> > 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.
Any progress?
--
Andy, BlueArc Engineering
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
