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

Alan Stern schrieb:
> 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.


to make it worse: I am always resubmitting the ISO URBs. As mentioned, I
handle two TX ISO URBs per endpoints, I hope as long the device is
plugged. When no frame data is to be transmitted, the ISO URBs should be
re-submitted at every ISO completion, containing 8 ISO packets with 1
byte (=0), what is the desired idle situation. (useless resource waste,
but running ISDN takes sacrifices anyway ;)

Martin Bachem



-------------------------------------------------------------------------
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