On Fri, 23 Jan 2009, Sheng Yang wrote:
> Hi, Linux USB community
>
> Recently I brought a USB sound card, everything looks fine except sometime
> this thing happen:
>
> [ 2870.009042] hub 1-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
> [ 2870.009051] usb 1-1: USB disconnect, address 3
> [ 2870.372015] usb 1-1: new full speed USB device using uhci_hcd and address 4
> [ 2870.693906] usb 1-1: configuration #1 chosen from 1 choice
> [ 2870.759002] input: Burr-Brown from TI USB Audio CODEC as
> /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1:1.3/input/input8
> [ 2870.784180] input,hidraw0: USB HID v1.00 Device [Burr-Brown from TI
> USB Audio CODEC ] on usb-0000:00:1a.0-1
>
> Everytime this happened during my listening. And after this, I have to reset
> my application to make sound work again.
>
> Kernel is 2.6.27-11, which is distribute with Kubuntu. I checked the code of
> upstream, found this:
>
> > /*
> > * EM interference sometimes causes badly
> > * 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)
> > && !connect_change
> > && hdev->children[i-1]) {
> > dev_err (hub_dev,
> > "port %i "
> > "disabled by hub (EMI?), "
> > "re-enabling...\n",
> > i);
> > connect_change = 1;
> > }
>
> I don't understand the comment here. So I checked the git-annonate, but seems
> this one had been added since the git repository created.
>
> Is there anybody can elaborate the comment(google didn't help me on this so
> far...), and if it due to some bad hardware design/programming?
USB communications are divided into frames (and microframes, if you're
using high-speed). Each frame lasts 1 millisecond. Packets are not
allowed to cross a frame (or microframe) boundary; if a device sends a
packet that goes on for too long -- beyond the end of the frame in
which it started -- then the hub into which the device is plugged will
disable the device's port. The same thing will happen if there's
electromagnetic noise in the USB cable when a frame ends. In short,
any activity at the wrong time will cause the port to be disabled.
The comment refers to this. The device's port has been disabled by the
hub (we don't know exactly why), so the code will go ahead and try to
re-enable the port.
> And what's
> wrong indeed?
Either the device isn't working right (sending packets when it
shouldn't be) or else there's noise in the USB cable. Or possibly,
your computer's USB controller isn't working right and thinks this is
happening even though it isn't.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
