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

[rudi.j.blom at gmail.com (Rudi 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
>>
>