Xref: utzoo comp.unix.xenix:7650 comp.unix.i386:479
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!csd4.csd.uwm.edu!bionet!ames!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!gryphon!turnkey!jackv
From: jackv@turnkey.gryphon.COM (Jack F. Vogel)
Newsgroups: comp.unix.xenix,comp.unix.i386
Subject: Re: ALR CPU's
Message-ID: <6360@turnkey.gryphon.COM>
Date: 17 Sep 89 16:24:36 GMT
References: <29@fleet.UUCP> <2777NU013809@NDSUVM1> <803@qmet.UUCP>
Reply-To: jackv@turnkey.gryphon.COM
Organization: Turnkey Computer Consultants, Westchester, CA
Lines: 20

In article <803@qmet.UUCP> sc@qmet.UUCP (Steve Croft) writes:
>In article <2777NU013809@NDSUVM1>, NU013809@NDSUVM1.BITNET (Greg Wettstein) writes:

 [Greg speculates that the problem is a 16Mhz part goosed to 20 ]

>I bought a 386/2, an early 16-MHz box from ALR.  It had one of the early
>386 chips with the "16-bit only" stamp.  The problem was, I didn't know
>it contained the 16-bit version because ALR covered the CPU with
>motherboard serial number stickers!!!  In fact, it looked like one

While Greg's speculation was a real possibility for why the SCO kernel was
panicing on coming up, yours is not. If the CPU in the ALR was not a double
sigma chip ( the double sigma was a stamp on the chip meaning it did not
have the 32-bit bug ) the installation disk would detect this, inform you
and not install. This assumes, of course, that you were installing 386
Xenix.

I have heard of a number of cases where SCO could not be successfully run
on an ALR system. This, however was some time back and I have no idea on
their current boxes. I would certainly advise "try it before you buy it"!!
--
Jack F. Vogel			jackv@seas.ucla.edu
AIX Technical Support	              - or -
Locus Computing Corp.		jackv@ifs.umich.edu