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