On Fri, 2008-11-21 at 23:33 -0500, Al McIntosh wrote: > > The "easy" options appear to be: > > 1. Move the cx18 to a different PCI slot so it no longer > shares an IRQ > line with the nvidia hardware. > > > I managed to get the encoder on an unshared IRQ line in the single CPU > machine. It's better but still pauses. > > > 19: 9923 IO-APIC-fasteoi cx18-0 > > > [ 12.137056] cx18: Start initialization, version 1.0.2 > > [ 12.157546] cx18-0: Initializing card #0 > [ 12.157552] cx18-0: Autodetected Hauppauge card > [ 12.157557] cx18-0 info: base addr: 0xf8000000 > [ 12.157559] cx18-0 info: Enabling pci device > [ 12.158002] cx18 0000:01:09.0: PCI INT A -> Link[APC4] -> GSI 19 > (level, low) -> IRQ 19 > > [ 12.158011] cx18-0: Unreasonably low latency timer, setting to 64 > (was 32) > [ 12.158017] cx18-0 info: cx23418 (rev 0) at 01:09.0, irq: 19, > latency: 64, memory: 0xf8000000 > [ 12.158021] cx18-0 info: attempting ioremap at 0xf8000000 len > 0x04000000
Hmm. 1. Can you point me to a sample of some video and the log messages generated with 'debug=15' (dma, mailbox, info, warning) on one trial, and the log messages with 'debug=399' (+ hi & irq) for a second trial. You may find something like # echo 399 > /sys/module/cx18/parameters/debug useful for this. 2. Well a single core machine is still bottle-necked by any driver module that requests an interrupt with IRQF_DISABLED, disabling local interrupts when it runs it's irq handler - Especially if the hardware generates a lot of interrupts. Also the nvidia hardware is at IRQ 18 while the CX23418 hardware is now on IRQ 19 which is a lower priority I believe. You could look at /proc/interrupts and look for the high interrupt count devices and try to unload their modules one by one to isolate the offender. Unloading the nvidia module may mean dropping down to runlevel three (stopping X) are running a capture with "cat /dev/video > foo.mpg" and looking at the log for changes in the symptoms. 3. Changing the buffersize to be larger by using the 'enc_mpg_buffers' option to ask for a lot more memory (maybe 8 MB), may slow the rate of interrupts from the CX23418 firmware handing over capture buffers, so things are better. Unfortunately I don't have much more advice. The CX23418 firmware apparently expects a particular level of responsiveness (which depends in part on how big the buffers you give it are) from the system. If a higher priority irq_handler is disabling interrupts for a non-trivial fraction of time on a single core machine, there will be times you're likely not going to make the CX23418 firmware's time line. Regards, Andy _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
