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

[Diego Rivera]

I disabled the ir_kbd_i2c and rc_hauppauge modules last night, and I haven't seen the soft lockup on
boot since.  I get a nagging feeling that it's the same thing happening on bootup, only when the
kernel is in a vulnerable position where such a loop causes it to choke...
I'll keep you posted if I see it without those modules in play. If that's it, then that as they say
would be that and I'd have solved all the issues in play.
Cheers!

On Sun, 2019-10-27 at 22:24 -0600, Diego Rivera wrote:
> 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 <isely at isely.net> 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
> > 
> > > 
> > 
> > 
> > 
-- 



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/20191028/bfed6f88/attachment.sig>