So here's another tidbit that we may eventually want to look into: under unknown circumstances, during driver bootup, a soft lockup will take place which renders the machine inoperable. This also happens in the VM. I'll try to fish out logs to see if anything stands out. That said, the driver patch does indeed seem to take care of the death due to unplug/replug. Now I have to test thoroughly to see if a soft-reset results in the device coming back to life after a hang. This is great progress, though! I'll keep you posted with everything I find during these next few days. For now, I'd submit the patch regardless since it's an improvement nonetheless. Cheers! And thanks again!
On Sun, 2019-10-27 at 18:15 -0600, Diego Rivera wrote: > Ok so excellent news! I can now remove and re-attach the devices with no > oopses!! I'm testing the > "soft-reset" part now to see if that'll work as well, but I now have a > workaround for that, too!! > I didn't see too much noise on the logs from the sysfs teardown, then again I > didn't look too > hard. What I meant by "parameter" was just that: a runtime flag that could > be turned on/off by a > user if they grow tired of the noise on the logs. For the I2C thing, I think > blacklisting the > I2C-IR driver like we had done before should be enough of a workaround for > now. > Thanks for this!! > Cheers! > -- > > > > Diego Rivera > > On Sun, 2019-10-27 at 18:19 -0500, Mike Isely wrote: > > The sysfs teardown issue right now is largely cosmetic - you just get log > > noise but the end > > result appears to still be correct. Obviously this still needs to be > > fixed, because getting > > stack traces in the kernel message log generally sucks. > > There actually is a pvrusb2 kernel config parameter you can set at compile > > time which will > > disable the sysfs piece of this. (Not a run-time switch though.) > > -Mike > > On Sun, 27 Oct 2019, Diego Rivera wrote: > > > I had a thought about the sysfs teardown race you mentioned. Would it > > > causetoo many problems > > > if instead you added a module parameter to selectivelydisable that bit > > > and let the rest of the > > > kernel do the teardown instead? > > > That might be enough of an optional workaround for now, since that > > > doesindeed seem like a > > > bigger challenge...unless, of course, that approachbrings more problems > > > into focus... > > > Just a thought... > > > Cheers! > > > -- > > > Diego Rivera -- Diego Rivera
signature.asc
Description: This is a digitally signed message part
_______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
