From: Volker Armin Hemmann [mailto:[email protected]] 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

