* 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. The machine is on a 1000watt UPS (only machine connected)..and since I didn't open the case for the 10 days that it was running 8.0 I doubt it. ::You say you switched acpi off, or I'd have suspected that. Yes, as did I. :/ ::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. :) ::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. It's attached now. Cheers! -- Ben Rosenberg ---===---===---===--- mailto:ben@whack.org Tell me what you believe.. I tell you what you should see.