Lose a packet when there is null packet in an isochronous transfer (libusb-1.0.8, linux 2.6.18)

[pvergain]

Lose a packet when there is null packet in an isochronous transfer (libusb-1.0.8, linux 2.6.18)

Context

• libusb 1.0.8
• linux 2.6.18 (centos)

• a certis2 USB device from id3Semiconductors using bAlternateSetting=3 for isochronous transfer.

lsusb -v -d 0b81:0103
(bInterfaceNumber=0, bAlternateSetting=3, bNumEndpoints=3

, endpoints=[(0x83, isochronous, IN, 868 bytes)

, (0x02, bulk, OUT, 32 bytes)
, (0x82, bulk, IN, 32 bytes)]

Interface Descriptor:

bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 3
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:

bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1

Transfer Type Isochronous
Synch Type None
Usage Type Data

wMaxPacketSize 0x0364 1x 868 bytes
bInterval 1

Endpoint Descriptor:

bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2

Transfer Type Bulk
Synch Type None
Usage Type Data

wMaxPacketSize 0x0020 1x 32 bytes
bInterval 0

Endpoint Descriptor:

bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2

Transfer Type Bulk
Synch Type None
Usage Type Data

wMaxPacketSize 0x0020 1x 32 bytes
bInterval 0

We use the isochronous mode to transfer fingerprint images from a certis2 USB device.

• one transfer = 10 packets
• at the beginning of the acquisition we immediatly submit 2 transfers and we are polling. When a transfer is received a new transfer is submitted.

The problem with null packet

During the transfer of 10 packets we notice that we lose our synchronisation stream
every time we have a null packet (piso_packet_desc->actual_length == 0).
This does not happen very often (1 null packet every 122 transfers) but this is sufficient to have small defects on the resulting image.

What we use to detect the problem

• we have put 5 megabytes of USB data received by the libusb in a file
• we have used beagle to see the data sent to the linux machine

By comparing the data received by the libusb and the data sent to the linux machine
we have come to the fact that there was a problem in the libusb 1.0.8.

Description of the problem when we receive a null packet

If the packet 8 is the null packet we have the following data from the beagle log

packet 1: 0     954 0:26.582.444    584.875 us  868 B       11  3   IN txn  60 03 00 00 87 78 87 88 87 88 87 88 78 88 88 88 78 78 87 87 77 77 78 87 77 77 77 87 77 77 78 77 88 88 78 78 77 88 78 77 87 77 87 78 77 87 88 87 87 78 87 78 87 77 88 78 77 77 78 77 77 77 77 78 87 78 77 77 87 78 77 87 77 77
packet 2: 0     958 0:26.583.444    584.875 us  868 B       11  3   IN txn  60 03 00 00 78 87 77 77 78 88 77 87 87 88 88 78 77 88 87 78 88 88 87 77 77 87 78 88 88 78 78 78 77 77 77 77 77 77 87 87 87 77 77 87 77 77 78 78 86 88 88 88 88 87 87 87 87 87 77 77 87 77 77 77 77 78 77 77 77 87 77 77 77 77
packet 3: 0     962 0:26.584.445    584.916 us  868 B       11  3   IN txn  60 03 00 00 77 77 87 78 77 78 77 77 77 77 77 67 88 87 87 88 87 78 88 77 77 87 88 77 87 78 87 88 78 77 88 88 77 78 77 87 77 77 77 77 77 77 77 87 77 78 77 77 87 77 77 87 78 77 77 77 77 77 78 77 88 77 77 78 78 77 77 87 78 78
packet 4: 0     966 0:26.585.445    584.916 us  868 B       11  3   IN txn  60 03 00 00 87 87 88 77 78 77 78 87 87 77 77 77 78 87 87 77 77 77 88 78 77 77 78 77 77 77 77 88 77 87 77 77 77 77 77 78 78 87 78 77 77 77 88 88 77 78 78 88 77 77 77 77 77 88 77 77 87 78 77 78 78 77 78 88 87 78 88 78 77 88
packet 5: 0     970 0:26.586.445    584.916 us  868 B       11  3   IN txn  60 03 00 00 77 77 78 87 77 77 78 76 77 87 87 87 77 78 77 78 77 77 87 78 77 77 77 78 77 78 87 88 87 87 77 77 78 77 78 88 77 77 77 77 78 77 77 78 77 77 78 77 77 77 77 77 77 77 77 77 77 78 77 77 77 78 77 87 77 77 77 77 77 78
packet 6: 0     974 0:26.587.445    584.895 us  868 B       11  3   IN txn  60 03 00 00 78 78 78 88 77 77 77 78 87 77 77 77 88 77 77 67 78 77 77 77 77 77 77 77 87 77 77 88 77 77 78 87 77 77 77 77 76 87 77 78 77 77 78 88 87 87 78 77 77 88 77 77 78 87 87 77 77 77 78 77 77 87 78 77 77 87 77 77 87 88
packet 7: 0     978 0:26.588.446    584.895 us  868 B       11  3   IN txn  60 03 00 00 88 87 87 77 87 77 88 88 77 87 78 77 77 77 77 77 78 77 88 77 88 78 78 78 77 87 77 77 76 76 77 87 78 87 77 78 77 77 78 78 77 77 77 77 77 77 78 77 88 77 78 87 77 77 78 77 77 88 87 87 77 77 78 78 78 77 77 77 77 77
packet 8: 0     982 0:26.589.445    6.145 us    0   B       11  3   IN txn
packet 9: 0     986 0:26.590.446    584.895 us  868 B       11  3   IN txn  60 03 00 00 88 78 77 77 87 77 77 78 78 77 88 77 87 87 77 87 77 77 77 77 77 88 87 87 77 87 77 77 77 77 77 78 87 77 78 77 77 87 77 77 77 77 77 76 77 77 78 77 77 78 77 77 87 78 77 88 77 77 77 87 77 77 77 78 77 77 77 87 87 77
packet 10: 0    990 0:26.591.446    584.916 us  868 B       11  3   IN txn  60 03 00 00 77 87 77 77 87 77 78 77 77 87 77 87 78 77 88 88 77 77 88 88 77 88 78 77 78 77 78 78 77 77 77 77 77 77 77 77 77 87 77 78 77 77 77 78 78 77 78 87 77 77 87 77 87 77 87 77 77 78 77 78 87 77 77 78 87 77 77 77 78 77

But here is what we receive from the libusb

    -
    packet 1 :  60 03 00 00 87 78 87 88 87 88 87 88 78 88 88 88 78 78 87 87 77 77 78 87 77 77 77 87 77 77 78 77 88 88 78 78 77 88 78 77 87 77 87 78 77 87 88 87 87 78 87 78 87 77 88 78 77 77 78 77 77 77 77 78 87 78 77 77 87 78 77 87 77 77 88 87 78 78 77 77 78 88 78 78 88 88 88 78 87 88 78 88 87 88
    packet 2 :  60 03 00 00 78 87 77 77 78 88 77 87 87 88 88 78 77 88 87 78 88 88 87 77 77 87 78 88 88 78 78 78 77 77 77 77 77 77 87 87 87 77 77 87 77 77 78 78 86 88 88 88 88 87 87 87 87 87 77 77 87 77 77 77 77 78 77 77 77 87 77 77 77 77 77 88 77 78 77 77 88 78 77 77 77 77 77 77 77 77 77 87 87 88
    packet 3 :  60 03 00 00 77 77 87 78 77 78 77 77 77 77 77 67 88 87 87 88 87 78 88 77 77 87 88 77 87 78 87 88 78 77 88 88 77 78 77 87 77 77 77 77 77 77 77 87 77 78 77 77 87 77 77 87 78 77 77 77 77 77 78 77 88 77 77 78 78 77 77 87 78 78 77 77 77 77 77 77 76 68 87 78 77 78 77 88 77 77 78 87 77 77
    packet 4 :  60 03 00 00 87 87 88 77 78 77 78 87 87 77 77 77 78 87 87 77 77 77 88 78 77 77 78 77 77 77 77 88 77 87 77 77 77 77 77 78 78 87 78 77 77 77 88 88 77 78 78 88 77 77 77 77 77 88 77 77 87 78 77 78 78 77 78 88 87 78 88 78 77 88 87 77 78 77 78 77 88 77 87 87 77 77 87 77 77 77 77 77 88 77
    packet 5 :  60 03 00 00 77 77 78 87 77 77 78 76 77 87 87 87 77 78 77 78 77 77 87 78 77 77 77 78 77 78 87 88 87 87 77 77 78 77 78 88 77 77 77 77 78 77 77 78 77 77 78 77 77 77 77 77 77 77 77 77 77 78 77 77 77 78 77 87 77 77 77 77 77 78 77 77 77 77 77 77 0F 0F 6E A8 77 77 78 77 77 77 77 77 77 77
    packet 6 :  60 03 00 00 78 78 78 88 77 77 77 78 87 77 77 77 88 77 77 67 78 77 77 77 77 77 77 77 87 77 77 88 77 77 78 87 77 77 77 77 76 87 77 78 77 77 78 88 87 87 78 77 77 88 77 77 78 87 87 77 77 77 78 77 77 87 78 77 77 87 77 77 87 88 78 78 78 78 77 78 78 77 78 77 88 88 77 78 88 78 87 87 78 77
    packet 7 :  60 03 00 00 88 87 87 77 87 77 88 88 77 87 78 77 77 77 77 77 78 77 88 77 88 78 78 78 77 87 77 77 76 76 77 87 78 87 77 78 77 77 78 78 77 77 77 77 77 77 78 77 88 77 78 87 77 77 78 77 77 88 87 87 77 77 78 78 78 77 77 77 77 77 87 77 77 87 77 77 77 77 87 78 87 77 77 77 77 77 77 77 77 77
    packet 8 :  60 03 00 00 77 87 77 77 77 77 87 87 78 77 77 77 77 76 77 78 87 87 87 87 88 87 78 78 78 78 87 78 78 88 78 77 87 87 77 88 77 78 77 77 77 77 78 78 77 76 77 78 77 77 77 88 87 77 77 87 87 87 77 87 88 77 78 78 78 78 87 88 87 77 87 77 77 87 77 78 77 77 77 77 78 87 87 77 78 78 78 88 77 77
    packet 9 :  60 03 00 00 88 78 77 77 87 77 77 78 78 77 88 77 87 87 77 87 77 77 77 77 77 88 87 87 77 87 77 77 77 77 77 78 87 77 78 77 77 87 77 77 77 77 77 76 77 77 78 77 77 78 77 77 87 78 77 88 77 77 77 87 77 77 77 78 77 77 77 87 87 77 77 77 77 78 78 87 87 88 87 77 78 77 77 87 77 77 87 77 77 77
    packet 10:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    -

We can see that:

• the packets 1 from 7 are correct
• the packet 8 has some data which have nothing to do with the beagle trace
• the packet number 9 is correct
• the packet number 10 has no data

By searching in the log we have found:

• that the packet 8 of the current transfer is the copy of a packet '8' of a previous transfer.
• the packet 10 seen in the beagle trace is definitely lost.

So there seems to be a problem with libusb 1.0.8 when there is a null packet during a transfer.

Can anyone help ?

Do you need some more information ?

Thanks for your help.

--
Patrick

[hansdegoede]

Hi,

I've taken a look at the libusb code involved in the transfer of iso data and it does not look at the actual packet length it gets back at all, all it does with it it copy it back to the user of the library.

This may be a kernel bug, possibly long fixed. Could you perhaps retry with a newer kernel ?

Regards,

Hans

[hansdegoede]

I've been looking into this again (triggered by looking into another bug which reminded me of this one), and I still cannot find anything wrong with our *current* code. But I've not looked at the actual 1.0.8 code, and there have been quite a few fixes / changes since then. Perhaps you can give our latest code a try and see if the bug persists?

You can find what hopefully will become our new 1.0.9 release soon here:
​http://git.stuge.se/?p=libusb-stuge.git;a=summary

One thing I did notice is that our code depends on the urbs of a split transfer (which will happen when
packetsize * number of packets in the transfer > 32Kb) completing in the order of submission. Judging from the
provided info you're not using split transfers so this should not be an issue in your case. To be sure
you could enable libusb debug output (this is a good idea when debugging issues in general) by configuring
libusb with:
./configure --enable-debug-log

Lines to watch to look for split iso transfers are:
"need %d 32k URBs for transfer"
If %d > 1 you are using a split transfer

And then on completion:
"handling completion status %d of iso urb %d/%d"

Where if say you've a transfer split into 2 urbs, you should see:
1/2
2/2
1/2
2/2

Etc.

[xiaofan]

No news from the original submitter, shall we close this ticket?

[hansdegoede]

Replying to xiaofan:

No news from the original submitter, shall we close this ticket?

Yes lets close this ticket.

[stuge]

Am closing as needinfo. Please re-open and provide usbmon logs as well as libusb debug output if the problem persists in a current version of the code.