On Thu, 30 Jul 2009, Matthijs Kooijman wrote:
> 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.
In addition, urb->unlinked is never supposed to change from nonzero to
0 while the URB is active.
> 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.
Good idea.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
