It maybe that the problem was specific for COMPAQ servers of type
Proliant/1600, Proliant/3000 and the HX580. In tat case it was maybe
more 'compaq special' specific rather than a UNIX 'feature' :-)
On 14/12/2019, Dan Cross <crossd(a)gmail.com> wrote:
I don't recall anything like that during that
timeframe, but I wasn't using
SCO. From the descriptions, they sound pretty system-specific. The second,
in particular, sounds a lot like the entire lock was optimized away....
That's necessarily pretty particular to a kernel/compiler pair.
On Sat, Dec 14, 2019, 11:04 AM Rudi Blom <rudi.j.blom(a)gmail.com> wrote:
Around 1997 I and others had a problem with SCO
UNIX 3.2V.4.2 on
'faster' Pentium CPUs. Faster defined as probably 200MHz or more.
There were at least two patches as far as I remember and maybe SLS
I didn't look at that time but now I'm wondering if other Unixes had
similar problems. Either commercial versions or free ones.
Anyone here who encountered such problems on other Unixes?
One patch had
"This is due to executing an invalid instruction in kernel mode (trap
6 is for an invalid instruction; a user process which does this will
simply die with a core dump). If your particular problem is a double
panic and it doesn't leave a system memory dump in whatever device
you've chosen for dumps (usually /dev/swap), apply the following
This is due to a problem in the kernel's querytlb() routine, which may
allow the Pentium to execute a 386-specific instruction which is not
supported on the Pentium. The cure involves patching a kernel module
using _fst. (see part 1 on where to find /etc/_fst). Go into the
/etc/conf/pack.d/kernel directory. We're going to work on locore.o, so
make a backup and then run _fst -w locore.o - The conversation between
you and _fst goes like this (the * is a prompt from _fst; don't type
it or any of _fst's responses):"
A second one was
"> Follow the additional instructions below ONLY if you now get
a k_trap type 0 panic after following
the instructions in
IT os/2366. To correct a k_trap 0, do the following:
# cd /etc/conf/pack.d/pit
# cp Driver.o Driver.orig
# _fst -w Driver.o
* spinwait+2D?w F989 FEE2
# cd /etc/conf/cf.d
# ./link_unix -y
Reboot your system. The above patch corrects a problem with
a software delay loop that was optimized out by the compiler
and which can cause panics on faster processors."
COFF mailing list