Lisp stopped itself (still)

[gooch@TIJERAS.SW-SW.Dialnet.Symbolics.COM (William D. Gooch)]

    Test Simple main-memory
    Testing memory board in slot 7. = #o7
    Testing memory board in slot 8. = #o10
    Testing memory board in slot 25 = #o31
    At least 1 location has bit 22. stuck on
    At least 1 location has bit 32. stuck on

    (* and this last statement was repeated for bits 36,37,38,38,40,
       41,42 *)

    2. locations have bit 22 stuck on; addr-ior 63124426, addr-and
      6312046, xor(addr-adn, addr-ior) 4000
    233. locations have bit 32 stuck on; addr-ior 63120777, addr-and
      63120400, xor(addr-and, addr-ior) 377

    (* this last statement was repeated for bits 36,37,38,39,40,41,42,
    (* all with the same numbers ie. 233. locations...addr-ior #,
    (* addr-and #, xor #, including the 377 at the end

Such errors are not problematic unless more than one of them occurs in
the same memory location.  If only one occurs at a given address, it is
corrected by the ECC and you never see it except during these tests.  If
two occur in the same location, you'll get double-bit errors.  If more
than two occur at the same location, results are unpredictable, but
guaranteed not to work in your favor.  I don't think this is the problem.

    ....

    Test disks
    Label for unit 0: 1635 cylinders, 15 heads, 24 pages/track,
     Id = 0, Fast mode = 1, Root at 30(8)
    Pack name: DE-00355
    Testing disk unit 0
    Testing heads
    Testing cylinders
    Error reading cylinder 1635 head 0 sector 0 on unit 0
    Too many retries for unit 0. Last error was: Timed out waiting for
     seek to cylinder 1635
    (there appears to be 1635 cylinders)

As I recall, this is normal.  It's just the funny way the FEP has of
saying "that's all, folks!"

    Testing sectors
    Error while mounting unit 1: Select error on unit 1 during unit
     select
    (* This last line was repeated for units 2,3,4,5,6,7 since there's
    (* only 1 drive I suppose.
    (* It seems that that last cylinder should have been omitted at
    (* format time.?

See above.

    Testing A-memory
      Testing every 177(8) locations: 0 1770 3760 5750 7740
      Testing power of 2 locations

    (* seems to be no problem here even with the bad mem board in.
    (* So from the load microcode report...

"A memory" is on the processor board.

    ....
    Error while opening cart:>3650-fpa-mic.mic: Data error or bad
     block not located

    (* Should I assume this means the tape is bad?

"Bad block not located" is a disk problem.

    (* So I loaded the microcode from the disk, as before, and then
    (* tried to load world from this IFS tape.

    Load world (default is FEP0:>genera-7-1.load)cart:>genera-7-1.load
    Error: Unbelievable (129480788) number of sparse entries

Probably a disk problem also.

    (* I realize this was a shot in the dark...I would probably
    (* have to have the tape in perfect position for this...
    (* So I went ahead and load worlded genera-7-1-5-combo.load,
    (* Enabled IDS, and Started, and I noticed that the first time
    (* the error message came up it was DISK-ERROR-ECC instead of
    (* DISK-ERROR-SEARCH. The numbers were the same as when I did
    (* continue, though it switched back to DISK-ERROR-SEARCH.
    (* BTW, what do the <211><211><211> mean?

Nothing, it's just FEP garbage.

    I assume that the only way out of this disk error is to get an
    IFS tape from Symbolics for this machine. Is this tape able to
    deal with the bad block (does it create a new base load file)?
    Can I get a tape that is compatible with genera 7.1 still?

Although the disk tools mentioned in other mail were not (I think)
shipped with Genera 7, they did exist and you may be able to find a copy
or get one from Symbolics.  If your problem is a bad disk block, you
should be able to splice around it and get the machine up without
rebuilding the disk from scratch.

Good luck.

    Geez, that animation I'm planning for next year's SIGGRAPH is
    slowly fading away...

Don't give up on it yet.