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

[Diego Rivera]

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
> _______________________________________________
> pvrusb2 mailing list
> pvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>