Bug 907221 - hid-generic timeout adds 10 seconds to boot time
Summary: hid-generic timeout adds 10 seconds to boot time
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 18
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Josh Boyer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-03 20:24 UTC by Steve P
Modified: 2013-04-03 04:23 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-03 04:23:26 UTC


Attachments (Terms of Use)
dmesg output. please see lines 853-855 (69.21 KB, text/plain)
2013-02-03 20:24 UTC, Steve P
no flags Details
lsusb.log (22.64 KB, text/x-log)
2013-02-04 16:48 UTC, Steve P
no flags Details
Patch to add quirk (1.13 KB, text/plain)
2013-03-15 14:34 UTC, Josh Boyer
no flags Details

Description Steve P 2013-02-03 20:24:27 UTC
Created attachment 692505 [details]
dmesg output. please see lines 853-855

Description of problem:
On an MSI 780DXR, the hid-generic driver encounters a timeout trying to initialize reports for the LED back-lit keyboard.  This adds about 10 seconds to the boot time.

dmesg excerpt:
[    2.901012] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[    2.980578] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: discard
[   11.981404] hid-generic 0003:1770:FF00.0004: timeout initializing reports
[   11.982126] hid-generic 0003:1770:FF00.0004: hiddev0,hidraw2: USB HID v1.10 Device [MSI EPF USB MSI EPF USB] on usb-0000:00:1d.0-1.7/input0

lsusb output:
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 002 Device 003: ID 0bda:0139 Realtek Semiconductor Corp. RTS5139 Card Reader Controller
Bus 002 Device 004: ID 1770:ff00  


Version-Release number of selected component (if applicable): 0.2.17-12.fc18


Steps to Reproduce:
1. Boot Fedora with the MSI SteelSeries LED keyboard attached
2. Examine dmesg to identify boot delay
  
Actual results:
About 10 seconds are added to the boot time.


Expected results:
No delay during boot.

Additional info:
It was suggested to add a quirk line to the driver and recompile.

Comment 1 Hans de Goede 2013-02-04 14:42:31 UTC
Hi,

This is not a libhid bug, but a kernel bug. Still I may be able to help :)

Can you please do:
lsusb -v > lsusb.log

And then attach the generated lsusb.log file, and you please also attach your full dmesg output?

Thanks,

Hans

Comment 2 Steve P 2013-02-04 16:48:10 UTC
Created attachment 692874 [details]
lsusb.log

Comment 3 Hans de Goede 2013-02-04 22:03:09 UTC
Hi,

(In reply to comment #2)
> Created attachment 692874 [details]
> lsusb.log

Hmm, funky device, ie:

    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None

Where as a normal keyboard has:

    Interface Descriptor:  
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0   
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      1 Keyboard

I was actually expecting something like your device has, but then on a *second* interface, some fancy keyboards present themselves as 2 hid devices 1 standard keyboard, and 1 device only usable through rawhid which gives access to the lcd, etc. And my plan was to then blacklist standard hid probing for the second interface ...

That won't work here though. I believe your best bet for getting this fixes is sending a mail to the linux-input list:
http://vger.kernel.org/vger-lists.html#linux-input

Regards,

Hans

Comment 4 Hans de Goede 2013-02-04 22:04:56 UTC
To be clear, as said I expected a rawhid only second interface, but your keyboard has only one interface, so everything needs to be done through that single interface, which means blacklisting it from (non raw) hid probing would be a bad idea.

Comment 5 Steve P 2013-02-05 01:33:24 UTC
As this is a laptop keyboard, I believe it has the standard keyboard interface in addition to this second usb interface to control the LEDs.  I am not sure how we can identify this, but I assume that if we disable probing the usb interface, the keyboard should still function.  Is there anyway I could test this on my own?

Comment 6 Hans de Goede 2013-02-05 08:28:43 UTC
(In reply to comment #5)
> As this is a laptop keyboard, I believe it has the standard keyboard
> interface in addition to this second usb interface to control the LEDs.  I
> am not sure how we can identify this, but I assume that if we disable
> probing the usb interface, the keyboard should still function.  Is there
> anyway I could test this on my own?

Ah, so your keyboard is using ps/2 for the keypresses, and usb with hid for the backlight funky setup,but we can work with that :)

So to tell the  usbhid driver to skip the reports initialization completely,  add the following to the kernel cmdline: usbhid.quirks=0x1770:0xff00:0x20000000

To add something to the kernel cmdline, edit /etc/grub2.cfg, find the entry for your currently running kernel (usually the first), and add it to the end of the "linux   /boot/vmlinuz-...." line, ie change:

linux   /boot/vmlinuz-3.7.4-204.fc18.x86_64 root=UUID=85b48b3e-e8ba-451b-800a-63609fcb77cb ro rd.md=0 rd.dm=0 rd.lvm=0 FONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYMAP=us quiet rhgb

To:

linux   /boot/vmlinuz-3.7.4-204.fc18.x86_64 root=UUID=85b48b3e-e8ba-451b-800a-63609fcb77cb ro rd.md=0 rd.dm=0 rd.lvm=0 FONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYMAP=us quiet rhgb usbhid.quirks=0x1770:0xff00:0x20000000

Note bugzilla will likely wrap the above examples, but they are a single line!

Then the 10 second timeout should be gone, and you should still see something like this:
[   11.982126] hid-generic 0003:1770:FF00.0004: hiddev0,hidraw2: USB HID v1.10 Device [MSI EPF USB MSI EPF USB] on usb-0000:00:1d.0-1.7/input0

At a minimum we want the hidraw driver to still get attached, so that later on a userspace utility for configuring the backlight of the keyboard can be written.

Comment 7 Steve P 2013-02-05 17:23:13 UTC
That worked perfectly! The system now boots without the 10 second delay.  Thank you!

Comment 8 Stan King 2013-02-24 07:54:23 UTC
For another data point on this problem, please take a look at RHBZ 806587.

In my case, it seems to be a multi-format card reader rather than a keyboard.  Nevertheless, the above trick seems to work.

Comment 9 Josh Boyer 2013-03-15 14:34:40 UTC
Created attachment 710694 [details]
Patch to add quirk

Something like this look OK Hans?

Comment 10 Hans de Goede 2013-03-15 15:51:11 UTC
(In reply to comment #9)
> Created attachment 710694 [details]
> Patch to add quirk
> 
> Something like this look OK Hans?

2 remarks:
1) About the commit message it is not the keyboard device it is the keyboard backlight led controller
2) I don't think using direct ids rather then defines will fly upstream, a quick google found me that someone already submitted a patch for this upstream, was asked to add his Signed-off-by, and never followed up :| But his patch does add defines, with what I believe are the proper names for the vendor / device. which I think we should do too:
http://www.spinics.net/lists/linux-usb/msg54756.html
(patch at the end of the very long mail).

