From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050719 Red Hat/1.7.10-1.1.3.1 Description of problem: The rhel4 kernel will occasionally hang, while spewing drivers/usb/input/hid-core.c: input irq status -71 received drivers/usb/input/hid-core.c: input irq status -71 received drivers/usb/input/hid-core.c: input irq status -71 received drivers/usb/input/hid-core.c: input irq status -71 received on the console. This seems to be related to using a sun type 6 (usb) keyboard, or at least I haven't seen it happen when that keyboard isn't used. This worked well in rhel3 (and 2.1). The hardware is a dell PE 2850. I normally get a few lines like that upon reboot. Here's the last data that got out the serial console last reboot: Sending all processes the TERM signal... Sending all processes the KILL signal... Saving random seed: Syncing hardware clockPlease stand by while rebooting the system... md: stopping all md devices. md: md0 switched to read-only mode. drivers/usb/input/hid-core.c: input irq status -71 received megaraid: flushing adapter 0...<4>drivers/usb/input/hid-core.c: input irq status -71 received drivers/usb/input/hid-core.c: input irq status -71 received drivers/usb/input/hid-core.c: input irq status -71 received drivers/usb/input/hid-core.c: input irq status -71 received drivers/usb/input/hid-core.c����� < BIOS screen > (This is also with the keyboard attached.) I've attached the output of lspci -vvv. /August. Version-Release number of selected component (if applicable): kernel-smp-2.6.9-11.EL How reproducible: Sometimes Steps to Reproduce: 1. Plug the keyboard in 2. reboot (it might hang on reboot or boot. Or maybe during normal use, but I'm not sure I've seen that.) 3. Additional info:
Created attachment 117270 [details] lspci -vvv from the affected box.
Yeah, that's the difficulty with the -71s. The interrupt comes, now what do you do with it? A -71 is some sort of transient hardware failure, like a bad CRC on the packet. Unfortunately, things like missing tokens are included too, and so if the keyboard's firmware drops dead, all submissions will return -71s. The HID cannot decide if to retry (he retries all). Ideas about adding some sort of hockey timeout and error counter schemes float around periodically, but these schemes are never robust enough to be implemented universally without breaking some strange device. I suggest unplugging the keyboard and plugging back if this happens again. Let me know if it consistently fails to initialize, or if unplugging causes system instability.
So, the situation here is that we need to catch the last few packets to understand what actually happens. But I'm too swamped to figure that out. Naturally, usbmon would not work so close to reboot, when all normal processes are killed. And CONFIG_USB_DEBUG is hideously verbose...
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.