RE: USB error checking

["Terry Moore" <tmm%mcci.com@localhost>]

Robert Swindells wrote:
> I posted a few weeks ago that I could reboot my Pinebook by doing:
> 
> % cat /dev/video0 > foo.jpg
> 
> I have now got it to drop into DDB and found that it is triggering an
> assertion in sys/arch/arm/arm32/bus_dma.c:_bus_dmamap_sync().
> 
>        KASSERTMSG(len > 0 && offset + len <= map->dm_mapsize,
>             "len %lu offset %lu mapsize %lu",
>             len, offset, map->dm_mapsize);
> 
> with len = 0.
> 
> I'm guessing that the video camera is returning bad USB packets.

For what it's worth, a zero-length USB packet in a video stream is expected
and frequent if you're doing variable-length (jpeg) compression over an
isochronous stream. (The video stream is compressed, and the compressed
frames are sent synchronously; so when you're done with data for a given
frame, you have to send zero-length packets in each sample interval to let
the host know that it's grabbed all the data.)

Given how EHCI hardware works, the buffer was allocated and is non-zero in
size; the actual size that came back in the descriptor is zero. I suppose
that usb_transfer_complete(), which is probably not EHCI-specific, optimized
the bus map call by only mapping the portion with valid data.

Zero-length USB packets are a very common scenario for everything except
Mass Storage, keyboards, and mice (which almost never send zero-length
packets on a data pipe). 

The man page for bus_dmamap_sync() doesn't say that a length of zero is
forbidden.

Best regards,
--Terry