With this fixed, it is probably best to submit both patches directly to Jiri Kosina  jkosina-suse-cz, with linux-input@vger.kernel.org in the CC.

Thanks for working on this!

Comment 11 Josh Boyer 2013-03-15 16:00:39 UTC
OK, I'll rework.  Thanks for finding that thread.

Comment 12 Josh Boyer 2013-03-15 16:19:34 UTC
Steve, if you could please test this scratch build after removing usbhid.quirks=0x1770:0xff00:0x20000000 from the command line, it would be greatly appreciated:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5127181

Comment 13 Hans de Goede 2013-03-24 15:56:27 UTC
(In reply to comment #12)
> Steve, if you could please test this scratch build after removing
> usbhid.quirks=0x1770:0xff00:0x20000000 from the command line, it would be
> greatly appreciated:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5127181

Steve, ping ?

Comment 14 Steve P 2013-03-24 21:43:58 UTC
I apologize for the delay in my response.  I do not know how to go about testing the build.  I thought there would be an .rpm to download or something along those lines.

Comment 15 Stan King 2013-03-24 22:16:22 UTC
Steve, I was able to find an RPM for the architecture I use (x86_64) under the "koji" link provided above.  I double-clicked on it, the firefox web browser activated "yumex", I provided the correct password, and everything worked fine after that.  I thought it would pull in some dependencies, but it apparently had all it needed within the RPM.  However, at the moment, it appears like the build has failed, so there's no usable RPM there right now.

Depending on how many test kernels you anticipate, you may want to bump the install-only limit in /etc/yum.conf.  I changed mine from 3 to 5, to postpone the day that this test kernel gets dropped from my available kernel choices.

Comment 16 Hans de Goede 2013-03-25 05:59:06 UTC
(In reply to comment #15)
> However, at the moment, it
> appears like the build has failed, so there's no usable RPM there right now.

Oh, you're right!

Josh, can you do a new build for this?

Comment 17 Josh Boyer 2013-03-25 12:12:38 UTC
(In reply to comment #16)
> (In reply to comment #15)
> > However, at the moment, it
> > appears like the build has failed, so there's no usable RPM there right now.
> 
> Oh, you're right!
> 
> Josh, can you do a new build for this?

Yeah, later today.  Typo in the patch.

Comment 18 Josh Boyer 2013-03-25 18:25:37 UTC
http://koji.fedoraproject.org/koji/taskinfo?taskID=5170528

That one should build now

Comment 19 Steve P 2013-03-26 00:33:54 UTC
The issue is resolved with the test build.  After removing usbhid.quirks=0x1770:0xff00:0x20000000 from the command line, the system booted without the usbhid delay.  Thank you.

Comment 20 Josh Boyer 2013-03-26 11:49:25 UTC
Thank you for testing.  Added to the Fedora kernel git branches.

Comment 21 Fedora Update System 2013-04-01 13:30:36 UTC
kernel-3.8.5-201.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/kernel-3.8.5-201.fc18

Comment 22 Fedora Update System 2013-04-01 22:34:07 UTC
Package kernel-3.8.5-201.fc18:
* 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:
https://admin.fedoraproject.org/updates/FEDORA-2013-4645/kernel-3.8.5-201.fc18
then log in and leave karma (feedback).

Comment 23 Fedora Update System 2013-04-03 04:23:28 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.