On Fri, 2010-10-01 at 11:52 -0400, Jay R. Ashworth wrote:
> ---- Original Message -----
> From: "John Drescher" <[email protected]>:
> > On Fri, Oct 1, 2010 at 10:59 AM, Jay R. Ashworth <[email protected]>
> > wrote:
> > > Just hard-upgraded the sis's Mythbox to SuSE 11.3 (2.6.34) and Myth
> > > .23.1
> > >
> > > And, of course, because I didn't do my homework, I'm getting the
> > >
> > > *********************** WARNING ***********************
> > > ivtv drivers prior to 0.10.0 can cause lockups when
> > > reading VBI. Drivers between 0.10.5 and 1.0.3+ do not
> > > properly capture VBI data on PVR-250 and PVR-350 cards.
> > >
> > > error.
> > >
> > > My ivtvctl says it's 0.10.5, in fact, and we're actually still
> > > locking the machine.
Does your machine provide any sort of Oops or BUG output in the logs
before the hang?
If it does I'd like to see it.
If it does not, odds are you have a Motherboard PCI Chipset / CX23416
PCI device incompatibility. If you haven't changed the motherboard and
the locking up is new, then it is likely the Linux PCI subsystem is
initializing your motherboard chipset differently with the new kernel.
(The ivtv driver has had a few changes, but I don't think they're
capable of locking the machine; making only the CX23416 act improperly
is more likely.)
Look at the output of
$ lspci -tnnvv
for all the PCI bridges between the CPU and the CX23416.
One can then check the history of the kernel's "drivers/pci/quirks.c"
code to see if any specific changes happened for you PCI chipset:
http://git.linuxtv.org/media_tree.git?a=history;f=drivers/pci/quirks.c;h=477345d416417c58662ea8386a0841ba65d0dd72;hb=9fe6206f400646a2322096b56c59891d530e8d51
If they have, try backing them out of your kernel.
> > > My *question*, though, is this: how do you upgrade the actual driver
> > > now that it's in the mainline? The ivtvdriver.org howto doesn't actually
> > > cover this, and, at 2.6.34, I don't have a lot of kernel upgrading
> > > left to do -- I would *really* prefer not to have to go off the
> > > reservation, kernel wise, if I don't have to.
> > >
> > > Can Andy or someone give me the 3 sentence precis of this, and once
> > > I've got it done, I'll write it up for the wiki?
> > >
> > > ( Sorry this is poorly threaded, but my mailer won't let me at the
> > > damn references header to unlink it... )
> > >
> >
> > It has been years since I have debugged ivtv (it just works now!)
> > anyways I believe the kernel driver would be a recent version just
> > that the client applications ivtvctrl ... are ancient. Check your
> > dmesg to verify that. There should be the driver version in the ivtv
> > initialization line.
>
> And I just did that, and to my surprise, while my *ivtvctl* is 0.10.5,
> my driver is in fact 1.4.1.
>
> It's not possible that the mismatched utilities package is what's causing
> this, is it?
Well the V4L2 API is pretty stable, so things shouldn't be too bad, with
a mismatch within a few years time.
Obviously using the latest ivtv-utils and v4l2-apps would probably be
best.
> I've been told that the utilities are supposed to Just
> Match the driver, but clearly, Suse didn't get the memo.
>
> In other news: why am I getting the backend error I am, if I'm on the
> right driver? (I know: ask the Myth people. :-)
Dunno, what's the error?
If you kill the backend does:
v4l2-ctl -d /dev/video0 -i 0 <--- tuner input
ivtv-tune -d /dev/video0 -t us-bcast -c 7 <--- Channel 7
mplayer /dev/video0
Show you channel 7 video?
Regards,
Andy
> Cheers,
> -- jra
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
