Description of problem: khubd suddenly starts to consume 100% CPU time, and /var/log/messages is floated with error messages. It starts with this message: Oct 3 14:29:34 monique kernel: hub 5-8:1.0: activate --> -110 Which is continued by this message: Oct 3 14:29:35 monique kernel: hub 5-8:1.0: activate --> -108 Oct 3 14:29:35 monique kernel: hub 5-8:1.0: hub_port_status failed (err = -108) The last two lines are repeated some HUNDRED times per SECOND. After 20 minutes, the /var/log/message grew 60 MByte large. Killing khubd showed no effect (even signal 9 did not impress the process). Shutting down the system seems to be impossible, too. Those "hub_port_status" messages are shown on the text terminal. After a few minutes waiting for the system to shut down, I finally pressed the reset button. Version-Release number of selected component (if applicable): kernel-2.6.22.9-91.fc7 Note: This is the first 2.6.22 kernel I could test due to bug 249652. This bug did not occur with the 2.6.21-1.3228 kernel. How reproducible: Sometimes. The system may work for hours or even days before showing this effect. Steps to Reproduce: None found yet. Just wait for it to happpen. Actual results: khubd consumes 100% CPU. /var/log/messages is floated with error messages. Reboot/hardware reset is required. Expected results: Everything works normally. Additional info: lsusb: Bus 005 Device 005: ID 050d:0234 Belkin Components F5U234 USB 2.0 4-Port Hub Bus 005 Device 001: ID 0000:0000 Bus 002 Device 002: ID 046d:c311 Logitech, Inc. (Internet Pro Keyboard) Bus 002 Device 001: ID 0000:0000 Bus 004 Device 004: ID 04a9:220d Canon, Inc. CanoScan N670U/N676U/LiDE 20 Bus 004 Device 001: ID 0000:0000 Bus 001 Device 003: ID 046d:c50e Logitech, Inc. MX-1000 Cordless Mouse Receiver Bus 001 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 I did not connect or disconnect any USB devices when the bug started. Also see bug 246713, which may be related to this bug. I have booted kernel 2.6.22.9-91 with the usbcore.autosuspend=0 option.
(In reply to comment #0) > Also see bug 246713, which may be related to this bug. I have booted kernel > 2.6.22.9-91 with the usbcore.autosuspend=0 option. Zero means suspend with no delay. To disable, use usbcore.autosuspend=-1
Thanks! The system is now running stable since I used usbcore.autosuspend=-1. Is -1 the default value? (I.e. do I need to put this boot option into grub.conf, anyways?)
(In reply to comment #2) > Thanks! The system is now running stable since I used usbcore.autosuspend=-1. > > Is -1 the default value? (I.e. do I need to put this boot option into grub.conf, > anyways?) -1 is not the default.
Would it be possible to try Rawhide kernel? I want to know if the new "hub-only" autosuspend in it works ok. The kernel can be found in http://download.fedora.redhat.com/pub/fedora/linux/development/x86_64/os/Packages/ (or i386/ if you have a 32-bit system). Keep in mind though, it would prevent normal updates with yum from taking place, because it's "newer" than fc7. So just do rpm -i, test, rpm -e.
I misspoke in comment #3: usbcore.autosuspend=-1 is the default in Fedora 7. So this problem was caused by setting autosuspend to 0 (which we should just reject anyway, it makes no sense to set it to that.)
(In reply to comment #4) Pete, I have tried kernel-2.6.23-0.224.rc9.git6.fc8 (i686) from Rawhide, without the autosuspend option being set. After about 30 hours of uptime, the error appeared again. First: Oct 12 05:55:43 monique kernel: hub 5-8:1.0: activate --> -110 Oct 12 05:55:43 monique kernel: hub 5-8:1.0: hub_port_status failed (err = -108) Oct 12 05:55:43 monique last message repeated 3 times Then repeatedly until reboot (about every two seconds): Oct 12 05:55:46 monique kernel: hub 5-8:1.0: activate --> -108 Oct 12 05:55:46 monique kernel: hub 5-8:1.0: hub_port_status failed (err = -108) Oct 12 05:55:46 monique last message repeated 3 times This weekend I will test the latest F7 production kernel without the autosuspend option. According to Chuck in comment #5, it should work as reliable as with autosuspend=-1.
kernel-2.6.22.9-91.fc7 is also working stable without autosuspend option. Which means that the bug occured because I was messing with the kernel options. I am sorry for the noise.
The bug reoccured today with kernel 2.6.23.1-10.fc7 without autosuspend option. It happened again after about 30 hours uptime. Nov 10 04:17:47 monique kernel: hub 5-8:1.0: activate --> -110 Nov 10 04:17:47 monique kernel: hub 5-8:1.0: hub_port_status failed (err = -108) Nov 10 04:17:47 monique last message repeated 3 times Then every two seconds: Nov 10 04:17:50 monique kernel: hub 5-8:1.0: activate --> -108 Nov 10 04:17:50 monique kernel: hub 5-8:1.0: hub_port_status failed (err = -108) Nov 10 04:17:50 monique last message repeated 3 times What is the reason for this error? And is there a way to fix it for good?
Unfortunately the Fedora 8 autosuspend changes leaked into the Fedora 7 kernel. This controls autosuspend by device classes, and apparently doesn't work. Looks like it should go back to being disabled completely by default.
Hello, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the Fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug and will try and assist you in resolving it if I can. There hasn't been much activity on this bug for a while. Could you tell me if you are still having problems with the latest kernel? If the problem no longer exists then please close this bug or I'll do so in a few days if there is no additional information lodged.
Closing as per previous comment. Please re-open if this is still an issue for you.