Loading...

ivtv-users@ivtvdriver.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [ivtv-users] Help With Troubleshooting Jeffrey Preston Fri Feb 03 08:10:47 2012

Update:

Tried enabling debug messages on ivtv...

Sudo modprobe ivtv debug=0x44f

 But I cannot find where the log file is created.  There is no 
\var\log\messages file or folder.

Tried setting the PCI latency timers to 128 from 64, but it made no difference.

-----Original Message-----
From: Andy Walls [mailto:[EMAIL PROTECTED] 
Sent: Saturday, January 28, 2012 8:25 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [ivtv-users] Help With Troubleshooting

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
> 




-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.1901 / Virus Database: 2109/4772 - Release Date: 01/28/12


_______________________________________________
ivtv-users mailing list
[EMAIL PROTECTED]
http://ivtvdriver.org/mailman/listinfo/ivtv-users