On Thu, 2012-01-26 at 18:39 -0600, [email protected] wrote:
> ==============Original message text===============
> On Wed, 25 Jan 2012 9:40:11 pm CST Andy Walls wrote:
> [email protected] wrote:
> >>Hello,
> >>I have two servers running Mythbuntu 11.04 and MythTV 0.24.1.
> >>I have
> >>three PVR-150 tuners in the server configured as a slave backend, and
> >>some digital tuners in the master backend. The problem I have is that
> >>whenever the analog tuners are called for by any frontend (even a local
> >>one), I get distorted video, with stuttering and image freezes. There
> >>is
> >>currently a bug report in with MythTV on a �Analog Channel Change�
> >>issue.
> >>I have tried the work-a-round (tune a digital channel before using one
> >>of
> >>the analog tuners), but it does not work for me. I finally saw some
> >>troubleshooting steps for IVTV drivers, and followed some of those
> >>steps.
> >>The one that caught my attention, is the �cat /dev/video1 > test.mpg�
> >>test. I looked at the file that was produced while the command was
> >>active, and VLC would only play a few seconds of the file and then skip
> >>to the end, and then terminate the viewing window. The video jumped
> >>and
> >>was distorted, just the same as it was in MythTV. So the issue,
> >>evidently, is not MythTV, but perhaps with IVTV or some related item.
> >>On a related note, the same hardware works without issues, when
> >>running
> >>MythTV 0.21 under Mythbuntu 8.10.
> >>What would you do next and where would you look for a>>resolution?
> >>Thanks,
> >>Jeff
> >What are the kernel versions shown with uname -a?
> Linux MYTHBE2 2.6.38-13-generic #54-Ubuntu SMP Tue Jan 3 13:44:52 UTC
> 2012 i686 i686 i386 GNU/Linux
OK, fairly modern; that's good. Do you happen to know the kernel
version under Mythbuntu 8.10? (so I check the differences between the
two kernels)
> >What are the ivtv-driver versions shown with v4l2-ctl -d /dev/video1
> >--log-status?
> ivtv1: Version: 1.4.2 Card: Hauppauge WinTV PVR-150
OK, good.
> >What other devices are shown sharing the interrupt lines with ivtv using
> >cat /proc/interrupts?
> CPU0 CPU1
> 0: 580 0 IO-APIC-edge timer
> 1: 3649 0 IO-APIC-edge i8042
> 6: 3 0 IO-APIC-edge floppy
> 7: 0 0 IO-APIC-edge parport0
> 8: 1 0 IO-APIC-edge rtc0
> 9: 0 0 IO-APIC-fasteoi acpi
> 14: 63335 0 IO-APIC-edge ata_piix
> 15: 1294927 0 IO-APIC-edge ata_piix
> 16: 7153671 2827260 IO-APIC-fasteoi uhci_hcd:usb2, uhci_hcd:usb5,
> nvidia
> 17: 12238 7179 IO-APIC-fasteoi ivtv1
> 18: 5690498 0 IO-APIC-fasteoi ata_piix, uhci_hcd:usb4,eth0,
> Ensoniq AudioPCI
> 19: 74042 0 IO-APIC-fasteoi uhci_hcd:usb3, ivtv2
> 22: 1829 0 IO-APIC-fasteoi ivtv0
> 23: 3 0 IO-APIC-fasteoi ehci_hcd:usb1
> NMI: 0 0 Non-maskable interrupts
> LOC: 14667959 15620982 Local timer interrupts
> SPU: 0 0 Spurious interrupts
> PMI: 0 0 Performance monitoring interrupts
> IWI: 0 0 IRQ work interrupts
> RES: 2407721 2344290 Rescheduling interrupts
> CAL: 789 2664 Function call interrupts
> TLB: 13663 20105 TLB shootdowns
> TRM: 0 0 Thermal event interrupts
> THR: 0 0 Threshold APIC interrupts
> MCE: 0 0 Machine check exceptions
> MCP: 540 540 Machine check polls
> ERR: 0
> MIS: 0
This looks pretty imbalanced: CPU0 handles a lot more of the interrupt
service than CPU1. This imbalance of CPU0 handling most of the hardware
interrupts might be a source of problems, *if* CPU0 is actually busy
with higher priority interrupts (ata_piix, nvidia) when the ivtv* card
interrupts come in.
The disk drive (ata_piix) and network card (eth0) interrupts have only
been handled by CPU0.
Is "irqbalance" running on your system?
For a back end system, I have to wonder what the nvidia card is doing
for you, assuming it it the only device generating interrupts on IRQ16.
It has genearted 9.98M interrupts in the same time of 30.3M local timer
interrupts (1 nvidia card interrupt per every 3 timer interrupts).
> Looks like one of the USB ports shares its IRQ with one of the cards, but
> my issue happens with all three cards, so that doesn't seem to be the
> likely cause of the issue.
Right, especially if there are no USB devices connected to the port that
IRQ19 serves.
> >What is the cpu loading shown with top during video capture? Are there
> >high numbers for user or io wait percentages?
> Tasks: 146 total, 1 running, 145 sleeping, 0 stopped, 0 zombie
> Cpu(s): 7.2%us, 4.0%sy, 0.0%ni, 88.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
> Mem: 2059632k total, 1143540k used, 916092k free, 112388k buffers
> Swap: 2095100k total, 0k used, 2095100k free, 688688k cached
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 2799 jpreston 20 0 214m 49m 24m S 2 2.5 36:37.44 knotify4
> 7959 jpreston 20 0 72220 12m 9.8m S 2 0.6 0:04.54 xfce4-terminal
>
> 1263 root 20 0 88408 51m 14m S 1 2.6 1:35.49 Xorg
> 8028 jpreston 20 0 3360 504 440 S 1 0.0 0:00.35 cat
> 8082 jpreston 20 0 2632 1136 848 R 1 0.1 0:00.08 top
> 1345 jpreston 20 0 6464 2516 1788 S 0 0.1 0:06.88 xscreensaver
> 1 root 20 0 3028 1792 1216 S 0 0.1 0:00.90 init
> 2 root 20 0 0 0 0 S 0 0.0 0:00.04 kthreadd
> 3 root 20 0 0 0 0 S 0 0.0 0:01.95 ksoftirqd/0
> 5 root 20 0 0 0 0 S 0 0.0 0:03.60 kworker/u:0
> 6 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/0
> 7 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/1
> 9 root 20 0 0 0 0 S 0 0.0 0:00.71 ksoftirqd/1
> 11 root 0 -20 0 0 0 S 0 0.0 0:00.00 cpuset
> 12 root 0 -20 0 0 0 S 0 0.0 0:00.00 khelper
> 13 root 0 -20 0 0 0 S 0 0.0 0:00.00 netns
> 15 root 20 0 0 0 0 S 0 0.0 0:00.27 sync_supers
> This was captured during a cat /dev/video1 > test.mpg, and the CPU usage
> never went above a few percent for any process. The file was still
> distorted and flawed.
OK. Plenty of memory (894 MB RAM still free), plenty of CPU (88.8%
idle), nothing waiting on I/O (0.0% wa).
'cat' consuming only 1% of CPU may be a little low, since the ivtv
driver and cat collectively do some buffer copies in the read() call
that cat makes into the ivtv driver. (May indicate not many filled
video buffers being provided by the ivtv driver).
Given this, the best guesses I have are:
1. an interrupt handling latency problem.
2. a PCI bus/chipset problem: DMA transfers aborting or IO transactions
to registers and memory on the CX23416 chip are being aborted
3. an ivtv driver bug/race in setting up the CX23416 decoder, that
causes problems in the decoder actually running
4. a cx25840 driver bug in setting up the CX25843 chip to lock on to the
video signal and digitize it properly
5. an analog tuner driver bug that causes tuning to fail
> Where else can I look for this? Do you have any other ideas?
For #4 and #5 above, the output of several runs of 'v4l2-ctl
--log-status' should let you know if the CX25843 has a good video
signal.
For #2 and #3, setting the debug=... option to the ivtv driver
in /etc/modprobe.conf or on the modprobe ivtv command line will turn on
various levels of logging in the ivtv driver (with messages emitted
to /var/log/messages normally).
$ modinfo ivtv
[...]
parm: debug:Debug level (bitmask). Default: 0
1/0x0001: warning
2/0x0002: info
4/0x0004: mailbox
8/0x0008: ioctl
16/0x0010: file
32/0x0020: dma
64/0x0040: irq
128/0x0080: decoder
256/0x0100: yuv
512/0x0200: i2c
1024/0x0400: high volume
[...]
So maybe, as root,
# modprobe -r ivtv
# modprobe ivtv debug=0x4f (or =0x44f)
And then do a 'cat /dev/videoN > foo.mpg' and examine all the debug spew
in /var/log/messages to see what is wrong.
For #1, I'd experiment with how does video capture behave with
a. having irqbalance running (or not running)
b. booting into only run-level 3 (text console, no GUI/X) and unloading
the nvidia driver module
I would also look at IRQ handling latency with ftrace and other kernel
tracing mechanisms:
http://lwn.net/Articles/322666/
http://lwn.net/Articles/322731/
http://lwn.net/Articles/366796/
http://lwn.net/Articles/365835/
http://www.spinics.net/lists/linux-media/msg15762.html
Regards,
Andy
> Thank you much for your assistance so far.
> Jeff
>
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
