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

[Diego Rivera]

Hey! Any news on the patch making it into mainline? And how can I track if/when it's been integrated
to the core kernel?
Thanks!

On Sun, 2019-11-03 at 20:41 -0600, Mike Isely wrote:
> 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 onboot since.  I get a nagging feeling that it's the same thing happening on bootup, only
> > when thekernel 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 saywould 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/20191119/2467e3e9/attachment.sig>