On Wed, 21 Feb 2007 19:28:53 -0800 "Rich Kadel" <[EMAIL PROTECTED]> wrote:
> I may have to do that, but I'll have to swap out the CPU as well (and > maybe memory). Could be pricey, but I need the stability. If that's > what it takes. > > Any recommendations on an Intel motherboard, chipset, CPU combination > that supports 4 PCI slots? PVR-500 requires 3.3 volt support, as I > recall. > You couldn't swap that box with your desktop, for example, for a few days? Anything to debug... > -- > > Rich Kadel > Appeligo, Inc. > (858) 433-1747 > www.appeligo.com > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Brad Barnett > Sent: Wednesday, February 21, 2007 4:13 PM > To: Discussion list for development of the IVTV driver > Subject: Re: [ivtv-devel] System (practically) non-responsive after > several hours...no clues > > > > DMA issues should only occur when the card is actually in use. However, > I want to warn you, I had DMA issues with merely one PVR-500 and a > PVR-350! > > I had these problems with three different VIA chipsets, and they utterly > vanished when I moved to an Intel chipset. VIA forums are rife with > complaints about said chips. > > With a box that has 4 tuner cards in it, trying a different motherboard > shouldn't be an issue. A swap out should take 10-15 minutes.... > > On Wed, 21 Feb 2007 15:50:45 -0800 > "Rich Kadel" <[EMAIL PROTECTED]> wrote: > > > 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 > > _______________________________________________ > 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 _______________________________________________ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
