On Sat, 18 Oct 2008, Mike Isely wrote: > I need to go back and study older kernels to see why this wasn't a > problem before 2.6.27. Once I have a better handle on this, I'll > concoct a patch to fix it permanently. >
I found the difference. Older kernels had different behavior when a USB device reset request was issued to the USB core. Previously the USB reset took place "in line", meaning that the reset request was executed by the USB core and control returned back to the caller, with no other state "disturbed". Specifically, the USB device remained connected and the driver instance still had control of it. With kernel 2.6.27, calling into the USB core to request a device reset triggers a USB disconnect / reconnect - and the disconnect callback to the driver happens on the same stack (i.e. thread context) as the caller which issued the reset request. Doing that callback piggybacked on top of the driver's own call into the USB core sets up the deadlock in the driver. However, even if the callback had come from another thread context we'd still be screwed: In that case the driver would happily disconnect, then it would get the reconnect as one might expect. And then... the driver would simply have issued another USB reset request as part of the new initialization. Lather, rinse repeat... Clearly it's no longer safe for the driver to trigger any kind of USB device reset and still hope to hang onto the device it is controlling. I will eliminate the initusbreset behavior completely. If anyone thinks this might be a bad idea (does someone thinks he/she is depending on it?), please tell me now. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
