RE: [linux-usb-devel] 2.6.17 hangs during boot on ASUS M2NPV-VM motherboard

On Fri, 14 Jul 2006 14:50:16 -0400 (EDT)
Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:

On Fri, 14 Jul 2006, Andrew Morton wrote:

On Fri, 14 Jul 2006 16:54:25 +0100
"Andy Chittenden" <AChittenden@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages