[comp.sys.xerox] Error with stack pointer

lane@SUMEX-AIM.STANFORD.EDU (Christopher Lane) (09/30/88)

    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

stumpf@cogsys.psychologie.uni-freiburg.dbp.de (Michael Stumpf) (09/30/88)

Hi there!
In our mixed configuration we have 1108 as well as 1186s.
On the 1186 (and only on these machines) we often discover
a boring error: Lisp seems to loose a stack pointer sometimes.
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.
If you try to backtrace, you can't see any problem - all arguments
are correct, until you enter the stack frame where the system 
crashed. Trying to evaluate something at this level often causes
big problems ending with doing a hardreset (and everything is gone).
For a couple of weeks I believed that this could be a memory
fault, but we now have two machines showing up with the same
problem. If it is a software problem, I would like to know how to
fix it (patches are welcome).

There is another, more simpler problem with our X8000 print
server (running 10.0). All screen dumps are printed in a way,
that the image is compressed to fit the onto half of the page
(i.e. most of all it is rotated and compressed without any need
to be rotated). Probably this is a parameter in the server
software which can be tuned.

Does TFTP to and from UNIX systems work? (FTP is fine.)
I should say that we are still running KOTO 2.01 (it takes
always a long time for new products to be available in Europe).

What is the pricing of Medley 1.0 and 1.0S in the States?

Best regards,
Michael