Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!SUMEX-AIM.STANFORD.EDU!lane
From: lane@SUMEX-AIM.STANFORD.EDU (Christopher Lane)
Newsgroups: comp.sys.xerox
Subject: Re: Error with stack pointer
Message-ID: <621544319.A3688.KSL-1186-13.lane@SUMEX-AIM.Stanford.EDU>
Date: 29 Sep 88 22:26:07 GMT
References: <123:stumpf@cogsys.psychologie.uni-freiburg.dbp.de>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 25


    In most cases you get a break window (often in the biclock
    process, and almost always in some numerical computations)
    stating that you attempted to compute ITIMES or so with
    an argument of NIL (in the case of the biclock process always
    the SIN fails with a bad argument of say {}#360,0 or like that).
    In most cases you can just say OK and the computation goes on.

I don't know if this is related but this sounds like the problem we had in
Koto with the 1186s when we ran with 8K microcode enabled with the (last
official) release of Koto microcode that supported PC emulation.

The microcode, as released, was only meant for running under the 4K control
store size but was in fact 8K in size.  By turning on the 8K capability from
the 'System Configuration Utility' you enabled the remainder of the microcode
which included, unfortunately, buggy floating point microcode that lead to
regular, unreproducible errors of the kind you describe.

The fix was to turn off the 8K microcode capability and go back to 4K control
store--or move forward to Lyric which had full 8K microcode with working
floating point.  This problem can happen by accident if you switch from Lyric
back to Koto (and are using the PC emulation-compatible microcode) and forget
to reduce your control store size.

- Christopher