Re: [Linux-usb-users] USB: Non zero status

On Mon, 20 Aug 2007, Martin Bachem wrote:

> > You said you are using ehci-hcd?  That seems strange; since this device 
> > can't trasmit more than 8 bytes/ms it should be designed to run at full 
> > speed, not high speed.  Or is it possible to run the device at line 
> > speeds higher than yours?  Even if it is, full speed could support up 
> > to at least 600 bytes/ms.  So why ehci-hcd?
> 
> think I'm wrong with that ehci postulation. if ehci-hcd is only handling
> high-speed transfers, uhci-hcd is the host controller in charge. I
> always thought ehci-hcd is the driving usb2.0 controllers, no matter
> what speed config they drive. (maybe it's hard work to write usb drivers
> without knowledge of USB ;)
> 
> 
> dmesg after unplugging device:
> 
> HFC-S USB: rx_iso_complete : urb->status -84, fifonum 5
> HFC-S USB: rx_iso_complete : urb->status -84, fifonum 7
> HFC-S USB: rx_iso_complete : urb->status -84, fifonum 1
> HFC-S USB: rx_iso_complete : urb->status -84, fifonum 3
> HFC-S USB: rx_iso_complete : urb->status -84, fifonum 5
> uhci_hcd 0000:00:1d.0: release dev 4 ep87-ISO, period 1, phase 0, 21 us
> HFC-S USB: rx_iso_complete : urb->status -84, fifonum 7
> uhci_hcd 0000:00:1d.0: release dev 4 ep88-ISO, period 1, phase 0, 21 us
> HFC-S USB: rx_iso_complete : urb->status -84, fifonum 1
> uhci_hcd 0000:00:1d.0: release dev 4 ep85-ISO, period 1, phase 0, 21 us
> HFC-S USB: rx_iso_complete : urb->status -84, fifonum 3
> uhci_hcd 0000:00:1d.0: release dev 4 ep86-ISO, period 1, phase 0, 21 us
> hub 5-0:1.0: state 7 ports 2 chg 0000 evt 0002
> uhci_hcd 0000:00:1d.0: port 1 portsc 008a,00
> hub 5-0:1.0: port 1, status 0100, change 0003, 12 Mb/s
> usb 5-1: USB disconnect, address 4
> usb 5-1: unregistering device
> usb 5-1: usb_disable_device nuking all URBs
> uhci_hcd 0000:00:1d.0: shutdown urb f59fac68 pipe 00028400 ep5out-iso
> uhci_hcd 0000:00:1d.0: shutdown urb f59fa920 pipe 00028400 ep5out-iso
> [...]

Yep, it's definitely uhci-hcd.

So to prevent getting those EXDEV errors, what you should do is always 
resubmit a TX URB.  Even if there is no outgoing frame data, submit an 
URB with 0 length.  That way the driver will maintain its correct 
location in the schedule of time slots.

I'd like to fix this eventually, but it's a low priority.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel