On Thursday 22 February 2007 00:50, Rich Kadel 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?
Just stop reading. Only a PVR350 has still interrupt activity (the VSYNC
interrupt of the TV-out), but all others only are active if they are
actively read from.
If you look at the console (I'm assuming you have a monitor attached)
and press enter on the keyboard, does the console react?
(Note: you may have to turn off console blanking with 'setterm -blank 0'
first, otherwise there is a chance that you never see the last console
messages because the console was blanked).
What is odd is that I wouldn't expect this to happen: a driver bug is
more likely to either keep the box alive or completely lock it, but it
seems to be in some halfway state.
If it is the driver, then I need to have logging with ivtvctl -D91.
Preferably with only one tuner in use. Unfortunately, this will result
in huge logs.
Regards,
Hans
> (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
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>
>
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
