Hi, > > The question in this case would seem to be why the donelist processing > > wasn't catching the TD at the list head. You might add a debug check > > calling ohci_dump_td() on the TD triggering that skip_ed branch; or > > maybe even ohci_dump_ed(verbose) to see the whole queue there. If > > that's called a lot, then just dump it the first three or four times.
Well, I did that, but of course the problem now manifested itself in a
different way: finish_unlinks() seems not to have been called at all.
The code says
/* HC may have partly processed this TD */
td_done (ohci, urb, td);
urb_priv->td_cnt++;
/* if URB is done, clean up */
if (urb_priv->td_cnt == urb_priv->length) { [...]
but td_cnt hasn't been incremented ever:
(gdb) p *(struct urb_priv *)0xda7cdba0
$28 = {ed = 0xda580000, length = 2, td_cnt = 0, pending = {next = 0xde70ca88,
prev = 0xdefa7e98}, td = 0xda7cdbb0}
... which is rather bad. It gets worse, however: dumping the HCCA shows
that the frame number is not incremented any more, despite HC_IS_RUNNING()
being true: it's still == ed->tick -1.
I am not sure how to recover from that. Apparently the chip has wedged
itself into a corner..?
Ideas appreciated. My brute-force idea would be to sample that frame
number every couple of jiffies and, if it hasn't changed, call
ohci_restart() and hope for the best. :-/
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Don't permit yourself to get between a dog and a lamp-post.
signature.asc
Description: Digital signature
