Comment 64 for bug 1175091

Created an attachment (id=555784)
updated analysis script for trace from comment 39

(In reply to comment #39)
> Created an attachment (id=552961) [details]
> the wanted log-file, while the failure occurs
>
> sporadic errors are some times hard to reproduce, this time it was easier

Thank you for this second trace and sorry for my long delay in analyzing it.

cat c39-trace | ./analyze.py
rfd 114 recv, frame len 1510 / 192 (-1318 left before page end)
rfd 113 mapped, page left 2496
rfd 115 recv, frame len 1298 / 192 (-1106 left before page end)
rfd 114 mapped, page left 1984
rfd 116 recv, frame len 1298 / 3008 (1710 left before page end)
rfd 115 mapped, page left 2240
rfd 117 recv, frame len 1298 / 448 (-850 left before page end)
[...]
rfd 470 mapped, page left 1984
rfd 472 recv, frame len 102 / 192 (90 left before page end)
rfd 471 mapped, page left 3264
rfd 473 recv, frame len 94 / 2496 (2402 left before page end)
rfd 472 mapped, page left 64
[...]
rfd 471 recv, frame len 1298 / 3264 (1966 left before page end)
rfd 470 mapped, page left 192
overflow (repeated 198 times) after rfd 471, rrd 472 frame len 102 / 64 (-38 left before page end)

It shows that the driver can in fact receive into some buffers that straddle
page boundaries and can write frames large enough to cross this boundary,
without crashing. However, once again the crash happens when writing into a
buffer that starts 64B before the page end. Like in the trace from comment 35,
that is the smallest distance present in the trace.

These traces show that the adapter crashes in a more constrained situation
(writing accross the page boundary to a buffer that starts 64B before the end
of a page) than the initial hypothesis (writing to any buffer that crosses a
page boundary).