On the LOP addressing: correct. lop_page_addr holds the PFN of the LOP table, and the table’s contents are the data-page PFNs. My version logged the data PFN and the table’s bus address but not entry[0].lop_page_addr itself, so it couldn’t actually verify the link you’re asking about. The new version logs all three, including what the value should be, so a mismatch is visible at a glance.
On staleness: also correct, and it matters more than instrumentation hygiene. Those four fields are written only by the DMA engine and nothing clears them when a buffer slot is reused — with 8 buffers, each slot carries values from 8 frames earlier. A completion-only dump could easily have shown us a previous frame’s counters and sent us down the wrong path.
The consequence is bigger though: the driver’s existing “payload length … received …” check reads received from one of those stale-able fields. So your run with no payload warnings does not prove a full transfer happened — it may have been comparing against a leftover value that happened to match. I read too much into that last time. Zeroing the counters at queue time fixes the new dump and the existing warning together.
One trap if you compare against your reconstruction: entry gets advanced by the fill loop, so the zeroing and the queue-time log have to use a saved base pointer, not entry[0].
Reading the output:
-
cur_line_num non-zero at completion → the DMA ran for that frame. If it’s near the frame height while your buffer is untouched, it wrote somewhere else and your theory is confirmed.
-
cur_line_num zero → the DMA never transferred; the completion is bookkeeping over nothing.
-
fbpt_lop_pfn != expect_lop_pfn → the FBPT is pointing at the wrong LOP table, which would be the whole answer.
9006-DEBUG-cio2-dump-fbpt-dma-fields.patch (1.5 KB)