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

[Mike Isely]

Quick update:

I've been dealing with another pop-up interrupt that has been taking my 
time ("fun" stuff involving PIC microcontroller firmware and a safety 
certification).

Thank you for reporting success.  I will get that patch pushed up.  I 
need to do two more quick things with it and I will try to get that 
submitted tomorrow evening.

Then I will turn my attention back to the remaining problems.

  -Mike


On Mon, 28 Oct 2019, Diego Rivera wrote:

> 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
> > > 
> > > > 
> > > 
> > > 
> > > 
> 

-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8