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'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. You should also be using the "-cache 8192" option with mplayer to mitigate the effects of any buffer delivery jitter or TS stream corruption. BTW, MythTV is very good at smoothing over the rough spots on which mplayer chokes. Regards, Andy > thanks for any help, > dan _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
