[pvrusb2] Ability to fully reset a PVRUSB2 Device

[Diego Rivera]

This is the result of a 2nd attempt with a hot-unplug.  I don't see many differences beyond the
values of some registers changing between one instance and the other.
Cheers!

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 symbols packages
> 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 behavior
> > just on hotplug / hotunplug operations with the device just sitting idle not being touched by
> > anything.  In this case I tested an old 29032 model - a very early module but it's a useful test
> > subject because it is simpler than the HVR-1950 yet still exercises most of the key pieces 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 long
> > time and I had to unbox a lot of stuff.  I also spent far too much time today setting up a
> > separate purpose-built computer which I can trash / crash / hang with wild abandon without
> > losing anything of value.  This approach allows me to keep my dev environment on a machine
> > separate 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 DVB side
> > of the fence, then the old 29032 model I've just tried won't exhibit that issue.  So a lot more
> > characterization to do.
> > Diego: It would useful if you could post to me the section of your /var/log/kern.log (or
> > equivalent) should all the kernel messages from the point when you plug in the device to when
> > the fireworks are happening after trying to tear down.  If I find that same pattern here then
> > we'll know for sure that we are chasing the same issue.
> >   -Mike
-- 



Diego Rivera

-------------- next part --------------
A non-text attachment was scrubbed...
Name: connect-2-kern.log
Type: text/x-log
Size: 5871 bytes
Desc: not available
URL: <http://www.isely.net/pipermail/pvrusb2/attachments/20190420/65d578da/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hot-unplug-kern.log
Type: text/x-log
Size: 26353 bytes
Desc: not available
URL: <http://www.isely.net/pipermail/pvrusb2/attachments/20190420/65d578da/attachment-0003.bin>
-------------- 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/20190420/65d578da/attachment-0001.sig>