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
