> > "
> > Note that the Total Bytes To Transfer field may be zero when all the
> > other criteria for executing a transaction are met. When this occurs,
> > the host controller will execute a zero-length transaction to the
> > endpoint. If the PID_Code field indicates an IN transaction and the
> > device delivers data, the host controller will detect a packet babble
> > condition, set the babble and halted bits in the Status field, set the
> > Active bit to a zero, write back the results to the source qTD, then
> > exit this state.
> > "
> >
> >
> > To me the above indicates that a ZLP will be automatically sent by the
> > hardware for a transaction ending on a boundary.
>
> No; that's not what it means. It means that the hardware will send a
> ZLP if the driver builds a qTD with a zero transfer length.
OK. Thanks. That debunks a theory of operation I had constructed.
I have a driver which works perfectly (I'm told) with high-speed USB, but fails regularly with a full-speed HC. I don't yet have a reproducible failure scenario. The device is a CDC ethernet type of device - a wireless adapter. Failure means the tx network queue gets stuck requiring reboot (rx ok).
I suspect lack of URB_ZERO_PACKET to be the problem as the device spec requires short packets to terminate a transfer. But given that 512 bytes is the transfer size for EHCI it seems to me that the same problem should occur for high-speed too, just at a lowered probability.
I'm new to the project and I'm waiting on test results. The device only works in a wireless environment I do not have direct access to (flash-OFDM) so I'm low on data.
While I'm waiting for test results, can anyone think of other mistakes that might cause the driver to get stuck in the tx direction but not at full-speed? If this is the wrong forum please point me in the right direction.
I've recently added tx_timeout+watchdog_timeo to the net_device part. Awaiting results on that as well as URB_ZERO_PACKET.
--
Rich
--
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
