Andy Walls <[email protected]> writes:
> On Sun, 2010-01-24 at 20:46 -0500, Peter Budny wrote:
>> I have a PVR-150 that's creating weird video. To start with, here's a
>> sample:
>>
>> http://www.cc.gatech.edu/~bigpeteb/test.mpg
>>
>> It seems to depend on the scene: some scenes display fine while others
>> have the glitch. I'm running through a set-top box so this is all
>> recorded on channel 3 on the card, regardless of what station I'm
>> watching.
>>
>> This card worked fine under linux-2.6.18 kernel with the appropriate
>> IVTV drivers. Now it's in a new machine
>
> So just to clarify, new hardware configuration as well as a new kernel
> and driver version?
Correct, new hardware configuration and new kernel+driver. But, on the
old machine I recall having similar glitches if I used anything newer
than 2.6.17 (I said .18 above, meant .17). At the time I just put the
old kernel and drivers back on and left it. I'd forgotten about it
until I put the card in a new machine.
>> (uname -a: Linux dvr
>> 2.6.31-gentoo-r6 #6 SMP Wed Jan 13 15:21:20 EST 2010 x86_64 Intel(R)
>> Celeron(R) CPU E3200 @ 2.40GHz GenuineIntel GNU/Linux) and it has this
>> problem.
>>
>> My first guess is that it's a buffer issue, perhaps that the buffer is
>> too small. I can't find in the docs how to set the buffer size.
>
> I concur that the problem is a buffer issue: likely missed or dropped.
>
> Do you get messages from these lines in your logs:
>
> IVTV_WARN("All %s stream buffers are full. Dropping data.\n",
> s->name);
> IVTV_WARN("Cause: the application is not reading fast enough.\n");
>
> ? Or maybe some other warnings from the ivtv driver?
I tried turning on some debugging, as you suggested, and it generated
only normal-seeming messages (a lot of DMA completed and IRQ completed,
nothing indicating errors).
After playing around with some parameters on the module, I see no
real effects. I tried doubling the size of all the encoding buffers,
but I still had the same broken video.
The only thing that seemed to be out of place was an occasional message
"ivtv0: warn: encoder VBI: Couldn't find start of buffer within the
first 256 bytes"
>> I'd appreciate any suggestions to try.
>
> My first guess would be an IRQ service problem:
>
> 1. A device sharing the IRQ line with the CX23416 has a device driver
> that sometimes errantly claims the CX23416's interrupt as it's own
> (IRQ_HANDLED). Or maybe both devices generate a lot of interrupts and
> hence some end up coincident in time.
>
> 2. A device sharing the IRQ line with the CX23416 has an irq handler
> that sometimes takes a long time to execute and doesn't complete quickly
> in that situation. (e.g. The ahci disk controller driver used to have
> an error path in its irq handler that could take a really long time.)
>
> 'cat /proc/interrupts' will show you if any device is sharing the IRQ
> line with the ivtv driver.
'cat /proc/interrupts' indicates, among other things
14: 1596863 1597175 IO-APIC-edge ata_piix
15: 0 0 IO-APIC-edge ata_piix
16: 6691638 6689226 IO-APIC-fasteoi uhci_hcd:usb5, HDA Intel, nvidia
19: 6894042 6894148 IO-APIC-fasteoi ata_piix, uhci_hcd:usb3, ivtv0
so the disk may be on the same IRQ as the IVTV card. (Probably so,
since it's a SATA disk.)
> My next guess would be PCI bus loading:
>
> Watching LiveTV with MythTV has at least three devices working that
> present a non-trivial load on the I/O buses: a disk controller, a
> graphics card, and the tv capture card.
>
> '/sbin/lspci -tv' will show you the bus segment hierarchy. See if
> there is an obvious bottleneck, such as a PCI bus segment shared with
> the CX23416 and a disk controller behind a PCI-PCI bridge. Check the
> latency timer settings of the PCI-PCI bridge.
>
> You also might just want to record TV, without displaying at the same
> time:
>
> cat /dev/video0 > test.mpg
> ^C
> mplayer test.mpg
>
> and see if you still have the glitches. But then again, that may be how
> you captured the one test clip to begin with.
This was indeed how I captured the test clip. Seems to make no
difference whether I use MythTV, or cat, or mplayer.
> My next guess would be some sort of DMA issue:
>
> I'm not sure what to do here. The DMA process for the CX23416 is very
> different from the CX23418 - I still need to come up to speed on it. I
> know that the kernel's software IO TLB can affect performance since it
> will use bounce buffers under certain conditions (but it shouldn't drop
> buffers). Your system will say something about SWIOTLB or SW IOMMU in
> the dmesg messages that happen at reboot, if it does.
>
>
> My final guess would be a CX25843 digitizer VSYNC detection and locking
> problem.
>
> If this card has worked with this STB before, then this is highly
> unlikely.
Well, I'm not sure how to go about determining which of these is the
problem. I have some kernel development experience from classes I've
taken, but nothing at this level. If you can walk me through some
things to try I'll see if they help, and if there's a bug hiding in the
driver maybe I can help track it down.
Thanks in advance for any help you can provide,
--
Peter Budny \
Georgia Tech \
CS PhD student \
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
