Created attachment 572481 [details]
Complete dmesg output from the affected system, from Fedora 17 Alpha.
Description of problem:
When booting Fedora 17 (or 15), one of my systems pauses for 10 seconds, after which the following message appears next in the dmesg output:
[ 13.221222] generic-usb 0003:0BDA:0152.0001: timeout initializing reports
Version-Release number of selected component (if applicable):
The newest kernel this appears in is version 3.3.0-1.fc17.i686.PAE
Happens every boot.
Steps to Reproduce:
1. Boot system with the 0BDA:0152 device (a memory card reader, I think)
A 10-second pause during the boot procedure
A boot procedure with no timeouts called out on typical devices thought to be functioning normally.
Does this happen with the 3.4 update ?
Hi, Dave. I'm using the 3.4.3-1.fc17.x86_64 kernel, and it still happens.
Here's a small excerpt from my dmesg output just now, covering the area of the delay:
[ 2.404109] device-mapper: uevent: version 1.0.3
[ 2.404244] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: firstname.lastname@example.org
[ 2.404344] cpuidle: using governor ladder
[ 2.404394] cpuidle: using governor menu
[ 2.404772] EFI Variables Facility v0.08 2004-May-17
[ 12.389267] generic-usb 0003:0BDA:0152.0001: timeout initializing reports
[ 12.389441] generic-usb 0003:0BDA:0152.0001: hiddev0,hidraw0: USB HID v1.11 Device [Generic USB2.0-CRW] on usb-0000:00:13.2-6/input1
[ 12.394377] input: Burr-Brown from TI USB Audio DAC as /devices/pci0000:00/0000:00:13.0/usb5/5-1/5-1:1.2/input/input2
[ 12.394559] generic-usb 0003:08BB:2704.0002: input,hidraw1: USB HID v1.00 Device [Burr-Brown from TI USB Audio DAC ] on usb-0000:00:13.0-1/input2
[ 12.397481] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:14.5/usb7/7-1/7-1:1.0/input/input3
[ 12.397695] generic-usb 0003:046D:C52F.0003: input,hidraw2: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-0000:00:14.5-1/input0
Still happening with kernel 3.4.4-3.fc17.x86_64.
Still happens with kernel 3.5.1-1.fc17.x86_64, although as of the previous kernel revision (3.5.0) it happens after the change to the smaller font, whereas it used to happen before that point.
Still occurs with kernel 3.6.9-2.fc17.x86_64.
Created attachment 701922 [details]
Output from "lsusb -v".
This is still happening with kernel 3.7.9-201.fc18.x86_64.
I've tried the trick suggested in RHBZ 907221. Not only does it skip the delay, the affected sub-system seems to be functioning well. I think the device in question is the multi-card reader. I tested this by inserting an SD card with a valid file system, and it seems to mount it and read from it successfully.
I've attached the output of "lsusb -v", as recommended in the other bugzilla report.
Hans, since you did so well with 907221, can you take a peek here?
(In reply to comment #8)
> Hans, since you did so well with 907221, can you take a peek here?
Actually I still need to write a proper fix for bug 907221 and send it upstream (this is on my to-do), and bug 907221 comment 8 already points to this bug, so I was already planning on fixing this one too while at it for bug 907221 (will be done as 2 separate patches of course).
Josh, if you've more time to work on this then me, you can probably easily write patches for this yourself, Stan (for this bug) and Steve (for bug 907221), have both already confirmed through the kenrel-cmdline options they tested that adding a HID_QUIRK_NO_INIT_REPORTS quirk for these devices fixes things.
So what is needed to add 2 entries for this to the hid_blacklist in:
Which is quite easy but before submitting 2 patches for this upstream I would like to do at least a test-compile. As said this is on my todo but so is a lot of other stuff, so if you can get around to writing 2 patches for this one of the coming days, that would be great!
Created attachment 710695 [details]
Patch to add quirk
Something like this look OK Hans?
(In reply to comment #10)
> Created attachment 710695 [details]
> Patch to add quirk
> Something like this look OK Hans?
Thanks! Yes this looks good.
Stan, here is a scratch build with that patch included. If you could please test it when it completes that would be appreciated:
(In reply to comment #12)
> Stan, here is a scratch build with that patch included. If you could please
> test it when it completes that would be appreciated:
Stan, when you test this make sure you remove the "usbhid.quirks=0x0bda:0x0152:0x20000000" you added to the kernel cmdline from the kernel cmdline, as the fixed kernel should figure that out itself :)
Kernel 3.8.3-102.1.fc17.x86_64 looks good. It doesn't print a confirmation that it self-detected the quirk, but it certainly doesn't incur the timeout any more.
After taking out the kernel cmdline quirk option, I retested with the current kernel 3.8.2-206.fc18.x86_64, and the timeout was still there, so definitely this test build is an improvement. The SD card reader still works (I think that is the affected hardware).
The change shaves about 9 seconds off the total start-up time, according to the systemd log messages. I'm sure there are some people out there besides me who will appreciate the faster boot time. Thanks again.
(In reply to comment #14)
> Kernel 3.8.3-102.1.fc17.x86_64 looks good. It doesn't print a confirmation
> that it self-detected the quirk
That is normal.
> but it certainly doesn't incur the timeout any more.
Added to the Fedora git repos.
kernel-3.8.5-201.fc18 has been submitted as an update for Fedora 18.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.8.5-201.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
then log in and leave karma (feedback).
kernel-3.8.5-201.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.