On Saturday 24 January 2009 11:15:58 Sheng Yang wrote:
> 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... :(
A little more complex...
If I connect the device to the USB extension cable(as I did before), touch the
unit won't result in reset. But if I direct plug it to the desktop, touch it
would result in reset... But the USB extension cable likely to be the convict
of reset for relative long period of time(for if I plug my removeable disk
with it, Linux won't get the device, but direct plug in is OK)...
Maybe go for a better USB extension cable... Or return the unit...
--
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
