It's been quite a long time, but I am working on it. My effort has been slowed due to everything else on my plate but I should be caught up and able to test for it this coming weekend. Been working on getting a kernel set up for this today.
-Mike On Wed, 10 Apr 2019, Diego Rivera wrote: > Hi! > Just wondering if you were able to get your setup going and if there's > anything I can do to help you > test any fixes you might come up with. > Cheers! > > On Sat, 2019-03-16 at 18:16 -0500, [email protected] wrote: > > I'd say there's a very good chance of fixing this. The critical issue for > > me is getting the time > > to dig into it. I've been out of this so long that my test setup is boxed > > up somewhere... > > Once I reproduce the problem I think it's pretty likely I can find a fix. > > Odds are that some > > aspects of the USB stack's interface to client drivers has changed in a > > manner that breaks use of > > it by the pvrusb2 driver. It's just a matter of figuring that out and > > dealing with it. Maybe a > > disconnect callback happening in a way now that the driver doesn't expect. > > With this many years > > since the last substantial change, this is certainly possible. > > -Mike > > > > On Sat, 16 Mar 2019, Diego Rivera wrote: > > I'd offer to help fix this but I'm not knowledgeable enough in building > > usbkernel drivers to be of > > much use... > > But any help I can offer is definitely at your disposal. > > Do you think there's any chance of fixing this? > > -- > > Diego Rivera > > On Sat, Mar 16, 2019, 17:08 <[email protected]> wrote: > > > > Based on other messages here (which I just now saw), it looks likethere's > > been a USB stack change > > in the kernel (for who knows how longago) that prevent hot-unplug from > > working. That is supposed > > to work.It used to. Oh joy. > > -Mike > > > > On Sat, 16 Mar 2019, Diego Rivera wrote: > > My bigger concern is why the driver is refusing to give up on > > "bad"devices... > > Also I found a solution for keeping the digital side out of TVH: changethe > > Unix group for dvb devices via udev :) > > I might come up with a more detailed rule only for the 1950s, but for > > nowthat'll do! > > Cheers! > > -- > > Diego Rivera > > On Sat, Mar 16, 2019, 16:27 <[email protected]> wrote: > > > > Short of preventing the digital stuff from being available in thekernel, > > no. The driver is set up > > to always exploit whatever it can... > > Catching up on the other replies... > > > > On Sat, 16 Mar 2019, Diego Rivera wrote: > > Negative on that count either... I unplugged the device and a fewminutes > > later it's still spewing > > out that message.Side question: is there any way to disable the digital > > side of thedriver upon > > launch? Maybe a > > parameter that can be passed in?Thanks for responding, too!! I realize this > > is a stale device but > > Icertainly appreciate your time! > > On Sat, 2019-03-16 at 11:36 -0500, [email protected] wrote: > > OK, now unplug it if you haven't already done so. That shouldbreak > > the connection between the > > driver and the hardware and cause the pvrusb2 driver to eventuallystop > > crabbing and let > > go. That's a scenario that I executed A LOT when debugging thedriver... > > (If that doesn't work then there may be another problem.) -Mike > > On Sat, 16 Mar 2019, Diego Rivera wrote:"On the digital side"... you're > > right! Turns out TVHeadend > > wasgrabbing the digital side of > > thetuners - I'll have to figure out a way to disable that, since Idon't > > need that. That said, > > once Iturned off TVHeadend, modprobe -r no longer complained aboutthe > > module being in > > use.However, it just hung .... and the log is littered with"pvrusb2: > > Attempted to execute > > controltransfer when device not ok"So definitely something's wronghere > > because either the module > > is definitely caring what happens tothe device(s), or something inthe > > overarching kernel > > framework changed that appears to need updateson the module inorder > > to properly comply... maybe > > USB events were removed/modified that the driverexpects for > > correctfunctioning?Just shooting > > blanks here... if there's additional debug information that I canprovide, > > I'll bemore than happy > > to try to rustle that up for you!Cheers!On Sat, 2019-03-16 at 11:26 -0500, > > [email protected] > > wrote:Interesting.The kernel of course will refuse to a remove a > > moduleuntil all references to it go > > away.The USB side of the pvrus2 driver won't (shouldn't) care sophysically > > unplugged the USB > > cable(and doing all manner of USB reset attempts) isn't going tohelp > > (or hurt - the driver > > won'tcare).The problem is not that the driver is referencing theUSB > > port but rather that other > > entities arereferencing the driver. So the first obvious case isto > > ensure nobody has it open > > which youdid. Another thing to look at is to see what if otherkernel > > modules are referencing > > thedriver. This might be happening on the digital side. If yourun > > lsmod to get a list of > > kernelmodules installed you should also see reference counts and alist of > > what other kernel > > modules arecausing that count to be non-zero. If there are othermodules > > listed, then they need > > to beremoved first - lowering the reference count - before you canremove > > the pvrusb2 driver.Yes, > > it's been a long time since I've messed with this driver, sadly,but > > my recollection is > > thatbasically while the pvrusb2 module will reference a lot ofother > > modules to get its job done, > > Ididn't think there was any kernel modules that could reference thepvrusb2 > > driver. When > > thepvrusb2 driver is installed into the running kernel, it will tieitself > > to the other modules > > thatis needs, but when you modprobe -r pvrusb2, it SHOULD undo allthat. > > It's conceivable that > > thesurrounding kernel environment has changed in ways thatinvalidate > > this - though I think if > > thatwere the case I'd see a lot of screaming here :-) (Eitherthat or > > almost nobody is using > > thisanymore...) -MikeOn Fri, 15 Mar 2019, Diego Rivera wrote:Hi!I realize > > it's been MANYyears > > since you've messed with > > this driver, but I figured why not ask?Ifthere's a betterplace/person > > to send this to, please let > > me know and I'll be glad to go knockonthat door instead!Here goes:I > > have a system with two WinTV- > > HVR-1950 devices (long story, still use analog cablehere)which I'vemanaged > > to get working with > > TVHeadend to supply Analog TV support via thedigitalplatform (yay,me! > > ☺).However, I'm running > > into a problem due likely to the age of one of the > > devices(probablystartingto get wonky). Every > > so often one of the devices ceases to function and just "dies".Itneeds tobe > > physically > > disconnected (or the machine rebooted) to get back to workingorder. > > I'vetried manyapproaches to > > reset the USB bus or the device itself via software but none ofthem > > seemto work:* If I try > > "modprobe -r pvrusb2" I get the error that the module is in use(but I > > have nouserprocesses > > actively using any of the pvrusb2 devices! I've made sure!).* If Itry > > to issueUSBDEVFS_DISCONNECT > > or USBDEVFS_RESET commands via IOCTL, neither works and areboot > > isnowrequired.* If I try to reset > > the whole USB bus via /sys/bus/pci/drivers/?hci_hcd/unbind andbind,it > > doesn'twork and a reboot is > > now required* If I try to use/sys/bus/usb/drivers/pvrusb2/unbindand > > bind, it does'nt work and a > > reboot is nowrequiredIn the last 3 cases, syslog ends up litteredwith > > the message "pvrusb2: > > Attempted to executecontroltransfer when device not ok", outputcontinually > > regardless of any > > attempt to rebind. Thissuggeststhat once the device is "not ok"(dead?), > > the driver doesn't > > attempt to clean it up(should it?)Is there any other way to force afull > > reset and > > reinitialization of a pvrusb2 device viasoftwarewithout actuallyhaving to > > disconnect/reconnect > > the device or reboot the machine?Thanks! > > > > > > > > > > > > > > > > > > -- > > Mike Iselyisely @ isely (dot) netPGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 > > B5 F5 C1 > > E8_______________________________________________pvrusb2 mailing > > [email protected] > > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 > > _______________________________________________pvrusb2 mailing > > [email protected] > > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 > > > > -- > > Mike Iselyisely @ isely (dot) netPGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 > > B5 F5 C1 > > E8_______________________________________________pvrusb2 mailing > > [email protected] > > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 > > _______________________________________________pvrusb2 mailing > > [email protected] > > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 > > > > > -- 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
