Hi Alan,
> Wow. The only thing I can think of which might cause this is if you
> didn't apply the new patch correctly. In particular, it looks like you
> managed to erase the line saying
>
> qh->xacterrs = QH_XACTERR_MAX;
>
> from qh_link_async() in ehci-q.c. It's not _too_ unlikely; that line
> immediately follows one of the changes in the patch.
Nope, I still have that line (and another one qh_completions).
> This isn't exactly an overflow. It's more like qh->xacterrs was left
> equal to 0 instead of being initialized to 32. That line does the
> initialization -- hence my suspicion.
Ok, not an overflow, but an underflow then. I was thinking it might be that
control flow somehow ends up at the if:
if ((token & QTD_STS_XACT) &&
QTD_CERR(token) == 0 &&
--qh->xacterrs > 0 &&
!urb->unlinked) {
with the first two conditions true, but the last one false. In this case,
exacterrs could be decremented without the XactErr message printed. If this
happens a few times (say 32) in quick succession, xacterrs could end up at
or below zero without any message being generated.
However, that would mean that after 32 tries, when xacterrs ends up at 0,
urb->unlinked suddenly becomes NULL, so the next time this if is reached, the
message is printed (with xacterrs having a value of 255 and the retry count
being printed as 32 - 255 = -223). This urb-unlinked suddenly becoming NULL
sounds unlikely, mostly since there is nothing else that uses xacterrs.
To be sure, I'm doing a new build using a clean tree with your patch applied.
I'll add some debug statements on the spots where xacterrs is reset, to see if
we can spot what happens.
Gr.
Matthijs
Attachment:
signature.asc
Description: Digital signature
