Boot hangs at usb.rc with usb device plugged in

[Julien Olivier]

If I boot with my Creative NX Ultra webcam (driver here ->
http://mxhaard.free.fr) plugged in, the system hangs at boot, when running
usb.rc. If I boot without the webcam plugged in, I have no problem.

More over, if I plug the webcam after the system is already up, it works perfectly.

[Matt Zimmerman (mdz)]

Have you installed that driver, or does it hang on a clean system with no
third-party drivers?

[Julien Olivier (julo)]

I have installed the driver. And I *think* it booted correctly before I install
the driver. Would it help if I un-installed the driver and tried to boot ?

[Matt Zimmerman (mdz)]

Yes, please do try booting without the driver. It should be sufficient to
simply delete the file from the /lib/modules directory.

[Julien Olivier (julo)]

I'm a bit confused now because I removed the driver (by rename the spca module)
and it worked fine: I could boot. The problem is that after I renamed the driver
back to its original name, it booted flawlessly too...

After a few tries, I can't reproduce the bug anymore.

That said, I've preformed a dist-upgrade just before doing those tests, but I
didn't really pay attention to the updated packages. I only noticed there was
hal, gnome-volume-manager and dbus something...

Maybe the best is to close the bug for now, and I'll re-open it later if I can
re-produce it.

What do you think ?

[Matt Zimmerman (mdz)]

Agreed, closing for now. If you encounter the problem again, check whether it
happens only when that driver is loaded, and if so, report a bug to the driver
maintainer (we don't support this driver)

[Julien Olivier (julo)]

After some testing, I could reproduce the bug without the webcam plugged.

The following elements are plugged:
 - Mobi-disk external "desktop" hard-drive
 - Trust 4-port hub with
    - Logitech mouse
    - USB to serial converter
    - Microsoft Sidewinder joypad
    - Sometimes a Creative NX Ultra webcam

As I said, I know the webcam isn't the reason of the hang as it happened even
with it un-plugged.
All the other elements use native drivers.

Finally, it's important to note that the hang on boot seems to happen quite
randomly: it occurs about once in 5 boots, and never happens twice in a row. So,
when it happens, I just shutdown my laptop and restart (without removing any USB
device). And the second time it works fine.

Are any of my devices known to cause problems on startup ?

[Matt Zimmerman (mdz)]

Please try to be absolutely sure that the hang is occurring with a stock Ubuntu
kernel with no third-party drivers loaded. If necessary, remove the
/lib/modules/`uname -r` directory out of the way and reinstall the kernel package.

Please send the complete output from the following commands:

dmesg
lspci

[Herbert Xu (herbert-gondor)]

(In reply to comment #6)
> After some testing, I could reproduce the bug without the webcam plugged.

When it hangs does pressing CTRL-SCROLLLOCK display anything?

[Julien Olivier (julo)]

(In reply to comment #8)

No, pressing CTRL-SCROLLLOCK doesn't do anything

[Julien Olivier (julo)]

Created an attachment (id=377)
dmesg

[Julien Olivier (julo)]

Created an attachment (id=378)
lspci

[Julien Olivier (julo)]

I managed to make it hang again, without the webcam plugged.

But this time I unplugged/replugeed the USB hub (which had the mouse, the serial
converter and the joypad plugged on) and it made it go on booting.

[Julien Olivier (julo)]

The only custom driver I have on my kernel is the ndiswrapper one for my
internal wifi card (an ipw2200). Should I remove it too ?

[Herbert Xu (herbert-gondor)]

(In reply to comment #13)
> The only custom driver I have on my kernel is the ndiswrapper one for my
> internal wifi card (an ipw2200). Should I remove it too ?

Most certainly. We can't support ndis drivers. In fact ipw2200 is included
with the Ubuntu kernels anyway so there is no need to use ndiswrapper. However,
ipw2200 is known to be unstable so please exclude it when we're looking at other
problems.

[Matt Zimmerman (mdz)]

*** Bug 8979 has been marked as a duplicate of this bug. ***

[Matt Zimmerman (mdz)]

We are seeing many reports of this issue on the mailing list recently; I'm not
sure whether it's actually become more common or not, but I'm increasing its
severity accordingly.

Herbert, what other information can we collect from users who are experiencing
the problem?

[Julien Olivier (julo)]

I removed ndiswrapper and my network still works thanks to the ipw2200 driver (I
assumed it wasn't included in Ubuntu since the installer didn't detect my wifi
network).

Now, I can't reproduce the bug anymore. But it seems to happen rather randomly,
so I'm not 100% sure it's solved yet.

[Herbert Xu (herbert-gondor)]

(In reply to comment #16)
> We are seeing many reports of this issue on the mailing list recently; I'm not
> sure whether it's actually become more common or not, but I'm increasing its
> severity accordingly.

Well I'm not certain whether all these hangs are necessarily related.

> Herbert, what other information can we collect from users who are experiencing
> the problem?

For a start, I'd like to find out whether it is a complete hang. Since we now
have SYSRQ please see if that works and if you can generate a back-trace to find
out where it is hanging.

[Mark Smith (ubuntu-marksmith)]

SYSRQ works, and a couple of ALT-SYSRQ-I commands to quit the process will allow
booting to continue. As to a backtrace from there, if anyone can give me some
pointers or a howto I'll happily do some experiments since I can reproduce the
problem at will.

[Daniel Stone (daniels)]

FWIW, the only time I hit this was running a hand-rolled 2.6.9-rc1-mm5 on my
desktop (Via KT400 chipset); when my media reader (one of the CF/SD/MS thingies)
was plugged in, any attempt to do anything with USB (from hotplug right down to
cat /proc/usb/devices [or whatever]) would just send whatever was dealing with
it into D. Always worked for me with all the Ubuntu kernels (you could read
media from it, it errored out straight away if there was no media, booted fine,
etc).

[Matt Zimmerman (mdz)]

(In reply to comment #19)
> SYSRQ works, and a couple of ALT-SYSRQ-I commands to quit the process will allow
> booting to continue. As to a backtrace from there, if anyone can give me some
> pointers or a howto I'll happily do some experiments since I can reproduce the
> problem at will.

sysrq+t will dump stack traces, and if the system is still functional enough,
they should be written to kern.log as well. If you could collect those and
attach them to the bug, I think that would be a help.

[Manuel Teira (manuel-teira)]

I'm suffering the same problem (usb.rc hanging) on my AMD 756 (Viper) based box.
I've read some (perhaps) related information here:

http://seclists.org/lists/linux-kernel/2004/Oct/0432.html

My problem arised while booting up with an HP 2100C scanner plugged in. When I
start with the scanner not plugged the boot process goes fine. I'm able to
switch on the scanner and, after this, I'm able to

cat /proc/bus/usb/devices

some times. But after a random lapse of time, it locks. This 'cat' process is in
D state. The same state is shared by the hald daemon, and a lot of applications
stop working, claiming that hald is not running.

I've tested it on this machine with the 2.6.8.1-3-k7 kernel and also with the
2.6.8.1-2-386 one, getting the same results. I've tested this scanner on another
machine (Intel Corp. 82371AB/EB/MB PIIX4 USB based) running ubuntu, and it works
perfectly.

I could provide more info about this, if you want.

Regards.

[Herbert Xu (herbert-gondor)]

(In reply to comment #22)
> I could provide more info about this, if you want.

Thanks. Please perform the tests referred to in comment #18.

[Manuel Teira (manuel-teira)]

Created an attachment (id=542)
Stack trace while usb.rc is hanging

This is the kern.log file when the usb.rc is hanging. After that, I pressed
Alt-SysRQ-T to show the stack traces and then, Alt-SysRq-I to kill the hanging
process.

Hope this helps.

[Manuel Teira (manuel-teira)]

The problem seems to be related with the error:
'usb 1-1: control timeout on ep0in'
After this, normally hald goes into 'D' state and never comes back. The usb
subsystem doesn't work either.

I've been experimenting with the options:
acpi=off
  In this way, hald seems not to hung, even plugging in the USB scanner. But
usb.rc hungs on boot if the scanner is plugged in.
acpi=off nolapic
  In this way, usb.rc didn't hung (with the USB scanner plugged in on boot), but
after complete boot, cat /proc/bus/usb/interfaces hungs and so does hald. Also,
plugging in the scanner after boot has the same effect.

acpi=off nolapic pci=noacpi
  The same results as in the previous test.

So, I'm not able to make this ubuntu work. Once an usb device is switched on,
and the kernel dumps:
'usb 1-1: control timeout on ep0in'
the system locks.

[Manuel Teira (manuel-teira)]

The problem seems to be related with the error:
'usb 1-1: control timeout on ep0in'
After this, normally hald goes into 'D' state and never comes back. The usb
subsystem doesn't work either.

I've been experimenting with the options:
acpi=off
  In this way, hald seems not to hung, even plugging in the USB scanner. But
usb.rc hungs on boot if the scanner is plugged in. hald didn't go to 'D' state,
but looking to a ps output, I see that [khubd] is in 'D' state.
acpi=off nolapic
  In this way, usb.rc didn't hung (with the USB scanner plugged in on boot), but
after complete boot, cat /proc/bus/usb/interfaces hungs and so does hald. Also,
plugging in the scanner after boot has the same effect.

acpi=off nolapic pci=noacpi
  The same results as in the previous test.

So, I'm not able to make this ubuntu work. Once an usb device is switched on,
and the kernel dumps:
'usb 1-1: control timeout on ep0in'
the system locks.

[Herbert Xu (herbert-gondor)]

Manuel, your problem sounds like an IRQ issue. Could you please open up a new
bug report as this may be a different issue to what the others are seeing?

In that new report please attach a complete strace when you boot up with no USB
devices attached. Please also include the contents of /proc/interrupts.

[Manuel Teira (manuel-teira)]

When you say an 'strace' you mean a kernel stack trace ?

[Herbert Xu (herbert-gondor)]

Sorry, I meant the dmesg. But please open up a new bug report, this one is
starting to get crowded.

[George Dekavalas (george-deka)]

I am also experiancing the same issue.
What information do you need and how do i get it.

[Mark Smith (ubuntu-marksmith)]

Apologies for the delay ...
I was unable to get any sort of traces from kern.log after the SysRq magic on Warty.
However - the problem has been resolved for me in Hoary.

[Matt Zimmerman (mdz)]

The only relevant change to the kernel in Hoary was the fix for #1814, so this
seems to be the same bug.

This bug has been marked as a duplicate of bug 8557.