[pvrusb2] Ability to fully reset a PVRUSB2 Device

Mike Isely isely at isely.net
Mon Sep 9 17:42:44 CDT 2019


Stay tuned.  And pester me again if I go quiet for too long.

The pvrusb2 driver sets up a single internal kernel thread to take care 
of various bits of background activity.  That thread also performs part 
of the setup and most of the tear-down when a device is hotplugged / 
hot-unplugged.  The oops is definitely happening in that thread - which 
is a good thing because it means that it should be possible to rule out 
lots of bizarre interactions involving other threads calling into the 
driver.  I am going to add printk's before each step of the tear-down 
process so I can start to get an idea where it is going awry.  I hope to 
do that tonight.

  -Mike


On Sun, 8 Sep 2019, Diego Rivera wrote:

> No problem! I can imagine how normal life has you pegged down, just like it does with us all!
> Thanks for circling back to it, though. Is there anything I can do on my end to help you?
> Cheers!
> 
> On Sat, 2019-09-07 at 14:26 -0500, isely at isely.net wrote:
> > Hi Diego,
> > I am sorry.  I had gotten completely distracted away from this.
> > I just updated to the latest kernel and have confirmed that it's still getting an oops when the
> > device is hot-unplugged.  I'm looking at it right now.  At first glance this looks like a fairly
> > nasty tear-down race - which long ago didn't used to be there.  So there has to be some kind of
> > environmental change leading to this behavior.
> >   -Mike
> > On Wed, 21 Aug 2019, Diego Rivera wrote:
> > > Hi, Mike!Any luck with this? I haven't poked you in some time so I figured I'd check to see if
> > > you've had theopportunity to debug this anymore, and if there's any way I can help with the
> > > process...Let me know!Cheers!
> > > On Sat, 2019-04-20 at 20:16 -0600, Diego Rivera wrote:
> > > > This is the result of a 2nd attempt with a hot-unplug.  I don't see many differences beyond
> > > > thevalues of some registers changing between one instance and the other.Cheers!-- 
> > > > 
> > > > 
> > > > Diego Rivera
> > > > On Sat, 2019-04-20 at 20:09 -0600, Diego Rivera wrote:
> > > > > Guinea pig #1 responding as ordered, sir!☺One is the kernel log from connection, the other
> > > > > is what happens if I try to do a modprobe-r.  I noticed there's a call trace with registers
> > > > > - I'm wondering if I need to add more symbolspackages so that trace can be more verbose and
> > > > > offer up more info. Thoughts?Let me know if you want me to try anything else.  I'm going to
> > > > > produce the output now for hot-unplug of the same device, see how that differs.Cheers!-- 
> > > > > 
> > > > > 
> > > > > Diego Rivera
> > > > > On Sat, 2019-04-20 at 20:26 -0500, isely at isely.net wrote:
> > > > > > Status update.  Nothing really useful to report except that I am seeing some screwy
> > > > > > behaviorjust on hotplug / hotunplug operations with the device just sitting idle not being
> > > > > > touched byanything.  In this case I tested an old 29032 model - a very early module but
> > > > > > it's a usefultest subject because it is simpler than the HVR-1950 yet still exercises most
> > > > > > of the keypieces of the driver.  I ran a freshly compiled 5.0.9 kernel (latest stable) for
> > > > > > this test.Sorry this has taken so long.  As was guessed earlier, I haven't worked on this
> > > > > > in a very longtime and I had to unbox a lot of stuff.  I also spent far too much time
> > > > > > today setting up aseparate purpose-built computer which I can trash / crash / hang with
> > > > > > wild abandon withoutlosing anything of value.  This approach allows me to keep my dev
> > > > > > environment on a machineseparate from the one that is running test kernels.I was able to
> > > > > > cleanly modprobe -r pvrusb2 every time so far, but if the issue is on the DVBside of the
> > > > > > fence, then the old 29032 model I've just tried won't exhibit that issue.  So alot more
> > > > > > characterization to do.Diego: It would useful if you could post to me the section of your
> > > > > > /var/log/kern.log (orequivalent) should all the kernel messages from the point when you
> > > > > > plug in the device to whenthe fireworks are happening after trying to tear down.  If I
> > > > > > find that same pattern here thenwe'll know for sure that we are chasing the same issue.  -
> > > > > > Mike
> 

-- 

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


More information about the pvrusb2 mailing list