the mystery is now solved thanks to you.
Alan Stern wrote:
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.Yes, I understand that fixing and hacking the driver code for every single buggy controller is
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
impossible. Even more, if it is ancient one.
now, the modem driver can be made to cope with the problem by timing outWell, at least there is something I can do about it (apart from buying a new USB card). I'll take
URBs and resubmitting them. I realize this is awkward, but it's the best
I can offer...
a look into driver and see what I can do. But at first I'll try to decrease size of driver's receive buffers.
With smaller buffer the probablity of occurence of this bug may be lower.
Just one more question: Wouldn't the resubmitting of URBs result into loss of data? I mean, when
the URB is "half complete" and I'll cancel it, will the data be resubmitted?
Thanks again for your help,
Andrej
------------------------------------------------------- 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
