[pvrusb2] [PATCH] pvrusb2: Fix oops on tear-down when radio support is not present

[Diego Rivera]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://www.isely.net/pipermail/pvrusb2/attachments/20191027/2ff241a5/attachment.sig>