On Wed, 25 Nov 2009, Stephan Diestelhorst wrote: > The patch seemed to work initially, however, after booting several > times and enabling / disabling the cam (through hotkey) and additional > rmmod uvcvideo, I managed to trigger the bug again, see the dmesg > with successful and errorneous attempts attached. You should add a dump_stack() line to handshake_on_error_set_halt(), just after the ehci_err() call. Then we'd be able to see the failure pathway and determine whether it really was caused by the delay being too short. > It might well be the case that the delay is too small. I will change > to a higher value (this and the device ID should eventually be > converted into symbolic constants). Does anybody have a clue how to > properly determine the neccessary delay, either with a stress test or > by someone (Intel) telling us the hardware delay? There hasn't been any feedback from Intel. If you can find the right person to ask, go ahead. Otherwise a stress test is the only option. 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
