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 the > opportunity 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 the > > values 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 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, [email protected] 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 > -- 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 [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
