From mboxrd@z Thu Jan 1 00:00:00 1970 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Sun, 15 Dec 2019 08:36:30 +0700 Subject: [COFF] SCO UNIX 3.2V4.2 and kernel trap on 'fast' pentium In-Reply-To: References: Message-ID: 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 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 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 >> >