On Friday 23 January 2009 22:58:19 Alan Stern wrote:
> 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, thanks very much for detail explaining!
Finally I found the bad USB cable result in reset sometime as I described. And
every time I touched device, it would reset too... God! I would ask for
refund... :(
--
regards
Yang, Sheng
--
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
