Yeah. Figured as much. I'll see what I can repro in terms of core dumps and stack traces.
Cheers! -- Diego Rivera On Sun, Oct 27, 2019, 21:10 Mike Isely <[email protected]> wrote: > > Thanks. I'll get that patch pushed upstream. > > The soft lockup situation I have not seen yet. That isn't to say it > isn't happening, but rather that I will probably need a lot of info in > order to reproduce it here. (This sort of problem can be a real devil > to reproduce especially on non-identical equipment.) > > -Mike > > On Sun, 27 Oct 2019, Diego Rivera wrote: > > > 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 > > > > -- > > Mike Isely > isely @ isely (dot) net > 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 > _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
