Red Hat Bugzilla – Bug 212169
"hub 1-0:1.0: over-current change on port" messages.
Last modified: 2010-06-07 01:42:20 EDT
+++ This bug was initially created as a clone of Bug #124114 +++
Description of problem:
Customer is seeing messages of this sort:
Aug 25 16:31:10 fclassdb kernel: hub 4-0:1.0: over-current change on port 2
while using the RHEL-4 U4 kernel. Unloading both the ehci_hcd and uhci_hcd
modules caused the messages to stop printing; however, having either of the two
modules (or both) installed caused these messages. The hardware is an HP ML70
i686 machine; I'll attach the dmidecode here as well.
Created attachment 139347 [details]
dmidecode from affected HP ML70 system
Do you know if these messages are relatively benign, or if they are
actually a problem? The customer doesn't have any USB devices installed, and is
wondering whether this indicates a problem or if it's just a false positive.
Chis asks, if these messages are benign. The answer: depends. They do not
affect operation of devices which are plugged into ports and enumerated.
But they are not entirely harmless, for two reasons.
#1: khubd is stuck for 500ms every time this happens, so this delays the
processing of connects and disconnects;
#2: As part of the recovery from the overcurrent, power is re-enabled
on all ports. If hub has coarsely grained power, this may affect other
ports. I don't know if this is an issue on ML70.
Navid asks, if there's a hardware problem. Yes, it's likely, although
it may be a firmware problem. These messages happen (most likely) if
(a) the southbridge's harness is improperly designed and/or implemented
and shunts the power to the ground, or (b) the descriptors of the hub
do not match the actual hardware and we access ports which do not exist.
Neither of these should be fatal, it's the recovery which makes it bad.
We should not fill up the logs with these messages.
What to do? I don't know right away. We cannot ignore overcurrent
indications. So, ideally we ought to devise a way to detect a broken
port and somehow disable it (until... what? reboot?)
Chris, do you know of a way to get access to a system with this symptom?
I need to experiment, maybe get usbmon traces.
Not off-hand, although it is a certified system so we must have some
around. Let me email a few people and find out...I'll get back to you.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
This request was previously evaluated by Red Hat Product Management
for inclusion in the current Red Hat Enterprise Linux release, but
Red Hat was unable to resolve it in time. This request will be
reviewed for a future Red Hat Enterprise Linux release.