Download your favorite Linux distribution at LQ ISO.
Go Back > Forums > Linux Forums > Linux - Newbie
User Name
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!


  Search this Thread
Old 10-31-2010, 09:05 PM   #1
LQ Newbie
Registered: Oct 2010
Posts: 2

Rep: Reputation: 1
USB port nn disabled by hub (EMI?), re-enabling

I am getting this occasionally in dmesg:
USB port nn disabled by hub (EMI?), re-enabling
and I would like to know:

What does the message mean, exactly? What is the actual hardware error code from the USB subsystem?

Under what conditions would the root hub disable the port?
Is it related to the USB power or the USB data lines?
If it's power, what aspects of the USB power does the root hub monitor? Voltage out of limits? Current spike? Ground bounce?
Can this power monitoring feature be turned off in the Linux driver settings?
Old 11-01-2010, 01:45 AM   #2
LQ Newbie
Registered: Oct 2010
Posts: 2

Original Poster
Rep: Reputation: 1
Okay I did some digging myself:
In stable: 2010-09-06
in /drivers/usb/hub.c
* EM interference sometimes causes bad shielded USB devices to
* be shutdown by the hub, this hack enables them again.
* Works at least with mouse driver.
if (!(portstatus & USB_PORT_STAT_ENABLE) &&
(portstatus & USB_PORT_STAT_CONNECTION) && (dev->children[i])) {
err("already running port %i disabled by hub (EMI?), re-enabling...", i + 1);
usb_hub_port_connect_change(hub, i, portstatus, portchange);

in /drivers/usb/hub.h
* wPortStatus bit field
* See USB 2.0 spec Table 11-21
#define USB_PORT_STAT_ENABLE 0x0002
#define USB_PORT_STAT_SUSPEND 0x0004
#define USB_PORT_STAT_RESET 0x0010
/* bits 5 for 7 are reserved */
#define USB_PORT_STAT_POWER 0x0100
#define USB_PORT_STAT_LOW_SPEED 0x0200
#define USB_PORT_STAT_TEST 0x0800
/* bits 13 to 15 are reserved */


USB 2.0 spec says: PORT_CONNECTION
When the Port Power bit is one, this bit indicates whether or not a device is attached. This field reads as one
when a device is attached; it reads as zero when no device is attached. This bit is reset to zero when the port
is in the Powered-off state or the Disconnected states. It is set to one when the port is in the Powered state,
a device attach is detected (see Section, and the port transitions from the Disconnected state to the
Disabled state.
SetPortFeature(PORT_CONNECTION) and ClearPortFeature(PORT_CONNECTION) requests shall not
be used by the USB System Software and must be treated as no-operation requests by hubs. PORT_ENABLE
This bit is set when the port is allowed to send or receive packet data or resume signaling.
This bit may be set only as a result of a SetPortFeature(PORT_RESET) request. When the hub exits the
Resetting state or, if present, the Speed_eval state, this bit is set and bus traffic may be transmitted to the
port. This bit may be cleared as the result of any of the following:
The port being in the Powered-off state
Receipt of a ClearPortFeature(PORT_ENABLE) request
Port_Error detection
Disconnect detection
When the port enters the Resetting state as a result of receiving the SetPortFeature(PORT_RESET)
The hub response to a SetPortFeature(PORT_ENABLE) request is not specified. The preferred behavior is
that the hub respond with a Request Error. This may not be used by the USB System Software. The
ClearPortFeature(PORT_ENABLE) request is supported as specified in Section

So the message is triggered when a connected port is changed to disabled by the hardware, and the code in usb.c then reenables it.
It also isn't a disconnect detection or an overcurrent detection.

I assume, then, that the hardware is disabling the port due to Port_Error detection:

USB 2.0 spec:

Port_Error == Internal Error condition detected (see Section 11.8.1)

11.8.1 Port Error
A Port Error can occur on a downstream facing port that is in the Enabled state. A Port Error condition
exists when:
The hub is in the WFEOP (Wait for End of Packet) state with connectivity established upstream from the port when the
(micro)frame timer reaches the EOF2 point.
At the EOF2 point, the Hub Repeater is in the WFSOPFU (Wait for Start of Packet from Upstream Port) state, and there is other than Idle state on the port.

If upstream-directed connectivity is established when the (micro)frame timer reaches the EOF1 point, the
upstream Transmitter will (return to Inactive state) generate a full-speed EOP to prevent the hub from being
disabled by the upstream hub. The connected port is then disabled if it has not ended the packet and
returned to the Idle state before the (micro)frame timer reaches the EOF2 point.

It looks to me like the protocol is being disrupted. It's a shielded USB cable, and USB uses differential signaling, so I'm suspecting the USB controller in my end device (a touchscreen) is the victim of some EMI coupled either through a common 0V reference connection, or through the touch interface it is connected to. (it isn't static discharge in this case.)
1 members found this post helpful.
Old 08-08-2011, 02:27 PM   #3
LQ Newbie
Registered: Mar 2011
Posts: 13

Rep: Reputation: 0
Thanks for shearing. It was driving me nuts .. I'll have to see if it's a EMI or other hardware issue.


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
"hub.c : connect-debounce failed, port 1 disabled " slk Linux - Software 3 11-10-2009 10:37 AM
4-Port USB Hub jglen490 Linux - Laptop and Netbook 7 12-25-2008 12:35 PM
"hub 1-2:1.0 Cannot enable port 2. Maybe the USB cable is bad?" General Linux - Hardware 1 04-21-2007 05:06 PM
D-Link DUB-H7 7-Port USB Hub help fred57 Linux - Hardware 1 09-15-2006 08:14 AM
usb port and usb hub dosent woke in suse 9.3 newpants2003 Linux - Newbie 1 06-13-2005 07:55 AM > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 07:40 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration