Ben Rosenberg wrote:
* Rachel Greenham (rachel@linuxgrrls.org) [021012 15:50]: ::> ::I don't know, sure looks like a hardware fault to me. Like duff memory. ::Does 8.1 still have the memtest86 option on the boot CD / DVD? If so ::give it a go, or give it a go on the 8.0 version. It is possible a fault ::has developed *since* or *while* you were installing 8.1. It's always ::possible you zapped a chip when you had the case open, or a power ::surge... So, put 8.0 back on it and see what happens, but try memtest86 ::first.
It could be. But I had a fresh install of 8.0 on this box for about 10 days prior to 8.1 because my root drive died and instead of reinstalling 7.3 and patching it. I just installed 8.0 and figured I'd upgrade. And if the upgrade went bad then I'd do a fresh install. So the machine ran as advertized with 8.0 on it for 10 days without an issue of any kind. Then I went to 8.1 w/ it's new kernel and new GCC compiled pkgs and everything went wanky. I would think it was just me, but with all the other issues I've see on the list. I'm not so sure.
Hang on, was the install of 8.1 an upgrade from 8.0 or a fresh install? (I never trust the upgrades.)
::Maybe you have DMA related problems? Earlier versions of SuSE (in my ::experience anyway) defaulted to having DMA turned off, and had to be set ::up manually (hdparm command in /etc/init.d/boot.local) but suse 8.1 has ::selected what I would consider the "right" settings for my drive by ::itself. Maybe on yours it's done the wrong thing and you need to ::manually set more conservative settings. In the first instance just turn ::DMA off in yast2 and see if the freezing stops (bear with the slower ::disk access for the time being).
This could be it. I'll give it a shot and report what I find.
::Last June I had very similar random crashes start appearing once I ::upgraded to kernel 2.4.4 on disk access through the onboard Promise ::IDE/RAID controller *only* when DMA was enabled. I got to be able to ::reproduce it consistently by doing a big bonnie test (ie: using the disk ::subsystem so heavily that it raised the chances of it happening during ::the test to nearly 100%). In the end I didn't wait for this to be fixed, ::but switched to using the on-board VIA IDE controller instead, though ::the original problem is very likely fixed by now. (the whole sorry tale ::is archived in the lkml) You're probably not experiencing the exact same ::problem, but DMA may still not be set up correctly. Or it might be a ::newly-introduced bug in the 2.4.19 kernel - or the *SuSE* 2.4.19 kernel ::- for your IDE controller.
Well, the weird thing is that I compiled ncftp and about 10 other programs lastnight. Lots of io there and tons of memory used since I did several of the compiles at once. The failure here seems to only occur while in X. I could be some setting that I have in the X related config files in ~/ because those are the same as they have been since 7.3 ..but with the same version of X 4.2.0. :)
Well, OK, next thing to try then is to reconfigure X from scratch and use a new empty home directory. See if it happens, gradually restore stuff from your existing home directory until it breaks. Unlikely I'd have thought that something in your home directory is broken. You *might* have a sickness in your graphics card itself though - memory in the card might be at fault, not in that part that's used for VGA, but when things get more exciting. BTW I'm not much of an expert on PC hardware, just tend to be fairly good at zoning in on faults. So the hwinfo file won't give me many more clues, but someone else out there might see something. I'm still *sure* this is hardware related. As we well know, Linux just doesn't crash like this unless there's a hardware (or hardware configuration) problem.
::BTW, the hw file you said was attached, wasn't :-) Probably suse's mail ::server stripping it.
No, I'm a moron and my wife was having a hissy fit at me when I was sending that email. I simply forgot to attach.
Go pay more attention to your wife you... man, you. :-P -- Rachel