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 <[email protected]> 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
