Xref: utzoo comp.unix.wizards:21043 comp.unix.xenix:10598
Path: utzoo!attcan!uunet!mstan!amull
From: amull@Morgan.COM (Andrew P. Mullhaupt)
Newsgroups: comp.unix.wizards,comp.unix.xenix
Subject: Re: System V kernel panic not syncing
Summary: Not quite
Message-ID: <782@s5.Morgan.COM>
Date: 15 Mar 90 06:43:33 GMT
References: <167@mnopltd.UUCP>
Organization: Morgan Stanley & Co. NY, NY
Lines: 48

In article <167@mnopltd.UUCP>, neal@mnopltd.UUCP writes:
> 
> ->Anyone know how to get the SCO UNIX System V/386 r3.2 kernel
> ->to do sync when it panics so fsck is happy when you start up again?
> ->
> 
> Wait a second... This doesn't make sense.  Panics are frequently situations
> where the kernel code is not confident to continue processing.  Doing a 
> sync in this situation is like painting over rust.   For any degree of system 
> stability you need to fsck and "take your medecine"...
> 

Not really. The problem is that a hardware workaround for a bug in the
CPU chip is detecting a potentially incorrect condition (relating
only to floating point exceptions) and translating the error into
a parity error so that it won't go unnoticed. Needless to say, UNIX
notices the fake parity error and panics. Now I know it's a bogus
parity error because the memory on the machine is rated faster than
its running, brand new, and it's completely repeatable. (Until I
put in a software workaround for the hardware workaround, it was
VERY repeatable.)

Now I did say this was 'beta' hardware - (and aside from this one
fault it seems solid as a rock...) - so nothing really important
is at risk. It's just that when that particular panic occurs, I
don't need to go looking too hard to tell if the situation is as I
have outlined above. (So far every one of the panics has been of this
kind...) Since there is quite a bit of mass storage on this machine,
it takes some time to fsck on the reboot. I was just looking for a
simple way to avoid this unnecessary delay. 

I have received quite a few responses admonishing me not to force a
sync on the grounds of file system safety. Well, I just thought I'd
put everybody in the picture so they could understand why I wanted
to force the sync.

The software workaround involves disabling all floating point
exceptions (and ensuring the correct status of the sticky bits) - 
so it can be criticized from the point of view of numerical analysis.

While we're on the subject. It occurs to me that an even more 
elegant solution would be to ignore parity errors which come from 
one specific location. (The fake parity error is always reported
from the same location...) Anyone know how to do this? Note: I do
not have access to kernel source, to my knowledge.

Thanks in Advance,
Andrew Mullhaupt