Bug 133751

Sep 27 00:20:22 edge kernel: drivers/usb/input/hid-core.c: can't 
resubmit intr, 0000:00:10.0-1.3/input1, status -19 
Sep 27 00:20:22 edge kernel: drivers/usb/input/hid-core.c: can't 
resubmit intr, 0000:00:10.0-1.3/input0, status -19 

This appears to be a kernel issue.

Issue reproducible on RHEL 4 Beta 2 (kernel-2.6.9-1.648_EL). No KVM 
involved here. Just disconnect USB Keyboard and the following message 
is displayed:
"drivers/usb/input/hid-core.c: can't resubmit intr, 0000:00:1d.2-
1.2/input0, status -19"

Currently regressing with latest kernel drop for RHEL 4.

Issue reproducible with the latest kernel drop of RHEL 4 (-906). 
Issue was initially reported while dis-connecting USB kerboard that 
has a USB mouse connected to it's internal hub. Trying to reproduce 
the issue with a plain USB keyboard and USB mouse.

The issue that I am reporting does not affect functionality though. 
Besides from the same kernel message that is displayed on the 
console, there is no loss of functionality here unlike the original 
report. Keyboard and Mouse both resume normal functionality when re-
plugged. Should I be opening a seperate issue to track my issue which 
maybe different from the originally reported issue ? Please advice.

Just installed FC3 (kernel 2.6.9-1.667) on x86_64 machine with a Happy
Hacking USB keyboard and Microsoft Notebook Optical mouse.  Mouse is
plugged into USB hub built-in to keyboard.  Periodically (usually at
night while I'm asleep), Something Bad happens and keyboard is no
longer usable.  Mouse works, but system is in weird state and cannot
shut down safely.  Have to power cycle to fix it.

These are the messages in the log:

Dec 23 01:46:26 ideq hal.hotplug[4962]: DEVPATH is not set
Dec 23 01:46:26 ideq hal.hotplug[4963]: DEVPATH is not set
Dec 23 01:46:26 ideq kernel: hub 3-0:1.0: port 3 disabled by hub
(EMI?), re-enabling...                                               
                         Dec 23 01:46:27 ideq kernel: usb 3-3: USB
disconnect, address 6
Dec 23 01:46:27 ideq kernel: usb 3-3.1: USB disconnect, address 7
Dec 23 01:46:27 ideq kernel: drivers/usb/input/hid-core.c: can't
resubmit intr, 0000:00:02.1-3.3/input0, status -19
Dec 23 01:46:27 ideq kernel: usb 3-3.3: USB disconnect, address 8
Dec 23 01:46:27 ideq kernel: usb 3-3: new full speed USB device using
address 9
Dec 23 01:46:27 ideq kernel: hub 3-3:1.0: USB hub found
Dec 23 01:46:27 ideq kernel: hub 3-3:1.0: 3 ports detected
Dec 23 01:46:28 ideq kernel: usb 3-3.1: new full speed USB device
using address 10
Dec 23 01:46:28 ideq hal.hotplug[5152]: DEVPATH is not set
Dec 23 01:46:28 ideq kernel: input: USB HID v1.00 Keyboard [Chicony 
PFU-65 USB Keyboard] on usb-0000:00:02.1-3.1
Dec 23 01:46:29 ideq kernel: usb 3-3.3: new low speed USB device using
address 11
Dec 23 01:46:29 ideq hal.hotplug[5234]: DEVPATH is not set
Dec 23 01:46:29 ideq kernel: input: USB HID v1.00 Mouse [Microsoft
Microsoft 3-Button Mouse with IntelliEye?] on usb-0000:00:02.1-3.3

Looks similar to this bug report, and the only thing that turned up on
a google search.

I'm now on kernel 2.6.10-1.760_FC3 and the problem with the lockup is
gone.  I think it went away with an earlier 2.6.10 packaging as well
as updating some of the usb/haldaemon/hotplug stuff...

Anyway, I don't know if this is related or not, but I still get (every
2 hours or so) these kinds of messages:

