Messages in this thread |  | | From | Kenneth Corbin <> | Subject | Re: PROBLEM: Linux consistently crashes running grip. (continued) | Date | Wed, 4 Sep 2002 06:51:53 -0700 |
| |
On Wednesday 04 September 2002 12:02 am, Nuitari wrote: > On Tue, 3 Sep 2002, Kenneth Corbin wrote: > > Long description of same problem. Still continuing after dumping the > > nvidia drivers and upgrading to the latest Redhat kernel. Anything else > > I can do? > > > > I am not subscribed to this list, please cc me with any response. > > Thanks in advance for wading through this. > > > > 1. Linux consistently crashes running grip. > > > > 2. Grip 3.0.1-1 is a graphical X frontend for a variety of CD ripper and > > MP3 encoder programs. When it is only ripping CD's everything is OK. > > But when it is ripping and encoding tracks, the system will die shortly > > after the ripping operation finishes while the encoding operation is > > going on. The time till death is variable, it has ranged from 5 seconds > > to 5 minutes on one occasion, but it always crashes. It happens with two > > different encoders (notlame and oggenc) and two different rippers > > (cdparanoia and cdda2wav) The quickest way to induce a failure is to > > make one pass ripping tracks and a second pass asking it to rip and > > encode. It is smart enough to realize the tracks have already been > > ripped and doesn't do much beyond checking that they are all accounted > > for. But my system still crashes. > > > > Gnu C 2.96 > > Did you try testing your ram for any defects (even if it means trying > various combinations of ram) ? > The only times I had similar problems was when I had faulty ram on my > motherboard or (in 1 case) a really defective onboard ide controller. > > Also be careful with Gcc 2.96, there is a lot of problems related to it.
OK, went looking for hardware diagnostic tools. memtest86 ran all night without reporting any problems. But cpuburn-1.4 burnK7 locked up almost immediately. Interestingly it seems to do OK in single user mode, but if anything else is running things go south very quickly. Usually it is a silent lockup. In one case I got an Ooops:0002. Indications are pointing toward some kind of hardware problem. Looks like I need to take this to someone who has some real diagnostics, or the resources to swap out parts until things start working. I'll let you know how this turns out.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |