On Sat, 2008-11-22 at 00:14 -0500, Andy Walls wrote: > 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. >
Other things to try: 4. With v4l2-ctl set the MPEG bit rates lower to reduce the rate of buffer interrupts. maybe the system can keep up at a reduced data rate. 5. With v4l2-ctl set the MPEG encoder stream_type to TS. It's a little easier to resync a TS that's corrupted than a PS that is corrupted, since a TS has headers every 188 bytes (IIRC). 6. Use the 'nosmp' kernel command line option to hopefully optimize the behavior of irq disabling calls in the kernel for a UP machine. 7. Limit processes running in user space to the absolute minimum that you need. User space apps make calls to drivers, that may cause the drivers to disable local interrupts while servicing their interrupts. Why have applications you don't need possibly increasing interrupt latency? I guess the big picture take away is, that you have a system level latency which is longer than what can be tolerated by the capture (given requested bitrate and other parameters) requested of the CX23418. I've optimized the cx18 irq handler top half as much as I can without making software maintenance a nightmare. This is a system tuning problem at this point. At least that's my current working hypothesis. Maybe verbose logs will reveal something different: PCI bus errors of some sort, the application is not reading buffers out fast enough so the encoder is starved of buffers to use, ...? OK - now I am really out of ideas. :) Regards, Andy _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
