From: Clemens L. <cl...@la...> - 2013-08-26 14:20:30
|
Jonathan Woithe wrote: > I have had a chance to look into this. As far as I can tell the transmit > packets are not being over run. The expected packet size is requested when > iso transmit is being set up, and data is not written beyond the expected > end point when filling the buffer in the callback. In any case, the kernel checks that packet buffers never go outside the iso buffer, and that buffer is independent of any other buffers, so if FFADO were to do anything weird with its packets, the only possible corruption would be in the packets' contents. > I'm now wondering whether there is something about the data pattern when a > Fireface is in use which is triggering this problem. The pattern in the kernel's memory allocations is quite simple: some memory (for an entry in the DMA descriptor queue) gets allocated when a packet is submitted. When that packet is actually transmitted on the bus, the DMA entry is freed, and a little bit of memory for the completion event is allocated. That event memory gets freed when userspace reads the event. To exhaust kernel memory, FFADO could either submit too many packets, or continue to submit packets even though the DMA context is stopped, or it could never read the completion events from the device. > Next up (possibly tomorrow) I'll try to understand what precisely triggers > the CTR discrepancy message to see if that sheds any light on things. This happened before the lockups, and I suspect it's an independent problem. Regards, Clemens |