On Fri, 10 Aug 2012, Tomas Sokorai wrote: > 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. I suspect what you're seeing is somehow indicative of a nasty underlying bug in the OHCI controller. Have you been able to try testing an OHCI-based system with a non-NVIDIA chipset? 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
