[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MCL incompatible with Radius accelerator: solutions?
- To: CXEA@MCGILLA.BITNET (CXEA000)
- Subject: Re: MCL incompatible with Radius accelerator: solutions?
- From: Gary Byers <gb>
- Date: Tue, 15 Oct 91 18:21:54 EDT
- Cc: firstname.lastname@example.org
- In-reply-to: <15OCT91.18417817.0063.MUSIC@MUSICA.MCGILL.CA>; from "CXEA000" at Oct 15, 91 5:03 pm
> I'm starting to get annoyed by the fact that MCL is incompatible with
> a Radious accelerator that we have on one of the SEs in our lab, a
> machine onto which I am sometimes bumped. Is there any known way to make
> MCL work with the accelerator? I'm using MCL 1.3.2.
> Thanks for any help.
When it dies, does it die with a "System Error #11 (miscellaneous hardware
My recollection is that there was a problem that manifested itself
on Radius accelerators that weren't equipped with floating-point coprocessors:
for reasons that aren't entirely clear to me, attempts to execute floating-
point instructions yielded "coprocessor protocol violation" exceptions
instead of the "F-line" exceptions that similar platforms would generate.
(The 1.3.2 kernel tried to detect the presence of an FPU by executing an
"FNOP" instruction and catching any resulting "F-line" exception; coprocessor
protocol violations went undetected.)
My even vaguer recollection is that this had something to do with the way
in which Radius boards were normally configured: a jumper was set to indicate
that an FPU was installed regardless of whether or not this was the case, in
order to simplify a subsequent FPU upgrade. (I heard this second- or third-
hand a few years ago; although the explanation makes sense to me and seems
to explain the behavior users have reported, I'm not absolutely sure that
If I'm correct in recalling that a jumper setting was to blame, that would
certainly suggest a solution. I tried at one point to get a definitive
answer from someone at Radius, but wound up just getting annoyed ...