> On Fri, 14 Jul 2006 14:50:16 -0400 (EDT)
> Alan Stern <[email protected]> wrote:
>
> > On Fri, 14 Jul 2006, Andrew Morton wrote:
> >
> > > On Fri, 14 Jul 2006 16:54:25 +0100
> > > "Andy Chittenden" <[email protected]> wrote:
> >
> > > > > So I guess there's something awry with the USB
> controller driver?
> > > > >
> > > >
> > > > Is there any other info that someone wants to track
> this down? Or has
> > > > someone got a fix?
> >
> > It's hard to come up with a fix without knowing what's
> wrong. The current
> > development version of that subroutine is essentially the
> same as the
> > version in 2.6.17.
> >
> > If you want to pin down the problem more precisely, try
> adding a whole
> > bunch of printk() statements to the
> quirk_usb_handoff_ohci() function in
> > drivers/usb/host/pci-quirks.c.
> >
>
> Andy, please add the below, work out what line it gets stuck
> at and then
> let us know? Thanks.
Well I did that and the kernel got a lot further! It ran through the
pci_init stuff without a hitch and then hung just after this line was
output:
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver
(PCI)
So I littered drivers/usb/host/ohci-pci.c with similar debugging and the
last line it printed was from (marked with --->):
static int __init ohci_hcd_pci_init (void)
{
int ret;
printk (KERN_DEBUG "%s: " DRIVER_INFO " (PCI)\n", hcd_name);
if (usb_disabled())
return -ENODEV;
D();
pr_debug ("%s: block sizes: ed %Zd td %Zd\n", hcd_name,
sizeof (struct ed), sizeof (struct td));
---> D();
ret = pci_register_driver (&ohci_pci_driver);
D();
return ret;
}
IE it never returned from pci_register_driver.
A bit more sprinkling of debugging showed it got to drivers/base/bus.c
(bus_add_driver()):
D();
driver_attach(drv);
D();
It never returned from driver_attach().
More debugging in drivers/base/dd.c showed the last output to be (marked
with --->):
static int __driver_attach(struct device * dev, void * data)
{
struct device_driver * drv = data;
/*
* Lock device and try to bind to it. We drop the error
* here and always return 0, because we need to keep trying
* to bind to devices and some drivers will return an error
* simply if it didn't support the device.
*
* driver_probe_device() will spit a warning if there
* is an error.
*/
---> D();
if (dev->parent) /* Needed for USB */
down(&dev->parent->sem);
D();
IE it never returned from down.
So why did putting in the initial lot of debug alter where the kernel
hung? And what's next?
NB a reminder: 2.6.16 boots up fine on this machine.
--
Andy, BlueArc Engineering
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
