On Thu, Aug 9, 2012 at 10:29 PM, Alan Stern <[email protected]> wrote: > In theory a similar quirk could be written to fix your problem. An > easy way to test this, if you can automatically detect the "hung" > condition, would be to set ohci->ed_to_check to the "unkillable" ed. >
I used a very stupid/simplistic logic I already had for debugging, to detect the condition: at the fourth (since its normally just one) pass over the SF interrupt clear without being it cleared, I assume it is stuck, and if ed_rm_list is the only one element long, I put it in ed_to_check. This seems to work, but its very odd: in my first test, after the first instance of the occurrence, every 5 second this condition kept popping up, 6 times, until the communication died definitely with -EPIPE: But neither the USB stack or app froze, just plug & unplug the device and good to go again. The second test, the "highlander ed" condition popped up, this time twice, also with a 5 second between them, but no further problems for quite a while after this, and no communication errors. Then three more events 5 sec. apart, and -EPIPE again. It seems this condition comes in a "cluster", or the simplistic logic of detection of this condition is not very well suited. -- Tomas J. Sokorai Sch. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
