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

Alan Stern wrote:
> On Sat, 18 Aug 2007, Martin Bachem wrote:
> 
>> yes, it's about TX frames... The ISDN controller working within the
>> device is a HFC-S USB (http://www.colognechip.com/hfc-s-usb.pdf ), which
>> has a very small Fifo of 128 Bytes. If I start filling the beginning of
>> an HDLC Frame into the Fifo, the fifo starts emptying this one to line
>> interface immetiately. If the Fifo runs empty, it terminates the HDLC
>> Frame. So I need to make sure the Fifo is well filled during the
>> transmission of one HDLC frame. This is the matter: as long is the
>> controller is transmitting one Frame, I need to keep the fifo well
>> filled with this frame data, but have to make sure to produce no overun.
>>
>> I configure each Fifo's fill level threshold to 64 bytes. The status
>> info of 'threshold reached' is signalled by a state byte in the RX URBs.
>> So at the time I care about the threshold reached bit (tx ISO
>> completion), its outdated.
>> The next issue is I do not know at what speed the fifo is emtied to line
>> interface. The line interface speed is fixed to 8 byte per ms, but due
>> to HDLC encoding the data amout gets increased by an unkown value (I
>> could do software HDLC encoding to know exactly, but I want to avoid that).
>>
>> So I start transmitting an HDLC frame by putting 8 bytes per ms in TX
>> ISO URBs. As soon as I realize by analyzing the RX URBs that threshold
>> is reached, I continue the TX stream by writing just 6 bytes into each
>> ISO packet. This way I hope to alternate betweeen threshold reached and
>> fill level below threshold smoothly, without messing with the fifos
>> boundries...
> 
> I see.  It's a really stupid design.
> 
> The overhead added by HDLC encoding can't slow the transfer rate much
> below 4 bytes/ms, right?  So what you're doing sounds pretty
> reasonable.  However you could consider transmitting only 4
> bytes/packet while the FIFO is above the threshold and 8 bytes/packet
> while it is below.  That should give at least 16 ms worth of leeway, so
> you could use 2 URBs and around 7 packets per URB.
> 
> You'll probably still need to do the "start_frame" debugging to figure 
> out the reason for those -EXDEV errors, though.

I will try so and let you know...

> 
> 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
[...]







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