Andy Walls <[email protected]> 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 > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-users > _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
