RE: [gentoo-user] Intermittent USB device failures

[Mike Edenfield]

From: Volker Armin Hemmann [mailto:volkerarmin@××××××××××.com]
Sent: Friday, August 15, 2014 7:53 PM
 
> Am 14.08.2014 um 03:52 schrieb Mike Edenfield:
> > I've recently taken an old Windows XP system and rebuilt it to run Gentoo.
Since 
> > then, I've been having issues using any type of USB input device (which is
> > particularly bad, since it has no PS/2 input ports).
> >
> > After some indeterminate period of time, the input device simply stops
responding.
> > Typically, I can use the console for a few days at a time before the
keyboard dies, 
> > but if I load up a GUI and start using the mouse it takes less than a few
hours. 
> > I'm fairly sure this problem is USB-related, since I believe I've
eliminated 
> > everything downstream of that: I've tried using both evdev and legacy mouse
and 
> > keyboard drivers in both the kernel and X and all of them work the same
way. evtest 
> > shows no activity from the device once it breaks, nor do the legacy /dev
driver files.
> >
> > Most notably, removing and re-plugging the device doesn't register as a
device 
> > attachment. If, for example, I take a working USB mouse and swap USB ports,
I get this:
> >
> > [ 1219.418050] usb 2-8: USB disconnect, device number 3
> > [ 1225.258011] usb 2-7: new low-speed USB device number 4 using ohci-> pci
> > [ 1225.449627] usb 2-7: New USB device found, idVendor=046d, idProduct=c044
> > [ 1225.449946] usb 2-7: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
> > [ 1225.450240] usb 2-7: Product: USB-PS/2 Optical Mouse
> > [ 1225.450740] usb 2-7: Manufacturer: Logitech
> > [ 1225.464165] input: Logitech USB-PS/2 Optical Mouse as
> > /devices/pci0000:00/0000:00:0b.0/usb2/2-7/2-7:1.0/input/input6
> > [ 1225.464666] hid-generic 0003:046D:C044.0003: input,hidraw1: USB HID
v1.10
> > Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:0b.0-7/input0
> >
> > If I do the same thing after the device has stopped functioning, I get the
> > disconnect message but that's it:
> >
> > [199729.451060] i2c i2c-3: sendbytes: NAK bailout.
> > [199733.215303] usb 2-7: USB disconnect, device number 4
> > [199814.495204] type=1006 audit(1394381639.494:3): pid=5861 uid=0 old
> > auid=4294967295 new auid=1000 old ses=4294967295 new ses=2 res=1
>
> you can use the power button + acpid to reload the usb modules (I hope
> you have usb support as modules and not built into the kernel) and see
> what happens next time usb acts up.

Thanks for the suggestion! Fortunately network access to the machine works fine
even with the USB down, so I was able to log in and unload/reload the USB
modules remotely.

When I `modprobe -r ochi_pci` while the system is operating normally, I see all
four modules (ohci-pci, ohci-hcd, ehci-pci, and ehci-hcd) unloading properly:

[25603.370000] ohci-pci 0000:00:0b.0: remove, state 1
[25603.370395] usb usb2: USB disconnect, device number 1
[25603.370414] usb 2-6: USB disconnect, device number 2
[25603.383451] usb 2-7: USB disconnect, device number 3
[25603.384217] ohci-pci 0000:00:0b.0: USB bus 2 deregistered
[25603.384597] ehci-pci 0000:00:0b.1: remove, state 1
[25603.384611] usb usb1: USB disconnect, device number 1
[25603.386306] ehci-pci 0000:00:0b.1: USB bus 1 deregistered

If I try to do the same thing after the mouse has locked up, modprobe stalls
trying to unload the first module:

wombat kutulu # modprobe -r -v ohci_pci
rmmod ohci_pci

wombat kutulu # dmesg
[38091.627389] ohci-pci 0000:00:0b.0: remove, state 1
[38091.627400] usb usb2: USB disconnect, device number 1

Any ideas what's going wrong here? Any chance I can salvage this hardware?

--Mike