One thing I just noticed, it's always the same pages in each buffer that is 'lost' (in "find_next_packet"). If I printk some details, the 'lost' parts are always some multiple of 4k in size (with allowance for 188 byte packet).
printk("find_next_packet() lost %p %d-%d (%d)\n", buf, start, pos, lost);
and then formatting the output through sort -u to eliminate duplicates produces output like:
ffffc90002966000 0-24064 (24064)
ffffc90002987000 0-4136 (4136)
ffffc90002990000 0-4136 (4136)
ffffc90002990000 20492-24064 (3572)
ffffc90002999000 0-4136 (4136)
ffffc900029a2000 0-4136 (4136)
ffffc900029ab000 12408-20492 (8084)
ffffc900029b4000 4136-12408 (8272)
ffffc900029bd000 12408-20492 (8084)
ffffc900029c6000 0-4136 (4136)
ffffc900029c6000 20492-24064 (3572)
ffffc900029cf000 20492-24064 (3572)
ffffc900029d8000 16544-20492 (3948)
ffffc900029d8000 4136-12408 (8272)
ffffc900029ea000 0-4136 (4136)
so taking ffffc900029d8000 as an example, the second and third pages have no data in them, and neither does the fifth page. This happens every time ffffc900029d8000 is accessed.
So I'm guessing that the sg list hasn't been programmed correctly or something... does that sound right? I guess I'll print out the pfn's to see if there is a pattern there next...
James
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
