Most recent kernel where this bug did *NOT* occur: pre 2.6.21 mm
kernels, non-mm 2.6.22-rc2
Distribution: Fedora Devel
Hardware Environment: EHCI input on external powered hub with CK804 mainboard
Software Environment: Nothing specific
Problem Description:
After a few hours of activity 2.6.22-rc1-mm1 and 2.6.22-rc2-mm1 will lose USB
HID INPUT (keyboard or mice with no priority), then the system will freeze
If the mouse/tackball is lost first switching to the console and moving the ball
will output random text. Restarting gpm will rescue the mouse (but the system
will lock up soon after anyway)
Same system with similar config works fine with mainline or older mm kernels
Last trace capture in logs before lockup:
Kernel:
drivers/hid/usbhid/hid-core.c: input irq status -75 received
Xorg:
ProcXCloseDevice to close or not ?
ProcXCloseDevice to close or not ?
(II) nek4k-enhanced-usb-0000:00:02.1-8.1/input1: Off
(II) track-expl-usb-0000:00:02.1-8.3/input0: Off
Steps to reproduce:
Just run the system for some time
More info there (logs, configs, etc)
http://bugzilla.kernel.org/show_bug.cgi?id=8535
--
Nicolas Mailhot
On Thu, 24 May 2007, Nicolas Mailhot wrote:
> Most recent kernel where this bug did *NOT* occur: pre 2.6.21 mm
> kernels, non-mm 2.6.22-rc2
> Distribution: Fedora Devel
> Hardware Environment: EHCI input on external powered hub with CK804 mainboard
> Software Environment: Nothing specific
> Problem Description:
> After a few hours of activity 2.6.22-rc1-mm1 and 2.6.22-rc2-mm1 will lose USB
> HID INPUT (keyboard or mice with no priority), then the system will freeze
> drivers/hid/usbhid/hid-core.c: input irq status -75 received
This is now handled in bugzilla [1]. Zan Lynx also reported this problem,
and from the HID_DEBUG output he provided is evident that it is caused by
HID layer receiving a report of size 4294967284 (which corresponds to
urb->actual_length of the URB received from USB core).
Alan Stern suggested to reproduce the bug with CONFIG_USB_DEBUG and also
collect the usbmon trace, so that we can clearly understand what happens.
I am now inclined to think that this is caused by USB core messing up the
URB somehow, HID core seems to receive the URB with already bogus values.
[1] http://bugzilla.kernel.org/show_bug.cgi?id=8535
Thanks,
--
Jiri Kosina
On Fri, 25 May 2007, Jiri Kosina wrote:
> This is now handled in bugzilla [1]. Zan Lynx also reported this problem,
> and from the HID_DEBUG output he provided is evident that it is caused by
> HID layer receiving a report of size 4294967284 (which corresponds to
> urb->actual_length of the URB received from USB core).
For completness, this is a snippet of HID_DEBUG output that Zan sent me in
a private mail, which demonstrates the urb->actual_length badness:
...
drivers/hid/hid-core.c: report (size 3) (unnumbered)
drivers/hid/hid-core.c: report 0 (size 3) = 00 00 00
hid-debug: input Keyboard.00e0 = 0
hid-debug: input Keyboard.00e1 = 0
hid-debug: input Keyboard.00e2 = 0
hid-debug: input Keyboard.00e3 = 0
hid-debug: input Keyboard.00e4 = 0
hid-debug: input Keyboard.00e5 = 0
hid-debug: input Keyboard.00e6 = 0
hid-debug: input Keyboard.00e7 = 0
drivers/hid/hid-core.c: report (size 4294967284) (unnumbered)
drivers/hid/hid-core.c: report 0 (size 4294967284) =
hid-debug: input Keyboard.00e0 = 0
hid-debug: input Keyboard.00e1 = 0
hid-debug: input Keyboard.00e2 = 0
hid-debug: input Keyboard.00e3 = 0
hid-debug: input Keyboard.00e4 = 0
hid-debug: input Keyboard.00e5 = 0
hid-debug: input Keyboard.00e6 = 0
hid-debug: input Keyboard.00e7 = 0
drivers/hid/hid-core.c: report (size 6) (numbered)
drivers/hid/hid-core.c: report 2 (size 5) = 00 00 00 00 00
hid-debug: input Button.0001 = 0
hid-debug: input Button.0002 = 0
hid-debug: input Button.0003 = 0
hid-debug: input Button.0004 = 0
hid-debug: input Button.0005 = 0
hid-debug: input Button.0006 = 0
hid-debug: input Button.0007 = 0
hid-debug: input Button.0008 = 0
hid-debug: input GenericDesktop.X = 0
hid-debug: input GenericDesktop.Y = 0
hid-debug: input GenericDesktop.Wheel = 0
Hangcheck: hangcheck value past margin!
drivers/hid/usbhid/hid-core.c: input irq status -75 received
...
--
Jiri Kosina