I have seen the same problem and backed out of the NVIDIA proprietary driver that I think may have been causing it. I am on 11.10 and the NVIDIA driver has been a disaster for me with it. The big down side is the lack of VDPUW.
I am thinking of moving to Debian instead to see if it gets me past the issues with Ubuntu. Sent from my iPhone On 2012-02-16, at 5:58 PM, "Jeffrey Preston" <[email protected]> wrote: > OK, > > I have experimented by loading Ubuntu 11.04, and then used Synaptic to load > MythTV. I found that I had a stable system with my three PVR-150's and > perfect video coming from all three tuners. However, about once every dozen > or so channel changes, I get the error "Video frame buffering failed too > many times.", and it exits out to the main menu. Going right back into > LiveTV again results in perfect video, at the channel that was changed to > prior to the error, EVERY time. It was my impression, that Mythbuntu was > basically Ubuntu 11.04 and MythTV combined, but when I load Mythbuntu, it > results in an system that gives me jumping, distorted video, with errors > "Video frame buffering failed too many times" or "Error opening jump program > file", almost every time I change channels. > > Does have any suggestions on where to look next? I am thinking now, that > IVTV is probably not at fault, but I cannot rule it out. > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Jeffrey Preston > Sent: Monday, February 13, 2012 12:08 PM > To: 'Andy Walls' > Cc: [email protected] > Subject: Re: [ivtv-users] Help With Troubleshooting > > Andy, > > Thank you for all the help. I will use whatever resources I can in order to > isolate and resolve this issue. To further the research a little, I decided > to try the Mythdora distro, and found some very interesting results. > Loading up and trying version 12.23 got me a 100% working system right away, > without any modifications. I then performed updates, and it all went to > hell. Didn't get the jumping distorted pictures, but it would lock up at a > blank screen anytime I tried live TV. I am going to go back and check the > version of the backend / frontends, where it was working and not, but then > this could be an entirely new issue, and not even related to the issue I am > hunting down. > > I will post the information here when I get a chance. Maybe it will help... > > -----Original Message----- > From: Andy Walls [mailto:[email protected]] > Sent: Saturday, February 11, 2012 11:02 AM > To: Jeffrey Preston > Cc: [email protected] > Subject: RE: [ivtv-users] Help With Troubleshooting > > On Thu, 2012-02-09 at 11:22 -0600, Jeffrey Preston wrote: >> Andy, >> >> I have tried the following things: >> >> 1 - I disabled Hyperthreading on my P4 3.2Ghz CPU, and for several >> minutes, this seemed to resolve the issue, but then it started >> happening again, and the picture went distorted, with lots of >> skipping, and jumping. MythTV would sometimes exit with "Error >> opening jump program file", or "Video frame buffering failed too many >> times". >> >> 2 - I changed grub and rebooted the machine without the GUI loaded. >> So this accomplished two things....no nVidia driver loaded and no >> Window managers running, so a fairly clean system as far as processes >> running. I started mythbackend, but then it exited at the end (maybe >> it is supposed to do that). I then started a remote frontend and the >> first station it tuned to gave me the same trouble. Re-started the >> system with graphics again. >> >> 3 - I ran the command 'v4l2-ctl --log-status' several times, but could >> see nothing in the output that would give me any idea of the signal >> quality or strength. Maybe I am not looking at the output correctly. > > You just want to see that a signal is present consistently. I suspect it > was. > > >> 4 - I issued the command "modprobe ivtv debug=0x4f", but could not >> find any logs in the folder you specified. I did look at the output >> from "dmesg" and found what I believe to be the results of the debug >> output from the ivtv module. However, there is only so much space, it >> seems, in the output from dmesg, and I could not find anything that >> was there that would give me a clue as to what is going on. Is there >> a way to get the debug mode for the ivtv module to redirect its output >> to a log file, so I can comb through it without worrying about the >> buffer space in dmesg? > > That's a syslog daemon configuration. The ivtv driver uses KERN_INFO and > KERN_DEBUG (and KERN_ERROR and KERN_WARN) logging facilities. > > As root, in /etc/rsyslod.conf or /etc/syslogd.conf you would want to direct > "kern.*" logging to /var/log/kernelmsgs or whatever. Then send syslod or > rsyslogd a SIGHUP to re-read the configuration: > > # kill -HUP (process ID of system log daemon) > > >> 5 - I looked to see if I could load IRQbalance as you suggested, and >> found that it was already running under Mythbuntu 11.04. I then >> unloaded it, rebooted and tried again - no difference. > > OK. > >> I tried ftrace, but I believe it is beyond my abilities to configure >> and run at the moment. I do not know how to mount the debug file >> system or enable the option on the Ubuntu kernel. > > I agree, it is complex. I really don't expect normal users to be able to > use it as an effective troubleshooting tool. > >> I have seen the MythTV bug reports, but they do not seem to apply >> exactly to my situation, however, I cannot help but think that they >> are at least linked to what is going on with my system. I do not >> believe it is a latency issue, as adjusting the latency of the cards >> and other things on my system made no difference in the behavior of >> the analog tuner (PVR-150's) at all. > > The PCI latency timer is just so that no one card can hog and hang the PCI > bus (remember the days of ISA cards?). > > The PCI bus has a Round-Robin arbiter for bus access, and the latency timer > is the maximu amount of time that device can master the bus before having to > yield the bus back to the next bus grantee by the arbiter. > > You can only set PCI latency timer values in multiples of 8 BTW. The PCI > clock runs at 33 MHz which makes 8 cycles to be approximately 250 > nanoseconds (242 ns actually). > > The ivtv driver tries to set the card's latency timer to allow its internal > DMA engine to have the PCI bus for 64 cycles (~2 microseconds) before the > card has to yield the PCI bus to another waiting PCI device. > > You might want to check the latency timers of any PCI bridges upstream of > the PVR-150. If their latency timer is shorter than the PVR-150s, then the > latency timer of the PVR-150 doesn't really matter. > >> I also do not think it has anything to do with changing channels, as >> I have had distorted video come up when first bring up my >> frontend...any frontend. > >> I know I should not let this get to me, but I had a working system >> under Mythbuntu 8.10, and it doesn't work under 11.04. I found that >> the issue actually began, or has something to do with the changes >> between Mythbuntu 8.10 and 9.10. I don't know where the changes are >> located that would affect analog tuners, but I will guarantee you the >> source of the issue is there. > > To find the root cause blindly but deterministically, with no guess-work, > one would have to > > - be able to reproduce your problem with a known bad kernel > - have a known working kernel version > - do a git bisect on the kernel source between those two versions, > - rebuild the kernel and install it and test it > - iterate the bisection process until the bad kernel change is isolated > > Each iteration takes ~30 minutes for me. Unfortunately that's time I really > don't have available. :( > > >> The problem still existed in Mythbuntu 10.10, as well. >> >> Perhaps someone that is familiar with the design architectures of >> Linux and Mythbuntu could point us all in the right direction. >> >> Andy, I want to thank you for your help so far. I would not have >> gotten this far without your help. Thanks for taking pity on an aging >> engineer. > > You're welcome. Sorry I don't have a lot of time available lately. > > Aging engineers have to watch out for each other. ;) > > Regards, > Andy > > >> -----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 >> > > > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.1913 / Virus Database: 2112/4804 - Release Date: 02/11/12 > > > _______________________________________________ > ivtv-users mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-users > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.1913 / Virus Database: 2112/4807 - Release Date: 02/13/12 > > > _______________________________________________ > 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
