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

[crossd at gmail.com (Dan Cross)]

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>