[me]
> I just got my new system up that uses a dual 450MHz pII on a
> ASUS P2B-DS. So far I've tried 2.1.130 (what I was using UP at the
> time and seemed stable enough), 2.1.131 (stock, -ac7 & -ac11) and now
> pre-2.1.132-2. All tend to croak unhelpfully, at least so far.
[John Allensworth]
> Dunno if it's related, but I posted a problem report earlier. Dual
> PII/300's on the Chaintech 6DBU board (equiv). I've had complete
> system locks like you mention below with UP 2.0.35 and 36, and SMP
> 2.1.131 stock, ac9, and ac13 SMP. My console apps are stable enough,
> but xemacs, netscape, and acroread all hose it. I was told to submit
> it as an X bug, but still haven't gotten any reports back :( I have
> a feeling my problem stems from some obscure incompatability with
> my vid card though...
I haven't gotten a running Xconfig for the new video card in that
system yet (Matrox G200, AGP connector) so I've been running it in just
the regular old console mode. I have been using X *clients* in some
cases (xcpustate, xdaliclock) since it is pretty obvious when the system
freezes with something updating pretty frequently.
[Jens Axboe]
> I don't have any good ideas, but I'm running the same motherboard
> as you and have never had any problems with 2.1.1xx kernels. Maybe
> your problem is hw related? Faulty RAM, remarked CPU's, etc?
How to tell? Most of the RAM problems you hear about tend to get
applications (core dumps from corruption, etc) a good chunk of the
time and I've failed a fair number of times without seeing that happen.
They're native 450MHz CPUs running at the right speed (not overclocked)
with the recommended cooling fans, etc.
Sitting idle, the box seems happy. In trying to syslog the problem, I
mounted all the writable ext2fs filesystems in sync mode. The box seems
to be doing the same tasks just fine, if one hell of a lot slower (what
you would expect for sync vs async).
It feels like a disk-related race to me. Lots of interrupts causing
it to freak, something.
[Eric Lee Green]
> What exactly are you doing right before it crashes? I have a customer
> with a similar problem under 2.1.131 with the same setup (except with
> an ICP-Vortex GDT RAID controller instead of the Adaptec SCSI on the
> P2B-DS), ... 2.1.131 kernel, SMP, the driver in 2.1.131 is
> ICP-Vortex's latest, the stock token ring driver, 1gb of memory,
> 72gb RAID partition.
I am using the native Adaptec controller, have about 27G total. One
9GB wide, one 18G LVD. I'm crunching up my homebrew linux distribution
via my build script, so basically lots of compiling.
Because my build script does the same thing every time and the last
few times I've knocked it back to stage 0, I can tell that it is crashing
in different places compiling different packages. Once, when I didn't
restart it from stage 0, it looked like it was briefly in a tight loop
throwing out a bunch of `sync' commands into the background when it bailed
(so not much actual I/O at all). Since it looks like I'm going to have
to be on the console with the screen unblanked and watching to catch it,
that is going to be the first thing I chase. (:
Again, it smells like a race to me. One compile isn't that different
from another, some will take the box out some won't. After it reboots
and you do the same thing over again, it will crash in a different place.
It will just reboot or seize up -- no CTRL-ALT-DELETE will fix it and
the console won't wake up.
Running a full build on a synced fs is sort of an interesting test, but
I'm obviously not stressing the CPU at all and things certainly aren't
being very speedy. I'm probably not exercising the problem or otherwise
avoiding the race.
Another test would be to pull out a CPU, run it with both UP & SMP
kernels and rebuild again, once per CPU, and see if it fails. That ought
to exercise most of the components. If I grind away that far without
finding anything, I'll probably pull out individual RAM modules (I have
2x128MB) and see if that makes a difference. It isn't misbehaving like
I see most people complain about when they have RAM problems though.
I have tested it for *really* long periods of time playing Half-Life (:
under win98. That will only abuse one CPU, but didn't see anything that
didn't look like a game-related problem (CTRL-ALT-DELETE gets you the
standard "nuke task" menu and you can recover).
--- john
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/