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