uhci_hcd generates flood of kernel messages while failing to mount usb stick

[Fabian Mueller]

When connecting my usb stick to the computer, it is not automatically discovered anymore. Even 'lsusb -v' does not show anything beside the usb hub.

Instead, 'cat /proc/kmsg' produces messages like

[17180190.832000] usb 1-2: new full speed USB device using uhci_hcd and address 5
[17180191.336000] usb 1-2: new full speed USB device using uhci_hcd and address 6
[17180191.840000] usb 1-2: new full speed USB device using uhci_hcd and address 7
[17180192.344000] usb 1-2: new full speed USB device using uhci_hcd and address 8
[17180192.848000] usb 1-2: new full speed USB device using uhci_hcd and address 9

and so on, about two messages per second. The address numbers go up till 127 and then start again at 0.

The problem is obviously related to uhci_hcd.ko, since removing it stops the messages (and reloading it starts them again).

I have this bug for 2 days now, the last time I used the stick was about two weeks ago, when everything was functioning properly. I had already migrated to dapper then, so it must be some issue with the last two weeks' updates.

I have been able to resolve the problem once by inserting and removing various modules like sd_mod, ehci_hcd, uhci_hcd, usb_storage, but I haven't been able to reproduce it :-/

Loading sd_mod, by the way, gives the following error message:

Driver 'sd' needs updating - please use bus_type methods

but it loads nonetheless.

Any help would be appreciated!

[Fabian Mueller (fabmue)]

This is the output of dmesg showing the message flood after loading uhci_hcd.ko and plugging in the usb stick.

[Johnathon (kirrus)]

Hi, thanks for reporting this bug, sorry its taken so long for someone to triage it (we have a large backlog at the moment)

Is this bug still a problem?

[Fabian Mueller (fabmue)]

hi,

that's ok, nice to see someone noticed at all :-)

i had found a workaround some time in the past, but i haven't been using
the usb stick for some time. i just tried it out again, and the bug is
still there.

i'm running feisty by now, so i should probably give you some new
diagnostic output. i'll create an attachment to the bug in a few days
(right now i'm a bit busy, sorry).

thanks in advance,

fabian

Johnathon wrote:
> Hi, thanks for reporting this bug, sorry its taken so long for someone
> to triage it (we have a large backlog at the moment)
>
> Is this bug still a problem?
>

[Fabian Mueller (fabmue)]

hi,

as promised, here is the output of dmesg on my currently running system...

[Fabian Mueller (fabmue)]

...and the lsmod output.

As I said before, I'm now running Ubuntu 7.04 Feisty with kernel 2.6.20 and the problem remains. Should I move the bug to linux-source-2.6.20 or create a bug report there with a link to this one?

If you need any other information for diagnostics, don't hesitate to ask.

[Johnathon (kirrus)]

Hi. For the moment, move the bug, the Kernel guys can create another one if they need to later. We've noted here that the problem exists in both.
Right, can you try running the following command, and see if it solves the issue for you?
"sudo rmmod ehci_hcd"

Regards, Johnathon

[Fabian Mueller (fabmue)]

Hi Johnathon,

removing the ehci_hcd module doesn't do anything (it wasn't loaded at the time, as shown in the lsmod output). I've tried to load and remove it again, which doesn't change anything. The sole troublemaker seems to be the uhci_hcd module.

I remember having read something about the kernel being a bit picky regarding the order in which usb modules are loaded. My /etc/modules lists "usb-storage", then "sd_mod", but neither is there a /dev/sd* device, nor does "sudo lsusb -v" show anything beside the hub after the modules are loaded and the stick is plugged in.

Hope this helps,

Fabian

[Johnathon (kirrus)]

Ok, can you post the information requested from here: https://wiki.ubuntu.com/DebuggingRemovableDevices whilst your usb stick is plugged in?

Thanks,

[Fabian Mueller (fabmue)]

Hi,

