Bug #5490
openISO IN urb sometimes completes with less than full data / incomplete frame
0%
Description
This is happening frequently at gruetzkopf:
Assert failed size % 32 == 0 mux_demux.c:419
This means that a non-modulo-32 length (plus 5 byte header) was received in an ISO IN URB.
22:00 <@gruetzkopf> <0001> mux_demux.c:421 (I0:L0) Transfer cut short, size was 251 bytes 23:58 <@gruetzkopf> just so i don't forget: i've also seen 253 and 252 by now
So this means that instead of 256 (+4) we've seen 251-253 (+4) byte transfer length.
I've checked the firmware, an I don't see any way how the firmware could do something wrong here: It uses (n * 32) + 4) as length, whic hcan never be one of those odd values.
On the osmo-e1d side, we are always checking for LIBUSB_TRANSFER_COMPLETED state, so both the transfer/urb, as well as the individual packets have LIBUSB_TRANSFER_COMPLETED before passing them higher up to the mux_demux code which is asserting here.
So I guess the underlying question is: Is this a kernel/libusb bug? Is it legal for ISO IN packets to complete with a length less than what was submitted?
If this is legal, then the next question si why it it is happening.
We can of course plaster around the issue and substitute the missing data with 0xff or something, creating various bit errors, rathe than asserting.
Files
