* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-10 10:41 ` Amit S. Kale
@ 2004-01-10 15:03 ` Pavel Machek
2004-01-10 18:14 ` Pavel Machek
` (2 subsequent siblings)
3 siblings, 0 replies; 28+ messages in thread
From: Pavel Machek @ 2004-01-10 15:03 UTC (permalink / raw)
To: Amit S. Kale
Cc: George Anzinger, Andrew Morton, jim.houston, discuss, ak,
shivaram.upadhyayula, lkml
Hi!
> I have released kgdb 2.0.1 for kernel 2.6.1:
> http://kgdb.sourceforge.net/linux-2.6.1-kgdb-2.0.1.tar.bz2
>
> It doesn't contain any assert stuff. I have split it into multiple parts to
> make a merge easier. Please let me know if you want me to further split them
> or if you want something to be changed. The README file from this tarball is
> pasted below.
>
> Here is two possible starting points:
> 1. SMP stuff -> Replace my old smp and nmi handling code.
> 2. Early boot -> Change 8250.patch to make configuration of serial port either
> through config options or through command line.
>
> I'll attempt reading your patch and merging as much stuff as possible.
> Thanks.
>
> Patch:
> ------
> Patch the kernel out of following patches.
> core.patch - KGDB architecture and interface independent code. Required.
> i386.patch - i386 architecture dependent part. Required only for that
> architecture.
> x86_64.patch - x86_64 architecture dependent part. Required only for that
> architecture.
> 8250.patch - Generic serial port (8250 and 16550) interface for kgdb. This
> is the only working interface in this release. Hence required.
> eth.patch - Ethernet interface for kgdb. This is still under development.
> Use only if you plan to contribute to its development.
It worked in 2.6something-mm. I'll try to take a look at this one; the
code is way better than -mm version. Hopefully getting kgdbeth to work
will not be that hard.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-10 10:41 ` Amit S. Kale
2004-01-10 15:03 ` Pavel Machek
@ 2004-01-10 18:14 ` Pavel Machek
2004-01-12 14:32 ` Amit S. Kale
2004-01-10 19:30 ` Pavel Machek
2004-01-12 6:00 ` George Anzinger
3 siblings, 1 reply; 28+ messages in thread
From: Pavel Machek @ 2004-01-10 18:14 UTC (permalink / raw)
To: Amit S. Kale
Cc: George Anzinger, Andrew Morton, jim.houston, discuss, ak,
shivaram.upadhyayula, lkml
Hi!
> I have released kgdb 2.0.1 for kernel 2.6.1:
> http://kgdb.sourceforge.net/linux-2.6.1-kgdb-2.0.1.tar.bz2
>
> It doesn't contain any assert stuff. I have split it into multiple parts to
> make a merge easier. Please let me know if you want me to further split them
> or if you want something to be changed. The README file from this tarball is
> pasted below.
>
> Here is two possible starting points:
> 1. SMP stuff -> Replace my old smp and nmi handling code.
> 2. Early boot -> Change 8250.patch to make configuration of serial port either
> through config options or through command line.
>
> I'll attempt reading your patch and merging as much stuff as possible.
> Thanks.
I'm getting error:
CC kernel/kgdbstub.o
kernel/kgdbstub.c: In function `kgdb_handle_exception':
kernel/kgdbstub.c:646: error: `thref' undeclared (first use in this
function)
kernel/kgdbstub.c:646: error: (Each undeclared identifier is reported
only once
kernel/kgdbstub.c:646: error: for each function it appears in.)
kernel/kgdbstub.c:677: error: `thread' undeclared (first use in this
function)
make[1]: *** [kernel/kgdbstub.o] Error 1
make: *** [kernel] Error 2
44.97user 3.71system 59.51 (0m59.514s) elapsed 81.81%CPU
I enabled KGDB_THREAD and problem went away.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-10 18:14 ` Pavel Machek
@ 2004-01-12 14:32 ` Amit S. Kale
0 siblings, 0 replies; 28+ messages in thread
From: Amit S. Kale @ 2004-01-12 14:32 UTC (permalink / raw)
To: Pavel Machek
Cc: George Anzinger, Andrew Morton, jim.houston, discuss, ak,
shivaram.upadhyayula, lkml
Fixed. Thanks.
On Saturday 10 Jan 2004 11:44 pm, Pavel Machek wrote:
> Hi!
>
> > I have released kgdb 2.0.1 for kernel 2.6.1:
> > http://kgdb.sourceforge.net/linux-2.6.1-kgdb-2.0.1.tar.bz2
> >
> > It doesn't contain any assert stuff. I have split it into multiple parts
> > to make a merge easier. Please let me know if you want me to further
> > split them or if you want something to be changed. The README file from
> > this tarball is pasted below.
> >
> > Here is two possible starting points:
> > 1. SMP stuff -> Replace my old smp and nmi handling code.
> > 2. Early boot -> Change 8250.patch to make configuration of serial port
> > either through config options or through command line.
> >
> > I'll attempt reading your patch and merging as much stuff as possible.
> > Thanks.
>
> I'm getting error:
>
> CC kernel/kgdbstub.o
> kernel/kgdbstub.c: In function `kgdb_handle_exception':
> kernel/kgdbstub.c:646: error: `thref' undeclared (first use in this
> function)
> kernel/kgdbstub.c:646: error: (Each undeclared identifier is reported
> only once
> kernel/kgdbstub.c:646: error: for each function it appears in.)
> kernel/kgdbstub.c:677: error: `thread' undeclared (first use in this
> function)
> make[1]: *** [kernel/kgdbstub.o] Error 1
> make: *** [kernel] Error 2
> 44.97user 3.71system 59.51 (0m59.514s) elapsed 81.81%CPU
>
> I enabled KGDB_THREAD and problem went away.
>
> Pavel
--
Amit Kale
EmSysSoft (http://www.emsyssoft.com)
KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net)
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-10 10:41 ` Amit S. Kale
2004-01-10 15:03 ` Pavel Machek
2004-01-10 18:14 ` Pavel Machek
@ 2004-01-10 19:30 ` Pavel Machek
2004-01-12 14:31 ` Amit S. Kale
2004-01-12 6:00 ` George Anzinger
3 siblings, 1 reply; 28+ messages in thread
From: Pavel Machek @ 2004-01-10 19:30 UTC (permalink / raw)
To: Amit S. Kale
Cc: George Anzinger, Andrew Morton, jim.houston, discuss, ak,
shivaram.upadhyayula, lkml
Hi!
> Well said!
>
> I have released kgdb 2.0.1 for kernel 2.6.1:
> http://kgdb.sourceforge.net/linux-2.6.1-kgdb-2.0.1.tar.bz2
>
> It doesn't contain any assert stuff. I have split it into multiple parts to
> make a merge easier. Please let me know if you want me to further split them
> or if you want something to be changed. The README file from this tarball is
> pasted below.
>
> Here is two possible starting points:
> 1. SMP stuff -> Replace my old smp and nmi handling code.
> 2. Early boot -> Change 8250.patch to make configuration of serial port either
> through config options or through command line.
>
> I'll attempt reading your patch and merging as much stuff as
> possible.
Fix round of changes:
* kgdbeth_opt does not initialize ipaddrptr -> this could not have
ever worked. [Okay, it still does not work].
* Add some basic documentation
* reply_arp can be static, AFAICS
* getDebugChar() no longer exists, kill it from the docs, read_char()
should be equivalent.
* eth_PutDebugChar() seems to be no longer used. Kill it.
Please apply,
Pavel
--- tmp/linux/drivers/net/kgdb_eth.c 2004-01-10 20:16:10.000000000 +0100
+++ linux/drivers/net/kgdb_eth.c 2004-01-10 20:10:27.000000000 +0100
@@ -72,8 +72,7 @@
read_char(void)
{
/* intr routine has queued chars */
- if (atomic_read(&kgdb_buf_in_cnt) != 0)
- {
+ if (atomic_read(&kgdb_buf_in_cnt) != 0) {
int chr;
chr = kgdb_buf[kgdb_buf_out_inx++] ;
@@ -150,8 +149,6 @@
kgdb_netdevice->hard_start_xmit(skb, kgdb_netdevice);
kgdb_netdevice->xmit_lock_owner = -1;
spin_unlock(&kgdb_netdevice->xmit_lock);
-
- /* kfree_skb(skb); */
}
static void kgdbeth_flush(void)
@@ -179,7 +176,7 @@
static struct sk_buff *send_skb = NULL;
-void
+static void
kgdb_eth_reply_arp(void)
{
if (send_skb) {
@@ -313,12 +310,12 @@
* Accept an skbuff from net_device layer and add the payload onto
* kgdb buffer
*
- * When the kgdb stub routine getDebugChar() is called it draws characters
+ * When the kgdb stub routine read_char() is called it draws characters
* out of the buffer until it is empty and then reads directly from the
* serial port.
*
* We do not attempt to write chars from the interrupt routine since
- * the stubs do all of that via putDebugChar() which writes one byte
+ * the stubs do all of that via write_char() which writes one byte
* after waiting for the interface to become ready.
*
* The debug stubs like to run with interrupts disabled since, after all,
@@ -434,7 +431,7 @@
}
/*
- * getDebugChar
+ * kgdbeth_read_char
*
* This is a GDB stub routine. It waits for a character from the
* serial interface and then returns it. If there is no serial
@@ -455,42 +452,6 @@
return chr;
}
-#define ETH_QUEUE_SIZE 256
-static char eth_queue[ETH_QUEUE_SIZE];
-static int outgoing_queue;
-
-void
-eth_flushDebugChar(void)
-{
- if(outgoing_queue) {
- write_buffer(eth_queue, outgoing_queue);
-
- outgoing_queue = 0;
- }
-}
-
-static void
-put_char_on_queue(int chr)
-{
- eth_queue[outgoing_queue++] = chr;
- if(outgoing_queue == ETH_QUEUE_SIZE)
- {
- eth_flushDebugChar();
- }
-}
-
-/*
- * eth_putDebugChar
- *
- * This is a GDB stub routine. It waits until the interface is ready
- * to transmit a char and then sends it.
- */
-void
-eth_putDebugChar(int chr)
-{
- put_char_on_queue(chr); /* this routine will wait */
-}
-
static void kgdbeth_begin_session(void)
{
kgdbeth_is_trapped = 1;
@@ -546,7 +507,7 @@
static int __init kgdbeth_opt(char *str)
{
char ipaddrstr[16];
- char *ipaddrptr;
+ char *ipaddrptr = ipaddrstr;
/* interfacenum */
if (*str < '0' || *str > '9')
--- /dev/null 2003-09-12 10:38:14.000000000 +0200
+++ linux/Documentation/kgdb/kgdb_eth.txt 2004-01-10 19:53:37.000000000 +0100
@@ -0,0 +1,10 @@
+Some notes about kgdb over ethernet
+
+ 2004 Pavel Machek <pavel@suse.cz>
+
+
+kgdbeth=interfacenum,localmac,listenport,remoteip,remotemac
+
+Then
+ % gdb ./vmlinux
+ (gdb) target remote udp:HOSTNAME:6443
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-10 19:30 ` Pavel Machek
@ 2004-01-12 14:31 ` Amit S. Kale
0 siblings, 0 replies; 28+ messages in thread
From: Amit S. Kale @ 2004-01-12 14:31 UTC (permalink / raw)
To: Pavel Machek
Cc: George Anzinger, Andrew Morton, jim.houston, discuss, ak,
shivaram.upadhyayula, lkml
Done. Thanks.
On Sunday 11 Jan 2004 1:00 am, Pavel Machek wrote:
> Hi!
>
> > Well said!
> >
> > I have released kgdb 2.0.1 for kernel 2.6.1:
> > http://kgdb.sourceforge.net/linux-2.6.1-kgdb-2.0.1.tar.bz2
> >
> > It doesn't contain any assert stuff. I have split it into multiple parts
> > to make a merge easier. Please let me know if you want me to further
> > split them or if you want something to be changed. The README file from
> > this tarball is pasted below.
> >
> > Here is two possible starting points:
> > 1. SMP stuff -> Replace my old smp and nmi handling code.
> > 2. Early boot -> Change 8250.patch to make configuration of serial port
> > either through config options or through command line.
> >
> > I'll attempt reading your patch and merging as much stuff as
> > possible.
>
> Fix round of changes:
>
> * kgdbeth_opt does not initialize ipaddrptr -> this could not have
> ever worked. [Okay, it still does not work].
>
> * Add some basic documentation
>
> * reply_arp can be static, AFAICS
>
> * getDebugChar() no longer exists, kill it from the docs, read_char()
> should be equivalent.
>
> * eth_PutDebugChar() seems to be no longer used. Kill it.
>
> Please apply,
> Pavel
>
>
> --- tmp/linux/drivers/net/kgdb_eth.c 2004-01-10 20:16:10.000000000 +0100
> +++ linux/drivers/net/kgdb_eth.c 2004-01-10 20:10:27.000000000 +0100
> @@ -72,8 +72,7 @@
> read_char(void)
> {
> /* intr routine has queued chars */
> - if (atomic_read(&kgdb_buf_in_cnt) != 0)
> - {
> + if (atomic_read(&kgdb_buf_in_cnt) != 0) {
> int chr;
>
> chr = kgdb_buf[kgdb_buf_out_inx++] ;
> @@ -150,8 +149,6 @@
> kgdb_netdevice->hard_start_xmit(skb, kgdb_netdevice);
> kgdb_netdevice->xmit_lock_owner = -1;
> spin_unlock(&kgdb_netdevice->xmit_lock);
> -
> - /* kfree_skb(skb); */
> }
>
> static void kgdbeth_flush(void)
> @@ -179,7 +176,7 @@
>
> static struct sk_buff *send_skb = NULL;
>
> -void
> +static void
> kgdb_eth_reply_arp(void)
> {
> if (send_skb) {
> @@ -313,12 +310,12 @@
> * Accept an skbuff from net_device layer and add the payload onto
> * kgdb buffer
> *
> - * When the kgdb stub routine getDebugChar() is called it draws characters
> + * When the kgdb stub routine read_char() is called it draws characters
> * out of the buffer until it is empty and then reads directly from the
> * serial port.
> *
> * We do not attempt to write chars from the interrupt routine since
> - * the stubs do all of that via putDebugChar() which writes one byte
> + * the stubs do all of that via write_char() which writes one byte
> * after waiting for the interface to become ready.
> *
> * The debug stubs like to run with interrupts disabled since, after all,
> @@ -434,7 +431,7 @@
> }
>
> /*
> - * getDebugChar
> + * kgdbeth_read_char
> *
> * This is a GDB stub routine. It waits for a character from the
> * serial interface and then returns it. If there is no serial
> @@ -455,42 +452,6 @@
> return chr;
> }
>
> -#define ETH_QUEUE_SIZE 256
> -static char eth_queue[ETH_QUEUE_SIZE];
> -static int outgoing_queue;
> -
> -void
> -eth_flushDebugChar(void)
> -{
> - if(outgoing_queue) {
> - write_buffer(eth_queue, outgoing_queue);
> -
> - outgoing_queue = 0;
> - }
> -}
> -
> -static void
> -put_char_on_queue(int chr)
> -{
> - eth_queue[outgoing_queue++] = chr;
> - if(outgoing_queue == ETH_QUEUE_SIZE)
> - {
> - eth_flushDebugChar();
> - }
> -}
> -
> -/*
> - * eth_putDebugChar
> - *
> - * This is a GDB stub routine. It waits until the interface is ready
> - * to transmit a char and then sends it.
> - */
> -void
> -eth_putDebugChar(int chr)
> -{
> - put_char_on_queue(chr); /* this routine will wait */
> -}
> -
> static void kgdbeth_begin_session(void)
> {
> kgdbeth_is_trapped = 1;
> @@ -546,7 +507,7 @@
> static int __init kgdbeth_opt(char *str)
> {
> char ipaddrstr[16];
> - char *ipaddrptr;
> + char *ipaddrptr = ipaddrstr;
>
> /* interfacenum */
> if (*str < '0' || *str > '9')
> --- /dev/null 2003-09-12 10:38:14.000000000 +0200
> +++ linux/Documentation/kgdb/kgdb_eth.txt 2004-01-10 19:53:37.000000000
> +0100 @@ -0,0 +1,10 @@
> +Some notes about kgdb over ethernet
> +
> + 2004 Pavel Machek <pavel@suse.cz>
> +
> +
> +kgdbeth=interfacenum,localmac,listenport,remoteip,remotemac
> +
> +Then
> + % gdb ./vmlinux
> + (gdb) target remote udp:HOSTNAME:6443
--
Amit Kale
EmSysSoft (http://www.emsyssoft.com)
KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net)
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-10 10:41 ` Amit S. Kale
` (2 preceding siblings ...)
2004-01-10 19:30 ` Pavel Machek
@ 2004-01-12 6:00 ` George Anzinger
2004-01-12 9:47 ` Pavel Machek
2004-01-12 14:50 ` Amit S. Kale
3 siblings, 2 replies; 28+ messages in thread
From: George Anzinger @ 2004-01-12 6:00 UTC (permalink / raw)
To: Amit S. Kale
Cc: Andrew Morton, jim.houston, discuss, ak, shivaram.upadhyayula,
lkml, Pavel Machek
Amit S. Kale wrote:
> George,
>
> Well said!
>
> I have released kgdb 2.0.1 for kernel 2.6.1:
> http://kgdb.sourceforge.net/linux-2.6.1-kgdb-2.0.1.tar.bz2
>
> It doesn't contain any assert stuff. I have split it into multiple parts to
> make a merge easier. Please let me know if you want me to further split them
> or if you want something to be changed. The README file from this tarball is
> pasted below.
>
> Here is two possible starting points:
> 1. SMP stuff -> Replace my old smp and nmi handling code.
> 2. Early boot -> Change 8250.patch to make configuration of serial port either
> through config options or through command line.
What does messing with 8250.c code buy us? I use a completely independent UART
driver and only have "back off" code in the 8250 driver. In fact, I usually
recommend that the serial (i.e. 8250.c) driver not even be loaded. My code also
allows a more aggressive hookup to the interrupt code, to get the ^C to do its
thing. I REALLY would like to keep Mr. Heisenberg out of kgdb. By using
existing kernel code we are inviting him to visit.
>
> I'll attempt reading your patch and merging as much stuff as possible.
> Thanks.
May I suggest reading the comments preceeding the patch itself in Andrew's
breakout code. These were written by Ingo and, I think, reflect some of the
things he found useful.
Also, the information found in .../Documentation/i386/kgdb/* of the patch.
>
> Patch:
> ------
> Patch the kernel out of following patches.
> core.patch - KGDB architecture and interface independent code. Required.
> i386.patch - i386 architecture dependent part. Required only for that
> architecture.
> x86_64.patch - x86_64 architecture dependent part. Required only for that
> architecture.
> 8250.patch - Generic serial port (8250 and 16550) interface for kgdb. This
> is the only working interface in this release. Hence required.
> eth.patch - Ethernet interface for kgdb. This is still under development.
> Use only if you plan to contribute to its development.
>
> Build:
> ------
> Enable following config options (in this order).
>
> Kernel hacking ->
> KGDB: kernel debugging with remote gdb ->
> KGDB: Thread analysis
> KGDB: Console messages through gdb
> Device drivers ->
> Character devices ->
> Serial drivers ->
> KGDB: On generic serial port (8250)
If KGDB is on, this should not be needed. Also the driver part of KGDB should
be local to the KGDB configure in the configure file. I think we should ALWAYS
have the serial link. The eth link should be backed up by the serial link.
By the way, I will be out of town on Monday, back on Tuesday.
George
>
> Boot:
> -----
> Supply command line options kgdbwait and kgdb8250 to the kernel.
> Example: kgdbwait kgdb8250=1,115200
>
> On Saturday 10 Jan 2004 3:46 am, George Anzinger wrote:
>
>>Amit,
>>
>>The base line kgdb code in the mm patches was offered by me. It derives
>>from (a long time ago) a kgdb I got from the RTIA (or was it the RTLINUX)
>>folks. Prio to that, well, your name is on it as well as others.
>>
>>As you may have noted there have been a lot of changes, mostly for the
>>better, I hope. I think we have slightly different objectives in our work.
>> I debug kernels, not drivers, so I am interested in getting into kgdb as
>>early as possible. To this end the current mm patch allows one to put a
>>breakpoint() as the first line of C code in the kernel. This required a
>>few adjustments, such as configuring the I/O port at CONFIG time, for
>>example.
>>
>>I would like for the two versions of kgdb to merge while keeping the
>>features of both. The work on seperating the common code is something I
>>like and, while I never do modules, the automatic module stuff in gdb sound
>>good.
>>
>>May I suggest that we compare and contrast the two versions and take a look
>>at the differences and the overlaps and settle on one way of doing the
>>various things.
>>
>>George
>
>
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-12 6:00 ` George Anzinger
@ 2004-01-12 9:47 ` Pavel Machek
2004-01-13 20:55 ` George Anzinger
2004-01-12 14:50 ` Amit S. Kale
1 sibling, 1 reply; 28+ messages in thread
From: Pavel Machek @ 2004-01-12 9:47 UTC (permalink / raw)
To: George Anzinger
Cc: Amit S. Kale, Andrew Morton, jim.houston, discuss, ak,
shivaram.upadhyayula, lkml, Pavel Machek
Hi!
> >I'll attempt reading your patch and merging as much stuff as possible.
> >Thanks.
>
> May I suggest reading the comments preceeding the patch itself in Andrew's
> breakout code. These were written by Ingo and, I think, reflect some of
> the things he found useful.
>
> Also, the information found in .../Documentation/i386/kgdb/* of the
>patch.
Some docs would be nice, but we probably want to have it in
Documentation/kgdb/, as it is no longer i386-specific.
Pavel
--
When do you have heart between your knees?
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-12 9:47 ` Pavel Machek
@ 2004-01-13 20:55 ` George Anzinger
0 siblings, 0 replies; 28+ messages in thread
From: George Anzinger @ 2004-01-13 20:55 UTC (permalink / raw)
To: Pavel Machek
Cc: Amit S. Kale, Andrew Morton, jim.houston, discuss, ak,
shivaram.upadhyayula, lkml, Pavel Machek
Pavel Machek wrote:
> Hi!
>
>
>>>I'll attempt reading your patch and merging as much stuff as possible.
>>>Thanks.
>>
>>May I suggest reading the comments preceeding the patch itself in Andrew's
>>breakout code. These were written by Ingo and, I think, reflect some of
>>the things he found useful.
>>
>>Also, the information found in .../Documentation/i386/kgdb/* of the
>>patch.
>
>
> Some docs would be nice, but we probably want to have it in
> Documentation/kgdb/, as it is no longer i386-specific.
and then sub arch under that for arch differences. I like it.
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-12 6:00 ` George Anzinger
2004-01-12 9:47 ` Pavel Machek
@ 2004-01-12 14:50 ` Amit S. Kale
2004-01-13 21:26 ` George Anzinger
1 sibling, 1 reply; 28+ messages in thread
From: Amit S. Kale @ 2004-01-12 14:50 UTC (permalink / raw)
To: George Anzinger
Cc: Andrew Morton, jim.houston, discuss, ak, shivaram.upadhyayula,
lkml, Pavel Machek
8250.patch changes generic 8250/16550 driver behavior only in following ways
1. It adds a function serial8250_release_irq to release those serial ports
which share an irq with kgdb irq.
2. There are checks so that a serial port that uses an irq used by an
initialized kgdb can't be initialized or started.
File kgdb_8250.c is independent of 8250.c kgdb_8250.c depends on KGDB_8250 and
8250.c depends on SERIAL_8250 which can be independently configured.
kgdb_8250.c can be compiled even if 8250.c is not included. kgdb_8250.c does
only the _minimum_ set of initializations required by hardware.
Serial interface should be configurable independent of kgdb and may not be
configured if ethernet interface is configured. Serial interface is far
simpler hence superior for debugging purposes. If it's available, using
ethernet interface is out of question. Ethernet interface can be used when
serial hardware isn't present or is being used for some other purposes.
On Monday 12 Jan 2004 11:30 am, George Anzinger wrote:
> Amit S. Kale wrote:
> > George,
> >
> > Well said!
> >
> > I have released kgdb 2.0.1 for kernel 2.6.1:
> > http://kgdb.sourceforge.net/linux-2.6.1-kgdb-2.0.1.tar.bz2
> >
> > It doesn't contain any assert stuff. I have split it into multiple parts
> > to make a merge easier. Please let me know if you want me to further
> > split them or if you want something to be changed. The README file from
> > this tarball is pasted below.
> >
> > Here is two possible starting points:
> > 1. SMP stuff -> Replace my old smp and nmi handling code.
> > 2. Early boot -> Change 8250.patch to make configuration of serial port
> > either through config options or through command line.
>
> What does messing with 8250.c code buy us? I use a completely independent
> UART driver and only have "back off" code in the 8250 driver. In fact, I
> usually recommend that the serial (i.e. 8250.c) driver not even be loaded.
> My code also allows a more aggressive hookup to the interrupt code, to get
> the ^C to do its thing. I REALLY would like to keep Mr. Heisenberg out of
> kgdb. By using existing kernel code we are inviting him to visit.
>
> > I'll attempt reading your patch and merging as much stuff as possible.
> > Thanks.
>
> May I suggest reading the comments preceeding the patch itself in Andrew's
> breakout code. These were written by Ingo and, I think, reflect some of
> the things he found useful.
>
> Also, the information found in .../Documentation/i386/kgdb/* of the patch.
>
> > Patch:
> > ------
> > Patch the kernel out of following patches.
> > core.patch - KGDB architecture and interface independent code. Required.
> > i386.patch - i386 architecture dependent part. Required only for that
> > architecture.
> > x86_64.patch - x86_64 architecture dependent part. Required only for that
> > architecture.
> > 8250.patch - Generic serial port (8250 and 16550) interface for kgdb.
> > This is the only working interface in this release. Hence required.
> > eth.patch - Ethernet interface for kgdb. This is still under development.
> > Use only if you plan to contribute to its development.
> >
> > Build:
> > ------
> > Enable following config options (in this order).
> >
> > Kernel hacking ->
> > KGDB: kernel debugging with remote gdb ->
> > KGDB: Thread analysis
> > KGDB: Console messages through gdb
> > Device drivers ->
> > Character devices ->
> > Serial drivers ->
> > KGDB: On generic serial port (8250)
>
> If KGDB is on, this should not be needed. Also the driver part of KGDB
> should be local to the KGDB configure in the configure file. I think we
> should ALWAYS have the serial link. The eth link should be backed up by
> the serial link.
>
> By the way, I will be out of town on Monday, back on Tuesday.
>
> George
>
> > Boot:
> > -----
> > Supply command line options kgdbwait and kgdb8250 to the kernel.
> > Example: kgdbwait kgdb8250=1,115200
> >
> > On Saturday 10 Jan 2004 3:46 am, George Anzinger wrote:
> >>Amit,
> >>
> >>The base line kgdb code in the mm patches was offered by me. It derives
> >>from (a long time ago) a kgdb I got from the RTIA (or was it the RTLINUX)
> >>folks. Prio to that, well, your name is on it as well as others.
> >>
> >>As you may have noted there have been a lot of changes, mostly for the
> >>better, I hope. I think we have slightly different objectives in our
> >> work. I debug kernels, not drivers, so I am interested in getting into
> >> kgdb as early as possible. To this end the current mm patch allows one
> >> to put a breakpoint() as the first line of C code in the kernel. This
> >> required a few adjustments, such as configuring the I/O port at CONFIG
> >> time, for example.
> >>
> >>I would like for the two versions of kgdb to merge while keeping the
> >>features of both. The work on seperating the common code is something I
> >>like and, while I never do modules, the automatic module stuff in gdb
> >> sound good.
> >>
> >>May I suggest that we compare and contrast the two versions and take a
> >> look at the differences and the overlaps and settle on one way of doing
> >> the various things.
> >>
> >>George
--
Amit Kale
EmSysSoft (http://www.emsyssoft.com)
KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net)
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-12 14:50 ` Amit S. Kale
@ 2004-01-13 21:26 ` George Anzinger
2004-01-14 6:31 ` Matt Mackall
2004-01-14 13:24 ` Amit S. Kale
0 siblings, 2 replies; 28+ messages in thread
From: George Anzinger @ 2004-01-13 21:26 UTC (permalink / raw)
To: Amit S. Kale
Cc: Andrew Morton, jim.houston, discuss, ak, shivaram.upadhyayula,
lkml, Pavel Machek
Amit S. Kale wrote:
> 8250.patch changes generic 8250/16550 driver behavior only in following ways
> 1. It adds a function serial8250_release_irq to release those serial ports
> which share an irq with kgdb irq.
> 2. There are checks so that a serial port that uses an irq used by an
> initialized kgdb can't be initialized or started.
>
> File kgdb_8250.c is independent of 8250.c kgdb_8250.c depends on KGDB_8250 and
> 8250.c depends on SERIAL_8250 which can be independently configured.
> kgdb_8250.c can be compiled even if 8250.c is not included. kgdb_8250.c does
> only the _minimum_ set of initializations required by hardware.
Ok.
>
> Serial interface should be configurable independent of kgdb and may not be
> configured if ethernet interface is configured. Serial interface is far
> simpler hence superior for debugging purposes. If it's available, using
> ethernet interface is out of question. Ethernet interface can be used when
> serial hardware isn't present or is being used for some other purposes.
>
I rather think that the serial inteface should be the fall back unless the user
has told us at configure time that it is not available. I am not prepared to
make a statment that it is better than eth. The eth intface should be much
faster, but it has its fingers into a large part of the kernel that MAY be the
subject of the current session. Thus, I think that eth may be better, IF one is
clearly not involved in debugging those areas of the kernel. (Which, by the
way, we need to enumerate at some point.)
> On Monday 12 Jan 2004 11:30 am, George Anzinger wrote:
>
>>Amit S. Kale wrote:
>>
>>>George,
>>>
>>>Well said!
>>>
>>>I have released kgdb 2.0.1 for kernel 2.6.1:
>>>http://kgdb.sourceforge.net/linux-2.6.1-kgdb-2.0.1.tar.bz2
>>>
>>>It doesn't contain any assert stuff. I have split it into multiple parts
>>>to make a merge easier. Please let me know if you want me to further
>>>split them or if you want something to be changed. The README file from
>>>this tarball is pasted below.
>>>
>>>Here is two possible starting points:
>>>1. SMP stuff -> Replace my old smp and nmi handling code.
>>>2. Early boot -> Change 8250.patch to make configuration of serial port
>>>either through config options or through command line.
>>
>>What does messing with 8250.c code buy us? I use a completely independent
>>UART driver and only have "back off" code in the 8250 driver. In fact, I
>>usually recommend that the serial (i.e. 8250.c) driver not even be loaded.
>>My code also allows a more aggressive hookup to the interrupt code, to get
>>the ^C to do its thing. I REALLY would like to keep Mr. Heisenberg out of
>>kgdb. By using existing kernel code we are inviting him to visit.
>>
>>
>>>I'll attempt reading your patch and merging as much stuff as possible.
>>>Thanks.
>>
>>May I suggest reading the comments preceeding the patch itself in Andrew's
>>breakout code. These were written by Ingo and, I think, reflect some of
>>the things he found useful.
>>
>>Also, the information found in .../Documentation/i386/kgdb/* of the patch.
>>
>>
>>>Patch:
>>>------
>>>Patch the kernel out of following patches.
>>>core.patch - KGDB architecture and interface independent code. Required.
>>>i386.patch - i386 architecture dependent part. Required only for that
>>> architecture.
>>>x86_64.patch - x86_64 architecture dependent part. Required only for that
>>> architecture.
>>>8250.patch - Generic serial port (8250 and 16550) interface for kgdb.
>>>This is the only working interface in this release. Hence required.
>>>eth.patch - Ethernet interface for kgdb. This is still under development.
>>>Use only if you plan to contribute to its development.
>>>
>>>Build:
>>>------
>>>Enable following config options (in this order).
>>>
>>>Kernel hacking ->
>>> KGDB: kernel debugging with remote gdb ->
>>> KGDB: Thread analysis
>>> KGDB: Console messages through gdb
>>>Device drivers ->
>>> Character devices ->
>>> Serial drivers ->
>>> KGDB: On generic serial port (8250)
>>
>>If KGDB is on, this should not be needed. Also the driver part of KGDB
>>should be local to the KGDB configure in the configure file. I think we
>>should ALWAYS have the serial link. The eth link should be backed up by
>>the serial link.
>>
>>By the way, I will be out of town on Monday, back on Tuesday.
>>
>>George
>>
>>
>>>Boot:
>>>-----
>>>Supply command line options kgdbwait and kgdb8250 to the kernel.
>>>Example: kgdbwait kgdb8250=1,115200
>>>
>>>On Saturday 10 Jan 2004 3:46 am, George Anzinger wrote:
>>>
>>>>Amit,
>>>>
>>>>The base line kgdb code in the mm patches was offered by me. It derives
>>>
>>>>from (a long time ago) a kgdb I got from the RTIA (or was it the RTLINUX)
>>>
>>>>folks. Prio to that, well, your name is on it as well as others.
>>>>
>>>>As you may have noted there have been a lot of changes, mostly for the
>>>>better, I hope. I think we have slightly different objectives in our
>>>>work. I debug kernels, not drivers, so I am interested in getting into
>>>>kgdb as early as possible. To this end the current mm patch allows one
>>>>to put a breakpoint() as the first line of C code in the kernel. This
>>>>required a few adjustments, such as configuring the I/O port at CONFIG
>>>>time, for example.
>>>>
>>>>I would like for the two versions of kgdb to merge while keeping the
>>>>features of both. The work on seperating the common code is something I
>>>>like and, while I never do modules, the automatic module stuff in gdb
>>>>sound good.
>>>>
>>>>May I suggest that we compare and contrast the two versions and take a
>>>>look at the differences and the overlaps and settle on one way of doing
>>>>the various things.
>>>>
>>>>George
>
>
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-13 21:26 ` George Anzinger
@ 2004-01-14 6:31 ` Matt Mackall
2004-01-14 20:02 ` George Anzinger
2004-01-14 13:24 ` Amit S. Kale
1 sibling, 1 reply; 28+ messages in thread
From: Matt Mackall @ 2004-01-14 6:31 UTC (permalink / raw)
To: George Anzinger
Cc: Amit S. Kale, Andrew Morton, jim.houston, discuss, ak,
shivaram.upadhyayula, lkml, Pavel Machek
On Tue, Jan 13, 2004 at 01:26:46PM -0800, George Anzinger wrote:
> >
> >Serial interface should be configurable independent of kgdb and may not be
> >configured if ethernet interface is configured. Serial interface is far
> >simpler hence superior for debugging purposes. If it's available, using
> >ethernet interface is out of question. Ethernet interface can be used when
> >serial hardware isn't present or is being used for some other purposes.
> >
> I rather think that the serial inteface should be the fall back unless the
> user has told us at configure time that it is not available. I am not
> prepared to make a statment that it is better than eth. The eth intface
> should be much faster, but it has its fingers into a large part of the
> kernel that MAY be the subject of the current session. Thus, I think that
> eth may be better, IF one is clearly not involved in debugging those areas
> of the kernel. (Which, by the way, we need to enumerate at some point.)
I have in mind creating some other interfaces that will be on a par
with serial for early boot availability. So lets not frame this in
terms of eth vs serial. We can throw a priority int in the config
interface, stuff that in the plug struct, and pick whichever one's
highest and claims to be currently available.
--
Matt Mackall : http://www.selenic.com : Linux development and consulting
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-14 6:31 ` Matt Mackall
@ 2004-01-14 20:02 ` George Anzinger
2004-01-14 23:26 ` Greg KH
0 siblings, 1 reply; 28+ messages in thread
From: George Anzinger @ 2004-01-14 20:02 UTC (permalink / raw)
To: Matt Mackall
Cc: Amit S. Kale, Andrew Morton, jim.houston, discuss, ak,
shivaram.upadhyayula, lkml, Pavel Machek
Matt Mackall wrote:
> On Tue, Jan 13, 2004 at 01:26:46PM -0800, George Anzinger wrote:
>
>>>Serial interface should be configurable independent of kgdb and may not be
>>>configured if ethernet interface is configured. Serial interface is far
>>>simpler hence superior for debugging purposes. If it's available, using
>>>ethernet interface is out of question. Ethernet interface can be used when
>>>serial hardware isn't present or is being used for some other purposes.
>>>
>>
>>I rather think that the serial inteface should be the fall back unless the
>>user has told us at configure time that it is not available. I am not
>>prepared to make a statment that it is better than eth. The eth intface
>>should be much faster, but it has its fingers into a large part of the
>>kernel that MAY be the subject of the current session. Thus, I think that
>>eth may be better, IF one is clearly not involved in debugging those areas
>>of the kernel. (Which, by the way, we need to enumerate at some point.)
>
>
> I have in mind creating some other interfaces that will be on a par
> with serial for early boot availability. So lets not frame this in
> terms of eth vs serial. We can throw a priority int in the config
> interface, stuff that in the plug struct, and pick whichever one's
> highest and claims to be currently available.
>
Right. I had hoped that we might one day be able to use the USB and I am sure
there are others.
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-14 20:02 ` George Anzinger
@ 2004-01-14 23:26 ` Greg KH
2004-01-15 0:02 ` George Anzinger
0 siblings, 1 reply; 28+ messages in thread
From: Greg KH @ 2004-01-14 23:26 UTC (permalink / raw)
To: George Anzinger
Cc: Matt Mackall, Amit S. Kale, Andrew Morton, jim.houston, discuss,
ak, shivaram.upadhyayula, lkml, Pavel Machek
On Wed, Jan 14, 2004 at 12:02:02PM -0800, George Anzinger wrote:
> Right. I had hoped that we might one day be able to use the USB and I am
> sure there are others.
Raw USB? Or some kind of USB to serial device?
Remember, USB needs interrupts to work, see the kdb patches for the mess
that people have tried to go through to send usb data without interrupts
(doesn't really work...)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-14 23:26 ` Greg KH
@ 2004-01-15 0:02 ` George Anzinger
2004-01-15 0:19 ` Pavel Machek
2004-01-15 0:23 ` Greg KH
0 siblings, 2 replies; 28+ messages in thread
From: George Anzinger @ 2004-01-15 0:02 UTC (permalink / raw)
To: Greg KH
Cc: Matt Mackall, Amit S. Kale, Andrew Morton, jim.houston, discuss,
ak, shivaram.upadhyayula, lkml, Pavel Machek
Greg KH wrote:
> On Wed, Jan 14, 2004 at 12:02:02PM -0800, George Anzinger wrote:
>
>>Right. I had hoped that we might one day be able to use the USB and I am
>>sure there are others.
>
>
> Raw USB? Or some kind of USB to serial device?
>
> Remember, USB needs interrupts to work, see the kdb patches for the mess
> that people have tried to go through to send usb data without interrupts
> (doesn't really work...)
I gave up on USB when I asked the following questions:
1. How many different HW USB master devices need to be supported (i.e. appear on
your normal line of MBs)? (answer, too many)
2. Can I isolate a USB port from the kernel so that it does not even know it is
there? (answer: NO)
What I want is a USB port that is completely coded in kgdb software (keeps
Heisenberg out). It would be a polled device except for the ^C (or equivalent)
interrupt.
We, of course, have the same issues with the eth interface. Far too much of the
rest of the kernel is involved in the communications with it. Also there are
way to many interfaces to code each one seperatly, thus the current effort using
a good deal of the kernel to remove all that special code. Of course Heisenberg
and all his friends and relations are taking up residence in that code :) Might
not be too bad except that his uncle is Murphy.
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-15 0:02 ` George Anzinger
@ 2004-01-15 0:19 ` Pavel Machek
2004-01-15 3:28 ` George Anzinger
2004-01-15 0:23 ` Greg KH
1 sibling, 1 reply; 28+ messages in thread
From: Pavel Machek @ 2004-01-15 0:19 UTC (permalink / raw)
To: George Anzinger
Cc: Greg KH, Matt Mackall, Amit S. Kale, Andrew Morton, jim.houston,
discuss, ak, shivaram.upadhyayula, lkml
Hi!
> >>Right. I had hoped that we might one day be able to use the USB and I am
> >>sure there are others.
> >
> >
> >Raw USB? Or some kind of USB to serial device?
> >
> >Remember, USB needs interrupts to work, see the kdb patches for the mess
> >that people have tried to go through to send usb data without interrupts
> >(doesn't really work...)
>
> I gave up on USB when I asked the following questions:
> 1. How many different HW USB master devices need to be supported (i.e.
> appear on your normal line of MBs)? (answer, too many)
> 2. Can I isolate a USB port from the kernel so that it does not even know
> it is there? (answer: NO)
>
> What I want is a USB port that is completely coded in kgdb software (keeps
> Heisenberg out). It would be a polled device except for the ^C (or
> equivalent) interrupt.
>
> We, of course, have the same issues with the eth interface. Far too much
> of the rest of the kernel is involved in the communications with it. Also
> there are way to many interfaces to code each one seperatly, thus the
> current effort using a good deal of the kernel to remove all that special
> code. Of course Heisenberg and all his friends and relations are taking up
> residence in that code :) Might not be too bad except that his uncle is
> Murphy.
I believe that usb only has UHCI, OHCI and EHCI drivers, the rest are
devices, but ?HCI is evil enough that ethernet looks like "nice and
easy" interface.
BTW it is not using that much of eth infrastructure, just the
driver. It should be possible to dedicate one ethernet to kgdb,
only...
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-15 0:19 ` Pavel Machek
@ 2004-01-15 3:28 ` George Anzinger
0 siblings, 0 replies; 28+ messages in thread
From: George Anzinger @ 2004-01-15 3:28 UTC (permalink / raw)
To: Pavel Machek
Cc: Greg KH, Matt Mackall, Amit S. Kale, Andrew Morton, jim.houston,
discuss, ak, shivaram.upadhyayula, lkml
Pavel Machek wrote:
> Hi!
>
>
>>>>Right. I had hoped that we might one day be able to use the USB and I am
>>>>sure there are others.
>>>
>>>
>>>Raw USB? Or some kind of USB to serial device?
>>>
>>>Remember, USB needs interrupts to work, see the kdb patches for the mess
>>>that people have tried to go through to send usb data without interrupts
>>>(doesn't really work...)
>>
>>I gave up on USB when I asked the following questions:
>>1. How many different HW USB master devices need to be supported (i.e.
>>appear on your normal line of MBs)? (answer, too many)
>>2. Can I isolate a USB port from the kernel so that it does not even know
>>it is there? (answer: NO)
>>
>>What I want is a USB port that is completely coded in kgdb software (keeps
>>Heisenberg out). It would be a polled device except for the ^C (or
>>equivalent) interrupt.
>>
>>We, of course, have the same issues with the eth interface. Far too much
>>of the rest of the kernel is involved in the communications with it. Also
>>there are way to many interfaces to code each one seperatly, thus the
>>current effort using a good deal of the kernel to remove all that special
>>code. Of course Heisenberg and all his friends and relations are taking up
>>residence in that code :) Might not be too bad except that his uncle is
>>Murphy.
>
>
> I believe that usb only has UHCI, OHCI and EHCI drivers, the rest are
> devices, but ?HCI is evil enough that ethernet looks like "nice and
> easy" interface.
>
> BTW it is not using that much of eth infrastructure, just the
> driver. It should be possible to dedicate one ethernet to kgdb,
> only...
It is not the shared usage the frightens me so much as the shared kernel
resources. Slab and what not, to support the sbuff, is the first thing that
comes to mind. The next thing is the lateness of the bring up and that most of
the eth interfaces require some sort of pci scan/verify, what not to get
properly configured. Another issue in connection with the memory thing, as near
as I can determine, alloc and friends come up rather late in the boot sequence.
This has caused me fits in trying to get the ^C thing to work as an early
"request_irq" fails because the memory subsystem will not give up the needed
memory for the required table.
For example, if you register a function to handle a command line expression, it
depends on where, i.e. what load order, the code is as to what it can do.
Likewise the init functions. If the function is setting up an interrupt handler
it had better not be the first function the kernel calls about the command line
as the memory management code is not yet up. This is why, for example, in my
patch the serial driver is in .../arch/i386/lib/ as this is loaded last and
thus its functions get called later in the init sequence and can thus call
"request_irq()" and get a sucess return. Likewise the code that looks to see if
you want to go into kgdb first thing is in a module that is loaded first so as
to be there as early as possible.
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-15 0:02 ` George Anzinger
2004-01-15 0:19 ` Pavel Machek
@ 2004-01-15 0:23 ` Greg KH
2004-01-15 3:30 ` George Anzinger
1 sibling, 1 reply; 28+ messages in thread
From: Greg KH @ 2004-01-15 0:23 UTC (permalink / raw)
To: George Anzinger
Cc: Matt Mackall, Amit S. Kale, Andrew Morton, jim.houston, discuss,
ak, shivaram.upadhyayula, lkml, Pavel Machek
On Wed, Jan 14, 2004 at 04:02:45PM -0800, George Anzinger wrote:
> Greg KH wrote:
> >On Wed, Jan 14, 2004 at 12:02:02PM -0800, George Anzinger wrote:
> >
> >>Right. I had hoped that we might one day be able to use the USB and I am
> >>sure there are others.
> >
> >
> >Raw USB? Or some kind of USB to serial device?
> >
> >Remember, USB needs interrupts to work, see the kdb patches for the mess
> >that people have tried to go through to send usb data without interrupts
> >(doesn't really work...)
>
> I gave up on USB when I asked the following questions:
> 1. How many different HW USB master devices need to be supported (i.e.
> appear on your normal line of MBs)? (answer, too many)
There are only 3, UHCI, OHCI, and EHCI. You can forget about EHCI, as
all EHCI controllers contain either a UHCI or OHCI controller embedded
in them (EHCI only handles the USB2 high speed data.) So you really
only have to handle 2.
> 2. Can I isolate a USB port from the kernel so that it does not even know
> it is there? (answer: NO)
Sorry, this is correct. Unless you want to take over the whole pci
device that the USB controller is on. That's a possiblity you might
want to look into.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-15 0:23 ` Greg KH
@ 2004-01-15 3:30 ` George Anzinger
0 siblings, 0 replies; 28+ messages in thread
From: George Anzinger @ 2004-01-15 3:30 UTC (permalink / raw)
To: Greg KH
Cc: Matt Mackall, Amit S. Kale, Andrew Morton, jim.houston, discuss,
ak, shivaram.upadhyayula, lkml, Pavel Machek
Greg KH wrote:
> On Wed, Jan 14, 2004 at 04:02:45PM -0800, George Anzinger wrote:
>
>>Greg KH wrote:
>>
>>>On Wed, Jan 14, 2004 at 12:02:02PM -0800, George Anzinger wrote:
>>>
>>>
>>>>Right. I had hoped that we might one day be able to use the USB and I am
>>>>sure there are others.
>>>
>>>
>>>Raw USB? Or some kind of USB to serial device?
>>>
>>>Remember, USB needs interrupts to work, see the kdb patches for the mess
>>>that people have tried to go through to send usb data without interrupts
>>>(doesn't really work...)
>>
>>I gave up on USB when I asked the following questions:
>>1. How many different HW USB master devices need to be supported (i.e.
>>appear on your normal line of MBs)? (answer, too many)
>
>
> There are only 3, UHCI, OHCI, and EHCI. You can forget about EHCI, as
> all EHCI controllers contain either a UHCI or OHCI controller embedded
> in them (EHCI only handles the USB2 high speed data.) So you really
> only have to handle 2.
>
>
>>2. Can I isolate a USB port from the kernel so that it does not even know
>>it is there? (answer: NO)
>
>
> Sorry, this is correct. Unless you want to take over the whole pci
> device that the USB controller is on. That's a possiblity you might
> want to look into.
Each cpu, usually, has several USB controllers. I would only want to take over
one. Is that possible? If not, it means we can not debug USB drivers...
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-13 21:26 ` George Anzinger
2004-01-14 6:31 ` Matt Mackall
@ 2004-01-14 13:24 ` Amit S. Kale
2004-01-14 22:32 ` George Anzinger
1 sibling, 1 reply; 28+ messages in thread
From: Amit S. Kale @ 2004-01-14 13:24 UTC (permalink / raw)
To: George Anzinger
Cc: Andrew Morton, jim.houston, discuss, ak, shivaram.upadhyayula,
lkml, Pavel Machek
On Wednesday 14 Jan 2004 2:56 am, George Anzinger wrote:
> Amit S. Kale wrote:
> > 8250.patch changes generic 8250/16550 driver behavior only in following
> > ways 1. It adds a function serial8250_release_irq to release those serial
> > ports which share an irq with kgdb irq.
> > 2. There are checks so that a serial port that uses an irq used by an
> > initialized kgdb can't be initialized or started.
> >
> > File kgdb_8250.c is independent of 8250.c kgdb_8250.c depends on
> > KGDB_8250 and 8250.c depends on SERIAL_8250 which can be independently
> > configured. kgdb_8250.c can be compiled even if 8250.c is not included.
> > kgdb_8250.c does only the _minimum_ set of initializations required by
> > hardware.
>
> Ok.
>
> > Serial interface should be configurable independent of kgdb and may not
> > be configured if ethernet interface is configured. Serial interface is
> > far simpler hence superior for debugging purposes. If it's available,
> > using ethernet interface is out of question. Ethernet interface can be
> > used when serial hardware isn't present or is being used for some other
> > purposes.
>
> I rather think that the serial inteface should be the fall back unless the
> user has told us at configure time that it is not available. I am not
> prepared to make a statment that it is better than eth. The eth intface
> should be much faster, but it has its fingers into a large part of the
> kernel that MAY be the subject of the current session. Thus, I think that
> eth may be better, IF one is clearly not involved in debugging those areas
> of the kernel. (Which, by the way, we need to enumerate at some point.)
Ethernet interface spans a large part of the kernel, so is going to be limited
in near future. When it becomes as minimal as the serial interface, both may
be given equal priority.
At 115kbps, serial interface is usable even when doing a thread list of 200
threads.
Slow scanning of modules is a design problem in my gdb modifications, it'll be
corrected soon.
>
> > On Monday 12 Jan 2004 11:30 am, George Anzinger wrote:
> >>Amit S. Kale wrote:
> >>>George,
> >>>
> >>>Well said!
> >>>
> >>>I have released kgdb 2.0.1 for kernel 2.6.1:
> >>>http://kgdb.sourceforge.net/linux-2.6.1-kgdb-2.0.1.tar.bz2
> >>>
> >>>It doesn't contain any assert stuff. I have split it into multiple parts
> >>>to make a merge easier. Please let me know if you want me to further
> >>>split them or if you want something to be changed. The README file from
> >>>this tarball is pasted below.
> >>>
> >>>Here is two possible starting points:
> >>>1. SMP stuff -> Replace my old smp and nmi handling code.
> >>>2. Early boot -> Change 8250.patch to make configuration of serial port
> >>>either through config options or through command line.
> >>
> >>What does messing with 8250.c code buy us? I use a completely
> >> independent UART driver and only have "back off" code in the 8250
> >> driver. In fact, I usually recommend that the serial (i.e. 8250.c)
> >> driver not even be loaded. My code also allows a more aggressive hookup
> >> to the interrupt code, to get the ^C to do its thing. I REALLY would
> >> like to keep Mr. Heisenberg out of kgdb. By using existing kernel code
> >> we are inviting him to visit.
> >>
> >>>I'll attempt reading your patch and merging as much stuff as possible.
> >>>Thanks.
> >>
> >>May I suggest reading the comments preceeding the patch itself in
> >> Andrew's breakout code. These were written by Ingo and, I think,
> >> reflect some of the things he found useful.
> >>
> >>Also, the information found in .../Documentation/i386/kgdb/* of the
> >> patch.
> >>
> >>>Patch:
> >>>------
> >>>Patch the kernel out of following patches.
> >>>core.patch - KGDB architecture and interface independent code. Required.
> >>>i386.patch - i386 architecture dependent part. Required only for that
> >>> architecture.
> >>>x86_64.patch - x86_64 architecture dependent part. Required only for
> >>> that architecture.
> >>>8250.patch - Generic serial port (8250 and 16550) interface for kgdb.
> >>>This is the only working interface in this release. Hence required.
> >>>eth.patch - Ethernet interface for kgdb. This is still under
> >>> development. Use only if you plan to contribute to its development.
> >>>
> >>>Build:
> >>>------
> >>>Enable following config options (in this order).
> >>>
> >>>Kernel hacking ->
> >>> KGDB: kernel debugging with remote gdb ->
> >>> KGDB: Thread analysis
> >>> KGDB: Console messages through gdb
> >>>Device drivers ->
> >>> Character devices ->
> >>> Serial drivers ->
> >>> KGDB: On generic serial port (8250)
> >>
> >>If KGDB is on, this should not be needed. Also the driver part of KGDB
> >>should be local to the KGDB configure in the configure file. I think we
> >>should ALWAYS have the serial link. The eth link should be backed up by
> >>the serial link.
> >>
> >>By the way, I will be out of town on Monday, back on Tuesday.
> >>
> >>George
> >>
> >>>Boot:
> >>>-----
> >>>Supply command line options kgdbwait and kgdb8250 to the kernel.
> >>>Example: kgdbwait kgdb8250=1,115200
> >>>
> >>>On Saturday 10 Jan 2004 3:46 am, George Anzinger wrote:
> >>>>Amit,
> >>>>
> >>>>The base line kgdb code in the mm patches was offered by me. It
> >>>> derives
> >>>>
> >>>>from (a long time ago) a kgdb I got from the RTIA (or was it the
> >>>> RTLINUX)
> >>>>
> >>>>folks. Prio to that, well, your name is on it as well as others.
> >>>>
> >>>>As you may have noted there have been a lot of changes, mostly for the
> >>>>better, I hope. I think we have slightly different objectives in our
> >>>>work. I debug kernels, not drivers, so I am interested in getting into
> >>>>kgdb as early as possible. To this end the current mm patch allows one
> >>>>to put a breakpoint() as the first line of C code in the kernel. This
> >>>>required a few adjustments, such as configuring the I/O port at CONFIG
> >>>>time, for example.
> >>>>
> >>>>I would like for the two versions of kgdb to merge while keeping the
> >>>>features of both. The work on seperating the common code is something
> >>>> I like and, while I never do modules, the automatic module stuff in
> >>>> gdb sound good.
> >>>>
> >>>>May I suggest that we compare and contrast the two versions and take a
> >>>>look at the differences and the overlaps and settle on one way of doing
> >>>>the various things.
> >>>>
> >>>>George
--
Amit Kale
EmSysSoft (http://www.emsyssoft.com)
KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net)
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [discuss] Re: kgdb for x86_64 2.6 kernels
2004-01-14 13:24 ` Amit S. Kale
@ 2004-01-14 22:32 ` George Anzinger
0 siblings, 0 replies; 28+ messages in thread
From: George Anzinger @ 2004-01-14 22:32 UTC (permalink / raw)
To: Amit S. Kale
Cc: Andrew Morton, jim.houston, discuss, ak, shivaram.upadhyayula,
lkml, Pavel Machek
Amit S. Kale wrote:
> On Wednesday 14 Jan 2004 2:56 am, George Anzinger wrote:
>
>>Amit S. Kale wrote:
>>
>>>8250.patch changes generic 8250/16550 driver behavior only in following
>>>ways 1. It adds a function serial8250_release_irq to release those serial
>>>ports which share an irq with kgdb irq.
>>>2. There are checks so that a serial port that uses an irq used by an
>>>initialized kgdb can't be initialized or started.
>>>
>>>File kgdb_8250.c is independent of 8250.c kgdb_8250.c depends on
>>>KGDB_8250 and 8250.c depends on SERIAL_8250 which can be independently
>>>configured. kgdb_8250.c can be compiled even if 8250.c is not included.
>>>kgdb_8250.c does only the _minimum_ set of initializations required by
>>>hardware.
>>
>>Ok.
>>
>>
>>>Serial interface should be configurable independent of kgdb and may not
>>>be configured if ethernet interface is configured. Serial interface is
>>>far simpler hence superior for debugging purposes. If it's available,
>>>using ethernet interface is out of question. Ethernet interface can be
>>>used when serial hardware isn't present or is being used for some other
>>>purposes.
>>
>>I rather think that the serial inteface should be the fall back unless the
>>user has told us at configure time that it is not available. I am not
>>prepared to make a statment that it is better than eth. The eth intface
>>should be much faster, but it has its fingers into a large part of the
>>kernel that MAY be the subject of the current session. Thus, I think that
>>eth may be better, IF one is clearly not involved in debugging those areas
>>of the kernel. (Which, by the way, we need to enumerate at some point.)
>
>
> Ethernet interface spans a large part of the kernel, so is going to be limited
> in near future. When it becomes as minimal as the serial interface, both may
> be given equal priority.
>
> At 115kbps, serial interface is usable even when doing a thread list of 200
> threads.
Only 200? :)
Yes, I agree, but the thing I see about the eth interface is that it allows much
more remote debugging, like accrost the country, and it is every so much easier
to set up. I don't know about you, but my experience with rs232, which after
all, can only be wired one of two ways, it that the probability of getting it
wrong is about 90%.
-g
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply [flat|nested] 28+ messages in thread