I've done everything and bundled it up in the attached tar file. There is no devices.txt since there are no /dev/sd* devices even when the stick is plugged in. hald doesn't say anything after the usual startup mess, i.e. everything in hal.log is from _before_ attaching the stick. Same with gvm.log.

As for the other requested information:

$ id
uid=1000(fabian) gid=1000(fabian) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),104(lpadmin),105(scanner),1000(fabian)
$ id hal
id: hal: No such user
$ id haldaemon
uid=117(haldaemon) gid=117(haldaemon) groups=117(haldaemon),24(cdrom),25(floppy),46(plugdev),124(powerdev)
$ uname -a
Linux cat 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

Regards,

Fabian

[Johnathon (kirrus)]

Hi,

Have you still got the problems in the latest kernel release?

Sorry Its taken me so long to look back at this one...

[Fabian Mueller (fabmue)]

Hi,

with kernel 2.6.20-16-generic, the stick is working when plugged in for the first time, although only after several scanning attempts:

[ 218.415370] usb 1-2: new full speed USB device using uhci_hcd and address 6
[ 218.919140] usb 1-2: new full speed USB device using uhci_hcd and address 7
[ 219.422917] usb 1-2: new full speed USB device using uhci_hcd and address 8
[ 219.926681] usb 1-2: new full speed USB device using uhci_hcd and address 9
[ 220.430440] usb 1-2: new full speed USB device using uhci_hcd and address 10
[ ... ]
[ 240.581172] usb 1-2: new full speed USB device using uhci_hcd and address 50
[ 241.100955] usb 1-2: new full speed USB device using uhci_hcd and address 51
[ 241.620684] usb 1-2: new full speed USB device using uhci_hcd and address 52
[ 242.112457] usb 1-2: new full speed USB device using uhci_hcd and address 53
[ 242.288250] usb 1-2: configuration #1 chosen from 1 choice
[ 242.291381] scsi1 : SCSI emulation for USB Mass Storage devices
[ 242.291785] usb-storage: device found at 53
[ 242.291794] usb-storage: waiting for device to settle before scanning
[ 247.291939] usb-storage: device scan complete
[ 247.295940] scsi 1:0:0:0: Direct-Access Hama FlashPen 6.16 PQ: 0 ANSI: 0 CCS
[ 247.304853] SCSI device sda: 2004991 512-byte hdwr sectors (1027 MB)
[ 247.308439] sda: Write Protect is off
[ 247.308461] sda: Mode Sense: 45 00 00 08
[ 247.308469] sda: assuming drive cache: write through
[ 247.317819] SCSI device sda: 2004991 512-byte hdwr sectors (1027 MB)
[ 247.320819] sda: Write Protect is off
[ 247.320837] sda: Mode Sense: 45 00 00 08
[ 247.320849] sda: assuming drive cache: write through
[ 247.320869] sda: sda1
[ 247.329966] sd 1:0:0:0: Attached scsi removable disk sda
[ 247.330149] sd 1:0:0:0: Attached scsi generic sg1 type 0

On subsequent tries, however, the problem is the same as before, i. e. a flood of messages of the type above, going on indefinitely.

Might it be some kind of timing problem, like the uhci_hcd driver polling the device, but not waiting long enough for an answer?

Regards, Fabian

[Johnathon (kirrus)]

Ok, I believe that there is enough information here now... Assigning to team and confirming.

Is moving it through now the right action? (request to kernel team bug handler)

[Brian Murray (brian-murray)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug does not meet the criteria for a stable release update and is being marked as Won't Fix for this particular version of the kernel. You can learn more about the stable release update process at https://wiki.ubuntu.com/StableReleaseUpdates .
However, the issue that you reported is one that should be possible to test with the live environment of the Desktop CD of the development release - Gutsy Gibbon. It would help us greatly if you could test with it so we can work on getting it fixed in the actively developed kernel. You can find out more about the development release at http://www.ubuntu.com/testing/ .
If you do decide to test with the development release of Ubuntu please comment on this bug report and include at least the minimal information requested at http://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks again and we appreciate your help.