Re: [pvrusb2] [PATCH] pvrusb2: Fix oops on tear-down when radio support is not present
Sadly, probably not. That appears not to be considered an LTS branch. So if it were to get there, the Ubuntu project would probably have to merge it into their own fork. -Mike On Mon, 16 Dec 2019, Diego Rivera wrote: > I wonder if it will ever make it into the 5.3 branch? This is what the latest > Ubuntu uses, and 20.04 > is still a few months away... > Cheers! > > On Fri, 2019-12-13 at 10:35 -0600, Mike Isely wrote: > > I was cc'ed just a few days ago on pushes of this patch to every stable > > branch. Specifically, > > 4.4, 4.9. 4.14, 4.19, and 5.4. > > So it's getting there. > > -Mike > > On Fri, 13 Dec 2019, Diego Rivera wrote: > > > Hey!! Any news on whether this patch can make it into Stable so it will > > > trickle down?Thanks!On > > > Wed, 2019-11-20 at 12:55 -0600, Mike Isely wrote: > > > > It's already in their pipeline. I'm unclear if reposting that might > > > > foul things up. I will > > > > askabout this. The cc's on the post already were after I checked with > > > > V4L folks about the > > > > currentpush process (it's been a while). -MikeOn Wed, 20 Nov 2019, Jan > > > > Ceuleers wrote: > > > > > On 20/11/2019 19:34, Mike Isely wrote: > > > > > > I posted it to linux-media several weeks ago. Based on email > > > > > > feedback seen in response, > > > > > > it isgood to go. There's nothing being waited for that I know > > > > > > about. At this point the > > > > > > timing ofwhere/when it goes is in the V4L maintainer's hands. > > > > > > > > > > Thanks Mike. Your post entered the annals here: > > > > > https://www.spinics.net/lists/linux-media/msg160029.html > > > > > > > > > > But it seems that you did not cc: stable. Would it be possible for > > > > > youto still do that > > > > > please?Only by doing that will the fix percolate downto distros that > > > > > peope are currently > > > > > using. > > > > > Thanks, Jan___pvrusb2 > > > > > mailing > > > > > listpvru...@isely.net > > > > > 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] [PATCH] pvrusb2: Fix oops on tear-down when radio support is not present
I was cc'ed just a few days ago on pushes of this patch to every stable branch. Specifically, 4.4, 4.9. 4.14, 4.19, and 5.4. So it's getting there. -Mike On Fri, 13 Dec 2019, Diego Rivera wrote: > Hey!! Any news on whether this patch can make it into Stable so it will > trickle down? > Thanks! > On Wed, 2019-11-20 at 12:55 -0600, Mike Isely wrote: > > It's already in their pipeline. I'm unclear if reposting that might foul > > things up. I will ask > > about this. The cc's on the post already were after I checked with V4L > > folks about the current > > push process (it's been a while). > > -Mike > > On Wed, 20 Nov 2019, Jan Ceuleers wrote: > > > On 20/11/2019 19:34, Mike Isely wrote: > > > > I posted it to linux-media several weeks ago. Based on email feedback > > > > seen in response, it is > > > > good to go. There's nothing being waited for that I know about. At > > > > this point the timing of > > > > where/when it goes is in the V4L maintainer's hands. > > > > > > Thanks Mike. Your post entered the annals here: > > > https://www.spinics.net/lists/linux-media/msg160029.html > > > > > > But it seems that you did not cc: stable. Would it be possible for youto > > > still do that please? > > > Only by doing that will the fix percolate downto distros that peope are > > > currently using. > > > > > > Thanks, Jan > > > ___pvrusb2 mailing > > > listpvru...@isely.net > > > 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] [PATCH] pvrusb2: Fix oops on tear-down when radio support is not present
It's already in their pipeline. I'm unclear if reposting that might foul things up. I will ask about this. The cc's on the post already were after I checked with V4L folks about the current push process (it's been a while). -Mike On Wed, 20 Nov 2019, Jan Ceuleers wrote: > On 20/11/2019 19:34, Mike Isely wrote: > > I posted it to linux-media several weeks ago. Based on email feedback > > seen in response, it is good to go. There's nothing being waited for > > that I know about. At this point the timing of where/when it goes is in > > the V4L maintainer's hands. > > Thanks Mike. Your post entered the annals here: > > https://www.spinics.net/lists/linux-media/msg160029.html > > But it seems that you did not cc: stable. Would it be possible for you > to still do that please? Only by doing that will the fix percolate down > to distros that peope are currently using. > > > Thanks, Jan > > ___ > pvrusb2 mailing list > pvrusb2@isely.net > 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] [PATCH] pvrusb2: Fix oops on tear-down when radio support is not present
I posted it to linux-media several weeks ago. Based on email feedback seen in response, it is good to go. There's nothing being waited for that I know about. At this point the timing of where/when it goes is in the V4L maintainer's hands. -Mike On Wed, 20 Nov 2019, Jan Ceuleers wrote: > On 20/11/2019 17:28, Gary Buhrmaster wrote: > > On Tue, Nov 19, 2019 at 9:59 PM Diego Rivera > > wrote: > >> 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? > > Just to set some expectations, I think it > > clearly it is not going in to 5.4, and I would > > not be surprised it misses 5.5 (pull requests > > are already being accepted, although as a > > targeted fix, it might get pulled during the > > rc fix cycle), so 5.6 could be the earliest > > for mainline. 5.5 is expected (around) > > March/April 2020, and 5.6 probably around > > June/July 2020. As to when any specific > > distro will repackage the kernel that > > includes the fix, well, that opens up > > another can of bad estimation. > But if Mike tags the fix for stable (and if that tag is accepted) then > it will be backported to stable kernels as well. > ___ > pvrusb2 mailing list > pvrusb2@isely.net > 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Occasional audio issue with recordings
In general you are correct that it is not possible to unload a module when it's being used by another module. That would cause linkage issues and a likely crash if it were allowed. However the V4L cases here are different, for pretty much all of these chip-level drivers. While logically the pvrusb2 driver is "using" the cx25840 module to do it's job, the physical reality is actually the opposite. The cx25840 module is actually using the pvrusb2 driver. It's the other way around. This makes sense when one realizes that the pvrusb2 driver is supplying a communication path to the cx25840 module so that it can itself reach its corresponding hardware. When the pvrusb2 driver detects new hardware, it figures out which chip-level modules are needed and just requests that the kernel load them. But that's it. It never directly references any of them. Once loaded, the modules will enumerate attached I2C adapters (for which the pvrusb2 driver is one such instance) and then bind to that adapter. So the dependency relationship is actually cx25840 -> pvrusb2, not pvrusb2 -> cx25840. Any activity from the pvrusb2 driver to one of those bound modules generally works through a publish/subscribe approach. So again the bindings work in the opposite direction you might otherwise assume. Thus you can (or, well, "should be able to") actually unload the cx25840 module at any time. Obviously the corresponding functionality will cease when this happens but the pvrusb2 driver generally won't care (or even notice). When the module reappears and rebinds, the pvrusb2 driver will republish appropriate state to it at that point, bringing things back into sync. This sort of thing I used to do a lot of when testing changes in the driver. -Mike On Tue, 5 Nov 2019, Jan Ceuleers wrote: > On 05/11/2019 05:02, Mike Isely wrote: > > With that knowledge, see if unloading / reloading the cx25840 module > > might affect the issue. (And that should actually work right now.) > > Also, you might want to see if there's a different firmware image > > floating around for that part. > > Thanks Mike. I'll experiment with that when the problem reoccurs. > > I didn't think it was possible to unload a module that is being used by > other modules, but as I said I'll give that a go either when I have to > (issue has reoccurred) or when the backend is free for my experimentation. > > root@dracor:~# lsmod | grep cx25 > cx25840 143360 2 > v4l2_common 16384 4 cx2341x,pvrusb2,cx25840,tuner > videodev 188416 5 cx2341x,v4l2_common,pvrusb2,cx25840,tuner > media 40960 3 videodev,cx25840,tuner > > Regarding firmware: we had that discussion back in April when I started > a thread on the subject of "Noise". > > Thx, Jan > > > ___ > pvrusb2 mailing list > pvrusb2@isely.net > 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Occasional audio issue with recordings
Jan: This might be something involving the cx25840 chip-level driver which is part of V4L. That corresponds to the part of the device which processes audio. It's also the point in the hardware where line-in analog video meets up with demodulated audio - so if you are seeing a problem with line-in but not an RF source then it's either got to be this chip or something in front of it. There may be an ADC upstream of that part for the line-in for the HVR1950 but it's been so long that I don't specifically recall. In any case, the pvrusb2 driver doesn't do the actual "processing"; it just sets up the dataflows via the various chip-level drivers. With that knowledge, see if unloading / reloading the cx25840 module might affect the issue. (And that should actually work right now.) Also, you might want to see if there's a different firmware image floating around for that part. -Mike On Mon, 4 Nov 2019, Jan Ceuleers wrote: > Dear pvrusb2 list, > > Ever so often one of my HVR1950 tuners, which records from a > directly-connected set-top box, gets into a state where audio is damaged > such that it cannot be played using either MythTV nor MPlayer. Video is > fine, but audio is damaged. > > A sample can be found here: > > https://gofile.io/?c=DQSKjQ > > Judging by the loud click when starting playback, along with the > occasional crackling that can be heard it sounds as if a large DC offset > has been added to the audio signal such that the audio decoder's output > is saturated. But that's just an assumption. > > The only way to recover is to reboot -- when the driver once again > becomes removable I'm sure an rmmod/modprobe cycle will be enough. That > is: it is not necessary also to power cycle the tuner itself. > > I have already excluded the possibility of these symptoms being caused > by an iffy power supply. > > Any hints would be gratefully received. > > Best regards, Jan > > ___ > pvrusb2 mailing list > pvrusb2@isely.net > 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] [PATCH] pvrusb2: Fix oops on tear-down when radio support is not present
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 on
> boot since. I get a nagging feeling that it's the same thing happening on
> bootup, only when the
> kernel 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 say
> would 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 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
> > >
Re: [pvrusb2] [PATCH] pvrusb2: Fix oops on tear-down when radio support is not present
If I can get independent confirmation that this definitely helps
matters, I will post the patch upstream. Just being absolutely
paranoid...
-Mike
On Sun, 27 Oct 2019, Mike Isely wrote:
> In some device configurations there's no radio or radio support in the
> driver. That's OK, as the driver sets itself up accordingly. However
> on tear-down in these caes it's still trying to tear down radio
> related context when there isn't anything there, leading to
> dereferences through a null pointer and chaos follows.
>
> How this bug survived unfixed for 11 years in the pvrusb2 driver is a mystery
> to me.
>
> Signed-off-by: Mike Isely
> ---
> drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> index aa4fbc3e88cc..0a831849a2b0 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> @@ -909,8 +909,11 @@ static void pvr2_v4l2_internal_check(struct pvr2_channel
> *chp)
> pvr2_v4l2_dev_disassociate_parent(vp->dev_video);
> pvr2_v4l2_dev_disassociate_parent(vp->dev_radio);
> if (!list_empty(>dev_video->devbase.fh_list) ||
> - !list_empty(>dev_radio->devbase.fh_list))
> + ((vp->dev_radio != NULL) &&
> + !list_empty(>dev_radio->devbase.fh_list))) {
> + pvr2_trace(PVR2_TRACE_STRUCT,"pvr2_v4l2 internal_check
> exit-empty id=%p",vp);
> return;
> + }
> pvr2_v4l2_destroy_no_lock(vp);
> }
>
> @@ -946,7 +949,8 @@ static int pvr2_v4l2_release(struct file *file)
> kfree(fhp);
> if (vp->channel.mc_head->disconnect_flag &&
> list_empty(>dev_video->devbase.fh_list) &&
> - list_empty(>dev_radio->devbase.fh_list)) {
> + ((vp->dev_radio == NULL) ||
> + list_empty(>dev_radio->devbase.fh_list))) {
> pvr2_v4l2_destroy_no_lock(vp);
> }
> return 0;
> --
> 2.20.1
> ___
> pvrusb2 mailing list
> pvrusb2@isely.net
> 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
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
[pvrusb2] [PATCH] pvrusb2: Fix oops on tear-down when radio support is not present
In some device configurations there's no radio or radio support in the
driver. That's OK, as the driver sets itself up accordingly. However
on tear-down in these caes it's still trying to tear down radio
related context when there isn't anything there, leading to
dereferences through a null pointer and chaos follows.
How this bug survived unfixed for 11 years in the pvrusb2 driver is a mystery
to me.
Signed-off-by: Mike Isely
---
drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
index aa4fbc3e88cc..0a831849a2b0 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
@@ -909,8 +909,11 @@ static void pvr2_v4l2_internal_check(struct pvr2_channel
*chp)
pvr2_v4l2_dev_disassociate_parent(vp->dev_video);
pvr2_v4l2_dev_disassociate_parent(vp->dev_radio);
if (!list_empty(>dev_video->devbase.fh_list) ||
- !list_empty(>dev_radio->devbase.fh_list))
+ ((vp->dev_radio != NULL) &&
+!list_empty(>dev_radio->devbase.fh_list))) {
+ pvr2_trace(PVR2_TRACE_STRUCT,"pvr2_v4l2 internal_check
exit-empty id=%p",vp);
return;
+ }
pvr2_v4l2_destroy_no_lock(vp);
}
@@ -946,7 +949,8 @@ static int pvr2_v4l2_release(struct file *file)
kfree(fhp);
if (vp->channel.mc_head->disconnect_flag &&
list_empty(>dev_video->devbase.fh_list) &&
- list_empty(>dev_radio->devbase.fh_list)) {
+ ((vp->dev_radio == NULL) ||
+list_empty(>dev_radio->devbase.fh_list))) {
pvr2_v4l2_destroy_no_lock(vp);
}
return 0;
--
2.20.1
___
pvrusb2 mailing list
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Ability to fully reset a PVRUSB2 Device
Diego: I was *finally* able to reproduce the precise kernel oops you got. I had to load the exact same Ubuntu kernel you are using and the test had to run specifically against an HVR-1950. The older (simpler) device I had been trying won't fail. But with that said, I got your exact call trace. Now that I see the signature, I immediately tested again using a 5.2.13 kernel.org vanilla kernel that is larded full of printk() statements in the driver, again on an HVR-1950. And it blew chunks again. The signature wasn't precisely the same (stack trace is slightly different) but it's close enough that I believe it's the same root cause. Now the real digging starts. Note: This is ignoring the sysfs tear-down collision I had mentioned earlier (which, interestingly didn't happen this time, probably because this oops stopped the tear-down before it got that far). This is also with the external userspace I2C access disabled so I can keep that source of log noise out of the way, for now. So there's really 3 issues here. Trying to focus on the one that is burning you specifically. If it turns out that what I'm seeing in the 5.2.13 kernel is actually different, well then that just means there are 4 problems :-( But right now I'm betting it's the same so that's the avenue I'm going to chase. If I run aground, then I'm going to backtrack to that specific Ubuntu kernel and rebuild it with all my debug code added and other config tweaks to help with chasing the problem. -Mike On Wed, 9 Oct 2019, Diego Rivera wrote: > Ok so it turns out it was much easier than expected ☺ > I have a VM now which "houses" both pvrusb2 devices, so if I have to bounce > anything it's now just a > VM. I also have scripts in the host that make it easy to detect when those > devices are acting up, > and bounce the VM accordingly. My next step may be to find a > computer-controllable relay of some > sort that I can power on/off the HVR-1950's when I detect they've died, for > automatic recovery. > But that's a project I have to leave for the weekend as I've neglected work > too much already > Cheers! > > On Tue, 2019-10-08 at 21:59 -0600, Diego Rivera wrote: > > In the mean time, this weekend I'm going to try something that it just > > occurred to me was within > > my reach: use KVM to encapsulate each device. Thus, if they bork, I only > > restart a "small"(ish) VM > > instead of the whole box. I just need to figure out a way to block the > > host from starting up the > > devices. Blacklisting pvrusb2 didn't seem to work, so I may have to simply > > remove the module > > altogether. > > But I'll try that in the weekend. > > Cheers!-- > > > > > > > > Diego Rivera > > > > On Tue, 2019-10-08 at 22:49 -0500, Mike Isely wrote: > > > This is proving to be a multi-faceted issue. > > > First, there's the infinite attempts at using the I2C interface from > > > userspace when the device > > > is unplugged. This is happening from outside the kernel and I need a > > > means to permanently shut > > > that up - killing the daemon sourcing this is only a workaround. But > > > that's a sideshow. > > > The issue I spent several days chasing involved the apparent chain of > > > kernel oopses that happen > > > when the device is unplugged. Turns out this is because when the driver > > > is disconnecting itself > > > from sysfs it's getting errors because something else outside of the > > > driver (apparently) did all > > > the disconnects already. This is really not right, as the driver take > > > care to undo what it > > > previously did when tearing down and somebody is not playing nice here. > > > There's one oops logged > > > for every sysfs endpoint being removed thus the reason for the cluster. > > > Another clue here is > > > that I'm also seeing similar failures from other V4L chip-level drivers > > > outside of the pvrusb2 > > > driver (which are connected to the pvrusb2 driver) triggering the same > > > problem in their own > > > sandboxes. And a few days ago going through my old e-mail I found a > > > discussion thread about > > > this - last Feb/Mar with people there equally puzzled. The last post > > > there seemed to pin the > > > blame on the pvrusb2 driver, but I think right now the pvrusb2 driver is > > > more of a victim than a > > > culprit. In any case I have to find a way to stop that behavior and > > > haven't found it yet. > > > Unfortunately I don't think that's actually the problem you hit. That >
Re: [pvrusb2] Ability to fully reset a PVRUSB2 Device
This is proving to be a multi-faceted issue. First, there's the infinite attempts at using the I2C interface from userspace when the device is unplugged. This is happening from outside the kernel and I need a means to permanently shut that up - killing the daemon sourcing this is only a workaround. But that's a sideshow. The issue I spent several days chasing involved the apparent chain of kernel oopses that happen when the device is unplugged. Turns out this is because when the driver is disconnecting itself from sysfs it's getting errors because something else outside of the driver (apparently) did all the disconnects already. This is really not right, as the driver take care to undo what it previously did when tearing down and somebody is not playing nice here. There's one oops logged for every sysfs endpoint being removed thus the reason for the cluster. Another clue here is that I'm also seeing similar failures from other V4L chip-level drivers outside of the pvrusb2 driver (which are connected to the pvrusb2 driver) triggering the same problem in their own sandboxes. And a few days ago going through my old e-mail I found a discussion thread about this - last Feb/Mar with people there equally puzzled. The last post there seemed to pin the blame on the pvrusb2 driver, but I think right now the pvrusb2 driver is more of a victim than a culprit. In any case I have to find a way to stop that behavior and haven't found it yet. Unfortunately I don't think that's actually the problem you hit. That whole thing was a decoy for me. Having burned through that I believe you're hitting something else - which I haven't been able to reproduce yet. But I have the logs you sent and will be reviewing that again now in light of the above. Also, I was testing at the time with older hardware which doesn't have all the bells and whistles of the HVR-1950 - no DVB side - which meant less of the driver was involved. I had done that thinking I was already reproducing your issue and was trying to simplify the scenario. Suspecting otherwise now, I've switched to an HVR-1950 and have gone back to trying to reliably reproduce the issue. That was about 2 weeks ago. Then I got my chain yanked in 3 other directions. But I'm almost dug out of all that and will be circling back to this issue, hopefully this weekend, which is looking to be comparatively quiet. Please DO keep pinging me. -Mike On Sun, 6 Oct 2019, Diego Rivera wrote: > Hey, Mike! > Any luck? Did my dumps help you out at all? Just poking to see if you had the > chance to continue > working on this. > Cheers! > > On Sun, 2019-09-22 at 15:04 -0500, Mike Isely wrote: > > Thank you! > > -Mike > > On Sun, 22 Sep 2019, Diego Rivera wrote: > > > As requested--*Diego Rivera* > > > > > > On Sun, Sep 22, 2019 at 1:53 PM Mike Isely wrote: > > > > Ugh. This is line-wrapped to hell-and-back. Can you resend that as > > > > afile attachment? > > > > -Mike > > > > On Sun, 22 Sep 2019, Diego Rivera wrote: > > > > > This is what kern.log shows when I hot-unplug/hot-poweroff one of > > > > > thedevices: > > > > > Sep 22 13:36:05 tvserver kernel: [ 156.265825] usb 1-4: USB > > > > > disconnect,device number 8Sep > > > > > 22 13:36:05 tvserver kernel: [ 156.266059] pvrusb2: Device > > > > > beingrendered inoperableSep 22 > > > > > 13:36:05 tvserver kernel: [ 156.266162] BUG: unable to handlekernel > > > > > NULL pointer > > > > > dereference at 0520Sep 22 13:36:05 tvserver kernel: [ > > > > > 156.266299] #PF error: > > > > > [normal kernelread fault]Sep 22 13:36:05 tvserver kernel: [ > > > > > 156.266376] PGD 0 P4D 0Sep 22 > > > > > 13:36:05 tvserver kernel: [ 156.266424] Oops: [#1] SMP PTISep > > > > > 22 13:36:05 tvserver > > > > > kernel: [ 156.266485] CPU: 0 PID: 2190 Comm:pvrusb2-context Not > > > > > tainted 5.0.0-29-generic > > > > > #31-UbuntuSep 22 13:36:05 tvserver kernel: [ 156.266610] Hardware > > > > > name: To Be > > > > Filled > > > > > By O.E.M. To Be Filled By O.E.M./Q1900-ITX, BIOS P1.70 03/31/2016Sep > > > > > 22 13:36:05 tvserver > > > > > kernel: [ 156.266770] RIP:0010:pvr2_v4l2_internal_check+0x47/0x70 > > > > > [pvrusb2]Sep 22 13:36:05 > > > > > tvserver kernel: [ 156.266867] Code: 2f e4 ff ff 48 8b > > > > 7b > > > > > 40 e8 26 e4 ff ff 48 8b 43 38 48 8b 90 20 05 00 00 48 05 20 05 00 00 > > > > > 48 > > > > 39 > > > > > d0 7
Re: [pvrusb2] Ability to fully reset a PVRUSB2 Device
Thank you! -Mike On Sun, 22 Sep 2019, Diego Rivera wrote: > As requested > -- > *Diego Rivera* > > > On Sun, Sep 22, 2019 at 1:53 PM Mike Isely wrote: > > > > > Ugh. This is line-wrapped to hell-and-back. Can you resend that as a > > file attachment? > > > > -Mike > > > > On Sun, 22 Sep 2019, Diego Rivera wrote: > > > > > This is what kern.log shows when I hot-unplug/hot-poweroff one of the > > > devices: > > > > > > Sep 22 13:36:05 tvserver kernel: [ 156.265825] usb 1-4: USB disconnect, > > > device number 8 > > > Sep 22 13:36:05 tvserver kernel: [ 156.266059] pvrusb2: Device being > > > rendered inoperable > > > Sep 22 13:36:05 tvserver kernel: [ 156.266162] BUG: unable to handle > > > kernel NULL pointer dereference at 0520 > > > Sep 22 13:36:05 tvserver kernel: [ 156.266299] #PF error: [normal kernel > > > read fault] > > > Sep 22 13:36:05 tvserver kernel: [ 156.266376] PGD 0 P4D 0 > > > Sep 22 13:36:05 tvserver kernel: [ 156.266424] Oops: [#1] SMP PTI > > > Sep 22 13:36:05 tvserver kernel: [ 156.266485] CPU: 0 PID: 2190 Comm: > > > pvrusb2-context Not tainted 5.0.0-29-generic #31-Ubuntu > > > Sep 22 13:36:05 tvserver kernel: [ 156.266610] Hardware name: To Be > > Filled > > > By O.E.M. To Be Filled By O.E.M./Q1900-ITX, BIOS P1.70 03/31/2016 > > > Sep 22 13:36:05 tvserver kernel: [ 156.266770] RIP: > > > 0010:pvr2_v4l2_internal_check+0x47/0x70 [pvrusb2] > > > Sep 22 13:36:05 tvserver kernel: [ 156.266867] Code: 2f e4 ff ff 48 8b > > 7b > > > 40 e8 26 e4 ff ff 48 8b 43 38 48 8b 90 20 05 00 00 48 05 20 05 00 00 48 > > 39 > > > d0 74 03 5b 5d c3 48 8b 43 40 <48> 8b 90 20 05 00 00 48 05 20 05 00 00 48 > > > 39 d0 75 e7 48 89 df e8 > > > Sep 22 13:36:05 tvserver kernel: [ 156.267140] RSP: > > 0018:b4f3c262fea0 > > > EFLAGS: 00010246 > > > Sep 22 13:36:05 tvserver kernel: [ 156.267223] RAX: > > RBX: > > > 9112efad8ba0 RCX: > > > Sep 22 13:36:05 tvserver kernel: [ 156.267331] RDX: 9112ee80cd20 > > RSI: > > > RDI: > > > Sep 22 13:36:05 tvserver kernel: [ 156.267439] RBP: b4f3c262fea8 > > R08: > > > R09: 9112ed60c618 > > > Sep 22 13:36:05 tvserver kernel: [ 156.267546] R10: f000 > > R11: > > > 002462016bed R12: 9112ef474000 > > > Sep 22 13:36:05 tvserver kernel: [ 156.267653] R13: c108ba90 > > R14: > > > R15: 9112f36ed700 > > > Sep 22 13:36:05 tvserver kernel: [ 156.267761] FS: > > () > > > GS:9112f820() knlGS: > > > Sep 22 13:36:05 tvserver kernel: [ 156.267880] CS: 0010 DS: ES: > > > > > CR0: 80050033 > > > Sep 22 13:36:05 tvserver kernel: [ 156.267968] CR2: 0520 > > CR3: > > > 00014820e000 CR4: 001006f0 > > > Sep 22 13:36:05 tvserver kernel: [ 156.268074] Call Trace: > > > Sep 22 13:36:05 tvserver kernel: [ 156.268136] > > > pvr2_context_thread_func+0xc4/0x2b0 [pvrusb2] > > > Sep 22 13:36:05 tvserver kernel: [ 156.268227] ? wait_woken+0x80/0x80 > > > Sep 22 13:36:05 tvserver kernel: [ 156.268290] kthread+0x120/0x140 > > > Sep 22 13:36:05 tvserver kernel: [ 156.268362] ? > > > pvr2_context_destroy+0xc0/0xc0 [pvrusb2] > > > Sep 22 13:36:05 tvserver kernel: [ 156.268449] ? > > > __kthread_parkme+0x70/0x70 > > > Sep 22 13:36:05 tvserver kernel: [ 156.268518] ret_from_fork+0x35/0x40 > > > Sep 22 13:36:05 tvserver kernel: [ 156.268578] Modules linked in: > > s5h1411 > > > tda18271 tda8290 tuner cx25840 pvrusb2 tveeprom cx2341x dvb_core > > > v4l2_common videodev media veth xt_nat ipt_MASQUERADE xfrm_user xfrm_algo > > > br_netfilter bridge stp llc xt_recent ipt_REJECT nf_reject_ipv4 xt_limit > > > xt_comment xt_multiport xt_conntrack xt_hashlimit xt_addrtype xt_mark > > > iptable_mangle xt_tcpudp xt_CT iptable_raw nfnetlink_log xt_NFLOG > > > nf_log_ipv4 nf_log_common xt_LOG nf_conntrack_sane nf_conntrack_netlink > > > nfnetlink nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip > > > nf_nat_pptp nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda > > > nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp > > nf_conntrack_proto_gre > > > nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack
Re: [pvrusb2] Ability to fully reset a PVRUSB2 Device
I picked through it. That's a crash when the driver was trying to untangle itself from the V4L interface. Different problem than the oopses I've been seeing. So far I have not seen this one happen here, but I'm running a 5.2.13 vanilla kernel checked out from git (no distro patches). I think right now I'm going to concentrate on the issues I can produce. Summary right now: 1. I2C access infinite loop caused by traffic from ir_kbd_i2c when the hardware is hot-unplugged. Disabling that module works around this issue. While not a solution that at least clears the air for the other issues... 2. Kernel oopses (not crashes) coming from attempts to remove sysfs controls during tear-down, which appears to be a case of something else doing the removal at the same time out from under the driver. 3. (Haven't reproduced yet) Kernel oops coming from the V4L2 side of the driver when tearing down. 4. (Haven't reproduced yet) Kernel panic on driver removal. 5. Process hang when trying to modprobe -r pvrusb2, under not-understood yet circumstances. (By process hang, what I mean is that the process which is running modprobe -r pvrusb2 never finishes, can't be interrupted, and the rest of the system seems to continue operating ok.) -Mike On Sun, 22 Sep 2019, Mike Isely wrote: > > Ugh. This is line-wrapped to hell-and-back. Can you resend that as a > file attachment? > > -Mike > > On Sun, 22 Sep 2019, Diego Rivera wrote: > > > This is what kern.log shows when I hot-unplug/hot-poweroff one of the > > devices: > > > > Sep 22 13:36:05 tvserver kernel: [ 156.265825] usb 1-4: USB disconnect, > > device number 8 > > Sep 22 13:36:05 tvserver kernel: [ 156.266059] pvrusb2: Device being > > rendered inoperable > > Sep 22 13:36:05 tvserver kernel: [ 156.266162] BUG: unable to handle > > kernel NULL pointer dereference at 0520 > > Sep 22 13:36:05 tvserver kernel: [ 156.266299] #PF error: [normal kernel > > read fault] > > Sep 22 13:36:05 tvserver kernel: [ 156.266376] PGD 0 P4D 0 > > Sep 22 13:36:05 tvserver kernel: [ 156.266424] Oops: [#1] SMP PTI > > Sep 22 13:36:05 tvserver kernel: [ 156.266485] CPU: 0 PID: 2190 Comm: > > pvrusb2-context Not tainted 5.0.0-29-generic #31-Ubuntu > > Sep 22 13:36:05 tvserver kernel: [ 156.266610] Hardware name: To Be Filled > > By O.E.M. To Be Filled By O.E.M./Q1900-ITX, BIOS P1.70 03/31/2016 > > Sep 22 13:36:05 tvserver kernel: [ 156.266770] RIP: > > 0010:pvr2_v4l2_internal_check+0x47/0x70 [pvrusb2] > > Sep 22 13:36:05 tvserver kernel: [ 156.266867] Code: 2f e4 ff ff 48 8b 7b > > 40 e8 26 e4 ff ff 48 8b 43 38 48 8b 90 20 05 00 00 48 05 20 05 00 00 48 39 > > d0 74 03 5b 5d c3 48 8b 43 40 <48> 8b 90 20 05 00 00 48 05 20 05 00 00 48 > > 39 d0 75 e7 48 89 df e8 > > Sep 22 13:36:05 tvserver kernel: [ 156.267140] RSP: 0018:b4f3c262fea0 > > EFLAGS: 00010246 > > Sep 22 13:36:05 tvserver kernel: [ 156.267223] RAX: RBX: > > 9112efad8ba0 RCX: > > Sep 22 13:36:05 tvserver kernel: [ 156.267331] RDX: 9112ee80cd20 RSI: > > RDI: > > Sep 22 13:36:05 tvserver kernel: [ 156.267439] RBP: b4f3c262fea8 R08: > > R09: 9112ed60c618 > > Sep 22 13:36:05 tvserver kernel: [ 156.267546] R10: f000 R11: > > 002462016bed R12: 9112ef474000 > > Sep 22 13:36:05 tvserver kernel: [ 156.267653] R13: c108ba90 R14: > > R15: 9112f36ed700 > > Sep 22 13:36:05 tvserver kernel: [ 156.267761] FS: () > > GS:9112f820() knlGS: > > Sep 22 13:36:05 tvserver kernel: [ 156.267880] CS: 0010 DS: ES: > > CR0: 80050033 > > Sep 22 13:36:05 tvserver kernel: [ 156.267968] CR2: 0520 CR3: > > 00014820e000 CR4: 001006f0 > > Sep 22 13:36:05 tvserver kernel: [ 156.268074] Call Trace: > > Sep 22 13:36:05 tvserver kernel: [ 156.268136] > > pvr2_context_thread_func+0xc4/0x2b0 [pvrusb2] > > Sep 22 13:36:05 tvserver kernel: [ 156.268227] ? wait_woken+0x80/0x80 > > Sep 22 13:36:05 tvserver kernel: [ 156.268290] kthread+0x120/0x140 > > Sep 22 13:36:05 tvserver kernel: [ 156.268362] ? > > pvr2_context_destroy+0xc0/0xc0 [pvrusb2] > > Sep 22 13:36:05 tvserver kernel: [ 156.268449] ? > > __kthread_parkme+0x70/0x70 > > Sep 22 13:36:05 tvserver kernel: [ 156.268518] ret_from_fork+0x35/0x40 > > Sep 22 13:36:05 tvserver kernel: [ 156.268578] Modules linked in: s5h1411 > > tda18271 tda8290 tuner cx25840 pvrusb2 tveeprom cx2341x dvb_core > > v4l2_common videodev media veth xt_nat ipt_MASQUERADE xfrm_u
Re: [pvrusb2] Ability to fully reset a PVRUSB2 Device
801 libahci > realtek i2c_hid video hid > Sep 22 13:36:05 tvserver kernel: [ 156.270831] CR2: 0520 > Sep 22 13:36:05 tvserver kernel: [ 156.270891] ---[ end trace > 5d13378174849ef9 ]--- > Sep 22 13:36:05 tvserver kernel: [ 156.270988] RIP: > 0010:pvr2_v4l2_internal_check+0x47/0x70 [pvrusb2] > Sep 22 13:36:05 tvserver kernel: [ 156.271089] Code: 2f e4 ff ff 48 8b 7b > 40 e8 26 e4 ff ff 48 8b 43 38 48 8b 90 20 05 00 00 48 05 20 05 00 00 48 39 > d0 74 03 5b 5d c3 48 8b 43 40 <48> 8b 90 20 05 00 00 48 05 20 05 00 00 48 > 39 d0 75 e7 48 89 df e8 > Sep 22 13:36:05 tvserver kernel: [ 156.271363] RSP: 0018:b4f3c262fea0 > EFLAGS: 00010246 > Sep 22 13:36:05 tvserver kernel: [ 156.271447] RAX: RBX: > 9112efad8ba0 RCX: > Sep 22 13:36:05 tvserver kernel: [ 156.271556] RDX: 9112ee80cd20 RSI: > RDI: > Sep 22 13:36:05 tvserver kernel: [ 156.271665] RBP: b4f3c262fea8 R08: > R09: 9112ed60c618 > Sep 22 13:36:05 tvserver kernel: [ 156.271773] R10: f000 R11: > 002462016bed R12: 9112ef474000 > Sep 22 13:36:05 tvserver kernel: [ 156.271882] R13: c108ba90 R14: > R15: 9112f36ed700 > Sep 22 13:36:05 tvserver kernel: [ 156.271990] FS: () > GS:9112f820() knlGS: > Sep 22 13:36:05 tvserver kernel: [ 156.272111] CS: 0010 DS: ES: > CR0: 80050033 > Sep 22 13:36:05 tvserver kernel: [ 156.272201] CR2: 0520 CR3: > 00014820e000 CR4: 001006f0 > Sep 22 13:36:10 tvserver kernel: [ 161.084276] usb 1-4: new high-speed USB > device number 9 using xhci_hcd > Sep 22 13:36:10 tvserver kernel: [ 161.236211] usb 1-4: New USB device > found, idVendor=2040, idProduct=7501, bcdDevice= 8.00 > Sep 22 13:36:10 tvserver kernel: [ 161.236349] usb 1-4: New USB device > strings: Mfr=1, Product=2, SerialNumber=3 > Sep 22 13:36:10 tvserver kernel: [ 161.236458] usb 1-4: Product: WinTV > Sep 22 13:36:10 tvserver kernel: [ 161.236516] usb 1-4: Manufacturer: > Hauppauge > Sep 22 13:36:10 tvserver kernel: [ 161.236584] usb 1-4: SerialNumber: > 7300-00-F080EDCF > Sep 22 13:36:10 tvserver kernel: [ 161.239374] pvrusb2: Hardware > description: WinTV HVR-1950 Model 751xx > > Cheers! > -- > *Diego Rivera* > > > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon> > Virus-free. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > On Sun, Sep 22, 2019 at 12:42 PM Mike Isely wrote: > > > On Sun, 22 Sep 2019, Mike Isely wrote: > > > > > > > > On Sun, 14 Apr 2019, Diego Rivera wrote: > > > > > > > Guinea pig #1 ready, sir! > > > > > > > > -- > > > > > > > > Diego Rivera > > > > > > > > > > Diego: > > > > > > Going back over this thread and comparing my recent notes, there's a > > > good experiment I'd like you to try: Get the hardware into a state > > > where you get the "Attempted to execute control transfer when device not > > > ok" infinite log spew. Once you've confirmed the scenario again, reboot > > > the host and then rename the ir-kbd-i2c.ko module to something which > > > disables it. You can find this module in the following path: > > > > > > /lib/modules/`uname -r`/krtnrl/drivers/media/i2c/ > > > > Typo correction: > > > > /lib/modules/`uname -r`/kernel/drivers/media/i2c/ > > > > (fingers in wrong position on keyboard, apparently) > > > > > > > > > > A good thing to do would be to just add "-disabled" to the end of the > > > file name. Then run "depmod -a" to rebuild the module dependencies > > > (should take a few seconds) and now the ir-kbd-i2c module will be > > > disabled. On the off-chance that it has already been loaded, also run > > > "modprobe -r ir_kbd_ic2" (or just reboot again). NOW, run that same > > > scenario where you get the log spew as mentioned above. Is that still > > > happening? Also, if it isn't still happening, does "modprobe -r > > > pvrusb2" still get stuck? > > > > > > The reason I ask is because that's what I am seeing here. That > > > ir-kbd-i2c here is the source of the endless stream of failing I2C > > > requests into the pvrusb2 driver. I want to make sure we're looking at
Re: [pvrusb2] Ability to fully reset a PVRUSB2 Device
Thanks. What you are illustrating is at least two problems. The log spew is definitely not the same issue as the hang-on-remove. I'm also looking at what is going on in sysfs when the device is hot-unplugged. In that case I'm getting a kernel oops for each sysfs control (/sys/class/pvrusb2/sn-x/ctl_*) being removed. Looks like something else is removing these controls in a race with the driver. This might be a kobject reference count issue. -Mike On Sun, 22 Sep 2019, Diego Rivera wrote: > Test carried out. If I disable the ir-kbd-i2c module, everything appears to > boot up well enough, and the " Attempted to execute control transfer when > device not ok" spam is no more!! So that's the good news. > > The bad news is that modprobe -r pvrusb2 doesn't succeed either - it just > hangs there. > > This is my Kernel version (on Ubuntu 19.04): 5.0.0-29-generic. It's the > default OOTB (latest update) kernel. I've attached the configuration as > requested. > > The scenario isn't 100% reproducible, but the way I usually do it is either > by rmmod/modprobe -r, hot-unplug/replug, or power off one of the devices > while connected, and powering it back on (this seems to be the most > frequent scenario, due to power spikes/fluctiations, etc). > > For this test, I just did the modprobe -r. I'll test the other two > scenarios and report back shortly. > > Cheers! > > -- > *Diego Rivera* > > > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon> > Virus-free. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > On Sun, Sep 22, 2019 at 12:42 PM Mike Isely wrote: > > > On Sun, 22 Sep 2019, Mike Isely wrote: > > > > > > > > On Sun, 14 Apr 2019, Diego Rivera wrote: > > > > > > > Guinea pig #1 ready, sir! > > > > > > > > -- > > > > > > > > Diego Rivera > > > > > > > > > > Diego: > > > > > > Going back over this thread and comparing my recent notes, there's a > > > good experiment I'd like you to try: Get the hardware into a state > > > where you get the "Attempted to execute control transfer when device not > > > ok" infinite log spew. Once you've confirmed the scenario again, reboot > > > the host and then rename the ir-kbd-i2c.ko module to something which > > > disables it. You can find this module in the following path: > > > > > > /lib/modules/`uname -r`/krtnrl/drivers/media/i2c/ > > > > Typo correction: > > > > /lib/modules/`uname -r`/kernel/drivers/media/i2c/ > > > > (fingers in wrong position on keyboard, apparently) > > > > > > > > > > A good thing to do would be to just add "-disabled" to the end of the > > > file name. Then run "depmod -a" to rebuild the module dependencies > > > (should take a few seconds) and now the ir-kbd-i2c module will be > > > disabled. On the off-chance that it has already been loaded, also run > > > "modprobe -r ir_kbd_ic2" (or just reboot again). NOW, run that same > > > scenario where you get the log spew as mentioned above. Is that still > > > happening? Also, if it isn't still happening, does "modprobe -r > > > pvrusb2" still get stuck? > > > > > > The reason I ask is because that's what I am seeing here. That > > > ir-kbd-i2c here is the source of the endless stream of failing I2C > > > requests into the pvrusb2 driver. I want to make sure we're looking at > > > the same bug. I've got roughly 3 misbehaviors on my plate right now. > > > This is one of them. > > > > > > There was an earlier mention of a kernel panic when trying to remove the > > > pvrusb2 driver from the system. While I am seeing kernel oopses from > > > this - due to sysfs doing something unexpected - it is not panicing. > > > So I have not yet seen that specific problem. I'd like to know what > > > exact kernel was being run (distro / uname -r output / .config would > > > help too). > > > > > > -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 > > > pvrusb2@isely.net > > > 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 > > pvrusb2@isely.net > > 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Ability to fully reset a PVRUSB2 Device
Never mind. That reply had been caught in the moderator queue. -Mike On Sun, 22 Sep 2019, Mike Isely wrote: > > What about the case I described with the infinite log spew involving > infinite series of "...control transefer when device not ok"? This one > was one of the cases you were pointing out way back. > > -Mike > > > On Sun, 22 Sep 2019, Diego Rivera wrote: > > > This is what kern.log shows when I hot-unplug/hot-poweroff one of the > > devices: > > > > Sep 22 13:36:05 tvserver kernel: [ 156.265825] usb 1-4: USB disconnect, > > device number 8 > > Sep 22 13:36:05 tvserver kernel: [ 156.266059] pvrusb2: Device being > > rendered inoperable > > Sep 22 13:36:05 tvserver kernel: [ 156.266162] BUG: unable to handle > > kernel NULL pointer dereference at 0520 > > Sep 22 13:36:05 tvserver kernel: [ 156.266299] #PF error: [normal kernel > > read fault] > > Sep 22 13:36:05 tvserver kernel: [ 156.266376] PGD 0 P4D 0 > > Sep 22 13:36:05 tvserver kernel: [ 156.266424] Oops: [#1] SMP PTI > > Sep 22 13:36:05 tvserver kernel: [ 156.266485] CPU: 0 PID: 2190 Comm: > > pvrusb2-context Not tainted 5.0.0-29-generic #31-Ubuntu > > Sep 22 13:36:05 tvserver kernel: [ 156.266610] Hardware name: To Be Filled > > By O.E.M. To Be Filled By O.E.M./Q1900-ITX, BIOS P1.70 03/31/2016 > > Sep 22 13:36:05 tvserver kernel: [ 156.266770] RIP: > > 0010:pvr2_v4l2_internal_check+0x47/0x70 [pvrusb2] > > Sep 22 13:36:05 tvserver kernel: [ 156.266867] Code: 2f e4 ff ff 48 8b 7b > > 40 e8 26 e4 ff ff 48 8b 43 38 48 8b 90 20 05 00 00 48 05 20 05 00 00 48 39 > > d0 74 03 5b 5d c3 48 8b 43 40 <48> 8b 90 20 05 00 00 48 05 20 05 00 00 48 > > 39 d0 75 e7 48 89 df e8 > > Sep 22 13:36:05 tvserver kernel: [ 156.267140] RSP: 0018:b4f3c262fea0 > > EFLAGS: 00010246 > > Sep 22 13:36:05 tvserver kernel: [ 156.267223] RAX: RBX: > > 9112efad8ba0 RCX: > > Sep 22 13:36:05 tvserver kernel: [ 156.267331] RDX: 9112ee80cd20 RSI: > > RDI: > > Sep 22 13:36:05 tvserver kernel: [ 156.267439] RBP: b4f3c262fea8 R08: > > R09: 9112ed60c618 > > Sep 22 13:36:05 tvserver kernel: [ 156.267546] R10: f000 R11: > > 002462016bed R12: 9112ef474000 > > Sep 22 13:36:05 tvserver kernel: [ 156.267653] R13: c108ba90 R14: > > R15: 9112f36ed700 > > Sep 22 13:36:05 tvserver kernel: [ 156.267761] FS: () > > GS:9112f820() knlGS: > > Sep 22 13:36:05 tvserver kernel: [ 156.267880] CS: 0010 DS: ES: > > CR0: 80050033 > > Sep 22 13:36:05 tvserver kernel: [ 156.267968] CR2: 0520 CR3: > > 00014820e000 CR4: 001006f0 > > Sep 22 13:36:05 tvserver kernel: [ 156.268074] Call Trace: > > Sep 22 13:36:05 tvserver kernel: [ 156.268136] > > pvr2_context_thread_func+0xc4/0x2b0 [pvrusb2] > > Sep 22 13:36:05 tvserver kernel: [ 156.268227] ? wait_woken+0x80/0x80 > > Sep 22 13:36:05 tvserver kernel: [ 156.268290] kthread+0x120/0x140 > > Sep 22 13:36:05 tvserver kernel: [ 156.268362] ? > > pvr2_context_destroy+0xc0/0xc0 [pvrusb2] > > Sep 22 13:36:05 tvserver kernel: [ 156.268449] ? > > __kthread_parkme+0x70/0x70 > > Sep 22 13:36:05 tvserver kernel: [ 156.268518] ret_from_fork+0x35/0x40 > > Sep 22 13:36:05 tvserver kernel: [ 156.268578] Modules linked in: s5h1411 > > tda18271 tda8290 tuner cx25840 pvrusb2 tveeprom cx2341x dvb_core > > v4l2_common videodev media veth xt_nat ipt_MASQUERADE xfrm_user xfrm_algo > > br_netfilter bridge stp llc xt_recent ipt_REJECT nf_reject_ipv4 xt_limit > > xt_comment xt_multiport xt_conntrack xt_hashlimit xt_addrtype xt_mark > > iptable_mangle xt_tcpudp xt_CT iptable_raw nfnetlink_log xt_NFLOG > > nf_log_ipv4 nf_log_common xt_LOG nf_conntrack_sane nf_conntrack_netlink > > nfnetlink nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip > > nf_nat_pptp nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda > > nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_proto_gre > > nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc > > nf_conntrack_h323 nf_conntrack_ftp ts_kmp nf_conntrack_amanda iptable_nat > > nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 arc4 > > iptable_filter bpfilter md4 cmac nls_utf8 cifs ccm fscache aufs overlay > > nls_iso8859_1 xfs libcrc32c snd_hdmi_lpe_audio snd_pcm > > Sep 22 13:36:05 tvserver kernel: [ 156.268655] snd_seq_midi > > snd_seq_midi_event snd_rawm
Re: [pvrusb2] Ability to fully reset a PVRUSB2 Device
q_codel ip_tables x_tables autofs4 hid_logitech_hidpp > hid_logitech_dj hid_generic usbhid r8169 ahci lpc_ich i2c_i801 libahci > realtek i2c_hid video hid > Sep 22 13:36:05 tvserver kernel: [ 156.270831] CR2: 0520 > Sep 22 13:36:05 tvserver kernel: [ 156.270891] ---[ end trace > 5d13378174849ef9 ]--- > Sep 22 13:36:05 tvserver kernel: [ 156.270988] RIP: > 0010:pvr2_v4l2_internal_check+0x47/0x70 [pvrusb2] > Sep 22 13:36:05 tvserver kernel: [ 156.271089] Code: 2f e4 ff ff 48 8b 7b > 40 e8 26 e4 ff ff 48 8b 43 38 48 8b 90 20 05 00 00 48 05 20 05 00 00 48 39 > d0 74 03 5b 5d c3 48 8b 43 40 <48> 8b 90 20 05 00 00 48 05 20 05 00 00 48 > 39 d0 75 e7 48 89 df e8 > Sep 22 13:36:05 tvserver kernel: [ 156.271363] RSP: 0018:b4f3c262fea0 > EFLAGS: 00010246 > Sep 22 13:36:05 tvserver kernel: [ 156.271447] RAX: RBX: > 9112efad8ba0 RCX: > Sep 22 13:36:05 tvserver kernel: [ 156.271556] RDX: 9112ee80cd20 RSI: > RDI: > Sep 22 13:36:05 tvserver kernel: [ 156.271665] RBP: b4f3c262fea8 R08: > R09: 9112ed60c618 > Sep 22 13:36:05 tvserver kernel: [ 156.271773] R10: f000 R11: > 002462016bed R12: 9112ef474000 > Sep 22 13:36:05 tvserver kernel: [ 156.271882] R13: c108ba90 R14: > R15: 9112f36ed700 > Sep 22 13:36:05 tvserver kernel: [ 156.271990] FS: () > GS:9112f820() knlGS: > Sep 22 13:36:05 tvserver kernel: [ 156.272111] CS: 0010 DS: ES: > CR0: 80050033 > Sep 22 13:36:05 tvserver kernel: [ 156.272201] CR2: 0520 CR3: > 00014820e000 CR4: 001006f0 > Sep 22 13:36:10 tvserver kernel: [ 161.084276] usb 1-4: new high-speed USB > device number 9 using xhci_hcd > Sep 22 13:36:10 tvserver kernel: [ 161.236211] usb 1-4: New USB device > found, idVendor=2040, idProduct=7501, bcdDevice= 8.00 > Sep 22 13:36:10 tvserver kernel: [ 161.236349] usb 1-4: New USB device > strings: Mfr=1, Product=2, SerialNumber=3 > Sep 22 13:36:10 tvserver kernel: [ 161.236458] usb 1-4: Product: WinTV > Sep 22 13:36:10 tvserver kernel: [ 161.236516] usb 1-4: Manufacturer: > Hauppauge > Sep 22 13:36:10 tvserver kernel: [ 161.236584] usb 1-4: SerialNumber: > 7300-00-F080EDCF > Sep 22 13:36:10 tvserver kernel: [ 161.239374] pvrusb2: Hardware > description: WinTV HVR-1950 Model 751xx > > Cheers! > -- > *Diego Rivera* > > > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon> > Virus-free. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > On Sun, Sep 22, 2019 at 12:42 PM Mike Isely wrote: > > > On Sun, 22 Sep 2019, Mike Isely wrote: > > > > > > > > On Sun, 14 Apr 2019, Diego Rivera wrote: > > > > > > > Guinea pig #1 ready, sir! > > > > > > > > -- > > > > > > > > Diego Rivera > > > > > > > > > > Diego: > > > > > > Going back over this thread and comparing my recent notes, there's a > > > good experiment I'd like you to try: Get the hardware into a state > > > where you get the "Attempted to execute control transfer when device not > > > ok" infinite log spew. Once you've confirmed the scenario again, reboot > > > the host and then rename the ir-kbd-i2c.ko module to something which > > > disables it. You can find this module in the following path: > > > > > > /lib/modules/`uname -r`/krtnrl/drivers/media/i2c/ > > > > Typo correction: > > > > /lib/modules/`uname -r`/kernel/drivers/media/i2c/ > > > > (fingers in wrong position on keyboard, apparently) > > > > > > > > > > A good thing to do would be to just add "-disabled" to the end of the > > > file name. Then run "depmod -a" to rebuild the module dependencies > > > (should take a few seconds) and now the ir-kbd-i2c module will be > > > disabled. On the off-chance that it has already been loaded, also run > > > "modprobe -r ir_kbd_ic2" (or just reboot again). NOW, run that same > > > scenario where you get the log spew as mentioned above. Is that still > > > happening? Also, if it isn't still happening, does "modprobe -r > > > pvrusb2" still get stuck? > > > > > > The reason I ask is because that's what I am seeing here. That > > > ir-kbd-i2c here is the source
Re: [pvrusb2] Ability to fully reset a PVRUSB2 Device
On Sun, 22 Sep 2019, Mike Isely wrote: > > On Sun, 14 Apr 2019, Diego Rivera wrote: > > > Guinea pig #1 ready, sir! > > > > -- > > > > Diego Rivera > > > > Diego: > > Going back over this thread and comparing my recent notes, there's a > good experiment I'd like you to try: Get the hardware into a state > where you get the "Attempted to execute control transfer when device not > ok" infinite log spew. Once you've confirmed the scenario again, reboot > the host and then rename the ir-kbd-i2c.ko module to something which > disables it. You can find this module in the following path: > > /lib/modules/`uname -r`/krtnrl/drivers/media/i2c/ Typo correction: /lib/modules/`uname -r`/kernel/drivers/media/i2c/ (fingers in wrong position on keyboard, apparently) > > A good thing to do would be to just add "-disabled" to the end of the > file name. Then run "depmod -a" to rebuild the module dependencies > (should take a few seconds) and now the ir-kbd-i2c module will be > disabled. On the off-chance that it has already been loaded, also run > "modprobe -r ir_kbd_ic2" (or just reboot again). NOW, run that same > scenario where you get the log spew as mentioned above. Is that still > happening? Also, if it isn't still happening, does "modprobe -r > pvrusb2" still get stuck? > > The reason I ask is because that's what I am seeing here. That > ir-kbd-i2c here is the source of the endless stream of failing I2C > requests into the pvrusb2 driver. I want to make sure we're looking at > the same bug. I've got roughly 3 misbehaviors on my plate right now. > This is one of them. > > There was an earlier mention of a kernel panic when trying to remove the > pvrusb2 driver from the system. While I am seeing kernel oopses from > this - due to sysfs doing something unexpected - it is not panicing. > So I have not yet seen that specific problem. I'd like to know what > exact kernel was being run (distro / uname -r output / .config would > help too). > > -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 > pvrusb2@isely.net > 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Ability to fully reset a PVRUSB2 Device
On Sun, 14 Apr 2019, Diego Rivera wrote: > Guinea pig #1 ready, sir! > > -- > > Diego Rivera > Diego: Going back over this thread and comparing my recent notes, there's a good experiment I'd like you to try: Get the hardware into a state where you get the "Attempted to execute control transfer when device not ok" infinite log spew. Once you've confirmed the scenario again, reboot the host and then rename the ir-kbd-i2c.ko module to something which disables it. You can find this module in the following path: /lib/modules/`uname -r`/krtnrl/drivers/media/i2c/ A good thing to do would be to just add "-disabled" to the end of the file name. Then run "depmod -a" to rebuild the module dependencies (should take a few seconds) and now the ir-kbd-i2c module will be disabled. On the off-chance that it has already been loaded, also run "modprobe -r ir_kbd_ic2" (or just reboot again). NOW, run that same scenario where you get the log spew as mentioned above. Is that still happening? Also, if it isn't still happening, does "modprobe -r pvrusb2" still get stuck? The reason I ask is because that's what I am seeing here. That ir-kbd-i2c here is the source of the endless stream of failing I2C requests into the pvrusb2 driver. I want to make sure we're looking at the same bug. I've got roughly 3 misbehaviors on my plate right now. This is one of them. There was an earlier mention of a kernel panic when trying to remove the pvrusb2 driver from the system. While I am seeing kernel oopses from this - due to sysfs doing something unexpected - it is not panicing. So I have not yet seen that specific problem. I'd like to know what exact kernel was being run (distro / uname -r output / .config would help too). -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Ability to fully reset a PVRUSB2 Device
Nope. The problem still happens. It has to be a race condition probably influenced by turning on all that trace print. This is actually all good stuff. There's a lot of good leads to chase down here. -Mike On Sat, 21 Sep 2019, Mike Isely wrote: > > I did something really simple: I ran modprobe -r ir_kbd_i2c then renamed > the .ko file so it would not get loaded anymore. That appears to have > put a stop to the infinite loop behavior. It is not a solution but a > large clue. With that change I just hotplugged then hot-unplugged the > hardware and THIS TIME it did not oops. But I don't believe it. I'm > trying another build right now with my trace print removed - going back > to the original scenario just to be sure that this is or is not related. > > Along the way I ran into another bad scenario, "modprobe -r pvrusb2" > after powering off the hardware seems to permanently jam. That's not > supposed to happen at all. > > I'm keeping a list... > > -Mike > > > On Sat, 21 Sep 2019, Diego Rivera wrote: > > > This is good news! Any progress is good progress! Perhaps disabling that > > bit somehow can provide a workaround? Maybe the whole I2C IR stack can be > > disabled system-wide? My box doesn't use that, so...? > > > > Cheers! > > > > -- > > > > Diego Rivera > > > > On Sat, Sep 21, 2019, 19:30 Mike Isely wrote: > > > > > On Sat, 21 Sep 2019, Diego Rivera wrote: > > > > > > > Thanks for the update! > > > > It occurred to me: what if for #3, instead of the driver not handling > > > the error, it's simply > > > > expecting a different/new (type of) error to be raised in order to go > > > through a code path that leads > > > > to it not getting borked? Bah ... I'm sure you've thought of this ☺ > > > > Cheers! > > > > > > Well anything is possible. However EIO is generally understood to mean > > > "I/O error" which in fact this is. > > > > > > I just added a dump_stack() call after detecting the error, and the > > > guilty component is the I2C IR chip-level driver (the thing that watches > > > the IR port and figures out what buttons you press on the remote). > > > It's coming from a call to get_key_haup_common() which is in > > > ir-kbd-i2c.c. That code is not written with any loop, but it pretty > > > clearly itself returns -EIO to its caller if the I2C transfer attempt > > > fails (for any reason). The caller can only be get_key_haup() but it > > > looks like the compiler optimized that away so it isn't showing up in > > > the stack trace. Stack frames above that point "look" like it might be > > > coming from userspace, so - on the Ubuntu system where I'm playing with > > > this, a userspace IR daemon might be in play here. It might be the > > > thing pounding on the pvrusb2 driver - in this scenario. > > > > > > I'm not familiar with that i2c kbd driver but there are a lot of avenues > > > to look at here. For example, I can probably disable away that whole > > > thing so I can turn my attention to #1. I also have several different > > > pvrusb2 devices here and they each have different IR designs which may > > > cause different upstream behavior. Like I said, a number of avenues > > > here. > > > > > > -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 > > > pvrusb2@isely.net > > > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 > > > > > ___ > > pvrusb2 mailing list > > pvrusb2@isely.net > > 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 > pvrusb2@isely.net > 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Ability to fully reset a PVRUSB2 Device
I did something really simple: I ran modprobe -r ir_kbd_i2c then renamed the .ko file so it would not get loaded anymore. That appears to have put a stop to the infinite loop behavior. It is not a solution but a large clue. With that change I just hotplugged then hot-unplugged the hardware and THIS TIME it did not oops. But I don't believe it. I'm trying another build right now with my trace print removed - going back to the original scenario just to be sure that this is or is not related. Along the way I ran into another bad scenario, "modprobe -r pvrusb2" after powering off the hardware seems to permanently jam. That's not supposed to happen at all. I'm keeping a list... -Mike On Sat, 21 Sep 2019, Diego Rivera wrote: > This is good news! Any progress is good progress! Perhaps disabling that > bit somehow can provide a workaround? Maybe the whole I2C IR stack can be > disabled system-wide? My box doesn't use that, so...? > > Cheers! > > -- > > Diego Rivera > > On Sat, Sep 21, 2019, 19:30 Mike Isely wrote: > > > On Sat, 21 Sep 2019, Diego Rivera wrote: > > > > > Thanks for the update! > > > It occurred to me: what if for #3, instead of the driver not handling > > the error, it's simply > > > expecting a different/new (type of) error to be raised in order to go > > through a code path that leads > > > to it not getting borked? Bah ... I'm sure you've thought of this ☺ > > > Cheers! > > > > Well anything is possible. However EIO is generally understood to mean > > "I/O error" which in fact this is. > > > > I just added a dump_stack() call after detecting the error, and the > > guilty component is the I2C IR chip-level driver (the thing that watches > > the IR port and figures out what buttons you press on the remote). > > It's coming from a call to get_key_haup_common() which is in > > ir-kbd-i2c.c. That code is not written with any loop, but it pretty > > clearly itself returns -EIO to its caller if the I2C transfer attempt > > fails (for any reason). The caller can only be get_key_haup() but it > > looks like the compiler optimized that away so it isn't showing up in > > the stack trace. Stack frames above that point "look" like it might be > > coming from userspace, so - on the Ubuntu system where I'm playing with > > this, a userspace IR daemon might be in play here. It might be the > > thing pounding on the pvrusb2 driver - in this scenario. > > > > I'm not familiar with that i2c kbd driver but there are a lot of avenues > > to look at here. For example, I can probably disable away that whole > > thing so I can turn my attention to #1. I also have several different > > pvrusb2 devices here and they each have different IR designs which may > > cause different upstream behavior. Like I said, a number of avenues > > here. > > > > -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 > > pvrusb2@isely.net > > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 > > > ___ > pvrusb2 mailing list > pvrusb2@isely.net > 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Ability to fully reset a PVRUSB2 Device
An update on this... 1. There are two kernel threads involved. One manages contexts, the other is involved in a kernel work queue for managing the hardware. A week ago I first thought it was that context-managing thread, but now it appears to be that second thread which is jamming, triggering a kernel oops and then aborting, leaving the driver in a fubar state. 2. The v5.3.1 kernel happens to now include an upstream fix that deals with a potential null pointer dereference problem in the sysfs part of the pvrusb2 driver. This is a new change, since at least 5.2.13 (the version I'm focusing on right now). This would be something that gets hit on tear-down so without that fix things MIGHT go awry. But right now I don't know if that is the same problem we're looking at here. This is because... 3. After turning on additional trace print, I've noticed another problem that might be masking things. Some background... The pvrusb2 driver doesn't do "everything" on its own. Rather, like many v4l drivers, it relies on common external v4l chip-level drivers to self-manage various parts of the video pipeline. In these cases the pvrusb2 driver provides a datapath for all these things to reach the hardware, via an I2C master interface that is carried over the USB cable (tunneled, effectively). Every chip-level driver in v4l that accesses stuff on the pvrusb2-related hardware does so through this pvrusb2-provided I2C interface. Well when you unplug the device / kill its power / whatever, obviously that datapath is severed. When this happens any further attempts to access that I2C master interface is met with an EIO error back to the caller (and you'll see a kernel log message "pvrusb2: Attempted to execute control transfer when device no ok"). During tear-down that's actually expected. However the tear-down can't complete until all these chip-level drivers in v4l stop trying to use this interface. And somebody these isn't giving up - the driver is getting into what appears to be an infinite loop of these errors and never getting out. This leads me to suspect a v4l chip-level driver may have a problem dealing with a hot-unplug situation. Given that those drivers are managed outside of the pvrusb2 driver (for obvious reasons), it's possible that a change in one of those might be a contributor to the problem here. So I'm trying to suss out #3 above first. That should hopefully clear the air to solve #1 and figure out if #2 is related to any of this. -Mike On Mon, 9 Sep 2019, Mike Isely wrote: > > 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, is...@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 > > > &
Re: [pvrusb2] Noise
The pvrusb2 driver is supposed to select the audio input in conjunction with the video choice. There is a map in the driver that, based upon the particular model, should be selecting the correct audio input for you when you select the "overall" input. It has always been like that. If there's a problem there now with that, well, it is another thing that needs to be investigated.More stuff to dig out, with no extra time in which to do it :-(Sent from my T-Mobile 4G LTE Device Original message From: Jan Ceuleers Date: 4/21/19 8:21 AM (GMT-06:00) To: pvrusb2@isely.net Subject: Re: [pvrusb2] Noise Mike,Thanks for your reply.Given that in the past it was possible (in fact necessary) to select theaudio input and that this is no longer possible/necessary now, am Iright in thinking that the driver programs the hardware to add all audiosources together on the assumption that only the "correct"-one willactually be producing an audio signal and the others will be silent?If so, are there circumstances under which this assumption might be false?Again if so, is there anything I can do about that? For example, in myuse case (where I'm only recording from line in and composite video in)can I disable certain components that aren't being used? For example getrid of certain firmware images, or use certain pvrusb2 module parameters?Thanks, JanOn 21/04/2019 14:54, is...@isely.net wrote:> Jan:>> That's an odd symptom. Getting audio from an RF signal actually has a > longer processing path than audio from the line-in port. In fact, > there should be very little (if anything) involved with the line-in port > that isn't also involved with processing audio from an RF signal. In > either of those two cases, the audio is processed by a separate chip > (cx25840 IIRC) and the result of that is what is fed into the mpeg > encoder chip. Once past the cx25840, there's no difference in the > datapath.>> There's a separate driver for the cx25840, which the pvrusb2 driver > employs, which is part of the v4l2 subsystem as a whole, so any problem > involving audio like you describe should also be likely with any other > video capture driver that also happens to use a cx25840. I know this > isn't being very helpful, but it does suggest that looking for other > online chatter involving that part might reveal another clue.>> -Mike>>> On Sun, 21 Apr 2019, Jan Ceuleers wrote:>>> Dear list, I am seeking some help with an audio defect that afflicts some>> recordings made using Hauppauge PVR 1950 devices. I have two mythtv backends: - the slave backend has three 1950s that record from analogue cable.>> Audio recorded from these tuners is fine. - the master backend has two 1950 PVRs that record from set-top boxes>> (i.e. from the composite video input and line audio inputs). All>> recordings made using these two tuners suffer from an audio defect as>> described below. The audio defect is a clearly audible repetitive "whistling" noise, with>> a periodicity of about 1 second. This noise is not present on the audio>> signal that goes into the PVR. I have tried many variations of v4l2-ctl -d$device -f $freq without>> effect (and have settled on 450 MHz as the frequency). The point of>> doing this is that I want to exclude noise from the channel the analogue>> tuner happens to be tuned to. Many moons ago a pvrusb2 device had multiple audio inputs from which one>> could select the right-one using v4l2-ctl -d$device>> --set-audio-input=$audiodev , with valid values for audiodev being 0, 1>> and 2. The correct setting for my use case was 1. This is no longer the>> case: the device presents only one audio input which is numbered 0. I'd be grateful for any hints. Thanks, Jan ___>> pvrusb2 mailing list>> pvrusb2@isely.net>> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2>>___pvrusb2 mailing listpvrusb2@isely.nethttp://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 ___ pvrusb2 mailing list pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
[pvrusb2] list test
Please disregard. Testing the mailing list -- 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
[pvrusb2] pvrusb2 list info status
Everyone: For the moment I've left CGI access disabled on the system which is serving the pvrusb2 list. This affects web access to the mailing list, unfortunately. I did this pre-emptively over the weekend as a defense against Shellshock until this situation sorts itself out. And in fact I just checked my web server logs this morning and there actually was a targeted attack against the server - just a few hours ago - via an attempt to access the list's web interface. It seems that a bullet was dodged. Sorry about this disruption. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Grabster AV400 and TS support..
Comments interspersed below...
On Thu, 3 Oct 2013, Andrea Venturi wrote:
Il 03/10/2013 07:23, Mike Isely ha scritto:
On Wed, 2 Oct 2013, Andrea Venturi wrote:
...However with that said, it's been quite a while and there certainly
haven't been any complaints so I guess I should get off my *ss and get the
experimental designation removed...
maybe let me do some more tests in the next few days to refresh Terratec
status and we'll see if the experiment mark is ready to go..
OK.
are you willing to bring forward some janitorial patches, eventually?
Of course.
i'm writing here because i'd like to finally test the Transport Stream
internal generation.
i've read here and there on the web and it says it's a feature available
only
on old encoder firmware.
BTW i've seen that you can get an idea of a firmware version if you give a
look at string Version inside encoder firmware, as in:
$ strings /lib/firmware/v4l-cx2341x-enc.fw | grep Version
Version 2.04.211
$ md5sum /lib/firmware/v4l-cx2341x-enc.fw
ab75947ef1b086e26f9b08e628baa02e /lib/firmware/v4l-cx2341x-enc.fw
That's very interesting. I was unaware that these opaque firmware blobs
had any means for being version controlled at all.
i saw in cx2341x.h, there's a API command called CX2341X_ENC_GET_VERSION and
it matches with the string embedded.
That would be useful, were the driver to be modified to adjust its
behavior based on what it gets - which is obviously where you're headed
here.
Since I have no
documentation on the machine language used by the encoder (all that
really exists in the community is a semi-complete ABI for communicating
with the part), I've never even tried to reverse-engineer the blob. I
should update the fwextract program to annotate its output with the
embedded version information.
in my further attempts to gain some skill on driver modding and insight on
capabilities, i've put this piece of code in a place where it should have been
called: pvr2_encoder_prep_config() in pvrusb2-encoder.c
===
u32 retData;
if (!pvr2_encoder_cmd(hdw, CX2341X_ENC_GET_VERSION, 0, 1, retData)) {
pvr2_trace(
PVR2_TRACE_ERROR_LEGS,
Firmware version: %x.%x.%x,
retData240xff, retData160xff, retData0x);
} else {
pvr2_trace(
PVR2_TRACE_ERROR_LEGS,
Firmware version not returned);
}
==
and i get indeed a consistent output when i do a capture with cat
/dev/video0/ /dev/null.
in dmesg i find (with debug=0x40001f in pvrusb2 module load):
...
[10134.320514] pvrusb2: pvr2_encoder_configure (cx2341x module)
[10134.333540] pvrusb2: Firmware version: 2.4.11
...
of course this informative call would need to be put after firmware upload
into encoder, not when starting real encoding..
Also realize that the pvrusb2 driver can force a reload of the firmware
if the encoder chip hangs (which unfortunately happens). Not just when
the driver comes up. In fact on hybrid devices this might even happen
when switching between analog and digital modes. This reload happens
pretty quickly but nonetheless we would need to reconfirm the firmware
version and possibly adjust driver behavior to match, which may turn
into a rabbit hole if we're not careful.
BTW ivtv driver has a special page related to firmware versions:
http://ivtvdriver.org/index.php/Firmware_versions
and here there's trace of this version 2.4.11 (11 is a typo, i suppose.. it
should be 2.4.211):
PVR250/350
Encoder: 0x02040011, md5sum ab75947ef1b086e26f9b08e628baa02e
Yes, I see that page now. But that's talking about ivtv versions and
recommended firmware versions related to software and hardware versions.
On the pvrusb2 side this really isn't an issue.
...
so the first questions:
- has TS support been scrapped from the pvrusb2 driver?
No, but it was never added either. TS support is purely a question at
the encoder chip level; the pvrusb2 driver doesn't do anything to help
(or hinder) that. It never has.
good.
- which is one firmware version known to be available for my tests
No idea. The driver doesn't discriminate firmware versions at all - it
treats them all exactly the same. This is sounding like we would need
to add new functionality to detect the version of the loaded cx2341x
firmware blob and then run-time adjust the behavior of cx2341x.c,
pvrusb2-encoder.c and very likely also pvrusb2-hdw.c (which defines all
knobs / switches visible in sysfs). Nothing of that concept exists in
the driver - it never has been there.
i suppose that, for next test, if i force pvrusb2-hdw. to show MPEG-2
Transport Stream in sysfs ctl_stream_type control file, i can try to make
Re: [pvrusb2] WinTV USB2/Tv-Viewer question
On Tue, 27 Aug 2013, Lorne Shantz wrote: I have done some more tinkering... It seems to be related to the composite cables coming from the vcr player. ? Tv-viewer would not play. I'm getting a lot of this below: [19727.089020] pvrusb2: ***WARNING*** device's encoder appears to be stuck (status=0x0003) [19727.089023] pvrusb2: Encoder command: 0x81 [19727.089024] pvrusb2: Giving up on command. This is normally recovered via a firmware reload and re-initialization; concern is only warranted if this happens repeatedly and rapidly. Routinely testing, I removed the cables from the vcr player and up it comes. ?? So it is intermittent it seems. I have recorded stuff from the vcr, but something seems amiss. Is there such a thing as a firmware update for these devices? I have over time seen later versions of the mpeg video encoder firmware bundled with later models of the device (any of the devices, actually). The fwextract.pl script recognizes a number of variants. However I personally have never really seen any improvement (or degradation) in behavior of that encoder correlated with firmware revision. Generally speaking, the different mpeg encoder firmware variants floating around all seem to be interchangeable, and the pvrusb2 driver doesn't make any attempt to discriminate among them. As for the ...apears to be stuck... message, that is what happens when the pvrusb2 driver attempts to issue a command to the mpeg encoder and the encoder fails to acknowledge it. (There's a sort of shared memory mailbox interface which uses a sort of handshake protocol for issuing commands to the encoder.) From all outward behavior at this point, the encoder appears to be crashed. I've only ever seen this happen when the command is issued to start streaming and there has NEVER been any pattern to it that I could find. It's just generally been random with a low probability. The pvrusb2 driver always recovers this case by quickly reseting the encoder and reloading its firmware. It's hackish but the whole recovery happens in less than a second and because it only ever seems to happen when streaming is started, it never actually causes lingering problems. Back when I first encountered this behavior (way back around 2005) I spent a LONG time trying to characterize it so that I could understand its cause. I never did find the root cause. Instead, the workaround (i.e. reboot the encoder) all along seems to have been good enough. Some day if I could ever get a good look at the source code for that encoder firmware, it might be possible to finally suss out what's really going on. But I doubt that day will ever come :-( I have over time seen some reports where people have gotten frequent rapid bursts of this problem happening. In all cases that I remember, it was never pinned down to be a real encoder problem. Rather some have found that cleaning up glitchy power has helped - the mpeg2 encoder is probably the most complicated and definitely the most power hungry chip in the device so it might be the most power sensitive as well. It might also be a sign over overheating. I've also suspected over time that if the mpeg encoder fails to get a clean digital stream from the upstream pipeline stage (the video digitizer) - perhaps because of problems with video sync - that this might cause the mpeg encoder to behave badly. But I've never been able to prove it. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
[pvrusb2] Fun with heat / power [was: (an indescipherable string)]
(see below) On Fri, 12 Jul 2013, Gary Buhrmaster wrote: On Fri, Jul 12, 2013 at 8:24 PM, Jan Brouwer j...@brewsky.nl wrote: ... My unit does get pretty hot... I didn't think of cooling it before, so maybe that would do the trick! Certain Hauppauge devices have a history of getting hot and resetting. Certain Hauppauge devices also have a history of having power supplies going (partially) bad (especially if they are a few years old). Either can cause random crashes. Since it is (usually) the easiest to test (unless your computer is next to the refrigerator :-), I always swap out the power supply first. Yes, this is definitely the case. In fact, back in prehistory when I was much more a hardware hacker than a software guy I learned that when digital circuits misbehave the FIRST thing one should always suspect is the power supply! To summarize various previous discussions on this topic, the things I've seen over the years: These units do dissipate heat. If you have it sitting in the open ambient air (with the room at a normal comfortable temperature) then it generally should not be a problem. But if the device is in a closed-up box where there's no air circulation or if perhaps it's stacked with other heat-generating devices, then you may have problems with crashes / resets. I do remember one specific tale a number of years back where the user had stacked 3-4 24xxx devices on top of each other and then stuffed them in a closed box. That didn't work out so well :-) I find that people get frequently fooled by bad power. The issue here is that normal PC power supplies are in fact very forgiving of bad mains - typical PC PSUs have large capacitors and a lot of internal protection. They're designed to process/condition 300-700 watts without wasting a lot of energy and it takes a good design to do that. I've had PCs actually keep going perfectly even when the building power fails for a fraction of a second. The monitor might wink out for a moment but the PC just keeps truckin' along. USB-powered devices (well, those not connected to a powered hub...) have the benefit of drawing power from that nice stable PSU. But any peripheral which is self-powered with, say, it's own little power brick is at a disadvantage. Power spikes, brown-outs, or just plain saggy power won't affect the PC but the cheap wall-wart just can't defend against crap like that. It doesn't have the same quality of filtering, and it is just too small to have enough hold-up capacitance to survive a dropout. That leads to situations where strangely enough pvrusb2 devices seem to randomly crash while the PC itself is unscathed. People frequently conclude that the device is flakey when in fact it's just bad power that can't be compensated by a simplistic power brick. So people seeing pvrusb2 resets don't immediately suspect bad power because, well, the PC is not crashing... Even a surge protector won't help the situation if the problem is dropouts or sags - surge protectors just block damaging spikes and filter EMI but they don't store energy to cover glitchy power losses, even for a fraction of a second. For that you need a UPS, and one that is fast enough on switchover to keep from glitching the power brick (I think most modern UPSes meet that requirement). One big tip-off of bad power is if you can correlate pvrusb2 crashes with external electrical events, like say your refrigerator cycling or a nearby A/C compressor turning on/off. A sump pump could even glitch things. Anything that can suddenly draw (or cease drawing) large loads can do this. And inductive loads - like a motor - can really screw with your power. And yes, I've seen reports of people who have correlated pvrusb2 crashes with their A/C compressor cycling on/off. (Though it has been a few years...) You won't be able to analyze bad power with a voltmeter (analog, DMM, DVM, whatever..). The events you are looking for will be too fast and the meter is usually filtered internally for slower (more readable) response. If you really want to look for glitches, use an oscilloscope - but BE CAREFUL - you're messing with high voltage + high current which can seriously injure or kill you. You can blow up the scope if you get the grounding wrong! Actually it would be safer instead to 'scope it indirectly - say look at the output of a doorbell transformer wired to the mains. Then at least it's isolated, current-limited 24VAC instead of 120VAC or 240VAC (depending obviously on your country's power grid). Anyway, if you suspect bad power, one easy test for this is just to plug the pvrusb2 device's power brick into a UPS. If you suspect heat issues, try just using a simple desk fan to blow air across the top for a while. If either experiment changes the behavior then you know you're onto something. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5
Re: [pvrusb2] Some install guidance on WinTV PVR2 USB
Yup, the device's Cypress FX2 microcontroller has to be working in order for it to show up in a USB enumeration. And if the FX2 is up, then likely everything else is fine as well - as has been noted throughout the resulting discussion thread. Given the rest of the thread here, it looks like you're good to go. To everyone else - thank you for jumping in and providing help. Way back in 2005 when I started this list, I was ultimately hoping that I wouldn't have to jump in every time - so I appreciate the collective wisdom everyone else has contributed here to help Lorne get unstuck! -Mike On Wed, 12 Jun 2013, Lorne Shantz wrote: Hey Mike, Pathetic I know, but I finally found my WinTV! I used the polarity you said (Positive in the center) and lsusb shows: Bus 001 Device 003: ID 045e:0730 Microsoft Corp. Digital Media Keyboard 3000 Bus 001 Device 004: ID 045e:00e1 Microsoft Corp. Wireless Laser Mouse 6000 Reciever Bus 002 Device 010: ID 2040:2400 Hauppauge WinTV PVR USB2 (Model 24019) Bus 002 Device 003: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth So it is seen... that should mean it isn't borked right? --- On Wed, 3/20/13, Mike Isely is...@isely.net wrote: From: Mike Isely is...@isely.net Subject: Re: [pvrusb2] Some install guidance on WinTV PVR2 USB To: Communications nexus for pvrusb2 driver pvrusb2@isely.net Date: Wednesday, March 20, 2013, 5:07 PM I will follow up with the correct polarity (by checking what I do have). However if you already tried it both ways, then odds are likely that you already let the magic smoke out. Low voltage digital logic behaves very destructively if fed reversed power. Generally if the device in question expects unregulated power coming in and has its own on-board regulator, then there's a *chance* it might survive reversed power - because only the regulator will have been exposed to the condition. Or maybe just the regulator got fried which might be fixable (especially if its a cheap little 7805 3-terminal linear device). Given that the brick supplies 6V and the onboard logic there is probably wanting 5V, then there very well may be an onboard regulator. -Mike On Wed, 20 Mar 2013, Lorne Shantz wrote: Thank you very much for the great reply. I just got done redoing the office floor and now I can't find the derned thing. One more question that I had was... I misplaced the power supply awhile back. I know it is 6 volts DC, but it doesn't indicate the polarity. I am going to assume that the center is + and the outside is -, since that is the way their new stuff is. Is that correct? I suppose I ruined it by trying it both ways, although no smoke, or any indication I smoked it. --- On Tue, 3/19/13, Mike Isely is...@isely.net wrote: From: Mike Isely is...@isely.net Subject: Re: [pvrusb2] Some install guidance on WinTV PVR2 USB To: Communications nexus for pvrusb2 driver pvrusb2@isely.net Date: Tuesday, March 19, 2013, 7:30 PM Lorne: These days the in-kernel pvrusb2 driver should work great without any special setup beyond perhaps ensuring you have the firmware files installed somewhere visible to udev. Kernel 3.4.33 is reasonably new and should just work. I imagine most distribution kernels probably compile this driver for you, either into the kernel package itself or maybe as a media package add-on. If you searched /lib/modules recursively, you should be able to find pvrusb2.ko in there. Things I would check for: 1. Ensure the pvrusb2 device's power brick is plugged in and the unit is actually getting power. If that isn't happening, then *nothing* else will work. 2. Even if the firmware files are not installed, the pvrusb2 driver should still attempt to attach to the hardware and you should see corresponding messages in the kernel log (i.e. dmesg) - leading up to the point where it gives up for lack of available firmware. So if you're not seeing any messages, then the lack of firmware is likely not the issue. 3. Even if the pvrusb2 driver itself were completely borked or otherwise missing, you should still be able to see the hardware show up to the kernel via either running the usbview tool or just cat /proc/bus/usb/devices. If you can't see anything there that suggests the presence of the pvrusb2 hardware, then the driver situation won't matter at all. (This would suggest the device is not getting power or there is a communication issue between the PC and the device.) If there is a suspicion about, say, a bad USB hub or USB cable, then I would (obviously) try swapping around those parts. If you have another PC (or laptop nearby), you can also try plugging the device in there - if only to see if you get a reaction from
Re: [pvrusb2] Hauppauge HVR-1900 - PAL-Nc, no audio
Multiple additional comments interspersed below... On Mon, 8 Apr 2013, Dermot Buckley wrote: Hi Mike, Thanks for the response. On 8 Apr 2013, at 11:43, Mike Isely is...@isely.net wrote: In times past when I've dealt with bugs involving no captured audio, the usual suspect was that the pvrusb2 hardware was being told to use the wrong broadcast standard. It's possible to choose a standard that is close enough for, say, video to work but not audio. There are different modulation standards and frequencies for the embedded audio and if that is set wrong, then of course there will be no audio. Making matters somewhat more confusing is that in many cases, the hardware can successfully guess the correct audio configuration even when the wrong standard is set. So you can get cases where, for example, someone with a 24xxx series device will get working audio using standard XYZ while someone else in the same country but using a 29xxx device with the same XYZ standard still won't hear any audio :-( I'm about 98% certain of the broadcast standard I'm setting (PAL-Nc). Our regular TV (which is both NTSC- and PAL-capable) displays PAL-N and SAP when changing channels (not very technical I know!), and my testing (included below) would seem to point to PAL-Nc being the correct variation. OK. I had to ask - because that's been a cause in the past... To verify, I checked all supported standards as follows: root@rasptune ~# rmmod pvrusb2 root@rasptune ~# modprobe pvrusb2 debug=1 (waiting a moment for RF tracking filter calibration...) root@rasptune ~# cd /sys/class/pvrusb2/sn-7836611 root@rasptune:/sys/class/pvrusb2/sn-7836611# echo PAL-Nc ctl_video_standard_mask_active/cur_val root@rasptune:/sys/class/pvrusb2/sn-7836611# v4l2-ctl --set-freq 163.25 Frequency set to 2612 (163.25 MHz) root@rasptune:/sys/class/pvrusb2/sn-7836611# v4l2-ctl --log-status Status Log: [ 9525.734707] pvrusb2: = START STATUS CARD #0 = [ 9525.737103] cx25840 0-0044: Video signal: present [ 9525.737124] cx25840 0-0044: Detected format: PAL-Nc [ 9525.737137] cx25840 0-0044: Specified standard:automatic detection [ 9525.737165] cx25840 0-0044: Specified video input: Composite 7 [ 9525.737180] cx25840 0-0044: Specified audioclock freq: 48000 Hz [ 9525.745622] cx25840 0-0044: Detected audio mode: forced mode [ 9525.745665] cx25840 0-0044: Detected audio standard: forced audio standard [ 9525.745680] cx25840 0-0044: Audio microcontroller: detecting [ 9525.745692] cx25840 0-0044: Configured audio standard: undefined [ 9525.745704] cx25840 0-0044: Configured audio mode: MONO1 (LANGUAGE A/Mono L+R channel for BTSC, EIAJ, A2) This is interesting. The cx25840 is what demodulates the audio from an analog signal. What we see here strongly suggests that it isn't working properly. All 5 of these lines look suspect (forced, still detecting, undefined standard, mono audio mode). Unfortunately I can't guess as to why. If I were directly seeing this here I'd probably be combing through the cx25840 module code in an attempt to see what generates those lines of output and to trace back from that point. There may be debug trace you can turn on in the cx25840 kernel module that may yield more clues as to how it is getting into this state. One thing is for sure - if the cx25840 hardware is not detecting audio yet, then everything downstream of this point (and that's basically everything) has no chance. [ 9525.745715] cx25840 0-0044: Specified audio input: Tuner (In8) [ 9525.745726] cx25840 0-0044: Preferred audio mode: stereo [ 9525.756834] cx25840 0-0044: IR Receiver: [ 9525.756866] cx25840 0-0044: Enabled: no [ 9525.756878] cx25840 0-0044: Demodulation from a carrier: disabled [ 9525.756887] cx25840 0-0044: FIFO: disabled [ 9525.756912] cx25840 0-0044: Pulse timers' start/stop trigger: disabled [ 9525.756924] cx25840 0-0044: FIFO data on pulse timer overflow: overflow marker [ 9525.756934] cx25840 0-0044: FIFO interrupt watermark: half full or greater [ 9525.756943] cx25840 0-0044: Loopback mode: normal receive [ 9525.756960] cx25840 0-0044: Max measurable pulse width: 318144512 us, 318144512000 ns [ 9525.756970] cx25840 0-0044: Low pass filter: disabled [ 9525.756979] cx25840 0-0044: Pulse width timer timed-out: no [ 9525.756988] cx25840 0-0044: Pulse width timer time-out intr: enabled [ 9525.756997] cx25840 0-0044: FIFO overrun: no [ 9525.757005] cx25840 0-0044: FIFO overrun interrupt: enabled
Re: [pvrusb2] Hauppauge HVR-1900 - PAL-Nc, no audio
Dermot: Actually I think you were on the right track. ALSA has nothing to do with capture of audio into the MPEG output file. Of course, ALSA may have everything to do with playback on your computer, but if there's already no audio in the MPEG file itself (easily proven by trying to play the file on multiple different computers), then ALSA is not involved. In times past when I've dealt with bugs involving no captured audio, the usual suspect was that the pvrusb2 hardware was being told to use the wrong broadcast standard. It's possible to choose a standard that is close enough for, say, video to work but not audio. There are different modulation standards and frequencies for the embedded audio and if that is set wrong, then of course there will be no audio. Making matters somewhat more confusing is that in many cases, the hardware can successfully guess the correct audio configuration even when the wrong standard is set. So you can get cases where, for example, someone with a 24xxx series device will get working audio using standard XYZ while someone else in the same country but using a 29xxx device with the same XYZ standard still won't hear any audio :-( The pvrusb2 driver does not directly program the audio configuration in the capture device. That job is left to the various chip drivers, e.g. cx25840.ko in your case. What the pvrusb2 driver does do however is to communicate the chosen standard out to the various chip drivers; then it is up to each chip driver to use that information to create the appropriate local configuration in the hardware. I would give odds that the problem involves use of the wrong video standard. Unfortunately I can't tell you what the right one would be. But you can certainly experiment with the different choices and see what might actually work better. It generally isn't possible to physically harm the hardware with a wrong video standard, so I would encourage some experimentation... You can use the pvrusb2 driver's sysfs interface to get detailed access to all the possible video standards. You mentioned that msp3400.ko is loaded - ignore that. It actually isn't used for the HVR-1900, rather audio processing on the HVR-1900 uses the cx25840.ko driver (which is a combined audio and video processor). -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Some install guidance on WinTV PVR2 USB
FYI, I tested a power brick here: Outside sheath is negative, inside is positive. The same power brick is used for 29xxx, 24xxx, HVR-1950 and probably also HVR-1900 (I don't have the HVR-1900 but the pattern would fit). The brick I have is rated with a universal 120 - 240 VAC input, 6VDC output. Unloaded, I measured 6.2VDC. Very likely it's a switching regulator (way too light to be transformer based). -Mike On Wed, 20 Mar 2013, Mike Isely wrote: I will follow up with the correct polarity (by checking what I do have). However if you already tried it both ways, then odds are likely that you already let the magic smoke out. Low voltage digital logic behaves very destructively if fed reversed power. Generally if the device in question expects unregulated power coming in and has its own on-board regulator, then there's a *chance* it might survive reversed power - because only the regulator will have been exposed to the condition. Or maybe just the regulator got fried which might be fixable (especially if its a cheap little 7805 3-terminal linear device). Given that the brick supplies 6V and the onboard logic there is probably wanting 5V, then there very well may be an onboard regulator. -Mike On Wed, 20 Mar 2013, Lorne Shantz wrote: Thank you very much for the great reply. I just got done redoing the office floor and now I can't find the derned thing. One more question that I had was... I misplaced the power supply awhile back. I know it is 6 volts DC, but it doesn't indicate the polarity. I am going to assume that the center is + and the outside is -, since that is the way their new stuff is. Is that correct? I suppose I ruined it by trying it both ways, although no smoke, or any indication I smoked it. --- On Tue, 3/19/13, Mike Isely is...@isely.net wrote: From: Mike Isely is...@isely.net Subject: Re: [pvrusb2] Some install guidance on WinTV PVR2 USB To: Communications nexus for pvrusb2 driver pvrusb2@isely.net Date: Tuesday, March 19, 2013, 7:30 PM Lorne: These days the in-kernel pvrusb2 driver should work great without any special setup beyond perhaps ensuring you have the firmware files installed somewhere visible to udev. Kernel 3.4.33 is reasonably new and should just work. I imagine most distribution kernels probably compile this driver for you, either into the kernel package itself or maybe as a media package add-on. If you searched /lib/modules recursively, you should be able to find pvrusb2.ko in there. Things I would check for: 1. Ensure the pvrusb2 device's power brick is plugged in and the unit is actually getting power. If that isn't happening, then *nothing* else will work. 2. Even if the firmware files are not installed, the pvrusb2 driver should still attempt to attach to the hardware and you should see corresponding messages in the kernel log (i.e. dmesg) - leading up to the point where it gives up for lack of available firmware. So if you're not seeing any messages, then the lack of firmware is likely not the issue. 3. Even if the pvrusb2 driver itself were completely borked or otherwise missing, you should still be able to see the hardware show up to the kernel via either running the usbview tool or just cat /proc/bus/usb/devices. If you can't see anything there that suggests the presence of the pvrusb2 hardware, then the driver situation won't matter at all. (This would suggest the device is not getting power or there is a communication issue between the PC and the device.) If there is a suspicion about, say, a bad USB hub or USB cable, then I would (obviously) try swapping around those parts. If you have another PC (or laptop nearby), you can also try plugging the device in there - if only to see if you get a reaction from the operating system, e.g. if it were Windows you might be prompted to install drivers or if it were Linux you could notice the appearance of the hardware in your dmesg output. Such a thing would at least tell you that the hardware is not dead. If none of that produces a reaction, then I'd probably re-examine step #1 above a lot more closely. If you have a voltmeter nearby then for example I'd check that you're getting 6 volts at the DC plug end... I have one laptop here that - with particular (older) kernel versions - has trouble recognizing the presence of the old (first generation) 29xxx model series. It's a really bizarre thing, requiring a specific combination of computer, kernel version, and a 29xxx model. I've never been able to track down why this is, except to suspect that the FX2 boot firmware in that model series has a quirk that is upsetting the USB
Re: [pvrusb2] Some install guidance on WinTV PVR2 USB
I will follow up with the correct polarity (by checking what I do have). However if you already tried it both ways, then odds are likely that you already let the magic smoke out. Low voltage digital logic behaves very destructively if fed reversed power. Generally if the device in question expects unregulated power coming in and has its own on-board regulator, then there's a *chance* it might survive reversed power - because only the regulator will have been exposed to the condition. Or maybe just the regulator got fried which might be fixable (especially if its a cheap little 7805 3-terminal linear device). Given that the brick supplies 6V and the onboard logic there is probably wanting 5V, then there very well may be an onboard regulator. -Mike On Wed, 20 Mar 2013, Lorne Shantz wrote: Thank you very much for the great reply. I just got done redoing the office floor and now I can't find the derned thing. One more question that I had was... I misplaced the power supply awhile back. I know it is 6 volts DC, but it doesn't indicate the polarity. I am going to assume that the center is + and the outside is -, since that is the way their new stuff is. Is that correct? I suppose I ruined it by trying it both ways, although no smoke, or any indication I smoked it. --- On Tue, 3/19/13, Mike Isely is...@isely.net wrote: From: Mike Isely is...@isely.net Subject: Re: [pvrusb2] Some install guidance on WinTV PVR2 USB To: Communications nexus for pvrusb2 driver pvrusb2@isely.net Date: Tuesday, March 19, 2013, 7:30 PM Lorne: These days the in-kernel pvrusb2 driver should work great without any special setup beyond perhaps ensuring you have the firmware files installed somewhere visible to udev. Kernel 3.4.33 is reasonably new and should just work. I imagine most distribution kernels probably compile this driver for you, either into the kernel package itself or maybe as a media package add-on. If you searched /lib/modules recursively, you should be able to find pvrusb2.ko in there. Things I would check for: 1. Ensure the pvrusb2 device's power brick is plugged in and the unit is actually getting power. If that isn't happening, then *nothing* else will work. 2. Even if the firmware files are not installed, the pvrusb2 driver should still attempt to attach to the hardware and you should see corresponding messages in the kernel log (i.e. dmesg) - leading up to the point where it gives up for lack of available firmware. So if you're not seeing any messages, then the lack of firmware is likely not the issue. 3. Even if the pvrusb2 driver itself were completely borked or otherwise missing, you should still be able to see the hardware show up to the kernel via either running the usbview tool or just cat /proc/bus/usb/devices. If you can't see anything there that suggests the presence of the pvrusb2 hardware, then the driver situation won't matter at all. (This would suggest the device is not getting power or there is a communication issue between the PC and the device.) If there is a suspicion about, say, a bad USB hub or USB cable, then I would (obviously) try swapping around those parts. If you have another PC (or laptop nearby), you can also try plugging the device in there - if only to see if you get a reaction from the operating system, e.g. if it were Windows you might be prompted to install drivers or if it were Linux you could notice the appearance of the hardware in your dmesg output. Such a thing would at least tell you that the hardware is not dead. If none of that produces a reaction, then I'd probably re-examine step #1 above a lot more closely. If you have a voltmeter nearby then for example I'd check that you're getting 6 volts at the DC plug end... I have one laptop here that - with particular (older) kernel versions - has trouble recognizing the presence of the old (first generation) 29xxx model series. It's a really bizarre thing, requiring a specific combination of computer, kernel version, and a 29xxx model. I've never been able to track down why this is, except to suspect that the FX2 boot firmware in that model series has a quirk that is upsetting the USB stack for a particular type of USB host controller combined with a particular kernel version. Hope that helps... -Mike On Mon, 18 Mar 2013, Lorne Shantz wrote: I had a it running a few years back until a system rebuild. I gave up because I couldn't remember how I had it working and just went with a PCI card. Well now I'm using a newer MB, that does not have any PCI slots. I really need to get this running. Kernel image: /boot/vmlinuz-3.4.33-2.24-desktop Initrd image: /boot/initrd-3.4.33-2.24-desktop Root device: /dev
Re: [pvrusb2] Best MPEG2 Stream Editor for Hauppauge Created MPEG2 Files
% 3 0 Warning! FPS changed 47.952 - 59.940 (-11.988010) [7] A:34538.4 V:34539.9 A-V: -1.503 ct: -0.256 300/153 9% 8% 0.2% 3 0 ---End of Mplayer Snip--- The Hauppauge audio/video sync was such a popular problem on the message boards without any resolution, and the only thing that comes to my mind is it may have been fixed with a firmware update, or a unique work-araound applied quietly within mplayer. Well, one things certain, I'm sure I'm on the right mailing list -- as if anybody knows, it would be people here! And, as I said, not going to pull my hair out on this. I usually just watch things once and discard the recorded show anyways. Likely the issue is only with TV broadcasted material and not with composite input recording. -- Roger http://rogerx.freeshell.org/ ___ pvrusb2 mailing list pvrusb2@isely.net 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] new kernel breaks hauppuage pvrusb2 and hvr-1950 withmythtv
I plan on some testing later on today (currently building a small pile of new kernel versions) and hopefully should have more answers soon. On Thu, 20 Dec 2012, Daniel Woo wrote: Even though I restart the mythbackend b/c of the permissions on /dev/video0, could this still be the problem? I don't understand this statement. Are you running something to change the permissions on /dev/video0 after the fact? It would be much better in that case to set up a udev rule so it's correct the first time, or ensure that the mythtv user is a member of the group associated with /dev/video0. Shouldn't mythbackend recheck the tuner on restart? I would expect mythbackend to look at all its tuners every time it starts. What do you think the problem is for the 2.x kernels? Tv-viewer won't work for them. Unsure about this. It's been a while since I've had to fix things in this driver, but I plan additional investigation hopefully later today. The pvrusb2 driver itself hasn't had any substantial changes in quite a while. However it's operating in a video4linux environment that is a moving target. There's always a concern that a surrounding change might break the driver. That's the sort of thing I will be looking at. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] PVR USB2 - how to check if it's dead? [SOLVED]
On Thu, 20 Dec 2012, Helmut Jarausch wrote: On 12/19/2012 04:40:08 PM, Mike Isely wrote: Hi Mike, that was my testing all the time. Now, I've traced xawtv step for step. The single control which is needed by my device to even produce a single byte of output on /dev/video0 is v4l2-ctl -s pal i.e. setting the video standard to PAL. Oh, of course. I'm getting slow. The driver tries to pick a default video standard based on the hardware it has encountered but that is an imperfect process at best. But it's also true that any app which uses a V4L2 device really has the responsibility to set the correct video standard to be used, which is what xawtv did for you there. I tend to miss this because my area is NTSC and the driver tends to start in that mode automatically for me. Is there any means to set this without v4l2-ctl ? Yes, there is a sysfs way to do this... Here, I do not have /sys/class/pvrusb2/sn-8039400/ctl_video_standard I believe there was a change a while back which eliminated that particular control (because the underlying V4L feature I believe went away). However you can achieve the same effect with another control. IIRC, it's ctl_video_standard_mask_active. I can e-mail additional detail about that, if you haven't already figured it out. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] new kernel breaks hauppuage pvrusb2 and hvr-1950 withmythtv
The driver *should* work in recent kernels without having to do anything out of the ordinary. With that said, I guess now I'm about to eat those words :-) I'll post additional information about what's going on once I do my tests here. This is another task right now for me in a long line of tasks at the moment. -Mike On Fri, 21 Dec 2012, Daniel Woo wrote: I tried to install v4l-dvb b/c nothing else worked. It installed to a new directory, so the old usbpvr2 driver was still used by linux. -Original Message- From: Mike Isely Sent: Friday, December 21, 2012 2:34 PM To: Communications nexus for pvrusb2 driver Subject: Re: [pvrusb2] new kernel breaks hauppuage pvrusb2 and hvr-1950 withmythtv On Fri, 21 Dec 2012, Daniel Woo wrote: Since I've gotten the pvrsub2 to work on mythbuntu 10.04 kernel 2.6.32, that's the one I'm going to concentrate getting the hvr-1950 to work. Should I upgrade my kernel to 2.6.35 or 2.6.38? Anyone know which version of the pvrsub2 driver works best with 2.x kernels? It should in theory work equally well with any kernel from the past few years. Does anyone know how to get the v4l-dvb to install to the kernel directory? It keeps making its own directory to install to. Oh wait, you're installing a v4l-dvb snapshot on top of the kernel? That's a whole new variable here. Since there haven't been any real changes in a while, the included in-kernel pvrusb2 driver should be fine and should not need any additional help. Is there another reason you're bringing in other stuff? -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] PVR USB2 - how to check if it's dead?
VIDIOC_QUERYCTRL/MENU: FAIL fail: v4l2-test-controls.cpp(295): returned control value out of range fail: v4l2-test-controls.cpp(383): invalid control 00980909 test VIDIOC_G/S_CTRL: FAIL fail: v4l2-test-controls.cpp(571): g_ext_ctrls returned an error (22) test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL fail: v4l2-test-controls.cpp(713): subscribe event for control 'Brightness' failed test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 9 Private Controls: 0 Input/Output configuration ioctls: fail: v4l2-test-io-config.cpp(46): STD cap not set, but could still get a standard fail: v4l2-test-io-config.cpp(132): STD failed for input 0. test VIDIOC_ENUM/G/S/QUERY_STD: FAIL test VIDIOC_ENUM/G/S/QUERY_DV_PRESETS: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) Format ioctls: fail: v4l2-test-formats.cpp(236): fmtdesc.pixelformat not set test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: FAIL test VIDIOC_G/S_PARM: OK test VIDIOC_G_FBUF: OK (Not Supported) fail: v4l2-test-formats.cpp(379): unknown pixelformat for buftype 1 test VIDIOC_G_FMT: FAIL test VIDIOC_TRY_FMT: OK (Not Supported) test VIDIOC_S_FMT: OK (Not Supported) test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK (Not Supported) Total: 38, Succeeded: 25, Failed: 13, Warnings: 0 ___ pvrusb2 mailing list pvrusb2@isely.net 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] question about managing HVR-1900 from an embedded host
a pretty simple protocol: You send a command byte followed by some number of bytes specific to the command, and then just read back the result. All FX2 commands are run this way. There is a general-purpose function in the pvrusb2 driver that implements the host side of this protocol. The function name is pvr2_send_request_ex() and can be found in pvrusb2-hdw.c. Example commands of this sort include requests for I2C data transfer, read/write of cx23416 registers, etc... 11) host translates PS to TS, sending output video to FPGA via parallel interface The pvrusb2 driver currently doesn't do any processing on the received stream. But obviously what you do with the received packets is up to you... 12) repeat from 10 Yes. In the case of the pvrusb2 driver, this is done with a pool of request URBs, which makes sense since the USB stack in Linux is naturally asynchronous. The pvrusb2 driver always tries to keep some minimum number of URBs queued for reception. Received data is kept in a ring buffer until the user application reads out the data - presumably to keep the stream running smoothly, the user application will always have a read() posted or at least a select() or poll() pending to the driver's open device node. In your PIC environment of course this is probably going to be completely different... Notes: 13) is BT565 is used as video path between CX25840 to CX23416, if not, then what ? I believe it is. I have been told in the past that this is the data format used between those two chips, however I've never had (yet) to implement anything that relied on this knowledge. From the viewpoint of the pvrusb2 driver, magic happens between those two parts :-) 14) looks like Linux uses v4l-pvrusb2-73xxx-01.fw (16,384 bytes) to load into FX2 Yes. 15) looks like Linux uses v4l-cx25840.fw (16,382 bytes) to load into CX25840 Yes. 16) looks like Linux uses v4l-cx2341x-enc.fw (376,836 bytes) to load into CX23416 Yes. Any corrections, pointers to relevant web pages, or other help to start filling in the great voids of understanding will be most appreciated. Many thanks, Mark PS Phew ! References 1. http://www.idesignz.org/DigiLiteZL/DigiLiteZL.htm 2. http://www.idesignz.org/DigiLiteZL_FPGA/DigiLiteZL-FPGA.htm Hope that helps. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] hauppage hvr-1900 on raspberry pi
Emmanuel: This is good stuff to know and thanks for posting it! And holy cow, how many people go to that level of detail to tune the performance of a Linux system? (Though of course I realize your case was unusual.) -Mike Isely On Mon, 25 Jun 2012, Emmanuel Touzery wrote: OK my final mail on the topic, since it's a bit off topic on this list. I got it to work reliably without cuts, the secret was in extra settings, especially for IPv4 tuning. my whole series of settings is here: echo 5 /proc/sys/kernel/sched_rt_period_us echo 2 /proc/sys/net/core/netdev_max_backlog echo 250 /proc/sys/net/core/optmem_max echo 16777216 /proc/sys/net/core/wmem_default echo 16777216 /proc/sys/net/core/wmem_max echo 1 /proc/sys/net/ipv4/tcp_low_latency echo 75 /proc/sys/kernel/sched_min_granularity_ns echo 60 /proc/sys/kernel/sched_latency_ns echo -1 /proc/sys/kernel/sched_rt_runtime_us I'm also shutting down cron, xinetd, and ntp before recording. crazy but i HAD cuts because of ntp triggering once per hour. i also increased the IPv4 incoming buffers on my PC on the other side: echo 16777216 /proc/sys/net/core/rmem_default echo 16777216 /proc/sys/net/core/rmem_max mplayer for recording DVB-T, cat with flywheel for AV IN, and then: sudo chrt -f -p 99 pid sudo renice -n -20 pid sudo ionice -c1 -ppid and note that this is over wifi. also works fine when i stream a video over DLNA at the same time. anyway, all is well that ends well, in the end it works fine. now if only there could be support for the IR blaster on the HVR-1900 it would be a perfect setup :-) emmanuel On Sun, Jun 17, 2012 at 11:24 AM, Emmanuel Touzery etouz...@gmail.comwrote: well i researched a bit more, now i'll try dvbstream and vlc streaming. On Sun, Jun 17, 2012 at 10:48 AM, Emmanuel Touzery etouz...@gmail.comwrote: Otherwise if someone is interested, for now I still can't make DVB-T recording work smoothly. Ethernet was a big help but not quite enough. I've made quite some tuning, using mplayer instead of tzap+cat, and then strongly prioritize that mplayer process: chrt 99 with FIFO scheduling, nice -20, ionice -c1 (though i guess that last one doesn't make a real difference), and even some scheduler tuning to increase latency and prioritize real time processes: echo -1 /proc/sys/kernel/sched_rt_runtime_us echo 4 /proc/sys/kernel/sched_rt_period_us echo 60 /proc/sys/kernel/sched_latency_ns echo 40 /proc/sys/kernel/sched_min_granularity_ns I've also tried NFS, udp and tcp, with max block size (1Mb!), 32kb and 64kb, but i still get cuts. I actually now get 15 minute blocks without cuts. But even only every 15 minutes, a cut is a cut... i also tried overclocking the pi without big differences (i actually didn't try to overclock it on the latest settings but i guess it also wouldn't help). i'll see, i'm still not quitting but getting closer :-/ emmanuel On Thu, Jun 7, 2012 at 10:08 PM, Felix Lighter felix.ligh...@gmail.comwrote: I'm glad that Ethernet helped the situation. Beware USB - it's also notorious for aggressively interrupting the CPU. 480Mbps USB2 comes at a high price, CPU-wise. And as you point out, it's already busy capturing video. I would definitely suggest looking into NFS, since you should be able to lighten the CPU load even further by increasing the write buffer size (in the mount options). Take a look and see whether Samba also offers any options for tuning network usage / bandwidth. Cheers, FL On 7 June 2012 15:43, Emmanuel Touzery etouz...@gmail.com wrote: Hello, Thanks for a lot for the tip. I tried quickly with a SMB share which I already had setup and... yes it seems better! Although I really can't believe it, it does seem to help. I'm glad you give me a plausible explanation with DMA though, because that's the last thing I was expecting. Especially since my network is not wired and though it's plugged using ethernet on the pi, it reaches my computer through wifi. I'll try more. I didn't try much with USB keys too because I measured a slightly lower throughput than with the SD card and I read that on the pi, the throughput for USB+ethernet is shared. I figured, since USB is already busy receiving the data from the video capture device, better save on the SD... but apparently not. But really I can't conclude much until I test more. The first tests seems to say networkusbsd. but even on network I've seen a skip. Though it's on a non-preempt kernel and without any sort of buffering (eg flywheel or fifo), nor nice or chrt. Anyway, it seems there's not much hope of configuring something differently on the driver or the kernel, so for now I'll focus on where to save: SD, network, usb, with or without FIFO and so on. And maybe also NFS
Re: [pvrusb2] My tuners occasionally get stuck
On Wed, 11 Apr 2012, Jan Ceuleers wrote: Jan Ceuleers wrote: I have now done two things: - automated the power cycling of the tuners whenever a zero-length recording has just finished (using a power socket controlled by sispmctl). - installed kernel 3.3.0. The issue has not recurred since, but it was not unusual for it not to occur for 2 weeks and then to happen a few times the next week. So I can't yet tell whether the kernel upgrade has solved it. But I do hope that if the issue recurs while I'm away the damage will be limited by my power-cycling rig. (That's unless USB really goes haywire again because the power socket is also controlled through USB). I'll report back in a little while. It's been 20 days since I did the above, and the issue still has not recurred. I will keep touching wood, but my working hypothesis is that the problem was fixed by the kernel upgrade. Glad to hear that! -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] My tuners occasionally get stuck
Jan: I think Gary has a good point here. Another angle you should consider is something I've seen here repeatedly over time, having nothing to do with the software: power. External USB devices that are not USB-powered of course rely on their own power supply. Cheap wall-wart power adapters simply do NOT have the resilience of a PC power supply when it comes to dirty power. A nearby A/C compressor cycling on/off can glitch the power enough to crash an externally-wall-wart-powered USB device while PC internal power supplies usually have enough internal energy storage (i.e. capacitors) to ride out an event like that. I've *personally witnessed* this sort of thing in the past and there have been repeated reports of people with randomly crashing USB devices that magically fix themselves when their power supply is moved behind, say, a UPS or sometimes just a good surge protector (depending on the severity of the power issue). Your report mentions all 4 tuners crashing at once, which admittedly might be more likely a kernel USB stack bug. Note that the pvrusb2 driver instances itself once for every device you have connected. Since the driver instances generally operate independantly of one another, a driver misbehavior should not be able to cause simultaneous failure of all tuners at once. The fact that a system reboot does not clear the problem is another factor that suggests the foul-up is in the tuners themselves, though the trigger could still be the kernel USB stack. Since you have 4 tuners, you have a unique opportunity to try an experiment: Put just 2 of the tuners behind a UPS. Wait for the next failure. Do all four tuners fail at once again or just two? If only 2 fail now then that's almost a smoking gun clue indicating bad power. If you still have all 4 failing at once then I'd put my money on Gary's theory: a kernel USB stack bug. Another idea - if you have a portable USB hard drive, plug it in as well and run a repeated massive tar command to generate large amounts of I/O. When you next get a failure, does the hard drive survive while the tuners still fail? If the hard drive fails too, then you've just exonerated the entire V4L subsystem and I'd then be looking really hard at the USB stack. Hope that helps. -Mike On Wed, 21 Mar 2012, Jan Ceuleers wrote: On 21/03/12 17:09, Gary Buhrmaster wrote: conjecture Understood, and thanks for your insights. Almost certainly a kernel usb issue. The 1900s and the APC device are likely victims, not the cause. These types of bug reports (the 'clear tt' ones) with usb devices have a tendency to reoccur on some irregular basis as the usb subsystem in the kernel gets improved. Usually the problem is patched in the next kernel rev (because others have reported it), although sometimes you have to do the git bisect to find the patch that was special to get it fixed. Indeed my thoughts align with yours: the tuners are significant USB traffic generators which are probably more likely than other devices to expose weaknesses in the kernel USB subsystem. But I did google the kernel log messages without success (probably because they are so terse). I recently upgraded from Ubuntu 10.10 to 11.04, and I had this problem under 10.10 as well. So the problem is not restricted to the 2.6.38 kernel in 11.04. But I will try a more recent kernel as well before taking it to linux-usb if I still need to. Thanks, Jan ___ pvrusb2 mailing list pvrusb2@isely.net 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] My tuners occasionally get stuck
On Sun, 25 Mar 2012, Gary Buhrmaster wrote: On Sun, Mar 25, 2012 at 19:46, Mike Isely is...@isely.net wrote: Another idea - if you have a portable USB hard drive, plug it in as well and run a repeated massive tar command to generate large amounts of I/O. When you next get a failure, does the hard drive survive while the tuners still fail? If the hard drive fails too, then you've just exonerated the entire V4L subsystem and I'd then be looking really hard at the USB stack. The op mentioned that he also had an APC UPS device that hung at the same time (although if I interpreted the posting correctly, that one recovered after the machine reboot; maybe it was not as confused and dazed as the pvrusb devices and was able to be reinitialized at boot). Ah, I missed that part. Yes this is a pretty good clue that the USB stack did something strange. AFAIK the APC device does not use the V4L subsystem (although you can never tell, APC is working at doing entire DC management, and maybe this one takes video/pictures of the site). :-) Last time I checked, V4L software still have nothing to do with UPS devices! So, I am sticking with my WAG. I agree. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
[pvrusb2] break with the past...
Everyone: To date I have worked to ensure that the standalone pvrusb2 driver stays at least compilable with old kernels dating all the way back to 2.6.12.x - that's 7 years ago! Even the snapshot released a few days ago I successfully verified compilation against a kernel that old. By standalone pvrusb2 driver, what I mean is the driver tarball that you can download from the pvrusb2 web site - as opposed to the pvrusb2 driver version that has also been included with the kernel tree since about 2.6.18. I've been able to do this with the standalone driver because, well, I've been very careful with #ifdef'ing implementations in the code and minding how the environment has changed as the kernel V4L have changed over time. At some point however there will need to be a break with the past. I suspect that the standalone driver would shrink considerably if I were to cut compatibility off at, for example, 2.6.32.x. So a question I have for people here is this: What is the *OLDEST* kernel for which you are using the standalone pvrusb2 driver? Don't count any uses of the in-kernel pvrusb2 driver - that's bound into the specific kernel version so obviously nothing there would ever change. What I'm looking for is an idea for just how far back it makes sense to continue with backwards compatibility for the standalone driver. What is the *OLDEST* kernel version for which you are using the standalone pvrusb2 driver? -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
[pvrusb2] New driver snapshot: pvrusb2-mci-20120219
A new pvrusb2 driver snapshot is available. This snapshot contains a few minor changes, and several large changes. I'd VERY much appreciate it if people could try this out against kernel versions 3.0.x or higher - the larger changes come into play with those kernels. I've done some testing here but it's difficult to hit all the dark corners these days given the variety of hardware handled by the driver (and the fact that I don't even have some of that hardware here). The ioctl2 change is the big one. If all is well with it, you should not notice a thing... If this looks good, i.e. I don't hear of anyone screaming in pain over this in the next week or so, I will work on getting these changes pushed back into the kernel. Note also that Mike Krufky's patch, mentioned over the past week, is here too: (+) Fix 7MHz and 8MHz DVB-T tuner support for HVR-1900 rev D1F5 (Mike Krufky). (+) Enable use of ioctl2 internal V4L interface. This is a large change but it was a very long time in coming. Thanks to Hans Verkuil for blazing the trail on this. This change completely alters how the pvrusb2 driver interacts with the V4L API as seen by applications. Previously the pvrusb2 driver implemented the actual ioctl() functions directly; now this is done in the V4L core via a function dispatch table out to the driver for each specific API function. This strategy allows for more interesting flexibility in that the V4L core can directly implement things that would be a nuisance for the driver (like video standards enumeration). All ongoing V4L development uses ioctl2 so we really must participate in this in order to keep up. Note: Since the stand-alone driver keeps backwards compatibility with older kernels, this functionality is only compiled-in when compiling against kernel versions 3.0.x or newer. The earliest this change will find its way to the kernel tree will probably not be until 3.4.x or 3.5.x. (+) Tie-in querystd operation (new with previous snapshot) with use of ioctl2. (+) Make output of querystd available via sysfs interface, by implementing as an internal control ID. (+) Fix truncated video standard name strings that sometimes happened in sysfs output. (+) Adjust V4L's enumeration of video standards on behalf of this driver (which happens now with use of ioctl2) to be limited to just those standards that we know the hardware supports. (+) Fix querystd implementation to be limited to just those standards that we know the hardware supports. (+) Remove pvrusb2 driver's own implementation for enumerating video standards. With the use of ioctl2, this now happens on our behalf inside the V4L core. I have NOT checked that the standards list generated is the same, but empirical testing so far looks OK. Also note that in order to remain backwards compatible, the driver internal implementation is still compiled in if ioctl2 is not used. Said another way, this change only affects those who compile the standalone driver against kernel versions 3.0.x or newer. This was another large alteration to the driver. As usual, the pvrusb2 web site can be found at: http://www.isely.net/pvrusb2/pvrusb2.html -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Problems with HVR-1900 (DVB)
I plan work on the driver this weekend...
-Mike
On Wed, 15 Feb 2012, Michael Krufky wrote:
The firmware is irrelevant to the problem that you are having. As for
supporting other versions of the tda10048 firmware, it would be a good
idea to post something about it on the linux-media mailing list (
linux-media linux-me...@vger.kernel.org )
Either way, I'm glad that my patch helped you... Hopefully it will get
merged into the kernel asap (hint hint) since it so obviously fixes a
major bug. :-)
Cheers,
Mike Krufky
On Wed, Feb 15, 2012 at 5:51 PM, Ales Novy ales.n...@gmail.com wrote:
Thanks Michael, the patch works!
Interesting is that it works with both dvb-fe-tda10048-1.0.fw I have. Is the
firmware related only to particular device(s)? Would it be useful to send
the extracted (newer) firmware to a repository and change the tda10048
module to work with more firmware versions?
Regards,
ales
On Wed, Feb 15, 2012 at 10:38 PM, Michael Krufky mkru...@linuxtv.org
wrote:
I posted a patch last week that should fix this problem. Please try this
patch:
http://git.linuxtv.org/mkrufky/hauppauge.git/commitdiff_plain/7202e49582611ccd70e93db8b8f75c0811015444
From: Michael Krufky mkru...@linuxtv.org
Date: Tue, 7 Feb 2012 16:28:33 + (-0500)
Subject: pvrusb2: fix 7MHz 8MHz DVB-T tuner support for HVR1900 rev D1F5
X-Git-Url: http://git.linuxtv.org
pvrusb2: fix 7MHz 8MHz DVB-T tuner support for HVR1900 rev D1F5
The D1F5 revision of the WinTV HVR-1900 uses a tda18271c2 tuner
instead of a tda18271c1 tuner as used in revision D1E9. To
account for this, we must hardcode the frontend configuration
to use the same IF frequency configuration for both revisions
of the device.
6MHz DVB-T is unaffected by this issue, as the recommended
IF Frequency configuration for 6MHz DVB-T is the same on both
c1 and c2 revisions of the tda18271 tuner.
Signed-off-by: Michael Krufky mkru...@linuxtv.org
Cc: Mike Isely is...@pobox.com
Cc: sta...@kernel.org
---
diff --git a/drivers/media/video/pvrusb2/pvrusb2-devattr.c
b/drivers/media/video/pvrusb2/pvrusb2-devattr.c
index c6da8f7..d8c8982 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-devattr.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-devattr.c
@@ -320,7 +320,17 @@ static struct tda829x_config tda829x_no_probe = {
.probe_tuner = TDA829X_DONT_PROBE,
};
+static struct tda18271_std_map hauppauge_tda18271_dvbt_std_map = {
+ .dvbt_6 = { .if_freq = 3300, .agc_mode = 3, .std = 4,
+ .if_lvl = 1, .rfagc_top = 0x37, },
+ .dvbt_7 = { .if_freq = 3800, .agc_mode = 3, .std = 5,
+ .if_lvl = 1, .rfagc_top = 0x37, },
+ .dvbt_8 = { .if_freq = 4300, .agc_mode = 3, .std = 6,
+ .if_lvl = 1, .rfagc_top = 0x37, },
+};
+
static struct tda18271_config hauppauge_tda18271_dvb_config = {
+ .std_map = hauppauge_tda18271_dvbt_std_map,
.gate = TDA18271_GATE_ANALOG,
.output_opt = TDA18271_OUTPUT_LT_OFF,
};
On Wed, Feb 15, 2012 at 3:48 PM, Ales Novy ales.n...@gmail.com wrote:
Hi,
I have HVR-1900 Model 73219 rev *D2F5* and I am not able to make it
work.
The analog part of the device work nicely but the DVB part does not.
From
the log (see bellow) everything looks good but DVB scan can not find any
channel. I've tried several things:
- Another dvb-fe-tda10048-1.0.fw firmware (than from
linux-firmware-nonfree
Ubuntu package). I manually extracted the firmware from Windows driver
(Hcw73bda.sys) and it has different size (25098 bytes) so I had to
modify
tda10048.ko module to disable firmware size check. Does not help, no
error
in the log but no channel found.
- Latest kernel 3.2.6-030206 but it also did not help.
Any idea what to try?
Thanks,
ales
Feb 15 20:15:32 velkej kernel: [ 86.312037] usb 2-1: new high-speed
USB
device number 2 using ehci_hcd
Feb 15 20:15:32 velkej mtp-probe: checking bus 2, device 2:
/sys/devices/pci:00/:00:1d.7/usb2/2-1
Feb 15 20:15:32 velkej mtp-probe: bus: 2, device: 2 was not an MTP
device
Feb 15 20:15:32 velkej kernel: [ 86.795508] Linux video capture
interface: v2.00
Feb 15 20:15:32 velkej kernel: [ 86.838739] pvrusb2: Hardware
description: WinTV HVR-1900 Model 73xxx
Feb 15 20:15:32 velkej kernel: [ 86.839154] usbcore: registered new
interface driver pvrusb2
Feb 15 20:15:32 velkej kernel: [ 86.839162] pvrusb2: V4L in-tree
version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner
Feb 15 20:15:32 velkej kernel: [ 86.839168] pvrusb2: Debug mask is 31
(0x1f)
Feb 15 20:15:33 velkej kernel: [ 87.859917] pvrusb2: Device
microcontroller firmware (re)loaded; it should now reset and reconnect.
Feb 15 20:15:33 velkej kernel: [ 87.891799] usb 2-1: USB disconnect,
device number 2
Re: [pvrusb2] Pops/Breaks on radio0 device
Roger: If it's working fine when you send the driver output to a file, then there's really nothing wrong with the driver. Odds are instead you might be instead dealing with a station that's weak enough that the pvrusb2 device might not be able to maintain a lock on the signal, resulting in real time breaks in the bit stream output, which might be upsetting the playback app due to the (probably tiny) pauses. There's NOTHING WRONG with the driver or the hardware in this case. You need to be having this conversation with the application developer, not here. I've seen a similar thing happen in mplayer with video/audio sync. See this link and read the last paragraph in the mplayer section: http://www.isely.net/pvrusb2/usage.html#mplayer The acid test is that if recording the data to a file clears the problem, then the driver is fine. -Mike On Thu, 2 Feb 2012, Roger wrote: I hooked-up my old pvrusb2 device today, a WinTV PVR USB2 Model 29xxx since the HVR-1950 cx25842 chip doesn't currently work, to be able to use the FM /dev/radio0 device and am noticing pops/breaks during audio playback. # mpeg2desc -a0 /dev/radio0 | mpg123 -T - Or # mpeg2desc -a0 /dev/radio0 | mpg321 --aggressive - Or $ mpeg2desc -a0 /dev/radio0 | madplay - And, using mplayer /dev/radio0 seems even more problematic. Increasing the cache does seem to resolve, but requires an excessive value for the -cache option (1-2 minutes). Recording to file for playing-back separately does resolve the pop/break problem, but isn't a convienient method of playing back a live stream. $ mpeg2desc -a0 /dev/radio0 /tmp/file.mp2 Seems to be a caching problem. I don't recall noticing this audio break problem within the past year or so. -- 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Looking for dvb-fe-tda10048-1.0.fw firmware
On Wed, 1 Feb 2012, Roger wrote: On Wed, Feb 01, 2012 at 03:49:10PM -0600, Mike Isely wrote: Sigh, I suppose I should fully document the script. It really is (IMHO) a very cool generic, useful tool for sniffing out and extracting just about any kind of binary needle from a huge haystack of Windows-supplied crud. I knew you modified it, but wasn't aware you rewrote the Perl script with a training function or with a intelligent universal firmware detection. I'm sure the majority of the public is also not aware of it at this point. Actually, the script has had the training feature in it pretty much from the day it was written, back around summer of 2005. It was never a modification. You might be thinking of a much much older extraction script that circulated prior to 2005. Back in Nov 2009, I made further improvements that gave the script the ability in many cases to successfully locate extract known firmware even when *not* previously trained. Using cryptographic sums makes possible some really cool stuff. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Looking for dvb-fe-tda10048-1.0.fw firmware
On Thu, 2 Feb 2012, Gary Buhrmaster wrote: On Thu, Feb 2, 2012 at 03:08, Mike Isely is...@isely.net wrote: I will be sending out an updated fwextract.pl with Gary's additional offsets. Plus I will integrate a small patch he sent that allows the script to run in a Windows environment as well (cygwin hosted? Active Perl?). I do not remember sending a patch for Windows. I suspect it was someone else who contributed that. Gary: You're right, and I apologize. The patch (and some more config data) is coming from someone else. What threw me was this statement: ...(I even emailed some new offsets for a new version of the driver from Hauppauge (same firmwire, just new offsets as I recall) to Mike, as the script requests)... I can't locate any such e-mail. The only other stuff I see from you (on the list or otherwise) was from 9-Jan and 10-Jan. Can you resend? -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Looking for dvb-fe-tda10048-1.0.fw firmware
On Wed, 1 Feb 2012, Gary Buhrmaster wrote: On Wed, Feb 1, 2012 at 20:07, Mike Isely is...@isely.net wrote: I can't locate any such e-mail. The only other stuff I see from you (on the list or otherwise) was from 9-Jan and 10-Jan. Can you resend? I sent it to the email in the script, which was a pobox.com address. I have resent it directly to your isely.net address. Got it this time. And having seen the date on the re-send, I realize now it was in fact sitting in my inundated inbox the ENTIRE TIME. Yes, folks, since May 2011. Color me embarrassed. Long story. I'll get this change included into fwextract.pl's configuration data. Expect to see something very soon. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Kernel oops in pvrusb2 driver
Handling hot unplug in any driver state has always been a difficult business. I'm actually kind of surprised that we've gone on this long (years) without another race like this being reported. I need to re-evaluate how this is being handled. It's possible that changes in the surrounding kernel may now be invalidating the strategy I had been using in the driver to cleanly self-tear-down when a hot-unplug happens. Actually it's been quite a while since I've dug into the driver. One of the key issues has been just not having enough time. However with the new year, one of the big time sinks that had been distracting me is now officially ended, so I will see about digging back into all this again! -Mike On Tue, 10 Jan 2012, Gary Buhrmaster wrote: On Tue, Jan 10, 2012 at 19:06, Mike Isely is...@isely.net wrote: Well even if it's unlikely, a kernel oops should still be chased. Was this on an SMP system? Yes, i5-2500, 4 CPUs. And I assume you were running the pvrusb2 driver that is part of the 3.1.7 kernel source tree (as opposed to compiling a separate driver)? Correct. I can test with additional debugging options, or compile driver code if that is helpful. I figured a reliable reproducer was a good first step in the process... Gary ___ pvrusb2 mailing list pvrusb2@isely.net 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] HVR-1950 IR Support
Roger: Just read through all of your messages. There's some good information in there, but this needs to be sorted out. Seems that lirc has come a long ways. I have a lot catching up to do here... -Mike On Sat, 24 Dec 2011, Roger wrote: For HVR-1950 lirc mplayer support - not using mplayer's default devinput and using lirc's devinput driver, I've configured using the following steps: 1) Recompile mplayer with lirc support. (I think this makes mplayer ignore the devinput events and will look for /dev/lirc0 events instead.) 2) Compile lirc userspace package with devinput driver. 3) Auto load the following modules in /etc/conf.d/modules during boot: modules=ir-kbd-i2c lirc_dev.ko rc-loopback ir-lirc-codec.ko rc-lirc 4) Have a /etc/lirc/lircd $HOME/.lircrc files. And /etc/conf.d/lirc has the previously mentioned: LIRCD_OPTS=-H devinput -d name=*HVR-1950* 5) irw should show events and mplayer now should recognize IR events as configured in $HOME/.lircrc. NOTE: Removing the pvrusb2 device or module while the lirc daemon is started will cause subsequent pvrusb2 reattachments to fail initializing and creating the /dev/dvb devices! I am not sure if using the in-kernel lirc_zilog.c staging driver will solve this at all as it does still attach itself to the pvrusb2 driver. This issue has always completely hindered my usage of the pvrusb2 remote control as I would never know when I would detach/reattach whether accidentally or intentionally. (Think the Windows driver might activate a script to unattach the IR daemon before loading it's hvr-1950 driver?) Any further suggestions from here? Should I experiment with the zilog driver? (I'll probably spend the next few hours configuring the only additional button I need, KEY_EXIT -- KEY_PAUSE KEY_PLAY and seek buttons already already worked with mplayer's devinput interface but need to be reconfigured using the lirc daemon.) -- Roger http://rogerx.freeshell.org/ ___ pvrusb2 mailing list pvrusb2@isely.net 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] hvr-1950 - analog side - problems using scantv
Remember that xawtv3 does not work with capture devices that emit mpeg video. Remember also that xawtv4 must be compiled to include mpeg support for it to have any chance at video capture. These details have been documented all along here: http://www.isely.net/pvrusb2/usage.html#xawtv The xawtv app is really old and I'm not even sure if anyone is maintaining it any longer. You might want to consider TV-Viewer as an alternative for the analog side: http://www.isely.net/pvrusb2/usage.html#TV-Viewer -Mike On Tue, 22 Nov 2011, Roger wrote: pvrusb2: firmware2 upload transfer failure pvrusb2: Clearing driver error statuss pvrusb2: firmware2 upload transfer failure pvrusb2: Clearing driver error statuss pvrusb2: firmware2 upload transfer failure pvrusb2: Clearing driver error statuss Never mind on the above. Looks like xawtv left things quite unstable for some reasons. Hard reset the device and things look good again. I can do cat /dev/video0 without problems. (Albeit, a black screen.) # cat /sys/class/pvrusb2/sn-6202710/ctl_input/cur_val television # echo 211250 /sys/class/pvrusb2/sn-6202710/ctl_freq_table_channel/cur_val -su: echo: write error: Numerical result out of range Now I'm stumped. -- 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Video Audio out of sync when using mencoder?
Roger:
Audio and video are muxed together by the capture device itself not by
anything about the host. There's basically NOTHING that any outside
software can do to interfere with that process.
Now, with that said, it's possible that the de-muxing might get screwed
up. If you're using mencoder to record I presume you're doing this in
order to transcode the stream to a different format, right? That means
that mencoder is going to de-mux the incoming stream and re-mux the
re-encoded results to your desired output format.
I have seen cases where mplayer will lose audio / video sync because
it's not getting the incoming stream data at a consistent rate - which
can happen if the capture device is having reception problems. A
drop-dead absolute method to determine if this is the case is to instead
of running mplayer directly on the stream that you instead cat the
device's output to file and THEN run mplayer on the file. If you do
this and all sync issues go away then it's mplayer doing something
strange - because when you're feeding it a ready-made file rather than a
live stream then there are no gaps / breaks.
Now you said you're using mencoder not mplayer. However they share the
same codebase and if mencoder is really de-muxing / re-muxing the stream
then I could see a similar problem happening. Try sending the capture
device output to a file for 5-10 minutes, then run that file through
mencoder and see if you're still having sync issues.
The last paragraph at the following URL talks about audio/video sync
issues with mplayer:
http://www.isely.net/pvrusb2/usage.html#mplayer
-Mike
On Sat, 19 Nov 2011, rogerx@gmail.com wrote:
Has anybody recently, or in the past, seen any HVR-1950 video/audio
out-of-sync
when recording using mencoder?
All of a sudden, I'm noticing video audio slowly going out of sync once the
video starts -- usually only detectable at first by mouth/audio sync and then
(randomly?) later one with video scenes audio?
I tested my boxes and can play a 720 MPEG2 Commercial DVD without issues. In
the past, I would copy my videos to another box and play them using a
'mplayer
on the fly resize for slow cpu's incantation' without sync issues. ie:
mplayer -vfm ffmpeg -lavdopts lowres=2:fast:skiploopfilter=all -idx \
-really-quiet -hardframedrop ${1}
CPU on all boxes is running around 26%, to 50% fullscreen, etc.
And, I don't play live video from the HVR.
I'm wondering if I encountered a bug in somewhere with the 3.x kernels, or
maybe mplayer, or maybe even nouveau (which can be likely).
I even have audio/video sync issues playing back the recorded video on
WindowsXP using smplayer.
I'm limiting-out on ideas as I don't have a multitude of video players
installed. So figured I'd post a query for any ideas. Especially since I'm
seeing this might be occuring during recording? (On recording using
mencoder,
I do get '1 duplicate frame each fps', however I've always being seeing this
for quite a long time.)
FYI: Concerning spammers, watch what your email client inserts for the to/cc
fields on reply or group reply. I've noticed most mailing lists and my mutt
here will insert the sender's email address along with the group mailing
list's
email. And, their mailing list will neglect sending you a copy (even though
you haven't marked the option to prevent sending duplicate emails.) Lovely
bit
of confusion there, and seeing you're recent spam issue -- it's what seems to
be turning the wheel.
--
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
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
[pvrusb2] Off-topic [was: Invitation to connect on LinkedIn]
This message appears to be the linkedin.com equivalent of what somebody caused to happen on this list a few years ago with facebook - when that person let a facebook app scan his addressbook and send e-mail invitations to every address in it! Please exercise a little more care. This sort of thing makes it onto subscriber-only lists such as this one because the sending app puts your e-mail address in the 'from' field of the message which is enough to get past mailman's subscriber-only filter. This makes it hard to block, and I have to hope that people who subscribe to this list generally don't fall for stuff like this. -Mike On Tue, 6 Sep 2011, Chris. Rutherford wrote: Communications, I'd like to add you to my professional network on LinkedIn. - Chris. Chris. Rutherford Senior Software Engineer at Sony United Kingdom Confirm that you know Chris. Rutherford: https://www.linkedin.com/e/-b7e8of-gs97v8k3-53/isd/4103701795/bSA1-5C2/?hs=falsetok=3L3dxSVbOUwkU1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/-b7e8of-gs97v8k3-53/8S4_yOhwitXmJnENm74JPO13MNRb/goo/pvrusb2%40isely%2Enet/20061/I1415852772_1/?hs=falsetok=2hyGHnGu-UwkU1 (c) 2011 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. ___ pvrusb2 mailing list pvrusb2@isely.net 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] FW: [admin] MTA change at isely.net mail server
On Fri, 26 Aug 2011, Freeh Sophia wrote: Everyone: Since about June 21st, another spammer out there has been relentlessly attacking the pvrusb2 mailing list using a type of attack I had not previously seen. As far as I can he has not succeeded and the list has stayed uncorrupted. But I am seeing a constant stream of bounce notifications every time he tries. The really annoying thing is that he's attacking the system by fraudulently using my domain (isely.net) in the from field and the MTA has been accepting these as legit - and then I get the backscatter when the post attempt fails due to the sender not actually being subscribed. [...] Freeh: I posted that text back on 8-Jul. Did you have a comment about this? It appears that all you did was to reflect back the same post... BTW, I have since shut off SPF enforcement, after discovering another problem with it :-( The spammer meanwhile seems to have given up :-) -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] [PATCH] Add support for Terratec Grabster AV 450MX
Thanks for posting this. I'll get it integrated into the driver asap.
-Mike
On Sun, 3 Jul 2011, Albert ARIBAUD wrote:
Signed-off-by: Albert ARIBAUD albert.arib...@free.fr
---
drivers/media/video/pvrusb2/pvrusb2-devattr.c | 20 +++-
drivers/media/video/pvrusb2/pvrusb2-devattr.h |2 +-
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-devattr.c
b/drivers/media/video/pvrusb2/pvrusb2-devattr.c
index e799331..e47b3a0 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-devattr.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-devattr.c
@@ -157,23 +157,23 @@ static const struct pvr2_device_desc
pvr2_device_gotview_2d = {
/**/
-/* Terratec Grabster AV400 */
+/* Terratec Grabster AV400 / AV450MX */
-static const struct pvr2_device_client_desc pvr2_cli_av400[] = {
+static const struct pvr2_device_client_desc pvr2_cli_av4x0[] = {
{ .module_id = PVR2_CLIENT_ID_CX25840 },
};
-static const struct pvr2_device_desc pvr2_device_av400 = {
- .description = Terratec Grabster AV400,
- .shortname = av400,
+static const struct pvr2_device_desc pvr2_device_av4x0 = {
+ .description = Terratec Grabster AV400 / AV450MX,
+ .shortname = av4x0,
.flag_is_experimental = 1,
- .client_table.lst = pvr2_cli_av400,
- .client_table.cnt = ARRAY_SIZE(pvr2_cli_av400),
+ .client_table.lst = pvr2_cli_av4x0,
+ .client_table.cnt = ARRAY_SIZE(pvr2_cli_av4x0),
.flag_has_cx25840 = !0,
.flag_has_analogtuner = 0,
.flag_has_composite = !0,
.flag_has_svideo = !0,
- .signal_routing_scheme = PVR2_ROUTING_SCHEME_AV400,
+ .signal_routing_scheme = PVR2_ROUTING_SCHEME_AV4x0,
};
@@ -540,7 +540,9 @@ struct usb_device_id pvr2_device_table[] = {
{ USB_DEVICE(0x2040, 0x7501),
.driver_info = (kernel_ulong_t)pvr2_device_751xx},
{ USB_DEVICE(0x0ccd, 0x0039),
- .driver_info = (kernel_ulong_t)pvr2_device_av400},
+ .driver_info = (kernel_ulong_t)pvr2_device_av4x0},
+ { USB_DEVICE(0x0ccd, 0x10a8),
+ .driver_info = (kernel_ulong_t)pvr2_device_av4x0},
{ }
};
diff --git a/drivers/media/video/pvrusb2/pvrusb2-devattr.h
b/drivers/media/video/pvrusb2/pvrusb2-devattr.h
index 273c8d4..75e8e8a 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-devattr.h
+++ b/drivers/media/video/pvrusb2/pvrusb2-devattr.h
@@ -69,7 +69,7 @@ struct pvr2_string_table {
#define PVR2_ROUTING_SCHEME_HAUPPAUGE 0
#define PVR2_ROUTING_SCHEME_GOTVIEW 1
#define PVR2_ROUTING_SCHEME_ONAIR 2
-#define PVR2_ROUTING_SCHEME_AV400 3
+#define PVR2_ROUTING_SCHEME_AV4x0 3
#define PVR2_DIGITAL_SCHEME_NONE 0
#define PVR2_DIGITAL_SCHEME_HAUPPAUGE 1
--
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
pvrusb2@isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Two PVR USB2 unit initially tune PAL as black and white
On Tue, 5 Jul 2011, Tom Warren wrote: Hi Mike, Thanks for your comprehensive and informative response. My hardware is fine, and I am happy to report I have solved the problem. I hope this information may help to solve it for others. When I initially set up the WinTV boxes, I used the 'scan' utility to obtain the channel frequencies. It turns out that most of the frequencies were wrong, and I believe I know why this happened. My local cable provider is using PAL B/G but it seems also places some programmes on other (D/K) frequencies adjacent to the official B/G ranges. I think this must have confused the utility and it chose the D/K channel spacing instead of B/G. To solve the issue, I found some PAL B/G frequency charts via Google, erased all of the errant values and created new ones following the chart. I then went back and filled in the D/K frequencies (which are between the official bands) and now the channels tune perfectly. Thanks again for your help, and I hope you'll check out Tvheadend because it really is an excellent back-end for both DVB and analogue feeds: lonelycoder.com/hts . Ah, so it was marginal tuning. The tuner was doing exactly what it was told, but it was told the wrong values. Interesting that NTSC isn't the only standard where this can happen. Thank you for figuring this out and posting it here - so others can learn from this. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Remote dies when upgrading to 2.6.38 from 2.6.36 on HVR-1900
On Sat, 9 Jul 2011, Nicholas Robbins wrote: Hello, I've had the remote working for some time, but today when I tried to upgrade my kernel to 2.6.38 from 2.6.36, the remote stopped working. Plugging the device in no longer produces a /dev/lirc0.Also there are no comments from lirc in the system log when the device is plugged in. The only thing I can find is that there is no longer a v4l1 compatibility option in the newer kernels. Could that be the problem? LIRC doesn't depend on the V4L ioctl-based API. It expects instead to install a kernel driver which ties into the I2C bus API exported by the bridge driver (e.g. pvrusb2). However that I2C API has undergone some changes of late. There have been some recent changes to the pvrusb2 driver within the kernel needed to stay in sync with these changes. I'd be willing to bet that this is what has caused the problem. This unfortunately creates issues for out-of-tree drivers when the kernel APIs they are using becomes a moving target. Try looking for a later version of LIRC. Odds are that a later release of the package already tracks this - or there very soon will be a release that will catch up. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
[pvrusb2] [admin] MTA change at isely.net mail server
Everyone: Since about June 21st, another spammer out there has been relentlessly attacking the pvrusb2 mailing list using a type of attack I had not previously seen. As far as I can he has not succeeded and the list has stayed uncorrupted. But I am seeing a constant stream of bounce notifications every time he tries. The really annoying thing is that he's attacking the system by fraudulently using my domain (isely.net) in the from field and the MTA has been accepting these as legit - and then I get the backscatter when the post attempt fails due to the sender not actually being subscribed. This sort of attack is obvious because *nobody* has any business posting messages from the outside to isely.net with a from field of isely.net. But up until now I've not tried to fend off this sort of thing. And unfortunately now that I'm looking into this, it appears that the Courier MTA doesn't have a means to block specifically named domains from the outside while still allowing those same domains from the inside. Thus if I tell Courier to block isely.net, then I can't send e-mail either. This is in fact the sort of attack that SPF can stop. The isely.net domain has been publishing an SPF record for years but the domain's MTA has never been set to enforce it. Well that just changed. I've tried to make the settings as forgiving as possible, but if the spammer keeps getting his crap accepted by my MTA I'm going to crank up the aggressiveness on this filter. If you don't know what SPF is, I encourage you to look here for more info: http://www.openspf.org/ The reason I mention all this here is that if you post to this list, if your ISP is publishing SPF, and it is misconfigured, then there's a very real chance now that the MTA at isely.net will reject the message. I hope that doesn't happen, but if it does I apologize in advance. You can thank all those spamming jackasses out there for forcing this upon us all. If you find that you can't send e-mail to the isely.net domain any longer, you should still be able to reach me at my pobox.com address (isely (at) pobox (dot) com) - while that still ultimately goes to the same inbox, the message takes a different route, via pobox.com, and that path I've verified as working correctly. If I'm told about a specific issue like this, I will try to solve it here - but my options will be limited if the root cause is really at the other end :-( Back to normal pvrusb2 traffic... -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] AVC-3610 Testing Unit.
Hi Bjorn, Sure if you're offering, I'll take a look and see if I can get it working with the driver. It should be sooner than the distant future though! I'll send you my address in a separate message. (Not that it's a great secret or anything.) -Mike On Wed, 22 Jun 2011, Bjorn d wrote: Hey Mike, I was wonder if you would send me your address. I lent my AVC-3610 to friend but got it back last week. I don’t need it for anything if it’s not going to work with Linux. I also happen to have unopened box with another 3610 somewhere. So If you get it working with linux I could use that one. Anyway, if I get the address I’ll send you the 3610, and maybe one day in the distant future you might get the driver working with it. I also need to know if you need me to find the driver CD, I think XP and newer finds the drivers on it’s own. Also, Thank you for the drivers am using them with a HVR-1900. ___ pvrusb2 mailing list pvrusb2@isely.net 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] No data from HVR-1900 encoder
On Sun, 19 Jun 2011, Magnus Ekhall wrote: Thanks for your help. I've now enabled a bunch of debug printouts to see what actually happens under the hood. I took a closer look at the kernel log and I'm pretty sure I got one of those messages regarding the stuck encoder, and the encoder was still working just fine. Maybe the printouts are unrelated to the problem after all... This is what I would expect if the driver did the recovery successfully (but the debug printouts were turned off). I also downloaded the latest windows driver from Hauppauges website and extracted the various firmwares. I found one firmware that was different from what I was currently running. The new firmware v4l-cx25840.fw has a md5sum of 95bc688d3e7599fd5800161e9971cc55. I don't know if that is what everybody else is running? I don't know if that will help me, but I'm running the new one now. Well in theory the cx25840 setup should not make a difference. There are in fact many versions of the cx25840 firmware floating around and they basically all work fine using the pvrusb2 driver. There is a firmware version floating around that is rumored to help enable FM radio reception on the HVR-1950, but the changes also I believe require incompatible V4L core changes. Now I'm just waiting for the problem to happen again so that I can take a dive in the now slightly more verbose kernel logs. :) What would be interesting would be to see evidence of the encoder getting stuff and the recovery *not* working. But it sounds like at this point we haven't even correlated your lack-of-video with a stuck encoder. And if you can get this to happen fairly regularly it would also be useful to see if cooling it might affect the incidence. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Two PVR USB2 unit initially tune PAL as black and white
On Wed, 4 May 2011, Tom Warren wrote: Greetings, I have two WinTV PVR USB '24xxx' boxes I'm using with the pvrusb2 driver which feed into tvheadend to stream PAL cable channels to xbmc. The set up works but I always get the first tuned channel in black white and have to tune to one (or more) different channels and then go back to the original channel get colour. Occasionally a channel will later go black and white again and I must apply the same fix. Hmm. Sorry I didn't notice this post when you first sent it - over a month ago :-( Could this be a driver problem, hardware problem, or fine-tuning problem?? I saw a post from 2006 that describes a similar issue using NTSC: http://www.isely.net/pipermail/pvrusb2/2006-January/000384.html Yes, I remember that well. The root cause was defective hardware. I spent weeks trying to find a bug in the driver and eventually came to the conclusion that it just wasn't possible for the driver to do this. Then I tried the obvious and ran the tuner under Windows, using the Hauppauge-supplied software, and sure enough same problem... Then I RMAed the unit. For analog video, there is an interesting history which might play into this issue. See long long ago before the advent of color TV, there was basically one video standard. But with color came along different countries adopted different schemes to encode the color information. That's really the big difference between NTSC vs PAL vs SECAM - different color information encoding. The outward effect of this is that if the video standard is set wrong, what you will see will in fact be a picture (perhaps distorted but a picture nonetheless) but it will be black and white. That's because with the wrong video standard set, the hardware will be using the wrong mechanism to find the encoded color information and thus it won't find anything, falling back to a black and white image. The point here is that there really isn't anything in the driver that can be used to get rid of the color component of the video. The only ways this can happen really comes down to these scenarios: 1. Wrong video standard in use 2. Selecting S-video and having a loose/unconnected wire for the chroma lead, or a defective s-video cable (because the color is pre-separated). 3. Defective hardware. Back in 2006, I went crazy looking for a non-existant case (4) after ruling out (1) (2). It never occurred to me to test for (3), but it's really easy to test for by running it under Windows: If totally different software still produces the same wrong results then it obviously can't be the software at fault. When I finally figured out it was (3) I was ready to smack myself for wasting so many weeks chasing a ghost! I'm running Ubuntu server 10.10 64-bit with the driver from linux-s2api-tbs6980-1_20101024 (commercial mod for the Tenow International TBS6981 dual satellite card) in which I made a small modification to set: .pixelformat= V4L2_PIX_FMT_MPEG, ...in the pvrusb2-v4l2.c file in order for tvheadend to recognise it as a valid source. A very very long time ago I instituted that change in the driver - and then discovered that xawtv no longer worked with the driver. So I backed out the change and it's been that way ever since. I'm unfamiliar with tvheadend. Since both boxes behave the same way, I suspect this is an issue with the driver. What can I do to debug the issue further? Two different pieces of hardware with the same wrong behavior? I wonder if this might be some kind of variation of (1) above. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Two PVR USB2 unit initially tune PAL as black and white
On Mon, 13 Jun 2011, Tom Warren wrote: On 4 May 2011 13:17, Tom Warren psycadil...@gmail.com wrote: Greetings, I have two WinTV PVR USB boxes I'm using with the pvrusb2 driver which feed into tvheadend playing PAL cable channels. The set up works but I always get the first tuned channel in black white and have to tune to one (or more) different channels and then go back to the original channel get colour. Occasionally a channel will later go black and white again and I must apply the same fix. Both boxes are the 'new' hardware version. Could this be a driver problem, hardware problem, or fine-tuning problem?? I saw a post from 2006 that describes a similar issue but using NTSC: http://www.isely.net/pipermail/pvrusb2/2006-January/000384.html I'm running Ubuntu server 10.10 64-bit with the driver from linux-s2api-tbs6980-1_20101024 (commercial mod for the Tenow International dual satellite card) in which I made a small modification to set: .pixelformat = V4L2_PIX_FMT_MPEG, ...in the pvrusb2-v4l2.c file in order for tvheadend to recognise it as a valid source. Since both boxes behave the same way, I suspect this is an issue with the driver. What can I do to debug the issue further? Thanks, Tom -- I have tried pre-tuning several channels with a script using v4lctl before launching tvheadend, but this does not solve the problem. I've compared the settings while BW vs colour but can't find any differences. What could be causing this? Also, is this only happening with the RF tuner or can you also reproduce it with the composite and s-video inputs? (If it's just the tuner, then the search space is narrowed down considerably.) Incorrect tuning might also do this - if the tuning isn't right then the hardware might not be finding the color information in the signal. That can definitely happen with NTSC, but the last time I actually *saw* that effect was back in the 1970's using a TV with a crappy mechanical tuner. Modern digital tuners usually don't have a problem like this unless you're really sending it an incorrect frequency. There are methods possible by which one can get the tuner and cx25840 kernel modules to report the in-use video standard. Has nobody else ever seen this problem? (Realize that the case in 2006 was definitely bad hardware so it doesn't count.) -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] pvrusb2 latest snapshot with F15 and even 2.6.38.8 vanilla
That's a very generic complaint. It could, at this point, be literally anything going wrong. You first need to verify that the pvrusb2 driver is being loaded (what does lsmod | grep pvrusb2 show). Then I'd probably try to use the sysfs interface and mplayer to verify that the driver and the hardware are working. If you get to that point then I'd be suspicious of something messed up in mythtv. -Mike On Thu, 16 Jun 2011, Scott Doty wrote: When I try to add a capture card in mythtv -- my wintv-pvrusb2 doesn't show up. This is with the latest driver snapshot from isely.net and even trying 2.6.38.8. Anyone off the top of their head know the solution? Thanks. :) -Scott p.s. versions: _[/sys/class/pvrusb2]_(root@tv)_ # rpm -qa | grep myth mytharchive-0.24.1-1.fc15.x86_64 mythtv-setup-0.24.1-1.fc15.x86_64 mythtv-docs-0.24.1-1.fc15.x86_64 mythplugins-0.24.1-1.fc15.x86_64 mythtv-0.24.1-1.fc15.x86_64 mythweb-0.24.1-1.fc15.x86_64 mythgame-0.24.1-1.fc15.x86_64 mythtv-frontend-0.24.1-1.fc15.x86_64 mythtv-backend-0.24.1-1.fc15.x86_64 mythweather-0.24.1-1.fc15.x86_64 mythnetvision-0.24.1-1.fc15.x86_64 mythtv-common-0.24.1-1.fc15.x86_64 mythvideo-0.24.1-1.fc15.x86_64 mythes-1.2.1-3.fc15.x86_64 mythtv-libs-0.24.1-1.fc15.x86_64 mythtv-themes-0.24-5.fc15.noarch mythbrowser-0.24.1-1.fc15.x86_64 mythtv-base-themes-0.24.1-1.fc15.x86_64 mythmusic-0.24.1-1.fc15.x86_64 mythzoneminder-0.24.1-1.fc15.x86_64 mythgallery-0.24.1-1.fc15.x86_64 mythnews-0.24.1-1.fc15.x86_64 ___ pvrusb2 mailing list pvrusb2@isely.net 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] how do I tune to digital broadcasts?
Fumi(aki): It sounds like the driver hardware are in good shape if you're able to get it to find TV stations. If you've gotten to that point, then the remaining issues are really generic to DVB. At this point you can treat the tuner as a normal DVB device and use pretty much any of the DVB tools available. Thus all of the normal generic DVB project documentation should apply for you. -Mike On Wed, 4 May 2011, Fumiaki Okushi wrote: Hi, I have a WinTV-HVR-1950 and am trying to tune to digital broadcasts. So far, I've managed to get the firmware loaded and the scan tool is able to list local TV stations. Unfortunately, I haven't found a way to tune to a particular TV station. I understand that for digital broadcasts, I have to go through the dvb interface (and not pvrusb2's sysfs interface). Is there a simple utility to tune to a particular digital TV station? I'm running Debian Wheezy on i386 hardware. I am in the US. Thanks, Fumi(aki) Okushi ___ pvrusb2 mailing list pvrusb2@isely.net 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] rebuild question
On Wed, 18 May 2011, Lorne Shantz wrote: Mike, I must be getting old, or senile... When I did this about a year ago, I figured it out and got it working. I don't know if the docs have changed or not, but after a couple of days with this, the docs seem confusing. We know it works, since nothing has changed but the OS was re-installed. I have all the files, but not sure what ones I need and their locations. I guessed but fell short. So I went back to scratch pretending I was starting over. So reading: file:///mnt/E/ISO Images/Linux/pvrusb2-mci-20100708/doc/setup.html#Compilation It goes into extreme detail on kernel version for all flavors it seems. I went to Driver Compilation and found the export and make information to be lacking for my limited knowledge. Since I use Openuse, I do seem to have a /lib/firmware, so assume that is where I want the .fw files. The compile fails, with my understanding, it says: The firmware files don't factor into the compilation. They only matter after you install the driver and try to make it run. make INSTALL_MOD_DIR=pvrusb2 -C /lib/modules/2.6.37.6-0.5-desktop/build M=/mnt/E/Applications/usbtv/pvrusb2-mci-20100708/ivtv modules make[1]: Entering directory `/usr/src/linux-2.6.37.6-0.5-obj/x86_64/desktop' make -C ../../../linux-2.6.37.6-0.5 O=/usr/src/linux-2.6.37.6-0.5-obj/x86_64/desktop/. modules CC [M] /mnt/E/Applications/usbtv/pvrusb2-mci-20100708/ivtv/saa7115.o /mnt/E/Applications/usbtv/pvrusb2-mci-20100708/ivtv/saa7115.c:81:33: fatal error: linux/video_decoder.h: No such file or directory compilation terminated. make[4]: *** [/mnt/E/Applications/usbtv/pvrusb2-mci-20100708/ivtv/saa7115.o] Error 1 make[3]: *** [_module_/mnt/E/Applications/usbtv/pvrusb2-mci-20100708/ivtv] Error 2 make[2]: *** [sub-make] Error 2 make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.37.6-0.5-obj/x86_64/desktop' make: *** [modules] Error 2 You're trying to build the ivtv modules in the snapshot. That stuff is very VERY old and only needed if you're trying to run in a very old kernel (prior to roughly kernel 2.6.18). The pvrusb2 web pages talk about when you need that stuff but in the modern era it isn't needed. Instead you need to build in the driver area not the ivtv area. This might work for you (just guessing since I don't know your distro): make INSTALL_MOD_DIR=pvrusb2 -C /lib/modules/2.6.37.6-0.5-desktop/build M=/mnt/E/Applications/usbtv/pvrusb2-mci-20100708/driver modules This is interesting. In the 7 years I've maintained this driver, you're the first person I've heard of getting tripped up by that! I wonder if it is possible to break it out to a quick start for the newer flavors or something. Like Chapters. I would even volunteer to help with the lay out for Openuse... However, I'm not a programmer and would be like a stupid grunt doing what is told to be done with little understanding. :) This message was not meant as confrontational or meant to get you angry. This is just my observation from a lay persons point of view that has just slightly beyond basic user status. Although I have been working with linux exclusively for about 2 years now. No, I understand your frustration completely. And sorry I didn't reply right away. You might have noticed a flurry of traffic today - that's me trying to catch back up. The ironic thing is that those instructions are as detailed as they are BECAUSE of the need to make them work for everyone. I built up those instructions over a long period of time as I kept encountering additional corner cases where people had run aground. As I learned of each special case I added to the instructions to cover that. And what resulted is what you see. Admittedly those instructions originated from an earlier time when building the driver was messier because of dependencies that needed to be satisfied. With the driver being in-kernel much of the complexity goes away. But also with the driver being in-kernel most people don't need to bother compiling it anymore. At the current moment, the stand-alone driver and the in-kernel driver for 2.6.39 are on-par with one another. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] No data from HVR-1900 encoder
a pretty strong datapoint that it's getting too hot. If you can run your tuner under Windows (yeah, I know, a pain), you can also diagnose bad hardware if running it under Windows also results in periodic failures. (However the inverse may not be true - it could be marginal hardware that only dies when driven hard enough and the two software environments - Linux vs Windows - are certainly going to be driving it differently.) And if a hardware problem is detectable and there is a way to work around it (by re-initializing it) that's fine as well. Well the driver is already doing some of that re-initialization... -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] No data from HVR-1900 encoder
See below... On Thu, 16 Jun 2011, Magnus Ekhall wrote: Hello, I'm using the pvrusb2 driver (excellent work by the way!) to use a Hauppauge HVR-1900 model 73xxx. The driver identifies the tuner (TDA18271HD/C2), the demodulator (cx25840) at boot and generally everything works great. However approx. once per week something odd happens. When mythtv tries to use the analogue tuner there is no data coming out of /dev/video0. Not even if I cat /dev/video0 I get anything in that case. Those two symptoms are consistent - if cat doesn't work then mythtv won't be able to stream from it either. I've even tried to reload the pvrusb2 driver and yanking the USB-cable. The only thing that works is a reboot. Power-cycling just the tuner *should* also clear things up. But you should not even need to do that. Read further... Now, that sounds a bit like the mystery bug written on the FAQ, but I'm not sure. Also, I know that pvrusb2 is sort of a higher level driver which uses sub-drivers, so maybe I'm at the wrong forum here... Anyway, the problem is really annoying, so any input is most welcome! In the kernel log there are a message that I believe might have something to do with the issue: May 1 08:49:33 digimatrix kernel: [383494.928478] pvrusb2: ***WARNING*** device's encoder appears to be stuck (status=0x0003) May 1 08:49:33 digimatrix kernel: [383494.928485] pvrusb2: Encoder command: 0x81 May 1 08:49:33 digimatrix kernel: [383494.928489] pvrusb2: Giving up on command. This is normally recovered via a firmware reload and re-initialization; concern is only warranted if this happens repeatedly and rapidly. This is a longstanding behavior in the driver. What's happening here is that the pvrusb2 driver has detected that the mpeg encoder chip has stopped responding. That chip is its own processor with a firmware program that gets loaded to it. When (if) it crashes this is the result. The pvrusb2 driver detects this situation and prints the warning to the kernel log. But the recovery is (should be) automatic - other logic in the driver then resets the mpeg encoder, sends it a fresh firmware image, and restarts it for you. (Actually what happens is that the driver marks internal state to track what it thinks has happened, e.g. dead mpeg encoder, and then the driver's normal internal state machine just sequences whatever steps it thinks are needed to bring the video pipeline back up into a working condition.) This is normally what is supposed to happen. You should see further messages in the kernel log as the driver reinitializes the encoder. Do you see that? The concern mentioned there is if the recovery is attempted and then the chip immediately crashes again (or perhaps just fails to start). Normally that never happens. Of course if the hardware is misbevaing or if it is overheating then well anything is possible. I don't know how to reload the firmware and do a re-initialization. I assume a modprobe -r would do that? In that case this does not help me. If the hardware is truly fouled up, then reloading the driver might not help. But power-cycling the tuner would probably clear it up. But the driver should be recovering this for you automatically... -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] rebuild question
On Mon, 16 May 2011, Lorne Shantz wrote: --- On Mon, 5/16/11, Mike Isely is...@isely.net wrote: [...] As far as the pvrusb2 driver is concerned you only need 2 pieces, the kernel module that is the driver, and all the firmware files. It has been so long that I have forgotten everything. Where do they normally reside? The answer depends on your distro, unfortunately. This lists firmware file names and tries to help you figure out where they should be installed: http://www.isely.net/pvrusb2/setup.html#Firmware [...] I went back to the list and didn't see how to read the old posts. It has been awhile. I can't even remember the file names. I will go do a search for the original website. I had hoped I could just copy my old files in, reboot and be back up. It is opensuse 11.4 with Linux linux-ncvm 2.6.37.6-0.5-desktop #1 SMP PREEMPT 2011-04-25 21:48:33 +0200 x86_64 x86_64 x86_64 GNU/Linux Start with the pvrusb2 web site. Read the setup instructions. It's all here: http://www.isely.net/pvrusb2/setup.html -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] rebuild question
On Mon, 16 May 2011, Lorne Shantz wrote: Okay, here is possibly a stupid question. My upgrade was a disaster from Opensuse 11.3 to 11.4. So I started over with a fresh install. I backup every night, so I'm thinking there may be a simple way to just copy what I need without starting from scratch. Is that too simple? :) Otherwise I have to gasp read and study and think, compile Not knowing how exactly you were setup before it's kind of hard to tell you how to preserve it. And by it I presume you're only asking about the pvrusb2 driver installation since that's what this list is about. As far as the pvrusb2 driver is concerned you only need 2 pieces, the kernel module that is the driver, and all the firmware files. The kernel module - if you're using the standalone driver - has to be compiled against the kernel you are using. If you did a scratch install of a later version of Opensuse, then it's very likely that you're running a later kernel. In that case you'll have to recompile the driver anyway. If you're using the in-kernel version of the driver then there should be nothing else to do as far as the kernel module is concerned - but that also depends on your distro, if they've made the multimedia kernel stuff into a separate package. The firmware files are needed in order to initialize the hardware. You will definitely need to locate and copy those across. The firmware files have stayed constant throughout the life of the driver so there's no requirement to upgrade any firmware if you're running a later driver. Look at the pvrusb2 web page about firmware installation if need to search for the right file names. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
[pvrusb2] New driver snapshot: pvrusb2-mci-20110501
A new pvrusb2 driver snapshot is available. This snapshot builds under 2.6.38. Change history since last snapshot: (+) Clean up s-video input for Terratec Grabster. Thanks go to Sven Barth for figuring this out. (+) Various cosmetic cleanups. (+) Various updates to keep up with the moving target that is the Linux kernel... (up to 2.6.38) (+) Fix potential memory leak involving device tear-down. (+) Provide more information about IR units to IR subsystem, other related changes to improve IR support. (+) Remove V4L1 compatibility when built against 2.6.38 or later. As usual, the pvrusb2 web site can be found at: http://www.isely.net/pvrusb2/pvrusb2.html -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Build without V4L1 support
Hi Sven, Sorry about the hassle with compiling the standalone driver. I will get a new snapshot released this weekend which should support 2.6.38 correctly. I just looked through my svn change history and I had already merged in changes to remove V4L1 support in preparation for this - and then forgot to release it. (The removal would only be active if the kernel is recent enough so when built against older kernels V4L1 support would still be there. And the change for this is really pretty tiny since the V4L1 aspects were isolated long ago.) There's actually a small collection of changes ready to be released and I think the reason I didn't release it right away is because I wanted to make sure it first got accepted upstream (which it did). I'll get a new snapshot out this weekend. -Mike On Mon, 25 Apr 2011, Sven Barth wrote: On 25.04.2011 19:27, Sven Barth wrote: On 25.04.2011 19:19, Sven Barth wrote: Hello Mike! I have a new problem now. It's not related to the AV400 directly, but seems to be a more general problem. My current kernel (2.6.38) does not seem to include the V4L1 header (linux/videodev.h) anymore, so pvrusb2-i2c-cmd-v4l1.c won't compile (I'm using the snapshot from January). So it seems you need to adjust your snapshot again for newer kernels as the kernel-next repository doesn't contain it either... Regards, Sven PS: I'll try to adjust it for me locally in the meantime. And v4l_compat_translate_ioctl used in pvrusb2-v4l2.c doesn't exist either anymore. Ok, I got it to compile (and run) for me again (puh ^^). For my second mail I applied the change I found in linux-next: http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=08af245de0cf6ab5f4ed008ee2bb99273774fce0#patch11 Regards, Sven ___ pvrusb2 mailing list pvrusb2@isely.net 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] HP / Adaptec AVC-3610 support in PVRUSB2 ?
Greg: The primary problem for me here is that I can't directly support the AVC-3610 because I don't have a sample to test. So I have to rely on others to figure out the differences and/or try changes to the driver. Generally, if the hardware is compatible enough (i.e. generally follows the usual reference design when using the Conexant encoder chip), then adding support for it in the pvrusb2 driver usually comes down to: 1. Figuring out how the video grabber chip's inputs are wired (i.e. which one is composite vs which one is wired to s-video) and defining a routing scheme for it in the driver. 2. Figuring out how to route FM radio audio, if there is an FM radio in the device. 3. Adding a definition in pvrusb2-devattr.c to recognize and configure the device. If it is a hybrid device (e.g. OnAir or HVR-1950 type device) then there's more work to get the digital side operating, but that is (still) not a very common case. There also might be issues with getting IR working if it has an IR receiver - though mostly that complexity has involved Hauppauge devices. At this point, there (still) isn't any support for the AVC-3610 in the pvrusb2 driver. But if you (or anyone) has useful patches to add that support, I'll be happy to merge those in. -Mike On Wed, 20 Apr 2011, Greg Tippitt wrote: Mike or Nick, I've read a series of old messages in Sep-Oct 2010 regarding the AVC-3610, but I wasn't clear if the AVC-3610 device might work with PVRUSB or not. Will they work now, or have you had time to make a guess if they might work in the future? These discontinued AVC-3610's are extremely affordable for a dual tuner ATSC device. If the driver may be working in the near future, or workable with some creativity, I may go ahead and buy one to try out with Unbuntu, as they are cheap enough it's not much of a risk. I don't program in C, so I'm not any help with the programming of the driver. I can help with testing, debugging, documentation if you need help. I worked for 20 years in other languages and am good at hardware configuration. (I can't believe I just volunteered to do documentation!) I would like to thank you and everyone that works on PVRUSB2. I recently bought a discontinued OnAir Sasem (aka Autumnwave) HDTV USB 2.0 tuner on eBay for almost nothing. Even though the company went out of business, your instructions were so easy to follow for loading the firmware, I had the device working in almost no time at all. The wait for the device to scan for my local channels took more time that the entire rest of the installation! Thank you for providing support for these old devices. Old hardware that is cheap, but still very useful, has enabled me to begin putting together a MythTV system that I could not afford otherwise. My wife and I are disabled and live on a fixed income, so brand new tech toys are normally outside of my budget. You help out lots of people and keep more stuff from going in the landfill. Thanks, Greg ___ pvrusb2 mailing list pvrusb2@isely.net 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Green screen + compiling problems ( compiling by newbie)
back multiple No such file or directory errors make INSTALL_MOD_DIR=pvrusb2 -C /lib/modules/2.6.32-30-generic/build M=/home/lj/Desktop/PVRUSB2/pvrusb2-mci-20110116/driver CONFIG_VIDEO_PVRUSB2=m CONFIG_VIDEO_PVRUSB2_24XXX=y CONFIG_VIDEO_PVRUSB2_SYSFS=y CONFIG_VIDEO_PVRUSB2_DVB=y CONFIG_VIDEO_PVRUSB2_DEBUGIFC=y CONFIG_VIDEO_ADV_DEBUG=y modules make[1]: Entering directory `/usr/src/linux-headers-2.6.32-30-generic' CC [M] /home/lj/Desktop/PVRUSB2/pvrusb2-mci-20110116/driver/pvrusb2-std.o CC [M] /home/lj/Desktop/PVRUSB2/pvrusb2-mci-20110116/driver/pvrusb2-compat.o CC [M] /home/lj/Desktop/PVRUSB2/pvrusb2-mci-20110116/driver/pvrusb2-ctrl.o CC [M] /home/lj/Desktop/PVRUSB2/pvrusb2-mci-20110116/driver/pvrusb2-hdw.o CC [M] /home/lj/Desktop/PVRUSB2/pvrusb2-mci-20110116/driver/pvrusb2-devattr.o /home/lj/Desktop/PVRUSB2/pvrusb2-mci-20110116/driver/pvrusb2-devattr.c:42:22: error: tda18271.h: No such file or directory /home/lj/Desktop/PVRUSB2/pvrusb2-mci-20110116/driver/pvrusb2-devattr.c:43:21: error: tda8290.h: No such file or directory Anyone see why my compilation fails? Those missing headers are for support of specific v4l-dvb tuners having to do with later model devices (like the HVR-1950). The standalone driver supports all that, and the kernel version you're compiling against (2.6.32) should also support that. However I've seen cases where a distro vendor's kernel source package fails to include *all* of the headers for that kernel. Sometimes the distro might split the headers into multiple packages, in which case you would need to identify and install those other packages. Anyone else experience the green screen and digital noise in the mpeg stream? See above... -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Tuner problems
On Sat, 2 Apr 2011, Jim Peters wrote: My backend has 6 tuners a pvr150 a pvr350 and 4 wintv pvr usb tuners. I am having problems with 2 of the wintv pvr tuners. 1 of them just quits/dies on me, it records blank videos when this happens (0 byte files)when this happens I just reboot the backend and everything works fine again for a while (I have actually made a cron job that runs every 4 hours to reboot the server if no recordings/comflaging/mediawatching is going on) this is a temporary fix that doesn't work well because I still get quite a few blank recordings from this tuner, so I would like to fix it. Only 1 fails while the other continues to work? Obviously software isn't going to differentiate this unless the models are different. My experience in cases like this is that either you're running a *really* old driver (like something from 2006) or the hardware is simply flaking out. Assuming that you're running a relatively recent kernel (and thus a recent driver), then possible hardware issues might be: 1. Bad USB cable, hub, or port - USB works perfectly when it works, but noise or marginal wiring can *really* foul things up. I've been down this road many times, unfortunately. 2. Dirty power - your PC benefits from a huge internal power supply that can bridge all manner of power line abuse. All your internal devices (e.g. pvr150, pvr350) benefit from this. But your external tuners are powered from little wall-warts that simply can't defend against power spikes / glitches / sags. This can cause the tuner to crash. 3. Heat problems - the mpeg encoder in these tuners uses enough power to get fairly warm. This is why you never see these devices for sale in a USB cable-powered configuration - there just isn't enough juice available. But that power creates heat, and while these devices are pretty forgiving, it *is* possible to overheat one. If you have the two devices stacked for example, the one on the top is going to be in the convective heat flow coming from the bottom tuner, so it will run warmer. I learned of a story once where one person stacked four of these in an enclosed box and experienced a lot of crashes... Since you have 2 tuners, you have a tremendous advantage. Try swapping them. Does the problem stick with the specific tuner? Could one be lacking ventilation? Try swapping power bricks between them. This should allow you to quickly zero in on the specific piece of suspect hardware... The other one has a screen flickering problem, it will flicker badly for a couple minutes then clear up for a few seconds and flicker some more. It looks somewhat like the old horizontal roll of old (really telling my age now!) but with digital attributes (chunks of the picture in the wrong place and stuff) I have this tuner set as the last tuner in the system so it hasn't been a big problem but between my wife learning how to use mythtv for her stuff, and an increased recording schedule on my part, it was the tuner that was used for stargate universe last week. so now we have a problem that needs fixed! Anyway my big problem is that I have no clue as to where to start looking for answers for these problems. what log files to look at or any special debugging steps i can take to get info that might be useful to figure this out. any help would be appreciated. Thanks That sounds like a weak signal. Are both PVR-USB2 tuners doing this or just one? Which model is this? (24xxx, 29xxx, HVR-1950/1900) If these are HVR-19x0 devices, then are you having the problems in digital or analog mode? If you rip from a VCR or DVD player (using the composite or s-video inputs) do you still see the flicker happening? -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] HVR1950 IR blaster inquiry
Jared: There have been some recent developments in the v4l-dvb tree with respect to IR. And there is a strong suspicion that with these changes the IR blaster side might start working now for the HVR-1950 (and also the HVR-1900). The changes should be available starting with the 2.6.39 kernel tree. I will also update the standalone driver to match (already have pulled down the changes just haven't done the release yet), however the key fixes are actually in the IR subsystem not the pvrusb2 driver so you would still need the 2.6.39 (or later) kernel anyway. -Mike On Sun, 3 Apr 2011, Jared Harvey wrote: Hello, Thanks to your well written pages, I got my HVR1950 capturing video and IR signals from the remote control. I'm currently trying to get the blaster to work so I can control my Dish 322 receiver. I thought I'd inquire about a note I found in this thread found here. http://www.isely.net/pipermail/pvrusb2/2009-October/002615.html OK, so to the best of my knowledge nobody has yet seen the IR blaster side work on the HVR-1950 :-( Do you know if anyone has gotten the IR blaster working? If so do you know where I might find more info about how to make it go? I've been searching your pages, misc forums, ect and haven't had the right luck yet. Not sure if it will help, but here are some notes about my configuration. Mythbuntu running Ubuntu 10.10 on 64bit laptop, with new HVR1950 and newer 16bit firmware, capturing video from coax channel 3 of a Dish 322 and controlling the Dish receiver via IR. Best regards. .. ..-. / -.-- --- ..- / .-. . .- -.. / - .. ... .-.. . - ... / .- ...- . / .- / -... . . .-. Jared Harvey Operator KB1GTT e-mail m...@jaredharvey.com Web page http://jaredharvey.com -- 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Terratec Grabster AV400 and 2.6.37
Sven: Sorry this has taken seemingly forever, but I thought you'd want to know that this change is in fact in the pvrusb2 svn repository and will appear with the next snapshot. More importantly, I've also now generated changesets to enable AV400 support in the kernel-resident version of the pvrusb2 driver. Assuming the patches overall test OK here, I plan on a pull request tonight, which hopefully should allow AV400 support to appear in the main kernel tree, starting with 2.6.39. -Mike On Sun, 6 Feb 2011, Mike Isely wrote: On Sat, 5 Feb 2011, Sven Barth wrote: I changed the routing from CX25840_SVIDEO_LUMA3|CX25840_SVIDEO_CHROMA4 to CX25840_SVIDEO_LUMA2|CX25840_SVIDEO_CHROMA4 and now the picture is stable and centered. The only remaining problem is, that it is black and white, but this can also be related to the source signal. I'll investigate this further. OK, I will pull this into the driver, along with a bunch of other stuff I'm going to try to finish today. Thanks. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Fedora 14 pvrusb2 kernel beware
Ken obviously knows this already, but for others here who have been watching this issue on this mailing list, it appears that Jarod Wilson has traced to a regression in the tda8290 driver. The entire trail is documented in the bugzilla entry referenced in the post to mythtv-users, copied below. I've been saying that there's been thrashing going on in the tuner driver(s) that the pvrusb2 driver relies on when operating HVR-1950 / HVR-1900 devices. Well this appears to be another example. Thanks go to Jarod Wilson for tracking this one down. -Mike This is from mythtv-users: On Tue, 1 Mar 2011, Jarod Wilson wrote: On Feb 25, 2011, at 10:43 AM, Ken Bass wrote: On 2/24/2011 5:44 PM, Jarod Wilson wrote: Please file a bug in Red Hat's bugzilla and assign it to or cc me on it, and I'll take a look and see what I can see. Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=680450 For those not following the bugzilla or the upstream linux-media mailing list, this was an upstream regression recently introduced, and I just posted the patch to fix it this morning (as well as committing it to a new Fedora kernel build). -- 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] RHEL 5.6 Hauppauge 1950 USB PVR
Tomas: Your kernel is probably too old. While I obviously can't know what might have been backported by the distro vendor, here's a general guide for generic kernel versions: http://www.isely.net/pvrusb2/setup.html#Prerequisites In particular, though the pvrusb2 driver has been in the kernel tree since 2.6.18, and you could certainly compile the standalone driver for an even older kernel, the problem you are going to have is DVB support in general and specific support for the tuner that's in your HVR-1950. Those are pieces that are outside of the pvrusb2 driver that you need for the HVR-1950 to work at all. And that means that you need to move up to at least kernel version 2.6.26. Unfortunately the tuner driver in v4l-dvb that your HVR-1950 needs has undergone a lot of thrashing and I think Hauppauge may have even changed out the part at some point. That all means that you may need an even *more* recent kernel before it's going to work. But certainly ancient kernels like 2.6.18 or 2.6.20 just aren't going to work for what you need to do :-( -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Quick Start for Hauppauge 1950 Digital Tuner and Composite Inputs?
On Wed, 9 Feb 2011, Nicholas Oleksinski wrote: Hi Folks: I am using the pvrusb2 driver to control my Hauppauge 1950 on Ubuntu 10.04, kernel 2.6.32-28-generic. The analog tuner seems to be working fine, but I cannot find the instructions for using the digital tuner or the composite input using the DVB side of pvrusb2 (I think?). I can set the device to use the composite input, but the resulting picture looks like a poorly tuned over the air station. Maybe the analog tuner needs to be shut down or something? v4l2-ctl is generally what I use to control the 1950. I love the device but I'm trying to get this last bit figured out. Can anyone point me to a howto or just send a couple hints? I have been looking for some time now. Have you looked at the driver usage page? See this link: http://www.isely.net/pvrusb2/usage.html In particular for DVB, this: http://www.isely.net/pvrusb2/usage.html#DVB -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Terratec Grabster AV400 and 2.6.37
On Sat, 5 Feb 2011, Sven Barth wrote: Well... I have already reported my findings to linux-media, so let's see whether they like my workaround or need to find a better solution. :D It appears that they like your solution. Great job! -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Terratec Grabster AV400 and 2.6.37
On Sat, 5 Feb 2011, Sven Barth wrote: I changed the routing from CX25840_SVIDEO_LUMA3|CX25840_SVIDEO_CHROMA4 to CX25840_SVIDEO_LUMA2|CX25840_SVIDEO_CHROMA4 and now the picture is stable and centered. The only remaining problem is, that it is black and white, but this can also be related to the source signal. I'll investigate this further. OK, I will pull this into the driver, along with a bunch of other stuff I'm going to try to finish today. Thanks. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Terratec Grabster AV400 and 2.6.37
On Sat, 5 Feb 2011, Sven Barth wrote: On 05.02.2011 18:35, Sven Barth wrote: I changed the routing from CX25840_SVIDEO_LUMA3|CX25840_SVIDEO_CHROMA4 to CX25840_SVIDEO_LUMA2|CX25840_SVIDEO_CHROMA4 and now the picture is stable and centered. The only remaining problem is, that it is black and white, but this can also be related to the source signal. I'll investigate this further. Ok, color works. It was a problem of the input signal. I have now simply plugged the S-video output of my graphic card into the S-video input of the AV400 and I have a colored picture of my monitor inside mplayer :D Great! The other possibility that I would have suggested is typical for S-Video: When routing S-Video, the chrominance is a separate input, so if that input configuration were wrong a very common symptom is that you get BW video. At this point, are there any other issues you see with this hardware as operated by the pvrusb2 driver? If not, I will remove its experimental status. Can anyone else test this hardware? -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Terratec Grabster AV400 and 2.6.37
On Sat, 5 Feb 2011, Sven Barth wrote: Hi again! I could pinpoint the source of the problem in the cx25840 module (it's volume related... something the cx25837 chip on the AV400 does not support), so I'll report this to the linux-media list. But now that I've (again) patched the cx25840 module I can use the AV400 without audio problems on my PC. :D As I hope that this regression will be fixed soon, what needs to be tested so that the AV400 will become a part of the in-kernel version? I have used the composite part of the device for months now without any problems. I'll need to test S-video, but so far I'm totally satisfied with the device (it runs better than on Windows). Basically I'd like to verify that all the inputs (audio and video routing configuration) work correctly; if I remember correctly that was really the part of the port that we weren't sure about. I can't do that myself because I don't have access to the hardware. You do - I can help you understand the routing mechanism, and if you can generate a patch and verify that it all works, then I will pull it into the driver. Changes that might be needed to the cx25840 driver is outside the scope of the pvrusb2 driver, but we can get those submitted to the v4l-dvb tree provided the changes don't regress other aspects of that driver. Regression testing cx25840 is a serious pain - I can only verify that it continues to work correctly with pvrusb2-driven devices but this part is used by a lot of other drivers so it's kind of a crap-shoot to ensure real stability there across everything when there's a change that looks like it might be a problem in other contexts. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] First take on a chinese oem capture card with FX2 and cx25843
Svenn: There are a number of different cards I've heard about that pair an FX2 microcontroller with a cx25843. Unfortunately none of them are going to work with the pvrusb2 driver, since the pvrusb2 driver at its core is looking for that mpeg encoder chip. The mystery chip in that photo is interesting - somebody went to the trouble to erase the markings from that chip. However it can't be the mpeg encoder - such a chip will have a dram interface and there just aren't enough pins there. Even if the pvrusb2 driver were to support raw mode (which perhaps someday it might), any implementation is probably still going to expect to shovel the bits through the encoder. I've learned a few things about how this is probably possible; basically it amounts to putting the encoder into a different mode. It would still be packetizing the data but it would be in a form that could then be made available as raw from the pvrusb2 driver's API - this is needed because audio still has to be interleaved. Long story, but the takeaway is that the encoder chip is still involved. It might be an interesting exercise to further improve the pvrusb2 driver to handle cards like you're describing. The fact is that much of the scaffolding is going to be the same - there is after all an FX2 there and I imagine RPC style communication still going on. But this is a very big deal to implement and I have to think that by now there's likely another v4l-dvb driver that already does this. -Mike On Fri, 28 Jan 2011, Svenn Are Bjerkem wrote: Hi, just out of curiosity (and some need) I bought one of these dvr oem usb2 cards which happen to be available for purchase. Normally seems to only run under winxp32 and with an application called superdvr. I opened the box and took some pictures of the PCB to identify the components. http://invalid.ed.ntnu.no/~svenn/html/oem_usb2_capture_card.html For a cheap chinese card, I find it funny that they have taken the hasle to mount the mini-USB socket while soldering a cable on the back side, but that's maybe for production programming. Most of the components are traceable, except for one unmarked chip. Since it contains the FX2 and cx25843 chip, I have been searching on the net for more information on drivers for cards using these chips, and I have found that it is mostly TV-tuner cards appearing in the discussions. I am trying out several tutorials on programming the FX2 with the linux driver in order to load a cx25843 firmware, either the linux one or the one downloaded by the winxp driver. I have to take one step at a time. I read on the homepage of the pvrusb2 driver that raw mode is not supported yet and this card assumingly does not have an mpeg encoder (unless that magic chip is one) and will probably feed some raw data on the USB channel. I will have to deal with that if I get that far. I post this, probably on the wrong mailinglist, in the hope that some other participant ever came across this card and would share any experience or pitfalls. I have just recently begun investigating and I have really no clue which application should be able to read the data that the USB connection provides. I am also in the process on reading up on v4l in order to find which direction to proceed. Currently I feel I have more knowledge about the chips on the board (I'm a hardware engineer) than the driver and application infrastructure. Eventually this capture card will be used with a UMPC running Linux to monitor moving parts of machinery. (Need to use cheap parts that I can afford to lose during development) Kind regards, -- 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Hauppauge WINTV PVR
On Fri, 28 Jan 2011, Lorne Shantz wrote: I have been using TVtime and the pvrusb2 driver for over a month now, and could not be happier. It is stable as a rock. I'm a little embarrassed to ask this here, but with the record function, then I lose the ability to see what is recording. If I bought another one, would I be then able to record one channel, while viewing another? In other words, will this driver load for two devices at the same time? I think you mean tv-viewer, not tvtime. Every time I see tvtime referenced, I suddenly think that the impossible has happened and tvtime has gained the ability to decode mpeg. But then I looked up old e-mail from you and realized you're really talking about tv-viewer. Shame on you for giving me false hope ;-) To answer your question, yes the driver can run as many devices as you can plug in. Internally the driver handles everything correctly on a per-instance basis. This logic all works perfectly and has been this way since the early days. I've tested this in the past and I've read multiple accounts of people in the past setting multi-tuner PVR systems this way. A possible alternative to the problem you're thinking about might involve the use of tee command. Look it up. You might be able to convince the author of tv-viewer to also look it up... -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] New driver snapshot: pvrusb2-mci-20110116
On Tue, 18 Jan 2011, JE Geiger wrote: Have not seen any comments, so... I downloaded the most recent snapshot and compiled it against my stock 2.6.37. Compiles OK. Appears to work OK. Just wanted to give some feedback. Thanks. It's appreciated! -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] HVR1900 noisy video
On Sat, 22 Jan 2011, Martin MAURER wrote: Hi, Investigating a little further I found that it sometimes gets better when I call /usr/bin/scan at-official (doing an dvb scan). For some reason the analog video is then perfectly fine. I will check if it remains fine, but first tests show that it does. Anyways, adding this to my startup script didn't help for some strange reason (and yes, I checked that is executed correctly) regards, Martin Martin: In *theory* doing something to the DVB side should not affect the quality of the analog side. In reality however, the two sides share the RF tuner, which might suggest that the analog side of the V4L-DVB driver for that RF tuner might not be setting up the chip properly. The pvrusb2 driver, being a bridge driver in V4L-DVB terminology, delegates handling of a lot of the hardware to other drivers within the V4L-DVB subsystem. I'd suspect a misbehavior in the tuner's driver. Making matters worse however is that Hauppauge has a habit of swapping out tuner sections within different manufacturing runs of the same device. So reproducing this doesn't just require another HVR-1900, but an HVR-1900 with the same tuner in it... Unfortunately I don't have any HVR-1900 to test against (I'm in the USA). So I'm kind of stuck here. Can anyone else here with an HVR-1900 (especially if you are using PAL) reproduce this behavior? -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] latest snapshot is failing to build with 2.6.37
Well he did say 2.6.37 in the subject line... I was just thinking about this. In any case right now I believe the in-kernel driver is currently up to date with respect to the snapshot, but I will work this out and get a new snapshot ready ASAP. -Mike On Wed, 5 Jan 2011, JE Geiger wrote: What version of the kernel are you building against/with ??? On Wed, Jan 5, 2011 at 5:26 AM, devsk funt...@yahoo.com wrote: /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c: In function 'pvr2_hdw_load_subdev': /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c:2576:7: warning: passing argument 4 of 'v4l2_i2c_new_subdev' makes integer from pointer without a castinclude/media/v4l2-common.h:148:35: note: expected 'u8' but argument is of type 'const char *' /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c:2576:7: warning: passing argument 5 of 'v4l2_i2c_new_subdev' makes pointer from integer without a cast include/media/v4l2-common.h:148:35: note: expected 'const short unsigned int *' but argument is of type 'short unsigned int' /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c:2576:7: error: too many arguments to function 'v4l2_i2c_new_subdev' include/media/v4l2-common.h:148:35: note: declared here /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c:2596:7: warning: passing argument 4 of 'v4l2_i2c_new_subdev' makes integer from pointer without a cast include/media/v4l2-common.h:148:35: note: expected 'u8' but argument is of type 'const char *' /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c:2596:7: error: too many arguments to function 'v4l2_i2c_new_subdev' include/media/v4l2-common.h:148:35: note: declared here make[2]: *** [/usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.o] Error 1 make[1]: *** [_module_/usr/src/pvrusb2-mci-20100708/driver] Error 2 make[1]: Leaving directory `/var/tmp/linux' make: *** [modules] Error 2 ___ pvrusb2 mailing list pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 ___ pvrusb2 mailing list pvrusb2@isely.net 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] latest snapshot is failing to build with 2.6.37
Given that the in-kernel driver is obviously building fine, then this is just a case of me needing to pull back the patches that deal with this change (and ifdef the changes so that the driver continues to build OK with older kernels). I will get this dealt with but the absolute earliest I will be able to take care of it will be Friday. My day-job has me completely saturated through Thursday night. -Mike On Wed, 5 Jan 2011, JE Geiger wrote: Same results here. Using 2.6.37. Looks like they diddled the functions around v4l: subdev: Merge v4l2_i2c_new_subdev_cfg and v4l2_i2c_new_subdev in 2.6.37. Took me so long to compile that you probably already have the fix. Send to the list when new snapshot is ready and I will retry. Don't you just love API changes after all this time. On Wed, Jan 5, 2011 at 7:53 AM, Mike Isely is...@isely.net wrote: Well he did say 2.6.37 in the subject line... I was just thinking about this. In any case right now I believe the in-kernel driver is currently up to date with respect to the snapshot, but I will work this out and get a new snapshot ready ASAP. -Mike On Wed, 5 Jan 2011, JE Geiger wrote: What version of the kernel are you building against/with ??? On Wed, Jan 5, 2011 at 5:26 AM, devsk funt...@yahoo.com wrote: /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c: In function 'pvr2_hdw_load_subdev': /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c:2576:7: warning: passing argument 4 of 'v4l2_i2c_new_subdev' makes integer from pointer without a castinclude/media/v4l2-common.h:148:35: note: expected 'u8' but argument is of type 'const char *' /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c:2576:7: warning: passing argument 5 of 'v4l2_i2c_new_subdev' makes pointer from integer without a cast include/media/v4l2-common.h:148:35: note: expected 'const short unsigned int *' but argument is of type 'short unsigned int' /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c:2576:7: error: too many arguments to function 'v4l2_i2c_new_subdev' include/media/v4l2-common.h:148:35: note: declared here /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c:2596:7: warning: passing argument 4 of 'v4l2_i2c_new_subdev' makes integer from pointer without a cast include/media/v4l2-common.h:148:35: note: expected 'u8' but argument is of type 'const char *' /usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.c:2596:7: error: too many arguments to function 'v4l2_i2c_new_subdev' include/media/v4l2-common.h:148:35: note: declared here make[2]: *** [/usr/src/pvrusb2-mci-20100708/driver/pvrusb2-hdw.o] Error 1 make[1]: *** [_module_/usr/src/pvrusb2-mci-20100708/driver] Error 2 make[1]: Leaving directory `/var/tmp/linux' make: *** [modules] Error 2 ___ pvrusb2 mailing list pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 ___ pvrusb2 mailing list pvrusb2@isely.net 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 ___ pvrusb2 mailing list pvrusb2@isely.net 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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] WinTV PVR2 issues
On Sat, 18 Dec 2010, Lorne Shantz wrote: Hey! Hold the phone. I completely missed the TV-Time recommendation! It installed fine, configured great, just no video. On a lark, I decided to reboot. Presto!! It is working!! HOLY COW!!! Holy cow is right - because I made no such recommendation. In fact, I said the opposite on the web page. I said basically that it was a great app but had no chance of working with the driver since tvtime can't do mpeg decoding. But you have it working? Has tvtime acquired the ability to decode mpeg? Am I missing something huge here? -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] WinTV PVR2 issues
On Sun, 19 Dec 2010, Lorne Shantz wrote: Sorry Mike. I meant to say TV-Viewer! I was using tvtime on my old pci card. That was the last recommendation you made must prior to Myth. Almost missed it. The view is crystal clear now, instead of the nasty ol grainy pci card. AWESOME. Tv-Viewer 0.8.1.1 works great. Recording, playing, timeshifting, all of it. Perplexed why absolutely nothing else would work though. Unless now that I have rebooted, that would work too. ?? That makes far more sense. The author of TV-Viewer used a pvrusb2 device as one of his development targets... But yes, if TV-Viewer is working for you, then the driver is completely healthy and the remaining problems, if any, must have to do with the application. If a reboot was the last step before TV-Viewer then you may be right about retrying those other apps. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] AVC-3610 Support??
On Thu, 11 Nov 2010, Bjorn de la Cour wrote: Hey Mike, I give up on trying to photograph the insides of the AVC-3610, I have tried. My Camera isn't good enough. I might get one new for the xmas but that's a ways away. So, If you want me do something else with the AVC-3610 I'll see if I can do it. Or if you want I can just send the Damn AVC-3510 and you can work on it sometime in 2011. Oh, sorry to hear that. I really didn't think it would be that difficult. These days I figured any modern point-and-shoot with a macro mode (the flower icon in the shooting mode list) should do it. The pictures I've taken: http://www.isely.net/gallery2/v/PVR+Hardware/ were done with a DSLR bought back in 2005 (along with a cheap halogen desk lamp for illumination). If you want to send me the AVC-3610 I'll take a shot at it. However right now for the next few months I am totally swamped on another project (this one pays bills). So no hurry. I am interested in trying to integrate support for this device however because you're not the first one to ask. If you'd like to do that we can exchange direct contact information off the list (e-mail to is...@pobox.com or is...@isely.net or both) BTW there are two of the following NOT one like my earlier email stated. Conexant CX25840-23 CY7C68013- 100DC 0519 I think it's a Cypress Chip from the logo. Ah! That's *very* useful to know. My concern about this device is how a single FX2 (that's the Cypress chip) could be handling two video paths. The answer to that would likely involve a lot of strange custom firmware which would make it hard to provide support. However if you have two of those FX2 parts (and two the CX25840 parts - the video digitizer and audio processor) then the whole thing makes a lot more sense now. I'd be willing to bet that you also have a tiny little USB hub on the PCB there somewhere and that when you plug in the device, the usbview program probably shows a new hub appearing with two instances of this device (each corresponding to one of the FX2 microcontrollers). I wish that I could have been more helpful. That last bit about the extra chips present was very helpful actually. You just significantly raised the odds that I can get the pvrusb2 driver to work with it! -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] AVC-3610 Support??
On Thu, 21 Oct 2010, Bjorn de la Cour wrote: I forget the camera at work. But I thought I would just list some chip markings. Tuners 2x: Philips FM136/F H-3 SV21 0534 One of the Tuners doesn't have the FM RF connector. mpeg Encoders? 2x: Conexant MPEG II A/V Encoder CX23416-12 Others: Conexant CX25840-23 CY7C68013- 100DC 0519 I think it's a Cypress Chip from the logo. There are other chips But I think they are related to the IR functions. By the way I did some damage to your future testing unit while opening the case. Whatever happened to good old fashion screws? There's just a single CY7C68013 but two CX23416's and two CX25840's? This sounds like it should work, except for the bit about a single FX2 (the CY7C68013) driving two video pipelines. The normal firmware in that chip only expects to talk to a single tuner, not two. That may cause a hiccup with the pvrusb2 driver since it was never designed with a configuration like that. Otherwise all the chips you've identified are workable - in fact ignoring the dual pipeline setup this appears very similar to a Hauppauge 24xxx device. Odds are pretty good that you should see an I2C EEPROM on the board. It might be a very tiny chip (perhaps an 8 pin SMT part). Knowing its ID will tell us its capacity and from that we can probably guess whether or not the FX2 firmware has to be loaded from the host. (The pvrusb2 driver can handle it either way but we have to know.) Having a hi-res photo of the whole board is where things like the question about the I2C EEPROM can come in handy. That would give a means to go back and examine it for parts missed on the first pass. Sorry about the reply delay; it's been a busy week here and I've been distracted on a different project. Now off to handle a pvrusb2 e-mail backlog... -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] problems with pvrusb
On Thu, 21 Oct 2010, Jim Peters wrote: I have 4 of these tuners, 3 of them are the 24xx series and 1 is a 29xx series, at one time they all worked great and I am not sure what happened to cause this but at some point the 29xx tuner started outputting black and white video. At first I suspected a hardware failure and thought maybe it was in the analog tuner part of the card so I switched it over to using the composite side but this didn't help. As a last resort to chalking it up as a failed piece of hardware I tried it on a windows machine and it works fine there so I am under the impression that this must be a driver/firmware issue. Since my other 3 tuners don't have a problem I assume that there must be some part of the driver/firmware that only affects the 29xx series cards and the problem lies within this, I have no idea where to look for a solution, any help would be appreciated. This is a very strange issue. There's really nothing in the driver that can cause the video to go BW. The only thing that I can come up with is that the 29xxx device is being configured with the wrong video standard. Most analog video standards use pretty much the same scheme for encoding luminance and sync info - the differences are just parmaeters: the number of scan lines, interlacing, and vertical refresh rate. But when color TV first became common so long ago, the standard got forked and different countries adopted different means for encoding a color subcarrier. That's really the big difference between NTSC vs PAL vs SECAM. The outward effect of this is that if you have the wrong video standard set, one likely result is that you'll still be close enough that the hardware can manage to get a lock on the sync pulses and the luminance but will fail to identify the chrominance / hue components of the signal. Result: Black and white video. Now with that said, everything you do to configure the 24xxx devices should be the same as for the 29xxx device. They do have different hardware so I suppose another possibility is that they're all configured wrong but the 24xxx devices have chips that are successfully autodetecting the video format in spite of what they were told. Just guessing, but those are things I'd look for. It's also possible that a bug has crept into the saa7115 driver in v4l-dvb which has gone unnoticed - that driver is unique for the 29xxx devices. It's not like that hasn't happened before. To test for that, I'd try to boot an older kernel, preferably one that you knew worked before. As for firmware issues, that's pretty unlikely here. The 29xxx and 24xxx devices can share the same mpeg encoder firmware so if you got that wrong they'd all be busted. The 29xxx and 24xxx devices use completely different FX2 firmware (the file names encode their type so there's no collision on systems with both device types). But the FX2 firmware is basic to controlling the entire device and if you corrupted the 29xxx version then it just isn't going to work at all. There's actually nothing in the FX2 firmware that can interfere with color vs BW video since the video standard info is sent directly to the individual chips over I2C and since the video data itself never actually gets into the FX2 processor (it's a dog-slow 8051 - no way could it keep up with that sort of data stream). Operating system Mythbuntu Linux 10.04.1 Automatic Daily builds mythtv version .23 Kernel and CPULinux 2.6.32-25-generic on x86_64 Processor information Dual Core AMD Opteron(tm) Processor 270, 4 cores Real memory 3.75 GB total, 504.48 MB used A long time ago I acquired a 29xxx device that had a problem where it would only produce BW video. No matter what I did with it, the damn thing would never produce color. I spent 6 WEEKS trying to figure out what kind of pvrusb2 driver bug could cause this and found nothing at all. Then I tried it on a Windows system - and got BW video. And that's when I RMA'ed the device back to Hauppauge. However you said you tried in Windows successfully so that pretty much proves that the hardware is fine. I'd look hard at the video standard to which it has been configured. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] HVR-1950 -- Have I messed up the fw installation?
an application like mythtv or xawtv will do for you. Or, as you did above, mplayer. However a lot of those settings you specified have driver internal defaults that should be fine. The pvrusb2 driver has a lot of knobs you can twiddle - but it doesn't mean you have to twiddle them all! The pvrusb2 driver has another means to operate its API. This can be done entirely from the shell, no application required. With that API you can in fact set it up with a few echo commands and then cat /dev/video1 to capture the stream. A lot of people do this and it's a great way to at least verify that the driver is working. But rather than describe it again here, I recommend you read the web page that documents it. Look here: http://www.isely.net/pvrusb2/usage.html#sysfs Or, more generally, for overall usage: http://www.isely.net/pvrusb2/usage.html I have not been able to watch broadcasts yet. I'm not sure what that would take. I cannot get xawtv to detect my tuner. Using xawtv has some additional caveats. You need to run a 4.x version of it and it must be compiled with the right support. Otherwise you won't be able to see any video with it. Long story, but similar to the above, see here: http://www.isely.net/pvrusb2/usage.html#xawtv Unfortunately I believe xawtv has been unmaintained for quite some time now :-( -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] AVC-3610 Support??
On Wed, 27 Oct 2010, Lorne Shantz wrote: Hey Mike, Probably not the place for this, but I keep forgetting to ask. Since I absolutely can not get Myth TV working right, what other program can I use to play the USB Hauppauge PVR card on? It is about as useful as a door stop at this point. Would sure be nice to be able to watch TV on it, since it is so much clearer than an internal card I am using. Try here: http://www.isely.net/pvrusb2/usage.html#V4L There are sections on that page that give advice for various apps when used with the driver. Hope that helps. -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] AVC-3610 Support??
On Wed, 20 Oct 2010, Bjorn de la Cour wrote: Okay Mike, so I have some more free time to try and get AVC-3610 working. If I was to ether take it apart to get chip IDs, send the USB software capture output from windows XP. Would you be able to tell if the PVRUSB2 drivers could be used for the AVC-3610. Which is better or should I just do both. If you think it is possible to modify the drivers. I would be willing to send you a AVC-3610. I just don't want to send one if it's not unlikely the you can modify the drivers. I understand that your time is limited so am hoping that it's just adding a few extra lines of code. Bjorn: I'd start by looking at the chips. Take off the cover and shoot a nice steady well-light high resolution digital picture of the board. Possible also shoot additional zoomed photos of the major chips if the primary picture can be detailed enough. Do that and it should be the only time you'll have to pop the cover - since we can always go back and look at the photos again. Knowing the chips that are present we can probably make a fair guess about whether or not the pvrusb2 driver has a chance of working with it. If so, then there's more experiments to do (one of which involves capturing USB traffic as you suspect). As for my time and interest, I am interested in seeing this work. But as we approach the holidays my time is going to get progressively more scarce. I have another hobby which involves a capella harmony and as you might imagine that gets pretty busy towards the holidays. Even now this is already starting to ramp up. Start with some board photos first; that will probably give an idea of how easy / difficult this effort will likely be. After that we can worry about time and effort. (Fact is, getting this device going has been a desire of multiple people over several years so in the overall grand scheme of things a few weeks is not a big effect.) -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
Re: [pvrusb2] Driver status [was:CPU Run pvrusb2-context]
On Fri, 15 Oct 2010, JE Geiger wrote: 2.6.36 is not finalized, but I did pull down 2.6.35.7 from kernel.org and compiled. The module pvrusb2 modprobes and rmmods just fine without doing the isely.net snapshot module compile. HVR-1950 device performs capture fine. Does the FM radio front end in the HVR-1950 work with pvrusb2? I recall some posts from the past indicating that the FM radio was not functional. No, it's not there. The reason is not simple. Unlike previous tuners, in the case of the HVR-1950 support of FM requires: 1. A specific firmware load for the cx25840 driver 2. Some kind of special mode switch issued to the cx25840 driver in order to enable FM reception, i.e. enable mode XYZ because we're on an HVR-1950/HVR-1900 tuner. 3. Last I checked, the V4L internal API lacks the needed capability for issuing any kind of mode switch like this to the cx25840 module - because until now such a thing was never needed. I know that Mike Krufky has done work to prove in the capability for FM support but he did it by hardcoding the required cx25840 mode switch - in other words his changes would break every other use of the cx25840 driver. Getting past this requires internal V4L changes. Plus there's no mechanism in V4L to identify cx25840 firmware blob versions so any changes to the cx25840 module to support this mode also has to depend on specific firmware which we can't even confirm has been loaded into the hardware (so at the very least if the wrong firmware is present we need to ensure that setting that mode results in benign misbehavior). Notice how unfortunately almost none of this actually has to do with the pvrusb2 driver itself. Enabling this on the pvrusb2 side is literally a single bit change in pvrusb2-devattr.c. Well and maybe a few snippets to enable that cx25840 mode setting once it becomes possible to actually do such a thing in V4L. Sigh :-( -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 pvrusb2@isely.net http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
