Re: [discuss] Re: kgdb for x86_64 2.6 kernels
From: George Anzinger
Date: Wed Jan 14 2004 - 22:31:02 EST
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@xxxxxxxxxx
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/