Re: [discuss] Re: kgdb for x86_64 2.6 kernels

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[George Anzinger]

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

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[Amit S. Kale]

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.

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.

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)
	
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)

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[Pavel Machek]

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?]

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[Pavel Machek]

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?]

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[Pavel Machek]

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?]

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[George Anzinger]

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

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[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?

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[Amit S. Kale]

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)

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[Amit S. Kale]

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)

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[Amit S. Kale]

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)

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[George Anzinger]

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

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[George Anzinger]

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

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[Matt Mackall]

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

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[Amit S. Kale]

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)

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[George Anzinger]

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

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[George Anzinger]

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

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[Greg KH]

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

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[George Anzinger]

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

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[Pavel Machek]

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?]

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[Greg KH]

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

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[George Anzinger]

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

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[George Anzinger]

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

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[Andi Kleen]

> I'd like to help also, but I don't have ICH4 or other usb-debug
> hardware AFAIK.

I suspect other vendors with EHCI support have it too. Check some data sheets.

-Andi

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[Randy.Dunlap]

On Thu, 15 Jan 2004 19:15:10 -0600 Matt Mackall <mpm@selenic.com> wrote:

| On Thu, Jan 15, 2004 at 09:52:17AM +0100, Andi Kleen wrote:
| > On Thu, Jan 15, 2004 at 12:36:58AM -0800, George Anzinger wrote:
| > > Now that is interesting.  As I read it, the debug port is programed the 
| > > same way in all the USB chips (given it exists at all).  AND it is much 
| > 
| > Yep, it's not PIO, but polled MMIO. Sorry for spreading misinformation.
| > 
| > > easier to use. Anyone care to put together a polling driver that makes it 
| > > look like RS232 on the host end given that we use a controller to 
| > > controller cable?
| > 
| > I suspect all laptop users with kernel bugs will admire whoever does that ;-)
| 
| I've been thinking about doing this, may get around to it eventually.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I'd like to help also, but I don't have ICH4 or other usb-debug
hardware AFAIK.

--
~Randy
Everything is relative.

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[Matt Mackall]

On Thu, Jan 15, 2004 at 09:52:17AM +0100, Andi Kleen wrote:
> On Thu, Jan 15, 2004 at 12:36:58AM -0800, George Anzinger wrote:
> > Now that is interesting.  As I read it, the debug port is programed the 
> > same way in all the USB chips (given it exists at all).  AND it is much 
> 
> Yep, it's not PIO, but polled MMIO. Sorry for spreading misinformation.
> 
> > easier to use. Anyone care to put together a polling driver that makes it 
> > look like RS232 on the host end given that we use a controller to 
> > controller cable?
> 
> I suspect all laptop users with kernel bugs will admire whoever does that ;-)

I've been thinking about doing this, may get around to it eventually.

-- 
Matt Mackall : http://www.selenic.com : Linux development and consulting

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[Andi Kleen]

On Thu, Jan 15, 2004 at 12:36:58AM -0800, George Anzinger wrote:
> Now that is interesting.  As I read it, the debug port is programed the 
> same way in all the USB chips (given it exists at all).  AND it is much 

Yep, it's not PIO, but polled MMIO. Sorry for spreading misinformation.

> easier to use. Anyone care to put together a polling driver that makes it 
> look like RS232 on the host end given that we use a controller to 
> controller cable?

I suspect all laptop users with kernel bugs will admire whoever does that ;-)

-Andi

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[George Anzinger]

Andi Kleen wrote:
> George Anzinger <george@mvista.com> writes:
> 
> 
>>>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:
> 
> 
> There is a special "USB debugport" specification available that allows
> to drive USB very simply using PIO without too much set up. It should
> be implemented in most chipsets by now because that other operating
> system is using it.
> 
> See e.g. http://www.usb.org/developers/presentations/pres0602/john_keys.pdf
> 
> It works with a simple "debug dongle", that is identical to the 
> USB networking cables that are often sold cheaply.
> 
> If you want to port kgdb to use USB I would use that. USB console
> would also be very useful for debugging laptops and some systems
> with no USB.

Now that is interesting.  As I read it, the debug port is programed the same way 
in all the USB chips (given it exists at all).  AND it is much easier to use. 
Anyone care to put together a polling driver that makes it look like RS232 on 
the host end given that we use a controller to controller cable?


-- 
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

Re: [discuss] Re: kgdb for x86_64 2.6 kernels

[Andi Kleen]

George Anzinger <george@mvista.com> writes:

>> 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:

There is a special "USB debugport" specification available that allows
to drive USB very simply using PIO without too much set up. It should
be implemented in most chipsets by now because that other operating
system is using it.

See e.g. http://www.usb.org/developers/presentations/pres0602/john_keys.pdf

It works with a simple "debug dongle", that is identical to the 
USB networking cables that are often sold cheaply.

If you want to port kgdb to use USB I would use that. USB console
would also be very useful for debugging laptops and some systems
with no USB.

-Andi