On Sat, 25 Apr 2009 14:38:32 -0600 (MDT) Miod Vallat
<m...@cvs.openbsd.org> wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: m...@cvs.openbsd.org 2009/04/25 14:38:32
>
> Modified files:
> sys/arch/sgi/sgi: machdep.c
>
> Log message:
> Handle unknown processor types as r5k family on O2, and r10k family
> otherwise. This will get a chance for r16k cpus to get configured
> correctly.
Hi Miod,
In this case, it's probably a good idea to retell a rumor told to me by
an SGI employee a number of years ago.
As you know, the O2 supports the R5000, R7000, R10000 and R12000
families of CPU modules. I have two somewhat odd/rare O2's here; one
has a 300MHz R5000 ("RM5200" a.k.a. "RM5271") and the other has a
400MHz R12000.
The original 350Mhz R7000 CPU module for the O2 was very buggy, and I
believe it did not have L3 cache. From what I was told from folks at
SGI, the only reason why the 300MHz RM5200 was created, was to support
an "existing customer" running proprietary binaries. A hint was given
that said customer was actually the US government/military, and they had
trouble with the R7000 and later processors with some of their apps.
I never found out the exact problems caused by the R7000 and later
processors trying to run binaries compiled for the original R5000. As
far as I know, there is no errata about the issues due to the source
(US gov/mil signal processing apps), but the problems were significant
enough to force the creation of the RM5200, even though the road map
for the R5000 series had supposedly ended.
I've got not way to prove if what I was told by the SGI employee is
bullshit or not. It might only be a pointless rumor, but who knows.
Unless we're going to create an IRIX compatibility layer, the issue of
supporting existing IRIX binaries, and the unstated troubles caused by
them, probably won't bother us.
The decision to treat unknown processors on the O2 as R5000 is most
likely sound, but then again, it *might* come back to bite us.
--
J.C. Roberts
