kgdb for x86_64 2.6 kernels

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

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.

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.

Hi!

Quoted 8 lines

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.

Quoted 7 lines

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

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.

Hi!

Quoted 10 lines

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.

Quoted 7 lines

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

drivers/net/kgdb_eth.c renamed from linux/drivers/net/kgdb_eth.c +6 -45

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

Documentation/kgdb/kgdb_eth.txt new file +11 -0

+0100 @@ -0,0 +1,10 @@
+Some notes about kgdb over ethernet
+
+ 2004 Pavel Machek <[email protected]>
+
+
+kgdbeth=interfacenum,localmac,listenport,remoteip,remotemac
+
+Then
+   % gdb ./vmlinux
+   (gdb) target remote udp:HOSTNAME:6443

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

Quoted 24 lines · 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

Quoted 2 lines

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.

Hi!

Quoted 3 lines

Quoted 2 lines

I'll attempt reading your patch and merging as much stuff as possible. Thanks.

Quoted 4 lines

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.

Quoted 12 lines · 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.

Quoted 4 lines

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.

Quoted 2 lines

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.

Quoted 17 lines

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

Quoted 8 lines

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

Quoted 30 lines

Boot:
-----
Supply command line options kgdbwait and kgdb8250 to the kernel.
Example: kgdbwait kgdb8250=1,115200

Quoted 24 lines · 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

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.

Quoted 106 lines

Quoted 12 lines · 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.

Quoted 4 lines

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.

Quoted 2 lines

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.

Quoted 17 lines

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

Quoted 8 lines

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

Quoted 33 lines

Boot:
-----
Supply command line options kgdbwait and kgdb8250 to the kernel.
Example: kgdbwait kgdb8250=1,115200

Quoted 26 lines · 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

Quoted 7 lines

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

Quoted 3 lines · George Anzinger

Quoted 2 lines

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.

Quoted 1 line

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.

Quoted 1 line · George Anzinger

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

Quoted 9 lines

Quoted 2 lines

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.

Hi!

Quoted 9 lines

Quoted 8 lines

Quoted 1 line

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

Quoted 7 lines

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

Quoted 8 lines · Greg KH

Quoted 2 lines · George Anzinger

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?

Quoted 3 lines

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)

Quoted 8 lines · George Anzinger

Quoted 6 lines · Greg KH

Quoted 1 line · George Anzinger

Right. I had hoped that we might one day be able to use the USB and I am sure there are others.

Quoted 8 lines

Quoted 5 lines

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.

Quoted 1 line

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.

Quoted 11 lines · 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.

Ok.

Quoted 6 lines

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

Quoted 107 lines · George Anzinger

Quoted 105 lines

Quoted 12 lines · 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.

Quoted 4 lines

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.

Quoted 2 lines

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.

Quoted 17 lines

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

Quoted 8 lines

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

Quoted 34 lines

Boot:
-----
Supply command line options kgdbwait and kgdb8250 to the kernel.
Example: kgdbwait kgdb8250=1,115200

Quoted 28 lines · 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

Quoted 24 lines · George Anzinger

Quoted 11 lines · 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.

Ok.

Quoted 6 lines

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.

Quoted 7 lines

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.