Follow-up to Brad Barnett's message: As a result of Hans' recommendation, I upgraded to 0.10.0rc1 (actually, to a subversion version that included his recent patch for the VBI messages also discussed in this thread). The system got a lot more stable. A few days of up-time in a row.
But after 3-4 days, it crashed again with the same symptoms. (Ping working, but nothing else, and no messages.) I suspect you may be right about the DMA load, so I shut down one of the two-tuner cards a couple of days ago, and today I removed the card completely. And I'm only reading video from one of the 6 tuners now. (The rest are doing VBI only.) We'll see if this makes a difference. Out of curiosity, does the DMA load only happen when an application is actively reading from the card? That is, did I need to physically remove it? Or was it good enough to just stop reading from the card? (from an earlier post of mine) > FYI, Yes, it is VIA. Specifically, an ASUS SK8V motherboard, VIA K8T800 chipset. > We'll see how 0.10.0rc1 works, and if not, I'll try removing one of the cards. Thanks, Rich -- Rich Kadel Appeligo, Inc. (858) 433-1747 www.appeligo.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad Barnett Sent: Sunday, February 11, 2007 5:34 PM To: Discussion list for development of the IVTV driver Subject: Re: [ivtv-devel] System (practically) non-responsive after several hours...no clues Rich, 4 PVR 500s is a heavy DMA load for any system. What motherboard does this system employ? What chipset does the motherboard have? VIA chipsets, for example, are particularly prone to DMA issues. A lockup due to a DMA issue can cause all sorts of issue, including your hard drive going offline.. which can account for the kernel being able to respond to a ping, but do little else. If you want to verify such a problem (and you have the ram for it), a quick test would be to use knoppix loaded into ram (or other ram based distro). This way, if the drives go MIA, you will still be able to ssh in and check things out. There are many other things that can be done, including quite a few debugging options you can turn on in the kernel. You could try a serial console, for example.... and this would allow you to see kernel messages before the lockup. On Sun, 11 Feb 2007 15:58:49 -0800 "Rich Kadel" <[EMAIL PROTECTED]> wrote: > Kernel: 2.6.18.6 > IVTV: 0.8.2 > CPU: AMD Opteron(tm) Processor 146 (Family: 15, Model: 39, Stepping: 1) > > I have a "generic" 4U AMD Opteron server that was running fine for long > periods until I started using the IVTV driver. It's a CentOS 4.3 > system. I was using the default 2.6.9 kernel, but ran into this > problem, so I upgraded to 2.6.18 and installed ITVT 0.8.2. Same > problem: > > After anywhere between 6 hours and 2 days, I can no longer ssh into my > system. Oddly, I CAN ping the system. If I bring up a monitor, the > monitor is showing static, like the video card is messed up. My IVTV > applications normally generate output, so I can see when the last file > was modified (after rebooting, of course), and that is the only good way > I know when it crashed. > > I have had ITVT problems/crashes before, on my Dell 2850, but that > always gave me a kernel panic and dump so I could see a little of what > was going on. With this system and problem, I get nothing in the logs > at the time of the crash. Occasionally, I will see this error, but it > does not always appear between crashes, so it doesn't appear to be the > problem > > Feb 11 03:30:11 server2 kernel: ivtv3: All encoder VBI stream buffers > are full. Dropping data. > Feb 11 03:30:11 server2 kernel: ivtv3: Cause: the application is not > reading fast enough. > > I have 4 PVR-500 cards in this system. All 8 tuners are capturing VBI. > 3 tuners are simultaneously recording low-res video by piping > /dev/video[n] to ffmpeg and translating it to .flv. Up until the time > of the "crash", things appear to be recording smoothly. > > I assume ping works because the system hasn't actually died completely, > and that's probably why I'm not seeing any kernel messages. > > Is there a way to debug this? Perhaps a SLIGHTLY more verbose output? > (I'd hate to create an enormous log file when it might not crash for a > couple of days again, but if there is a reasonable and helpful debug > flag, I'll try it.) > > I've attached the ivtv init log messages. > > Thanks, > Rich > > -- > > Rich Kadel > Appeligo, Inc. > (858) 433-1747 > www.appeligo.com > > _______________________________________________ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel _______________________________________________ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
