Bug 316801 - khubd consumes 100% CPU and fills system log
khubd consumes 100% CPU and fills system log
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-03 09:25 EDT by Richard Körber
Modified: 2008-02-15 21:44 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-15 21:44:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Richard Körber 2007-10-03 09:25:21 EDT
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.
Comment 1 Chuck Ebbert 2007-10-03 19:45:32 EDT
(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

Comment 2 Richard Körber 2007-10-09 19:03:50 EDT
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?)
Comment 3 Chuck Ebbert 2007-10-09 19:06:42 EDT
(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.
Comment 4 Pete Zaitcev 2007-10-10 03:57:32 EDT
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.
Comment 5 Chuck Ebbert 2007-10-10 12:45:16 EDT
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.)
Comment 6 Richard Körber 2007-10-12 02:40:09 EDT
(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.
Comment 7 Richard Körber 2007-10-17 03:28:42 EDT
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.
Comment 8 Richard Körber 2007-11-10 04:53:42 EST
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?
Comment 9 Chuck Ebbert 2007-11-12 16:13:49 EST
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.
Comment 10 Christopher Brown 2008-01-14 13:18:30 EST
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.
Comment 11 Christopher Brown 2008-02-15 21:44:16 EST
Closing as per previous comment. Please re-open if this is still an issue for you.

Note You need to log in before you can comment on or make changes to this bug.