[COFF] SCO UNIX 3.2V4.2 and kernel trap on 'fast' pentium

[COFF] SCO UNIX 3.2V4.2 and kernel trap on 'fast' pentium

[rudi.j.blom]

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] SCO UNIX 3.2V4.2 and kernel trap on 'fast' pentium

[crossd]

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 at 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 at minnie.tuhs.org
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20191214/77ae68e6/attachment.html>

[COFF] SCO UNIX 3.2V4.2 and kernel trap on 'fast' pentium

[rudi.j.blom]

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 at 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 at 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 at minnie.tuhs.org
>> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
>>
>

[COFF] SCO UNIX 3.2V4.2 and kernel trap on 'fast' pentium

[rudi.j.blom]

Blame early morning and typing BEFORE having had coffee.

The "HX580" should be "Digital Prioris HX590"

Sorry,
uncle rubl