Feb  7 19:37:24 ideq kernel: hub 2-0:1.0: port 3 disabled by hub
(EMI?), re-enabling...
Feb  7 19:37:24 ideq kernel: usb 2-3: USB disconnect, address 47
Feb  7 19:37:24 ideq kernel: usb 2-3.1: USB disconnect, address 48
Feb  7 19:37:24 ideq hal.hotplug[15624]: DEVPATH is not set
Feb  7 19:37:24 ideq kernel: drivers/usb/input/hid-core.c: can't
resubmit intr, 0000:00:02.0-3.3/input0, status -19
Feb  7 19:37:24 ideq kernel: usb 2-3.3: USB disconnect, address 49
Feb  7 19:37:24 ideq hal.hotplug[15717]: DEVPATH is not set
Feb  7 19:37:24 ideq kernel: usb 2-3: new full speed USB device using
ohci_hcd and address 50
Feb  7 19:37:25 ideq kernel: hub 2-3:1.0: USB hub found
Feb  7 19:37:25 ideq kernel: hub 2-3:1.0: 3 ports detected
Feb  7 19:37:26 ideq kernel: usb 2-3.1: new full speed USB device
using ohci_hcd and address 51
Feb  7 19:37:26 ideq hal.hotplug[15829]: DEVPATH is not set
Feb  7 19:37:26 ideq kernel: input: USB HID v1.00 Keyboard [Chicony 
PFU-65 USB Keyboard] on usb-0000:00:02.0-3.1
Feb  7 19:37:27 ideq kernel: usb 2-3.3: new low speed USB device using
ohci_hcd and address 52
Feb  7 19:37:27 ideq kernel: input: USB HID v1.00 Mouse [Microsoft
Microsoft 3-Button Mouse with IntelliEye?] on usb-0000:00:02.0-3.3
Feb  7 19:37:27 ideq hal.hotplug[15911]: DEVPATH is not set

Any clues?

Still happens on kernel-2.6.10-1.766_FC3... help?

An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

The behavior is identical on 2.6.12-1.1372_FC3. 
 
Actually something I discovered after the additional bug report is that there 
is a way to restore keyboard & mouse without a reboot: by doing a complete 
back-forth cycle twice (rather than just once) it will reconnect.  So an odd 
number of disconnect/reconnect cycles produces a non-functional keyboard and 
mouse, whereas an even number restores functionality.  Here's what the 
messages log of a complete back, forth, back, forth looks like: 
 
Jul 21 14:36:52 edge hal.hotplug[4989]: DEVPATH is not set 
Jul 21 14:36:52 edge hal.hotplug[5038]: DEVPATH is not set 
Jul 21 14:36:52 edge kernel: usb 2-2: USB disconnect, address 2 
Jul 21 14:36:52 edge kernel: usb 2-2.1: USB disconnect, address 3 
Jul 21 14:36:52 edge kernel: usb 2-2.3: USB disconnect, address 4 
Jul 21 14:36:52 edge hal.hotplug[5079]: DEVPATH is not set 
Jul 21 14:37:53 edge kernel: usb 2-2: new full speed USB device using uhci_hcd 
and address 5 
Jul 21 14:37:53 edge kernel: hub 2-2:1.0: USB hub found 
Jul 21 14:37:53 edge kernel: hub 2-2:1.0: 3 ports detected 
Jul 21 14:37:53 edge kernel: usb 2-2.1: new low speed USB device using 
uhci_hcd and address 6 
Jul 21 14:37:54 edge hal.hotplug[5229]: DEVPATH is not set 
Jul 21 14:37:54 edge kernel: input: USB HID v1.10 Mouse [Logitech USB Mouse] 
on usb-0000:00:10.0-2.1 
Jul 21 14:37:54 edge kernel: usb 2-2.3: new full speed USB device using 
uhci_hcd and address 7 
Jul 21 14:37:54 edge hal.hotplug[5265]: DEVPATH is not set 
Jul 21 14:37:54 edge kernel: input: USB HID v1.10 Keyboard [Mitsumi Electric 
Apple Extended USB Keyboard] on usb-0000:00:10.0-2.3 
Jul 21 14:37:54 edge hal.hotplug[5318]: DEVPATH is not set 
Jul 21 14:37:54 edge kernel: input: USB HID v1.10 Device [Mitsumi Electric 
Apple Extended USB Keyboard] on usb-0000:00:10.0-2.3 
 

It gets more interesting. 
 
