14 Dec
2019
14 Dec
'19
5:33 a.m.
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
uod464a.
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
patch.
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):"
https://scofaq.aplawrence.com/FAQ_scotec3ktrap6.html
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
* $q
# 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."
Cheers,
uncle rubl
14 Dec
14 Dec
2:43 p.m.
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
uod464a.
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
patch.
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):"
https://scofaq.aplawrence.com/FAQ_scotec3ktrap6.html
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
* $q
# 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."
Cheers,
uncle rubl
_______________________________________________
COFF mailing list
COFF(a)minnie.tuhs.org
https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
15 Dec
15 Dec
1:36 a.m.
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
uod464a.
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
patch.
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):"
https://scofaq.aplawrence.com/FAQ_scotec3ktrap6.html
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
* $q
# 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."
Cheers,
uncle rubl
_______________________________________________
COFF mailing list
COFF(a)minnie.tuhs.org
https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
1595
days inactive
1596
days old
2 comments
2 participants
participants (2)
-
Dan Cross -
Rudi Blom