> 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 ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel