On Wed, 3 Nov 2004, Andrej Kristofic wrote:

> I compiled and booted 2.6.10-rc1 kernel. The problem is still present. 
> Below is the controller
> state from /proc/driver.
> 
> Best regards,
> 
> Andrej

<...>
>     [c2e8e2a0] link (02e8e212) element (03343b00)
>      Element != First TD
>       0: [c3343140] link (03343180) e3 SPD Length=3f MaxLen=3f DT0 
> EndPt=7 Dev=2, PID=69(IN) (buf=030f6000)

<...>
>       21: [c3343b00] link (03343b40) e3 SPD Length=3f MaxLen=3f DT1 
> EndPt=7 Dev=2, PID=69(IN) (buf=030f6540)
>       22: [c3343b40] link (03343b80) e3 SPD Active Length=0 MaxLen=3f 
> DT0 EndPt=7 Dev=2, PID=69(IN) (buf=030f6580)
<...>

This very clearly indicates a hardware bug in the UHCI controller.  It's 
not a question of missing interrupts or anything like that; the controller 
was supposed to update a pointer in memory and it failed to do so.

Here's the quick summary.  At the top you see a QH that contains 53 TDs.  
The controller has finished executing TDs 0 - 21 and should be working on
TD 22.  (You can tell because TD 21 isn't marked Active but TD 22 is.)  
And in fact the element pointer in the QH should have been updated to
point to TD 22 at the time TD 21 was completed but it wasn't; it still
points to TD 21.  Consequently the controller doesn't realize it has more
work to do.  All it knows is that it's up to TD 21, which is no longer
active.  Hence it skips the entire entry and never goes on to finish the
remaining TDs.

In principle the UHCI driver could be made to cope with such problems, by 
updating the element field as necessary.  In practice it's not so easy 
to do this, because the situation above is a legal kind of intermediate 
state.  It shouldn't persist longer than a millisecond, but the driver 
currently isn't designed to detect that sort of persistence.

For any driver, there's a limit to how much device bugginess it can cope
with.  This PIIX3 bug exceeds the limit of the UHCI driver as it now
stands.  Maybe some time in the future the prospect will improve.  For
now, the modem driver can be made to cope with the problem by timing out
URBs and resubmitting them.  I realize this is awkward, but it's the best
I can offer...

Alan Stern



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Reply via email to