[ivtv-users] cx18 video corruption
Daniel Flesner
danimal at agriroots.com
Fri Oct 2 05:20:03 CEST 2009
Andy Walls <awalls at radix.net> writes:
> Dan,
>
> On Wed, 2009-09-30 at 22:33 -0400, Daniel Flesner wrote:
>> i have an hvr-1600 that i'm trying to get working with local cable's
>> free HD channels. it mostly works very nice (thanks andy), but the video
>> has small corruptions in it. if i look at the dmesg i have errors like:
>>
>> cx18-0: warning: failed to be awakened upon RPU acknowledgment sending
>> CX18_CPU_DE_SET_MDL; timed out waiting 14 msecs
>> cx18-0: warning: failed to be awakened upon RPU acknowledgment sending
>> CX18_CPU_DE_SET_MDL; timed out waiting 11 msecs
>> cx18-0: warning: failed to be awakened upon RPU acknowledgment sending
>> CX18_CPU_DE_SET_MDL; timed out waiting 14 msecs
>> cx18-0: warning: failed to be awakened upon RPU acknowledgment sending
>> CX18_CPU_DE_SET_MDL; timed out waiting 15 msecs
>
> Those are actually harmless. Those are outgoing empty buffers being
> handed back to the CX23418 firmware. They are taking a long time to get
> acknowledged which happens because:
>
> 1. The CX23418 didn't immediately acknowledge the buffer handover.
> That's normal, and in practice, I've found it doesn't happen frequently,
>
> and
>
> 2. When the cx-18-0-out/n thread goes to sleep waiting on the
> acknowledgment from the firmware, and the firmware causes the IRQ
> handler to send a wake-up, the linux *scheduler* takes a long time to
> put cx18-0-out/n back into a running state.
>
>
> What has normally happened is that the CX23418 firmware actually has
> acknowledeged the bufffer handover, but the cx18-0-out/n thread didn't
> get notified until much later.
>
> So unless you get a solid stream of these messages, this warning message
> is harmless in terms of cx18. What it does indicate is that at least
> one of your CPU cores (the one running the cx18-0-out/n thread in
> question) is very busy and/or the scheduler isn't doing a very good job.
> 15 ms is kinda of long to be asleep, but I've seen 10 ms many times
> before with my Fedora 10 setup.
>
>
> Please turn on debug info warn and mailbox in the cx18 driver and note
> how often you get the "Possibly falling behind" warning. That's the one
> that's indicative of potential incoming video processing delays by your
> system.
i turned on more debug info and only got a single warning on the
recording tonight.
>
>
>> i'm running fedora 11 with the latest kernel, i tried updating the
>> v4l-dvb driver, but the behavior seems the same.
>
> Indicative of a system level issue vs. a driver level one.
>
>
>> i read a while back about interrupt problems, the interrupt info for my
>> machine is:
>>
>> cat /proc/interrupts
>> CPU0 CPU1 CPU2 CPU3
>> 0: 281 111 234 191 IO-APIC-edge
>> timer
>> 1: 1 1 0 0 IO-APIC-edge
>> i8042
>> 8: 7 8 16 13 IO-APIC-edge
>> rtc0
>> 9: 0 0 0 0 IO-APIC-fasteoi
>> acpi
>> 12: 0 2 2 0 IO-APIC-edge
>> i8042
>> 16: 220827 129818 98284 46306 IO-APIC-fasteoi
>> uhci_hcd:usb3, uhci_hcd:usb8, nvidia
>> 17: 2586763 2548712 1974642 1930591 IO-APIC-fasteoi
>> cx18-0
>> 18: 118657 53841 124164 64003 IO-APIC-fasteoi
>> ehci_hcd:usb1, uhci_hcd:usb7
>> 19: 0 0 0 0 IO-APIC-fasteoi
>> uhci_hcd:usb6
>> 20: 1673 241 823 486 IO-APIC-fasteoi
>> firewire_ohci
>> 21: 0 0 0 0 IO-APIC-fasteoi
>> uhci_hcd:usb4
>> 22: 20843 5755 23756 7796 IO-APIC-fasteoi HDA
>> Intel
>> 23: 1594911 1485736 1468820 1426265 IO-APIC-fasteoi
>> ehci_hcd:usb2, uhci_hcd:usb5
>> 27: 1095 1095 1607156 1306382 PCI-MSI-edge
>> ahci
>> 28: 60 9700117 54 60 PCI-MSI-edge
>> eth0
>> NMI: 0 0 0 0 Non-maskable
>> interrupts
>> LOC: 71028778 71198700 68479506 66790971 Local timer
>> interrupts
>> SPU: 0 0 0 0 Spurious interrupts
>> RES: 873725 646350 996161 709235 Rescheduling
>> interrupts
>> CAL: 12575 10193 10957 11134 Function call
>> interrupts
>> TLB: 691919 910061 754828 948509 TLB shootdowns
>> TRM: 0 0 0 0 Thermal event
>> interrupts
>> THR: 0 0 0 0 Threshold APIC
>> interrupts
>> ERR: 0
>> MIS: 0
>>
>> it looks to me that the cx18 has it's own interrupt, so i guess that's
>> not the problem?
>
> That's correct in that no other linux driver in particular is directly
> to blame.
>
> I notice that your interrupts are generally balanced, but there is an
> assymetry between CPU0/1 and CPU2/3 (execpt for a different assymetry
> with the USB hubs).
>
> That might explain why the cx18-0-out/n thread is held off for a "long"
> time at times, but again, that's nothing to worry about.
>
>
>> also, here's the driver initialization log:
>>
>> cx18: Start initialization, version 1.2.0
>> cx18-0: Initializing card 0
>> cx18-0: Autodetected Hauppauge card
>> cx18-0: info: base addr: 0xf4000000
>> cx18-0: info: Enabling pci device
>> cx18 0000:01:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
>> cx18-0: info: cx23418 (rev 0) at 01:00.0, irq: 17, latency: 64, memory: 0xf4000000
>> cx18-0: info: attempting ioremap at 0xf4000000 len 0x04000000
>> cx18-0: cx23418 revision 01010000 (B)
>> cx18-0: info: GPIO initial dir: 0000ffff/0000ffff out: 00000000/00000000
>> cx18-0: info: activating i2c...
>> cx18-0: Autodetected Hauppauge HVR-1600
>> cx18-0: info: NTSC tuner detected
>> cx18-0: Simultaneous Digital and Analog TV capture supported
>> IRQ 17/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs
>> tuner 2-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
>> cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
>> cx18-0: info: Allocate encoder MPEG stream: 64 x 32768 buffers (2048kB total)
>> cx18-0: info: Allocate TS stream: 32 x 32768 buffers (1024kB total)
>> cx18-0: info: Allocate encoder YUV stream: 16 x 131072 buffers (2048kB total)
>> cx18-0: info: Allocate encoder VBI stream: 20 x 51984 buffers (1015kB total)
>> cx18-0: info: Allocate encoder PCM audio stream: 256 x 4096 buffers (1024kB total)
>> cx18-0: info: Allocate encoder IDX stream: 32 x 32768 buffers (1024kB total)
>> cx18-0: Registered device video0 for encoder MPEG (64 x 32 kB)
>> DVB: registering new adapter (cx18)
>> cx18-0: DVB Frontend registered
>> cx18-0: Registered DVB adapter0 for TS (32 x 32 kB)
>> cx18-0: Registered device video32 for encoder YUV (16 x 128 kB)
>> cx18-0: Registered device vbi0 for encoder VBI (20 x 51984 bytes)
>> cx18-0: Registered device video24 for encoder PCM audio (256 x 4 kB)
>> cx18-0: Initialized card: Hauppauge HVR-1600
>> cx18: End initialization
>> cx18 0000:01:00.0: firmware: requesting v4l-cx23418-cpu.fw
>> cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
>> cx18 0000:01:00.0: firmware: requesting v4l-cx23418-apu.fw
>> cx18-0: info: load segment a00000-a07fff
>> cx18-0: info: load segment ae0000-ae00ff
>> cx18-0: info: load segment b00000-b1a65f
>> cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes)
>> cx18-0: info: 1 MiniMe Encoder Firmware 0.0.74.0 (Release 2007/03/12)
>> cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
>> cx18 0000:01:00.0: firmware: requesting v4l-cx23418-cpu.fw
>> cx18 0000:01:00.0: firmware: requesting v4l-cx23418-apu.fw
>> cx18-0: info: load segment a00000-a07fff
>> cx18-0: info: load segment ae0000-ae00ff
>> cx18-0: info: load segment b00000-b1a65f
>> cx18-0: info: 1 MiniMe Encoder Firmware 0.0.74.0 (Release 2007/03/12)
>> cx18 0000:01:00.0: firmware: requesting v4l-cx23418-dig.fw
>> cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
>> cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes)
>> cx18-0: info: Changing input from 1 to 0
>> cx18-0: info: Mute
>> cx18-0 843: info: decoder set video input 7, audio input 8
>> cx18-0 843: info: decoder set video input 7, audio input 8
>> cx18-0: info: Unmute
>> cx18-0: info: Switching standard to 1000.
>> cx18-0 843: info: changing video std to fmt 1
>> cx18-0 843: info: PLL regs = int: 15, frac: 2876158, post: 4
>> cx18-0 843: info: Video PLL = 107.999999 MHz
>> cx18-0 843: info: Pixel rate = 13.499999 Mpixel/sec
>> cx18-0 843: info: ADC XTAL/pixel clock decimation ratio = 2.121
>> cx18-0 843: info: Chroma sub-carrier initial freq = 3.579545 MHz
>> cx18-0 843: info: hblank 122, hactive 720, vblank 26, vactive 481, vblank656 38, src_dec 543, burst 0x5a, luma_lpf 1, uv_lpf 1, comb 0x66, sc 0x087c00
>>
>>
>> was wondering what else i can do to fix or help fix the problem, the
>> jitter can get annoying and sometimes mplayer crashes with corrupted
>> video and/or audio packets from the capture file.
>
>
> This sounds like a cable signal level problem. When capturing, please
> run femon in a terminal window and look for periods where the
> uncorrectable block count increases. If you get those, and the
> correspond roughly to when the artifacts occur, then cable TV signal is
> the problem.
i ran femon during the capture tonight and did get what looks like some
bit errors. it ran predominately with the ber 0's messages, but once in
a while with the ber set to a non 0 value as below:
status 1f | signal 013a | snr 0138 | ber 00000000 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal 013a | snr 013a | ber 00000000 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal 0138 | snr 0138 | ber 00000000 | unc 00000000 |
FE_HAS_LOCK
status 1f | signal 013a | snr 013a | ber 00000276 | unc 00000276 |
FE_HAS_LOCK
so it appears it is a signal quality issue. i need an external amplifier
then i suppose? i did add a splitter and an extra line for the digital
input when i got the hvr1600 so maybe that is the issue. the splitter is
rated to 2300Mhz so that is fine right? what are acceptable values for
the signal and/or snr above?
>
> You should also be using the "-cache 8192" option with mplayer to
> mitigate the effects of any buffer delivery jitter or TS stream
> corruption.
i do run mplayer with the cache flag.
>
> BTW, MythTV is very good at smoothing over the rough spots on which
> mplayer chokes.
>
> Regards,
> Andy
>
>> thanks for any help,
>> dan
>
thanks again,
dan
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users at ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
More information about the ivtv-users
mailing list