Today I had a second PC hooked up to the KVN temporarily for an install.  To 
my surprise, switching back and forth between the two works fine.  Apparently 
it's just switching to Mac OS X and back to Linux that doesn't work 50% of the 
time.  Very weird...I'm tempted to track down a non-Apple USB keyboard and see 
what happens trying to switch that, in case it's some really weird feature in 
the keyboard. 
 
Also, possible related: whenever I switch to the Fedora box I get some really 
serious CPU hogging (or something) such that the mouse pointer jumps around 
and if xmms is playing something the music skips really badly for 3 - 5 
seconds.  This was all the more noticeable because the other box (Gentoo) that 
I now have plugged in does not exhibit this behavior. 
 

Is the FC4 the same? The CPU hogging is probably the thundering of hotplug
processes on FC3, which we replaced with udev in FC4.

It's still the same on FC4 (kernel 2.6.12-1.1398_FC4).  I have since upgraded my
computer to be a dual core x86_64 so the CPU slowdown is much less noticeable,
but it's still there.  The mouse stutters for perhaps half a second now, as
opposed to a couple of seconds before.  I still have to switch back and forth
twice to get it to recognize the keyboard and mouse after switching to the G5. 
Here's the current dmesg for one switch (i.e. back and forth twice):

usb 2-1: USB disconnect, address 40
usb 2-1.1: USB disconnect, address 41
drivers/usb/input/hid-core.c: can't resubmit intr, 0000:00:02.0-1.3/input0,
status -19
drivers/usb/input/hid-core.c: can't resubmit intr, 0000:00:02.0-1.3/input1,
status -19
usb 2-1.3: USB disconnect, address 42
usb 1-1: new high speed USB device using ehci_hcd and address 25
usb 1-1: device not accepting address 25, error -71
ohci_hcd 0000:00:02.0: wakeup
usb 1-1: new high speed USB device using ehci_hcd and address 27
usb 1-1: device not accepting address 27, error -71
ohci_hcd 0000:00:02.0: wakeup
hub 1-0:1.0: connect-debounce failed, port 1 disabled
usb 2-1: new full speed USB device using ohci_hcd and address 43
hub 2-1:1.0: USB hub found
hub 2-1:1.0: 3 ports detected
usb 2-1.1: new low speed USB device using ohci_hcd and address 44
input: USB HID v1.10 Mouse [Logitech USB Mouse] on usb-0000:00:02.0-1.1
usb 2-1.3: new full speed USB device using ohci_hcd and address 45
input: USB HID v1.10 Keyboard [Mitsumi Electric Apple Extended USB Keyboard] on
usb-0000:00:02.0-1.3
input: USB HID v1.10 Device [Mitsumi Electric Apple Extended USB Keyboard] on
usb-0000:00:02.0-1.3

Thanks for testing. I see how it works now. The -19 is correct, it
happens because the disconnect method had no chance to run when
HID resubmits the interrupt URB. But upon reconnect, it's a -71.

It would be very helpful if you did the following:
 - get a Rawhide kernel. It's compatible. Current is 1.1616_FC5.
   You do not have to use it, just run it once. Keep the old one!
 - install kernel-doc, too
 - install it, and get a usbmon trace as in
/usr/share/doc/kernel-doc-2.6.13/Documentation/usb/usbmon.txt
 - Attach the file, do not drop it into comment box, please!

I cannot guarantee, unfortunately, what happens exactly. But I hope
that something like QUIRK_NOGET will fix it. Maybe all that happens
is that the keyboard has no time to reboot under certain conditions.

This is a mass-update to all currently open Fedora Core 3 kernel bugs.

Fedora Core 3 support has transitioned to the Fedora Legacy project.
Due to the limited resources of this project, typically only
updates for new security issues are released.

As this bug isn't security related, it has been migrated to a
Fedora Core 4 bug.  Please upgrade to this newer release, and
test if this bug is still present there.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

Thank you.

This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.

This happens to me with FC5t3 on x86_64  
 
kernel-2.6.15-1_1955_FC5 
 
 
  
   

[This comment added as part of a mass-update to all open FC4 kernel bugs]

FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel.  As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
to FC5.

Please retest with Fedora Core 5.

Thank you.

A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

(this is a mass-close to kernel bugs in NEEDINFO state)

As indicated previously there has been no update on the progress of this bug
therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue
still occurs for you and I will try to assist in its resolution. Thank you for
taking the time to report the initial bug.

If you believe that this bug was closed in error, please feel free to reopen
this bug.