12-Oct-82 18:12:03-EDT,176;000000000001
From: DEVON@MIT-MC
Date: 10/10/82 16:17:55

DEVON@MIT-MC 10/10/82 16:17:55
To: (BUG HARDWARE) at MIT-MC
cadr-24 seems to be crashing a lot, possibly disk getting lost.

12-Oct-82 20:01:31-EDT,442;000000000001
Date: Tuesday, 12 October 1982  19:53-EDT
From: RLL at SCRC-TENEX
To:   Ed Barton <EB at MIT-OZ>
Cc:   bug-apiary-machines at MIT-OZ, BUG-HARDWARE at MIT-OZ
In-reply-to: The message of 10 Oct 1982 02:31-EDT from Ed Barton <EB at MIT-OZ>


Apiary-2 was fixed today and should not get any more C-MEMEORY Parity
errors.  The circuit breaker on Apiary-1 will be replaced in the morning
and it shouldn't trip the power anymore.

-Rick
12-Oct-82 20:36:35-EDT,581;000000000001
Date: Monday, 11 October 1982, 17:40-EDT
From: Daniel L. Weinreb <dlw at SCRC-TENEX>
Subject: found dead
To: Hewitt at MIT-OZ, BUG-HARDWARE at MIT-MC, bug-apiary-machines at MIT-OZ
In-reply-to: The message of 8 Oct 82 20:54-EDT from Carl Hewitt <Hewitt at MIT-OZ>

By the way, the fact that it was "FILE serving BASSET" is just because I
was looking at your directory structure to try to find your problem with
inability to create directories.  This has no direct relationship to the
crash, which was a hardware problem, so don't be alarmed if you see that
message.


12-Oct-82 21:12:11-EDT,564;000000000001
Date: Monday, 11 October 1982, 21:09-EDT
From: Carl Hewitt <Hewitt at MIT-OZ>
Subject: circuit breaker on AP1
To: BUG-HARDWARE at MIT-MC, bug-apiary-machines at MIT-OZ
Cc: Hewitt at MIT-XX
Fcc: OZ:PS:<HEWITT>HEWITT.BABYL

In HARDWARE in System 210.126, ZMail 45.14, LMFS 27.26, Tape 10.9,
Canon 14.2, microcode 896, site configuration 19, A210.126 FS27.26, on Apiary:

When I came in at 9:00 this evening I found that the circuit
breaker on the processor had tripped bringing the machine down.
I reset the circuit breaker to bring the machine up.


13-Oct-82 00:15:54-EDT,224;000000000001
From: DEVON@MIT-MC
Date: 10/12/82 06:31:17

DEVON@MIT-MC 10/12/82 06:31:17
To: (BUG HARDWARE) at MIT-MC
the vt-52 next to MC's console is messed up.  it displays the second line twice, and the first line not at all.

14-Oct-82 18:18:30-EDT,321;000000000001
Mail-From: PGA created at 14-Oct-82 18:14:02
Date: 14 Oct 1982 1814-EDT
From: PGA at MIT-OZ
Subject: Cadr 9
To: bug-hardware at MIT-OZ

Cadr 9 does not cold boot.  I haven't tried to power cycle it or
anything like that, but if anyone has a chance to look at it,
gratitude will be forthcoming.

Phill
-------
15-Oct-82 16:11:58-EDT,902;000000000001
Date: 15 October 1982 11:14-EDT
From: Patrick G. Sobalvarro <PGS at MIT-AI>
To: BUG-HARDWARE at MIT-AI, INFO-LISPM at MIT-AI

Attempts, possibly ill-fated, are being made to restore the Lab's Lisp
Machines to their former pristine state, after the late summer madness.  You
can help by sending mail to BUG-HARDWARE telling if you have broken
keyboards, mice, memory boards, or other Lisp Machine components sitting
around in your office, machine room, automobile, or what have you.  Better
yet, you could bring them to 936.

If your machine or machines have less than 256K of memory, send mail to
BUG-HARDWARE.  It is no longer necessary or even desirable to cannibalize or
gut other machines to make yours work; and it is no longer a good idea to
steal, hoard, or lock up Lisp Machine components.  So if you got 'em, give
'em back, or we'll snip some wires on your backplanes, O.K.?

16-Oct-82 16:53:12-EDT,593;000000000001
Mail-From: PGS created at 16-Oct-82 16:50:40
Date: Saturday, 16 October 1982  16:50-EDT
Sender: PGS at MIT-OZ
From: PGS at MIT-MC
To:   bug-minits at MIT-OZ, bug-hardware at MIT-OZ

The ninth floor tip (which services a lot of terminals on the third floor for
no reason I can figure out) is hardwarily broken.  This means that the entire
robotics group is without terminals (except for me; I ran a line to the third
floor tip).  If I could find its transceiver (things are so well albelled
around here) without pulling up half the floor I'd see if it was doing
anything. 
-------
17-Oct-82 23:52:46-EDT,1059;000000000001
Mail-From: PGA created at 17-Oct-82 23:47:15
Date: Sunday, 17 October 1982  23:47-EDT
Sender: PGA at MIT-OZ
From: PGA at MIT-MC
To:   PGS at MIT-OZ
Cc:   bug-hardware at MIT-OZ, bug-minits at MIT-OZ
In-reply-to: The message of 16 Oct 1982  16:50-EDT from PGS

    Date: Saturday, 16 October 1982  16:50-EDT
    From: PGS
    To:   bug-minits, bug-hardware

    The ninth floor tip (which services a lot of terminals on the third floor for
    no reason I can figure out) is hardwarily broken.  This means that the entire
    robotics group is without terminals (except for me; I ran a line to the third
    floor tip).  If I could find its transceiver (things are so well albelled
    around here) without pulling up half the floor I'd see if it was doing
    anything. 
I think I have fixed the problem.  Tell me if I am wrong.  I find that either
there was a bad memory card, or the concentrator was overheating.  I have removed
the front panel covers from all the concentrators.  I think they are much happier
thus.

Phill
-------
18-Oct-82 05:38:28-EDT,1314;000000000001
Date: 18 October 1982 05:26-EDT
From: Pandora B. Berman <CENT at MIT-ML>
Subject: ai tu-20
To: TC at MIT-ML, TY at MIT-ML, ERIC at MIT-ML
cc: BUG-HARDWARE at MIT-ML

AI's tape drive is broken. no, not either of OZ's; AI's.  we suspect
that the heads are misaligned; marty worked on this this weekend with
some help from a DEC repairman who was here for some other reason
(work on OZ or something).  that seems to have made it better, but it
still doesn't work.  symptoms:
	before marty worked on it, any attempt to read
files from tape generated continuous
BAD HEADER    +34  iyd`768
BAD HEADER    +34  iyd`768
...
where the garbage given as the bad header was the same during
each attempt to read from a tape, but different with different
attempts (i.e. if i rewound the tape and tried again it said
BAD HEADER s*  df87r eu
BAD HEADER s*  df87r eu
...) the garbage usually contained some spaces and often included
a legible dir name.
	after marty worked on it, it gave BAD HEADER errors
again, but this time the headers were sometimes different, e.g.
two of one kind followed by two of another. 

marty says one bit was rather far off when they were trying to
readjust the skew (realign the heads); maybe it did not get
corrected enough. please call dec in and get them to fix it.

18-Oct-82 13:37:28-EDT,633;000000000001
Date: Monday, 18 October 1982, 12:01-EDT
From: Carl Hewitt <Hewitt at MIT-OZ>
Subject: working around parity errors
To: BUG-HARDWARE at MIT-MC
Cc: Hewitt at MIT-XX

In HARDWARE in System 210.126, ZMail 45.14, LMFS 27.26, Tape 10.9,
Canon 14.2, microcode 896, site configuration 101, on Lisp Machine Apiary-2:

Is there any way to map a physical frame of memory out of the
address space for given physical memory location N?  Is there
any way to recover from a parity error using the debugging
cable?  Apiary-2 has been taking main memry parity errors
on physical address 706125 for several days.

Thanks,

Carl


18-Oct-82 15:13:41-EDT,899;000000000000
Date: Monday, 18 October 1982, 15:06-EDT
From: Jan Krueger <JLMK at MIT-MC>
Subject: cadr16
To: bug-hardware at oz
Cc: jlmk at mc, soley at mc

Dear Bug-Hardware,
	Century Data finally came to fix our disk (!!!).  It now spins.
The cadr, however, still does not work.  That is, Disk Drive Death is no
longer a symptom of our dead cadr and therefore there must be another
reason for its continuing death.  Debugging reveals a disk error,
"Nonexistent Memory".  Will you please look at it again???????????
Please?!!!!!!!!  Please?!!!!!!!!  Please?!!!!!!!!  Please?!!!!!!!!
Please?!!!!!!!!  Please?!!!!!!!!  Please?!!!!!!!!  Please?!!!!!!!!
Please?!!!!!!!!  Please?!!!!!!!!  Please?!!!!!!!!  Please?!!!!!!!!
Please?!!!!!!!! (Sorry, I got carried away.)
(plllleeeeeeeassssssseeeeee????)
	Thank you for your cooperation in this matter.


					Regards,
					Jan L. M. Krueger
					
18-Oct-82 23:23:05-EDT,1247;000000000001
Date: 18 October 1982 20:51-EDT
From: David A. Moon <MOON at MIT-MC>
Subject: working around parity errors
To: Hewitt at MIT-OZ
cc: BUG-HARDWARE at MIT-MC, service at SCRC-TENEX

    Date: Monday, 18 October 1982, 12:01-EDT
    From: Carl Hewitt <Hewitt at MIT-OZ>
    Subject: working around parity errors
    To: BUG-HARDWARE at MIT-MC
    Cc: Hewitt at MIT-XX

    In HARDWARE in System 210.126, ZMail 45.14, LMFS 27.26, Tape 10.9,
    Canon 14.2, microcode 896, site configuration 101, on Lisp Machine Apiary-2:

    Is there any way to map a physical frame of memory out of the
    address space for given physical memory location N?  Is there
    any way to recover from a parity error using the debugging
    cable?  Apiary-2 has been taking main memry parity errors
    on physical address 706125 for several days.

Pull out the memory board (with the power off!) and return it to Symbolics
as broken.  Take your highest-numbered memory board (normally farthest
right) and change its switches to be the same as the one you remove, so you
only lose one memory board instead of all boards with address >= the one
removed.

Or send your mail to the people who maintain your machine, instead
of BUG-HARDWARE @ MC.
18-Oct-82 23:55:20-EDT,451;000000000001
Date: Monday, 18 October 1982  23:51-EDT
From: HEWITT at MIT-XX
To:   David A. Moon <MOON at MIT-MC>
Cc:   Hewitt at MIT-XX, service at SCRC-TENEX, bug-hardware at mc
Reply-to:  Hewitt at MIT-XX
Subject: working around parity errors
In-reply-to: The message of 18 Oct 1982  20:51-EDT from David A. Moon <MOON at MIT-MC>

Dave,

Thanks for your reply.  Is

 service at SCRC at MC

the correct address to use?

Cheers,

Carl
-------
19-Oct-82 01:31:08-EDT,1247;000000000001
Date: Tuesday, 19 October 1982, 01:14-EDT
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: Your non-ZMAIL bug
To: Phillip G. Apley <pga at MIT-OZ>
Cc: BUG-ZMAIL at MIT-OZ, bug-hardware at MIT-OZ
In-reply-to: The message of 17 Oct 82 20:44-EDT from Phillip G. Apley <pga at MIT-OZ>

    Date: Sunday, 17 October 1982, 20:44-EDT
    From: Phillip G. Apley <pga at MIT-OZ>
    In ZMAIL in Remote-File 14.0, LMFILE-Remote 18.1, MIT-Specific 10.0,
    System 87.46, ZMail 46.9, microcode 171, Use me, on Unknown:

    I typed "S", the run bar went on, and the word "run" appeared in the modeline.
    No file activity appeared to occur, and the machine stayed in this state for 15 min.
    I warm booted it and when I returned to the mailer and typed "Help" the machine
    immediately froze in the same state again.  This machine is LM30, which
    may still be in the debugging stage.  Is it?  I have no interest in trying
    this problem again, right now, to see if it is repeatable.

    Phill
This sounds like a hardware bug, not a ZMAIL bug.
Normally the run bar does not completely stay on, with
no paging or flickering, unless something is wrong, such
as looping in the scheduler or microcode, or a hardware failure.
19-Oct-82 14:25:24-EDT,534;000000000001
Mail-From: PGS created at 19-Oct-82 14:24:56
Date: Tuesday, 19 October 1982  14:24-EDT
Sender: PGS at MIT-OZ
From: PGS at MIT-MC
To:   Robert W. Kerns <RWK at SCRC-TENEX>
Cc:   bug-hardware at MIT-OZ, BUG-ZMAIL at MIT-OZ,
      Phillip G. Apley <pga at MIT-OZ>
Subject: Your non-ZMAIL bug
In-reply-to: The message of 19 Oct 1982 01:14-EDT from Robert W. Kerns <RWK at SCRC-TENEX>

CADR30 has a bum T-80 on it, we think.  It is still being debugged.  When
it's been finished, it will move down to the third floor.
-------
19-Oct-82 22:28:04-EDT,279;000000000001
Date: Tuesday, 19 October 1982, 22:24-EDT
From: Allan C. Wechsler <ACW at SCRC-VIXEN>
Subject: Arthur Dent
To: Bug-hardware at mit-eecs

The RESUME key on Arthur Dent's keyboard doesn't send anything.

Priority: high.  The RESUME key is pretty important.

   --- Allan
20-Oct-82 12:20:03-EDT,218;000000000000
Date: Wednesday, 20 October 1982, 12:17-EDT
From: Richard M. Stallman <RMS at MIT-OZ>
To: bug-hardware at MIT-OZ

Cadr1 got disk error: timeout, cyl 24, head 6, sec 13.
last memory address touched by disk = 326.
21-Oct-82 06:37:05-EDT,1460;000000000000
Date: Thursday, 21 October 1982, 06:31-EDT
From: David A. Levitt <LEVITT at MIT-OZ>
Subject: hardware problem fixed; wetware fix on agenda
To: bug-hardware at MIT-OZ
Cc: rms at MIT-OZ, kwh at MIT-OZ, hanson at MIT-OZ, 7ai at MIT-OZ

Someone left CADR-9 in an unbootable state yesterday.  It was a simple
"current band unbootable" problem, which I have fixed, but the condition
I found it in was the result from at least three independent human
policy errors:

1) An band (89.11) was moved to the machine but never tested.  A single
test would have shown that, even though 89.11 works in general, this band
was unbootable.  MORAL: If you don't have time to test it, you don't have
time to move it.

2) No message was sent to BUG-HARDWARE@OZ when the machine crashed.  No
note was left on the machine.  MORAL: If you break something or find it
broken, report it.  People will get even madder if you don't.

3) A LOD on the CADR-9 disk pack, which I labelled "bad band!" long ago,
was recently relabeled "Empty".  Naturally, eventually someone moved a
band to it, and it wouldn't boot.  MORAL: In this life, all disks have
bad sectors.  Some are finessed in formatting; others are discovered the
hard way and labeled for the next generation.  Watch carefully for those
headstones!

I think most of us know all this, but I've CC'ed this to 7AI because with
the current hardware staff shortage, we can't afford to start getting sloppy.
21-Oct-82 06:42:07-EDT,556;000000000000
Date: Thursday, 21 October 1982, 06:36-EDT
From: David A. Levitt <LEVITT at MIT-OZ>
Subject: General problem with poorly mounted CADR debug connectors
To: bug-hardware at MIT-OZ

I recently noticed that both CADR-9 and CADR-27 have loosely mounted
connectors for their debug cables, probably a common problem due to the
way the connectors are held on.  This makes it hard to connect the cable
properly, and may be responsible for the high debug-cable death-rate.  A
lab-wide screw tightening session for these might decrease that fatality
rate.
22-Oct-82 03:55:00-EDT,1247;000000000000
Mail-From: LEVITT created at 22-Oct-82 03:54:04
Date: Friday, 22 October 1982  03:54-EDT
Sender: LEVITT at MIT-OZ
From: LEVITT at MIT-MC
To:   HANSON at MIT-OZ
Cc:   7ai at MIT-OZ, bug-hardware at MIT-OZ
Subject: Problems on CADR9
In-reply-to: The message of 21 Oct 1982  19:55-EDT from HANSON

DPH was wrong about that partition.  From way back, it wouldn't boot
copies of working systems, even with compatible microcode.  I
discovered that a year ago or so; when I reported it I there was a
shortage of disk packs, so I labeled the partition.  (Perhaps it's
me who's at fault, for not reporting it widely enough.)

When I started debugging the machine this time, I tried repeatedly to
boot to that band (89.11) with the correct microcode (183) and it
failed every time.  In the process of relabeling it BAD BAND!!, I
DISK-SAVEd a different system, and it didn't hang during booting.  But
that shouldn't be surprising!  Different systems use parts of the
disks differently; the flaky sector would just screw someone later.

There are more disks now, so this one should be reformatted or replaced.
But in general, t300s are big enough that if there is any question of
a hard or soft error, label it and avoid it.
-------
22-Oct-82 04:54:36-EDT,434;000000000000
Date: 22 October 1982 04:53-EDT
From: Pandora B. Berman <CENT at MIT-ML>
Subject: ai tape drive?
To: TY at MIT-ML
cc: BUG-HARDWARE at MIT-ML, eric at MIT-EECS

ty, you said you would call the right people (i didn't quite catch
who they were) to work on ai's tape drive. did you? if so, did they?
or when are they going to? if not, please do so as soon as possible;
i can't do backups on ai if the tapes won't be readable.

22-Oct-82 13:59:12-EDT,235;000000000000
Date: Friday, 22 October 1982, 09:30-EDT
From:  <RMS at MIT-OZ>
To: bug-hardware at MIT-OZ

CADR 18 got a fatal disk error: NXM transfer-aborted
cyl 36, head 14, sector 0
last mem addr touched by disk = 1113000
status 64020011
24-Oct-82 08:32:07-EDT,189;000000000000
Date: 24 Oct 1982 0048-EDT
From: LS.PAE at MIT-EECS
Subject: buggy terminal
To: bug-hardware at MIT-EECS

vt100 #51 started power cycling itself repeatedly. I turned it off.
-------
25-Oct-82 09:57:06-EDT,292;000000000000
Date: 25 October 1982 01:19-EDT
From: Pandora B. Berman <CENT at MIT-ML>
Subject: oz:tinman:?
To: BUG-OZ at MIT-ML, BUG-HARDWARE at MIT-ML

in running a dump tonight i tried to dump tinman:. dumper replied
%no such device - tinman<*>*.*.*
%no files dumped
someone please fix this.

25-Oct-82 19:54:10-EDT,228;000000000000
Mail-From: CAL created at 25-Oct-82 18:01:18
Date: 25 Oct 1982 1801-EDT
From: Clifford A. Lasser <CAL at MIT-OZ>
To: bug-hardware at MIT-OZ

CADR 6's left control key does not always work, usually but not always.
-------
26-Oct-82 20:18:25-EDT,435;000000000000
Mail-From: PGA created at 26-Oct-82 20:12:12
Date: 26 Oct 1982 2012-EDT
From: PGA at MIT-OZ
Subject: Chaosnet transceivers
To: bug-hardware at MIT-OZ, bug-oz at MIT-OZ, pgs at MIT-OZ, dph at MIT-OZ

I have a large number of Chaosnet Transceivers.  Before I give the
ones we don't need to Eric and EE, please inform me if you need one,
or if you know of a device which is off the net because it lacks a 
transceiver.
-------
26-Oct-82 23:04:13-EDT,881;000000000000
Mail-From: HDT created at 26-Oct-82 23:01:14
Date: 26 October 1982  23:01-EDT (Tuesday)
Sender: HDT at MIT-OZ
From: Howard Daniel Trachtman <HDT at MIT-MC>
To:   RICKL at MIT-OZ
cc:   bug-hardware at MIT-OZ
Subject: left mouse button, cadr 19
In-reply-to: The message of 26 Oct 1982  22:50-EDT from RICKL at MIT-OZ

    Date: Tuesday, 26 October 1982  22:50-EDT
    From: RICKL at MIT-OZ
    To:   bug-lispm at MIT-OZ
    Re:   left mouse button, cadr 19

    left mouse button, cadr 19, sometimes sticks.  a low-level
    problem, but one you should be aware of.

In the future, please send similar lisp machine hardware problems to
bug-hardware.  In this particular case, you could take the mouse
to John Purbrick, whose office is next to cadr-1's room (907).

Also stuck is the abort key on cadr-5 and non-functional is the
resume key on Marvin.
-------
27-Oct-82 00:13:27-EDT,421;000000000000
Date: Wednesday, 27 October 1982, 00:08-EDT
From: JCMa@MIT-OZ
Subject: [RICKL at MIT-OZ: left mouse button, cadr 19]
To: bug-hardware@MIT-OZ

Mail-From: RICKL created at 26-Oct-82 22:50:15
Date: 26 Oct 1982 2250-EDT
From: RICKL at MIT-OZ
Subject: left mouse button, cadr 19
To: bug-lispm at MIT-OZ

left mouse button, cadr 19, sometimes sticks.  a low-level
problem, but one you should be aware of.
-------
27-Oct-82 09:06:09-EDT,581;000000000000
Mail-From: AKR created at 27-Oct-82 09:04:47
Date: Wednesday, 27 October 1982  09:04-EDT
Sender: AKR at MIT-OZ
From: AKR at MIT-MC
To:   PGA at MIT-OZ
Cc:   bug-hardware at MIT-OZ, bug-oz at MIT-OZ, dph at MIT-OZ,
      pgs at MIT-OZ
Subject: Chaosnet transceivers
In-reply-to: The message of 26 Oct 1982  20:12-EDT from PGA


If you have a large number, I would like to keep one in 936 for the next
CADR.  Just a week ago, I had a hard time finding a working transceiver for
CADR-TEST.  I am also not sure if CADR-8's transceiver, that is up in 936, works.
-------
27-Oct-82 11:38:56-EDT,462;000000000000
Mail-From: HDT created at 27-Oct-82 11:34:53
Date: 27 Oct 1982 1134-EDT
From: Howard Daniel Trachtman <Hdt at MIT-OZ>
Subject: disk-labels
To: bug-hardware at MIT-OZ



 Both cadr-5 in 904 and the cadr in 901 are dead now, and both
had bad disk partitions in the past.  Cadr-5 dies towards the
latter part of booting.

If it is in fact the bands that are bad, could someone please
edit the disk label so that people won't use those bands.
-------
28-Oct-82 02:57:29-EDT,730;000000000000
Date: 28 October 1982 02:16-EDT
From: Pandora B. Berman <CENT at MIT-ML>
Subject: ai tape drive
To: BUG-HARDWARE at MIT-ML
cc: ERIC at MIT-ML

    Date: 27 Oct 1982 1525-EDT
    From: TY at MIT-OZ
    Subject: ai's tape drive
    To: cent at MIT-OZ

    dec did the alignment but the damm thing seems to be wedged when ever there
    is I/O . I don't know who to ask but someone should look at it.
    Try to use it.. It looks to me as if it just wants to write ones
    -------
i don't want to risk messing things up worse than they are.
would someone who knows about tape drives please check out AI's SOON,
and fix it (or at least announce what needs to be fixed) so
i can return to doing dumps of AI? thx.

28-Oct-82 15:00:00-EDT,424;000000000000
Date: 28 October 1982 14:54-EDT
From: Richard Mark Soley <SOLEY at MIT-MC>
To: BUG-HARDWARE at MIT-MC
cc: JLMK at MIT-MC, WGD at MIT-MC

According to its herald, CADR 16 has a total of 128K physical memory.
This means that 256K has been stolen.  Do you keep a log of which
boards belong to which machines?  If so, could you tell us which
machines have more memory than they should?  Thank you.

	-- Richard Soley
28-Oct-82 17:29:56-EDT,1220;000000000000
Date: Thursday, 28 October 1982  17:16-EDT
Sender: PGS at MIT-OZ
From: PGS at MIT-MC
To:   Richard Mark Soley <SOLEY at MIT-OZ>
Cc:   BUG-HARDWARE at MIT-MC, JLMK at MIT-MC, WGD at MIT-OZ
In-reply-to: The message of 28 Oct 1982  14:54-EDT from Richard Mark Soley <SOLEY>

    Date: Thursday, 28 October 1982  14:54-EDT
    From: Richard Mark Soley <SOLEY>

    According to its herald, CADR 16 has a total of 128K physical memory.
    This means that 256K has been stolen.  Do you keep a log of which
    boards belong to which machines?  If so, could you tell us which
    machines have more memory than they should?  Thank you.

    	-- Richard Soley

I hope you mean, "This means that 128K has been stolen," because I don't
believe that LCS paid for extra memory boards for that machine, and all Lisp
machines being made at that time were being sent out with 256K total, as far
as I know.  Correct me if I'm wrong.

Anyway, no, we don't keep a log of which boards belong to which machines, but
I'm pretty darned sure I know which research group's machines your memory
ended up on.  Go to Alex Krymm, room 936, and he will give you two memory
boards as soon as he has them debugged.
-------
29-Oct-82 01:55:46-EDT,1059;000000000000
Date: 29 October 1982 01:50-EDT
From: Pandora B. Berman <CENT at MIT-ML>
Subject: ai tape drive
To: BUG-HARDWARE at MIT-ML
cc: ERIC at MIT-ML


    Date: 27 Oct 1982 1525-EDT
    From: TY at MIT-OZ
    Subject: ai's tape drive
    To: cent at MIT-OZ

    dec did the alignment but the damm thing seems to be wedged when ever there
    is I/O . I don't know who to ask but someone should look at it.
    Try to use it.. It looks to me as if it just wants to write ones
    -------
i don't know what dec did, but either the drive isn't aligned or none of
the tapes are. i tried the experiment of reading files off various ai gfr
tapes. GFR21 produced parity errors and non-recoverable data errors;
there was a label on it claiming that it was bad, so i decided the
labeler might have been right and tried other tapes. both GFR23 and
GFR16 (which was made a year ago) produce BAD HEADER errors. 
i remain to be convinced that DEC provided anything other than provocative
maintenance on the tape drive. i still can't do backups with it.

29-Oct-82 11:30:58-EDT,250;000000000000
Date: 29 October 1982 10:42-EDT
From: Ken Church <KWC at MIT-ML>
To: bug-hardware at MIT-OZ

The mouse on the cadr19 lispm terminal in GSB's office doesn't work.
You can't move it horizontally.

How can we go about getting it fixed?

- ken
29-Oct-82 16:31:01-EDT,829;000000000000
Date: 29 October 1982  16:16-EDT (Friday)
Sender: RPK at MIT-OZ
From: Robert P. Krajewski <RPK at MIT-MC>
Subject: Amazing
To:   Richard Mark Soley <SOLEY at MIT-OZ>
Cc:   BUG-HARDWARE at MIT-MC, JLMK at MIT-MC, WGD at MIT-OZ
In-reply-to: The message of 28 Oct 1982  14:54-EDT from Richard Mark Soley <SOLEY>

    Date: Thursday, 28 October 1982  14:54-EDT
    From: Richard Mark Soley <SOLEY>
    To:   BUG-HARDWARE at MIT-MC
    cc:   JLMK at MIT-MC, WGD

    According to its herald, CADR 16 has a total of 128K physical memory.
    This means that 256K has been stolen.  Do you keep a log of which
    boards belong to which machines?  If so, could you tell us which
    machines have more memory than they should?  Thank you.

    	-- Richard Soley
WHAT ???  How can you even run programs on it then ???
29-Oct-82 16:38:57-EDT,942;000000000000
Mail-From: HAMMY created at 29-Oct-82 16:37:22
Date: 29 Oct 1982 1637-EDT
From: HAMMY at MIT-OZ
Subject: RS232 connecters
To: cadr at MIT-OZ
cc: hammy at MIT-EECS

	I know that this subject does not explicitly deal with lisp
machines, but I think the mailing list reaches the right crowd.  
	Recently EE received a shipment of cinch RS232 connectors, but
instead of getting female connectors (for stringing terminals), we got
hoods instead.  You know, those little plastic things that cover the
connectors.  
	We have more than a lifetime supply.  Anybody interested in
horsetrading?  We were expecting to get female connectors that use
pins, does anybody have some?  
	Would anybody be interested in setting up a mailing list for
swapping needed parts?  You know, all those times when you needed a 
12K resister, and you found that you just ran out.  Something like that.


						Hammy 
						<Hammy at OZ>

-------
30-Oct-82 03:16:21-EDT,1178;000000000000
Date: Saturday, 30 October 1982, 02:09-EDT
From: David A. Moon <Moon at MIT-MC>
Subject: Missing memory on CADR16
To: Richard Mark Soley <SOLEY at MIT-MC>
Cc: BUG-HARDWARE at MIT-MC, JLMK at MIT-MC, WGD at MIT-MC
In-reply-to: The message of 28 Oct 82 14:54-EDT from Richard Mark Soley <SOLEY at MIT-MC>

    Date: 28 October 1982 14:54-EDT
    From: Richard Mark Soley <SOLEY at MIT-MC>
    To: BUG-HARDWARE at MIT-MC
    cc: JLMK at MIT-MC, WGD at MIT-MC

    According to its herald, CADR 16 has a total of 128K physical memory.
    This means that 256K has been stolen.
Bear in mind that if some of your memory is broken (so broken that the trivial
memory size test during booting can detect that it is broken), the machine
doesn't use it, nor any extant memory at higher addresses.  So if you want
to know how much memory is really in the machine, you have to go look.  If
there is more than it thinks it has than the board at the next higher address
(in your case, board #2 since they are 64K each and start at 0) is probably
broken.  If the amount it thinks it has is not a multiple of 64K then the
board containing the boundary is certainly broken.
30-Oct-82 17:54:42-EDT,742;000000000000
Date: Saturday, 30 October 1982, 17:50-EDT
From: Daniel Weise <Daniel at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ
Cc: akr at MIT-OZ, taft at MIT-OZ, hanson at MIT-OZ, dph at MIT-OZ, pgs at MIT-OZ

In HARDWARE in Remote-File 19.1, LMFILE-Remote 21.1, MIT-Specific 14.0,
System 89.25, ZMail 47.8, Experimental Local-File 40.7,
Experimental DPL 3.0, microcode 183,  , on Lisp Machine Two:

This machine likes to die every once in a while.  The blinkers
stop blinking, the clock stops clocking and its heart stops
beating.  Mouth to mouth resuscitation (warm booting) does not
work (the run bar flickers for a short brief moment before freezing
again.)  Only by praying to the great god C-M-C-M-RUBOUT can it
be resurrected.  

daniel
31-Oct-82 14:57:38-EST,651;000000000000
Date: Sunday, 31 October 1982, 14:53-EST
From: Daniel Weise <Daniel at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ
Cc: taft at MIT-OZ, akr at MIT-OZ, pgs at MIT-OZ, dph at MIT-OZ

In HARDWARE in Remote-File 19.1, LMFILE-Remote 21.1, MIT-Specific 14.0,
System 89.25, ZMail 47.8, Experimental Local-File 40.0, microcode 187, .,
on Lisp Machine Two:

This machine died on me again.  I got out the debugging cables and did
some looking around.  :why said I had a main memory parity error at
610472 and then died trying to get the microcode symbols for 187 (the
price of being up to date).  I didn't bother to do memory tests at that
point.

Daniel
 1-Nov-82 07:06:51-EST,910;000000000000
Date: 1 November 1982 06:57-EDT
From: Pandora B. Berman <CENT at MIT-ML>
Subject: oz tape drive acting up
To: BUG-backup at MIT-OZ
cc: bug-hardware at MIT-OZ

while i was doing a full dump tonight (of ss:, luckily), at what looked
like the end of the tape being written, dumper unexpectedly reported
a write-protect error, and asked for a <cr> when i had rectified the
situation. nothing looked wrong, and the tape most certainly possessed
a write ring, so i fed it a <cr> and watched it start getting nothing
but recurrent errors on the order of "something is wrong with the
tape drive" (all this is in the hardcopy of the oz system console,
around 4am or so). eventually i just started the dump over, using only
mta1:. would someone who knows about such things please look mta0: over
for anything wrong? is it possible that something subtle happened like
the tape drive door opened a crack?
 1-Nov-82 10:40:18-EST,1213;000000000000
Date: Monday, 1 November 1982, 10:31-EST
From: Ed Barton <eb at MIT-OZ>
To: Bug-Hardware at MIT-OZ


(cc)
***********************************************
PC=17045   OBUS=25022006030   (STACK-CLOSURE-TRAP-REALLY 1)
IR=(JUMP (EXTRA-PDL-TRAP-1 14)) 
ERROR-STATUS JC-TRUE NO-OP IR48 IMODD XBUS-PARITY-ERR 

***********************************************
PC=167   OBUS=6200   (QMLP 3)
IR=(DISPATCH (BYTE-FIELD 4 11) M-INST-BUFFER OPDTB LOW-PC-BIT-SEL-HW) 
ERROR-STATUS IR48 MN-MEM-PAR ANY-ERR XBUS-PARITY-ERR 

There is a main memory parity error.
:why
Machine being debugged is MIT-LISPM-18.
Processor error:
  Main-memory parity error
Bus-interface errors since last reset:
  Xbus data parity error
Memory parity error physical address = 1006424, data = 5100014031, MD data=5100014031
Address is memory board #4, bank #0
Checking disk copy of this virtual memory address
Disk data = 5140014031, differs in bit 23
Do you want to try a parity sweep?(Y or N) Yes.Assuming there are 5 memory boards
[Warning: I don't think this works for more than 256K]

Level 1 map loaded for the low 256K addresses.
Level 2 map loaded.
Type :WHYSOFT to attempt to analyze the current software state.
 1-Nov-82 12:15:52-EST,492;000000000000
Mail-From: HANSON created at 31-Oct-82 17:40:51
Date: Sunday, 31 October 1982  17:40-EST
Sender: HANSON at MIT-OZ
From: HANSON at MIT-MC
To:   bug-hardware at MIT-OZ


The disk currently connected to CADR2 is in fact the disk that
was fixed for CADR8.  CADR2's disk is broken and should be fixed;
until then CADR8 is still out of service.

CADR8's keyboard doesn't work, either.  The physical keyboard is
ok, but the connection between the keyboard and the machine
isn't there.
 1-Nov-82 13:01:31-EST,241;000000000000
Mail-From: HDT created at  1-Nov-82 12:56:00
Date:  1 Nov 1982 1255-EST
From: Howard Daniel Trachtman <Hdt at MIT-OZ>
Subject: Dead cadr-s
To: bug-hardware at MIT-OZ


  Both cadr-2 and cadr-5 died shortly after cold boots.
-------
 1-Nov-82 18:34:15-EST,1943;000000000000
Date: Monday, 1 November 1982, 18:29-EST
From: Chris Hanson <HANSON at MIT-OZ>
To: Bug-Hardware at MIT-OZ


More problems with CADR2/CADR8:

The CADR8 disk drive, which was just put in service to replace CADR2's
ailing drive, now no longer works.  When I found that CADR2 wasn't
working, I went upstairs and found that the drive had spun itself down.
So I spun it up again, and tried to boot the machine.  No luck, it
stopped at microcode 528 (the same place that it normally stops while
waiting for the drive to spin up).  I threw the switch to spin down the
drive, but it refused to spin down!  So I cut the main power.

I looked at it pretty closely and discovered that the +-50V circuit
breaker inside was blown.  I decided to put my own disk pack into the
drive and try a few things.  When I attempted to turn the breaker back
on with the main power breaker on, it wouldn't go; however by turning
off the main power, turning on the other breaker, and turning back on
the main power, it stayed on.  However, the drive still refused to spin
up.

I then disconnected drive #2 from CADR27 and attempted to connect it to
CADR2.  This new drive spun up just fine, but CADR2 kept on stopping at
microcode 528.  Reasoning that perhaps it was the disk controller, I
swapped in the controller from CADR8, but the behavior remained the
same.

At this point I had changed the cabling, disk controller, and drive on
CADR2, and its behavior remained exactly the same.

DPH and I then attempted to connect up CADR27's disk to CADR8 and see if
it would boot.  In the process of putting back the disk controller
board, we noticed that CADR2's DC had some loose pins.  But CADR8's
board was OK.  We put it back in, then tried to bring up the machine.
The drive spun up ok, but the machine stopped at microcode 598, without
ever trying to seek.  Not having any other possibilities in mind, we
gave up.

Chris Hanson
 2-Nov-82 00:10:18-EST,207;000000000000
Date: Tuesday, 2 November 1982, 00:07-EST
From: Chris Hanson <HANSON at MIT-OZ>
To: Bug-Hardware at MIT-OZ


CADR1 refuses to cold boot.  It is getting interrupts
from an unknown Unibus address 1774.
 2-Nov-82 04:58:54-EST,992;000000000000
From: CENT@MIT-ML
Date: 11/02/82 04:59:33
Subject: ai tapes lose again

CENT@MIT-ML 11/02/82 04:59:33 Re: ai tapes lose again
To: (BUG HARDWARE) at MIT-ML
i don't think it's misaligned heads, people. i took a blank new tape,
put it on ml, and copied the file ML:CENT;SAS TALE (4+ blocks of
amusing text) to the MT0: device. then i took the tape over to AI and
tried copying from the MT0: device to DSK:. i got two different chunks
of controlified gibberish, which are in the files AI:CENT; TRY 1 and
TRY 2; they are each exactly 6 blocks long. the file from ML is really
on the tape; i tried copying it back from MT0: to DSK:CENT;FOO FOO, and
srccom'ing found no differences. the tape is labelled TEMP 2, and is
on my desk in 926, if anyone is interested in IT.
but i think the problem is either in ai's tape drive or tape drive
controller. ty, what's the story on DEC doing maintenance on wed.?
are they really going to do something useful? for this tape problem
maybe?

 2-Nov-82 14:38:26-EST,1343;000000000000
Mail-From: PGS created at  2-Nov-82 05:48:51
Date: Tuesday, 2 November 1982  05:48-EST
Sender: PGS at MIT-OZ
From: PGS at MIT-MC
To:   CENT at MIT-ML
Subject: ai tapes lose again
cc:   bug-hardware at MIT-OZ
In-reply-to: The message of 2 Nov 1982  04:59-EST from CENT at MIT-ML

It looks to me like there isn't any one on the other end of BUG-HARDWARE
listening to people talking about things like fixing tape drives.  That is,
if you say that a Lisp Machine is broken, Krymm will go frotz with it and
make it work, but if you say that the tape drive is broken, there isn't
anyone who gets BUG-HARDWARE who will make sure that it works.  I was under
the impression that Ty was the person who traditionally interfaced with the
field circus people, but clearly this isn't happening this time.

Penny, if you feel up to it (that is, if you're in the right phase), you
should probably call up field circus yourself and tell them to fix the thing
and make sure that it works before they go away.  And if it doesn't work,
they should do whatever is necessary to make it work, short of replacing it
altogether, which would probably be an unjustifiable expense.  However, you
should feel free to get them to replace motors and random tronics in its
guts, regardless of how much Lester the Molester or whoever yabbles about it.
 2-Nov-82 17:56:31-EST,269;000000000000
Mail-From: KWH created at  2-Nov-82 17:12:02
Date:  2 Nov 1982 1712-EST
From: KWH at MIT-OZ
Subject: CADR-6 dead
To: bug-hardware at MIT-OZ

The aforementioned Lisp Machine croaked while I (Dulcey) was using
it.  It won't boot or do anything else now.
-------
 3-Nov-82 08:13:09-EST,925;000000000000
Date: Wednesday, 3 November 1982, 08:12-EST
From: Patrick Sobalvarro <PGS at MIT-OZ>
Subject: CADR-6 dead
To: dulcey at MIT-OZ, bug-hardware at MIT-OZ

    Mail-From: KWH created at  2-Nov-82 17:12:02
    Date:  2 Nov 1982 1712-EST
    From: KWH at MIT-OZ
    Subject: CADR-6 dead
    To: bug-hardware at MIT-OZ

    The aforementioned Lisp Machine croaked while I (Dulcey) was using
    it.  It won't boot or do anything else now.
    -------

CC claimed to have no idea why CADR-6 wasn't working, which isn't a surprise,
because TC had powered it down while the electricians were here, and powered it
up again afterwards.  If you had used CC when it died, we might have been able
to fix it before it bit someone else.  Anyway, I just booted CADR-6, and it's
alive now.

If a machine breaks, use CC to get a rough description of the problem.  If you
don't know how to use CC, get someone to show you.
 3-Nov-82 11:25:08-EST,261;000000000000
Date: Wednesday, 3 November 1982, 10:56-EST
From: David Chapman <Zvona at MIT-OZ>
To: bug-hardware at MIT-OZ
Cc: pa-cadr22 at MIT-OZ

CADR22's power supply fan stuck again.  This happens every three months.
Is there a permanent preventive cure for this?
 4-Nov-82 09:54:48-EST,224;000000000000
Mail-From: TC created at  4-Nov-82 09:49:48
Date:  4 Nov 1982 0949-EST
From: TC at MIT-OZ
Subject: cadr 22 
To: bug-hardware at MIT-OZ
cc: pgs at MIT-OZ

    ron changed the power supply fan on this
today.
-------
 4-Nov-82 09:55:59-EST,378;000000000000
Date: Wednesday, 3 November 1982, 10:56-EST
From: David Chapman <Zvona at MIT-OZ>
To: bug-hardware at MIT-OZ
Cc: pa-cadr22 at MIT-OZ
Remailed-date:  4 Nov 1982 0943-EST
Remailed-from: TC at MIT-OZ at MIT-MC
Remailed-to: bug-hardware at MIT-AI

CADR22's power supply fan stuck again.  This happens every three months.
Is there a permanent preventive cure for this?


 6-Nov-82 05:13:31-EST,356;000000000000
Mail-From: CYPHER created at  5-Nov-82 18:30:15
Date: 5 November 1982  18:30-EST (Friday)
Sender: CYPHER at MIT-OZ
From: D. Scott Cyphers <CYPHER at MIT-MC>
Subject: cadr12 memory
To:   bug-cadr at MIT-OZ

We dropped off two bad memory boards earlier today from Cadr12.  Could
someone send me mail when they are fixed?

Thanks,

Scott Cyphers
 8-Nov-82 12:31:37-EST,561;000000000000
Mail-From: JFC created at  8-Nov-82 12:30:38
Date:  8 Nov 1982 1230-EST
From: JFC at MIT-OZ
Subject: cadr25
To: bug-hardware at MIT-OZ
cc: jfc at MIT-OZ

Cadr25 has an intermittent fault that causes bad parity words
to be written onto disk, causing later unexpected crashes. Also
its disk drive is broken. Connecting it to another disk drive in
its present state will probably cause it to munge the label (at least)
of the disk pack. Also (possibly unrelated)the PC does not always 
start at address 00000 when powered on.

							- Jfc
-------
 9-Nov-82 09:19:20-EST,516;000000000000
Date: Tuesday, 9 November 1982, 09:13-EST
From: Gavan Duffy <GAVAN at MIT-MC>
To: BUG-APIARY-HARDWARE at MIT-OZ
Cc: BUG-HARDWARE at MIT-OZ

In HARDWARE in Experimental System 218.133, Zmail 65.40, LMFS 28.28,
Tape 11.3, LGP 20.4, microcode 963, site configuration 27, on Lisp Machine Twenty:

About 8:45 this morning, while working on apiary-1, the screen went
dead.  Underneath apiary-1 at the same time, on the 7th floor, workmen
were installing copper tubing in the ceiling.  Are these events related?
 9-Nov-82 20:19:33-EST,271;000000000000
Date: Tuesday, 9 November 1982, 20:14-EST
From: Howard D. Trachtman <Hdt at MIT-OZ>
To: bug-hardware at MIT-OZ

Cadr-18 just died.  Warm booting didn't work, and there were
no debug cables anywhere around that were long enough.
The led's on the machine said 16512
12-Nov-82 13:47:40-EST,372;000000000000
Date: 12 November 1982 13:44-EST
From: Jan Krueger <JLMK at MIT-MC>
To: bug-hardware at MIT-OZ

Dear Bug-hardware type-people,
Cadr16 has crashed many times doing various things for no particluar reason.  
Warm booting usually doesn't bring it back up and we have to resort to cold 
booting.  Could someone take a look and see what's wrong? 
			Thanks,
			-Jan-
12-Nov-82 18:39:05-EST,545;000000000000
Date: Friday, 12 November 1982, 15:15-EST
From: Carl Richard Feynman <CARLF at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in Remote-File 19.1, LMFILE-Remote 21.2, MIT-Specific 14.0,
System 89.37, ZMail 47.13, microcode 183, !, on Lisp Machine Eighteen:

This machine crashed in the middle of some perfectly normal typing at
ZWEI at 5:07 pm. The clock stopped, and a warm boot caused one of the
run-bars that appear an inch above the bottom of the screen to appear,
but nothing further to happen. A cold boot worked.

			--carl
12-Nov-82 18:42:14-EST,190;000000000000
Date: 12 November 1982 16:19-EST
From: Mark Plotnick <MP at MIT-MC>
To: BUG-HARDWARE at MIT-MC

The right-hand fuse on MC's system console has burned out,
so it's not typing anything.
13-Nov-82 00:41:02-EST,753;000000000000
From: CENT@MIT-ML
Date: 11/13/82 00:33:32
Subject: mc console

CENT@MIT-ML 11/13/82 00:33:32 Re: mc console
To: MP at MIT-MC
CC: CBF at MIT-ML, (BUG HARDWARE) at MIT-MC
    Date: 12 November 1982 16:19-EST
    From: Mark Plotnick <MP at MIT-MC>
    To: BUG-HARDWARE at MIT-MC

    The right-hand fuse on MC's system console has burned out,
    so it's not typing anything.

i replaced the fuse and turned on the console; it began typing funny, as if
it was losing some of the output, and then blew the fuse again. CBF came
over and fixed the problem, which was an incorrectly-implaced, and thus
too tight, ribbon; would whoever put it in please have someone competent
check him out in this before he tries replacing the ribbon again.
13-Nov-82 05:52:53-EST,539;000000000000
Date: 13 November 1982 02:41-EST
From: Pandora B. Berman <CENT at MIT-ML>
Subject: mta0 loses again
To: MARTY at MIT-ML
cc: bug-hardware at MIT-OZ

i was running a full dump of ps:. a tape (luckily, the first) was on mta0:.
when dumper reached EOT and should have rewound, it instead reported
"tape is write protected, fix & try again". no way to get around this,
so i had to start from the beginning on mta1:. marty, please remember to
call dec and make them fix the write-protection sensor. it did this a few
weeks ago, too.
13-Nov-82 15:42:48-EST,528;000000000000
Date: 13 November 1982 13:24-EST
From: Ed Schwalenberg <ED at MIT-MC>
Subject: MC T32 emitting continuous garbage.
To: BUG-HARDWARE at MIT-MC
cc: BUG-ITS at MIT-MC

I set the linespeed to 0 to disable T32, which was typing garbage at the
system.  Is there any documentation for LSPEED?  I went blithely ahead
and assumed that it worked like a reasonable program, but it would be
nice to know.  It would be similarly nice if the same programs worked for
all known TTY types, but this is rapidly becoming a dead issue.
13-Nov-82 15:43:39-EST,170;000000000000
Date: 13 November 1982 13:28-EST
From: Ed Schwalenberg <ED at MIT-MC>
Subject: T21 as well...
To: BUG-HARDWARE at MIT-MC
cc: BUG-ITS at MIT-MC

has been silenced.
13-Nov-82 17:14:43-EST,664;000000000000
Date: 13 November 1982 17:09-EST
From: V. Ellen Golden <ELLEN at MIT-MC>
Subject: T21 and T32
To: ED at MIT-MC
cc: BUG-HARDWARE at MIT-MC

Thanks for "silencing" these two very ambitious little bogosities.
They (and a couple of their friends, T31 and T34, but those two don't
seem prone to run amok) appear to have come detached somewhere between
the I/O-11 and the patch panel on the 8th floor.  TY and Joe Ricchio
have promised to go up in the ceiling above the patch panel and check
the situation out.  Meanwhile back at the ranch, we try to set their
LSPEED's to 0 when the system is brought up, this seems to keep them
"off line" (so to speak).
13-Nov-82 23:19:32-EST,170;000000000000
Mail-From: HANSON.FOX created at 13-Nov-82 22:05:26
Date: 13-Nov-82 22:05:26
From: HANSON.FOX at MIT-OZ
To: cadr at MIT-OZ

[This was a failing send]
-------
20
15-Nov-82 13:54:33-EST,180;000000000000
Date: Monday, 15 November 1982, 13:52-EST
From: William A. Kornfeld <BAK at MIT-OZ>
To: bug-hardware at MIT-OZ

Left control key for the keyboard on cadr6 is not functioning.
15-Nov-82 16:14:54-EST,324;000000000000
Date: 15 November 1982 16:09-EST
From: Richard J. Mlynarik <MLY at MIT-ML>
Subject: cadr-11 and the fact that its "resume" key doesn't work
To: bug-hardware at MIT-OZ

This is true. It produces a complete null, even using tv:key-state
Please fix this, as it makes somes things (eg EH) very difficult to use.
Thanks.
16-Nov-82 06:08:23-EST,299;000000000000
Mail-From: GUMBY created at 16-Nov-82 06:04:16
Date: 16 Nov 1982 0604-EST
From: GUMBY at MIT-OZ
Subject: AP1
To: bug-hardware at MIT-OZ

Around 6am this morning I suddenly lost all signals to the AP1 console.
The BW CRT went blank and the colour screen showed that it had no input.
-------
16-Nov-82 06:23:19-EST,199;000000000000
Date: 16 November 1982 06:18-EST
From: Christopher C. Stacy <CStacy at MIT-MC>
To: BUG-HARDWARE at MIT-MC
cc: KLH at MIT-MC


CADR16's console died at the same as AP1's; sudden loss of video.
16-Nov-82 09:48:02-EST,601;000000000000
Mail-From: PGS created at 16-Nov-82 09:47:42
Date: Tuesday, 16 November 1982  09:47-EST
Sender: PGS at MIT-OZ
From: PGS at MIT-MC
To:   William A. Kornfeld <BAK at MIT-OZ>
Cc:   bug-hardware at MIT-OZ
In-reply-to: The message of 15 Nov 1982 13:52-EST from William A. Kornfeld <BAK>

    Date: Monday, 15 November 1982, 13:52-EST
    From: William A. Kornfeld <BAK>
    To:   bug-hardware

    Left control key for the keyboard on cadr6 is not functioning.

Take it to Ron Witkin, tell him what's wrong, and get a new keyboard from
him.  Hah!  I bet you had no idea it was that simple.
16-Nov-82 12:27:13-EST,402;000000000000
Date: 16 November 1982 12:24-EST
From: Richard Mark Soley <SOLEY at MIT-MC>
To: BUG-HARDWARE at MIT-MC

The tube on cadr16 (in room 833) seems to be dead.  KLH
left this message on it:

Dead (Tube blown? Screen image suddenly began shrinking
smaller and smaller and vanished into a black hole -KLH 0540 11/16.

Could it please be checked?  Are there any spare monitors?

	-- Richard Soley
16-Nov-82 18:58:48-EST,228;000000000000
Date: 16 November 1982 18:55-EST
From: Richard Mark Soley <Soley at MIT-MC>
Sender: ___032 at MIT-MC
To: BUG-HARDWARE at MIT-MC

CADR25 (in room 904) fails to cold boot, either by keyboard
or boot button, at location 40.
17-Nov-82 02:24:58-EST,370;000000000000
Date: 17 November 1982 02:20-EST
From: David C. Plummer <DCP at MIT-MC>
Subject: [Forwarded: CSTACY@MIT-MC, Re: note about AP1 console dying]
To: BUG-HARDWARE at MIT-MC

Date: 17 November 1982 00:42-EST
From: Christopher C. Stacy <CSTACY at MIT-MC>
Subject:  note about AP1 console dying
To: BUG-HARDARE at MIT-MC
cc: ECC at MIT-MC


"PP" ==> patch panel

17-Nov-82 02:25:26-EST,501;000000000000
Mail-From: AGRE created at 17-Nov-82 02:22:37
Date: 17 Nov 1982 0222-EST
From: AGRE at MIT-OZ
Subject: Cadr-2's video signal...
To: bug-hardware at MIT-OZ
cc: : ;

... seems to be messed up.  Both the B&W and color screens look like
a TV with both vertical and horizontal hold knobs at random settings.
Neither hitting the boot button nor CMCM-Rubout seems to affect it any.
It happened to GAK (I don't know if he reported it); talk to him for
details of how it happened.  - phIl
-------
17-Nov-82 12:12:51-EST,428;000000000000
Date: Wednesday, 17 November 1982, 11:57-EST
From: Kent M. Pitman <kmp at MIT-MC>
To: BUG-HARDWARE at EE

In HARDWARE in System 210.128 on Lisp Machine Twenty-two:

The monitor on this machine seems to be flaking out. The intensity goes through
rapid changes making the scope nearly useless. We played with cords a bit
and it's possible that it's just a faulty connection in the power cord or
the ground pin.

--kmp
17-Nov-82 12:13:34-EST,461;000000000000
Date: Wednesday, 17 November 1982, 12:02-EST
From: Kent M. Pitman <kmp at MIT-MC>
Subject: Cadr-22
To: BUG-HARDWARE at MIT-MC

Hmm. We poked at some more wires and it seems to have stabilized some. I'm
inclined to believe there is/was some bad connection between the keyboard 
and the monitor. We had recently played with the cable to the keyboard so
it's the most likely suspect... Anyway, things seem happier now than when
I sent that last message.
17-Nov-82 13:07:05-EST,592;000000000000
Mail-From: KMP created at 17-Nov-82 13:05:31
Date: 17 Nov 1982 1305-EST
From: KMP at MIT-OZ
Subject: cadr22 again
To: bug-hardware at MIT-OZ

it's still chronically losing. the problem seems to definitely be in either
the power cord or the cord connecting the keyboard to the monitor. the point
of contact under the keyboard of the cable that runs to the back of the
monitor is the prime suspect. it should be easy to reproduce this lossage.
the effects on the screen of just playing with the cable are reasonably 
graphic so they're easy to spot when they happen.
-kmp
-------
17-Nov-82 13:37:13-EST,311;000000000000
Date: 17 November 1982 13:27-EST
From: Alan Bawden <ALAN at MIT-MC>
Subject:  [CSTACY: note about AP1 console dying]
To: BUG-HARDWARE at MIT-MC

Date: 17 November 1982 00:42-EST
From: Christopher C. Stacy <CSTACY>
To:   BUG-HARDARE
cc:   ECC
Re:   note about AP1 console dying

"PP" ==> patch panel
17-Nov-82 15:14:40-EST,176;000000000000
Date: 17 Nov 1982 1510-EST
From: Robert Scott Lenoil <LS.LENOIL at MIT-EECS>
Subject: Bouncing terminal
To: bug-hardware at MIT-EECS

term 6,1 has bouncing "g".
-------
17-Nov-82 15:19:38-EST,338;000000000000
Date: Wednesday, 17 November 1982  15:16-EST
From: David Vinayak Wallace <GUMBY at MIT-EECS>
To:   bug-hardware at ee
Subject: broken vt100 in eecs terminal farm

vt100 row 6, #2 has trouble tabbing (I think it's tabbing). Type a ?
and see what it does.
It''s not the terminal settings. The one next to it doesn't act like
that.
17-Nov-82 20:02:42-EST,307;000000000000
Mail-From: CAL created at 17-Nov-82 20:01:26
Date: Wednesday, 17 November 1982  20:01-EST
Sender: CAL at MIT-OZ
From: Cliff Lasser <CAL at MIT-MC>
To:   bug-hardware at MIT-OZ


It seems as if the keyboard on cadr 9 is dead.  It stop working on cadr2 so
I tried it out on cadr 9 and left it there.
17-Nov-82 20:12:34-EST,258;000000000000
Date: 17 November 1982 20:08-EST
From: Richard Mark Soley <SOLEY at MIT-MC>
To: bug-hardware at MIT-EECS

The screen on cadr16 (in room 833) is still dead.
It has been unplugged.  Can someone look at it?
Are there spare monitors?

	-- Richard Soley
18-Nov-82 14:33:10-EST,256;000000000000
Mail-From: DPH created at 18-Nov-82 14:30:18
Date: 18 Nov 1982 1430-EST
From: DPH at MIT-OZ
To: bug-hardware at MIT-OZ

I replaced the bad keyboard on cadr-9 with one I got from ROn.

GLR tells me the left control key on cadr-6 is losing.
-------
18-Nov-82 14:39:30-EST,422;000000000000
Date: Thursday, 18 November 1982  14:33-EST
Sender: AKR at MIT-OZ
From: AKR at MIT-MC
To:   Richard Mark Soley <SOLEY at MIT-OZ>
Cc:   bug-hardware at MIT-EECS
In-reply-to: The message of 17 Nov 1982  20:08-EST from Richard Mark Soley <SOLEY>


	The right person to find is Ron Witkin in room 916, in the
machine-shop area.  He would know if there are spare monitors and he
knows how to adjust and repair them.
18-Nov-82 20:33:21-EST,237;000000000000
Date: 18 Nov 1982 2028-EST
From: Philip E. Agre <LM.AGRE at MIT-EECS>
Subject: vt-100 #7-1
To: bug-hardware at MIT-EECS

has a marginal CTRL key.  I wants to be pressed down extra firmly or
it won't do anything.   - phiL
-------
22-Nov-82 04:16:49-EST,1300;000000000000
Mail-From: PGS created at 22-Nov-82 04:12:44
Date: Monday, 22 November 1982  04:12-EST
Sender: PGS at MIT-OZ
From: PGS at MIT-MC
To:   bug-hardware at MIT-OZ

IOB#32 is plugged into CADR-6 right now.  IOB#12 is on CADR-25.  IOB#12 works
on CADR-6, I think (at least there were no complaints when it was plugged in
on CADR-6).  IOB#32 does work on CADR-25, but has no serial I/O, so it is
impossible to run the Puma with it.  More precisely, IOB#32 has serial O but
no serial I.  IOB#12 has serial I/O.  Thus the switch.

But: IOB#12 does not quite work on CADR-25.  It seems to send and receive
OPN, ANS, CLS, and STS just fine, but it doesn't really seem to be too hot on
those old data packets.  The symptom is, it boots up, gets the time, answers
to NAME, even tells you who's on Lisp Machines, answers its own HOSTAT and
just does fine on those low opcodes, but as soon as you try to do something
that requires data packets, it says, "BARFOLA!  Chaos connection
#<YOUR-MOTHER-WEARS-ARMY-BOOTS> went into illegal state while waiting for
transaction."  The connection has received a LOS.  It looks like the far end
waits around and then times out and sends a LOS along?  Or sumpin.  Could we
be missing a bit (like, say, the 200's bit)?  Anyone have a more reasonable
thory?
22-Nov-82 04:26:46-EST,440;000000000000
Mail-From: PGS created at 22-Nov-82 04:24:52
Date: Monday, 22 November 1982  04:24-EST
Sender: PGS at MIT-OZ
From: PGS at MIT-MC
To:   bug-hardware at MIT-OZ
In-reply-to: The message of 22 Nov 1982  04:12-EST from PGS

Oh, I forgot to mention that I went through the rituals of cleaning and
checking contacts several times on IOB#12 in CADR-25.  It looks to me like a
conspiracy of marginality on the parts of CADR-25 and IOB#12.
24-Nov-82 01:11:50-EST,728;000000000000
Date: 24 November 1982 01:07-EST
From: Pandora B. Berman <CENT at MIT-ML>
Subject: ai dead
To: bug-hardware at MIT-OZ

ai apparently has a dead board. gsb watched it try to boot, and believes
it is dying on the half-word boundary trying to print out DSKDMP (it
says "DSK", then decrements wrong and prints "3.N,Z"; then somehow gets
back to the beginning of the loop and starts with "DSK" again, so that
it prints a solid line of "DSK3.N,Z" across the page). gsb diagnoses
this as the ILDB instruction being broken -- he says that's what breaks
on ML too. 
someone who can read prints and explore with a scope is needed to find
which board has broken in the processor; we think we have spares to
replace it with.
24-Nov-82 08:44:01-EST,413;000000000000
Date: Wednesday, 24 November 1982, 08:43-EST
From: Howard D. Trachtman <Hdt at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in Remote-File 19.1, LMFILE-Remote 21.2, MIT-Specific 14.0,
System 89.42, ZMail 47.13, microcode 187,   , on Lisp Machine Three:


The return key frequently (like until you're
used to it, 100% of the time) sends 2 or more returns.

This makes it very hard to get work done.
24-Nov-82 09:03:25-EST,692;000000000000
Mail-From: PGS created at 24-Nov-82 09:00:52
Date: Wednesday, 24 November 1982  09:00-EST
Sender: PGS at MIT-OZ
From: PGS at MIT-MC
To:   Howard D. Trachtman <Hdt at MIT-OZ>
Cc:   BUG-HARDWARE at MIT-OZ
In-reply-to: The message of 24 Nov 1982 08:43-EST from Howard D. Trachtman <Hdt>

    Date: Wednesday, 24 November 1982, 08:43-EST
    From: Howard D. Trachtman <Hdt>
    To:   BUG-HARDWARE

    The return key frequently (like until you're
    used to it, 100% of the time) sends 2 or more returns.

    This makes it very hard to get work done.

Heaven forbid that anything should keep you from getting work done.  Take
your keyboard to Ron Wicken in the machine shop.
25-Nov-82 08:58:23-EST,215;000000000000
Mail-From: HDT created at 25-Nov-82 08:57:06
Date: 25 Nov 1982 0857-EST
From: Howard Daniel Trachtman <Hdt at MIT-OZ>
Subject: zaphod 
To: bug-hardware at MIT-OZ


  Has been out since 11/23/82....
-------
25-Nov-82 16:23:38-EST,382;000000000000
Mail-From: KLOTZ created at 25-Nov-82 16:23:02
Date: Thursday, 25 November 1982  16:23-EST
Sender: KLOTZ at MIT-OZ
From: Leigh L. Klotz <KLOTZ at MIT-MC>
To:   bug-hardware at MIT-OZ
Subject: [DEJONG: VELO-BIND STUCK]

Date: Thursday, 25 November 1982  15:27-EST
From: DEJONG
To:   bug-velo-bind
Re:   VELO-BIND STUCK

The velo-bind binder is stuck in a down position.
26-Nov-82 13:40:54-EST,1209;000000000000
Mail-From: PGS created at 26-Nov-82 13:38:01
Date: Friday, 26 November 1982  13:38-EST
Sender: PGS at MIT-OZ
From: PGS at MIT-MC
To:   bug-hardware at MIT-OZ
Subject: new styles for winter

It seems that at some time in the far-distant past, it became fashionable to
remove the rear shrouds from T-80's, presumably to improve cooling or
something.  At least, I guess the intention was to improve cooling, because
the only visible effect seems to be that the card cages get full of dandruff,
chewing gum, and layers of dust so thick that one can't see whether fuses are
blown or not.

Has it actually been verified that removing the shrouds is a good idea?  The
last Trident repairman I talked to pointed out that there are several LCS
T-80's which, less chic than their AI sisters, didn't go in for the bare
look, yet didn't seem to need repair any more often.  He also suggested that
"The only difference I can see, is, dese ones dat don't have the covers, dey
get more shit in the cahd cages, is all."

In any case, I looked around for the shrouds and couldn't find any.  Does
anyone know where they might have walked off to?  Looks like we have about 4
or 5 T-80's without shrouds.
26-Nov-82 14:35:58-EST,261;000000000000
Date: 26 November 1982 14:30-EST
From: Jonathan D. Taft <TAFT at MIT-MC>
To: PGS at MIT-MC
cc: BUG-HARDWARE at MIT-MC

The absence of any covers on any disk drive is purely accidental or
due to plain laziness.  All covers do indeed belong on the drives.
28-Nov-82 05:23:00-EST,338;000000000000
Date: Sunday, 28 November 1982, 05:18-EST
From: Richard M. Stallman <RMS at MIT-OZ>
To: BUG-hardware at MIT-OZ

In hardware in Remote-File 19.1, LMFILE-Remote 21.2, MIT-Specific 14.0,
System 89.42, ZMail 47.13, microcode 187, .,
on Lisp Machine Twenty-five:


Main memory parity error on cadr5: board 3, bank 0, probably bit 0.
28-Nov-82 06:12:53-EST,537;000000000000
Date: Sunday, 28 November 1982, 06:07-EST
From: Richard M. Stallman <RMS at MIT-OZ>
To: BUG-hardware at MIT-OZ

In hardware in Remote-File 19.1, LMFILE-Remote 21.2, MIT-Specific 14.0,
System 89.42, ZMail 47.13, microcode 187, .,
on Lisp Machine Twenty-five:

I can make connections to CADR5 reliably from itself
and from CADR25, but attempts to connect from CADR1 and CADR18
nearly always get no response.

Meanwhile, CADR5 was getting frequent fatal disk errors a while ago.
So I stopped using it for anything nontrivial.
29-Nov-82 08:43:02-EST,807;000000000000
Date: Monday, 29 November 1982, 08:37-EST
From: David C. Plummer <DCP at SCRC-TENEX>
Subject: [ECC at MIT-OZ: Keyboard]
To: bug-hardware at MIT-OZ
Cc: ecc at MIT-OZ

please, Please, PLEASE send this type of thing to BUG-HARDWARE.
		     ------------------------------

Date: Monday, 29 November 1982, 06:44-EST
From: Eugene Ciccarelli <ECC at MIT-OZ>
Subject: Keyboard
To: BUG-LISPM at MIT-OZ

In LMFILE-Remote 21.2, MIT-Specific 14.0, System 89.45, ZMail 47.13,
Experimental Remote-File 20.0, Experimental Local-File 41.1,
microcode 183, LMFS 41.0, on Lisp Machine Six:

The left-hand Hyper key on this keyboard frequently fails to OR
in its bit.  If you type it consciously, determinedly, it does
work, but lots of times I type H-C-A or something, and just get
C-A.  (Or something.)
29-Nov-82 15:41:48-EST,401;000000000000
Date: Monday, 29 November 1982, 15:40-EST
From: Clifford A. Lasser <CAL at MIT-OZ>
To: BUG-hardware at MIT-OZ

In hardware in LMFILE-Remote 21.2, MIT-Specific 14.0, System 89.42,
ZMail 47.13, Experimental Remote-File 20.0, Experimental Local-File 41.1,
DAEDALUS 1.5, Nodes 1.2, microcode 183, LMFS 41.0,
on Lisp Machine Two:

The left control key on this machine does not work all the time.
29-Nov-82 18:27:59-EST,632;000000000000
Date: Monday, 29 November 1982, 18:27-EST
From: Patrick Sobalvarro <PGS at MIT-OZ>
To: CAL at MIT-OZ, BUG-hardware at MIT-OZ

    Date: Monday, 29 November 1982, 15:40-EST
    From: Clifford A. Lasser <CAL at MIT-OZ>
    To: BUG-hardware at MIT-OZ

    The left control key on this machine does not work all the time.

I don't care.  I never use CADR-2.  If you care, you should take the keyboard
up to Ron Wicken in the machine shop, and explain what's wrong or leave a note,
and take a working one.  Sorry for the obnoxious tone of this message.  I have
sent one just like it to about 20 people over the past month.
30-Nov-82 12:38:53-EST,317;000000000000
Date: Tuesday, 30 November 1982, 12:34-EST
From: David Chapman <Zvona at MIT-OZ>
To: BUG-hardware at MIT-OZ

In hardware in Experimental System 218.157, Zmail 65.41, LMFS 28.38,
Tape 11.3, LGP 20.4, microcode 963, site configuration 28, FPS, on Lisp Machine Six:

The right conterol key on cadr6 is marginal.
30-Nov-82 14:42:48-EST,955;000000000000
Mail-From: RPK created at 30-Nov-82 14:38:32
Date: 30 November 1982  14:38-EST (Tuesday)
Sender: RPK at MIT-OZ
From: Robert P. Krajewski <RPK at MIT-MC>
To:   Bug-Hardware at MIT-OZ, LS.Gumby at EE
Subject: [pace: forwarded]

Date: Monday, 29 November 1982, 20:28-EST
From: Pace Willisson <pace>
To:   BUG-LISPM

In Remote-File 19.1, LMFILE-Remote 21.2, MIT-Specific 14.0, System 89.45,
ZMail 47.13, microcode 187, Hit me, on Arthur Dent:

When I say "(apropos 'blt ':package 'si)" the system gets a trap and says:

>>>>TRAP 16351 (TRANS-TRAP)
The word #<DTP-TRAP 1> was read from location 1763033 (in CONTROL-TABLES).
While in the function STRING  STRING-SEARCH  SI:APROPOS-1

Is this type of bug worth reporting.  What does it mean anyway?

Pace


-- Could this be a symptom of Arthur having a bad pack or drive ?  I can
remember something happening like this before in System 87 on one of the EE
Lisp Machines.

``Bob''
30-Nov-82 19:16:16-EST,157;000000000000
Date: Tuesday, 30 November 1982, 19:13-EST
From: David Chapman <Zvona at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ

I switched the keyboards on cadrs 6 and 8.
 2-Dec-82 14:00:13-EST,323;000000000000
Date: Thursday, 2 December 1982, 13:59-EST
From: David Chapman <Zvona at MIT-OZ>
To: dph at MIT-OZ, bug-hardware at MIT-OZ

cadr6 keeps crashing.  I can't debug it very well because 
ucadr.sym.963 doesn't load into cadr27 because of incompatibility 
with sys86.  But it was a first-level map parity error last time.
 3-Dec-82 16:50:34-EST,389;000000000000
Mail-From: ZVONA created at  3-Dec-82 12:57:48
Date: Friday, 3 December 1982  12:57-EST
Sender: ZVONA at MIT-OZ
From: ZVONA at MIT-MC
To:   bug-hardware at MIT-OZ
cc:   taft at MIT-OZ, akr at MIT-OZ

I switched board 50 on cadr22 for board 3 on cadr2.  Cadr22 now has
512K (we bought another 256K from LMI) and board 50 seems to draw too
much power to run with the other boards.
 3-Dec-82 17:41:38-EST,1104;000000000000
Date: 3 December 1982 17:37-EST
From: KMP@OZ
Sender: CSTACY at MIT-MC
Subject: Cadr-22 losing
To: bug-hardware at MIT-OZ
cc: ZVONA at MIT-OZ, RICH at MIT-OZ, DICK at MIT-OZ

Cadr-22 is having some odd problem with the keyboard. It seems that you can't
type on its keyboard faster than about 1 char per 3-5 seconds. If you type 
very fast, only very few characters actually get through. If you type a char
and then wait for it to echo and then count to 3 slowly you can then type
another character. Echo lags about a second or more, too. All in all, it's not
very good. Booting to another band (even with different microcode) has no 
effect, so the problem is almost surely in hardware and probably in the 
keyboard. Also, even c-m-c-m-rubout does not tend to work very reliably. You
have to hold down the keys for a long time or try a lot or something before
it finally takes. Output (eg, from (PRINT-DISK-LABEL)) if you have the patience
to type slowly enough to complete an s-expression seems to come at the normal
speed so the processor and memory seem to be working fine...
--kmp
 4-Dec-82 01:54:51-EST,689;000000000000
Date: Saturday, 4 December 1982, 01:53-EST
From: David A. Moon <Moon at SCRC-TENEX>
Subject: Cadr-22 losing
To: KMP at MIT-OZ
Cc: bug-hardware at MIT-OZ, ZVONA at MIT-OZ, RICH at MIT-OZ, DICK at MIT-OZ
In-reply-to: The message of 3 Dec 82 17:37-EST from KMP at OZ

    Date: 3 December 1982 17:37-EST
    From: KMP@OZ

    Cadr-22 is having some odd problem with the keyboard. It seems that you can't
    type on its keyboard faster than about 1 char per 3-5 seconds. If you type 
    very fast, only very few characters actually get through....

Did you try unplugging the mouse?  It could have been sending
garbage very fast, using up the microprocessor in the keyboard.
 4-Dec-82 15:00:22-EST,445;000000000000
Mail-From: ZVONA created at  4-Dec-82 14:59:32
Date: Saturday, 4 December 1982  14:59-EST
Sender: ZVONA at MIT-OZ
From: ZVONA at MIT-MC
To:   bug-hardware at MIT-OZ
cc:   pa-cadr22 at MIT-OZ

Cadr22 is without main power.  I can't figure out what is wrong.  I
flipped all the breakers I could find, both in the machine and the one
it is plugged into.  It is in fact plugged in.  Can someone less
ignorant than I take a look?  Thanks.
 4-Dec-82 18:50:26-EST,409;000000000000
Mail-From: KMP created at  4-Dec-82 18:49:19
Date:  4 Dec 1982 1849-EST
From: KMP at MIT-OZ
Subject: Re: Cadr-22 losing
To: Moon at SCRC-TENEX
cc: bug-hardware at MIT-OZ, ZVONA at MIT-OZ, RICH at MIT-OZ, DICK at MIT-OZ
In-Reply-To: Your message of 4-Dec-82 0154-EST

The mouse was unplugged the whole time while I was noting this symptom. I also
booted the keyboard with no helpful effect.
-------
 4-Dec-82 19:44:17-EST,366;000000000000
Date: Saturday, 4 December 1982, 19:41-EST
From: Patrick Sobalvarro <PGS at MIT-OZ>
To: bug-hardware at MIT-OZ

CADR-30 does not generate sound.  This is not a problem in the wiring or the
keyboard; we've seen before that we have a bum iob that doesn't generate sound.
It's a pain if you use sound to advise you of things happening in the
background (I do).
 6-Dec-82 01:30:31-EST,389;000000000000
Mail-From: DPH created at  6-Dec-82 01:28:44
Date:  6 Dec 1982 0128-EST
From: DPH at MIT-OZ
Subject: cadr status after power down
To: bug-hardware at MIT-OZ

cadr-22 seems to be getting no power.  anybody know what circuit
breaker it's on?

cadr-3 refused to boot and began to smell like something might have
fried.  I couldn't locate the smell but powered it back off.
-------
 6-Dec-82 09:56:04-EST,424;000000000000
Mail-From: WELG created at  6-Dec-82 09:54:54
Date:  6 Dec 1982 0954-EST
From: W. Eric L. Grimson <WELG at MIT-OZ>
Subject: cadr-3 down
To: bug-hardware at MIT-OZ

Cadr-3 appears to be in a bad state.  It will not respond to a cold
boot.  Moreover, the screen contains a jumble of textured garbage,
and flickers in a manner similar to that experienced when the vertical
hold goes on a regular tv.

eric
-------
 6-Dec-82 10:16:08-EST,454;000000000000
Mail-From: RG.JMTURN created at  6-Dec-82 10:14:18
Date: Monday, 6 December 1982  10:14-EST
Sender: RG.JMTURN at MIT-OZ
From: RG.JMTURN at MIT-MC
To:   W. Eric L. Grimson <WELG at MIT-OZ>
Cc:   bug-hardware at MIT-OZ
Subject: cadr-3 down
In-reply-to: The message of 6 Dec 1982  09:54-EST from W. Eric L. Grimson <WELG>

Check the 6-conductor cable going from the TV to the Cadr. It sounds
like you lost the sync and keyboard lines.
				James
 6-Dec-82 10:59:42-EST,716;000000000000
Mail-From: AKR created at  6-Dec-82 10:52:08
Date: Monday, 6 December 1982  10:52-EST
Sender: AKR at MIT-OZ
From: AKR at MIT-MC
To:   DPH at MIT-OZ
Cc:   bug-hardware at MIT-OZ
Subject: cadr status after power down
In-reply-to: The message of 6 Dec 1982  01:28-EST from DPH


Cadr-22 is powered off the unswitched part (unswitched????) of the box
that sits under the regulated power supply.  There are two circuit breakers
on opposite sides.  The circuit breaker that is not on the processor side is the
good one, and it keeps tripping because all the power is being run through it. 
I reconnected some of the cooling fans to some power outlet in the floor, in
order to reduce the load a little.


 7-Dec-82 01:17:02-EST,165;000000000000
Date: Tuesday, 7 December 1982, 01:15-EST
From: William A. Kornfeld <BAK at MIT-OZ>
To: bug-hardware at MIT-OZ

the left control key on cadr-9 is intermittent.
 8-Dec-82 16:57:47-EST,278;000000000000
Date: 8 December 1982 16:55-EST
From: Richard Mark Soley <SOLEY at MIT-MC>
To: BUG-HARDWARE at MIT-MC

CADR16 has the amusing property of only operating approximately
5 minutes between cold boots.  Could someone look at it (i.e.,
by debug cable).  Thanks.

	-- Richard
 8-Dec-82 23:24:33-EST,278;000000000000
Date: 8 December 1982 23:21-EST
From: Pandora B. Berman <CENT at MIT-ML>
Subject: mta1: loses
To: BUG-HARDWARE at MIT-ML, bug-backup at MIT-OZ

oz's mta1: keeps losing vacuum a few seconds after i start using it;
it loads the tape ok but dies very shortly into the dump.
 9-Dec-82 10:24:04-EST,185;000000000000
Date: Thursday, 9 December 1982, 10:13-EST
From: Devon S. McCullough <Devon at MIT-MC>
To: Bug-Hardware at MIT-MC

the VT-52 next to MC's console clears it's screen spontaneously.
12-Dec-82 18:24:49-EST,600;000000000000
Mail-From: KMP created at 12-Dec-82 18:20:11
Date: 12 Dec 1982 1820-EST
From: KMP at MIT-OZ
Subject: CADR-22's terminal
To: bug-hardware at MIT-OZ
cc: pa-cadr22 at MIT-OZ

The black keyboard for Cadr-22 in room 823 has a faulty control key. It
fails about half the time. I'll try to bring it by for a replacement next
time I'm in, but in case someone gets ambitious in the meantime, I thought
I'd mention it. --kmp

ps the faulty control key is the left control key. (right ones are not much
   prone to going bad since they don't receive nearly the use that left ones
   do)
-------
12-Dec-82 20:11:28-EST,1061;000000000000
Mail-From: ZVONA created at 12-Dec-82 20:09:27
Date: Sunday, 12 December 1982  20:09-EST
Sender: ZVONA at MIT-OZ
From: ZVONA at MIT-MC
To:   KMP at MIT-OZ
Cc:   bug-hardware at MIT-OZ, pa-cadr22 at MIT-OZ
Subject: CADR-22's terminal
In-reply-to: The message of 12 Dec 1982  18:20-EST from KMP

    Date: Sunday, 12 December 1982  18:20-EST
    From: KMP
    To:   bug-hardware
    cc:   pa-cadr22
    Re:   CADR-22's terminal

    The black keyboard for Cadr-22 in room 823 has a faulty control key. It
    fails about half the time. I'll try to bring it by for a replacement next
    time I'm in, but in case someone gets ambitious in the meantime, I thought
    I'd mention it. --kmp

    ps the faulty control key is the left control key. (right ones are not much
       prone to going bad since they don't receive nearly the use that left ones
       do)
Goddamn.  I've returned that keyboard n times from n different
machines, and we keep getting it back.  Maybe I'll get ambitious and
hide it under the machine room floor tiles.
13-Dec-82 05:55:22-EST,409;000000000000
Date: Sunday, 13 December 1980, 05:54-EST
From: Howard Daniel Trachtman <Hdt at MIT-OZ>
To: BUG-Hardware at MIT-OZ

In Hardware in Remote-File 19.1, LMFILE-Remote 21.2, MIT-Specific 14.0,
System 89.49, ZMail 47.13, microcode 183, .,
on Lisp Machine Twenty-four:


In case its not know, this machine frequenly wedges
with this band, usually in the lisp listener.  Warm booting
almost always helps.
15-Dec-82 00:10:58-EST,358;000000000000
Date: Tuesday, 15 December 1980, 00:07-EST
From: Carl Richard Feynman <CARLF at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in Remote-File 19.1, LMFILE-Remote 21.2, MIT-Specific 14.0,
System 89.48, ZMail 47.13, microcode 187, nis12/8,
on Lisp Machine Three:

	The RESUME key on the keyboard on this machine appears to be broken.

					--carlf
17-Dec-82 16:16:47-EST,1407;000000000000
Date: 17 December 1982 16:16-EST
From: Patrick G. Sobalvarro <PGS at MIT-ML>
Subject: Vrooom!, or, Turbo-CADR-19
To: BUG-HARDWARE at MIT-ML
cc: HOPELESS-DREAM-KEEPERS-OF-INTERGALACTIC-SPACE at MIT-ML

CADR-19 is still living in the fast lane.  The idle time in the wholine
changes by 40 hours per 3 seconds.  The blinkers are doing their pathetic
best to keep up.  Needless to say, it can't establish any Chaos connections
in this state -- they time out in a few nanoseconds.

It calmed down for a little while yesterday when Krymm came into the room,
said a few words, and passed his hands over the console.  I took advantage of
the intermission to bring over a working system from CADR-30, but as soon as
Krymm left the room it started speeding again.

Anyway, the clock in the who-line seems to be keeping more or less normal
time, but (process-sleep 6000.) seems not to sleep at all.  I'm a little
worried about the long-term effects of this lack of sleep on the processor.
I've seen what happens to speed freaks after they've gone for a week without
sleep.  CADR-19 could be reduced to a burned-out shadow of its former self,
wandering around the network asking other processors for the time, but never
able to keep its attention on them long enough to find out the answer.

P.S.  Whoever fixes this, please contact me.  I have a friend I'd like you to
take a look at.

Pat
17-Dec-82 18:58:19-EST,603;000000000000
Date: Friday, 17 December 1982, 18:58-EST
From: Daniel L. Weinreb <dlw at SCRC-TENEX>
Subject: Vrooom!, or, Turbo-CADR-19
To: PGS at MIT-ML, BUG-HARDWARE at MIT-ML
Cc: HOPELESS-DREAM-KEEPERS-OF-INTERGALACTIC-SPACE at MIT-ML
In-reply-to: The message of 17 Dec 82 16:16-EST from Patrick G. Sobalvarro <PGS at MIT-ML>

We had this happen once at one of our LM-2's at ISI.  I'm nearly certain
that it turned out to be what you'd expect, namly, the microsecond clock
on the IOB.  I don't remember who at SCH dealt with the problem.  Try
swapping its IOB (don't forget about the Chaosnet address).
18-Dec-82 05:56:12-EST,261;000000000000
Date: Saturday, 18 December 1982, 05:53-EST
From: Howard D. Trachtman <HDT at MIT-OZ>
To: Bug-Hardware at MIT-OZ

I think I tripped a fuse or something in 904.
Sorry.   [Its clearly the power, and not anything major, but 
I'm too burnt to deal with it.]
18-Dec-82 06:26:00-EST,413;000000000000
Date: Saturday, 18 December 1982  06:18-EST
Sender: AKR at MIT-OZ
From: AKR at MIT-MC
To:   Patrick G. Sobalvarro <PGS at MIT-ML>
Cc:   BUG-HARDWARE at MIT-ML
Subject: Vrooom!, or, Turbo-CADR-19
In-reply-to: The message of 17 Dec 1982  16:16-EST from Patrick G. Sobalvarro <PGS at MIT-ML>


	Cadr-19's is back to normal.  It had a broken crc generator chip on
the IOB board.  Also cadr-30 beeps again.
20-Dec-82 15:29:00-EST,323;000000000000
Mail-From: NIS created at 20-Dec-82 15:27:00
Date: 20 Dec 1982 1527-EST
From: H. Keith Nishihara <NIS at MIT-OZ>
Subject: cadr-3 disk does not seem to be running?
To: bug-hardware at MIT-OZ

perhaps someone has already reported this but in case not,  
something is wrong with cadr-3's disk drive 
--keith
-------
21-Dec-82 06:42:34-EST,266;000000000000
Date: 21 December 1982 01:30-EST
From: Pandora B. Berman <CENT at MIT-ML>
Subject: dover loses
To: BUG-HARDWARE at MIT-ML

the dover seems to have severe problems with its paper tray.
i turned off printing/spooling until someone competent can
try to fix it.
26-Dec-82 13:08:19-EST,222;000000000000
Date: Sunday, 26 December 1982, 13:06-EST
From: Richard M. Stallman <RMS at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ

In HARDWARE on Lisp Machine One:

Cmem parity error in bit "bit-47" (4000000000000000) at address 6275
30-Dec-82 11:46:51-EST,481;000000000000
Mail-From: LEVITT created at 30-Dec-82 11:46:06
Date: 30 Dec 1982 1146-EST
From: LEVITT at MIT-OZ
Subject: CADR6 machine and keyboard dead
To: bug-hardware at MIT-OZ

The gray keyboard on CADR2 was producing random characters on almost
every keystroke, it seemed, so I swapped it in favor of the black keyboard
that was on CADR6.  (CADR6 was failing to cold-boot anyway.)B  The black
keyboard works fine on CADR2, the bad gray one is still at the CADR6 console.
-------
 3-Jan-83 04:51:53-EST,486;000000000000
Date: 3 January 1983 04:48-EST
From: William G. Dubuque <WGD @ MIT-MC>
Sender: BIL @ MIT-MC
To: BUG-HARDWARE @ MIT-MC

CADR-16's monitor (in 833) seems to be losing ever since the power
shutdown yesterday. The screen stays blank even though the machine
seems to be working. As far as I know, the monitor was not turned off
when the power was shutoff, so this may have something to do with it.
Any suggestions or help as to how to get this fixed would be greatly
appreciated.
 3-Jan-83 05:26:44-EST,940;000000000000
Date: Monday, 3 January 1983, 05:22-EST
From: Patrick Sobalvarro <PGS at MIT-OZ>
To: BUG-HARDWARE at MIT-MC
In-reply-to: The message of 3 Jan 83 04:48-EST from William G. Dubuque <WGD at MIT-MC>

    Date: 3 January 1983 04:48-EST
    From: William G. Dubuque <WGD @ MIT-MC>
    Sender: BIL @ MIT-MC
    To: BUG-HARDWARE @ MIT-MC

    CADR-16's monitor (in 833) seems to be losing ever since the power
    shutdown yesterday. The screen stays blank even though the machine
    seems to be working. As far as I know, the monitor was not turned off
    when the power was shutoff, so this may have something to do with it.
    Any suggestions or help as to how to get this fixed would be greatly
    appreciated.

I verified (by temporary substitution) that the monitor is actually broken.
Incidentally, the tube seems ok, but some of the circuitry must be fried.  I
directed these people to Ron Wicken for a replacement.
 3-Jan-83 17:43:15-EST,177;000000000000
Date: Monday, 3 January 1983, 17:44-EST
From: Richard M. Stallman <RMS at MIT-OZ>
To: bug-hardware at MIT-OZ

CADR 25 got unrecognized unibus interrupt, vector address 260
 5-Jan-83 00:51:52-EST,214;000000000000
Date: Wednesday, 5 January 1983, 00:51-EST
From: David Vinayak Wallace <Gumby at MIT-OZ>
Subject: gronked cadr 9
To: BUG-hardware at MIT-OZ

When you power up cadr9's disk it makes a horrible grinding noise.
 5-Jan-83 03:46:49-EST,348;000000000000
Date: Wednesday, 5 January 1983, 03:45-EST
From: JCMa@MIT-OZ
Subject: For your info
To: bug-hardware@MIT-OZ, kmp@MIT-OZ
Cc: jcma@MIT-OZ

Cadr-9 is dead.  I swapped an apparently bad board from cadr-22 (MWM#50)
with a good board from cadr-9 (MWM#68).  These boards are in the slots
cadr-9: #26 and cadr-22: #22.  Cadr-22 is now up to 512K.
 5-Jan-83 09:11:02-EST,620;000000000000
Date: Wednesday, 5 January 1983, 09:11-EST
From: Patrick Sobalvarro <PGS at MIT-OZ>
Subject: gronked cadr 9
To: Gumby at MIT-OZ, BUG-hardware at MIT-OZ
In-reply-to: The message of 5 Jan 83 00:51-EST from David Vinayak Wallace <Gumby at MIT-OZ>

    Date: Wednesday, 5 January 1983, 00:51-EST
    From: David Vinayak Wallace <Gumby at MIT-OZ>
    Subject: gronked cadr 9
    To: BUG-hardware at MIT-OZ

    When you power up cadr9's disk it makes a horrible grinding noise.

It was independently verified that CADR-9's disk did not survive Sunday's power
outage.  We probably should have put a sign on it.
 5-Jan-83 11:16:09-EST,1471;000000000000
Mail-From: KMP created at  5-Jan-83 11:14:28
Date:  5 Jan 1983 1114-EST
From: KMP at MIT-OZ
Subject: [JCMa@MIT-OZ: For your info]
To: BUG-HARDWARE at MIT-OZ
cc: ZVONA at MIT-OZ, RICH at MIT-OZ, DICK at MIT-OZ, KMP at MIT-OZ

    Date: Wednesday, 5 January 1983, 03:45-EST
    From: JCMa@MIT-OZ
    Subject: For your info
    To: bug-hardware@MIT-OZ, kmp@MIT-OZ
    Cc: jcma@MIT-OZ

    Cadr-9 is dead.  I swapped an apparently bad board from cadr-22 (MWM#50)
    with a good board from cadr-9 (MWM#68).  These boards are in the slots
    cadr-9: #26 and cadr-22: #22.  Cadr-22 is now up to 512K.
    -----
The board you swapped was a good board. There appears to be slight 
variation in the amount of power drawn by different boards if I understand
correctly. Board 50 is one of the "heavy" drain boards, which is why it
couldn't be run on Cadr-22. It ought to run fine on Cadr-9 when it comes back
up at least until Cadr-9 is upgraded to 512K in which case there's a chance
it'll have the same trouble Cadr-22 was having in driving all its memory 
boards. At that time, someone may want to trade it back to us. For now, I
think the change is no worse for anyone else and better for us. Thanks.
--kmp

ps to Zvona: This description of the situation is based on what I understood
	     from you a while back when we were having troubles with that 
	     board. If anything in this note sounds amiss, feel free to 
	     correct me.
-------
 5-Jan-83 12:21:33-EST,867;000000000000
Mail-From: GUMBY created at  5-Jan-83 12:16:34
Date: 5 January 1983  12:16-EST (Wednesday)
Sender: GUMBY @ MIT-OZ
From: David Vinayak Wallace <GUMBY @ MIT-MC>
To:   Patrick Sobalvarro <PGS @ MIT-OZ>
Cc:   BUG-hardware @ MIT-OZ
Subject: gronked cadr 9
In-reply-to: The message of 5 Jan 1983 09:11-EST from Patrick Sobalvarro <PGS at MIT-OZ>

    Date: Wednesday, 5 January 1983, 09:11-EST
    From: Patrick Sobalvarro <PGS at MIT-OZ>

        Date: Wednesday, 5 January 1983, 00:51-EST
        From: David Vinayak Wallace <Gumby at MIT-OZ>
        Subject: gronked cadr 9
        To: BUG-hardware at MIT-OZ

        When you power up cadr9's disk it makes a horrible grinding noise.

    It was independently verified that CADR-9's disk did not survive
    Sunday's power outage.  We probably should have put a sign on it.

Was the pack munged?
 8-Jan-83 15:51:09-EST,358;000000000000
Mail-From: DANNY created at  8-Jan-83 15:50:45
Date: Saturday, 8 January 1983  15:50-EST
Sender: DANNY @ MIT-OZ
From: DANNY @ MIT-MC
To:   bug-hardware @ MIT-OZ

Cadr-8 seems to have a flakey disk (??).
Dies when booting off old system 89 band or new system 91
band. A died while writing a 222 band. Is there some diagnostic that
can be run on it?
10-Jan-83 02:27:12-EST,1040;000000000000
Date: 10 January 1983 02:23-EST
From: Mark J. Dulcey <Dulcey @ MIT-ML>
To: BUG-hardware @ MIT-OZ


FS, FC, on Lisp Machine Filecomputer:

On cadr-27 for anyone who cares:

(si:print-disk-error-log)
Disk error count 3.

Command 4000 (Read) 
CCW-list pointer 61027 (low 16 bits)
Disk address: unit 1, cylinder 0, head 0, block 0 (1 0 0 0 decimal)
Memory address: 704377 (type bits 0)
Status: 37700021455  No-Select  Off-line  Off-Cylinder  Transfer-Aborted  Sel-Unit-Attention

Command 4000 (Read) 
CCW-list pointer 61027 (low 16 bits)
Disk address: unit 1, cylinder 0, head 0, block 0 (1 0 0 0 decimal)
Memory address: 460777 (type bits 0)
Status: 37700021455  No-Select  Off-line  Off-Cylinder  Transfer-Aborted  Sel-Unit-Attention

Command 4000 (Read) 
CCW-list pointer 61027 (low 16 bits)
Disk address: unit 3, cylinder 0, head 0, block 0 (3 0 0 0 decimal)
Memory address: 463777 (type bits 0)
Status: 37700021455  No-Select  Off-line  Off-Cylinder  Transfer-Aborted  Sel-Unit-Attention

NIL
(dribble-end)
11-Jan-83 04:47:47-EST,309;000000000000
Mail-From: AKR created at 11-Jan-83 04:46:54
Date: 11 Jan 1983 0446-EST
From: AKR at MIT-OZ
Subject: CADR-18 DISK DEAD.
To: bug-hardware at MIT-OZ


	Cadr-18 appears to have a broken disk drive.  It spins
up, but the devide check light goes off the moment it starts
seeking the disk label.
-------
11-Jan-83 17:17:40-EST,1799;000000000000
Mail-From: PGS created at 11-Jan-83 17:16:35
Date: Tuesday, 11 January 1983  17:16-EST
Sender: PGS @ MIT-OZ
From: PGS @ MIT-MC
To:   bug-hardware @ MIT-OZ
Subject:AI-CHAOS-11

I am documenting this here so that no one loses the way I just did.

Jon and I wheeled the 11/40 over to next to the ai-chaos-11.  I had
previously severed the Unibus on the 11/40 after the processor and memory.
The 11/40 has 24K of memory; the boot roms are high enough so that it
shouldn't have conflicted.  Anyway, we verified that the processor was
working after we got it to its new location (despite the fact that the Unibus
wasn't yet terminated).  We disconnected the Unibus cable coming out of the
11/10, or 11/05, or whatever a GT40 is, and put a unibus cable coming out of
the 11/40 in where it had been.

Over my fervent protests, Jon then powered it up and destroyed everything.
Then we powered up the 11/40, and noticed that bits 16 and 17 in the address
register were stuck on, and were unaffected by reset.  Load address didn't
work.  The bus light was on.  In general, the thing was broken.  We removed
the unibus cable and terminated the bus, and the thing was stil unhappy.  It
is broken, so something on the backplane under the GT40 eats PDP-11's.

I suspect the 11 side of the 10-11 interface of losing somehow, although I
have no good reason for my suspicions.  I didn't look long enough at the code
to know whether removing the 10-11 interface board will cause it to generate
NXM's.  Any advice would be appreciated; DEC should have things fixed
tomorrow afternoon.

The GT40's unibus cable is hanging in thin air right now, so anyone tempted
to play with it tonight should take note of this.
12-Jan-83 09:08:22-EST,491;000000000000
Mail-From: DANIEL created at 12-Jan-83 09:05:11
Date: Wednesday, 12 January 1983  09:05-EST
Sender: DANIEL @ MIT-OZ
From: DANIEL @ MIT-MC
To:   Carl Richard Feynman <carlf @ MIT-OZ>
Cc:   batali @ MIT-OZ, bug-hardware @ MIT-OZ, taft @ MIT-OZ, danny @ MIT-OZ
Subject: bad band
In-reply-to: The message of 11 Jan 1983 23:37-EST from Carl Richard Feynman <carlf>

It ahs the same problems with band 6 and band 3 in my experience
in the last week.  Could someone take a look at this?
12-Jan-83 21:22:54-EST,1042;000000000000
Date: Wednesday, 12 January 1983, 21:21-EST
From: Jonathan D. Taft <TAFT at MIT-OZ>
Subject: Cadr-8 Disk Problems
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in System 222.57, Hardcopy 11.5, Zmail 74.11, LMFS 30.4,
Tape 13.0, microcode 977, site configuration 2, on Lisp Machine Eight:

Any kind of disk band manipulation loses on this machine. 
Any system, any band, any time.

The 91 systems used to give more trouble than the 222's but now
you can't move partitions around at all.  Occasionally the
machine actually wedges on a user, but not often.

(SI:PRINT-DISK-ERROR-LOG) claims zero errors.

Just now the machine wedged and I tried to warm boot.  It
actually managed to print the following error:

    >>Error Disk read error
    unit 0, cylinder 59, surface 12, sector 3
    status ECC Hard  Transfer Aborted

    it was in SI:DISK-RUN with arguments:
       RQB:  <mumble array>
       UNIT: 0
       ADDRESS: 45426
       SECTORS-PER-TRACK 21
       HEADS-PER-CYLINDER 23
       COMMAND 4000				; "Read"
13-Jan-83 02:55:53-EST,279;000000000000
Date: 13 January 1983 02:38-EST
From: Patrick G. Sobalvarro <PGS @ MIT-MC>
Subject: ai-chaos-11
To: BUG-HARDWARE @ MIT-MC

This is just an obnoxious message from me and krymm, saying to all you losers
who aren't around to hear us scream, that we're beginning to win.  OK?
13-Jan-83 12:54:26-EST,214;000000000000
Date: Thursday, 13 January 1983, 12:52-EST
From: William A. Kornfeld <BAK at MIT-OZ>
Subject: cadr 9 chaos connection
To: bug-hardware at MIT-OZ

Cadr 9, although working now, isn't talking to the chaos net.
13-Jan-83 20:15:59-EST,525;000000000000
Date: Thursday, 13 January 1983, 20:15-EST
From: William A. Kornfeld <BAK at MIT-OZ>
Subject: file reading bug
To: BUG-LISPM at MIT-OZ, BUG-HARDWARE at MIT-OZ

In System 222.116, Hardcopy 11.9, Zmail 74.26, LMFS 30.11, Tape 13.0,
microcode 977, site configuration 3, FPS, on Lisp Machine Six:

I get the following error on various QBIN files at seemingly random
(non-repeatable) locations:

FASL-GROUP-NIBBLE-WITHOUT-CHECK-BIT

I know the files are good because they can be read fine into other
Lisp machines.
14-Jan-83 08:25:56-EST,316;000000000000
Date: Friday, 14 January 1983, 08:21-EST
From: Patrick Sobalvarro <PGS at MIT-OZ>
Subject: AI-CHAOS-11, the continued saga
To: bug-hardware at MIT-OZ

We fixed it.  We're not saying what was wrong with it, but the astute observer
will notice a moby new power supply in the back door and a new subnet 1 board.
15-Jan-83 02:34:45-EST,3280;000000000000
Date: Saturday, 15 January 1983  00:21-EST
Sender: DCP @ MIT-OZ
From: DCP @ MIT-MC
To:   chaos-ncp-people @ mc, bug-hardware @ ai, mit-network-group @ mc
Subject: This is aMAZing!!!!!

Let me describe the cricumstances, then I'll describe my theory.

From main campus, subnet 7:

A connection could not be made to any host at Tech Square.
However, we could get from subnet 7 to EE which must use subnet
1.  Viewing the routing tables of the various bridges showed that
there was no route to any hosts at Tech Square.

Chaosnetting to Multics and ARPA TCPing to MC revealed the
following from MC (near the other end of subnet 1):

All the bridges on subnet 1 responded.  ALL of them, including
the ones on the main campus.  Additionally, all sizes of packets
could be sent and received from all bridges.  The routing tables,
however, showed no route.  (I think the reason they responded at
all was because they were using old hop information even though
the cost was maximum.)  No hosts on subnet 7 could be accessed,
nor could speech or EE.  I assume this is because the various
routing tables did not get cast in cement, so old hop information
only worked for exactly one intervening bridge (in this case the
intervening bridge was MC-IO-11).

Each end of subnet 1 had routing information for itself, but not
for the other end.

Theory: routing on subnet 1 was broken, but all other packets
were making it through.  This does no good for hosts not on
subnet 1 since they have moldy (worse than stale) routing tables.

We came over to Tech Square to start disconnecting transceivers,
since in the past the Symbolics microwave transceiver has been
known to be a little flakey.  Unplugging it did not solve the
problem.  Additionally unplugging oz-network-11 and ai-chaos-11
caused routing to start to happen, and the rest of the network
started to appear.  Plugging oz-network-11 back did not cause
lossage.  Plugging scrc-microwave back did not cause lossage (it
made the symbolics subnets reappear).  Plugging ai-chaos-11 back
caused the routing tables to start to monotonically increase.

Hmmm....  What's going on here?  

AI-chaos-11 was hung.  No big deal, it does that.  It's chaos
board should be doing nothing.  Unwedging ai-chaos-11 and
starting it at 1000 (the program's starting address) caused
routing packets to be received again.  Hmmm.....

Theory: AI-chaos-11's chaosnet interface was (incorrectly)
deciding that it should send aborts for hardware broadcast
packets.  This would explain some things:

Main campus could use subnet 1 because ai-chaos-11's aborts did
not have enough energy to abort routing packets on the main
campus end.  (Also, some of the transceivers at main campus are
inches apart.)  Tech Square could talk to itself by reverting to
subnet 6.

Conclusions: A unibus chaos baord should be generated ASAP for
ai-chaos-11.  Until then, ai-chaos-11 should NEVER be left
halted/hung with the power on.  OR, the baord should be fixed.
This may be slightly tricky.  My guess is it has a rev2 chaos
baord (none built for at least 3 years).  There may some prints
around the lab, or there may be some prints at EE.

This is an amazing incident, and I'm moderately freaked out.


15-Jan-83 03:44:34-EST,989;000000000000
Date: Saturday, 15 January 1983, 03:30-EST
From: Patrick Sobalvarro <PGS at MIT-OZ at MIT-MC>
Subject: This is aMAZing!!!!!
To: DCP at MIT-MC, chaos-ncp-people at MIT-MC, bug-hardware at MIT-AI,
    mit-network-group at MIT-MC
In-reply-to: The message of 15 Jan 83 00:21-EST from DCP at MIT-MC

I replaced the subnet 1 board in the AI-CHAOS-11.  It was actually Pyggy's
board, one of the recent ones (#103) that Krymm and I had put in it while
testing this morning, and were too burned and lazy to replace once the thing
was working.  I returned its original subnet 1 board to it; that board is
marked Quad Chaos #2, so it's earlier than you thought.  The other board in
there was Quad Chaos #13; it at least had CSR switches.  To fix #13 (which is
also earlier than Rev. 2) we had to borrow a set of prints from EE.

Everything seems okay right now; a (hostat) shows main campus subnet 1 hosts
responding just fine, but it's only been half an hour since I booted it.


15-Jan-83 23:59:07-EST,634;000000000000
Mail-From: DPH created at 15-Jan-83 20:28:55
Date: Saturday, 15 January 1983  20:28-EST
Sender: DPH @ MIT-OZ
From: DPH @ MIT-MC
To:   bug-hardware @ MIT-OZ
subj: cadr6


Cadr6 has been suffering from chaosnet flakiness such as qfasl files
not loading on cadr6 that load elsewhere.  Last night I tried
receiving a band onto that machine and it got munged in the process.
Today I tried temporarily swapping chaos transcievers between it and
another cadr, and it still lost on trying to receive a band (that is,
the band arrived with munged bits) -- so it looks like it's not a
transciever problem.  IOB? cable? I'm lost.
17-Jan-83 02:04:40-EST,220;000000000000
Date: Monday, 17 January 1983, 02:02-EST
From:  at MIT-OZ
To: BUG-HARDWARE at OZ

In HARDWARE on Lisp Machine Nine:

Although there are four memory boards plugged into this machine, it
seems to only have 192K.

17-Jan-83 05:41:20-EST,1152;000000000000
Date: 17 January 1983 05:41-EST
From: Pandora B. Berman <CENT @ MIT-ML>
Subject: ai tape drive losing
To: BUG-HARDWARE @ MIT-ML

i have tried a couple times in the past few days to do an incremental dump
on AI. each time, the tape drive finds the load point and apparently starts
the dump correctly, but 4 blocks into .;@ NITS (the first normal-type file
-- DUMP claims to dump the MFD and .;.FILE. (DIR) successfully) something
goes wrong. DUMP claims to be sitting there waiting for more of the file,
while the tape drive keeps going.  ^G, which should stop DUMP from doing
whatever it's doing and make it produce a DUMP prompt, does nothing obvious
on the first incantation, and gives ? for all subsequent ones, while not
affecting the tape drive. ^Z, which should halt any job in its tracks, does
pop me up to HACTRN level, but the tape drive keeps going. all that seems
to get the drive's attention once it gets into this state is turning it
offline; this stops it, and then i can do all the normal offline things.

i have cleaned the drive, and i have powercycled it (i think). these do
not seem to have helped. any theories?
17-Jan-83 12:03:42-EST,496;000000000000
Date: Monday, 17 January 1983, 11:59-EST
From: Gavan Duffy <GAVAN at MIT-OZ>
Subject: redundancy in key-hitting
To: BUG-LISPM at MIT-OZ, bug-hardware at MIT-OZ

In Release 4.0, site configuration 9, on Lisp Machine One:

In split screen mode, one screen is a lisp listener and one screen is an
editor buffer, terminal-o needs to be hit twice in order to change the
cursor screen.  This could be a problem with the keyboard, since the
same behavior was noticed to happen with system-p.
17-Jan-83 16:09:47-EST,451;000000000000
Date: Monday, 17 January 1983, 16:08-EST
From: Clifford A. Lasser <CAL at MIT-OZ>
To: BUG-hardware at MIT-OZ

In Remote-File 22.0, LMFILE-Remote 23.1, MIT-Specific 16.0,
Experimental System 91.20, Experimental ZMail 48.3, microcode 204, !,
on Lisp Machine Filecomputer:

When one tries to bring up the file server, one gets the error message:
"unit 2 not loaded". 

Taft says he tried yesterday to get the disc started, but it won't spin.
17-Jan-83 18:00:00-EST,728;000000000000
Mail-From: DCP created at 17-Jan-83 17:56:08
Date: Monday, 17 January 1983  17:56-EST
Sender: DCP @ MIT-OZ
From: DCP @ MIT-MC
To:   bug-hardware @ MIT-OZ
cc:   pgs @ MIT-OZ, akr @ MIT-OZ
Subject: brokenness

The subnet 6 interface in oz-network-11 appears to be broken.
Gren unplugged the interface cable from the transceiver at my
request, and that seemed to cause the network to restabilize.
You will probably find the ribbon cable still unplugged (unless
somebody else fixes it before you get to it).

Symptoms: LOST and CRC counts go up phenomonly (about 100 times
that of packets in).  You might also check the physical
characteristics of the cable near the transceiver, and check the
transceiver itself.
18-Jan-83 01:11:46-EST,483;000000000000
Date: Tuesday, 18 January 1983, 01:11-EST
From: Carl Richard Feynman <CARLF at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in Experimental Remote-File 22.0,
Experimental LMFILE-Remote 23.1, Experimental MIT-Specific 16.0,
Experimental System 91.22, Experimental ZMail 48.4, DAEDALUS 1.7,
Nodes 1.2, microcode 204, on Lisp Machine Two:

This machine crashed into an unbootable state at 00:47:14.
I spun the disk down and back up again, and it booted ok.

				--carlf
18-Jan-83 10:00:28-EST,977;000000000000
Date: Tuesday, 18 January 1983, 09:55-EST
From: Daniel L. Weinreb <dlw at SCRC-TENEX>
Subject: redundancy in key-hitting
To: GAVAN at MIT-OZ, BUG-LISPM at MIT-OZ, bug-hardware at MIT-OZ
In-reply-to: The message of 17 Jan 83 11:59-EST from Gavan Duffy <GAVAN at MIT-OZ>

    Date: Monday, 17 January 1983, 11:59-EST
    From: Gavan Duffy <GAVAN at MIT-OZ>
    In Release 4.0, site configuration 9, on Lisp Machine One:

    In split screen mode, one screen is a lisp listener and one screen is an
    editor buffer, terminal-o needs to be hit twice in order to change the
    cursor screen.  This could be a problem with the keyboard, since the
    same behavior was noticed to happen with system-p.

It works fine for me.  Perhaps it's a hardware problem, as you suggest.
Why don't you try doing exactly the same thing on some other machine,
and see if the problem persists?  If it does, let us know again, and
describe in detail what you're doing.  Thanks.
18-Jan-83 13:17:36-EST,598;000000000000
Date: Tuesday, 18 January 1983, 13:16-EST
From: Daniel Weise <Daniel at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ
Cc: danny at MIT-OZ

In HARDWARE in Experimental Remote-File 22.0,
Experimental LMFILE-Remote 23.1, Experimental MIT-Specific 16.0,
Experimental System 91.22, Experimental ZMail 48.4, DAEDALUS 1.7,
Nodes 1.2, microcode 204, on Lisp Machine Two:

Cadr8 is losing more than ever.  It won't boot.  Its disk passes the
seek tests of (dcheck) but loses uterrly on reading and writing.  It's
label is also unreadable from cc.  Someone should have a serious
look at the disk, please.
18-Jan-83 19:14:01-EST,216;000000000000
Mail-From: DANIEL created at 18-Jan-83 19:10:17
Date: 18 Jan 1983 1910-EST
From: DANIEL at MIT-OZ
Subject: cadr2
To: bug-hardware at MIT-OZ, akr at MIT-OZ

Died.  Won't boot.  Can someone look at it?
-------
19-Jan-83 01:50:40-EST,1484;000000000000
Date: Wednesday, 19 January 1983, 01:47-EST
From: Patrick Sobalvarro <PGS at MIT-OZ>
Subject: brokenness
To: DCP at MIT-MC, bug-hardware at MIT-OZ
Cc: pgs at MIT-OZ, akr at MIT-OZ
In-reply-to: The message of 17 Jan 83 17:56-EST from DCP at MIT-MC

    Date: Monday, 17 January 1983  17:56-EST
    Sender: DCP @ MIT-OZ
    From: DCP @ MIT-MC
    To:   bug-hardware @ MIT-OZ
    cc:   pgs @ MIT-OZ, akr @ MIT-OZ
    Subject: brokenness

    The subnet 6 interface in oz-network-11 appears to be broken.
    Gren unplugged the interface cable from the transceiver at my
    request, and that seemed to cause the network to restabilize.
    You will probably find the ribbon cable still unplugged (unless
    somebody else fixes it before you get to it).

    Symptoms: LOST and CRC counts go up phenomonly (about 100 times
    that of packets in).  You might also check the physical
    characteristics of the cable near the transceiver, and check the
    transceiver itself.

I think (as you seem to) that we'd find it easiest to debug this by exchanging
the subnet 6 interface and seeing if that makes things win, because the cable
and the transceiver are not obviously losers, but the only interface I can come
up with just now is Pyggy's board, which was for a while the AI-CHAOS-11 subnet
6 board, and seemed to wedge subnet 1.

So we're going to have to wait a bit to put the OZ-NET-11 back on the net,
until we can come up with another interface.
19-Jan-83 19:56:31-EST,346;000000000000
Date: Wednesday, 19 January 1983, 19:56-EST
From: John Batali <Batali at MIT-OZ>
Subject: Cadr-2 flakiness
To: bug-hardware at MIT-OZ

I logged into cadr2 and it began to load my init file.  Before the file
was loaded I got the message: "You have used up the virtual memory!" and
the machine wedged.  My init file doesn't cons THAT much.
20-Jan-83 02:49:43-EST,1158;000000000000
Date: 20 January 1983 02:48-EST
From: Pandora B. Berman <CENT @ MIT-ML>
Subject: ai tape drive guesses
To: BUG-HARDWARE @ MIT-ML, MARTY @ MIT-ML

    Date: 17 January 1983 05:41-EST
    From: Pandora B. Berman <CENT @ MIT-ML>
    Subject: ai tape drive losing
    To: BUG-HARDWARE @ MIT-ML

    i have tried a couple times in the past few days to do an incremental dump
    on AI. each time, the tape drive finds the load point and apparently starts
    the dump correctly, but 4 blocks into .;@ NITS (the first normal-type file
    -- DUMP claims to dump the MFD and .;.FILE. (DIR) successfully) something
    goes wrong. DUMP claims to be sitting there waiting for more of the file,
    while the tape drive keeps going.....

Moon suggested that the drive is getting continuous write errors, and the
4 blocks is the available buffer length.

in concord with this theory, JPG observed that MC's tape drive had similar
symptoms last month.  DEC eventually decided there was a parity error
in the drive's internal core (or is this part of the controller?), so they
replaced the core, or part of it.

marty, could you look into this?
20-Jan-83 11:08:27-EST,312;000000000000
Mail-From: KWH created at 20-Jan-83 11:06:27
Date: 20 Jan 1983 1106-EST
From: KWH at MIT-OZ
Subject: Cadr-2 lossage.
To: bug-hardware at MIT-OZ


Editing the disk label on Cadr-2 wedges it into a state from which it
must be cold booted.  (This only happens after you try to change
something.)
-------
20-Jan-83 20:35:31-EST,529;000000000000
Date: Thursday, 20 January 1983, 20:35-EST
From: Carl Richard Feynman <CARLF at MIT-OZ>
Subject: cadr-2 disk
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in Release 4.0, Experimental DAEDALUS 56.0,
site configuration 6, on Lisp Machine Eight:

Alas, it appears that cadr-2 is busted again. It does not boot. When
I push the boot button on the machine, the disk drive seeks (I can 
tell this by feeling the drive) but the microcode counter stops at
00032, which I believe is the "can't load" location. Sigh.

				--carlf
20-Jan-83 20:41:12-EST,199;000000000000
Mail-From: CAL created at 20-Jan-83 20:39:44
Date: Thursday, 20 January 1983  20:39-EST
Sender: CAL @ MIT-OZ
From: Cliff Lasser <CAL @ MIT-MC>
To:   bug-hardware @ MIT-OZ


Cadr2 won't boot.
21-Jan-83 15:08:01-EST,405;000000000000
Date: Friday, 21 January 1983, 13:08-EST
From: Howard D. Trachtman <HDT at MIT-OZ>
To: Bug-hardware at MIT-OZ

Cadr-6's video monitor is displaying nothing but horizontal lines,
rendering the machine unusable.  I unplugged it.
The machine still talks to the chaosnet ok, but it won't listen to its keyboard.
There is a note from someone else, saying the same thing happened on Monday.
--Howard--
21-Jan-83 18:09:22-EST,412;000000000000
Date: Friday, 21 January 1983, 18:08-EST
From: jlmk at mc
Sender: ANONYMOUS at MIT-OZ
Subject: cadr15
To: bug-hardware at oz

Hi Guys!
	Hope you had a good vacation!  I managed to get cadr15 running.
The monitor seems a bit scrod though.   It is not scanning right.  First
it was scanning too much so a shadow appeared, not it is not scanning
much at all.  Have a good day.
					Regards,
					-Jan-
21-Jan-83 22:03:20-EST,119;000000000000
Date: Friday, 21 January 1983, 22:01-EST
From: Hdt@MIT-OZ
To: bug-hardware@MIT-OZ

Cadr-5 just crashed on gander.
22-Jan-83 16:16:51-EST,1199;000000000000
Date: Saturday, 22 January 1983, 16:15-EST
From: Daniel Weise <DANIEL at MIT-OZ>
Subject: Hardware or Software bug?
To: BUG-LISPM at MIT-OZ, bug-hardware at MIT-OZ

In Release 4.0, site configuration 6, on Lisp Machine Two:

I can't tell if this is a hardbug or software bug.  

Rel 4.0 will not run on this Lisp Machine.  After the most nominal
amount of consing it thinks it has used up all its virtual memory.  I
can reproduce this bug just by logging in and doing (load
"src:<circuit>defsystem").  (It chokes while trying to create an
array for the symbol table of a newly declared
package.)  I have tried rel 4.0's and mcr's from various cadr's doing
compare-bands all the way with no success.  I have varied the bands I
put the rel 4.0 and mcr on.  Nothing helps.  System 91 (as least 91's
loaded before this machine recent spat of problems) will boot and run
OK.  Doing (gc-status) to the out-of-memory-trap says there is lots of
room left.

Allow me to take this opportunity to flame at the jerk who
originally moved rel 4.0 to this machine without testing it
(and destroyed the only vanilla 91 on this machine in the process):
Go away, we don't need you.

Daniel
22-Jan-83 18:18:37-EST,511;000000000000
Mail-From: PGS created at 22-Jan-83 18:16:28
Date: Saturday, 22 January 1983  18:16-EST
Sender: PGS @ MIT-OZ
From: PGS @ MIT-MC
To:   Daniel Weise <DANIEL @ MIT-OZ>
Cc:   bug-hardware @ MIT-OZ, BUG-LISPM @ MIT-OZ
Subject: Hardware or Software bug?
In-reply-to: The message of 22 Jan 1983 16:15-EST from Daniel Weise <DANIEL>

Rel 4.0's running out of space immediately on CADR-2 is almost undoubtedly a
hardware bug.  There were bugs like this on CADR-TEST a couple of weeks ago;
it was running 91.
23-Jan-83 17:00:32-EST,248;000000000000
Mail-From: DANIEL created at 23-Jan-83 16:52:36
Date: Sunday, 23 January 1983  16:52-EST
Sender: DANIEL @ MIT-OZ
From: DANIEL @ MIT-MC
To:   bug-hardware @ MIT-OZ

The color board on cadr1 doesn't seem to be putting any video
signal out.  
25-Jan-83 00:29:03-EST,398;000000000000
Date: Tuesday, 25 January 1983, 00:28-EST
From: Patrick Sobalvarro <PGS at MIT-OZ>
Subject: gateway madness
To: bug-hardware at MIT-OZ

I stole Pyggy's Chaos board and stuck it in Toto to keep the MC-IO-11 from
losing its ass being the only (viable) subnet 1 <-> subnet 6 gateway around
(and the only route to OZ).  So OZ is now back on subnet 6.

We badly need more Unibus Chaos boards.
25-Jan-83 22:34:27-EST,471;000000000000
Mail-From: PGS created at 25-Jan-83 22:33:35
Date: Tuesday, 25 January 1983  22:33-EST
Sender: PGS @ MIT-OZ
From: PGS @ MIT-MC
To:   bug-hardware @ MIT-OZ

CADR-7 began generating losing video, the monitor began to screech (no sync
or sumpin), and finally it went black.  Hard to believe, but I think the
monitor died.  How do I know that CADR-7 was generating losing video, and the
monitor wasn't just frying?  I tried it on CADR-TEST's monitor.  Really ugly.
26-Jan-83 03:59:56-EST,1069;000000000000
Date: 26 January 1983  03:56-EST (Wednesday)
Sender: MARTY @ MIT-OZ
From: Martin David Connor <MARTY @ MIT-MC>
To:   Pandora B. Berman <CENT @ MIT-ML>
Cc:   BUG-HARDWARE @ MIT-ML
Subject: AI Tape Drive
In-reply-to: The message of 20 Jan 1983  02:48-EST from Pandora B. Berman <CENT at MIT-ML>

    Date: Thursday, 20 January 1983  02:48-EST
    From: Pandora B. Berman <CENT at MIT-ML>
    To:   BUG-HARDWARE at MIT-ML, MARTY at MIT-ML
    Re:   ai tape drive guesses
	...

    marty, could you look into this?

AI tape drive is back.

-  The EOT (end of tape) senser was loose, and can swing into a bad
   angle so that tapes cannot be loaded. I tightened it after finding 
   a suitable position.

-  Cleaned the head.

-  Removed a silly red wire that wasn't connected to anything but
   which may have been touching random pins when the door was closed.

After this I was able to dump and read back a directory, and to list a
random incremental tape (incr. 238).

So, give it a try, we'll see how long it lasts this time.

Marty;

26-Jan-83 05:53:09-EST,1217;000000000000
Mail-From: LEVITT created at 26-Jan-83 05:50:46
Date: Wednesday, 26 January 1983  05:50-EST
Sender: LEVITT @ MIT-OZ
From: LEVITT @ MIT-MC
To:   bug-hardware @ MIT-OZ
Subject: CADR-9 has only 192K

This bug report is a little late: CSTACY and I took a closer look at
CADR-9 the other night, and discovered that althought 4 memory boards
were visible, one of them (MW#34 as I recall) was not actually plugged
into the cadr cage.  Combined with the delay in upgrading it to 384K,
this left it with an "unusable" 192K.  Booting with this board in (at
address 0) produced peculiar behavior: the machine appeared to halt at
alternating locations in low mem (all around location 40), "halting"
repeatedly at intervals of around 1Hz, without a discernible pattern.
(We were unable to reproduce this exact behavior, or to boot with that
board without halting,, but it might be a clue.)  We returned the bad
board to 936 with a note attached.

We began a project to snarf good memory boards out of broken CADR-18,
but apparently this has already been done!  Someone with more
knowledge of memory board resources should find 1 or 2 good memory
boards to put in CADR-9, and maximize our "usable" machines.
26-Jan-83 08:48:17-EST,557;000000000000
Mail-From: AKR created at 26-Jan-83 08:45:55
Date: Wednesday, 26 January 1983  08:45-EST
Sender: AKR @ MIT-OZ
From: AKR @ MIT-MC
To:   LEVITT @ MIT-OZ
Cc:   bug-hardware @ MIT-OZ
Subject: CADR-9 has only 192K
In-reply-to: The message of 26 Jan 1983  05:50-EST from LEVITT


This bug report is indeed a little late since cadr-9 has 320K since tuesday
morning.  Cadr-9's problem had nothing to do with memory boards so swapping
memory boards around was a pure waste of time.  The problem was a bad contact
in the backplane which has been fixed.
26-Jan-83 08:58:14-EST,272;000000000000
Mail-From: AKR created at 26-Jan-83 08:55:24
Date: Wednesday, 26 January 1983  08:55-EST
Sender: AKR @ MIT-OZ
From: AKR @ MIT-MC
To:   PGS @ MIT-OZ
Cc:   bug-hardware @ MIT-OZ
Subject: cadr-7
In-reply-to: The message of 25 Jan 1983  22:33-EST from PGS

Fixed.

27-Jan-83 04:32:10-EST,159;000000000000
Date: 27 January 1983 04:31-EST
From: Pandora B. Berman <CENT @ MIT-ML>
Subject: AI Tape Drive
To: MARTY @ MIT-MC
cc: BUG-HARDWARE @ MIT-ML

it works!!
27-Jan-83 12:35:00-EST,1193;000000000000
Date: Thursday, 27 January 1983, 12:31-EST
From: Richard M. Stallman <RMS at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ

In Remote-File 22.0, LMFILE-Remote 23.1, MIT-Specific 16.0, System 91.35,
ZMail 48.6, microcode 204, gc @18, on Lisp Machine Two:


Insert your description of the circumstances, and how often the problem occurs:



Machine being debugged is MIT-LISPM-8.
Disk error: Memory-Parity  Transfer-Aborted
  disk address: UNIT 0 CYLINDER 115 HEAD 5 SECTOR 16 
  last memory address touched by disk = 47776
Contents of disk error log in debugee's main memory 600-640:

Command 11 (Write) 
CCW-list pointer 700 (low 16 bits)
Disk address: unit 0, cylinder 115, head 5, block 16 (0 77 5 14 decimal)
Memory address: 47776 (type bits 0)
Status: 1622020011  Read-compare  Mem-parity  Transfer-Aborted (or wr. ovr.)  Interrupt  Idle

Command 11 (Write) 
CCW-list pointer 700 (low 16 bits)
Disk address: unit 0, cylinder 53, head 10, block 5 (0 43 8 5 decimal)
Memory address: 41176 (type bits 0)
Status: 562020011  Internal-parity  Read-compare  Mem-parity  Transfer-Aborted (or wr. ovr.)
          Interrupt  Idle
Microcode halted via ILLOP from FATAL-DISK-ERROR
27-Jan-83 15:30:36-EST,457;000000000000
Mail-From: CARLF created at 27-Jan-83 15:27:06
Date: Thursday, 27 January 1983  15:27-EST
Sender: CARLF @ MIT-OZ
From: CARLF @ MIT-MC
To:   bug-hardware @ MIT-OZ

At 3:05 cadr-8 went into a state where it responded to nothing,
not even cold-boot. I tried disconnecting and reconnecting the keyboard,
but this didn't do anything. I didn't do anything strange to the machine;
I didn't even touch it for 30 minutes before the crash.


				--carlf
27-Jan-83 16:11:48-EST,206;000000000000
Mail-From: DANIEL created at 27-Jan-83 16:07:20
Date: 27 Jan 1983 1607-EST
From: DANIEL at MIT-OZ
To: bug-hardware at MIT-OZ

Cadr8 is dead.  My puny attempts to get it to boot
have failed.
-------
30-Jan-83 00:58:01-EST,563;000000000000
Date: Sunday, 30 January 1983, 00:54-EST
From: rlh at MIT-OZ
To: BUG-HARDWARE at MIT-OZ
Cc: rlh at MIT-OZ

In HARDWARE in Remote-File 22.0, LMFILE-Remote 23.1, MIT-Specific 16.0,
System 91.35, ZMail 48.6, microcode 216,  , on Marvin:

The keyboard currently attached to cadr-13, which last week was attached
to cadr-14 just opposite and was having the same sort of trouble,
bounces its abort and possibly break keys, has a gummed up resume key,
and its left ctrl key seems to send garbage such as bouncing and "hold output"
(or maybe "stop output").
31-Jan-83 13:37:18-EST,719;000000000000
Mail-From: DICK created at 31-Jan-83 13:24:27
Date: Monday, 31 January 1983  13:24-EST
Sender: DICK @ MIT-OZ
From: Dick @ MIT-MC
To:   bug-hardware @ MIT-OZ
Subject: broken ambassador


The ambassador terminal number 0070489 in room 820-a is broken.  You
can type along on it just fine and suddenly you hit a character and
the screen goes blank and it starts beeping.  If you power cycle it, it
comes back to life (having sent severl random characters) and is fine
until it flips out again.  This problem just started up a few days
ago.  It used to happen just a couple of times a day and now happens
every 2-3 minutes.  I tried swapping keyboards with another terminal
and that did no good.

			Dick
31-Jan-83 15:51:59-EST,325;000000000000
Date: 31 January 1983 15:47-EST
From: Ken Church <KWC @ MIT-ML>
To: BUG-CHAOS @ MIT-ML, BUG-HARDWARE @ MIT-ML
cc: srwg @ MIT-SPEECH

There is some electrical tape on the chaos net connection to cadr-12 and
cadr-26 that seems to be melting.  Is there any harm that could result by
replacing it with fiberglass tape?

 1-Feb-83 05:00:42-EST,678;000000000000
Date: 1 February 1983 04:58 EST
From: Pandora B. Berman <CENT @ MIT-ML>
Subject: hub lossage?
To: PGA @ MIT-ML
cc: BUG-HARDWARE @ MIT-ML

i was emacsing away at ML on my office vt52 (which is connected to
ne43-8hub) when all of a sudden it went catatonic. i think i may have hit
the break key a couple times accidently just before this happened, but am
not sure.  booting the hub did not help, nor did turning the terminal off
and on again. i don't know whether this is just my terminal losing, or its
connection to the hub, or the whole hub. i logged in on the seventh floor
and found my hactrn had become detached. ML appears to have been fine
all through this.
 1-Feb-83 05:10:40-EST,367;000000000000
Date: 1 February 1983 05:09 EST
From: Pandora B. Berman <cent @ MIT-ML>
Sender: ___010 @ MIT-ML
Subject: back again
To: PGA @ MIT-ML
cc: BUG-HARDWARE @ MIT-ML

gee, my terminal seems to be well (at least, as well as it ever is)
now. no indication that anyone booted the hub after i did, but
that may have happened. maybe it just wanted some time to itself.
 2-Feb-83 00:44:31-EST,417;000000000000
Mail-From: KMP created at  2-Feb-83 00:42:09
Date:  2 Feb 1983 0042-EST
From: KMP at MIT-OZ
Subject: CADR-22 memory board missing
To: bug-hardware at MIT-OZ

One of the memory boards for cadr-22 has been missing for about a week.
No one contacted us when they took it or when I sent a system message asking
if anyone knew what had happened. Have you heard anything about any board
transfers?
-kmp
-------
 2-Feb-83 07:49:17-EST,338;000000000000
Date: Wednesday, 2 February 1983, 07:47-EST
From: Gavan Duffy <GAVAN at MIT-OZ>
Subject: cadr-2 wedges out
To: BUG-HARDWARE at MIT-OZ

The disk on cadr-2 appears to be flaky.  It wedged shortly after loading
patches.  No warm-boot, no cold-boot.  After power-cycling the disk it 
warm-booted, but wedged again shortly thereafter.
 2-Feb-83 22:49:14-EST,485;000000000000
Date: Wednesday, 2 February 1983, 22:48-EST
From: Howard D. Trachtman <Hdt at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in Remote-File 22.0, LMFILE-Remote 23.1, MIT-Specific 16.0,
System 91.37, ZMail 48.6, microcode 204,  , on Lisp Machine Five:

This machine crashed repeatedly, requiring a warm boot at times, at intervals
of about 15 minutes.

Frequently it crashes when attempting to do something with the chaosnet, though
once it died while I was simply typing.
 2-Feb-83 22:57:41-EST,453;000000000000
Date: Wednesday, 2 February 1983, 22:53-EST
From: Howard D. Trachtman <Hdt at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in Remote-File 22.0, LMFILE-Remote 23.1, MIT-Specific 16.0,
System 91.37, ZMail 48.6, microcode 204,  , on Lisp Machine Five:

I might add that it has now died three times in a row at reading 98% 
src:<hdt.lisp>safe.lisp.2

Previously zmail lost at 0% of a file, and it also died while trying to do
a terminal-1-f.
 3-Feb-83 15:53:45-EST,523;000000000000
Date: Thursday, 3 February 1983, 15:44-EST
From: Daniel Weise <Daniel at MIT-OZ>
To: bug-hardware at MIT-OZ
Cc: kahle at MIT-OZ, danny at MIT-OZ, taft at MIT-OZ

cadr8 seems to be having main memory parity errors.  Once yesterday
and just now today it died.  continuiing from (cc:cc) yielded the
message: there was a main memory parity error.  It was in board
3 bank 3 address 755462.  bits 1,2,4,5,9,10,14,16-19,21,22 were other
than they should be.  This is the same thing that happened last 
night.

Daniel
 3-Feb-83 16:23:20-EST,199;000000000000
Date: 3 February 1983 14:22 EST
From: Richard Mark Soley <SOLEY @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC

CADR15 (room 800f) crashes consistently during cold (and/or warm) boot.

	-- Richard Soley
 4-Feb-83 11:07:21-EST,852;000000000000
Mail-From: RICH created at  4-Feb-83 11:04:29
Date: 4 February 1983  11:04-EST (Friday)
Sender: RICH @ MIT-OZ
From: Charles Rich <RICH @ MIT-MC>
To:   pa-cadr22 @ MIT-OZ
CC:   NIS @ MIT-OZ, NGL @ MIT-OZ, POGGIO @ MIT-OZ, Welg @ MIT-OZ,
      Bug-Hardware @ MIT-OZ
Subject: Missing Memory Board Found on CADR3

Memory Board #68, which was removed from CADR22 sometime in the past
two weeks has been located in CADR3.  CADR3 currently has 6 boards in
it.  According to Welg, the usual memory complement of CADR3 is 4
boards.  Unless there is some objection, we will shortly remove
Board #68 from CADR3 and replace it in CADR22.

		-Chuck.

P.S. If there was some reason why this board was moved to CADR3
it would have been nice for the person who did it to tell us,
so we wouldn't have had to waste this time wondering what happened.
 5-Feb-83 13:27:45-EST,296;000000000000
Mail-From: DPH created at  5-Feb-83 13:24:41
Date:  5 Feb 1983 1324-EST
From: DPH at MIT-OZ
Subject: cadr-2
To: bug-hardware at MIT-OZ

cadr-2's disk is at the point where it won't stay spun up for more
than a few minutes.  It loses "ready" even though it seems to be
spinning.
-------
 6-Feb-83 16:38:32-EST,349;000000000000
Mail-From: AKR created at  6-Feb-83 16:31:51
Date: Sunday, 6 February 1983  16:31-EST
Sender: AKR @ MIT-OZ
From: AKR @ MIT-MC
To:   DPH @ MIT-OZ
Cc:   bug-hardware @ MIT-OZ
Subject: cadr-2
In-reply-to: The message of 5 Feb 1983  13:24-EST from DPH


	Cadr2 had a bad memory board (# 5), which pulled out.  I was then
unable to crash it.
 7-Feb-83 22:35:17-EST,199;000000000000
Date: Monday, 7 February 1983, 22:16-EST
From: Richard M. Stallman <RMS at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ

CADR-18 got a disk error on main memory parity at 1321603.
I can't tell what bit.
 7-Feb-83 22:47:40-EST,188;000000000000
Mail-From: RMS created at  7-Feb-83 22:43:32
Date:  7 Feb 1983 2243-EST
From: RMS at MIT-OZ
Subject: I replaced chip 21F in board 5 on cadr18.
To: bug-hardware at MIT-OZ


-------
 8-Feb-83 05:53:31-EST,191;000000000000
Date: Tuesday, 8 February 1983, 05:50-EST
From: Richard M. Stallman <RMS at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ

CADR 1 seems to be crashing a lot while just sitting there after booting.
10-Feb-83 18:22:09-EST,326;000000000000
Date: Thursday, 10 February 1983, 18:20-EST
From: Robert P. Krajewski <RpK at MIT-OZ>
Subject: The <Resume> key
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in Remote-File 22.0, LMFILE-Remote 23.1, MIT-Specific 16.0,
System 91.40, ZMail 48.7, microcode 204, gc @18,
on Lisp Machine Three:

doesn't work on this keyboard.
14-Feb-83 04:47:27-EST,387;000000000000
Date: Monday, 14 February 1983, 04:45-EST
From: Richard M. Stallman <RMS at MIT-OZ>
Subject: cadr-18 keyboard
To: bug-hardware at MIT-OZ

Frequently the mouse on cadr-18 will not move vertically.

This is not the fault of the mouse itself.  It has happened
with different mice.

Sometimes vertical motion does work for a while.
Then it stops again.

It's losing right now.
17-Feb-83 17:34:23-EST,282;000000000000
Date: Thursday, 17 February 1983, 17:25-EST
From: brewster kahle <kahle at MIT-OZ>
To: bug-hardware at MIT-OZ

Cadr-2's disk is still flakey.

The "cadr-freeze" that our president talks
so much about is still with us.

sigh

Please do something about it.

-brewster

18-Feb-83 11:06:55-EST,270;000000000000
Date: Friday, 18 February 1983, 06:31-EST
From:  <RMS at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ

I think that cadr18 may be getting some disk errors while cold booting
off band 8.  It sometimes seems to pause a long time and then
continue.  Once it died in mid boot.
19-Feb-83 20:41:22-EST,267;000000000000
Date: Saturday, 19 February 1983, 20:35-EST
From: Patrick Sobalvarro <PGS at MIT-OZ>
To: bug-hardware at MIT-OZ

Enabling unibus interrupts for serial i/o on CADR-25 causes the machine to
wedge.  Looks like interrupts come in constantly.  This is not software.
20-Feb-83 22:31:26-EST,353;000000000000
Mail-From: RPK created at 20-Feb-83 22:30:02
Date: 20 February 1983  22:29-EST (Sunday)
Subject: AI disk unit
To:   Bug-Hardware @ MIT-OZ
Sender: RPK @ MIT-OZ
From: CStacy @ MIT-OZ


AI's disk unit 6 makes a loud whining noise.  This is probably from the air
filter fan or something; it has nothing todo with the drive being spun up.

Chris
20-Feb-83 22:52:22-EST,764;000000000000
Date: Sunday, 20 February 1983, 22:48-EST
From: Gavan Duffy <GAVAN at MIT-OZ>
Subject: AP2 is in a losing state.
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in Release 4.1, site configuration 14, on Lisp Machine Apiary-1:

AP2 is in a losing state.

Machine being debugged is MIT-APIARY-2.
Bus-interface errors since last reset:
  Xbus non-existent memory or device
  Xbus data parity error
  UnibusXbus map error: invalid or write-protect
Disk error: No-Select  Off-line  Off-Cylinder
  disk address: UNIT 0 CYLINDER 0 HEAD 0 SECTOR 0 
  last memory address touched by disk = 16137562
Contents of disk error log in debugee's main memory 600-640:
Halted at location 556 in the microcode bootstrap PROM.
Reason=Waiting for disk error bits to clear
21-Feb-83 02:27:00-EST,206;000000000000
Date: 21 February 1983 02:22 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC

Someone was hacking on LM1 when the screen went blank.
I looked and something on CADR-1 fried.
21-Feb-83 10:25:34-EST,376;000000000000
Mail-From: BRD created at 21-Feb-83 10:23:30
Date: 21 February 1983  10:23-EST (Monday)
From: Bruce R. Donald <BRD @ MIT-OZ>
To:   Jfc @ MIT-OZ
cc:   bug-hardware @ MIT-OZ
Subject:   monitor on Cadr-31
Reply-To: BRD@MIT-OZ@MIT-MC


John, if you have a minute could you show me how to twaddle the
monitor on cadr-31 which is losing badly after the powerdown?
Bruce
22-Feb-83 07:12:52-EST,683;000000000000
Date: Tuesday, 22 February 1983, 07:08-EST
From: Andrew Y. Chu <aychu at MIT-XX>
Subject: cadr-5 disk error
To: BUG-HARDWARE at MIT-OZ


This happened just once.

Machine being debugged is MIT-LISPM-5.
Disk error: ECC-Soft  Transfer-Aborted
  disk address: UNIT 0 CYLINDER 113 HEAD 15 SECTOR 14 
  last memory address touched by disk = 1145377
Contents of disk error log in debugee's main memory 600-640:

Command 0 (Read) 
CCW-list pointer 740 (low 16 bits)
Disk address: unit 0, cylinder 113, head 15, block 14 (0 75 13 12 decimal)
Memory address: 1145377 (type bits 0)
Status: 2020120011  Read-compare  ECC-Soft  Transfer-Aborted (or wr. ovr.)  Interrupt  Idle
22-Feb-83 17:20:58-EST,183;000000000000
Date: Tuesday, 22 February 1983, 17:14-EST
From: Patrick Sobalvarro <PGS at MIT-OZ>
To: bug-hardware at MIT-OZ

I'm calling the DEC losers to fix the AI-CHAOS-11's power supply.
22-Feb-83 18:13:22-EST,313;000000000000
Mail-From: BRD created at 22-Feb-83 18:07:57
Date: 22 February 1983  18:07-EST (Tuesday)
From: Bruce R. Donald <BRD @ MIT-OZ>
To:   bug-hardware @ MIT-OZ
Subject:   L:ISMP-3
Reply-To: BRD@MIT-OZ@MIT-MC


Not only does the <resume> key not work, but now <abort> does not respond,
and you must C-M-abort.
23-Feb-83 03:13:33-EST,426;000000000000
Date: Wednesday, 23 February 1983, 03:12-EST
From: Richard M. Stallman <RMS at MIT-OZ>
Subject: bad spot in PAGE partition in cadr-5 disk
To: bug-hardware at MIT-OZ

I sent a bug report yesterday while logged in as aychu.
I find that I get a disk error in this session as well
from the same operation.  I suspect therefore that the
disk block identified in the previous message is a
bad block in the PAGE partition.
23-Feb-83 15:23:12-EST,448;000000000000
Mail-From: PGS created at 23-Feb-83 14:54:36
Date: Wednesday, 23 February 1983  14:54-EST
Sender: PGS @ MIT-OZ
From: PGS @ MIT-MC
To:   bug-hardware @ MIT-OZ
Subject: bad spot in PAGE partition in cadr-5 disk
In-reply-to: Msg of 23 Feb 1983 03:12-EST from Richard M. Stallman <RMS>

We should replace this platter with a new one as soon as possible, unless we
can verify that formatting it is sufficient.  I've run into this lossage too.
23-Feb-83 15:30:01-EST,705;000000000000
Mail-From: PGS created at 23-Feb-83 15:28:05
Date: Wednesday, 23 February 1983  15:28-EST
Sender: PGS @ MIT-OZ
From: PGS @ MIT-MC
To:   bug-hardware @ MIT-OZ
Subject: bad spot in PAGE partition in cadr-5 disk
In-reply-to: Msg of 23 Feb 1983  14:54-EST from PGS

    Date: Wednesday, 23 February 1983  14:54-EST
    From: PGS
    Sender: PGS
    To:   bug-hardware
    Re:   bad spot in PAGE partition in cadr-5 disk

    We should replace this platter with a new one as soon as possible, unless
    we can verify that formatting it is sufficient.  I've run into this
    lossage too.

I mean, we should replace the disk.  I didn't realize how silly this sounds
when I first sent it...
24-Feb-83 02:41:43-EST,411;000000000000
Mail-From: PGS created at 24-Feb-83 02:37:58
Date: Thursday, 24 February 1983  02:37-EST
Sender: PGS @ MIT-OZ
From: PGS @ MIT-MC
To:   bug-hardware @ MIT-OZ

AI-CHAOS-11 temporarily swapped for robotics' gt40; dec will fix latter
tomorrow.  I put robotics' 16Kx16 core in the old ai-chaos-11; if the dacs in
it work after we get the power supply fixed, we'll just leave it there as the
robotics gt40.
24-Feb-83 14:39:53-EST,888;000000000000
Mail-From: KMP created at 24-Feb-83 14:34:53
Date: 24 Feb 1983 1434-EST
From: KMP at MIT-OZ
Subject: CADR-22's missing memory board
To: RICH at MIT-OZ, ZVONA at MIT-OZ
cc: NIS at MIT-OZ, NGL at MIT-OZ, POGGIO at MIT-OZ, WELG at MIT-OZ,
    BUG-HARDWARE at MIT-OZ, ALR at MIT-OZ

CADR-3 wasn't being used this afternoon so I recovered our missing memory
board (board #68) from it. CADR-22 is now running its full 512K.

By the way, when I went up to take down CADR-3, I noticed that it was in
a wedged state in software. Typing any character (including Terminal and
System) just beeped. This is probably a bug in the software for the default
band. I mention it only because I didn't want anyone who walks in later
expecting things to work to assume my swapping the boards is what broke it.
That condition was in effect prior to when I took the board out.

-kmp
-------
24-Feb-83 16:07:19-EST,1215;000000000000
Date: Thursday, 24 February 1983, 16:04-EST
From: Patrick Sobalvarro <PGS at MIT-OZ>
Subject: CADR-3's keyboard beeping
To: KMP at MIT-OZ, RICH at MIT-OZ, ZVONA at MIT-OZ
CC: NIS at MIT-OZ, NGL at MIT-OZ, POGGIO at MIT-OZ, WELG at MIT-OZ,
    BUG-HARDWARE at MIT-OZ, ALR at MIT-OZ
In-reply-to: The message of 24 Feb 83 14:34-EST from KMP at MIT-OZ

    Date: 24 Feb 1983 1434-EST
    From: KMP at MIT-OZ
    Subject: CADR-22's missing memory board

    ...
    By the way, when I went up to take down CADR-3, I noticed that it was in
    a wedged state in software. Typing any character (including Terminal and
    System) just beeped. This is probably a bug in the software for the default
    band...

You are describing a wedged keyboard.  It was probably sending characters to
the machine that don't make any sense to a Lisp listener.  You can boot a
keyboard by pressing the boot button underneath it.  I would bet that you could
have figured this out for yourself, but didn't think of it because you were
more interested in saying silly things about RMS's software.  I'm pissed off
because you wasted my time this way, by causing me to go over to CADR-3 to
check out your bug report.
24-Feb-83 16:23:23-EST,456;000000000000
Date: Thursday, 24 February 1983, 16:09-EST
From: Patrick Sobalvarro <PGS at MIT-OZ>
Subject: gt40
To: bug-hardware at MIT-OZ

The robotics GT40 (formerly AI-CHAOS-11) is back.  The dacs were fine, but the
serial board seemed to be set up for 1200 baud or something.  The bill for
replacing a power supply?  $474.  $300 for a power supply, and $174 for 2 hours
of this loser trying to figure things out, after I told him it was the power
supply.
24-Feb-83 20:30:42-EST,840;000000000000
Mail-From: SAUND created at 24-Feb-83 20:27:10
Date: 24 Feb 1983 2027-EST
From: SAUND at MIT-OZ
Subject: broken lisp machine
To: bug-lispm at MIT-OZ
cc: bug-hardware at MIT-OZ

One of the lisp machines in the 3rd floor robotics lounge is broken.
This must be either CADR-19 or CADR-31.  It cold boots and appears
normal, but halts soon after it is made to do work.  Typically it will
halt upon trying to read a file into an editor buffer.  Warm booting 
gives an error message which resembles "disk read error unit foo cyl bar
surface meef".        At the time the machine was running the band
which had system 93.11, but I see that somebody is playing with the 
machine and changing the current band even as I write this so I don't
know what state the machine will be in when you repairmen get to it.
-Eric Saund
-------
24-Feb-83 22:00:52-EST,1553;000000000000
Mail-From: JFC created at 24-Feb-83 21:57:27
Date: 24 Feb 1983 2157-EST
From: JFC at MIT-OZ
Subject: broken lispm
To: bug-lispm at MIT-OZ
cc: bug-hardware at MIT-OZ, saund at MIT-OZ

	24-Feb-83 20:30:43-EST,840;000000000001
	Mail-From: SAUND created at 24-Feb-83 20:27:10
	Date: 24 Feb 1983 2027-EST
	From: SAUND at MIT-OZ
	Subject: broken lisp machine
	To: bug-lispm at MIT-OZ
	cc: bug-hardware at MIT-OZ
	
	One of the lisp machines in the 3rd floor robotics lounge is broken.
	This must be either CADR-19 or CADR-31.  It cold boots and appears
	normal, but halts soon after it is made to do work.  Typically it will
	halt upon trying to read a file into an editor buffer.  Warm booting 
	gives an error message which resembles "disk read error unit foo cyl bar
	surface meef".        At the time the machine was running the band
	which had system 93.11, but I see that somebody is playing with the 
	machine and changing the current band even as I write this so I don't
	know what state the machine will be in when you repairmen get to it.
	-Eric Saund
	-------
I think this was caused by the garbage collector being left on by whoever used the machine
before Eric. Apparently the garbage collector doesnt work in system 93, or should I say
microcode 226. The band that didnt work on cadr31 was 93.11,gc@2 mcr226. I tried running
the 93.10,GC@3 band from cadr18 on cadr30 but that also illops shortly after the
garbage collector is turned on. The illops were to locations 5310 and 5315 in the scavenger. 
-JfC
-------
25-Feb-83 13:50:54-EST,2101;000000000000
Date: Friday, 25 February 1983, 13:39-EST
From: Carl Hewitt <Hewitt at MIT-OZ>
Subject: flakey disk?
To: BUG-HARDWARE at MIT-MC, bug-apiary-hardware at MIT-MC

In HARDWARE in Release 4.1, System 222.171, site configuration 14, on Lisp Machine Apiary-2:

cc-disk-analyze gives read-compare-difference
unit 0 cylinder 1314 head 5 sector 14

Machine being debugged is MIT-APIARY-1.
Bus-interface errors since last reset:
  Unibus non-existent device
The running microcode is version 979.
This program doesn't understand why the machine stopped (not ILLOP).
The running microcode is version 979.
Micro PC History (OPC's), oldest first:
   22517   (DISK-COMPLETION-ERROR 3)
   22520   (DISK-COMPLETION-ERROR 4)
   22563   FATAL-DISK-ERROR
   22564   (FATAL-DISK-ERROR 1)
   00361   ILLOP
   00362   TRAP-NO-VMA
   22564   (FATAL-DISK-ERROR 1)
   22565   LOG-DISK-ERROR
Backtrace of microcode subroutine stack:
    7  023165   CALL-INSTANCE-METHOD
    6  022445   QIBRN
    5  022335   (XSBOXSZ 4)
    4  021531   RCONS-MAYBE-EXTEND-REGION-1
    3  021617   (MAKE-REGION-2 4)
    2  020721   LCONS-N
    1  004755   (QLENTR 3)
    0  040170   QMLP
Microcode state flags: microcode interrupt
Current stack group is: <Stack Group ZMACS-WINDOWS>
Current process is: #<DTP-INSTANCE 2635672>"ZMACS-WINDOWS"
Complete backtrace follows: (type Space to stop)

11115773 #<DTP-FEF-POINTER BP-CHAR 10111013>[0] ("" 0 NORMAL)
11115756 #<DTP-FEF-POINTER SET-BLINKER-SIZE 10074562>[60] ("" 0 NORMAL) #<WINDOW #<DTP-INSTANCE 35616515> 2015711> #<DTP-INSTANCE 20741460> 0 0 #<DTP-INSTANCE 20523175>
11115675 #<DTP-FEF-POINTER REDISPLAY 10072013>[2050] #<WINDOW #<DTP-INSTANCE 35616515> 2015711>
11115665 #<DTP-FEF-POINTER REDISPLAY-ALL-WINDOWS 10071427>[102]
11115550 #<DTP-FEF-POINTER (METHOD EDITOR EDIT) 10066726>[337] EDIT
11115537 #<DTP-FEF-POINTER (METHOD TOP-LEVEL-EDITOR COMBINED EDIT) 7354171>[102] EDIT
11115533 #<DTP-FEF-POINTER ZMACS-WINDOW-TOP-LEVEL 7265341>[52]
11115463 #<DTP-FEF-POINTER PROCESS-TOP-LEVEL 10452646>[125] NIL

BOUND-LOC-POINTER-NOT-LOCATIVE 
25-Feb-83 15:18:13-EST,788;000000000000
Return-path: <MOON@SCRC-TENEX>
Date: Friday, 25 February 1983  15:15-EST
From: MOON at SCRC-TENEX
To:   Carl Hewitt <Hewitt at MIT-OZ>
Cc:   bug-apiary-hardware at MIT-MC, BUG-HARDWARE at MIT-MC
Subject: flakey disk?
In-reply-to: The message of 25 Feb 1983 13:39-EST from Carl Hewitt <Hewitt at MIT-OZ>

I think you bashed the state of AP1 before sending the bug report,
perhaps by typing control-S twice.  CC is really a p.o.s.
read-compare-difference is a bit that lights up randomly and is
not an error unless you are doing read-compares, which are not
turned on by default (%disk-switches can turn them on; it's in
the system 78 release notes or some obscure place like that).
So the original disk error status got cleared somehow before
you did that cc-disk-analyze.
26-Feb-83 21:41:44-EST,695;000000000000
Date: 26 Feb 1983 2131-EST
From: SAUND at MIT-OZ
Subject: dovering from a lisp machine
To: bug-hardware at MIT-MC
cc: philip at MIT-OZ

Yesterday I could load the file, oz:ps:<philip.general>dover, into a lisp machine and
send pictures from the screen.  Today all I can get is the error message, 
[cannot connect to the dover at the moment].   Though this message occurs occasionally
in normal operation, I think that there may be a more general problem now since
both the dover and spooler are up and working and are not busy.  I understand some
work was done on the chaosnet today.   I think things can be sent directly to the
dover over the chaosnet as of this writing.
-------
27-Feb-83 17:09:55-EST,925;000000000000
Date: Sunday, 27 February 1983, 17:02-EST
From: brewster kahle <kahle at MIT-OZ>
Subject: cadr-2's color monitor
To: bug-hardware at MIT-OZ

The color monitor intermittintly stops working.
Symptoms: The monitor blinks out after some random period of
time.  
          Power cycling it brings it back for only a second or two
and then blinks out again.
          The Horizontal sweep is on for that on period as evidenced
by the hiss, and then it shuts down.
          After repeating this a few times it doesn't come back at all.
          There seems to be nbo excess of heat on the board or
anything wrong with the fuse or wire connections.

          This same problem occured on Cadr-8's color monitor last week
but was pulled back to life by a long power off cycle.

Any clues?
Is there anyone that takes care of these things?
Who has hacked them before, so I might get some advice?

-brewster

27-Feb-83 17:29:07-EST,351;000000000000
Return-path: <PGS@MIT-OZ>
Date: Sunday, 27 February 1983, 17:24-EST
From: Patrick Sobalvarro <PGS@MIT-OZ>
Subject: cadr-2's color monitor
To: kahle@MIT-OZ, bug-hardware@MIT-OZ
In-reply-to: The message of 27 Feb 83 17:02-EST from brewster kahle <kahle at MIT-OZ>

Talk to TC about CADR-2's monitor.  He arranges getting things like that fixed.
27-Feb-83 19:36:22-EST,1092;000000000000
Return-path: <PGS@MIT-OZ>
Date: Sunday, 27 February 1983, 19:33-EST
From: Patrick Sobalvarro <PGS@MIT-OZ>
Subject: chaosnet status
To: bug-hardware@MIT-OZ

Just saying all this so the next person who hacks it can benefit from what
little I've found out.  When I came in this afternoon, no one was able to reach
OZ from the terminal concentrators.  I went up to the ninth floor and found
that OZ's sn 6 transceiver was disconnected.  Marty later told me that he'd
told Gren to do this to see if it improved things.  It hadn't; in fact, the
trouble seemed to be on sn 1, so I reconnected it, and people were once again
able to reach OZ from sn 6 pretty much normally.

Hostat on a Lisp Machine showed no main campus hosts, and ridiculous numbers of
CRC errors on subnet 1, looks like as many errors as packets.  No significant
number of aborts.  Someone booted the AI-CHAOS-11 recently and it has not been
able to download (it downloads over sn 1).  I'll try starting it assuming core
hasn't been bashed.  I'll work on finding the problem on sn 1 for a little
while longer.
27-Feb-83 20:13:14-EST,397;000000000000
Return-path: <PGS@MIT-OZ>
Mail-From: PGS created at 27-Feb-83 20:08:28
Date: 27 Feb 1983 2008-EST
From: PGS@MIT-OZ
Subject: chaosnet status
To: bug-hardware@MIT-OZ

Dan Huttenlocher and I terminated sn 1 in the basement and the CRC errors
stopped.  The AI-CHAOS-11 was finally able to download.  Things in the
building are back to normal; we just can't talk to the main campus.
-------
27-Feb-83 22:55:57-EST,1970;000000000000
Return-path: <DPH@MIT-OZ>
Mail-From: DPH created at 27-Feb-83 22:52:54
Date: Sunday, 27 February 1983  22:52-EST
Sender: DPH @ MIT-OZ
From: DPH @ MIT-MC
To:   Patrick Sobalvarro <PGS @ MIT-OZ>
Cc:   bug-hardware @ MIT-OZ
Subject: chaosnet status
In-reply-to: Msg of 27 Feb 1983 19:33-EST from Patrick Sobalvarro <PGS>

    Date: Sunday, 27 February 1983, 19:33-EST
    From: Patrick Sobalvarro <PGS>
    To:   bug-hardware
    Re:   chaosnet status
    Return-path: <PGS@MIT-OZ>

 Just saying all this so the next person who hacks it can benefit from what
 little I've found out.  When I came in this afternoon, no one was able to reach
 OZ from the terminal concentrators.  I went up to the ninth floor and found
 that OZ's sn 6 transceiver was disconnected.  Marty later told me that he'd
 told Gren to do this to see if it improved things.  It hadn't; in fact, the
 trouble seemed to be on sn 1, so I reconnected it, and people were once again
 able to reach OZ from sn 6 pretty much normally.

I guess I object to random transciever disconnection if it is intended
to be "semi-permanent" fix, like more than 5 minutes or so to test
soemthing.  It just seems to make more problems than it fixes.

 Hostat on a Lisp Machine showed no main campus hosts, and ridiculous numbers of
 CRC errors on subnet 1, looks like as many errors as packets.  No significant
 number of aborts.  Someone booted the AI-CHAOS-11 recently and it has not been
 able to download (it downloads over sn 1).  I'll try starting it assuming core
 hasn't been bashed.  I'll work on finding the problem on sn 1 for a little
 while longer.

Tech^2 was severed from main campus by a break in the bldg 36 basement
phone closet.  It caused Tech^2 subnet 1 to be poorly terminated, no
doubt causing the errors.  This is now fixed, and the error rate is
back to "normal".  Can we buy a microwave for backup, this seems to be
happening a lot (only semi-serious)...
28-Feb-83 09:59:48-EST,413;000000000000
Return-path: <OAF@MIT-OZ>
Mail-From: OAF created at 28-Feb-83 09:58:17
Date: 28 Feb 1983 0958-EST
From: OAF@MIT-OZ
Subject: avoiding some fairly problematic cable runs - forever!
To: DPH@MIT-MC
cc: bug-hardware@MIT-OZ
In-Reply-To: Your message of 27-Feb-83 2255-EST

Hey, why NOT a microwave for backup!
What does it cost?  (I'm assuming we link Tech Square to Bldg 36, or
39, roof-to-roof.)
-------
28-Feb-83 18:46:49-EST,276;000000000000
Return-path: <JfC@MIT-OZ>
Date: Monday, 28 February 1983, 18:43-EST
From: John Canny <JfC@MIT-OZ>
To: bug-hardware@MIT-OZ

Cadr31 is still dying with disk errors regularly, also it had a memory parity error once
in bank 1 of board 4, perhaps due to the disk ? 
-JfC

28-Feb-83 19:53:43-EST,429;000000000000
Return-path: <PETREW@MIT-OZ>
Mail-From: PETREW created at 28-Feb-83 19:50:07
Date: Monday, 28 February 1983  19:50-EST
Sender: PETREW @ MIT-OZ
From: PETREW @ MIT-MC
To:   John Canny <JfC @ MIT-OZ>
Cc:   bug-hardware @ MIT-OZ
In-reply-to: Msg of 28 Feb 1983 18:43-EST from John Canny <JfC>

Memory board 4 in Cadr-31 was probably sick, and the parity
error was probably not a disk error.  I replaced the board.
-Peter
28-Feb-83 23:28:01-EST,1913;000000000000
Return-path: <PGS@MIT-OZ>
Mail-From: PGS created at 28-Feb-83 23:24:26
Date: Monday, 28 February 1983  23:24-EST
Sender: PGS @ MIT-OZ
From: PGS @ MIT-MC
To:   bug-hardware @ MIT-OZ
Subject: chaosnet status

Transmission from the MC-IO-11 to the AI-CHAOS-11 is losing.  Symptoms are:
very low pkt transmission rate, AI-CHAOS-11 seems dead to MC for several
minutes at a time.  Occasionally it wins.  Moving down the cable to OZ,
things are a little better.  The AI-CHAOS-11 answers STATUS most of the time
from OZ.  Occasionally it doesn't respond for periods of a minute or so.
When it start responding, the lost packet count is a couple hundred higher.

What's stranger is that none of the error counts on the MC-IO-11 or the
AI-CHAOS-11 are rising very fast at all.  Lost and abort counts on both
subnet 6 and 1 on both MC-IO-11 and AI-CHAOS-11 are respectably low compared
to pkts-in and pkts-out.  CRC and other errors are very low.

I tried very hard last night (this morning) to convince myself that the
AI-CHAOS-11 was at fault, but I was unsuccessful.  I replaced transceivers
and interfaces with ones known to be winning, both subnets 6 and 1, and the
problem continued.  The processor is acting like a working processor.

I have not touched the MC-IO-11 at all, but it acts reasonable, I guess.

Perhaps the cable between the two is at fault.

More bits: TFTP from XX to the dover is very unreliable these days, much more
so than ever before.  Times out all the time.  Could the Ethernet be broken
somehow and somehow eating a lot of the CHAOS-11's time (constant
retransmission using bus for DMA or sumpin)?  I realize this is a little
spacey, but I'm at wits' end.  I may try disconnecting the ether flat cable
and running the AI-CHAOS-11, seeing if it's more reliable at talking to MC
then.  Otherwise I am going to go over the cable some.

I badly need advice.
28-Feb-83 23:52:22-EST,836;000000000000
Return-path: <PGA@MIT-OZ>
Mail-From: PGA created at 28-Feb-83 23:47:35
Date: 28 Feb 1983 2347-EST
From: PGA@MIT-OZ
Subject: Re: chaosnet status
To: PGS@MIT-MC
cc: bug-hardware@MIT-OZ
In-Reply-To: Your message of 28-Feb-83 2327-EST

Gee, this is a long shot.  Remember several months ago when the transceiver
on the AI-CHAOS-11 was intermittent?  It got moved to LM-20 somehow,
where it was less dangerously intermittent.  When I was able to get
a replacement transceiver from Fred, I got hold of the intermittent
transceiver and gave it to Fred with a little note about it
being intermittent.  Well, I talked to him the other day and
he said he couldn't find anything wrong with it and returned it
to service.  Anybody know where a recently fixed transceiver
may have gone?  Could it be the problem?

Phill
-------
 1-Mar-83 03:25:41-EST,752;000000000000
Return-path: <PGS@MIT-OZ>
Mail-From: PGS created at  1-Mar-83 03:24:51
Date: Tuesday, 1 March 1983  03:24-EST
Sender: PGS @ MIT-OZ
From: PGS @ MIT-MC
To:   bug-hardware @ MIT-OZ
Subject: mistakes I won't make again, or how I fixed the MC-IO-11 - AI-CHAOS-11 link

You know that message I sent tonight about the AI-CHAOS-11 and the MC-IO-11
not being able to talk to each other well for reasons undetermined?
Something in it wasn't quite true.  While I did swap the sn 6 interface, I
didn't swap the sn 6 transceiver, because I couldn't see how the sn 6
transceiver could be messing things up in such a way that the sn 1 interface
didn't read stuff from MC, but did read stuff from anything else on sn 1.

Well, now I'm a true believer.
 1-Mar-83 06:05:17-EST,605;000000000000
Return-path: <PGS@MIT-MC>
Date: 28 February 1983 00:56 EST
From: Patrick G. Sobalvarro <PGS @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC

Connections between MC and the AI-CHAOS-11 are still losing.  COnnections
between OZ and the AI-CHAOS-11 win more often.  For the past few hours I've
tried to convince myself the it's the AI-CHAOS-11 without success.  I swapped
transceivers, subnet 1 interfaces, etc.  I'll try the sn 6 interface now, but
it's clear that this is a pretty silly idea (packets get lost on sn 1).  I
think there's something broken between the AI-CHAOS-11 and MC-IO-11, like a
cable.
 1-Mar-83 16:04:24-EST,202;000000000000
Return-path: <RMS@MIT-OZ>
Date: Tuesday, 1 March 1983, 16:01-EST
From: Richard M. Stallman <RMS@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR-1 has 6 boards plugged in, but it only thinks there are four.
 1-Mar-83 16:19:01-EST,389;000000000000
Return-path: <PGS@MIT-OZ>
Mail-From: PGS created at  1-Mar-83 16:16:52
Date: Tuesday, 1 March 1983  16:16-EST
Sender: PGS @ MIT-OZ
From: PGS @ MIT-MC
To:   bug-hardware @ MIT-OZ

Lest anyone think it broke again: the note from me about network connections
between mc-io-11 and ai-chaos-11 that MC's mailer finally got around to
mailing today is 2 days old.  I really did fix it.
 1-Mar-83 18:20:47-EST,967;000000000000
Return-path: <RWK@SCRC-TENEX>
Date: 26 Feb 1983 0533-EST
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: Re: flakey disk?
To: Hewitt at MIT-OZ, BUG-HARDWARE at MIT-MC, bug-apiary-hardware at MIT-MC
cc: RWK at SCRC-TENEX
In-Reply-To: The message of Friday, 25 February 1983, 13:39-EST from Carl Hewitt <Hewitt at MIT-OZ>

From the evidence of an earlier message, i would say your
machine is getting parity errors, not disk errors.  The disk
will signal an error if it gets a parity error
during a disk transfer.  Read-compare-difference is
not an error unless the disk operation was a read-compare
(unlikely, since it isn't used by default).

I assume you typed in the line that says
"cc-disk-analyze gives read-compare-difference"?

I pesume you typed :WHY before :MAIL, which may
have caused the error to go away by the time you
did the :MAIL.  Generally, you should do :MAIL
*INSTEAD* of :WHY.  I guess I should fix
this already.
-------
 1-Mar-83 21:01:18-EST,241;000000000000
Return-path: <GARBER@MIT-MC>
Date: 1 March 1983 20:57 EST
From: Edward M. Garber <GARBER @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC

The chaos net seems to be having trouble again; I am currently unable to
supdup to cipg,dspg,eddie from mc.
 1-Mar-83 21:30:44-EST,378;000000000000
Return-path: <PGS@MIT-OZ>
Date: Tuesday, 1 March 1983  21:21-EST
Sender: PGS @ MIT-OZ
From: PGS @ MIT-MC
To:   Edward M. Garber <GARBER @ MIT-MC>
Cc:   BUG-HARDWARE @ MIT-MC
In-reply-to: Msg of 1 Mar 1983 20:57 EST from Edward M. Garber <GARBER at MIT-MC>

This is because DPH, GLR, and JTW were fixing a kludged splice they'd put in
the other night.  It's fixed now.
 4-Mar-83 00:41:08-EST,413;000000000000
Return-path: <AKR@MIT-OZ>
Mail-From: AKR created at  4-Mar-83 00:36:43
Date: Friday, 4 March 1983  00:36-EST
Sender: AKR @ MIT-OZ
From: AKR @ MIT-MC
To:   Bug-hardware @ MIT-OZ
Subject: TRANSCEIVER in 937


	Who took the transceiver that was connected to cadr-test.
I need it.  There are working treansceivers in Fred's office, so
people should stop stealing stuff that is being used out of 936, 937.
 4-Mar-83 00:46:46-EST,345;000000000000
Return-path: <PGS@MIT-OZ>
Mail-From: PGS created at  4-Mar-83 00:46:04
Date: Friday, 4 March 1983  00:46-EST
Sender: PGS @ MIT-OZ
From: PGS @ MIT-MC
To:   AKR @ MIT-OZ
Cc:   Bug-hardware @ MIT-OZ
Subject: TRANSCEIVER in 937
In-reply-to: Msg of 4 Mar 1983  00:36-EST from AKR

I told you today that I took it the day before yesterday.
 7-Mar-83 11:02:52-EST,478;000000000000
Return-path: <bgs@MIT-OZ>
Date: Monday, 7 March 1983, 11:03-EST
From: Brian G. Schunck <bgs@MIT-OZ>
To: BUG-HARDWARE@MIT-OZ

In HARDWARE in Experimental MIT-Specific 18.1, Experimental System 93.24,
Experimental ZMail 49.9, microcode 226, gc@2,
on Lisp Machine Twenty-five:

Cadr-5 is down with some sort of hardware problem.  It has been
crashing every 15 min. or so for some reason that I can't determine
so I finally just left it in the crashed state.  Have fun.
 8-Mar-83 13:59:02-EST,825;000000000000
Return-path: <PGS@MIT-OZ>
Mail-From: PGS created at  8-Mar-83 13:49:47
Date: Tuesday, 8 March 1983  13:49-EST
Sender: PGS @ MIT-OZ
From: PGS @ MIT-MC
To:   eric @ MIT-OZ, dcp @ MIT-OZ, local-nets @ MIT-OZ,
      network-hackers @ MIT-OZ, bug-hardware @ MIT-OZ
Subject: [jon: chaos prints]

Date: Tuesday, 8 March 1983  05:04-EST
From: jon at mit-vax
To:   pgs
cc:   tk
Re:   chaos prints
Return-path: <jon@MIT-VAX>

thanks for the prints.  if its ok with you id like to keep them for a
day and make a copy.
(if you need them they are on my desk in 416).
for the record there is a bug in the rev5 board which makes it unwilling
to match an address with a 0 in the 100(8) bit.  (bit 6)
i didnt bother trying to trace it any further since it was easier to change
the software.
thanks again.
	jon sieber
10-Mar-83 16:03:52-EST,463;000000000000
Return-path: <SOLEY@MIT-MC>
Date: 10 March 1983 16:00 EST
From: Richard Mark Soley <SOLEY @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC

I have no idea why, but chaos subnet 6 seems to be dying a lot
lately.  Is someone working on it somewhere?  This is pretty
bad, it affects htvax, cadr15, cadr16, oz, and even mc to an
extent.  Have you all heard anything about this?  It seems to
go down about once a day for 20 minutes, and then revive.

	-- Richard Soley
10-Mar-83 17:58:38-EST,620;000000000000
Return-path: <PETREW@MIT-OZ>
Date: Thursday, 10 March 1983  17:52-EST
Sender: PETREW @ MIT-OZ
From: PETREW @ MIT-MC
To:   Richard Mark Soley <SOLEY @ MIT-OZ>
Cc:   BUG-HARDWARE @ MIT-MC
In-reply-to: Msg of 10 Mar 1983 16:00 EST from Richard Mark Soley <SOLEY>

Yes, I have been working on subnet six the last couple of days.
It's nothing to worry about.  Hopefully, this nuisance will 
circumvent the greater nuisance of the net dying somewhere for
a non-obvious reason which takes many times longer to locate 
and repair.  My apologies to everyone inconvenienced by these
activities.
	-Peter Hendrickson
11-Mar-83 14:36:49-EST,425;000000000000
Return-path: <kahle@MIT-OZ>
Date: Friday, 11 March 1983, 14:34-EST
From: brewster kahle <kahle@MIT-OZ>
Subject: cadr-1's color monitor
To: bug-hardware@MIT-OZ

Appearently the color monitor for cadr-1 is broken.
I tried loading the Daedalus system and the monitor did
not respond.  Is there any monitor test pattern generator so I
don't have to count on acres of software working also.

Thank you.

-brewster

11-Mar-83 21:10:04-EST,206;000000000000
Return-path: <rms@MIT-OZ>
Date: Friday, 11 March 1983, 21:07-EST
From: Richard M. Stallman <rms@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR27 unit 0 got a file-unsafe.
Turning the drive off and on fixed it.14-Mar-83 20:23:27-EST,807;000000000000
Return-path: <KMP@MIT-OZ>
Mail-From: KMP created at 14-Mar-83 20:21:09
Date: 14 Mar 1983 2021-EST
From: KMP@MIT-OZ
Subject: Cadr-22 is out of service
To: bug-hardware@MIT-OZ
cc: RICH@MIT-OZ, ZVONA@MIT-OZ, DICK@MIT-OZ, KMP@MIT-OZ

Cadr-22 has stopped for no obvious reason. Hitting c-m-c-m-Rubout from
the keyboard has no effect. I swapped keyboards with a known-to-be-working
keyboard and got no effect. The disk is on and the power is on. When
the keyboard boots, it gives tones that indicate it thinks it is connected
to a LispM. The screen image looks like it's talking to a LispM. There is
no run bar on the screen, however, and keyboard input and mouse control are
absent. That's about all I can say for it. I hope someone has the time to
take a look at it. Thanks much. --kmp
-------
14-Mar-83 21:29:51-EST,501;000000000000
Return-path: <kmp@MIT-MC>
Date: Monday, 14 March 1983, 21:27-EST
From: Kent M. Pitman <kmp at MIT-MC>
Subject: Cadr-22 back in service
To: Rich at OZ, Zvona at OZ, Dick at OZ
Cc: BUG-HARDWARE at OZ

Krymm took a look at Cadr-22 and got it to go again. He said it 
seemed to be a problem in the main memory somewhere, which I suggested
was probably related to our running all 8 boards. It seems to be
running fine now. I guess we'll just wait and see if any further
problems develop.
-kmp
15-Mar-83 00:28:47-EST,462;000000000000
Return-path: <GUMBY@MIT-OZ>
Mail-From: GUMBY created at 15-Mar-83 00:24:50
Date: 15 Mar 1983 0024-EST
From: GUMBY@MIT-OZ
Subject: cadr-6
To: bug-hardware@MIT-OZ
cc: cadr@MIT-OZ

LOD1 of CADR-6's disk has bad blocks in it. It also has the current band LOD1.
SET-CURRENT-BANDs and EDIT-DISK-LABEL's crash. I tried to fix it over the
debugging cables, but the slave connector was so marginal that no signal got 
to the master machine.

bleh.
-------
16-Mar-83 03:34:44-EST,796;000000000000
Return-path: <Hdt@MIT-OZ>
Date: Wednesday, 16 March 1983, 03:32-EST
From: Howard Daniel Trachtman <Hdt@MIT-OZ>
To: BUG-HARDWARE@MIT-OZ

Someone had tried to change the band on cadr-18 from a 91/204 to a 93/226
For some reason the machine died, and I tried setting the bands back to
what they were before, but the machine still wouldn't boot at all, even
after resetting the keyboard.

I ran (cc:cc-test-machine) and discovered this:
  In the shifter logic test there were erroneous bits:
Shift counts 14, 15, 23, 24, 29-31
M bits 1,17,18,25,26
SA bits 4,20,21,25-27,29
R bits 0,17,22,23

Running (cc:cc-test-shifter-logic) did not not reproduce the errors.
Running (cc:cc-test-machine) again did reproduce the same errors in shifter logic.

The machine now booted beautifully.16-Mar-83 23:40:32-EST,477;000000000000
Return-path: <Daniel@MIT-OZ>
Date: Wednesday, 16 March 1983, 23:36-EST
From: Daniel Weise <Daniel@MIT-OZ>
To: BUG-HARDWARE@MIT-OZ

In HARDWARE in Experimental MIT-Specific 18.1, Experimental System 93.24,
Experimental ZMail 49.9, Experimental Local-File 43.0, microcode 226, LF,
on Lisp Machine One:

The color monitor on CADR is still not receiveing valid video
signals.  Is anyone going to try to fix this or has somebody
tried and found it impossible?

Daniel
17-Mar-83 11:49:18-EST,227;000000000000
Return-path: <GARBER@MIT-MC>
Date: 17 March 1983 11:46 EST
From: Edward M. Garber <GARBER @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC

BUG REPORT:
The chaos net connection between MC and cipg,dspg and eddie is currently broken.
17-Mar-83 12:39:27-EST,227;000000000000
Return-path: <GARBER@MIT-MC>
Date: 17 March 1983 11:46 EST
From: Edward M. Garber <GARBER @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC

BUG REPORT:
The chaos net connection between MC and cipg,dspg and eddie is currently broken.
19-Mar-83 15:48:50-EST,210;000000000000
Return-path: <Devon@MIT-MC>
Date: Saturday, 19 March 1983, 15:46-EST
From: Devon S. McCullough <Devon at MIT-MC>
To: bug-hardware at MIT-MC

When 3-2075 stops ringing, 3-6765 rings once, which is annoying.19-Mar-83 22:35:47-EST,848;000000000000
Return-path: <STRAZ@MIT-OZ>
Return-path: <STRAZ@MIT-OZ>
Mail-From: STRAZ created at 19-Mar-83 21:22:04
Date: 19 Mar 1983 2122-EST
From: Steve Strassmann <STRAZ@MIT-OZ>
Subject: CADR-9 is broken
To: bug-lispm@MIT-OZ
Redistributed-to: bug-hardware@MIT-OZ
Redistributed-by: JCMa@MIT-OZ
Redistributed-date: Saturday, 19 March 1983, 22:33-EST

CADR-9 is broken. It seems to work fine after cold-boot, but within
15-60 minutes it dies for no apparent reason. By death, I mean
one of the "running lights" (long horiz line at the bottom) is stuck
on and no response is made to anything less than a boot. Warm boot
grovels for a few seconds, but then it is stuck again. Cold boot
does work.

The lispm was always handling tyi at the time of failure; once it was
a crlf in emacs that seemed to cause catatonia.

Thanks,
Steve
-------
19-Mar-83 22:39:25-EST,924;000000000000
Return-path: <HDT@MIT-OZ>
Mail-From: HDT created at 19-Mar-83 22:36:59
Date: 19 Mar 1983  22:36 EST (Sat)
From: Howard D. Trachtman <HDT@MIT-OZ>
To:   bug-hardware@MIT-OZ
cc:   straz@MIT-OZ
Subject: [STRAZ: CADR-9 is broken]

Please send LispM hardware problems to bug-hardware in the future.

Date: Saturday, 19 March 1983  21:22-EST
From: Steve Strassmann <STRAZ@MIT-OZ>
To:   bug-lispm@MIT-OZ
Re:   CADR-9 is broken

CADR-9 is broken. It seems to work fine after cold-boot, but within
15-60 minutes it dies for no apparent reason. By death, I mean
one of the "running lights" (long horiz line at the bottom) is stuck
on and no response is made to anything less than a boot. Warm boot
grovels for a few seconds, but then it is stuck again. Cold boot
does work.

The lispm was always handling tyi at the time of failure; once it was
a crlf in emacs that seemed to cause catatonia.

Thanks,
Steve
20-Mar-83 00:40:15-EST,509;000000000000
Return-path: <AKR@MIT-OZ>
Mail-From: AKR created at 20-Mar-83 00:38:44
Date: Sun, 20 Mar 1983  00:38 EST
From: AKR@MIT-OZ
To:   Daniel Weise <Daniel@MIT-OZ>
Cc:   BUG-HARDWARE@MIT-OZ
In-reply-to: Msg of 16 Mar 1983 23:36-EST from Daniel Weise <Daniel>


I think the color TV board is broken.  At the moment, I am a bit
overwhelmed with work, so I put this deep down on my stack.
If there really is a demand for a working color monitor on cadr-1,
then I will give it a try sooner.  Any reply's???
20-Mar-83 23:37:46-EST,852;000000000000
Return-path: <MARTY@MIT-OZ>
Mail-From: MARTY created at 20-Mar-83 23:30:31
Date: 20 Mar 1983  23:30 EST (Sun)
From: Martin David Connor <MARTY@MIT-OZ>
To:   bug-hardware@MIT-OZ
Cc:   kew@MIT-OZ, judy@MIT-OZ, dcb@MIT-OZ, pondy@MIT-OZ
Subject: Concentrator line to 810


In moving a line I seem to have disturbed the concentrator line to
810.  It is the grey cable connected to rows 2-4 from the top of the
phone block behind the 9th floor concentrator.

I'm at a loss as to what's the matter. Everything seems to be
connected, but I get no response from the terminal.  The concentrator
and terminal seem to have voltage.

Could somebody look at it, and see if you can find anything?

My sincere apologies to the folks in 810. I tried a couple hours to
fix it tonight, and will try again tomorrow if necessary.

Thanks,

Marty

21-Mar-83 00:20:42-EST,628;000000000000
Return-path: <MARTY@MIT-OZ>
Mail-From: MARTY created at 21-Mar-83 00:16:26
Date: 21 Mar 1983  00:16 EST (Mon)
From: Martin David Connor <MARTY@MIT-OZ>
To:   Bug-hardware@MIT-OZ
Subject: Concentrator line to 810
Cc:   Ian@MIT-OZ, ZZZ@MIT-OZ, DCB@MIT-OZ, Pondy@MIT-OZ, KEW@MIT-OZ, Judy@MIT-OZ


I switched concentrator lines in 810 and 914.
So 810 now has a working concentrator line again.

Unfortunately now 914 has a broken concentrator line, but there are
other lines that work there.

So, hopefully someone will still look at that bad line, but 810 is
back on the net.

*yawn*

And to all a goodnight.

21-Mar-83 11:01:04-EST,495;000000000000
Return-path: <KWC@MIT-ML>
Date: 21 March 1983 10:32 EST
From: Ken Church <KWC @ MIT-ML>
Subject:  cadr19
To: BUG-HARDWARE @ MIT-ML

The monitor in room 301 looks like a dried up piece of fruit.
Actually, the display is all shrunk and out of focus and the keyboard
doesn't seem to work.  I haven't looked at it much harder, since
I really don't need it, just now.  Just thought I'd let you know...,
since it is probably not too hard to fix, and someone might care to
use it.

- ken
22-Mar-83 07:31:07-EST,856;000000000000
Return-path: <LEVITT@MIT-OZ>
Mail-From: LEVITT created at 22-Mar-83 07:28:48
Date: Tue, 22 Mar 1983  07:28 EST
From: LEVITT@MIT-OZ
To:   bug-hardware@MIT-OZ
Subject: CADR-4 moved, but disk is dead.


I moved CADR-4, which has been without a home on the 9th floor
for a while, to the 7th floor machine room, because we urgently
needed to test music hardware on the 7th. CADR-4 came up fine, but
after powering it down to straighten up the cables and tweak the
final position of the machine, it began exhibiting this symptom:

Spins up fine.
On booting CADR, does "emergency head retract" at first disk seek,
but continues to spin, while CADR halts at location 40.

I swapped the disk pack. disk controller card, and the disk/CADR
cables, and always got the same symptom.  The pack boots on other
drives.  So it appears to be the drive.
22-Mar-83 10:26:37-EST,198;000000000000
Return-path: <TK@MIT-MC>
Date: 22 March 1983 10:24 EST
From: Tom Knight <TK @ MIT-MC>
To: LEVITT @ MIT-MC
cc: BUG-HARDWARE @ MIT-MC

Did you level the disk drive?  This might be its problem.
22-Mar-83 20:36:37-EST,459;000000000000
Return-path: <RWK@SCRC-TENEX>
Date: 22 Mar 1983 2039-EST
From: Robert W. Kerns <RWK at SCRC-TENEX>
Subject: Re: CADR-4 moved, but disk is dead.
To: LEVITT at MIT-OZ, bug-hardware at MIT-OZ
cc: RWK at SCRC-TENEX
In-Reply-To: The message of Tue, 22 Mar 1983  07:28 EST from LEVITT@MIT-OZ

I hpe you inspected the heads on CADR-4's disk before moving
the pack to another machine, or there may now be two crashed
drives and two crashed packs.
-------
22-Mar-83 22:13:45-EST,4515;000000000000
Return-path: <Hdt@MIT-OZ>
Date: Tuesday, 22 March 1983, 22:10-EST
From:  <Hdt@MIT-OZ>
To: BUG-hardware@MIT-OZ

In Remote-File 22.0, LMFILE-Remote 23.1, MIT-Specific 16.0, System 91.41,
ZMail 48.7, microcode 204, 2/11/83, on Lisp Machine One:


Insert your description of the circumstances, and how often the problem occurs:



Machine being debugged is MIT-LISPM-18.
Disk error: ECC-Soft  Transfer-Aborted
  disk address: UNIT 0 CYLINDER 175 HEAD 14 SECTOR 13 
  last memory address touched by disk = 25377
Contents of disk error log in debugee's main memory 600-640:

Command 0 (Read) 
CCW-list pointer 10000 (low 16 bits)
Disk address: unit 0, cylinder 461, head 15, block 13 (0 305 13 11 decimal)
Memory address: 410776 (type bits 0)
Status: 560024011  Internal-parity  Read-compare  Transfer-Aborted (or wr. ovr.)  Timeout
          Interrupt  Idle

Command 0 (Read) 
CCW-list pointer 740 (low 16 bits)
Disk address: unit 0, cylinder 175, head 14, block 13 (0 125 12 11 decimal)
Memory address: 25377 (type bits 0)
Status: 2020120011  Read-compare  ECC-Soft  Transfer-Aborted (or wr. ovr.)  Interrupt  Idle

Command 0 (Read) 
CCW-list pointer 740 (low 16 bits)
Disk address: unit 0, cylinder 175, head 14, block 13 (0 125 12 11 decimal)
Memory address: 25377 (type bits 0)
Status: 2020120011  Read-compare  ECC-Soft  Transfer-Aborted (or wr. ovr.)  Interrupt  Idle

Command 0 (Read) 
CCW-list pointer 740 (low 16 bits)
Disk address: unit 0, cylinder 175, head 14, block 13 (0 125 12 11 decimal)
Memory address: 25377 (type bits 0)
Status: 2020120011  Read-compare  ECC-Soft  Transfer-Aborted (or wr. ovr.)  Interrupt  Idle

Command 0 (Read) 
CCW-list pointer 740 (low 16 bits)
Disk address: unit 0, cylinder 175, head 14, block 13 (0 125 12 11 decimal)
Memory address: 25377 (type bits 0)
Status: 2020120011  Read-compare  ECC-Soft  Transfer-Aborted (or wr. ovr.)  Interrupt  Idle

Command 0 (Read) 
CCW-list pointer 740 (low 16 bits)
Disk address: unit 0, cylinder 175, head 14, block 13 (0 125 12 11 decimal)
Memory address: 25377 (type bits 0)
Status: 2020120011  Read-compare  ECC-Soft  Transfer-Aborted (or wr. ovr.)  Interrupt  Idle

Command 0 (Read) 
CCW-list pointer 740 (low 16 bits)
Disk address: unit 0, cylinder 175, head 14, block 13 (0 125 12 11 decimal)
Memory address: 25377 (type bits 0)
Status: 2020120011  Read-compare  ECC-Soft  Transfer-Aborted (or wr. ovr.)  Interrupt  Idle
This program doesn't understand why the machine stopped (not ILLOP).

Micro PC History (OPC's), oldest first:
   23167   (DISK-COMPLETION-RETRY-1 1)
   23170   (DISK-COMPLETION-RETRY-1 2)
   23205   FATAL-DISK-ERROR
   23206   (FATAL-DISK-ERROR 1)
   00023   ILLOP
   00024   XWIPM
   23206   (FATAL-DISK-ERROR 1)
   23207   LOG-DISK-ERROR
Backtrace of microcode subroutine stack:
    7  023617   INTRX2
    6  023071   (AWAIT-DISK 2)
    5  022761   (DISK-SWAP-HANDLER 15)
    4  022314   (SWAPIN1-GO 6)
    3  021345   (PGF-R 3)
    2  005623   (QCAR4 1)
    1  007036   (XGET1 3)
    0  040140   QMLP
Microcode state flags: microcode interrupt

Current stack group is: <Stack Group MAIN-ZMAIL-WINDOW>
Current process is: #<DTP-INSTANCE 25510074>"MAIN-ZMAIL-WINDOW"
Complete backtrace follows: (type Space to stop)

14563310 #<DTP-FEF-POINTER EXPUNGE-ZMAIL-BUFFER 22247156>[330] #<DTP-INSTANCE 31534252>
14563303 #<DTP-FEF-POINTER EXPUNGE-AND-SAVE-ZMAIL-BUFFER 22247000>[30] #<DTP-INSTANCE 31534252>
14563275 #<DTP-FEF-POINTER ZMAIL-SAVE-ALL 22246711>[31]
14563267 #<DTP-FEF-POINTER COM-ZMAIL-QUIT 22246475>[116]
14563255 #<DTP-FEF-POINTER COMMAND-EXECUTE 15477635>[100] COM-ZMAIL-QUIT (MENU ("Quit" . COM-ZMAIL-QUIT) 1 #<DTP-INSTANCE 3450024>)
14563250 #<DTP-FEF-POINTER ZMAIL-COMMAND-EXECUTE 22224016>[27] COM-ZMAIL-QUIT
14563240 #<DTP-FEF-POINTER (SELECT-METHOD ZMAIL-COMMAND-LIST MENU) 22224057>[32] MENU ("Quit" . COM-ZMAIL-QUIT) 1 #<DTP-INSTANCE 3450024>
14563224 #<DTP-FEF-POINTER (METHOD ZMAIL-FRAME PROCESS-SPECIAL-COMMAND) 22224044>[25] PROCESS-SPECIAL-COMMAND MENU ("Quit" . COM-ZMAIL-QUIT) 1 #<DTP-INSTANCE 3450024>
14563126 #<DTP-FEF-POINTER (METHOD ZMAIL-COMMAND-LOOP-MIXIN COMMAND-LOOP) 22221456>[245] COMMAND-LOOP
14563111 #<DTP-FEF-POINTER (METHOD ZMAIL-FRAME COMBINED COMMAND-LOOP) 22341511>[147] COMMAND-LOOP
14563103 #<DTP-FEF-POINTER ZMAIL-PROCESS-TOP-LEVEL 22223257>[146] #<DTP-INSTANCE 3441077>
14563027 #<DTP-FEF-POINTER PROCESS-TOP-LEVEL 22210346>[121]

BOUND-LOC-POINTER-NOT-LOCATIVE 
22-Mar-83 23:19:14-EST,722;000000000000
Return-path: <LEVITT@MIT-OZ>
Date: Tue, 22 Mar 1983  23:07 EST
From: LEVITT@MIT-OZ
To:   Tom Knight <TK@MIT-MC>
Cc:   BUG-HARDWARE@MIT-MC
In-reply-to: Msg of 22 Mar 1983 10:24 EST from Tom Knight <TK at MIT-MC>

    From: Tom Knight <TK at MIT-MC>
    Did you level the disk drive?  This might be its problem.

I leveled it several times.  When I first moved it, I leveled it
easily (I thought), and it worked fine.  I leveled it again after
adjusting its position slightly, before the problem occured.  Later,
GUMBY suggested a reliable way to use the level - setting it on the
ring where the disk pack is mounted - and I re-leveled it very
carefully.  Always the same behavior, on known-good disk packs.
23-Mar-83 00:39:57-EST,2129;000000000000
Return-path: <LEVITT@MIT-OZ>
Mail-From: LEVITT created at 23-Mar-83 00:35:03
Date: Wed, 23 Mar 1983  00:35 EST
From: LEVITT@MIT-OZ
To:   Robert W. Kerns <RWK@SCRC-TENEX>
Cc:   bug-hardware@MIT-OZ
Subject: CADR-4 disk; music group needs
In-reply-to: Msg of 22 Mar 1983  20:39-EST from Robert W. Kerns <RWK at SCRC-TENEX>


    From: Robert W. Kerns <RWK at SCRC-TENEX>
    I hpe you inspected the heads on CADR-4's disk before moving
    the pack to another machine, or there may now be two crashed
    drives and two crashed packs.

I moved the CADR-4 pack to CADR-20, where it booted, and then tried it
again in CADR-4 where it failed again.  CADR-20 is running fine.  But
thanks for the warning, I should be more cautious, diagnosing disks is
not my specialty.  ***

If you're wondering why a graduate student is out on his own
installing machines and diagnosing disks, it's because I learned that
for the past few weeks NOT ONLY has there been power on the 7th for
one more T300 and an unknown number of CADRs with T-80's, but CADR-4
has been unused and without a console.  Nothing had been done, and I
was all furiouser because I hadn't been made aware of the situation.

Apparently it's not widely known how badly some lab members are still
being hurt by the 7 month delay with the machine room.  People in the
music group, including undergraduate thesis students and UROPs, are
unable to hear a single program because of that delay, and delays in
other solutions sought from staff (e.g. long-distance cable drivers
from Fred Drenckahn).  It's a disaster, with just some hope of healing
by the end of the semester.

Yesterday I learned about concerns that the Music Group would try to
"commandeer" the 7th floor machines.  Since the Music Group will be
using special hardware, but has not bought "its own" machines, I agree
that it's important to generally announce this, and that people can't
be "bumped" by group members the way they can on some machines.  I'll
do that.  But I pray that the installation of the machines will be
hastened, rather than held up, by our urgent need.
23-Mar-83 14:49:20-EST,446;000000000000
Return-path: <FRED@SCRC-TENEX>
Date: Wednesday, 23 March 1983  14:48-EST
From: FRED at SCRC-TENEX
To:   LEVITT%MIT-OZ at MIT-MC
Cc:   bug-hardware%MIT-OZ at MIT-MC,
      Robert W. Kerns <RWK%SCRC-TENEX at MIT-MC>
Subject: CADR-4 disk; music group needs
In-reply-to: The message of Wed 23 Mar 1983  00:35 EST from LEVITT%MIT-OZ at MIT-MC

please have the courtesy to spell my name correctly in any future 
acknowledgements.  thank you
23-Mar-83 17:12:49-EST,638;000000000000
Return-path: <LEVITT@MIT-OZ>
Date: Wed, 23 Mar 1983  17:05 EST
From: LEVITT@MIT-OZ
To:   FRED@SCRC-TENEX
Cc:   bug-hardware%MIT-OZ@MIT-MC, LEVITT%MIT-OZ@MIT-MC,
      Robert W. Kerns <RWK%SCRC-TENEX@MIT-MC>
Subject: CADR-4 disk; music group needs
In-reply-to: Msg of 23 Mar 1983  14:48-EST from FRED at SCRC-TENEX


Oops!  I didn't make it at all clear that the hardware from Fred
Drenckhahn was not in our original plan; he offered it to us it us to
bail us out of the incredible combined lossage incurred by the machine
room snafus, and the losing interface design internal to our
synthesizers.  Sorry, Fred, and thanks.
24-Mar-83 06:05:57-EST,558;000000000000
Return-path: <RMS@MIT-OZ>
Date: Thursday, 24 March 1983, 06:04-EST
From: Richard M. Stallman <RMS@MIT-OZ>
To: BUG-HARDWARE@MIT-OZ

In HARDWARE in LMFILE-Remote 23.1, MIT-Specific 16.0, System 91.40,
ZMail 48.7, Experimental Remote-File 23.0, Experimental Local-File 42.0,
microcode 204, Reverse Video, Local File, GCed,
on Lisp Machine Eighteen:


CADR-1 got an M memory parity error.
That's all the information :WHY gave me.
I could see how the value in the M reg I think it was referring to
was computed, and the value appeared to be correct.24-Mar-83 09:13:45-EST,349;000000000000
Return-path: <Batali@MIT-OZ>
Date: Thursday, 24 March 1983, 09:12-EST
From: John Batali <Batali@MIT-OZ>
To: BUG-HARDWARE@MIT-OZ

In HARDWARE in MIT-Specific 18.1, System 93.32, ZMail 49.11,
microcode 226, Yow!  Winning away!, on Lisp Machine Eight:

This machine has a bouncing BREAK key.  Typing it gets anywhere
from one to 5 breakpoints.24-Mar-83 17:20:51-EST,631;000000000000
Return-path: <KMP@MIT-OZ>
Mail-From: KMP created at 24-Mar-83 17:15:20
Date: 24 Mar 1983 1715-EST
From: KMP@MIT-OZ
Subject: Missing mouse/keyboard
To: pa-cadr22@MIT-OZ
cc: BUG-HARDWARE@MIT-OZ

I have obtained a new keyboard from the pool upstairs. We're still critically
short of keyboards/mice so any info regarding the other's disappearing would
be appreciated. They were out of mice, so we had to take the joy-stick style.
It has a smoother ride, but is hard to fine-tune it to point at small points
on the screen. Sorry for the inconvenience, we'll try to get back a real mouse
when one comes available.
-------
25-Mar-83 03:09:26-EST,681;000000000000
Return-path: <CENT@MIT-ML>
Date: 25 March 1983 03:06 EST
From: Pandora B. Berman <CENT @ MIT-ML>
Subject: ai tape drive again
To: BUG-HARDWARE @ MIT-ML, MARTY @ MIT-ML

the tape controller seems to be broken, probably in a simple fashion: it
won't turn on. in frobbing with the power switch and breaker in back i got
it to flash its little power light there a few times, but only when i was
moving the breaker. then it wouldn't even do that.  i found both the
controller and the drive off originally.  maybe the controller power got
fried by the power surge that crashed everything a few days ago?
please fix so i can continue to back up ai and thus help it limp along.25-Mar-83 10:20:34-EST,377;000000000000
Return-path: <PGS@MIT-OZ>
Mail-From: PGS created at 25-Mar-83 10:18:40
Date: 25 Mar 1983 1018-EST
From: PGS@MIT-OZ
Subject: CADR-23's video
To: bug-hardware@MIT-OZ

I suspect that the problem with cadr-23's video is due to a bad tv board;
the monitor is fine (I tried swapping).  The other possibility is that the 
cable or connectors are broken, of course.
-------
25-Mar-83 14:06:11-EST,233;000000000000
Return-path: <GUMBY@MIT-OZ>
Mail-From: GUMBY created at 25-Mar-83 14:05:41
Date: 25 Mar 1983 1405-EST
From: GUMBY@MIT-OZ
Subject: marvin's aaa (the one in his office)
To: bug-hardware@MIT-OZ

has no horizontal sync.
-------
26-Mar-83 01:01:51-EST,305;000000000000
Return-path: <CSTACY@MIT-ML>
Date: 26 March 1983 00:59 EST
From: Christopher C. Stacy <CSTACY @ MIT-ML>
Subject: scrounging around
To: BUG-HARDWARE @ MIT-ML


I traded LM24 a joystick for a mouse.
There is a keyboard of unknown status lying next to LM24.
There is a big black mouse next to LM1.
26-Mar-83 08:40:21-EST,673;000000000000
Return-path: <MAP@MIT-MC>
Date: Saturday, 26 March 1983, 08:37-EST
From: Michael A. Patton <MAP at MIT-MC>
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in MIT-Specific 18.1, System 93.32, ZMail 49.11,
microcode 226, Yow!  Winning away!, on Lisp Machine Eight:

CADR-6 appears to be in bad shape, it got that way gradually
over the last hour.  It started with a couple of strange network
related errors, then it crashed hard (wouldn't even warm boot
and cc from other machine kept getting strange errors [cc
attributable to gumby]).  It cold-booted once clean but when it
tried to reference the net it started loosing again, now it
can't even get the time of day.
26-Mar-83 09:19:31-EST,555;000000000000
Return-path: <Gumby@MIT-OZ>
Date: Saturday, 26 March 1983, 09:18-EST
From: David Vinayak Wallace <Gumby@MIT-OZ>
Subject: Foo!
To: ninth-floor@MIT-OZ
CC: bug-hardware@MIT-OZ

Somebody cleaned up the lisp machine corral. That was really nice of
them. 

They also cleaned up all the loose cables, including ALL the debugging
cables. That was really stupid.

Where did they end up? I couldn't find them in 906 or 936. I finally had
to use the one on the seventh floor, which is a long walk.

Please put them back. You may screw someone else.
26-Mar-83 12:18:07-EST,469;000000000000
Return-path: <MARTY@MIT-OZ>
Date: 26 Mar 1983  12:12 EST (Sat)
From: Martin David Connor <MARTY@MIT-OZ>
To:   Pandora B. Berman <CENT@MIT-ML>
Cc:   BUG-HARDWARE@MIT-ML
Subject: ai tape drive again
In-reply-to: Msg of 25 Mar 1983 03:06 EST from Pandora B. Berman <CENT at MIT-ML>


I had a little chat with it, it seems to be back to it's pitiful but
functioning state.
It seems the power glitch the other night had scared it.  
It is feeling better now.

26-Mar-83 14:17:55-EST,500;000000000000
Return-path: <Zvona@MIT-OZ>
Date: Saturday, 26 March 1983, 13:50-EST
From: David Chapman <Zvona@MIT-OZ>
Subject: 3600 console problems
To: bug-lispm@SCRC-TENEX, bug-hardware@MIT-OZ

I don't quite know where to send this, but ... the PI 3600 console CRT
has the problem that the plastic frame frob (is that what is called a
``bezell'', I somehow remember?) covers the top line of the screen so
you can't read it.  Also, it is out of focus around the edges -- is
there a way to adjust this?
26-Mar-83 15:16:52-EST,1197;000000000000
Return-path: <PGA@MIT-OZ>
Mail-From: PGA created at 26-Mar-83 15:13:23
Date: 26 Mar 1983 1513-EST
From: PGA@MIT-OZ
Subject: [David Chapman <Zvona@MIT-OZ>: 3600 console problems]
To: bug-lispm@MIT-OZ, bug-hardware@MIT-OZ
cc: levitt@MIT-OZ, laura@MIT-OZ, minsky@MIT-OZ

	Return-path: <Zvona@MIT-OZ>
	Date: Saturday, 26 March 1983, 13:50-EST
	From: David Chapman <Zvona@MIT-OZ>
	Subject: 3600 console problems
	
	I don't quite know where to send this, but ... the PI 3600
	console CRT has the problem that the plastic frame frob (is
	that what is called a ``bezell'', I somehow remember?) covers
	the top line of the screen so you can't read it.  Also, it is
	out of focus around the edges -- is there a way to adjust
	this?

It's spelled with one 'l'.  Just to be sure, I checked.  I found the
closest part of the definition to Zvona's use, in American Heritage, interesting:

    3. A groove or flange designed to hold the beveled edge of a watch
    crystal or a gem.

Did you ever think of a CRT tube as being like a gem?  I suppose it's
more like a watch crystal.  There is probably an intermediate gap in
the Entymology, but it's an interesting thought.

-------
26-Mar-83 15:28:17-EST,460;000000000000
Return-path: <PGA@MIT-OZ>
Mail-From: PGA created at 26-Mar-83 15:26:09
Date: 26 Mar 1983 1526-EST
From: PGA@MIT-OZ
Subject: Re: [David Chapman <Zvona@MIT-OZ>: 3600 console problems]
To: bug-lispm@MIT-OZ, bug-hardware@MIT-OZ, levitt@MIT-OZ, laura@MIT-OZ,
    minsky@MIT-OZ, PGA@MIT-OZ
In-Reply-To: Your message of 26-Mar-83 1513-EST

Whoops, that's etymology, not entomology; unless we think transformation
of language is a 'bug' (insect?).
-------
26-Mar-83 22:54:33-EST,221;000000000000
Return-path: <Gumby@MIT-OZ>
Date: Saturday, 26 March 1983, 22:51-EST
From: David Vinayak Wallace <Gumby@MIT-OZ>
To: BUG-HARDWARE@MIT-OZ

In HARDWARE on Lisp Machine Eight:

The break key on this keyboard repeats.
27-Mar-83 19:11:31-EST,550;000000000000
Return-path: <MOON@SCRC-TENEX>
Date: Sunday, 27 March 1983  19:07-EST
From: MOON at SCRC-TENEX
To:   David Chapman <Zvona at MIT-OZ>
Cc:   bug-hardware at MIT-OZ, bug-lispm at SCRC-TENEX
Subject: 3600 console problems
In-reply-to: The message of 26 Mar 1983 13:50-EST from David Chapman <Zvona@MIT-OZ>

BUG-PI-3600 @ ML is the mailing list for problems with Rivest's machine.
It goes to cognizant people here.

The problems with that console were forwarded to customer service a few days
ago so I assume it will be readjusted this week.
27-Mar-83 19:21:35-EST,2069;000000000000
Return-path: <KMP@MIT-MC>
Date: 27 March 1983 19:16 EST
From: Kent M. Pitman <KMP @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC
cc: RICH @ MIT-MC, DICK @ MIT-MC, RZ @ MIT-MC, ELLEN @ MIT-MC,
    JPG @ MIT-MC, WGD @ MIT-MC, ZVONA @ MIT-MC, CSTACY @ MIT-MC,
    Petrew @ MIT-OZ

Yesterday evening, Bill Dubuque came in asking what was the matter with
his Cadr. He said it was turned off and he had powered it up but that it
seemed to think it had only 64K of memory. I don't know much about Cadrs,
but figured we could at least check the boards to make sure someone hadn't
been stealing memory. We spun the disks down on both and then turned off
the power. I pulled the boards on one of them (the one Bill said thought
it had too little memory) and all the dip switches seemed to be set right.
We replacd the boards and powered both machines back on, then both disk
packs on. The lights flashed as if the disks were spinning up, then both
lights simultaneously died and the disks appeared to not be working. One
of the machines we had done nothing with (save turn off and on again) so
we couldn't have hurt it; the other we were very careful to replace the
boards as they had been, so I'm pretty sure we didn't have any effect on
things there either. Since we couldn't figure out what was up, we left these
machines turned off. They are LM15 and LM16; their homes are ``near the
XGP'' in the Cadr Corral.

Today, I came in and found Cadr-22's console dark. When I went upstairs,
I noticed that its power switches (disk and cpu) were on, the breakers
were on, but there was no power to the machine. I set the switch on the
disk to be off and then tried power cycling the machine with no effect.
DANIEL said that he smelled something that smelled like a ``burnt chip.''
The two problems (the smell of fried chip and the lack of power) may or
may not be related.

In any case, the bottom line is that some cadrs are broken and I thought
I'd bring it to your attention and hope you'll have time to look into 
fixing them soon. Thanks muchly.
--kmp
27-Mar-83 22:35:35-EST,381;000000000000
Return-path: <HDT@MIT-OZ>
Mail-From: HDT created at 27-Mar-83 22:32:53
Date: 27 Mar 1983 2232-EST
From: Howard Daniel Trachtman <Hdt@MIT-OZ>
Subject: File-computer
To: bug-hardware@MIT-OZ


 LM27's monitor doesn't work, and I'm not sure about the processor,
as there are no other monitors around to see whats up.
It doesn't respond to any chaosnet connections.
-------
27-Mar-83 22:36:59-EST,513;000000000000
Return-path: <PETREW@MIT-OZ>
Mail-From: PETREW created at 27-Mar-83 22:32:48
Date: Sun, 27 Mar 1983  22:32 EST
From: PETREW@MIT-OZ
To:   Bug-Hardware@MIT-OZ
Subject: Cadr-22's Bugs

One more for the growing list.
It has been reported to me that the video connector to the console
was flakey for awhile and would work only in certain positions.
Now it doesn't work in any position.  I don't have time to fix
this now, but whoever does fix the Cadr in general should know
why they don't get any video.
29-Mar-83 01:17:16-EST,753;000000000000
Return-path: <CENT@MIT-AI>
Date: 29 March 1983 01:10 EST
From: Pandora B. Berman <CENT @ MIT-AI>
Subject: ai tape drive
To: BUG-HARDWARE @ MIT-AI, MARTY @ MIT-AI

is losing again (so what else is new). this looks like the error
we ran into in jan.(?) where i think the write head was the problem?
sypmtoms: i start an incr. dump and the tape goes round but never
gets beyond .; . inspection of the log file shows that it has lost
in trying to write the first real, undumped file. a look at the job
in peek shows the amount of file written is exactly 4 blocks -- while
the tape continues to progress.
i think we decided that the buffer was 4+0 long, but i forget the rest
of the solution. marty, could you have another chat with it? thx..
29-Mar-83 02:36:26-EST,431;000000000000
Return-path: <MOON@MIT-MC>
From: MOON@MIT-MC
Date: 03/29/83 02:30:11
Subject: ai tape drive

MOON@MIT-MC 03/29/83 02:30:11 Re: ai tape drive
To: CENT at MIT-AI
CC: (BUG HARDWARE) at MIT-AI, MARTY at MIT-AI
Those symptoms indicate continual write errors I think.  The system
just keeps retrying but no write ever succeeds.  Probably because
the tape controller reads back what it wrote and the read back gets garbage..

29-Mar-83 03:30:18-EST,212;000000000000
Return-path: <PGS@MIT-OZ>
Date: Tuesday, 29 March 1983, 03:29-EST
From: Patrick Sobalvarro <PGS@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR-30 is flakey; it crashes every few hours.  CADR-19 has no video signal.
29-Mar-83 22:07:20-EST,3231;000000000000
Return-path: <HDT@MIT-OZ>
Mail-From: HDT created at 29-Mar-83 22:05:12
Date: 29 Mar 1983  22:05 EST (Tue)
From: Howard D. Trachtman <HDT@MIT-OZ>
To:   Bug-hardware@MIT-OZ
cc:   Bradst@MIT-OZ
Subject: [Bradst !: forwarded]

Date: Tuesday, 29 March 1983, 20:05-EST
From: John Bradstreet <Bradst ! at MIT-OZ>
To:   BUG-LISPM at MIT-OZ

In MIT-Specific 18.1, System 93.30, ZMail 49.10, microcode 226, gc@2,
on Lisp Machine Nine:



	  I somehow got a disk error while doing a simple System-E while trying to
	switch edit buffers.  What a royal pain.
	  Note that this is the second time I have gotten this sort of error on this
	particular Lisp Machine.  Did anyone take care of the problem the first time ?

	  >J.Bradstreet<

Cadr-9 has been having hardware problems.  Thanks for your report, but please
send hardware problems to bug-hardware, not bug-lispm.  

>>ERROR: Disk read error unit 0, cyl 81., surf 15., sec 9.,
  status ECC-Hard  Transfer-Aborted
 Type control-C to retry.
Backtrace from the debugger:

SI:DISK-RUN (P.C. = 325)

 Arg 0 (RQB): #<ART-16B-510. 7201000>
 Arg 1 (UNIT): 0.
 Arg 2 (ADDRESS): 26411.
 Arg 3 (SECTORS-PER-TRACK): 17.
 Arg 4 (HEADS-PER-CYLINDER): 19.
 Arg 5 (CMD): 2048.
 Arg 6 (CMD-NAME): "read"
   --Defaulted args:--
 Arg 7 (NO-ERROR-CHECKING): NIL
Local 0 (ADR): 1553.
Local 1 (CYLINDER): 81.
Local 2 (SURFACE): 14.
Local 3 (SECTOR): 10.
Local 4 (ERROR-COUNT): 4.
Local 5 (ER-H): 3649.
Local 6 (ER-L): 8201.
Local 7 (FINAL-ADDRESS): 26495.
Local 8 (FINAL-CYLINDER): 82.
Local 9 (FINAL-SURFACE): 0.
Local 10 (FINAL-SECTOR): 9.
Local 11 (MICROCODE-ERROR-RECOVERY): T


SI:DISK-READ-WIRED (P.C. = 100)

 Arg 0 (RQB): #<ART-16B-510. 7201000>
 Arg 1 (UNIT): 0.
 Arg 2 (ADDRESS): 26411.
   --Defaulted args:--
 Arg 3 (MICROCODE-ERROR-RECOVERY): T
Local 0 (SECTORS-PER-TRACK): 17.
Local 1 (HEADS-PER-CYLINDER): 19.


SYS:PAGE-IN-WORDS (P.C. = 173)

 Arg 0 (ADDRESS): 6429753.
 Arg 1 (NWDS): 22536.
Local 0 (CCWX): 85.
Local 1 (CCWP): 186.
Local 2 (BASE-ADDR): 6430464.
Local 3 (ADDR): 6452224.
Local 4 (N): 65.
Local 5 (PFN): 177.
Local 6 (I): NIL
Local 7 (CCWP): NIL
Local 8 (VPN): NIL


SYS:PAGE-IN-ARRAY (P.C. = 45)

 Arg 0 (ARRAY): #<ART-1B-768.-939. 30416066>
 Arg 1 (FROM): 6429753.
 Arg 2 (TO): (768. 939.)
Local 0 (SIZE): 22536.


SYS:PAGE-IN-PIXEL-ARRAY (P.C. = 40)

 Arg 0 (ARRAY): #<ART-1B-768.-939. 30416066>
 Arg 1 (FROM): NIL
 Arg 2 (TO): (768. 939.)


Remainder of stack:

(METHOD TV:SHEET DEEXPOSE) (P.C. = 460)
(INTERNAL (METHOD TV:BASIC-FRAME COMBINED DEEXPOSE) 0.) (P.C. = 47)
TV:SHEET-DEEXPOSE (P.C. = 202)
(METHOD TV:BASIC-FRAME COMBINED DEEXPOSE) (P.C. = 63)
TV:SHEET-PREPARE-FOR-EXPOSE (P.C. = 513)
TV:SHEET-EXPOSE (P.C. = 153)
(METHOD ZWEI:ZMACS-FRAME COMBINED EXPOSE) (P.C. = 63)
(METHOD TV:SELECT-MIXIN BEFORE SELECT) (P.C. = 102)
(METHOD ZWEI:ZMACS-WINDOW COMBINED SELECT) (P.C. = 216)
(METHOD ZWEI:ZMACS-FRAME COMBINED SELECT) (P.C. = 126)
(METHOD TV:ESSENTIAL-WINDOW MOUSE-SELECT) (P.C. = 33)
(METHOD TV:BASIC-FRAME COMBINED MOUSE-SELECT) (P.C. = 50)
TV:KBD-SYS-1 (P.C. = 470)
SI:PROCESS-RUN-FUNCTION-INTERNAL (P.C. = 102)
SI:PROCESS-TOP-LEVEL (P.C. = 121)
30-Mar-83 00:02:19-EST,434;000000000000
Return-path: <STRAZ@MIT-OZ>
Mail-From: STRAZ created at 29-Mar-83 23:58:33
Date: 29 Mar 1983 2358-EST
From: Steve Strassmann <STRAZ@MIT-OZ>
Subject: 7th floor concentrator
To: pga@MIT-OZ, bug-hardware@MIT-OZ


Around 11:30 pm tuesday night, the upper box died so bad booting doesn't
even help. 

Could someone label the concentrators so you don't have to guess which one
of the two to re-boot?

Thanks,
Steve
-------
30-Mar-83 12:15:17-EST,155;000000000000
Return-path: <PGS@MIT-OZ>
Date: Wednesday, 30 March 1983, 12:11-EST
From: Patrick Sobalvarro <PGS@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR-5 is broken.
30-Mar-83 20:27:09-EST,435;000000000000
Return-path: <CENT@MIT-OZ>
Mail-From: CENT created at 30-Mar-83 20:21:37
Date: 30 Mar 1983 2021-EST
From: CENT@MIT-OZ
Subject: ninth floor page
To: bgb@MIT-OZ
cc: bug-hardware@MIT-OZ

re your report that it is not working:
the last person who was working on it was Fred Drenckhahn. it was
never in great shape anyway. are you sure the volume on the speaker
nearest you is all the way up? some people turn it down.
-------
31-Mar-83 01:46:11-EST,252;000000000000
Return-path: <Straz@MIT-OZ>
Date: Thursday, 31 March 1983, 01:45-EST
From: Steve Strassmann <Straz@MIT-OZ>
Subject: cadr-9's keybbboard
To: bug-hardware@MIT-OZ


CADR-9's BB key is bbecoming bbbbery bbery bbouncy. All my bb's are getting cloned.31-Mar-83 09:13:00-EST,294;000000000000
Return-path: <RMS@MIT-OZ>
Date: Thursday, 31 March 1983, 09:12-EST
From: Richard M. Stallman <RMS@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR-1 got a c-mem parity error.  The pc was 6477.
I looked at c-mem locations 6476 and 6477,
warm booted, and looked at them again.  They were unchanged.
31-Mar-83 16:03:52-EST,225;000000000000
Return-path: <PGS@MIT-OZ>
Mail-From: PGS created at 31-Mar-83 16:02:26
Date: 31 Mar 1983 1602-EST
From: PGS@MIT-OZ
To: bug-hardware@MIT-OZ

cadr-30 wedged with a main memory parity error, board 2 bank 1 bit 1
-------
 1-Apr-83 18:17:18-EST,583;000000000000
Return-path: <Straz@MIT-OZ>
Date: Friday, 1 April 1983, 18:12-EST
From: Steve Strassmann <Straz@MIT-OZ>
To: BUG-HARDWARE@MIT-OZ, bug-lispm@MIT-OZ

In MIT-Specific 18.1, System 93.37, ZMail 49.16, microcode 226, gc@2,
on Lisp Machine Six:


Loading qfasl files on cadr-6 is very flaky. I tried a (load "..") once and
I got an error that said some gubbish like "LDB-NIBBLE-FILE...  "

I just ^Z'ed out of the error and did a (load "..") again and it won.
I would guess this cadr is intermittently losing chaos bits while loading.

-Steve  6:12pm 1 April (it's not funny) 2-Apr-83 02:13:36-EST,256;000000000000
Return-path: <BAK@MIT-OZ>
Date: Saturday, 2 April 1983, 02:11-EST
From: William A. Kornfeld <BAK@MIT-OZ>
Subject: flaky key on lispm keyboard
To: bug-hardware@MIT-OZ

The BREAK key on the keyboard attached to CADR8 has a bad case of contact bounce.
 2-Apr-83 13:45:28-EST,658;000000000000
Return-path: <LMFILE@MIT-OZ>
Date: Saturday, 2 April 1983, 13:42-EST
From: RMS@MIT-OZ
Sender: LMFILE@MIT-OZ
To: bug-hardware@MIT-OZ

I think CADR 6 is having chaosnet trouble.
I tried several times to read the file
SYS:WINDOW;SHWARM LISP into ZWEI, and it would always
say "error: attempt to read from a connection that got a LOS:
connection is not in the right state."
The "fasl nibble without check bit" error that STRAZ was getting
is also believed to be a consequence of bits lost in the chaosnet
interface or transceiver of CADR 6 (since it only happens there).
Such lossages have been happening intermittently on CADR 6
for months now.
 4-Apr-83 13:58:25-EST,246;000000000000
Return-path: <BAK@MIT-OZ>
Date: Monday, 4 April 1983, 13:53-EST
From: William A. Kornfeld <BAK@MIT-OZ>
Subject: bad disk on CADR 9
To: bug-hardware@MIT-OZ

I got the following error twice:

unit 0,cyl 11, surf 9,sec 3
status ECC-HARD

 4-Apr-83 14:42:58-EST,367;000000000000
Return-path: <ZVONA@MIT-OZ>
Mail-From: ZVONA created at  4-Apr-83 14:41:22
Date:  4 Apr 1983 1441-EST
From: ZVONA@MIT-OZ
To: bug-hardware@MIT-OZ

Cadr-6 has this problem with the chaos net.  It drops bits on reads.  It never seems
to drop bits on write.  It seems only to drop them while loading fasl files, but that is probably just a coincidence. 
-------
 4-Apr-83 21:45:50-EST,253;000000000000
Return-path: <STRAZ@MIT-OZ>
Mail-From: STRAZ created at  4-Apr-83 21:43:46
Date:  4 Apr 1983 2143-EST
From: Steve Strassmann <STRAZ@MIT-OZ>
Subject: death
To: bug-hardware@MIT-OZ, bug-music@MIT-OZ


CADR-9 won't cold boot   9:40pm Mon
-------
 5-Apr-83 04:59:42-EST,181;000000000000
Return-path: <HDT@MIT-OZ>
Date: Tuesday, 5 April 1983, 05:00-EST
From: Howard D. Trachtman <HDT@MIT-OZ>
To: bug-hardware@MIT-OZ

Parity error on cadr1, baord 5, bank 1, bit 13. 5-Apr-83 05:24:16-EST,287;000000000000
Return-path: <HDT@MIT-OZ>
Date: Tuesday, 5 April 1983, 05:25-EST
From: Howard D. Trachtman <HDT@MIT-OZ>
To: bug-hardware@MIT-OZ

Cadr1 has got three parity errors,
all in board 5, but in different banks.
The last one was bank 2, bit 21.
I suspect that board has a subtle problem. 5-Apr-83 17:29:15-EST,329;000000000000
Return-path: <KASS@MIT-OZ>
Mail-From: KASS created at  5-Apr-83 17:25:46
Date:  5 Apr 1983 1725-EST
From: KASS@MIT-OZ
Subject: Cadr 23
To: bug-hardware@MIT-OZ

     Cadr 23 still has intermittant video.  Wiggling
the coax connector on the back of the monitor sometimes
brings back the video for a short while.
-------
 5-Apr-83 23:20:14-EST,329;000000000000
Return-path: <RMS@MIT-OZ>
Date: Tuesday, 5 April 1983, 23:21-EST
From: Richard M. Stallman <RMS@MIT-OZ>
To: bug-hardware@MIT-OZ

I removed CADR1's memory board 5.
It has no number on it that I can see.  It is now
sitting on CADR18's disk drive.
It was getting parity errors every few minutes or hours
in different banks. 5-Apr-83 23:30:09-EST,312;000000000000
Return-path: <KATSU@MIT-OZ>
Date: Tuesday, 5 April 1983, 23:31-EST
From: Katsushi Ikeuchi <KATSU@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR1 is still losing, now in board 1,
multiple banks all at once.  Most of the errors in board 1, bank 2 or 3
seemed to be in bit 24., but there were errors in several banks. 6-Apr-83 21:24:11-EST,526;000000000000
Return-path: <JfC@MIT-OZ>
Date: Wednesday, 6 April 1983, 21:23-EST
From: John Canny <JfC@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR-23 has a consistent error somewhere in its arithmetic hardware. 
I only found it because it goes into an infinite loop in my microcode,
but other people have had problems with this machine with obscure but
repeatable bugs. I think it is in the shifter logic, but if the bug
doesnt show up in the machine tests, I can show you where 
(within about 6-7 instructions) it is losing.

- JfC
 7-Apr-83 17:11:47-EST,209;000000000000
Return-path: <KOCH@MIT-OZ>
Mail-From: KOCH created at  7-Apr-83 17:07:48
Date:  7 Apr 1983 1707-EST
From: KOCH@MIT-OZ
Subject: Cadr23
To: bug-hardware@MIT-OZ

Cadr 23 is dead for some reason.
-------
 8-Apr-83 18:02:00-EST,956;000000000000
Return-path: <RICH@MIT-OZ>
Mail-From: RICH created at  8-Apr-83 17:57:31
Date: 8 Apr 1983  17:57 EST (Fri)
From: Charles Rich <RICH@MIT-OZ>
To:   BUG-Hardware@MIT-OZ
CC:   PA-CADR22@MIT-OZ
Subject: CADR22

Cadr22 has died this afternoon for an undiagnosed reason.
Help would be appreciated.  Here is what we know:

	Run bar froze in the middle of programming.
	Cold boot started but then run bar froze again.
	Further cold boot from console no response.
	Boot button on chassis causes disk to stutter
	  but display unchanged.
	Power down disk.
	Power down chassis.
	Power up chassis
	Power up disk.
	Boot button on chassis.  PC freezes at 21105.
	Boot button again on chassis.  PC starts at zeroes
	  and freeezes again at 21105.
	Display dark.

Thanks, Chuck.

	Note we had debug cables hooked up to it this afternoon
	slaving CADR27 to format a new disk and copy some
	bands, but we didn't touch the disk on CADR22.

-CR
 9-Apr-83 00:22:20-EST,729;000000000000
Return-path: <AKR@MIT-OZ>
Mail-From: AKR created at  9-Apr-83 00:18:18
Date: Sat, 9 Apr 1983  00:18 EST
From: AKR@MIT-OZ
To:   Charles Rich <RICH@MIT-OZ>
Cc:   BUG-Hardware@MIT-OZ, PA-CADR22@MIT-OZ
Subject: CADR22
In-reply-to: Msg of 8 Apr 1983  17:57 EST (Fri) from Charles Rich <RICH>

According to Dave Custer someone changed the band without changing
the appropriate microload.  This could have happened while trying to edit
the disk-label on CADR-27 if it was used as a slave.  By omitting
the "cc" you are actually modifying cadr-22's disk-label, thus
rendering cadr22 unbootable.
You can fix this by doing a (set-current-band 'lod_ "cc") or doing
a (set-current-microload 'mcr_ "cc") from another machine.
 9-Apr-83 06:29:19-EST,189;000000000000
Return-path: <RMS@MIT-OZ>
Date: Saturday, 9 April 1983, 06:30-EST
From: Richard M. Stallman <RMS@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR 1 main mem parity error: board 0, bank 1, bit 31. 9-Apr-83 15:09:47-EST,320;000000000000
Return-path: <CAL@MIT-OZ>
Date: Saturday, 9 April 1983, 15:09-EST
From: Cliff Lasser <CAL@MIT-OZ>
To: BUG-hardware@MIT-OZ

In hardware in MIT-Specific 18.1, System 93.44, ZMail 49.18,
microcode 226, gc@2, on Lisp Machine Two (by the 7th floor playroom - used to
be cadr8!!):

This cadr has a tendency to crash. 10-Apr-83 15:04:18-EST,354;000000000000
Return-path: <BAK@MIT-OZ>
Date: Sunday, 10 April 1983, 15:07-EST
From: William A. Kornfeld <BAK@MIT-OZ>
To: bug-hardware@MIT-OZ

I send a message about two weeks ago reporting a problem with a disk.
Does anybody read and process these messages?  If so, acknowledgements
would be appreciated and would encourage users to continue reporting
bugs.
10-Apr-83 17:53:25-EST,223;000000000000
Return-path: <STRAZ@MIT-OZ>
Mail-From: STRAZ created at 10-Apr-83 17:49:40
Date: 10 Apr 1983 1749-EST
From: Steve Strassmann <STRAZ@MIT-OZ>
Subject: cadr-8
To: bug-hardware@MIT-OZ


cadr-8 won't cold boot
-------
10-Apr-83 23:13:30-EST,298;000000000000
Return-path: <RPK@MIT-OZ>
Date: Sunday, 10 April 1983, 23:14-EST
From: Robert P. Krajewski <RPK@MIT-OZ>
To: BUG-Hardware@MIT-OZ

In Hardware in MIT-Specific 18.1, System 93.44, ZMail 49.18,
microcode 226, on Lisp Machine Twenty-five:


The mouse on this cadr [25] will not move vertically.11-Apr-83 19:02:28-EST,760;000000000000
Return-path: <PGS@MIT-OZ>
Mail-From: PGS created at 11-Apr-83 18:59:06
Date: Mon, 11 Apr 1983  18:59 EST
From: PGS@MIT-OZ
To:   bug-hardware@MIT-OZ
Subject: [JOHANN: CADR-2, a.k.a. CADR-8]

Date: Monday, 11 April 1983  16:59-EST
From: JOHANN
To:   bug-lispm, cherry, taft
Re:   CADR-2, a.k.a. CADR-8

CADR-2 has died (i.e., won't boot), and in
its final hour of death claimed to be CADR-8,
in disguise.  The latter turned out to be
annoying to several people, especially after
I inadvertently power-cycled CADR-8, which
someone else was trying to use.  CADR-2's
software presently announces that CADR-2's
console is attached to CADR-8.  This creates
a problem whenever someone needs to service
a device attached to a mis-labeled machine.
11-Apr-83 19:32:30-EST,479;000000000000
Return-path: <PDH@MIT-OZ>
Mail-From: PDH created at 11-Apr-83 19:28:38
Date: Mon, 11 Apr 1983  19:28 EST
From: PDH@MIT-OZ
To:   Bug-hardware@MIT-OZ
Subject: Cadr-1

When I run (cc-test-machine) on Cadr-1 it has errors in the shifter logic test
and does not appear to be completely happy with the clock test.  It passes
all memory test except Tests 6 and 7 in the (cc-run-mtest) function.  In both cases
it says the test was halted because "(error-wrong-data) (= 51)".
12-Apr-83 03:27:58-EST,174;000000000000
Return-path: <PGS@MIT-OZ>
Date: Tuesday, 12 April 1983, 03:23-EST
From: RMS@MIT-OZ
Sender: PGS@MIT-OZ
To: bug-hardware@MIT-OZ

I replaced chip 8A on CADR18's board 5.
12-Apr-83 07:56:09-EST,1330;000000000000
Return-path: <pgs@MIT-OZ>
Date: Tuesday, 12 April 1983, 07:53-EST
From: Patrick Sobalvarro <pgs@MIT-OZ>
To: BUG-HARDWARE@MIT-OZ

In HARDWARE in MIT-Specific 18.1, System 93.45, ZMail 49.19,
microcode 226, on Lisp Machine Five:

Disk gets fatal disk errors on read.

Machine being debugged is MIT-LISPM-25.
Microcode halted via ILLOP from FATAL-DISK-ERROR
Micro PC History (OPC's), oldest first:
   23424   (LOG-DISK-ERROR 16)
   23342   (DISK-COMPLETION-ERROR 2)
   23343   (DISK-COMPLETION-ERROR 3)
   23344   (DISK-COMPLETION-ERROR 4)
   23404   FATAL-DISK-ERROR
   23405   (FATAL-DISK-ERROR 1)
   00023   ILLOP
   00024   XWIPM
Backtrace of microcode subroutine stack:
   10  024020   INTRX2
    7  023270   (AWAIT-DISK 2)
    6  023160   (DISK-SWAP-HANDLER 15)
    5  022404   (COREF-CCW-X 13)
    4  022472   SWAPIN1
    3  021544   (PGF-R 3)
    2  005623   (QCAR4 1)
    1  000375   (QICAR 2)
    0  040140   QMLP
Microcode state flags: microcode interrupt

Current stack group is: <Stack Group Zmacs Frame 1>
Current process is: #<DTP-INSTANCE 23614253>"Zmacs Frame 1"
Complete backtrace follows: (type Space to stop)

22741564 #<DTP-FEF-POINTER GET-HOST-FROM-ADDRESS 1764347>[32] 11406 CHAOS
22741521 #<DTP-FEF-POINTER CONNECT 3614143>[255] #<DTP-INSTANCE 23627421> "FILE 1" 5

...12-Apr-83 09:53:15-EST,405;000000000000
Return-path: <DCP@MIT-MC>
Date: 12 April 1983 09:52 EST
From: David C. Plummer <DCP @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC, bug-twenex @ MIT-XX

XX's chaos subnet 6 connection looks in sad shape.  It aborts
about 30% of the outgoing packets and gets CRC errors on 20% of
the incoming packets.  It's probably not the interface, but more
likely the ribbon cable being loose or the transceiver losing.
12-Apr-83 11:59:02-EST,241;000000000000
Return-path: <LEVITT@MIT-OZ>
Mail-From: LEVITT created at 12-Apr-83 11:54:36
Date: 12 Apr 1983 1154-EST
From: LEVITT@MIT-OZ
Subject: CADR9 unusable
To: bug-hardware@MIT-OZ

The CADR9 console apparently has no vertical sync.
-------
12-Apr-83 12:03:49-EST,424;000000000000
Return-path: <PGS@MIT-OZ>
Mail-From: PGS created at 12-Apr-83 12:01:41
Date: 12 Apr 1983 1201-EST
From: PGS@MIT-OZ
Subject: cadr31, cadr32, and cadr23.
To: bug-hardware@MIT-OZ

All of these machines are up right now, and none of them are in use right
now.  Why?  Their consoles all seem to be broken in some way.  Nearly a
quarter of our lisp machines are unusable right now because of console
problems.
-------
12-Apr-83 14:05:11-EST,453;000000000000
Return-path: <LEVITT@MIT-OZ>
Mail-From: LEVITT created at 12-Apr-83 14:01:24
Date: Tue, 12 Apr 1983  14:01 EST
From: LEVITT@MIT-OZ
to:   bug-hardware@MIT-OZ
Subject: CADR9 fixed
In-reply-to: Msg of 12 Apr 1983  11:54-EST from LEVITT

    Date: Tuesday, 12 April 1983  11:54-EST
    From: LEVITT
    To:   bug-hardware
    Re:   CADR9 unusable

    The CADR9 console apparently has no vertical sync.

With some assistance, I fixed CADR9.
12-Apr-83 15:43:59-EST,468;000000000000
Return-path: <AKR@MIT-OZ>
Mail-From: AKR created at 12-Apr-83 15:41:14
Date: Tue, 12 Apr 1983  15:41 EST
From: AKR@MIT-OZ
To:   PGS@MIT-OZ
Cc:   bug-hardware@MIT-OZ
Subject: cadr31, cadr32, and cadr23.
In-reply-to: Msg of 12 Apr 1983  12:01-EST from PGS

Cadr 23 appears to have a video cable problem.  The console works fine when connected
to cadr32.
Cadr32's monitor crashes the machine as soon as the keyboard is connected; the video
side of it works.
12-Apr-83 16:26:55-EST,436;000000000000
Return-path: <AKR@MIT-OZ>
Mail-From: AKR created at 12-Apr-83 16:22:27
Date: Tue, 12 Apr 1983  16:22 EST
From: AKR@MIT-OZ
To:   PDH@MIT-OZ
Cc:   Bug-hardware@MIT-OZ
Subject: Cadr-1
In-reply-to: Msg of 11 Apr 1983  19:28-EST from PDH

Cc-run-mtest will fail in test 6,7 if you have more than 256 K of memory.
The shifter logic test fails sometimes if you don't ground  pin 5C07-09,
as mentioned when you run cc-test-machine.
17-Apr-83 17:08:09-EST,252;000000000000
Return-path: <UC.MP@MIT-EECS>
Date: 17 Apr 1983 1704-EST
From: Mark Plotnick <UC.MP at MIT-EECS>
Subject: noisy line
To: bug-hardware at MIT-EECS

Dialup line 42 is extremely noisy.  Garbage gets inserted
into the input stream.
	Mark
-------
17-Apr-83 21:03:05-EST,411;000000000000
Return-path: <GAVAN@MIT-OZ>
Date: Sunday, 17 April 1983, 19:54-EST
From: Gavan Duffy <GAVAN@MIT-OZ>
Subject: Mouse Socket loses on cadr-18	
To: BUG-HARDWARE@MIT-OZ

In Release 4.1, System 222.186, Hardcopy 11.14, Zmail 74.43, LMFS 30.26,
site configuration 20, on Lisp Machine Eighteen:

The socket for the mouse on the cadr-18 TV doesn't seem to work.  The
socket on the keyboard is alright though.
19-Apr-83 00:20:39-EST,550;000000000000
Return-path: <PDH@MIT-OZ>
Date: Tue, 19 Apr 1983  00:03 EST
From: PDH@MIT-OZ
To:   David C. Plummer <DCP@MIT-MC>
Cc:   BUG-HARDWARE@MIT-MC, bug-twenex@MIT-XX
Subject: XX's Losing Chaos
In-reply-to: Msg of 12 Apr 1983 09:52 EST from David C. Plummer <DCP at MIT-MC>

The connector on the end of the cable is not straight.  This is probably the
source of error.  Unfortunately, there don't appear to be any female connectors
for that size.  I'll see if I can get more ordered.  If anybody has a stash of
these, or only one, please tell me.
19-Apr-83 13:28:10-EST,474;000000000000
Return-path: <OAF@MIT-OZ>
Mail-From: OAF created at 19-Apr-83 13:26:03
Date: Tuesday, April 19, 1983 1:26PM-EST
From: Oded AnOaf Feingold <OAF@MIT-OZ>
To: bug-hardware at MIT-OZ

The Ann Arbor Terminal that sumwun complained disappeared.
The one that said "broken F key - ALR."
Tom Callahan put it in my office.
I guess I win the booby prize.
(It's not all that bad - I'll try to do something with it....)

Assuming I cause it to work - where do it go?

Oded
19-Apr-83 16:06:42-EST,331;000000000000
Return-path: <NIS@MIT-OZ>
Mail-From: NIS created at 19-Apr-83 16:04:41
Date: Tuesday, April 19, 1983 4:04PM-EST
From: H. Keith Nishihara <NIS@MIT-OZ>
To: bug-hardware at MIT-OZ

cadr3 and cadr24 both seem to be sick
24 seems to have some disk problem .. dies every so often
3 dies more frequently  dont know why 
--keith
19-Apr-83 18:42:49-EST,391;000000000000
Return-path: <OAF@MIT-ML>
Date: 19 April 1983 18:42 EST
From: Oded Anoaf Feingold <OAF @ MIT-ML>
To: bug-hardware @ MIT-OZ

The ambassador that said "F key broken - ALR."
In fact the f,v,n,/?,7 and several other keys didn't work.
Wire 26 of the 26-wire flatcable had marginal connections
to the keyboard.
It has been repaired.
Somebody get that terminal out of my office, please.
20-Apr-83 02:24:49-EST,521;000000000000
Return-path: <AKR@MIT-OZ>
Mail-From: AKR created at 20-Apr-83 02:19:41
Date: Wed, 20 Apr 1983  02:19 EST
From: AKR@MIT-OZ
To:   H. Keith Nishihara <NIS@MIT-OZ>
Cc:   bug-hardware@MIT-OZ
In-reply-to: Msg of Apr 19 1983 4:04PM-EST from H. Keith Nishihara <NIS>


Cadr3 was fixed by Dave Custer.  Dispatch memory was flakey.
Cadr-24 seems reliable at the moment.  I changed one if the cables
going to the disk drive.  If the disk becomes flakey, there is a new
formatted disk pack sitting on cadr-24's drive.

20-Apr-83 19:52:47-EST,418;000000000000
Return-path: <DCP@MIT-MC>
Date: 20 April 1983 18:49 EST
From: David C. Plummer <DCP @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC

It appears the power glitch was not very kind to the following transceivers:
  OZ-11 subnet 6
  PLASMA subnet 1
  Microwave subnet 1
These subnet connections have a large abort count.  If the micrcowave
problem is not mechanical, please let me know so I can have it
properly replaced.
21-Apr-83 06:14:02-EST,511;000000000000
Return-path: <MARTY@MIT-OZ>
Mail-From: MARTY created at 21-Apr-83 06:05:35
Date: 21 Apr 1983  06:05 EST (Thu)
From: Martin David Connor <MARTY@MIT-OZ>
To:   Shimon@MIT-OZ
Cc:   TC@MIT-OZ, Bug-Hardware@MIT-OZ
Subject: 3rd floor terminal concentrator


The "Technical Magic" board in this concentrator seems fried.
Shimon is without a terminal because there are no spare ports.
Could we get another card for the 3rd floor machine?
I moved Demetri and Philip to another line temporarily.

Thanks.

24-Apr-83 23:53:03-EDT,2764;000000000000
Return-path: <Hdt@MIT-OZ>
Date: Sunday, 24 April 1983, 13:32-EDT
From: Howard D. Trachtman <Hdt at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ
CC: rms at MIT-OZ

In HARDWARE in Experimental MIT-Specific 19.0, Experimental System 94.7,
Experimental ZMail 50.2, microcode 238, ZM GC@0, on Lisp Machine One:

I just looked at cadr-1, whose clock stopped at 3:40, and which claimed to have
just been cold booted (band 4, 94.6).

Machine being debugged is MIT-LISPM-18.
Processor error:
  Main-memory parity error
Bus-interface errors since last reset:
  Xbus data parity error
Memory parity error physical address = 1336401, data = 10403442504
Address is memory board #5, bank #2
Checking disk copy of this virtual memory address
Disk data identical, could be parity bit.Assuming there are 6 memory boards
[Warning: I don't think this works for more than 256K]

Level 1 map loaded for the low 256K addresses.
Level 2 map loaded.This program doesn't understand why the machine stopped (not ILLOP).

Micro PC History (OPC's), oldest first:
   16467   (TRANS-INVZ 2)
   00225   (QADR4 1)
   00226   (QADR4 2)
   00433   QIMOVE1
   00434   (QIMOVE1 1)
   00144   QMLP
   00145   (QMLP 1)
   00146   (QMLP 2)
Backtrace of microcode subroutine stack:
   37  025632   (BEG06 1)
   36  025632   (BEG06 1)
   35  025632   (BEG06 1)
   34  025632   (BEG06 1)
   33  025632   (BEG06 1)
   32  025632   (BEG06 1)
   31  025632   (BEG06 1)
   30  025632   (BEG06 1)
   27  025632   (BEG06 1)
   26  025632   (BEG06 1)
   25  025632   (BEG06 1)
   24  025632   (BEG06 1)
   23  025632   (BEG06 1)
   22  025632   (BEG06 1)
   21  025632   (BEG06 1)
   20  025632   (BEG06 1)
   17  025632   (BEG06 1)
   16  025632   (BEG06 1)
   15  025632   (BEG06 1)
   14  022332   SPHT1
   13  023447   (DISK-COMPLETION 1)
   12  022332   SPHT1
   11  022140   (PGF-L2A 1)
   10  022332   SPHT1
    7  022125   (PGF-MAP-MISS 2)
    6  022332   SPHT1
    5  021757   (GET-MAP-BITS 12)
    4  016346   (TRANS-OLD0 2)
    3  010411   (QQARY 2)
    2  000225   (QADR4 1)
    1  000433   QIMOVE1
    0  017045   (ENSURE-STACK-ENV-COPIED 13)

Current stack group is: <Stack Group Scheduler>
Current process is: NIL
Complete backtrace follows: (type Space to stop)

2540117 #<DTP-FEF-POINTER SYMEVAL-IN-STACK-GROUP 1712323>[63] PACKAGE <Stack Group MAIN-STACK-GROUP>
2540107 #<DTP-FEF-POINTER WHO-LINE-PACKAGE 12740635>[125] #<DTP-INSTANCE 2200275>
2540102 #<DTP-FEF-POINTER (METHOD WHO-LINE-SHEET UPDATE) 12740231>[30] UPDATE
2540073 #<DTP-FEF-POINTER (METHOD WHO-LINE-SHEET COMBINED UPDATE) 13003022>[102] UPDATE
2540063 #<DTP-FEF-POINTER WHO-LINE-UPDATE 12740435>[72]
2540010 #<DTP-FEF-POINTER PROCESS-SCHEDULER 1700652>[240]

25-Apr-83 12:27:16-EDT,942;000000000000
Return-path: <OAF@MIT-OZ>
Mail-From: OAF created at 25-Apr-83 11:57:34
Date: Mon, 25 Apr 1983  11:57 EDT
From: OAF@MIT-OZ
To:   Patrick Sobalvarro <PGS@MIT-OZ>
CC:   system@MIT-OZ, bug-hardware@MIT-OZ
Subject: Terminals and hear-ye, hear-ye
In-reply-to: Msg of 21 Apr 1983 11:29-EST from Patrick Sobalvarro <PGS>

Yes, Patrick, there IS a means of dealing with busted terminals.
Mail to me (oaf) and bug-hardware will get things started.

                        AAAs and how they die
Fried AAAs may be dropped in my office.  Soon that will change (when my
office saturates), but for now it's true.  (Note - keyboard problems I
can deal with myself.  Logic and power supply stuff [including the infamous
Q105 forest fire] probably have to go out.)  Turnaround time will be on the
order of 2 weeks for intractable problems, but we hope to work up a stock
for quick replacement.

Watch this space for more details.

Oded
26-Apr-83 16:41:07-EDT,573;000000000000
Return-path: <JfC@MIT-OZ>
Date: Tuesday, 26 April 1983, 16:37-EDT
From: John Canny <JfC@MIT-OZ>
To: bug-hardware@MIT-OZ


CADR-23's monitor has a new video cable and is getting video OK now, but
there is a problem with the monitor itself. It was overscanning in both
directions, was excessively bright, and had a bad smell. I adjusted the
height and the brightness but couldnt make the smell go away so I turned
it of. Also it wouldnt boot from the keyboard (although the raised run
bar flickered a bit) but this may be something simple. Any takers ?

 - JfC
27-Apr-83 23:14:08-EDT,346;000000000000
Return-path: <CAL@MIT-OZ>
Date: Wednesday, 27 April 1983, 23:10-EDT
From: Cliff Lasser <CAL@MIT-OZ>
To: bug-hardware@MIT-OZ

Cadr's 1 and 5 seem to be dead.  There were a couple of power glitches tonight
(I hope there aren't any more to come!).  They both survived the first one.
However, after the second glitch they both refused to boot.28-Apr-83 18:40:50-EDT,451;000000000000
Return-path: <JfC@MIT-OZ>
Date: Thursday, 28 April 1983, 18:40-EDT
From: John Canny <JfC@MIT-OZ>
To: bug-hardware@MIT-OZ


CADR-19 wasnt listening to its keyboard (it beeped at all keys, and
eventually died when I tried to boot it) so its console and keyboard
were moved to CADR-23 (outside 352) and they both work fine. CADR-23's
old monitor, which smells like barbecued transformer when powered up,
is still sitting outside 352.

- JfC
29-Apr-83 00:32:19-EDT,1190;000000000000
Return-path: <PDH@MIT-OZ>
Mail-From: PDH created at 29-Apr-83 00:22:21
Date: Fri, 29 Apr 1983  00:22 EDT
From: PDH@MIT-OZ
To:   Bug-Hardware@MIT-OZ
Subject: Cadr 1 and Cadr 5

Both of these machines died a couple of minutes ago at the same time.
Upon further examination, I found that Cadr 1 is daisy chained off 
Cadr 5.  Not a good practice.  Cadr 5 was hooked into a wiggling socket
in the wall.  This could be harmless, but the power did die.
Both disks on the machines had stopped so I powered them down, so to speak
since they were already stopped.  I have cut the main power switch on each
LM so that there won't be any unexpected surprises if power were to suddenly 
reappear.  I should also report a slight smell of a frying power supply.  This 
may have become less significant after a time.  I guess something like this
was attributed to a glitch a couple of nights ago.  Maybe that's happening now.
At any rate, the problem lies in Cadr-5's power supply, or the building power.
Somebody who knows more about these topics should maybe take a look.

I just went and sniffed around.  It seems that the burning smell is coming
(was coming) from Cadr-5' power.
29-Apr-83 11:27:52-EDT,422;000000000000
Return-path: <DPH@MIT-OZ>
Mail-From: DPH created at 29-Apr-83 11:25:40
Date: Fri, 29 Apr 1983  11:25 EDT
From: DPH@MIT-OZ
To:   bug-hardware@MIT-OZ


Cadr-6 won't boot.  It is getting processor level-2-map parity errors.

CC-SCAN-LEVEL-2-MAP-FOR-BAD-PARITY found bad parity in addresses
10, 250, 251, and 337.

After power cycling and trying to boot again, it found bad level-2-map
parity in address 1577.

 2-May-83 10:23:22-EDT,175;000000000000
Return-path: <CSTACY@MIT-MC>
Date: 2 May 1983 10:16 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC

LM6 dropped dead randomly and wont boot.
 2-May-83 21:17:10-EDT,569;000000000000
Return-path: <ALAN@MIT-OZ>
Mail-From: ALAN created at  2-May-83 21:15:50
Date: Mon, 2 May 1983  21:15 EDT
From: Alan Bawden <ALAN@MIT-OZ>
To:   bug-hardware@MIT-OZ
Subject: [AKR: forwarded]

Date: Monday, 2 May 1983  18:56-EDT
From: AKR
To:   GLR
cc:   Bug-harware
Return-path: <AKR@MIT-OZ>

The main problem on cadr2 that i encountered was a loose
processor ribbon cable or connector.  Shaking the cables
at the bus-interface side will crash the cadr.  I will try
to fix this later this evening.  This problem would always
show up as a disk problem.
 3-May-83 04:06:09-EDT,410;000000000000
Return-path: <AKR@MIT-OZ>
Mail-From: AKR created at  3-May-83 04:01:09
Date: Tue, 3 May 1983  04:01 EDT
From: AKR@MIT-OZ
To:   Bug-hardware@MIT-OZ
Subject: cadr-2


Cadr2 should be more reliable now.  The bus interface had one
flakey socket to chip connection.  The disk drive was moved to the other side,
to prevent it from jumping up and down everytime somone steps on the tile
in front of it.

 3-May-83 15:13:28-EDT,606;000000000000
Return-path: <SOLEY@MIT-MC>
Date: 3 May 1983 14:49 EDT
From: Richard Mark Soley <SOLEY @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC

CADR 15 is not responding to its keyboard.  Some things I know:

(1) It is NOT keyboard.  We switched the PROM on the kbd, tried
    the same kbd out on another CADR, and it's fine.

(2) The video is fine, so it's probably not the cable.

I think it must be a problem in the machine itself; the connections
the machine, however, seem to be okay.

CADR15's console is in 800F.  Please take a look at the machine; it
may just be a bad cable somewhere.

	-- Richard
 3-May-83 20:42:21-EDT,1262;000000000000
Return-path: <LMFile@MIT-OZ>
Date: Tuesday, 3 May 1983, 20:42-EDT
From: File Transfer Login <LMFile@MIT-OZ>
To: BUG-HARDWARE@MIT-OZ


sigh

Machine being debugged is MIT-LISPM-6.
Microcode halted via ILLOP from PAGE-BAND-FLAG+2
Micro PC History (OPC's), oldest first:
   22302   CLEAR-PAGE-BAND-FLAG-REALLY
   22303   (CLEAR-PAGE-BAND-FLAG-REALLY 1)
   22260   PAGE-BAND-FLAG
   22261   (PAGE-BAND-FLAG 1)
   22262   (PAGE-BAND-FLAG 2)
   22263   (PAGE-BAND-FLAG 3)
   00361   ILLOP
   00362   TRAP-NO-VMA
Backtrace of microcode subroutine stack:
    4  022303   (CLEAR-PAGE-BAND-FLAG-REALLY 1)
    3  021645   (SWAPIN2 4)
    2  020721   (PGF-R 3)
    1  004755   (QLENTR 3)
    0  040170   QMLP
Halted due to unexpected page fault, VMA=500123010, maps=5@1/ 5 246@2/ 63200246 ACCESS 3 STATUS 4 META 64 PHYS-PAGE 246 META BIT BREAKDOWN: OLDSPACE 1 EXTRA-PDL 1 REGION-REP 1 UNUSED 0

Current stack group is: <Stack Group MAIN-STACK-GROUP>
Complete backtrace follows: (type Space to stop)

213435 #<DTP-FEF-POINTER SET-SCAVENGER-WS 10204541>[0] 400
213430 #<DTP-FEF-POINTER MACHINE-DEPENDENT-LISP-REINITIALIZE-EARLY 10372600>[211] Error printing debugging information:
  2100011100 ARRAY HEADER NOT DTP-ARRAY-HEADER - QF-ARRAY-SETUP 7-May-83 15:42:14-EDT,170;000000000000
Return-path: <ERIC@MIT-EECS>
Date:  7 May 1983 1453-EDT
From: Eric M. Ostrom <ERIC at MIT-EECS>
Subject: foo
To: bug-hardware at MIT-EECS

This is a test
-------
 7-May-83 15:50:53-EDT,245;000000000000
Return-path: <NIS@MIT-OZ>
Mail-From: NIS created at  6-May-83 21:10:52
Date: Friday, May 6, 1983 9:10PM-EDT
From: H. Keith Nishihara <NIS@MIT-OZ>
Subject: cadr23 down
To: bug-hardware at MIT-OZ

seems one of power strips is bad
--keith
 7-May-83 18:23:51-EDT,601;000000000000
Return-path: <JLK@SCRC-TENEX>
Date: Saturday, 7 May 1983  17:24-EDT
From: JLK at SCRC-TENEX
To:   Eric M. Ostrom <ERIC at MIT-EECS>
Cc:   bug-hardware at MIT-EECS
Subject: foo
In-reply-to: The message of 7 May 1983  14:53-EDT from Eric M. Ostrom <ERIC at MIT-EECS>

    Date: Saturday, 7 May 1983  14:53-EDT
    From: Eric M. Ostrom <ERIC at MIT-EECS>
    To:   bug-hardware at MIT-EECS
    Re:   foo
    Return-path: <ERIC@MIT-EECS>
    Received: from MIT-EECS by SCRC-TENEX with CHAOS; Sat 7-May-83 14:53:15-EDT

    This is a test
Could you take me off this mailing list?  THanks.
 9-May-83 05:19:08-EDT,609;000000000000
Return-path: <Hdt@MIT-OZ>
Date: Monday, 9 May 1983, 05:18-EDT
From: Hdt@MIT-OZ
To: BUG-hardware@MIT-OZ

In HARDWARE in Bad MIT-Specific 19.1,
Inconsistently updated System 94.16, Inconsistently updated ZMail 50.3,
microcode 238, ZM GC@0, on Lisp Machine One:


lm18 died completely while in a process-wait of "keyboard"
It didn't even start to cold boot when I tried, and restarting the
keyboard didn't help.   This is the useless stuff I got from CC;
given the state of the machine, perhaps this really isn't suprising.

Error printing debugging information:
  A-V-NIL's contents are garbage. 9-May-83 10:02:26-EDT,1033;000000000000
Return-path: <DPH@MIT-OZ>
Mail-From: DPH created at  9-May-83 09:58:15
Date: Mon, 9 May 1983  09:58 EDT
From: DPH@MIT-OZ
To:   Hdt@MIT-OZ
Cc:   BUG-hardware@MIT-OZ, bug-hardware@MIT-OZ
In-reply-to: Msg of 9 May 1983 05:18-EDT from Hdt

    Date: Monday, 9 May 1983, 05:18-EDT
    From: Hdt
    To:   BUG-hardware

    In HARDWARE in Bad MIT-Specific 19.1,
    Inconsistently updated System 94.16, Inconsistently updated ZMail 50.3,
    microcode 238, ZM GC@0, on Lisp Machine One:


    lm18 died completely while in a process-wait of "keyboard"
    It didn't even start to cold boot when I tried, and restarting the
    keyboard didn't help.   This is the useless stuff I got from CC;
    given the state of the machine, perhaps this really isn't suprising.

    Error printing debugging information:
      A-V-NIL's contents are garbage.

The error nas nothing to do with cadr18's state.  It is a bug which
AKR reported in CC in system 94.  It makes 94 basically useless for
debugging crashed machines.
10-May-83 18:07:23-EDT,186;000000000000
Return-path: <PGS@MIT-OZ>
Mail-From: PGS created at 10-May-83 18:05:07
Date: Tue, 10 May 1983  18:05 EDT
From: PGS@MIT-OZ
To:   bug-hardware@MIT-OZ

CADR-20 is reportedly broken.
13-May-83 14:48:04-EDT,369;000000000000
Return-path: <JLMK@MIT-MC>
Date: Friday, 13 May 1983, 14:37-EDT
From: Jan Krueger <JLMK at MIT-MC>
Subject: cadr15
To: bug-hardware at oz

Cadr15 is dead.  It will respond to a cold boot from upstairs, but
doesn't respond at all to the keyboard process, except to boot the
keyboard.  Please see  what you can do.
					
					Thanks,
					Jan Krueger
						
15-May-83 02:25:04-EDT,407;000000000000
Return-path: <AKR@MIT-OZ>
Mail-From: AKR created at 15-May-83 02:22:52
Date: Sun, 15 May 1983  02:22 EDT
From: AKR@MIT-OZ
To:   Jan Krueger <JLMK@MIT-MC>
Cc:   bug-hardware@MIT-OZ
Subject: cadr15
In-reply-to: Msg of 13 May 1983 14:37-EDT from Jan Krueger <JLMK at MIT-MC>


Cadr15 worked fine from cadr27's console a few days ago.
I suggest running another keyboard cable if the monitor
works.
16-May-83 20:06:07-EDT,842;000000000000
Return-path: <STRAZ@MIT-OZ>
Mail-From: STRAZ created at 16-May-83 20:00:35
Date: 16 May 1983 2000-EDT
From: Steve Strassmann <STRAZ@MIT-OZ>
To: bug-hardware@MIT-OZ, bug-lispm@MIT-OZ


Cadr-4 (i think), that is, the cadr whose console is just outside 702
is dead.

Cold boot loses. This came about after I set-current-band to be an MIT band.

   1) Why this lossage?
   2) I've seen this on several other machines... Why?
   3) If it's incurable (which I strongly doubt)
      why  not make set-current-band check out first
      whether it's going to get itself into a coma, and if so,
      warn the user.
   4) Set-current-band always pesters you with worrying about changing
      the microcode. Why can't it go ahead and make the change?
      At least, it ought to take Y-or-N instead of YES-or-NO.
      
-------
16-May-83 23:30:56-EDT,1343;000000000000
Return-path: <DPH@MIT-OZ>
Mail-From: DPH created at 16-May-83 23:27:29
Date: Mon, 16 May 1983  23:27 EDT
From: DPH@MIT-OZ
To:   Steve Strassmann <STRAZ@MIT-OZ>
Cc:   bug-hardware@MIT-OZ, bug-lispm@MIT-OZ
In-reply-to: Msg of 16 May 1983  20:00-EDT from Steve Strassmann <STRAZ>

    Date: Monday, 16 May 1983  20:00-EDT
    From: Steve Strassmann <STRAZ>
    To:   bug-hardware, bug-lispm

    Cadr-4 (i think), that is, the cadr whose console is just outside 702
    is dead.

    Cold boot loses. This came about after I set-current-band to be an MIT band.

Fixed in the source.  That band wouldn't boot for me either.  However,
when I copied different LOD and MCR bands into those partitions, the
machine booted, so it looks like the 94 or its microcode that lived
there were bad.

       1) Why this lossage?
       2) I've seen this on several other machines... Why?
       3) If it's incurable (which I strongly doubt)
          why  not make set-current-band check out first
          whether it's going to get itself into a coma, and if so,
          warn the user.

Yow, am I halting yet?

       4) Set-current-band always pesters you with worrying about changing
          the microcode. Why can't it go ahead and make the change?
          At least, it ought to take Y-or-N instead of YES-or-NO.

17-May-83 20:30:05-EDT,4111;000000000000
Return-path: <Hewitt@MIT-OZ>
Date: Tuesday, 17 May 1983, 20:22-EDT
From: Carl Hewitt <Hewitt at MIT-OZ>
Subject: AP1 stopped while running apropos
To: BUG-HARDWARE at MC

In HARDWARE in Release 4.1, System 222.186, Hardcopy 11.14, Zmail 74.43,
LMFS 30.26, site configuration 19, on Lisp Machine Apiary-2:

stopped during processing of apropos.


Machine being debugged is MIT-APIARY-1.
Bus-interface errors since last reset:
  Unibus non-existent device
Disk error: Memory-Parity  Transfer-Aborted
  disk address: UNIT 0 CYLINDER 377 HEAD 2 SECTOR 15 
  last memory address touched by disk = 1077266
Memory parity error physical address = 1077266, data = 36720333502, MD data=NIL
Address is memory board #4, bank #1
The running microcode is version 979.
Checking disk copy of this virtual memory address, even though page is modified.

DISK-CONTROL-STATUS READ-COMPARE-DIFFERENCE ECC-HARD TRANSFER-ABORTED IDLE 
ECC ERROR PATTERN BITS 2374
ECC ERROR BIT POSITION 20047
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 377 HEAD 2 SECTOR 15 
MEMORY-ADDRESS 4377
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

RETRYING 

DISK-CONTROL-STATUS READ-COMPARE-DIFFERENCE ECC-HARD TRANSFER-ABORTED IDLE 
ECC ERROR PATTERN BITS 743
ECC ERROR BIT POSITION 20044
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 377 HEAD 2 SECTOR 15 
MEMORY-ADDRESS 4377
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

RETRYING 

DISK-CONTROL-STATUS READ-COMPARE-DIFFERENCE ECC-HARD TRANSFER-ABORTED IDLE 
ECC ERROR PATTERN BITS 2543
ECC ERROR BIT POSITION 20034
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 377 HEAD 2 SECTOR 15 
MEMORY-ADDRESS 4377
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

RETRYING 

DISK-CONTROL-STATUS READ-COMPARE-DIFFERENCE ECC-HARD TRANSFER-ABORTED IDLE 
ECC ERROR PATTERN BITS 433
ECC ERROR BIT POSITION 20041
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 377 HEAD 2 SECTOR 15 
MEMORY-ADDRESS 4377
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

RETRYING 

DISK-CONTROL-STATUS READ-COMPARE-DIFFERENCE ECC-HARD TRANSFER-ABORTED IDLE 
ECC ERROR PATTERN BITS 1661
ECC ERROR BIT POSITION 20035
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 377 HEAD 2 SECTOR 15 
MEMORY-ADDRESS 4377
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000
Disk data = 3177414777, differs in bit 0, 2-5, 7, 9-11, 13, 15-21, 23, 25-27, 29-31
Assuming there are 8 memory boards
[Warning: I don't think this works for more than 256K]

Level 1 map loaded for the low 256K addresses.
Level 2 map loaded.
The running microcode is version 979.
Microcode halted via ILLOP from FATAL-DISK-ERROR
The running microcode is version 979.
Micro PC History (OPC's), oldest first:
   22603   (LOG-DISK-ERROR 16)
   22516   (DISK-COMPLETION-ERROR 2)
   22517   (DISK-COMPLETION-ERROR 3)
   22520   (DISK-COMPLETION-ERROR 4)
   22563   FATAL-DISK-ERROR
   22564   (FATAL-DISK-ERROR 1)
   00361   ILLOP
   00362   TRAP-NO-VMA
Backtrace of microcode subroutine stack:
   10  023165   CALL-INSTANCE-METHOD
    7  022445   QIBRN
    6  022335   (XSBOXSZ 4)
    5  021531   RCONS-MAYBE-EXTEND-REGION-1
    4  021617   (MAKE-REGION-2 4)
    3  020721   LCONS-N
    2  010361   (XGPN 3)
    1  002736   QMDDL
    0  040170   QMLP
Microcode state flags: microcode interrupt
Current stack group is: <Stack Group MAIN-STACK-GROUP>
Current process is: #<DTP-INSTANCE 2333256>"Initial Process"
Complete backtrace follows: (type Space to stop)

213535 #<DTP-FEF-POINTER APROPOS-1 10334262>[0] MORE-VPOS
213525 #<DTP-FEF-POINTER MAPATOMS 10405155>[70] #<DTP-FEF-POINTER APROPOS-1 10334262> #<PACKAGE "USER" 14423532> NIL
213514 #<DTP-FEF-POINTER MAPATOMS-ALL 10405222>[53] #<DTP-FEF-POINTER APROPOS-1 10334262> #<PACKAGE "USER" 14423532>
213501 #<DTP-FEF-POINTER APROPOS 10334216>[105] LABEL
213452 #<DTP-FEF-POINTER *EVAL 10347534>[653] (APROPOS (QUOTE LABEL))
213414 #<DTP-FEF-POINTER LISP-TOP-LEVEL1 10370450>[210] #<DTP-INSTANCE 20514317>
213410 #<DTP-FEF-POINTER LISP-TOP-LEVEL 10367665>[35]

17-May-83 22:02:19-EDT,544;000000000000
Return-path: <ZVONA@MIT-OZ>
Mail-From: ZVONA created at 17-May-83 21:59:30
Date: Tue, 17 May 1983  21:59 EDT
From: ZVONA@MIT-OZ
To:   bug-apiary-machines@MIT-OZ, bug-pi-3600@MIT-OZ, bug-hardware@MIT-OZ

I don't know where to send this, but:

Carl's 3600 isn't making contact with its disk.  The fep gets repeated
disk ECC errors when doing any disk operations.  This may have
something to do with the fact that the IO card doesn't seem to be
plugged in properly.  Obvious things (powercycling, jiggling the card,
etc) didn't work.
18-May-83 00:15:24-EDT,1112;000000000000
Return-path: <FRED@SCRC-TENEX>
Date: Wednesday, 18 May 1983  00:07-EDT
From: FRED at SCRC-TENEX
To:   ZVONA at MIT-OZ
Cc:   bug-apiary-machines at MIT-OZ, bug-hardware at MIT-OZ,
      bug-pi-3600 at MIT-OZ
In-reply-to: The message of Tue 17 May 1983  21:59 EDT from ZVONA at MIT-OZ


   The I/O board is in fact fully engaged, due to a variation in connectors
the board is artificially longer and does not allow the ejectors to appear
engaged.    fred    Date: Tue, 17 May 1983  21:59 EDT



    From: ZVONA at MIT-OZ
    To:   bug-apiary-machines at MIT-OZ, bug-pi-3600 at MIT-OZ,
          bug-hardware at MIT-OZ
    Return-path: <ZVONA@MIT-OZ>
    Received: from MIT-OZ by SCRC-TENEX with CHAOS; Tue 17-May-83 22:04:34-EDT

    I don't know where to send this, but:

    Carl's 3600 isn't making contact with its disk.  The fep gets repeated
    disk ECC errors when doing any disk operations.  This may have
    something to do with the fact that the IO card doesn't seem to be
    plugged in properly.  Obvious things (powercycling, jiggling the card,
    etc) didn't work.


18-May-83 00:49:36-EDT,776;000000000000
Return-path: <LMFile@MIT-OZ>
Date: Wednesday, 18 May 1983, 00:46-EDT
From: The AI File Server <LMFile@MIT-OZ>
To: BUG-HARDWARE@MIT-OZ

In HARDWARE in MIT-Specific 19.3, Experimental System 94.19,
Experimental ZMail 50.4, Experimental Local-File 44.0, FILE-Server 6.6,
MagTape 14.3, Experimental LFS 2.0, microcode 238, FC,
on Lisp Machine Filecomputer:


Insert your description of the circumstances, and how often the problem occurs:

Cadr-23 disk error.  Mysterious.

Machine being debugged is MIT-LISPM-23.
Disk error: Transfer-Aborted
  disk address: UNIT 0 CYLINDER 0 HEAD 0 SECTOR 0 
  last memory address touched by disk = 345377
Contents of disk error log in debugee's main memory 600-640:
Halted at location 7234 in the microcode bootstrap PROM.
19-May-83 15:55:03-EDT,644;000000000000
Return-path: <NIS@MIT-OZ>
Mail-From: NIS created at 19-May-83 15:50:58
Date: Thursday, May 19, 1983 3:50PM-EDT
From: H. Keith Nishihara <NIS@MIT-OZ>
Subject: cadr24
To: philip at MIT-OZ
CC: bug-hardware at MIT-OZ


cadr 24's disk got messed up and i replaced it with the backup that was left
on top of the disk drive

problem happened when sdt and ngl were trying to do a cc-set-current-band
from cadr3 .. and the disk-label got trashed.   This may have happened before
(ive  noticed that the disk label frequently got garbadge scattered in the comment
fields every time i did a set-current-band over the debug cable)

-keith
19-May-83 19:13:24-EDT,537;000000000000
Return-path: <RMS.G.DULCEY@MIT-OZ>
Mail-From: RMS.G.DULCEY created at 19-May-83 19:07:36
Date: Thu, 19 May 1983  19:07 EDT
From: RMS.G.DULCEY@MIT-OZ
To:   H. Keith Nishihara <NIS@MIT-OZ>
Cc:   bug-hardware@MIT-OZ, philip@MIT-OZ, bug-lispm@MIT-OZ
Subject: cadr24
In-reply-to: Msg of May 19 1983 3:50PM-EDT from H. Keith Nishihara <NIS>

  CADR 24's disk got messed up...

Indeed, CC:SET-CURRENT-BAND has a bug which causes the disk labels it
produces to look ugly.  We have a fix over here at LMI -- it will reach
MIT soon.
19-May-83 19:40:45-EDT,424;000000000000
Return-path: <NIS@MIT-OZ>
Mail-From: NIS created at 19-May-83 19:37:32
Date: Thursday, May 19, 1983 7:37PM-EDT
From: H. Keith Nishihara <NIS@MIT-OZ>
Subject: cadr24
To: bug-hardware at MIT-OZ
CC: ngl at MIT-OZ

something is still not right with cadr24
(cc:cc-test-machine) says its got trouble in shifter ..

the machine dies (warm bootable) when loading various files
like with load-patches  .. sigh

-keith
21-May-83 04:52:58-EDT,1451;000000000000
Return-path: <Wedged-Out@MIT-OZ>
Date: Saturday, 21 May 1983, 04:52-EDT
From: Wedged-Out@MIT-OZ
Subject: Wedged
To: BUG-HARDWARE@MIT-OZ

In HARDWARE in Release 4.1, System 222.186, Hardcopy 11.14, Zmail 74.43,
LMFS 30.26, site configuration 19, Vanilla, on Lisp Machine Apiary-1:

After accidently typing an inappropriate comma in ZTOP mode, getting a
ZWEI:REDISPLAY bug, trying to start up a new editor, got wedged
completely.  After warm-booting, could do nothing.  Message came up
about SIMPLE-PROCESS getting an error.  After second warm-boot,
ZMACS-WINDOW got an error, and the name of a SIMPLE-PROCESS GC-daemon
came up.  Only at this point did the clock and all blinkers stop.

Machine being debugged is MIT-APIARY-2.
Bus-interface errors since last reset:
  Unibus non-existent device
The running microcode is version 979.
This program doesn't understand why the machine stopped (not ILLOP).
The running microcode is version 979.
Micro PC History (OPC's), oldest first:
   00251   (QADR4 1)
   00251   (QADR4 1)
   00251   (QADR4 1)
   00251   (QADR4 1)
   00252   (QADR4 2)
   00253   QEAFE
   00254   (QEAFE 1)
   00255   (QEAFE 2)
Backtrace of microcode subroutine stack:
    1  000441   QIMOVE1
    0  040170   QMLP
Current stack group is: <Stack Group Scheduler>
Current process is: NIL
Complete backtrace follows: (type Space to stop)

11022413 #<DTP-FEF-POINTER PROCESS-SCHEDULER 10454555>[327]

21-May-83 17:13:30-EDT,1198;000000000000
Return-path: <JFC@MIT-OZ>
Mail-From: JFC created at 21-May-83 17:08:56
Date: Sat, 21 May 1983  17:08 EDT
From: JFC@MIT-OZ
To:   H. Keith Nishihara <NIS@MIT-OZ>
Cc:   bug-hardware@MIT-OZ, philip@MIT-OZ
Subject: cadr24
In-reply-to: Msg of May 19 1983 3:50PM-EDT from H. Keith Nishihara <NIS>

    Date: Thursday, May 19, 1983 3:50PM-EDT
    From: H. Keith Nishihara <NIS>
    To:   philip
    cc:   bug-hardware
    Re:   cadr24

    cadr 24's disk got messed up and i replaced it with the backup that was left
    on top of the disk drive

    problem happened when sdt and ngl were trying to do a cc-set-current-band
    from cadr3 .. and the disk-label got trashed.   This may have happened before
    (ive  noticed that the disk label frequently got garbadge scattered in the comment
    fields every time i did a set-current-band over the debug cable)

    -keith

This seems to be a very common problem, I've noticed exactly the same
thing when setting CADR-31's band from CADR-30. Copying a disk partition
over the debug cable seemed to work OK, but when the current band was changed,
the label was messed up. It has also happened between CADR-5 and 25.

 - JfC
23-May-83 13:33:21-EDT,515;000000000000
Return-path: <SAUND@MIT-OZ>
Mail-From: SAUND created at 23-May-83 13:28:48
Date: Monday, May 23, 1983 1:28PM-EDT
From: Eric Saund <SAUND@MIT-OZ>
Subject: CADR-1 problems
To: bug-hardware at MIT-OZ


 CADR-1, running system 93.47, microcode 226, halted several times as I was trying to use
it today, Monday, 5-23-83, 13:20 pm.  Eventually, it would not recover by warm booting,
and it halted again after cold-booting.  Two of the console addresses at which it 
halted are  "23405", and, I think, "00143.".23-May-83 18:23:21-EDT,387;000000000000
Return-path: <NGL@MIT-OZ>
Date: Monday, 23 May 1983, 18:23-EDT
From: Noble G. Larson <NGL@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR1 is dying with "main memory par error from disk"
during booting.  :WHY seems not to know what to do at that stage.
However, CC does mostly work if you use 94.21, which gets around the
A-V-NIL problem (A-V-NIL really is garbage at that stage), or 93.
23-May-83 23:46:06-EDT,805;000000000000
Return-path: <RMS@MIT-OZ>
Date: Monday, 23 May 1983, 23:47-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
Re: lossage on cadr-6
To: bug-hardware@MIT-OZ

I found CADR-6 saying "will not boot a 94 band".
I tried it and it got a c-mem parity error.
The 1000000000000 bit was mistakenly turned on it 636@c.

I cleared this bit and started at COLD-BOOT and it won.

I found that putting the microcode in MCR6 rather than MCR2
caused it to win.

Strangely, comparing the contents of MCR2 with the place I got
the UCADR 239 from returned T.  I cannot understand why, if
the contents compare ok, it would boot right from one and not from the other.

I left MCR2 with "bad" in its label, but the contents are still there.
Perhaps someone should try to figure out why this kind of lossage happens.
24-May-83 01:06:42-EDT,201;000000000000
Return-path: <RMS@MIT-OZ>
Date: Tuesday, 24 May 1983, 01:04-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR-6 crashed again.  I suspect it may be the c-mem chip instead.
24-May-83 03:21:33-EDT,210;000000000000
Return-path: <RMS@MIT-OZ>
Date: Tuesday, 24 May 1983, 03:19-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
To: BUG-hardware@MIT-OZ

CADR1's problem is a parity error, possibly in bit 31,
in board 0, bank 1.
25-May-83 13:38:48-EDT,303;000000000000
Return-path: <STRAZ@MIT-OZ>
Mail-From: STRAZ created at 25-May-83 13:30:57
Date: 25 May 1983 1330-EDT
From: Steve Strassmann <STRAZ@MIT-OZ>
Subject: CADR-6
To: bug-hardware@MIT-OZ


CADR-6 (near the 7th Hammock) is very ill. It runs for almost a minute
after cold-booting, then dies.
-------
25-May-83 15:39:27-EDT,674;000000000000
Return-path: <ALAN@MIT-OZ>
Mail-From: ALAN created at 25-May-83 15:34:54
Date: Wed, 25 May 1983  15:34 EDT
From: Alan Bawden <ALAN@MIT-OZ>
To:   bug-hardware@MIT-OZ
Subject: [PHILIP: Machine will not cold boot]

Date: Wednesday, 25 May 1983  11:41-EDT
From: PHILIP
To:   bug-lispm-hardware
Re:   Machine will not cold boot
Return-path: <PHILIP@MIT-OZ>

CADR-32 on the 3rd floor will not even cold
boot anymore. By power cycling it, it is
sometimes possible to bring it back up
but it crashes in the following minutes.

There is a board in the card cage that
has not been fully inserted. Whether it is
in or out, doesn't seem to help anyway.

Philippe
25-May-83 19:01:57-EDT,673;000000000000
Return-path: <KLOTZ@MIT-OZ>
Mail-From: KLOTZ created at 25-May-83 18:59:03
Date: Wed, 25 May 1983  18:59 EDT
From: Leigh L. Klotz <KLOTZ@MIT-OZ>
To:   bug-hardware@MIT-OZ
Subject:You might find this interesting, especially the last part...

Date: Wednesday, 25 May 1983  11:41-EDT
From: PHILIP
To:   bug-lispm-hardware
Re:   Machine will not cold boot

CADR-32 on the 3rd floor will not even cold
boot anymore. By power cycling it, it is
sometimes possible to bring it back up
but it crashes in the following minutes.

There is a board in the card cage that
has not been fully inserted. Whether it is
in or out, doesn't seem to help anyway.

Philippe
26-May-83 22:46:30-EDT,483;000000000000
Return-path: <LMFile@MIT-OZ>
Date: Thursday, 26 May 1983, 22:44-EDT
From: The AI File Server <LMFile@MIT-OZ>
To: bug-hardware@MIT-OZ

More info on the CADR 6 problem:
I tried it with a different disk pack and it lost the same way.

Also, I found that by patching the losing bit in 636@c to 0
I could get the machine to run.  But it crashed after a while
and that same bit had been clobbered to 1 again.
So the problem does not appear to be connected with booting per se.
28-May-83 20:23:24-EDT,410;000000000000
Return-path: <KLOTZ@MIT-OZ>
Mail-From: KLOTZ created at 28-May-83 20:22:05
Date: Sat, 28 May 1983  20:22 EDT
From: Leigh L. Klotz <KLOTZ@MIT-OZ>
To:   bug-hardware@MIT-OZ
Subject: [GJC: forwarded]

Date: 28 May 1983 19:55 EDT
From: George J. Carrette <GJC at MIT-MC>
To:   BUG-CHAOS at MIT-MC
Received: from MIT-MC by MIT-OZ; Sat 28 May 83 19:56:54-EDT

The route from MC to MARIE or JCF is down.
31-May-83 00:12:07-EDT,767;000000000000
Return-path: <rlh@MIT-EDDIE>
Date: Monday, 30 May 1983, 22:31-EDT
From: Roger L. Hale <rlh at MIT-EDDIE>
To: BUG-Hardware at MIT-OZ

In Hardware in MIT-Specific 19.3, Experimental System 94.18,
Experimental ZMail 50.4, microcode 238, ZM GC@0, on Marvin:

The keyboard now attached to Marvin (according to the writing on the wall,
CADR-14 or 10; under the "Do Not Write or move a band" sign at EECS)
has troubles with a number of keys at its left end:
left-CTRL especially fails to register, and will occasionally
send some bogus characters when you hit it hard enough for it to notice.
TERMINAL and RUBOUT are also dropped sometimes, and during one period
when they were being particularly recalcitrant I also could not
get a W or R to appear easily.
31-May-83 00:12:53-EDT,648;000000000000
Return-path: <rlh@MIT-EDDIE>
Date: Monday, 30 May 1983, 23:25-EDT
From: Roger L. Hale <rlh at MIT-EDDIE>
To: BUG-Hardware at MIT-OZ

In Hardware in MIT-Specific 19.3, Experimental System 94.18,
Experimental ZMail 50.4, microcode 238, ZM GC@0, on Marvin:

(continuing my last message)
The keyboard hung itself up (so that right-CTRL <char> was
simply not getting through; I had previously giving up on
left-CTRL);  resetting it cleared up this trouble and I think
most of the troubles on the left end of the keyboard.
Left-CTRL now registers as CTRL; however, it still generates
^_ or ^H^_ or ^_^H sometimes when it is first pressed.
31-May-83 00:13:38-EDT,1545;000000000000
Return-path: <rlh@MIT-EDDIE>
Date: Monday, 30 May 1983, 23:59-EDT
From: Roger L. Hale <rlh at MIT-EDDIE>
To: BUG-Hardware at MIT-OZ

In Hardware in MIT-Specific 19.3, Experimental System 94.18,
Experimental ZMail 50.4, microcode 238, ZM GC@0, on Marvin:

(third installment on the keyboard)
It is fairly often hanging up so that one or more of
	r, s, thir, <rubout>, (
and perhaps others get thrown away or never seen.
Resetting the keyboard with the black button underneath
cleared the immediate hangup each time but one,
but it reappeared right away elsewhere.  When I checked
the seating of the connectors in back they felt fine
but the check seems to have cleared up this sort of trouble.
Left-CTRL still sporadically drops out in the middle of a
<CTRL>-string lean.

I am having a great deal of trouble right now with various
characters not registering.  A combination of resetting and
wiggling the connector seems to have gotten me out of it
for the moment (surprisingly long - a whole sentence now)
but I can't tell when it may strike again, and sometimes
it persists through a lot of poking.  I have a notion that
it's a bad idea to use the left-CTRL key as it seems to
bring it on? but can't really tell.  It definitely isn't the
only thing that brings it on.  I have gotten to the end or
this paragraph and letter with no further trouble [not meaning
to imply anything for the future:  if there were gremlins
looking over my shoulder I have hereby dissociated myself
from having spoke too soon].  Ah!!
 2-Jun-83 00:50:48-EDT,510;000000000000
Return-path: <PDH@MIT-OZ>
Mail-From: PDH created at  2-Jun-83 00:46:57
Date: Thu, 2 Jun 1983  00:46 EDT
From: PDH@MIT-OZ
To:   Bug-Hardware@MIT-OZ
Subject: Cadr 19: It works but...

its video display has a weird interference that moves from top to bottom
inverting and distorting everything in its path.  The rest of the screen,
however, is very clear and legible.  Fiddling with the potentiometers inside
did not seem to help.

It is better than nothing, but it has a strong annoyance potential.
 3-Jun-83 08:41:00-EDT,714;000000000000
Return-path: <@MIT-MC:RMS@MIT-OZ>
Received: from MIT-MC by MIT-OZ; Fri 3 Jun 83 08:32:55-EDT
Date: Friday, 3 June 1983, 08:03-EDT
From:  <RMS at MIT-OZ>
To: bug-hardware at MIT-OZ

The green light on CADR-18's disk drive is lit all the time.
As a result, when I change packs on that drive I have
to guess when it is ok to open the door.

I don't know whether these disk drives ever refuse to slow
down if they are scared to retract their heads.
That was my first thought when I turned the drive off
and the light did not start flashing.
I was really scared I might hurt it by opening the door,
but that was the only way I could tell if it had stopped.

Presumably the disk people can fix this.

 3-Jun-83 13:54:34-EDT,1576;000000000000
Return-path: <LMFile@MIT-OZ>
Date: Friday, 3 June 1983, 13:53-EDT
From: RpK@MIT-OZ
Sender: LMFile@MIT-OZ
Re: CHAOSNet hardware problems on Lisp Machine Eighteen
To: BUG-Hardware@MIT-OZ
CC: rms@MIT-OZ

[This may have something to do with the disk, but I'm not so
sure.  Here are the symptoms anyway.]

After doing (SETQ LM18-PKT (CHAOS:SIMPLE "LM18")), the response is the
following:

Number: 0 (34657512)  Opcode: 5 (ANS).  Number of bytes = 36 .
From 3076-0 to 3060-10066 .
002400,000036,003060,010066,003076,000000,000000,000000
Pkt number = 0, Ack number = 0, Forwarded 0 times.
Retransmitted 0 times, last at 0.
Link = NIL
  which contains the following string:
"
107 CADR%1's Rgoe p6765
3
<MACRO>-<MACRO>" ; <MACRO> character, actually

It's probably dropping bit #? in either the lower or high byte of the
16-bit word.  Notice:

Character      Codes (octal) Index into packet-string
---------      ------------- ------------------------
9 -> 1         71 ->  61         1
- -> %         55 ->  45         9
o -> g         157 -> 147       15
m -> e         155 -> 145       17
p -> x         156 -> 146       19
Return -> Macro 215 -> 205      27, 29

LM18 will not respond to anything but ANS-response requests.  It can't
get the time when it boots, can't handle FILE protocol (or any kinf of
stream protocol, it seems), and can do RFCs for ANS-responses only
inconsisently. 

Perhaps the reason why some of the bands are bad on the machine is
because they were transferred when the problem was not as
consistent.

``Bob'' 4-Jun-83 11:18:51-EDT,309;000000000000
Return-path: <Zvona@MIT-OZ>
Date: Saturday, 4 June 1983, 11:17-EDT
From: David Chapman <Zvona@MIT-OZ>
To: bug-hardware@MIT-OZ

Where are bug reports on 3600 hardware supposed to go?

ap4 is losing.  It halts randomly often.  In general you can't even log
in.  I haven't tried to isolate the problem.
 5-Jun-83 02:38:39-EDT,205;000000000000
Return-path: <RMS@MIT-OZ>
Date: Sunday, 5 June 1983, 02:34-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
To: bug-hardware@MIT-OZ

I think CADR 18 needs a new disk pack; or at least try reformatting it.
 5-Jun-83 03:08:23-EDT,2839;000000000000
Return-path: <CSTACY@MIT-MC>
Date: 5 June 1983 02:50 EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject:  which mailing list today?
To: BUG-HARDWARE @ MIT-MC, BUG-SYMBOLICS-HARDWARE @ MIT-MC
cc: CSTACY @ MIT-MC, TK @ MIT-MC, HEWITT @ MIT-MC, RIVEST @ MIT-MC,
    DLW @ SCRC-TENEX, RWK @ SCRC-TENEX


Hello,

There has been alot of confusion lately about where to mail Lisp
Machine hardware trouble reports.  In an effort to clear this up, and
make things coherent, I have rearranged the relavent mailing lists.
This message describes how things work under the new scheme.

First, some people were reporting 3600 software reports to random
places.  The place for all Lisp Machine operating software bug
reports is BUG-LISPM.  It does not matter where the machine came
from.  If it is a software problem, send it to BUG-LISPM.

There are two main mailing lists for hardware, both based on OZ.
There should be synonyms on the ITS machines too.

BUG-HARDWARE is the same as BUG-MIT-HARDWARE.
This list is mostly for broken CADRs (Lisp Machines manufactured and
maintained at MIT.)  The hardware staff at the AI lab is on this list.

BUG-SYMBOLICS-HARDWARE is for broken LM-2s and 3600s.
This is seperate from BUG-HARDWARE because the Symbolics computers
are not maintained by our own staff.  There are service contracts
for repairing these machines, and the service people should be on
this list (I think I put them on).

There also some synonyms, like this:
 BUG-CADR ==> BUG-MIT-HARDWARE
 BUG-LM2  ==> BUG-SYMBOLICS-HARDWARE
 BUG-3600 ==> BUG-SYMBOLICS-HARDWARE
 BUG-APIARY-HARDWARE ==> BUG-SYMBOLICS-HARDWARE
 BUG-PI-3600 ==> BUG-SYMBOLCS-HARDWARE

These changes should assure that hardware bug reports go to the
correct place.

If you think you want to be on or off some hardware bug list or
another, or think that another list should be created for some reason,
send me a description of what you want and I'll help you set it up
properly.

Unfortunately, for the moment users will have to remember to send bug
reports to the correct list.  When you pick "Hardware" from the BUG
menu in ZMAIL, you will get BUG-HARDWARE. People will have to manually
change the address to the right one, but that is what they have been
doing anyway.  At least now they dont have to remember n different
mailing list names.

I will try to get the Symbolics people to arrange for a software fix
for this problem: you should get the right mailing list automatically
from ZMAIL.  If nothing is forthcoming, I can kludge it up anyway.
Offhand, I think there should be a HARDWARE-BUG-REPORTS option for
each machine in the site specific information.  If anyone has ideas on
good ways to do this, please send them to me -- let's not start a big
disucssion with all of BUG-HARDWARE(s).

Chris
 6-Jun-83 09:55:02-EDT,518;000000000000
Return-path: <CENT@MIT-ML>
From: CENT@MIT-ML
Date: 06/06/83 04:37:02
Subject: which mailing list today?

CENT@MIT-ML 06/06/83 04:37:02 Re: which mailing list today?
To: CSTACY at MIT-MC
CC: (BUG HARDWARE) at MIT-MC
please note that bug-hardware grew to include all lab hardware problems,
not just lispm lossage. bug-mit-hardware (bug-hardware for short) should
continue to perform this function, except for symbolics-hardware bugs. i
have added edifying comments to this effect in the mailing-lists file..
 8-Jun-83 07:06:56-EDT,2587;000000000000
Return-path: <STRAZ@MIT-OZ>
Date: Wednesday, 8 June 1983, 07:04-EDT
From: Steve Strassmann <STRAZ@MIT-OZ>
To: BUG-hardware@MIT-OZ

In Release 4.1, System 222.186, Hardcopy 11.14, Zmail 74.43, LMFS 30.26,
site configuration 20, on Lisp Machine Four:

This has been happening with more and more annoying regularity. A simple <resume>
recovers, but it usually occurs at the beginning of loading huge files, and it
manifests itself only when I toddle off to the bathroom or someplace.


>>Error: Timeout while waiting for MIT-OZ to connect to contact name O1607.
While in the function (METHOD FS:HOST-UNIT NEW-DATA-CONNECTION)  (METHOD FS:HOST-UNIT GET-DATA-CONNECTION)  (METHOD FS:FILE-HOST-MIXIN GET-DATA-CONNECTION)


(METHOD FS:HOST-UNIT NEW-DATA-CONNECTION): (P.C. = 205)
 (SELF = #<HOST-UNIT 2732006>)
 Arg 0 (OPERATION): NEW-DATA-CONNECTION
 Local 0 (INPUT-HANDLE): "I1606"
 Local 1 (OUTPUT-HANDLE): "O1607"
 Local 2 (PKT): #<CHAOS Packet 2740012>
 Local 3 (ID): "T1608"
 Local 4 (DATA-CONN): NIL
 Local 5 (CONNECTION): #<CHAOS Connection for O1607 to CHAOS|0 2100372>
 Local 6 (STRING): NIL


(METHOD FS:HOST-UNIT NEW-DATA-CONNECTION):  (P.C. = 205)
   (SELF = #<HOST-UNIT 2732006>)
   Arg 0 (OPERATION): NEW-DATA-CONNECTION

(METHOD FS:HOST-UNIT GET-DATA-CONNECTION):  (P.C. = 101)
   (SELF = #<HOST-UNIT 2732006>)
   Arg 0 (OPERATION): GET-DATA-CONNECTION
   Arg 1 (DIRECTION): INPUT

(METHOD FS:FILE-HOST-MIXIN GET-DATA-CONNECTION):  (P.C. = 53)
   (SELF = #<TOPS20-CHAOS-HOST MIT-OZ>)
   Arg 0 (OPERATION): GET-DATA-CONNECTION
   Arg 1 (DIRECTION): INPUT

FS:OPEN-CHAOS:  (P.C. = 450)
   Arg 0 (HOST): #<TOPS20-CHAOS-HOST MIT-OZ>
   Arg 1 (*COMMAND-PATHNAME*): #<TOPS20-PATHNAME "OZ:PS:<STRAZ>LISPM.INIT">
   Arg 2 (OPTIONS): (CHARACTERS DEFAULT)

(METHOD FS:CHAOS-PATHNAME OPEN):  (P.C. = 26)
   (SELF = #<TOPS20-PATHNAME "OZ:PS:<STRAZ>LISPM.INIT">)
   Arg 0 (OPERATION): OPEN
   Arg 1 (PATHNAME): #<TOPS20-PATHNAME "OZ:PS:<STRAZ>LISPM.INIT">
   Rest arg (OPTIONS): (CHARACTERS DEFAULT)

OPEN:  (P.C. = 375)
   Arg 0 (PATHNAME): #<TOPS20-PATHNAME "OZ:PS:<STRAZ>LISPM.INIT">
   Rest arg (KEYWORD-ARGS): (CHARACTERS DEFAULT)

LOAD:  (P.C. = 244)
   Arg 0 (PATHNAME): #<TOPS20-PATHNAME "OZ:PS:<STRAZ>LISPM.INIT">
   Arg 1 (PKG): "USER"
   Arg 2 (NONEXISTENT-OK-FLAG): T
   Arg 3 (DONT-SET-DEFAULT-P): T
   --Defaulted args:--
   Arg 4 (NO-MSG-P): NIL

LOGIN:  (P.C. = 471)
   Arg 0 (USER-NAME): STRAZ
   --Defaulted args:--
   Arg 1 (HOST): #<TOPS20-CHAOS-HOST MIT-OZ>
   Arg 2 (*LOGIN-LOAD-INIT-FILE-P*): T
 8-Jun-83 08:21:45-EDT,364;000000000000
Return-path: <PHILIP@MIT-OZ>
Date: Wednesday, 8 June 1983, 08:22-EDT
From: Philippe Brou <PHILIP@MIT-OZ>
To: BUG-hardware@MIT-OZ

In lispm-hardware in MIT-Specific 18.1, System 93.45, ZMail 49.18,
microcode 226, on Lisp Machine Twenty-three:

BREAK key on this keyboard is bouncy.
(Get 2 to 5 characters even when hit a single time).

Thanks
Philippe
10-Jun-83 02:35:00-EDT,969;000000000000
Return-path: <Moon@SCRC-TENEX>
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 10-Jun-83 02:31:29-EDT
Date: Friday, 10 June 1983, 02:24-EDT
From: David A. Moon <Moon@SCRC-TENEX>
To: Steve Strassmann <STRAZ@MIT-OZ>
Cc: BUG-hardware@MIT-OZ
In-reply-to: The message of 8 Jun 83 07:04-EDT from Steve Strassmann <STRAZ at MIT-OZ>

    Date: Wednesday, 8 June 1983, 07:04-EDT
    From: Steve Strassmann <STRAZ@MIT-OZ>
    In Release 4.1, System 222.186, Hardcopy 11.14, Zmail 74.43, LMFS 30.26,
    site configuration 20, on Lisp Machine Four:

    This has been happening with more and more annoying regularity. A simple <resume>
    recovers, but it usually occurs at the beginning of loading huge files, and it
    manifests itself only when I toddle off to the bathroom or someplace.

    >>Error: Timeout while waiting for MIT-OZ to connect to contact name O1607.

We fixed this bug in Tenex recently.  JTW knows how to fix it in Twenex.
13-Jun-83 16:02:03-EDT,374;000000000000
Return-path: <WELG@MIT-OZ>
Mail-From: WELG created at 13-Jun-83 15:58:42
Date: Monday, June 13, 1983 3:58PM-EDT
From: W. Eric L. Grimson <WELG@MIT-OZ>
Subject: Cadr30
To: bug-hardware at MIT-OZ

Cadr30 appears to be in a fried state.  It will not respond
to a warm boot or a cold one, and moreover, power cycling
the machine does not produce any response.

eric
13-Jun-83 17:27:45-EDT,498;000000000000
Return-path: <ALAN@MIT-OZ>
Mail-From: ALAN created at 13-Jun-83 17:14:19
Date: Mon, 13 Jun 1983  17:14 EDT
From: Alan Bawden <ALAN@MIT-OZ>
To:   bug-symbolics-hardware@MIT-OZ
Cc:   bug-hardware@MIT-OZ
Subject: [chunka: ap2 wedged and refuses to boot]

Date: Monday, 13 June 1983, 15:16-EDT
From: Chunka Mui <chunka>
To:   BUG-apiary
Re:   ap2 wedged and refuses to boot
Return-path: <@MIT-XX:chunka@MIT-OZ>

Lisp Machine Apiary-2 is wedged and refuses to boot.



	chunka@mit-oz
14-Jun-83 02:53:23-EDT,263;000000000000
Return-path: <PGS@MIT-OZ>
Date: Tuesday, 14 June 1983, 02:38-EDT
From: Patrick Sobalvarro <PGS@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR-30 is broken; gets parity errors while writing to the page partition
during boot.  I don't think this is the disk's fault.
15-Jun-83 01:59:23-EDT,308;000000000000
Return-path: <PGS@MIT-OZ>
Date: Wednesday, 15 June 1983, 01:58-EDT
From: Patrick Sobalvarro <PGS@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR31 seems to have a bad memory chip or something; it wedges every once in a
while, causing Eric Grimson's long-running crunchers to be lost (it can't be
warm-booted).
15-Jun-83 10:18:06-EDT,613;000000000000
Return-path: <Kahle@MIT-OZ>
Date: Wednesday, 15 June 1983, 10:11-EDT
From: Brewster Kahle <Kahle@MIT-OZ>
To: BUG-hardware@MIT-OZ

In MIT-Specific 18.1, System 93.45, ZMail 49.19,
Experimental DAEDALUS 2.4, Experimental Nodes 2.7, microcode 226,
Exp Daed, on Lisp Machine Eight:

This machine has the feature that it freeses regularly.
Taft suspects that microcode hardware. (or something like that)
In any case the machine will freeze in the middle of idling
or any generic instructions.  Warm booting brings it back.

Has anyone looked at this problem?

Should I leave it frozen?

-brewster

15-Jun-83 16:48:03-EDT,385;000000000000
Return-path: <RPK@MIT-OZ>
Mail-From: RPK created at 15-Jun-83 16:42:22
Date: 15 Jun 1983  16:42 EDT (Wed)
From: Robert P. Krajewski <RPK@MIT-OZ>
To:   BUG-HARDWARE@MIT-OZ
Subject: CADR1 will not boot

PC stopped at 23563 when attempting to boot.  It's currently slaved to
CADR18.  You can print out the disk label alright.

Also, a fan on CADR5 has bit the dust.

``Bob''
19-Jun-83 19:07:36-EDT,306;000000000000
Return-path: <PGS@MIT-OZ>
Date: Sunday, 19 June 1983, 19:06-EDT
From: Patrick Sobalvarro <PGS@MIT-OZ>
To: bug-hardware@MIT-OZ

31 won't boot; seems to have disk problems of some sort.  Halts at 29 in the
prom with an unexpected page fault.  print-disk-label fails multiple times
before succeeding.
23-Jun-83 10:35:11-EDT,246;000000000000
Return-path: <KAHLE@MIT-OZ>
Mail-From: KAHLE created at 23-Jun-83 10:33:39
Date: Thu, 23 Jun 1983  10:33 EDT
From: KAHLE@MIT-OZ
To:   bug-hardware@MIT-OZ
Subject: cadr-2's (((( key

Cadr-2's 9 key is not debounced anymore.

-brewster

26-Jun-83 05:55:31-EDT,323;000000000000
Return-path: <RMS@MIT-OZ>
Mail-From: RMS created at 26-Jun-83 05:51:29
Date: 26 Jun 1983 0551-EDT
From: RMS@MIT-OZ
To: bug-hardware@MIT-OZ

CADR18's disk is incompatible with other disks.
A pack with data that reads ok on CADR18 does not read
on CADR5 or CADR25.
Probably the disk needs to be realigned.
-------
 3-Jul-83 17:14:15-EDT,684;000000000000
Return-path: <dph@MIT-SPEECH>
Date: Sunday, 3 July 1983, 17:06-EDT
From: Daniel Huttenlocher <dph at MIT-SPEECH>
Subject: TOTO subnet 26 lossage
To: bug-hardware at oz, net-hackers at ee

Network performance on Subnet 26 was horrible on Sunday afternoon.  The
problem seems to be with TOTO.  It's los, crc and random error counts
were high and rapidly increasing, while XI's were low and stable.  I
disconnected the cable between TOTO and it's subnet 26 ethernet
transciever (at the transciever end).  Net performance on the subnet is
now much better.  Can someone who knows more about ethernet boards check
it out (or tell me where I can find another one to swap with).
 3-Jul-83 21:52:13-EDT,1250;000000000000
Return-path: <DCP@SCRC-POINTER>
Received: from SCRC-CHARLES by SCRC-TENEX with CHAOS; Sun 3-Jul-83 21:45:34-EDT
Date: Sunday, 3 July 1983, 21:44-EDT
From: David C. Plummer <DCP@scrc-pointer>
Subject: TOTO subnet 26 lossage
To: dph@MIT-SPEECH, bug-hardware@MIT-OZ, net-hackers@MIT-EECS
In-reply-to: The message of 3 Jul 83 17:06-EDT from Daniel Huttenlocher <dph at MIT-SPEECH>

    Date: Sunday, 3 July 1983, 17:06-EDT
    From: Daniel Huttenlocher <dph at MIT-SPEECH>
    Network performance on Subnet 26 was horrible on Sunday afternoon.  The
    problem seems to be with TOTO.  It's los, crc and random error counts
    were high and rapidly increasing, while XI's were low and stable.  I
    disconnected the cable between TOTO and it's subnet 26 ethernet
    transciever (at the transciever end).  Net performance on the subnet is
    now much better.  Can someone who knows more about ethernet boards check
    it out (or tell me where I can find another one to swap with).
I should learn to use net-hackers.  Yes, I came to the same conclusions,
and was actually wondering who did the disconection.  For those on
MIT-Network-Group you saw my theory of how the board is losing.  Eric
should have some Interlans to swap in.
 7-Jul-83 22:08:43-EDT,402;000000000000
Return-path: <LMFile@MIT-OZ>
Date: Thursday, 7 July 1983, 22:06-EDT
From: rms@MIT-OZ
Sender: LMFile@MIT-OZ
To: bug-hardware@MIT-OZ

Cadr 6 (processor says cadr 7) was getting parity errors
in board 0 bank 0 while booting.
I removed that board and moved another board to that
address in memory, but it still gets the same errors.
The board I pulled is XMEM #5, now sitting on the disk drive.
10-Jul-83 19:28:27-EDT,603;000000000000
Return-path: <saz@MIT-OZ>
Date: Sunday, 10 July 1983, 19:25-EDT
From: David M. J. Saslav <saz@MIT-OZ>
To: BUG-Hardware@MIT-OZ

In Hardware in MIT-Specific 19.5, System 94.34, ZMail 50.15,
microcode 239, ZM GC@0, on Lisp Machine Nine:

In order to boot to either band one or two on this machine
(cadr 9) (the MIT bands) I had to cold-boot, cold-boot again,
WARM-boot, then do a third cold-boot!  The first three operations
resulted in a frozen terminal.  This is undoubtedly a microcode
problem.  I'm putting a sign on this machine warning users not to
use the MIT systems on this machine.  12-Jul-83 09:19:03-EDT,408;000000000000
Return-path: <NIS@MIT-OZ>
Mail-From: NIS created at 12-Jul-83 09:18:26
Date: Tuesday, July 12, 1983 9:18AM-EDT
From: H. Keith Nishihara <NIS@MIT-OZ>
Subject: cadr24
To: bug-hardware at MIT-OZ

its not booting .. ran cc-test-machine from cadr3 and get
message about lc not incrementing properly .. i remember seeing
this message several times in the past when problems
occured with cadr24
--keith
12-Jul-83 16:06:55-EDT,249;000000000000
Return-path: <BATALI@MIT-OZ>
Mail-From: BATALI created at 12-Jul-83 12:46:51
Date: Tue, 12 Jul 1983  12:46 EDT
From: BATALI@MIT-OZ
To:   bug-hardware@MIT-OZ
Subject: Cadr-8

Is fried.  Won't finish cold-booting.  Power-cycling doesn't help.
14-Jul-83 00:38:12-EDT,453;000000000000
Return-path: <LMFile@MIT-OZ>
Date: Thursday, 14 July 1983, 00:31-EDT
From: The AI File Server <LMFile@MIT-OZ>
To: BUG-HARDWARE@MIT-OZ

In HARDWARE in MIT-Specific 19.5, System 94.35, ZMail 50.16,
Experimental Local-File 44.3, FILE-Server 6.6, MagTape 14.4,
Experimental LFS 2.3, microcode 238, FC, on Lisp Machine Filecomputer:


Cadr-20 has a main memory parity error, according to CC.
It wedges, warm bootably.  PC=173377, OBUS=36677777777.14-Jul-83 01:18:54-EDT,416;000000000000
Return-path: <KLOTZ@MIT-OZ>
Mail-From: KLOTZ created at 14-Jul-83 01:15:25
Date: Thursday, July 14, 1983 1:15AM-EDT
From: Leigh L. Klotz <KLOTZ@MIT-OZ>
Subject: cadr-20
To: bug-hardware at MIT-OZ

Maybe I don't know how to use CC.  It's still reporting "Main memory
parity error" at the same location, but the machine is running.  It
definitely did wedge before, twice while running and once while paging.
14-Jul-83 15:02:33-EDT,533;000000000000
Return-path: <HQM@MIT-OZ>
Date: Thursday, 14 July 1983, 14:56-EDT
From: Henry Minsky <HQM@MIT-OZ>
To: BUG-Hardware@MIT-OZ

In Hardware in MIT-Specific 19.4, System 94.26, ZMail 50.10,
Experimental Local-File 44.1, Experimental DAEDALUS 3.0, Nodes 2.7,
microcode 239, GC@0, on Lisp Machine Two:

cadr 2's keyboard does double and triple left-parens
(((((( when you strike it. (the shift-9 key, rather than the
unshifted paren)

I have never got out of the habit of shifting to type my parens,
so this is really annoying.18-Jul-83 21:06:39-EDT,363;000000000000
Return-path: <RMS@MIT-LISPM-27>
Date: Sunday, 17 July 1983, 04:49-EDT
From:  <RMS at FC>
To: bug-hardware at oz

I think I just got a disk error swapping on CADR9.
At least, the machine died with the disk bar lit
at a time when I was not doing anything that ought to
refer to any other disk partition.  I didn't want to
go to the 9th floor to debug it.
18-Jul-83 21:16:53-EDT,857;000000000000
Return-path: <RG.JMTURN@MIT-OZ>
Mail-From: RG.JMTURN created at 18-Jul-83 21:13:59
Date: Mon, 18 Jul 1983  21:13 EDT
From: RG.JMTURN@MIT-OZ
To:   The AI File Server <LMFile@MIT-OZ>
Cc:   BUG-HARDWARE@MIT-OZ
In-reply-to: Msg of 14 Jul 1983 00:31-EDT from The AI File Server <LMFile>

    Date: Thursday, 14 July 1983, 00:31-EDT
    From: The AI File Server <LMFile>
    To:   BUG-HARDWARE

    In HARDWARE in MIT-Specific 19.5, System 94.35, ZMail 50.16,
    Experimental Local-File 44.3, FILE-Server 6.6, MagTape 14.4,
    Experimental LFS 2.3, microcode 238, FC, on Lisp Machine Filecomputer:


    Cadr-20 has a main memory parity error, according to CC.
    It wedges, warm bootably.  PC=173377, OBUS=36677777777.

You have your debug cable backwards (it looks like), You should never
see PC >16K (decimal) on a CADR.

					James
19-Jul-83 09:17:22-EDT,641;000000000000
Return-path: <PGS@MIT-MC>
Date: 19 July 1983 09:16 EDT
From: Patrick G. Sobalvarro <PGS @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC

I fixed CADR-31 (wasn't hard; spent a long time screwing with cables and
straightening pins with a needle-nosed pliers) and put up a nice sign in the
machine room for air conditioning repairmen:

If you want to move one of the computers, get someone to help you.  If you
are in a hurry, ask yourself these questions: How many $100K worth of
insurance does your company have?  Will they be angry at you when they have
to spend it all in one place?

Perhaps every machine room should have one of these.
19-Jul-83 13:38:20-EDT,313;000000000000
Return-path: <PGS@MIT-HEPHAESTUS>
Date: 18 July 1983 18:45 EDT
From: PGS@MIT-HEPHAESTUS @ MIT-MC
To: BUG-HARDWARE @ MIT-MC

CADR-31 is down.  The disk cables are yanked out, pins bent.  I asked the
air conditioning repairman what he knew about it, he claimed nothing.
I am going home; otherwise I'd fix it.19-Jul-83 13:44:07-EDT,340;000000000000
Return-path: <KLOTZ@MIT-MC>
Date: 18 July 1983 20:18 EDT
From: Leigh L. Klotz <KLOTZ @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC

Cadr-20, now with 448K, is still losing.  It conses for about 45 minutes
now before losing.

Are these the symptoms of trying to hang too much memory off the thing,
or are they just two flakey memory boards?
19-Jul-83 19:58:33-EDT,615;000000000000
Return-path: <LEVITT@MIT-OZ>
Date: Tuesday, 19 July 1983, 18:39-EDT
From: David A. Levitt <LEVITT@MIT-OZ>
Subject: CADR4 very unreliable - needs a disk check
To: bug-hardware@MIT-OZ
Cc: kdf@MIT-OZ


In intervals ranging between a half hour and a day, whether it's being
used or not CADR4 has frozen in TYI with the run bar on, requiring cold
boot.  (CC:SALVAGE-EDITOR) can be done from CADR-8 first.

KDF left a note on by the console when this first began happening 3 days
ago, but I don't believe it was reported to BUG-HARDWARE.  Has it been
checked out or fixed?  Apparently it's a disk problem.
20-Jul-83 11:00:14-EDT,425;000000000000
Return-path: <PGS@MIT-MC>
Date: 20 July 1983 09:11 EDT
From: Patrick G. Sobalvarro <PGS @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC

I spoke to John Purbrick about mice again.  He is going to order ten mice
from the mouse house, with appropriate connectors for CADRs and 3600s.
Incidentally, I noticed a 3600 console upstairs with a Purbrick mouse on it.
3600s seem to lose mice pretty fast.  Where the hell are they going?
24-Jul-83 04:06:23-EDT,325;000000000000
Return-path: <rms@MIT-OZ>
Date: Sunday, 24 July 1983, 04:00-EDT
From: Richard M. Stallman <rms@MIT-OZ>
To: BUG-hardware@MIT-OZ

In hardware in MIT-Specific 19.5, System 94.32, ZMail 50.13,
microcode 239, uC239, on Lisp Machine Twenty-five:


CADR1 died with cmem par err at 7047@c,
which contained 200000217170644 .25-Jul-83 02:29:42-EDT,395;000000000000
Return-path: <RMS@MIT-OZ>
Date: Monday, 25 July 1983, 02:29-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR18 is stopping in weird ways.
In one instance, it seemed that a CALL-EQUAL M-T A-V-NIL ILLOP
had called ILLOP even though the args were not equal.
I made it do that instruction over and it did not ILLOP again,
but it halted somewhere else.  So I gave up.26-Jul-83 05:30:58-EDT,247;000000000000
Return-path: <RMS@MIT-OZ>
Date: Tuesday, 26 July 1983, 05:26-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR4 got a parity error, board 5 bank 3.
I cannot tell what bit because the person on CADR8 is using brand S.
28-Jul-83 00:35:56-EDT,1531;000000000001
Return-path: <rms@MIT-OZ>
Date: Thursday, 28 July 1983, 00:31-EDT
From: Richard M. Stallman <rms@MIT-OZ>
To: BUG-HARDWARE@MIT-OZ

CADR 8 crashed twice in an hour and a half.  (debugging from CADR4).
Note that 260 is the vector address for the keyboard.
I found the keyboard unibus channel is set up correctly
together with 260 as the vector address in the proper place (location 502).
So either the memory reference failed to read that word properly,
or the (JUMP-NOT-EQUAL MD A-B INTR-0) at INTR-0 plus 6 executed wrong.
MD was clobbered since that instruction so I can't tell which.
M-B does contain 260.

I restarted at INTR-0 minus one and stepped.  It worked properly this time.


Machine being debugged is MIT-LISPM-8.
Bus-interface errors since last reset:
  Parity error in data from processor
Microcode halted via ILLOP from INTR-0+3
Micro PC History (OPC's), oldest first:
   23740   INNUBI
   23720   INTR-0
   23721   (INTR-0 1)
   23722   (INTR-0 2)
   23723   (INTR-0 3)
   23724   (INTR-0 4)
   00023   ILLOP
   00024   XWIPM
Backtrace of microcode subroutine stack:
    2  005655   (QCAR4 1)
    1  007640   AREFI-RETURN
    0  040144   QMLP
Microcode state flags: microcode interrupt
Interrupt from unknown Unibus device, vector=260

Current stack group is: <Stack Group Scheduler>
Current process is: NIL
Complete backtrace follows: (type Space to stop)

7000063 #<DTP-FEF-POINTER BLINKER-CLOCK 12711145>[0] 1
7000010 #<DTP-FEF-POINTER PROCESS-SCHEDULER 1700652>[214]

 2-Aug-83 11:15:45-EDT,356;000000000000
Return-path: <NIS@MIT-OZ>
Mail-From: NIS created at  2-Aug-83 11:15:17
Date: Tuesday, August 2, 1983 11:15AM-EDT
From: H. Keith Nishihara <NIS@MIT-OZ>
Subject: cadr-24
To: bug-hardware at MIT-OZ

cadr-24 has been quite flaky and dies quite reguarly from typing at
its terminal etc 
 -- let me know if i can help with locating
it trouble --keith
 2-Aug-83 15:21:59-EDT,281;000000000000
Return-path: <TC@MIT-OZ>
Mail-From: TC created at  2-Aug-83 15:16:52
Date:  2 Aug 1983 1516-EDT
From: TC@MIT-OZ
Subject: cadr 24
To: bug-hardware@MIT-OZ
cc: nis@MIT-OZ

      JOHN HOLDEN WILL BE IN THURSDAY OR
FRIDAY.TO LOOK AT THE HEAD ALIGNMENT ON
THE T-300.
-------
 3-Aug-83 23:38:25-EDT,2775;000000000000
Return-path: <rpk@MIT-OZ>
Date: Wednesday, 3 August 1983, 23:34-EDT
From: Robert P. Krajewski <rpk@MIT-OZ>
To: BUG-HARDWARE@MIT-OZ

In HARDWARE in MIT-Specific 19.5, System 94.35, ZMail 50.16,
Experimental Local-File 44.3, FILE-Server 6.6, MagTape 14.4,
Experimental LFS 2.3, microcode 238, FC, on Lisp Machine Filecomputer:


Insert your description of the circumstances, and how often the problem occurs:

Cadr2 froze on loading a file.  :STKP wasn't very helpful.

Machine being debugged is MIT-LISPM-2.
This program doesn't understand why the machine stopped (not ILLOP).

Micro PC History (OPC's), oldest first:
   22603   (PHTDEL3 2)
   22516   (COREF-CCW-0 10)
   22517   (COREF-CCW-0 11)
   22520   (COREF-CCW-0 12)
   22563   (COREF-CCW-X 14)
   22564   (COREF-CCW-X 15)
   00361   (XLOCATE-IN-HIGHER-CONTEXT 2)
   00362   XLOCATE-IN-HIGHER-CONTEXT-1
Backtrace of microcode subroutine stack:
   11  025351   (COLD-AWAIT-DISK 1)
   10  025762   (DISK-COPY-PART-3 10)
    7  025311   DISK-RR-2
    6  000000   ZERO
    5  000000   ZERO
    4  000000   ZERO
    3  000000   ZERO
    2  000000   ZERO
    1  000000   ZERO
    0  000000   ZERO

DISK-CONTROL-STATUS READ-COMPARE-DIFFERENCE NXM TRANSFER-ABORTED IDLE 
ECC ERROR PATTERN BITS 3015
ECC ERROR BIT POSITION 333
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 1112 HEAD 3 SECTOR 5 
MEMORY-ADDRESS 6757400
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 6757400

RETRYING 

DISK-CONTROL-STATUS READ-COMPARE-DIFFERENCE NXM TRANSFER-ABORTED IDLE 
ECC ERROR PATTERN BITS 3406
ECC ERROR BIT POSITION 334
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 1112 HEAD 3 SECTOR 5 
MEMORY-ADDRESS 6757400
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 6757400

RETRYING 

DISK-CONTROL-STATUS READ-COMPARE-DIFFERENCE NXM TRANSFER-ABORTED IDLE 
ECC ERROR PATTERN BITS 3015
ECC ERROR BIT POSITION 333
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 1112 HEAD 3 SECTOR 5 
MEMORY-ADDRESS 6757400
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 6757400

RETRYING 

DISK-CONTROL-STATUS READ-COMPARE-DIFFERENCE NXM TRANSFER-ABORTED IDLE 
ECC ERROR PATTERN BITS 3015
ECC ERROR BIT POSITION 333
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 1112 HEAD 3 SECTOR 5 
MEMORY-ADDRESS 6757400
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 6757400

RETRYING 

DISK-CONTROL-STATUS READ-COMPARE-DIFFERENCE NXM TRANSFER-ABORTED IDLE 
ECC ERROR PATTERN BITS 3015
ECC ERROR BIT POSITION 333
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 1112 HEAD 3 SECTOR 5 
MEMORY-ADDRESS 6757400
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 6757400
Error printing debugging information:
  500000000 NOT AN ARRAY-POINTER - QF-ARRAY-SETUP 3-Aug-83 23:38:53-EDT,1239;000000000000
Return-path: <rpk@MIT-OZ>
Date: Wednesday, 3 August 1983, 23:36-EDT
From: Robert P. Krajewski <rpk@MIT-OZ>
To: BUG-HARDWARE@MIT-OZ

In HARDWARE in MIT-Specific 19.5, System 94.35, ZMail 50.16,
Experimental Local-File 44.3, FILE-Server 6.6, MagTape 14.4,
Experimental LFS 2.3, microcode 238, FC, on Lisp Machine Filecomputer:


Insert your description of the circumstances, and how often the problem occurs:

Tried to boot Lm2 after previous message.

Machine being debugged is MIT-LISPM-2.
Microcode halted via ILLOP from BEG03+1
Micro PC History (OPC's), oldest first:
   25567   (BEGCM3 2)
   25570   BEGCM4
   25571   (BEGCM4 1)
   25572   BEG03
   25573   (BEG03 1)
   25574   (BEG03 2)
   00023   ILLOP
   00024   XWIPM
Backtrace of microcode subroutine stack:
    6  025351   (COLD-AWAIT-DISK 1)
    5  025757   (DISK-COPY-PART-3 5)
    4  025311   DISK-RR-2
    3  000000   ZERO
    2  000000   ZERO
    1  000000   ZERO
    0  000000   ZERO
Halted due to unexpected page fault, VMA=1000, maps=0@1/ 0 2@2/ 0 ACCESS 0 STATUS 0 META 0 PHYS-PAGE 0 META BIT BREAKDOWN: OLDSPACE 0 EXTRA-PDL 0 REGION-REP 0 UNUSED 0
Error printing debugging information:
  577777775 NOT AN ARRAY-POINTER - QF-ARRAY-SETUP 4-Aug-83 23:17:46-EDT,361;000000000000
Return-path: <RMS@MIT-OZ>
Date: Thursday, 4 August 1983, 18:20-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
To: BUG-hardware@MIT-OZ

In hardware in MIT-Specific 19.5, System 94.38, ZMail 50.17,
Experimental Local-File 44.3, microcode 239, gc@34,
on Lisp Machine Two:


CADR27 got a parity error in board 3 bank 0.
It was not possible to tell which bit. 4-Aug-83 23:28:08-EDT,504;000000000000
Return-path: <RMS@MIT-OZ>
Date: Thursday, 4 August 1983, 22:50-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
To: BUG-HARDWARE@MIT-OZ

Machine being debugged is MIT-LISPM-5.
Processor error:
  Main-memory parity error
Bus-interface errors since last reset:
  Xbus data parity error
Memory parity error physical address = 150346, data = 7001212023, MD data=7001212023
Address is memory board #0, bank #3
Checking disk copy of this virtual memory address
Disk data = 7001212021, differs in bit 1
14-Aug-83 17:04:19-EDT,307;000000000000
Return-path: <CRE@MIT-ML>
Date: 14 August 1983 17:00 EDT
From: Christopher R. Eliot <CRE @ MIT-ML>
To: BUG-HARDWARE @ MIT-ML

With the dover down I am wondering why we have our second dover doing
nothing useful? It has been sitting in the cellar for MONTHS. 
Who is responsible for this stupidity????14-Aug-83 19:49:25-EDT,239;000000000000
Return-path: <DPH@MIT-OZ>
Mail-From: DPH created at 14-Aug-83 19:45:57
Date: Sunday, August 14, 1983 7:45PM-EDT
From: Daniel Huttenlocher <DPH@MIT-OZ>
Subject: cadr4
To: bug-hardware at MIT-OZ

Video on cadr-4 is completely scrod.
14-Aug-83 21:09:22-EDT,368;000000000000
Return-path: <PDH@MIT-OZ>
Mail-From: PDH created at 14-Aug-83 21:08:15
Date: Sun, 14 Aug 1983  21:08 EDT
Message-ID: <[MIT-OZ].PDH.14-Aug-83 21:08:14>
From: PDH@MIT-OZ
To:   Bug-Hardware@MIT-OZ, Music-Hackers@MIT-OZ
Subject: Cadr-9 on Seventh Floor

I just got done moving Cadr-9 into the seventh floor machine room.  Everything
seems to be working fine. 

15-Aug-83 04:01:36-EDT,3325;000000000000
Return-path: <tim@MIT-OZ>
Date: Monday, 15 August 1983, 04:00-EDT
From: Tim McNerney <tim@MIT-OZ>
To: BUG-HARDWARE@MIT-OZ

In HARDWARE in MIT-Specific 19.5, System 94.39, ZMail 50.17,
microcode 239, gc@34, on Lisp Machine Eight:


Insert your description of the circumstances, and how often the problem occurs:



Machine being debugged is MIT-LISPM-9.
Bus-interface errors since last reset:
  Xbus non-existent memory or device
  Xbus data parity error
Disk error: Nonexistent-Memory  Transfer-Aborted
  disk address: UNIT 0 CYLINDER 10 HEAD 3 SECTOR 1 
  last memory address touched by disk = 4600400
Contents of disk error log in debugee's main memory 600-640:

Command 11 (Write) 
CCW-list pointer 10000 (low 16 bits)
Disk address: unit 0, cylinder 103, head 1, block 6 (0 67 1 6 decimal)
Memory address: 223020 (type bits 0)
Status: 621020011  Read-compare  Header-Compare  Transfer-Aborted (or wr. ovr.)  Interrupt
          Idle

Command 11 (Write) 
CCW-list pointer 10000 (low 16 bits)
Disk address: unit 0, cylinder 103, head 1, block 16 (0 67 1 14 decimal)
Memory address: 227020 (type bits 0)
Status: 1621020011  Read-compare  Header-Compare  Transfer-Aborted (or wr. ovr.)  Interrupt
          Idle

Command 11 (Write) 
CCW-list pointer 10000 (low 16 bits)
Disk address: unit 0, cylinder 103, head 1, block 11 (0 67 1 9 decimal)
Memory address: 224420 (type bits 0)
Status: 1160420011  Internal-parity  Read-compare  Header-ECC  Transfer-Aborted (or wr. ovr.)
          Interrupt  Idle

Command 11 (Write) 
CCW-list pointer 10000 (low 16 bits)
Disk address: unit 0, cylinder 103, head 1, block 16 (0 67 1 14 decimal)
Memory address: 227020 (type bits 0)
Status: 1621020011  Read-compare  Header-Compare  Transfer-Aborted (or wr. ovr.)  Interrupt
          Idle

Command 11 (Write) 
CCW-list pointer 10000 (low 16 bits)
Disk address: unit 0, cylinder 103, head 1, block 16 (0 67 1 14 decimal)
Memory address: 227020 (type bits 0)
Status: 1621020011  Read-compare  Header-Compare  Transfer-Aborted (or wr. ovr.)  Interrupt
          Idle

Command 11 (Write) 
CCW-list pointer 10000 (low 16 bits)
Disk address: unit 0, cylinder 103, head 1, block 15 (0 67 1 13 decimal)
Memory address: 226420 (type bits 0)
Status: 1561020011  Internal-parity  Read-compare  Header-Compare
          Transfer-Aborted (or wr. ovr.)  Interrupt  Idle
This program doesn't understand why the machine stopped (not ILLOP).

Micro PC History (OPC's), oldest first:
   23620   (XDSKOP 13)
   23621   (XDSKOP 14)
   23622   (XDSKOP 15)
   23623   (XDSKOP 16)
   23624   (XDSKOP 17)
   23625   (XDSKOP 20)
   23626   (XDSKOP 21)
   23627   XDSKOP2
Backtrace of microcode subroutine stack:
   23  025352   (COLD-AWAIT-DISK 2)
   22  025762   (DISK-COPY-PART-3 10)
   21  025311   DISK-RR-2
   20  000000   ZERO
   17  000000   ZERO
   16  000000   ZERO
   15  000000   ZERO
   14  000000   ZERO
   13  000000   ZERO
   12  000000   ZERO
   11  000000   ZERO
   10  000000   ZERO
    7  000000   ZERO
    6  000000   ZERO
    5  000000   ZERO
    4  000000   ZERO
    3  000000   ZERO
    2  000000   ZERO
    1  000000   ZERO
    0  000000   ZERO
Error printing debugging information:
  2101240023 ARRAY HEADER NOT DTP-ARRAY-HEADER - QF-ARRAY-SETUP15-Aug-83 04:12:57-EDT,401;000000000000
Return-path: <TIM@MIT-OZ>
Mail-From: TIM created at 15-Aug-83 04:11:43
Date: Mon, 15 Aug 1983  04:11 EDT
Message-ID: <[MIT-OZ].TIM.15-Aug-83 04:11:42>
From: TIM@MIT-OZ
To:   PDH@MIT-OZ
Cc:   Bug-Hardware@MIT-OZ, Music-Hackers@MIT-OZ
Subject: Cadr-9 on Seventh Floor
In-reply-to: Msg of 14 Aug 1983  21:08-EDT from PDH

Oh well, Cadr-9 died shortly after being transplanted. (See bug mail).
15-Aug-83 08:46:52-EDT,738;000000000000
Return-path: <PGS@MIT-MC>
Date: 15 August 1983 08:45 EDT
From: Patrick G. Sobalvarro <PGS @ MIT-MC>
To: CRE @ MIT-ML
cc: BUG-HARDWARE @ MIT-ML
In-reply-to: Msg of 14 Aug 1983 17:00 EDT from Christopher R. Eliot <CRE at MIT-ML>

    Date: 14 August 1983 17:00 EDT
    From: Christopher R. Eliot <CRE at MIT-ML>
    To:   BUG-HARDWARE at MIT-ML

    With the dover down I am wondering why we have our second dover doing
    nothing useful? It has been sitting in the cellar for MONTHS. 
    Who is responsible for this stupidity????

Certainly no one on BUG-HARDWARE, which usually is limited to discussing
broken Lisp Machines (and occasionally network hardware).  This sounds like a
problem for Big Mike or Little Al.

15-Aug-83 22:58:21-EDT,1269;000000000000
Return-path: <CENT@MIT-ML>
Date: 15 August 1983 22:50 EDT
From: Pandora B. Berman <CENT @ MIT-ML>
Subject: purpose of bug-hardware
To: PGS @ MIT-MC
cc: BUG-HARDWARE @ MIT-ML

    Date: 15 August 1983 08:45 EDT
    From: Patrick G. Sobalvarro <PGS @ MIT-MC>

	Date: 14 August 1983 17:00 EDT
	From: Christopher R. Eliot <CRE at MIT-ML>
	With the dover down I am wondering why we have our second dover
        doing nothing useful? It has been sitting in the cellar for MONTHS.
        Who is responsible for this stupidity????

    Certainly no one on BUG-HARDWARE, which usually is limited to
    discussing broken Lisp Machines (and occasionally network hardware).
    This sounds like a problem for Big Mike or Little Al.

sorry pat, but you're wrong. the history of bug-hardware has shown that it
is where general complaints about both labs' hardware (e.g. "MC dialups
don't work") goes, as there is no better list for making such complaints.
also, the people who used to be most prominent in fixing hardware fixed all
hardware, lispm and otherwise (moon, hic, and so forth). so people not
interested in lispms (e.g. ellen and gsb) are on BUG-HARDWARE to keep in
touch with users who don't know to ask them about non-lispm-hardware
lossage.16-Aug-83 09:24:49-EDT,349;000000000000
Return-path: <TC@MIT-OZ>
Mail-From: TC created at 16-Aug-83 09:21:37
Date: 16 Aug 1983 0921-EDT
From: TC@MIT-OZ
Subject: DOVER
To: CENT@MIT-OZ
cc: PGS@MIT-OZ, CRE@MIT-OZ, BUG-HARDWARE@MIT-OZ

     THE DOVER IN THE CELLAR IS THE OLD
DOVER,WAITING TO BE SHIPPED OUT FOR
OVERHAUL.THE NEW DOVER HAS BEEN INSTALLED
FOR OVER A MONTH.
-------
16-Aug-83 14:26:10-EDT,281;000000000000
Return-path: <RMS@MIT-OZ>
Date: Tuesday, 16 August 1983, 14:16-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR-5 consistently fails to cold boot.
One time, the error was a unibus-nxm-error at AWAIT-DISK.
Another time it halted at FATAL-DISK-ERROR.
16-Aug-83 14:27:19-EDT,187;000000000000
Return-path: <RMS@MIT-OZ>
Date: Tuesday, 16 August 1983, 14:17-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR-5 also has a dead fan under the I/O card cage.16-Aug-83 15:18:00-EDT,196;000000000000
Return-path: <RMS@MIT-OZ>
Date: Tuesday, 16 August 1983, 15:08-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR 18 got a main mem par error, board 1, bank 1, bit 31.
16-Aug-83 18:54:20-EDT,397;000000000000
Return-path: <RMS@MIT-OZ>
Date: Tuesday, 16 August 1983, 18:45-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR-18 is completely dead now.  I tried to replace the bad memory chip,
but the power was still on (I had turned off the wrong switch).
I'm afraid this has destroyed something, because it gets parity errors
trying to boot now even with that board removed.
17-Aug-83 15:41:13-EDT,219;000000000000
Return-path: <WJL@MIT-ML>
Date: 17 August 1983 15:34 EDT
From: Bill Long <WJL @ MIT-ML>
To: BUG-HARDWARE @ MIT-ML

The 300 baud lines on ML all get busy signals (and there's no one on them).
What's up?
-Bill Long18-Aug-83 09:30:40-EDT,359;000000000000
Return-path: <KwH@MIT-OZ>
Date: Thursday, 18 August 1983, 09:24-EDT
From: Ken Haase <KwH@MIT-OZ>
Subject: Dropped into the FEP...
To: BUG-hardware@MIT-OZ

In hardware in Release 4.4, FEP 12, site configuration 58, on Lisp Machine Janis Joplin:

This machine dropped me into the FEP with "ECC Syndrome 31, address 3xxxxx3"
from "show status".

Ken
18-Aug-83 11:25:52-EDT,362;000000000000
Return-path: <GUMBY@MIT-OZ>
Mail-From: GUMBY created at 18-Aug-83 11:22:23
Date: Thursday, August 18, 1983 11:22AM-EDT
From: David Vinayak Wallace <GUMBY@MIT-OZ>
Subject: problem with 7B
To: BUG-hardware at MIT-OZ
CC: oaf at MIT-OZ, bug-minits at MIT-OZ

Marvin's line on 7B is bad.  The terminal is OK.

Who actually fixes this (if anyone)?

david
18-Aug-83 18:48:13-EDT,731;000000000000
Return-path: <OAF@MIT-OZ>
Mail-From: OAF created at 18-Aug-83 18:45:54
Date: Thu, 18 Aug 1983  18:45 EDT
Message-ID: <[MIT-OZ].OAF.18-Aug-83 18:45:53>
From: OAF@MIT-OZ
To:   David Vinayak Wallace <GUMBY@MIT-OZ>
Cc:   BUG-hardware@MIT-OZ, bug-minits@MIT-OZ
Subject: problem with 7B
In-reply-to: Msg of 18 Aug 1983  11:22-EDT from David Vinayak Wallace <GUMBY>

I don't know who fixes those things (technical majik cards).  I hope it
isn't me.

I'm thinking of trying to debug one of those cards (like, on an extender
and all, and constantly reloading minits to drive people crazy), just to
see if there's a systemic improvement available, like interposing some 
resistors on the lines to prevent flameouts.

Oded
21-Aug-83 16:11:33-EDT,260;000000000000
Return-path: <JGA@MIT-MC>
Date: 21 August 1983 16:08 EDT
From: John G. Aspinall <JGA @ MIT-MC>
Subject: AAA schematic
To: bug-hardware @ MIT-OZ

Does anyone over there have a schematic for the Ann Arbor Ambasador
that I could borrow for a short while?
22-Aug-83 08:02:54-EDT,385;000000000000
Return-path: <PGS@MIT-OZ>
Date: Monday, 22 August 1983, 07:59-EDT
From: Patrick Sobalvarro <PGS@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR-5 is broken again.  I would have tried to find out what was wrong with it,
but there is only one debug cable in 905, and the only other debug cables I
could find on the ninth floor were these 50-foot 60-conductor monstrosities in
the corral.
22-Aug-83 23:26:32-EDT,507;000000000000
Return-path: <GSB@MIT-ML>
Date: 22 August 1983 23:22 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
To: ann @ MIT-XX, ricchio @ MIT-XX, ty @ MIT-XX
cc: BUG-HARDWARE @ MIT-ML

    GASP@MIT-ML 08/22/83 15:39:23
    Greetings,
     I was wonderoing if you knew any way around or how to fix the problem
    with the 300 baud telephone # (i.e. 258-6742).  It has been busy for
    about a month and so have been the immediatly consecutive numbers.
----
Also involved is -6743, which is hunted to by -6742.
23-Aug-83 08:33:05-EDT,677;000000000000
Return-path: <PGS@MIT-OZ>
Date: Tuesday, 23 August 1983, 08:33-EDT
From: Patrick Sobalvarro <PGS@MIT-OZ>
Subject: modular debugging shown useful
To: bug-hardware@MIT-OZ

I tried swapping CADR-1's and CADR-5's drives, because CADR-5 was getting
continual disk errors, and I needed to use it this afternoon.  I also swapped
the packs.  CADR-1 booted up happily on CADR-5's drive, but CADR-5 got infinite
disk errors on CADR-1's drive.  Swapping packs (CADR-5 with CADR-5's drive and
CADR-1's pack) made CADR-5 happy, thus showing the problem to be with the pack.
I took CADR-25's old pack and formatted it; it seems to win.  So flush the
service call on that drive.
24-Aug-83 07:55:17-EDT,302;000000000000
Return-path: <RICCHIO@MIT-XX>
Date: 24 Aug 1983 0751-EDT
From: Joe Ricchio <RICCHIO@MIT-XX>
To: GSB@MIT-ML, ann@MIT-XX, ty@MIT-XX
cc: BUG-HARDWARE@MIT-ML, RICCHIO@MIT-XX
In-Reply-To: Your message of 22-Aug-83 2322-EDT

We are attempting to make a fix to the telephone problems. Thanks
-------
24-Aug-83 17:43:47-EDT,850;000000000000
Return-path: <DICK@MIT-OZ>
Mail-From: DICK created at 24-Aug-83 17:43:26
Date: Wed, 24 Aug 1983  17:43 EDT
Message-ID: <[MIT-OZ].DICK.24-Aug-83 17:43:26>
Sender: DICK@MIT-OZ
From: Dick@MIT-MC
To:   bug-hardware@MIT-OZ
Subject: avatar (ne cadr-22)
cc:   bug-kbe@MIT-OZ


cadr-22 just died.  It has at least two problems.

1- It locked up in the middle of running, and when you tried to
boot it wen on for 2-3 seconds and then locked up again.
looking at it upstairs, I noticed that when you tried to boot
it it did a lot of disk io and then stopped with the numbers
in the leds all 8s.  This happend repeatably.

2- I turned the disk drive off, and as it was about to stop the belt
between the motor and the disk spindle came off its pullies.
We cannot even experiment with the cpu until this problem is fixed.

			Dick Waters
25-Aug-83 08:53:14-EDT,1464;000000000000
Return-path: <PGS@MIT-MC>
Date: 25 August 1983 08:37 EDT
From: Patrick G. Sobalvarro <PGS @ MIT-MC>
Subject:  avatar (ne cadr-22)
To: DICK @ MIT-MC
cc: bug-hardware @ MIT-OZ, bug-kbe @ MIT-OZ
In-reply-to: Msg of Wed 24 Aug 1983  17:43 EDT from Dick

    Date: Wed, 24 Aug 1983  17:43 EDT
    From: Dick
    Re:   avatar (ne cadr-22)

    cadr-22 just died.  It has at least two problems.

    1- It locked up in the middle of running, and when you tried to
    boot it wen on for 2-3 seconds and then locked up again.
    looking at it upstairs, I noticed that when you tried to boot
    it it did a lot of disk io and then stopped with the numbers
    in the leds all 8s.  This happend repeatably.

All 8s is generally what you'll see when the machine is running, after it's
finished booting.  Some of the 8s will look slightly dimmer than others.  Of
course, it's possible that the machine was halted, and there was something
wrong with the PC display so that it showed all 8s.

    2- I turned the disk drive off, and as it was about to stop the belt
    between the motor and the disk spindle came off its pullies.
    We cannot even experiment with the cpu until this problem is fixed.

This won't be fixed until next week, because (I believe) John Holden, who
repairs our disk drives, is on his annual vacation.  You should tell Tom
Callahan about the drive, and he will have John Holden come and fix it as
soon as possible.
25-Aug-83 20:59:09-EDT,314;000000000000
Return-path: <tim@MIT-OZ>
Date: Thursday, 25 August 1983, 20:19-EDT
From: Tim McNerney <tim@MIT-OZ>
To: BUG-Hardware@MIT-OZ

In Hardware in MIT-Specific 19.5, System 94.39, ZMail 50.17,
Experimental Local-File 44.3, microcode 239, gc@34,
on Lisp Machine Four:

Dies often, but warm-bootable (fortunately).26-Aug-83 12:45:11-EDT,1221;000000000000
Return-path: <AKR@MIT-OZ>
Mail-From: AKR created at 26-Aug-83 12:16:17
Date: Fri, 26 Aug 1983  12:16 EDT
Message-ID: <[MIT-OZ].AKR.26-Aug-83 12:16:16>
From: AKR@MIT-OZ
To:   Dick@MIT-MC
Cc:   bug-hardware@MIT-OZ, bug-kbe@MIT-OZ
Subject: avatar (ne cadr-22)
In-reply-to: Msg of 24 Aug 1983  17:43-EDT from Dick at MIT-MC

	Date: Wednesday, 24 August 1983  17:43-EDT
	From: Dick at MIT-MC
	Re:   avatar (ne cadr-22)
	
	cadr-22 just died.  It has at least two problems.
	
	1- It locked up in the middle of running, and when you tried to
	boot it wen on for 2-3 seconds and then locked up again.
	looking at it upstairs, I noticed that when you tried to boot
	it it did a lot of disk io and then stopped with the numbers
	in the leds all 8s.  This happend repeatably.

The chaos net was wedged for a few minutes on wednesday around 5:30 pm
and all lisp-machines on subnet 6 had the same problem.  So I am almost sure
that the processor is not broken.

	2- I turned the disk drive off, and as it was about to stop the belt
	between the motor and the disk spindle came off its pullies.
	We cannot even experiment with the cpu until this problem is fixed.

Sigh!  Nothing I can do about this one.
26-Aug-83 12:54:38-EDT,926;000000000000
Return-path: <DCP@SCRC-TENEX>
Received: from SCRC-CHARLES by SCRC-TENEX with CHAOS; Fri 26-Aug-83 12:53:10-EDT
Date: Friday, 26 August 1983, 12:51-EDT
From: David C. Plummer <DCP@SCRC-TENEX>
Subject: TOTO's subnet 6 connection.
To: net-hackers@MIT-EECS, bug-hardware@MIT-OZ

In case nobody has noticed, TOTO's subnet 6 connection has completely
unacceptable statistics:

Chaosnet host status report.  Type Control-Abort to quit.
Site   Name/Status              Subnet     #-in    #-out   abort    lost     crc ram bitc other
406    TOTO (OZ-Network-11)          1   555753   812223       0   34148    2404   0    0    22
                                     6  1269038   869283  119168  152241  512503   0258063 36949
                                    23  2161359  2649558       0       0       0   0    0   378
                                    26  1940424  1447332    3711       0       3   0    3   685
26-Aug-83 23:03:38-EDT,411;000000000000
Return-path: <GSB@MIT-ML>
Date: 26 August 1983 22:34 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
Subject: TOTO's subnet 6 connection.
To: DCP @ SCRC-TENEX
cc: bug-hardware @ MIT-OZ, net-hackers @ MIT-EECS

That ain't all, apparently.  HTJR is not talking to the chaosnet.
This sucks big dead donkey d*cks as i was just intending to store
my work there so i could work on it while DEC breaks ml some more.
27-Aug-83 12:14:03-EDT,626;000000000000
Return-path: <GLR@MIT-OZ>
Mail-From: GLR created at 27-Aug-83 10:09:54
Date: Sat, 27 Aug 1983  10:09 EDT
Message-ID: <[MIT-OZ].GLR.27-Aug-83 10:09:54>
From: Jerry Roylance <GLR@MIT-OZ>
To:   Glenn S. Burke <GSB@MIT-ML>
Cc:   bug-hardware@MIT-OZ, DCP@SCRC-TENEX, net-hackers@MIT-EECS
Subject: HTJR not talking to subnet 6
In-reply-to: Msg of 26 Aug 1983  22:34-EDT from Glenn S. Burke <GSB at MIT-ML>


Swapping transceivers does not help.
The transceiver cable is mislabled HTVAX and it looks ok, but people have been pulling wires
in that area.
I can't log in, so I didn't bother looking further.

				Jerry
27-Aug-83 15:57:29-EDT,1043;000000000000
Return-path: <PDH@MIT-OZ>
Mail-From: PDH created at 27-Aug-83 15:51:29
Date: Sat, 27 Aug 1983  15:51 EDT
Message-ID: <[MIT-OZ].PDH.27-Aug-83 15:51:28>
From: PDH@MIT-OZ
To:   Jerry Roylance <GLR@MIT-OZ>
Cc:   bug-hardware@MIT-OZ, DCP@SCRC-TENEX, Glenn S. Burke <GSB@MIT-ML>,
      net-hackers@MIT-EECS
Subject: HTJR not talking to subnet 6
In-reply-to: Msg of 27 Aug 1983  10:09-EDT from Jerry Roylance <GLR>

The only thing that I could find blatantly wrong with HTJR's connection
was that the cable had been pinched between two tiles- even though there
was a hole two inches away.  It didn't look too seriously mangled, just
a little row of black marks.  I put some electrical tape over it and ran
it through the hole just to make sure.  i thought that maybe the metal edge
of the tile was getting in close enough, perhaps even touching, the wires
so that there was a bit of leakage all the way across the wires.  Not enough
to break the connection but enough to even out the potentials enough so that
errors would occur.
27-Aug-83 20:51:46-EDT,321;000000000000
Return-path: <GAVAN@MIT-OZ>
Date: Saturday, 27 August 1983, 20:51-EDT
From: Gavan Duffy <GAVAN@MIT-OZ>
To: BUG-Hardware@MIT-OZ

In Hardware in MIT-Specific 19.5, System 94.39, ZMail 50.17,
Experimental Local-File 44.3, microcode 239, gc@34,
on Lisp Machine Six:

Thespacebaronthiskeyboardseemstobesomewhatwedged.29-Aug-83 09:32:45-EDT,403;000000000000
Return-path: <GSB@MIT-MC>
Date: 29 August 1983 09:22 EDT
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: htjr's chaos connection
To: BUG-HARDWARE @ MIT-MC

Well, it's back.  The chaosnet-ncp process had been missing.  I don't
know whether it got flushed in an atteempt to restart it because of
earlier lossage, or it just died, or even whether it had been present
when i first noticed lossage...
31-Aug-83 02:50:52-EDT,663;000000000000
Return-path: <CENT@MIT-OZ>
Mail-From: CENT created at 31-Aug-83 02:40:27
Date: Wednesday, August 31, 1983 2:40AM-EDT
From: Pandora Berman <CENT@MIT-OZ>
Subject: cadr5 icmem broken
To: BUG-hardware at MIT-OZ

at RMS's request, i have been installing the final 4K of ICMEM in
the cadrs. tonight he showed me how to test it. looks like
CADR 5 has problems.
in cc:c-mem-banks-fast-address-test,
bit 41 was bad for all address bits, and
bits 12-23 were bad for address bit 6.
we tried replacing the indicated 2147 and 74s04, but got the
same results on retesting. wire lossage?

cadr25 came through with flying colors.
rms is testing cadrs 1 and 18.
31-Aug-83 05:38:33-EDT,456;000000000000
Return-path: <RMS@MIT-OZ>
Mail-From: RMS created at 31-Aug-83 05:36:29
Date: Wednesday, August 31, 1983 5:36AM-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
To: bug-hardware at MIT-OZ

CADR 18 has cmem problems:
fast-address-test-c-mem-banks reports that bit 32
fails for locations 0 and 7777 within bank 3,
while bits 36-47 fail for address bit 0 in bank 3.
I tried replacing the relevant memory chip and
address driver, but that did not fix it.
31-Aug-83 06:28:11-EDT,282;000000000000
Return-path: <RMS@MIT-OZ>
Mail-From: RMS created at 31-Aug-83 05:48:59
Date: Wednesday, August 31, 1983 5:49AM-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
To: bug-hardware at MIT-OZ

CADR 1 got a c-mem parity error.
Bit 44. was mistakenly cleared in location 10103 of c-mem.
31-Aug-83 18:34:09-EDT,395;000000000000
Return-path: <AKR@MIT-OZ>
Mail-From: AKR created at 31-Aug-83 17:43:27
Date: Wed, 31 Aug 1983  17:43 EDT
Message-ID: <[MIT-OZ].AKR.31-Aug-83 17:43:26>
From: AKR@MIT-OZ
To:   Pandora Berman <CENT@MIT-OZ>
Cc:   BUG-hardware@MIT-OZ
Subject: cadr5 icmem broken
In-reply-to: Msg of 31 Aug 1983  02:40-EDT from Pandora Berman <CENT>


All the chips were good.  There were 3 wiring errors.
31-Aug-83 18:36:20-EDT,346;000000000000
Return-path: <AKR@MIT-OZ>
Mail-From: AKR created at 31-Aug-83 17:44:10
Date: Wed, 31 Aug 1983  17:44 EDT
Message-ID: <[MIT-OZ].AKR.31-Aug-83 17:44:09>
From: AKR@MIT-OZ
To:   Richard M. Stallman <RMS@MIT-OZ>
Cc:   bug-hardware@MIT-OZ
In-reply-to: Msg of 31 Aug 1983  05:36-EDT from Richard M. Stallman <RMS>


Fixed:  bad wiring again.
31-Aug-83 18:38:44-EDT,402;000000000000
Return-path: <AKR@MIT-OZ>
Mail-From: AKR created at 31-Aug-83 17:49:54
Date: Wed, 31 Aug 1983  17:49 EDT
Message-ID: <[MIT-OZ].AKR.31-Aug-83 17:49:54>
From: AKR@MIT-OZ
To:   Bug-hardware@MIT-OZ
Cc:   Music-Hackers@MIT-OZ
Subject: Cadr-9 on Seventh Floor
In-reply-to: Msg of 15 Aug 1983  04:11-EDT from TIM


Cadr9 now has a new disk on it.  Does someone
know what happened to the old one?
 3-Sep-83 11:56:36-EDT,358;000000000000
Return-path: <TLP@MIT-OZ>
Mail-From: TLP created at  3-Sep-83 11:53:36
Date: Sat, 3 Sep 1983  11:53 EDT
Message-ID: <[MIT-OZ].TLP. 3-Sep-83 11:53:36>
From: TLP@MIT-OZ
To:   bug-hardware@MIT-OZ

CADR-30 is hardware flaky again.  Could somebody take a look at it? 
Scott Heide in 344 can reliably get it to crash, if that is helpful.
Thanx.

Tomas
 4-Sep-83 19:48:23-EDT,254;000000000000
Return-path: <MERMAN@MIT-OZ>
Date: Sunday, 4 September 1983, 19:49-EDT
From: Dave Goodine <MERMAN@MIT-OZ>
To: bug-hardware@MIT-OZ


Cadr 1 got CRAM parity errors.
CC-SCAN-CMEM-FOR-BAD-PARITY showed 15 bad locs.
Machine will not boot.

-MERMAN
 6-Sep-83 00:19:56-EDT,563;000000000000
Return-path: <CENT@MIT-ML>
Date: 6 September 1983 00:19 EDT
From: Pandora B. Berman <CENT @ MIT-ML>
Subject: cadr27 disk lossage
To: BUG-HARDWARE @ MIT-ML

when i tried to dump the LMFILEsystem, things barfed claiming that
UNIT 2 wasn't online. i encountered a circle of errors and eventually
coldbooted. when booting, CADR27 first said that it couldn't reach
OZ to get patches (indicating chaosnet loassage, too), and then
announced that UNIT2 wasn't online and so the file server was
inaccessible. 
i'm not sure which disk is supposed to be unit2... 6-Sep-83 06:30:24-EDT,325;000000000001
Return-path: <RMS@MIT-OZ>
Mail-From: RMS created at  6-Sep-83 06:25:31
Date:  6 Sep 1983 0625-EDT
From: RMS@MIT-OZ
Subject: CADR27 disk unit 2
To: bug-hardware@MIT-OZ

Stopping and starting the drive fixed this.  What
could cause the drive to be in a state where it is
spinning but the green light is off?
-------
 6-Sep-83 16:01:05-EDT,754;000000000000
Return-path: <PGS@MIT-OZ>
Date: Tuesday, 6 September 1983, 16:00-EDT
From: Patrick Sobalvarro <PGS@MIT-OZ>
To: bug-hardware@MIT-OZ, bug-lispm@MIT-OZ

The new mice are here, as promised, but their scale is slightly wrong -- it's a
little too fine.  Using a VMI monitor and the MIT system, the top of a chinual
no longer corresponds to a whole screen.  I tried bashing the second entries of
sys:mouse-x-scale-array and sys:mouse-y-scale-array to 1500 and 2300
respectively, and this seems to produce more or less the right results.
However, I wish there were a more aesthetic way of hacking this -- it would be
nice if there were a keyworded function for setting it (maybe
(tv:set-mouse-type ':purbrick) or (tv:set-mouse-type ':mouse-house)).
 7-Sep-83 16:07:14-EDT,749;000000000000
Return-path: <AKR@MIT-OZ>
Mail-From: AKR created at  7-Sep-83 16:01:12
Date: Wed, 7 Sep 1983  16:01 EDT
Message-ID: <[MIT-OZ].AKR. 7-Sep-83 16:01:11>
From: AKR@MIT-OZ
To:   RMS@MIT-OZ
Cc:   bug-hardware@MIT-OZ
Subject: CADR27 disk unit 2
In-reply-to: Msg of 6 Sep 1983  06:25-EDT from RMS

	Date: Tuesday, 6 September 1983  06:25-EDT
	From: RMS
	To:   bug-hardware
	Re:   CADR27 disk unit 2
	
	Stopping and starting the drive fixed this.  What
	could cause the drive to be in a state where it is
	spinning but the green light is off?

Usually a disk drive problem, maybe the disk controller.  I would'nt
worry about it unless it happens again; it could have been a glitch
that sent the drive off-line without spinning it down.
 7-Sep-83 20:10:58-EDT,638;000000000000
Return-path: <CENT@MIT-ML>
Date: 7 September 1983 20:12 EDT
From: Pandora B. Berman <CENT @ MIT-ML>
Subject: CADR27 disk unit 2
To: RMS @ MIT-OZ
cc: bug-hardware @ MIT-OZ

    Date:  6 Sep 1983 0625-EDT
    From: RMS@MIT-OZ
    Subject: CADR27 disk unit 2
    To: bug-hardware@MIT-OZ
    Stopping and starting the drive fixed this.  What could cause the
    drive to be in a state where it is spinning but the green light is
    off?

it could just be that the bulb is burned out. i have a few of the
right size but higher wattage (burn out faster); i'm sure TC has more
of the real thing around but i don't know where.
 8-Sep-83 10:02:55-EDT,325;000000000000
Return-path: <RMS@MIT-OZ>
Date: Thursday, 8 September 1983, 10:00-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
To: BUG-Hardware@MIT-OZ

CADR 1 got parity error in bit 44. (counting from low bit = 0)
of location 12632 of c-mem.

Wasn't this reported some time ago?

Bit 28. in the third bank seems to be failing too.
12-Sep-83 11:25:18-EDT,289;000000000000
Return-path: <NGL@MIT-OZ>
Date: Monday, 12 September 1983, 11:22-EDT
From: Noble G. Larson <NGL@MIT-OZ>
To: BUG-Hardware@MIT-OZ

CADR 24 has a problem in the Chaos net interface, probably on the IOB.  The transceiver was
absolved(CADR 3 worked fine using it).  -ngl(11:20 am, 9/12)
12-Sep-83 12:52:04-EDT,242;000000000000
Return-path: <SCOTT@MIT-OZ>
Mail-From: SCOTT created at 12-Sep-83 12:51:34
Date: 12 Sep 1983 1251-EDT
From: SCOTT@MIT-OZ
Subject: cadr-32
To: bug-hardware@MIT-OZ

The beeper for cadr-32 doesn't seem to work.
Thanks,
Scott.
-------
12-Sep-83 15:23:51-EDT,380;000000000000
Return-path: <NIS@MIT-OZ>
Mail-From: NIS created at 12-Sep-83 15:17:02
Date: Monday, September 12, 1983 3:17PM-EDT
From: H. Keith Nishihara <NIS@MIT-OZ>
Subject: cadr24 iob board and chaos connection
To: bug-hardware

seems that cadr 3 and 24 have been spliced out of the 
chaos net.  Ngl says that 24's iob board is possibly suspect.  
could we get 24 back?  
--keith
12-Sep-83 15:25:21-EDT,367;000000000000
Return-path: <NIS@MIT-OZ>
Mail-From: NIS created at 12-Sep-83 15:18:32
Date: Monday, September 12, 1983 3:18PM-EDT
From: H. Keith Nishihara <NIS@MIT-OZ>
Subject: cadr24 blower fan is going
To: bug-hardware

the fan under iob board is hitting something and 
making lots of noise.  previously it may have been 
completely stuck.. held by the filter  -- keith
12-Sep-83 17:34:30-EDT,434;000000000000
Return-path: <DANIEL@MIT-OZ>
Mail-From: DANIEL created at 12-Sep-83 17:31:20
Date: Monday, September 12, 1983 5:31PM-EDT
From: kmp
Sent-by: Daniel Weise <DANIEL@MIT-OZ>
Subject: cadr22 is dead
To: akr
CC: kmp, bug-hardware

can somebody look at cadr-22 (aka avatar)?  It was down yesterday
after the ac failed and I don't know if anyone looked at it today
but it is not answering requests so I suppose it is still down.

13-Sep-83 00:46:07-EDT,771;000000000000
Return-path: <CENT@MIT-ML>
Date: 13 September 1983 00:40 EDT
From: Pandora B. Berman <CENT @ MIT-ML>
Subject: cadr-32
To: SCOTT @ MIT-OZ
cc: BUG-HARDWARE @ MIT-ML

    Date: 12 Sep 1983 1251-EDT
    From: SCOTT@MIT-OZ
    Subject: cadr-32
    To: bug-hardware@MIT-OZ
    The beeper for cadr-32 doesn't seem to work.

what do you mean? that <break> and CTRL-G and such don't cause an audible
noise? if so, maybe your keyboard is broken. unplug it and bring it to ron
wiken in 926 (he doesn't get mail, so you have to find him); he will fix it
or give you a replacement. or possibly the noise is turned all the way
down; the knob for this is on the bottom of the kbd (next to the mouse
connector and the cable to the console), and clockwise turns it up.
14-Sep-83 00:34:18-EDT,229;000000000000
Return-path: <RMS@MIT-OZ>
Date: Wednesday, 14 September 1983, 00:34-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
To: bug-hardware@MIT-OZ

CADR 1 c-mem parity error:
bit 47. was 1 and should have been 0, in location 23201@c.
14-Sep-83 16:22:06-EDT,314;000000000000
Return-path: <MARTY@MIT-OZ>
Mail-From: MARTY created at 14-Sep-83 16:14:09
Date: Wednesday, September 14, 1983 4:14PM-EDT
From: Martin David Connor <MARTY@MIT-OZ>
Subject: NE43-3A
To: bug-hardware


Seems to be crashing more often lately (the last 3 days),
maybe someone could take a quick look at it.

15-Sep-83 17:40:22-EDT,1114;000000000000
Return-path: <KMP@MIT-OZ>
Mail-From: KMP created at 15-Sep-83 17:16:02
Date: Thursday, September 15, 1983 5:16PM-EDT
From: Kent M. Pitman <KMP@MIT-OZ>
Subject: Cadr-22 problems
To: AKR
CC: BUG-HARDWARE, RICH, DICK, FAUST

CADR-22 has a problem. It seems to think it has only 256K of memory.
It doesn't, though; it has 512K physically present. The problem looks
to me like one of the power strips on the upright post of the machine
isn't getting any power from the box. At least, its little yellow light
doesn't go on and the fan (which runs off that strip) doesn't spin. Can
you maybe look at the box which is supposed to be feeding that power 
strip and see what might have broken so the machine can work happily again?
Greg Faust said something about that someone was grumbling earlier today
about someone having overloaded Switched or UnSwitched power -- maybe two
cords were coming out of one instead of one out of each or something like
that. We're not too sure of the details on that, but it might be related.
Anyway, any help you can offer would certainly be appreciated. Thanks.
--kmp
16-Sep-83 15:00:30-EDT,313;000000000000
Return-path: <TC@MIT-OZ>
Mail-From: TC created at 16-Sep-83 14:42:25
Date: 16 Sep 1983 1442-EDT
From: TC@MIT-OZ
Subject: CADR-22
To: BUG-HARDWARE@MIT-OZ
cc: AKR@MIT-OZ, KMP@MIT-OZ, DANIEL@MIT-OZ

      ITS POWER CONTROL WAS FRIED.IT
SHOULD BE OK NOW,BUT I COULDN'T GET
IN TO 826 TO MAKE SURE.
-------
20-Sep-83 12:19:59-EDT,688;000000000000
Return-path: <SR.HUME@MIT-SPEECH>
Date: 20 September 1983  12:24-EDT (Tuesday)
From: Chris Hume <SR.HUME at MIT-SPEECH>
Subject: Panic in 36-568
Cc:   SR.Cypher at MIT-SPEECH
To:   Bug-Hardware at Oz

This is to follow up the problem I phoned in to Alex Krymm yesterday.
We have a CADR named Koala that appears to have a sick Power Supply.
Logic levels were metered here at below .3 Volts.

I'm a new employee of Victor Zue's saddled with the pacification of
those researchers who are temporarily unable to access their files, etc.
Hopefully, you'll be able to turn up a P.S. for us before the mob comes
after me.

I can be phoned at 3-8923 or 3-8513.
Thanx.  Chris


22-Sep-83 12:43:00-EDT,372;000000000000
Return-path: <KOCH@MIT-OZ>
Mail-From: KOCH created at 22-Sep-83 12:40:20
Date: Thursday, September 22, 1983 12:40PM-EDT
From: Christof Koch <KOCH@MIT-OZ>
Subject: Cadr 23
To: bug-hardware

Cadr 23 has been down since the air conditioning problems.  It is 
important to fix it quickly since it has special convolution
hardware that is needed as soon as possible.
22-Sep-83 16:09:56-EDT,275;000000000000
Return-path: <TC@MIT-OZ>
Mail-From: TC created at 22-Sep-83 16:03:52
Date: 22 Sep 1983 1603-EDT
From: TC@MIT-OZ
To: KOCH@MIT-OZ
cc: TC@MIT-OZ, BUG-HARDWARE@MIT-OZ

      ALEX IS WORKING ON CADR-23.IT
IS A COMPLEX PROBLEM AND I AM SURE
HE WILL FIX IT ASAP.
-------
23-Sep-83 18:06:11-EDT,317;000000000000
Return-path: <NIS@MIT-OZ>
Mail-From: NIS created at 23-Sep-83 18:02:22
Date: Friday, September 23, 1983 6:02PM-EDT
From: H. Keith Nishihara <NIS@MIT-OZ>
Subject: cadr24
To: bug-hardware

why is it powered down?  can it be brought back to life?
we should switch it back to its own disk at some point
--keith
26-Sep-83 23:33:10-EDT,219;000000000000
Date: Monday, 26 September 1983, 23:33-EDT
From: Richard M. Stallman <RMS at MIT-OZ>
To: bug-hardware at MIT-OZ

CADR1 got a C mem parity error.  The 20's bit was turned on incorrectly
in location 22665 of C mem.
27-Sep-83 16:06:20-EDT,450;000000000000
Date: Tuesday, 27 September 1983, 16:06-EDT
From: Michael H. Kass <KASS at MIT-OZ>
To: BUG-Hardware at MIT-OZ

Cadr 24 died spontaneously while I was using it moments ago.
Curiously, the run bar was off and it just ignored all 
keyboard input.  Warm booting caused it to page a bit and
then die with the run light on.  It now refuses to cold 
boot.  After several attempts, it once it got as far as putting
up the lisp window before wedging.28-Sep-83 22:37:50-EDT,182;000000000000
Date: Wednesday, 28 September 1983, 22:38-EDT
From: saund at MIT-OZ
Subject: shift key on cadr5
To: bug-hardware at MIT-OZ

The left shift key on cadr5 doesn't work very well.
29-Sep-83 12:49:58-EDT,1165;000000000000
Date: Thursday, 29 September 1983, 12:50-EDT
From: saund at MIT-OZ
Subject: cadr5
To: bug-hardware at MIT-OZ

  I had a very strange experience with cadr5 at 12:15 pm, 9/29/83.
  I was in an editor when the machine started beeping at me wildly,
just intermittently at first, but incresingly.  Actually, it was very 
nice that the machine gave me warning that it was going to die because
I had a chance to save my edit buffer.   Soon enough it was beeping continuously
and everything else seemed to stop working.  The beeping stopped, and the machine
would not respond to any keyboard input, including cold boot, though the mouse
still worked and the clock was still ticking.    At the physical
machine in room 905 (or whatever) a red led was blinking on the upper
right side of the dark panel.
  Returning to the console, I plugged in the keyboard from cadr24 and was able to
cold boot cadr5, even though no other keyboard input seemed to get through, 
including warm boot.  
  Now, everything appears to be normal, and I am typing this message on cadr5
with cadr5's original keyboard.   
There is something mysterious and wrong going on here.
29-Sep-83 17:46:33-EDT,544;000000000000
Date: 29 September 1983 17:45 EDT
From: Peter Szolovits <PSZ @ MIT-ML>
Subject:  CADR terminal in 301
To: BUG-HARDWARE @ MIT-ML

I note that the Lisp machine terminal in Room 301 is powered down.  When
I tried to power it up, it took >10 mins to have any visible brightness
on it at all.  It stayed very dim, however, with the retrace lines
showing very strongly.  I suspect it's also disconnected at the patch
panel, since it did not respond to any keystrokes.  Is it known to have
some disease, or can it be fixed up to be usable?
30-Sep-83 15:01:11-EDT,325;000000000000
Mail-From: TC created at 30-Sep-83 15:00:31
Date: Fri 30 Sep 83 15:00:31-EDT
From: TC@MIT-OZ
Subject: CADR 301
To: PSZ@MIT-OZ
cc: TC@MIT-OZ, BUG-HARDWARE@MIT-OZ

        SOME LCS PERSON REMOVED THE CADR
FROM NINE.THEY ARE GOING TO PUT IT IN
THE SECOND FALSE FLOOR AREA.I ASSUMED
THEY HAD YOUR PERMISSION.
-------
 5-Oct-83 17:03:29-EDT,470;000000000000
Mail-From: TSC created at  5-Oct-83 17:02:41
Date: Wed 5 Oct 83 17:02-EDT
From: THOMAS COLLETT <TSC@MIT-OZ>
Subject: CADR-30 wedges, can reproduce it
To: bug-hardware@MIT-OZ, brd@MIT-OZ, akr@MIT-OZ, pgs@MIT-OZ

CADR-30 has been wedging a lot lately, and only warm booting
helps. The file <TSC>FILE-CAUSES-CADR-30-TO-WEDGE.LISP
will help reproduce the error.

(1) load it into ZWEI.

(2) Hit M-Z and try to compile it. It seems to wedge each time.

Brd.

11-Oct-83 19:36:59-EDT,1599;000000000000
Date: Tuesday, 11 October 1983, 19:35-EDT
From: John Canny <JfC at MIT-OZ>
To: BUG-Hardware at MIT-OZ

In Hardware in MIT-Specific 19.5, System 94.41, ZMail 50.17,
microcode 239, on Lisp Machine Thirty-two:

This occurred on Lisp machine thirty-one running the same system as this
machine. Thirty-one has been dying regularly with this or some other error.
This message was sent through the mailer rather than CC because CC seems
to be broken in the current system. It does not respond to the help
command :? and the bug report command (I thought it was :bug) didnt work either.

(cc)
CC contains saved state, type control-S to flush it.
***********************************************
PC=23562   OBUS=1404   FATAL-DISK-ERROR
IR= ( (M-1 ) LDB (BYTE-FIELD 30 0) C-PDL-BUFFER-POINTER-POP A-ZERO ) 
ERROR-STATUS JC-TRUE NO-OP ANY-ERR 
:why
Machine being debugged is MIT-LISPM-31.
Disk error: Off-line  Off-Cylinder  Transfer-Aborted  Sel-Unit-Attention  Any-Unit-Attention
  disk address: UNIT 0 CYLINDER 11 HEAD 7 SECTOR 17 
  last memory address touched by disk = 276377
Contents of disk error log in debugee's main memory 600-640:

Command 0 (Read) 
CCW-list pointer 740 (low 16 bits)
Disk address: unit 0, cylinder 11, head 7, block 17 (0 9 7 15 decimal)
Memory address: 276377 (type bits 0)
Status: 21417  Transfer-Aborted (or wr. ovr.)  Off-Line  Off-Cylinder  Interrupt
          Sel-Unit-Attention  Any-Unit-Attention  Idle

Type :WHYSOFT to attempt to analyze the current software state.

(|#(|??  
Back to top level in Lisp Listener 1.
(dribble-end)
14-Oct-83 14:08:08-EDT,403;000000000000
Mail-From: NIS created at 14-Oct-83 14:07:30
Date: Fri 14 Oct 83 14:07-EDT
From: H. Keith Nishihara <NIS@MIT-OZ>
Subject: is this proper mail list forconcept terminal troubles?
To: bug-hardware@MIT-OZ

concept terminal in room 322 (nishihara + grimson) 
is having display problems (looks like raster has a glitch)
--keith 

ps if this is wrong place, could someone send me a note -- thanks

17-Oct-83 08:12:41-EDT,515;000000000000
Mail-From: TC created at 17-Oct-83 08:12:27
Date: Mon 17 Oct 83 08:12:27-EDT
From: TC@MIT-OZ
Subject: CONCEPT
To: NIS@MIT-OZ
cc: TC@MIT-OZ, BUG-HARDWARE@MIT-OZ

        RON WITKEN ROOM 926 AND ODET FINGOLD
(OAF)ARE THE PEOPLE TO CONTACT.THEY HAVE
AGREED TO TAKE CARE OF ALL TERMINAL TROUBLES.
        IF YOU HAVE A CONCEPT AT HOME,AND
HAVE TROUBLE DONT BRING IT IN.YOU CAN GET
A REPAIR PO# FROM SHARRON AND HUMAN DESIGNED SYSTEMS
WILL COME TO YOUR HOUSE.SEE ODET RON OR ME
IF YOU NEED HELP.
-------
18-Oct-83 17:45:50-EDT,224;000000000000
Date: Tuesday, 18 October 1983, 17:43-EDT
From: Richard M. Stallman <RMS at MIT-OZ>
To: bug-hardware at MIT-OZ

CADR 1 got a c-mem parity error;
the 40000000000000 bit was 1 and should have been 0,
in location 11224.
19-Oct-83 15:02:04-EDT,326;000000000000
Date: Wednesday, 19 October 1983, 15:02-EDT
From: Alan Bawden <Alan at MIT-MC>
Subject: Moon's mouse
To: BUG-HARDWARE at OZ

In HARDWARE in Release 4.5, site configuration 62, on Lisp Machine Keith Moon:

This mouse is starting to degenerate.  It frequently is reluctant to
notice motion in the left-right direction.
24-Oct-83 10:46:40-EDT,519;000000000000
Mail-From: TC created at 24-Oct-83 10:46:09
Date: Mon 24 Oct 83 10:46:09-EDT
From: TC@MIT-OZ
Subject: CADR-9 AND 32
To: BUG-HARDWARE@MIT-OZ
cc: TC@MIT-OZ

        AFTER THE WEEKEND AC SHUTDOWN
I COULD NOT GET 9,S DISK TO SPIN UP.
I TRIED A FEW POWER CYCLES,NO WIN.
        CADR-32 WOULD NOT BOOT,WARM
OR COLD.I TRIED POWER CYCLE,IT STOPPED
AT 40 EVERY TIME.
        CADR-27 HAD POWER STRIP PROBLEMS.
PLEASE TRY TO USE THE CIRCUIT BREAKER
TO TURN THEM ON AND OFF.THE POWER STRIPS
CANT HACK IT.
-------
29-Oct-83 14:39:41-EDT,246;000000000000
Mail-From: RMS created at 29-Oct-83 14:38:58
Date: Sat 29 Oct 83 14:38:57-EDT
From: RMS@MIT-OZ
Subject: CADR-1 cmem par error
To: bug-hardware@MIT-OZ

the 1000000000000000 bit (ILONG), in location 17446, was turned on by mistake.
-------
31-Oct-83 08:04:57-EST,1338;000000000000
Date: Monday, 31 October 1983, 08:04-EST
From:  <PGS at MIT-MC>
Sender:  at MIT-MC
To: BUG-HARDWARE at MIT-OZ
CC: bug-lispm at MIT-OZ

In HARDWARE in System 97.23, CADR 1.0, ZMail 51.9, MIT-Specific 21.0,
microcode 257, ZM MIT, on Lisp Machine Thirty:

CADR-30 seems to be broken.  I can't tell whether the print error is a
legitimate error message, but looks to me like CC is having trouble,
too.

Machine being debugged is MIT-LISPM-31.

Microcode halted via ILLOP from TRAP
Micro PC History (OPC's), oldest first:
   16553   TRANS-REALLY-TRAP
   16554   (TRANS-REALLY-TRAP 1)
   16555   (TRANS-REALLY-TRAP 2)
   16556   (TRANS-REALLY-TRAP 3)
   24025   TRAP
   24026   (TRAP 1)
   00023   ILLOP
   00024   XWIPM
Backtrace of microcode subroutine stack:
    7  016551   TRANS-DROP-THROUGH
    6  026141   (BEG03 13)
    5  000000   COPY-BUFFER-CCW-ORIGIN
    4  000000   COPY-BUFFER-CCW-ORIGIN
    3  000000   COPY-BUFFER-CCW-ORIGIN
    2  000000   COPY-BUFFER-CCW-ORIGIN
    1  000000   COPY-BUFFER-CCW-ORIGIN
    0  000000   COPY-BUFFER-CCW-ORIGIN
Halted trying to signal an error, because trapping is disabled
Error was signalled from (TRANS-REALLY-TRAP 2)
  Error table says: (TRANS-TRAP)

>>ERROR: 300000000 NOT AN ARRAY-POINTER - QF-ARRAY-SETUP

[Sorry, error while trying to print that.]
31-Oct-83 20:03:24-EST,517;000000000000
Date: Monday, 31 October 1983, 20:04-EST
From: Alan Bawden <Alan at MIT-MC>
Subject: Fucking mouse!
To: BUG-HARDWARE at OZ

In HARDWARE in Release 4.5, site configuration 65, on Lisp Machine Jimi Hendrix:

The mouse on this 3600 is deficient in the usual way: it is almost
completely insensitive horizontal direction.  I would smash this one
against the wall (couldn't make it any worse) except I can't figure out
how to detach it from the rest of the console.

How come nobody makes a reasonable mouse?
31-Oct-83 20:22:30-EST,611;000000000000
Date: Monday, 31 October 1983, 20:22-EST
From: Alan Bawden <Alan at MIT-MC>
Subject: ex-mouse
To: BUG-HARDWARE at OZ

In HARDWARE in Release 4.5, site configuration 65, on Lisp Machine Jimi Hendrix:

I exchanged the mouse on this machine with the mouse on Janis.  For the
record, most of the numbers on the bottom of the faulty mouse have been
worn off, however the serial number in the upper right-hand corner of
the Mouse House (tm) sticker is still readable.  It says: 03846.  Unlike
the mouse I am using now, the loser does not have a Symbolics sticker
and serial number affixed to the bottom.
 1-Nov-83 22:39:22-EST,693;000000000000
Date: 1 November 1983 22:41 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  musical Fucking mouse!
To: RWK @ SCRC-TENEX
cc: CSTACY @ MIT-MC, BUG-HARDWARE @ MIT-OZ
In-reply-to: Msg of Tue 1 Nov 83 18:48 EST from "Robert W. Kerns" <RWK at YUKON.SCRC.Symbolics>

    Date: Tue, 1 Nov 83 18:48 EST
    From: "Robert W. Kerns" <RWK at YUKON.SCRC.Symbolics>
    To:   Alan Bawden <ALAN at MIT-MC.ARPA>
    cc:   CSTACY at MIT-MC.ARPA, BUG-SYMBOLICS-HARDWARE at MIT-OZ.ARPA
    Quick.  Where is it?  As I said, short of trying every mouse
    in the place.

Since everybody is being so feeble about this, tomorrow I will find the
mouse in question, unplug it, and nail it to my wall.
 1-Nov-83 23:38:24-EST,410;000000000000
Date: Tuesday, 1 November 1983, 23:40-EST
From: Bruce R. Donald <Brd at MIT-OZ>
To: BUG-hardware at MIT-OZ

In MIT-Specific 19.5, System 94.34, ZMail 50.15, microcode 238, ZM GC@0,
on Lisp Machine Thirty:

Cadr 30 wedges and must be warm-booted about ten times an hour.
This is very annoying. I'm sure you can reproduce it by just trying to use it. Typically,
it wedges in Zmacs CoRoutining Process.
 2-Nov-83 15:14:33-EST,695;000000000000
Date: Wednesday, 2 November 1983, 15:06-EST
From: Alan Bawden <Alan at MIT-MC>
Subject: Bug-Hardware@OZ
To: BUG-HARDWARE at MIT-OZ, BUG-SYMBOLICS-HARDWARE at MIT-OZ,
    BUG-ZMail at SCRC-TENEX
Cc: Alan at MIT-MC

In HARDWARE in Release 5.0 [GC'd Beta Test rev 2], on Lisp Machine Keith Moon (3600):

I had assumed that the mailing list BUG-HARDWARE@OZ included Symbolics
hardware.  However I find that BUG-HARDWARE@OZ points only to
BUG-MIT-HARDWARE@OZ.  This is unfortunate since this is the mailing list that
ZMail automatically uses to report hardware bugs.

Until somebody fixes this in some other way, I will add BUG-SYMBOLICS-HARDWARE
to the BUG-HARDWARE@OZ mailing list.
 2-Nov-83 15:26:54-EST,466;000000000000
Date: Wednesday, 2 November 1983, 15:28-EST
From: Alan Bawden <Alan at MIT-MC>
Subject: Dead Mouse
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in Release 5.0 [GC'd Beta Test rev 2], on Lisp Machine Keith Moon (3600):

It looks like someone flushed the losing mouse from this floor.  (It only took
me 2 minutes to check this.)  I hope that this means that it has been replaced.
If I ever see it again I still plan to carry out my threat to nail it to my
wall.
 2-Nov-83 17:29:21-EST,1033;000000000000
Date: Wed, 2 Nov 83 17:32 EST
From: "Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>
Subject: Bug-Hardware@OZ
To: Alan Bawden <Alan@MIT-MC.ARPA>
Cc: BUG-HARDWARE@MIT-OZ.ARPA, BUG-SYMBOLICS-HARDWARE@MIT-OZ.ARPA,
    BUG-ZMail@SCRC.SCRC.Symbolics
In-reply-to: The message of 2 Nov 83 15:06-EST from Alan Bawden <Alan at MIT-MC>
Message-ID: <831102173255.4.RWK@YUKON.SCRC.Symbolics>

    Date: Wednesday, 2 November 1983, 15:06-EST
    From: Alan Bawden <Alan at MIT-MC>
    In HARDWARE in Release 5.0 [GC'd Beta Test rev 2], on Lisp Machine Keith Moon (3600):

    I had assumed that the mailing list BUG-HARDWARE@OZ included Symbolics
    hardware.  However I find that BUG-HARDWARE@OZ points only to
    BUG-MIT-HARDWARE@OZ.  This is unfortunate since this is the mailing list that
    ZMail automatically uses to report hardware bugs.

    Until somebody fixes this in some other way, I will add BUG-SYMBOLICS-HARDWARE
    to the BUG-HARDWARE@OZ mailing list.
Then I will remove myself from BUG-SYMBOLICS-HARDWARE.
 2-Nov-83 17:41:42-EST,1283;000000000000
Date: Wednesday, 2 November 1983, 17:44-EST
From: Carl Hewitt <Hewitt at MIT-OZ>
Subject: Bug-Hardware@OZ
To: Alan Bawden <Alan at MIT-MC>
Cc: BUG-HARDWARE at MIT-OZ, BUG-SYMBOLICS-HARDWARE at MIT-OZ,
    BUG-ZMail at SCRC-TENEX, Hewitt at MIT-OZ
In-reply-to: The message of 2 Nov 83 15:06-EST from Alan Bawden <Alan at MIT-MC>

    Date: Wednesday, 2 November 1983, 15:06-EST
    From: Alan Bawden <Alan at MIT-MC>
    Subject: Bug-Hardware@OZ
    To: BUG-HARDWARE at MIT-OZ, BUG-SYMBOLICS-HARDWARE at MIT-OZ,
        BUG-ZMail at SCRC-TENEX
    Cc: Alan at MIT-MC

    In HARDWARE in Release 5.0 [GC'd Beta Test rev 2], on Lisp Machine Keith Moon (3600):

    I had assumed that the mailing list BUG-HARDWARE@OZ included Symbolics
    hardware.  However I find that BUG-HARDWARE@OZ points only to
    BUG-MIT-HARDWARE@OZ.  This is unfortunate since this is the mailing list that
    ZMail automatically uses to report hardware bugs.

    Until somebody fixes this in some other way, I will add BUG-SYMBOLICS-HARDWARE
    to the BUG-HARDWARE@OZ mailing list.

Why do you think that Symbolics should get all the hardware bug reports
for all MIT equipment?

It would be nice if the 3600's would default hardware bug reports to
BUG-SYMBOLICS-HARDWARE@OZ.
 2-Nov-83 17:49:26-EST,1243;000000000000
Date: Wednesday, 2 November 1983, 17:51-EST
From: Christopher C. Stacy <CStacy at MIT-MC>
Subject: Bug-Hardware@OZ
To: Carl Hewitt <Hewitt at MIT-OZ>
Cc: Alan Bawden <Alan at MIT-MC>, BUG-HARDWARE at MIT-MC,
    BUG-ZMAIL at SCRC-TENEX, BUG-SYMBOLICS-HARDWARE at MIT-MC
In-reply-to: The message of 2 Nov 83 17:44-EST from Carl Hewitt <Hewitt%MIT-OZ at MIT-MC>

    Date: Wednesday, 2 November 1983, 17:44-EST
    From: Carl Hewitt <Hewitt%MIT-OZ@MIT-MC.ARPA>
	Date: Wednesday, 2 November 1983, 15:06-EST
	From: Alan Bawden <Alan at MIT-MC>
	In HARDWARE in Release 5.0 [GC'd Beta Test rev 2], on Lisp Machine Keith Moon (3600):
	Until somebody fixes this in some other way, I will add BUG-SYMBOLICS-HARDWARE
	to the BUG-HARDWARE@OZ mailing list.
    Why do you think that Symbolics should get all the hardware bug reports
    for all MIT equipment?
    It would be nice if the 3600's would default hardware bug reports to
    BUG-SYMBOLICS-HARDWARE@OZ.

I have been saying for about a year that this is a change which should
be in a "local MIT" system which machines around here loaded.  
Now that there is support for such a system in Release 5, maybe
someone will do it.  (Or come up with a better solution.)

Chris
 3-Nov-83 00:29:23-EST,1513;000000000000
Date: Thu, 3 Nov 83 00:33 EST
From: "Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>
Subject: Bug-Hardware@OZ
To: "Christopher C. Stacy" <CStacy@MIT-MC.ARPA>
Cc: Carl Hewitt <Hewitt@MIT-OZ.ARPA>, Alan Bawden <Alan@MIT-MC.ARPA>,
    BUG-HARDWARE@MIT-MC.ARPA, BUG-ZMAIL@SCRC.SCRC.Symbolics,
    BUG-SYMBOLICS-HARDWARE@MIT-MC.ARPA
In-reply-to: The message of 2 Nov 83 17:51-EST from "Christopher C. Stacy" <CStacy at MIT-MC>
Message-ID: <831103003314.2.RWK@YUKON.SCRC.Symbolics>

    Date: Wednesday, 2 November 1983, 17:51-EST
    From: Christopher C. Stacy <CStacy at MIT-MC>
	Date: Wednesday, 2 November 1983, 17:44-EST
	From: Carl Hewitt <Hewitt%MIT-OZ@MIT-MC.ARPA>
	    Date: Wednesday, 2 November 1983, 15:06-EST
	    From: Alan Bawden <Alan at MIT-MC>
	    In HARDWARE in Release 5.0 [GC'd Beta Test rev 2], on Lisp Machine Keith Moon (3600):
	    Until somebody fixes this in some other way, I will add BUG-SYMBOLICS-HARDWARE
	    to the BUG-HARDWARE@OZ mailing list.
	Why do you think that Symbolics should get all the hardware bug reports
	for all MIT equipment?
	It would be nice if the 3600's would default hardware bug reports to
	BUG-SYMBOLICS-HARDWARE@OZ.

    I have been saying for about a year that this is a change which should
    be in a "local MIT" system which machines around here loaded.  
    Now that there is support for such a system in Release 5, maybe
    someone will do it.  (Or come up with a better solution.)
There has been support for it for a year now!
 3-Nov-83 11:55:50-EST,2301;000000000000
Date: Thursday, 3 November 1983, 11:58-EST
From: Carl Hewitt <Hewitt at MIT-OZ>
Subject: Bug-Hardware@OZ
To: "Robert W. Kerns" <RWK at YUKON.SCRC.Symbolics>
Cc: "Christopher C. Stacy" <CStacy at MIT-MC.ARPA>,
    Carl Hewitt <Hewitt at MIT-OZ.ARPA>,
    Alan Bawden <Alan at MIT-MC.ARPA>, BUG-HARDWARE at MIT-MC.ARPA,
    BUG-ZMAIL at SCRC.SCRC.Symbolics,
    BUG-SYMBOLICS-HARDWARE at MIT-MC.ARPA, Hewitt at MIT-OZ
In-reply-to: <831103003314.2.RWK@YUKON.SCRC.Symbolics>

    Return-path: <Mailer@MIT-XX>
    Date: Thu, 3 Nov 83 00:33 EST
    From: "Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>
    Subject: Bug-Hardware@OZ
    To: "Christopher C. Stacy" <CStacy@MIT-MC.ARPA>
    Cc: Carl Hewitt <Hewitt@MIT-OZ.ARPA>, Alan Bawden <Alan@MIT-MC.ARPA>,
        BUG-HARDWARE@MIT-MC.ARPA, BUG-ZMAIL@SCRC.SCRC.Symbolics,
        BUG-SYMBOLICS-HARDWARE@MIT-MC.ARPA
    In-reply-to: The message of 2 Nov 83 17:51-EST from "Christopher C. Stacy" <CStacy at MIT-MC>
    Message-ID: <831103003314.2.RWK@YUKON.SCRC.Symbolics>

        Date: Wednesday, 2 November 1983, 17:51-EST
        From: Christopher C. Stacy <CStacy at MIT-MC>
            Date: Wednesday, 2 November 1983, 17:44-EST
            From: Carl Hewitt <Hewitt%MIT-OZ@MIT-MC.ARPA>
                Date: Wednesday, 2 November 1983, 15:06-EST
                From: Alan Bawden <Alan at MIT-MC>
                In HARDWARE in Release 5.0 [GC'd Beta Test rev 2], on Lisp Machine Keith Moon (3600):
                Until somebody fixes this in some other way, I will add BUG-SYMBOLICS-HARDWARE
                to the BUG-HARDWARE@OZ mailing list.
            Why do you think that Symbolics should get all the hardware bug reports
            for all MIT equipment?
            It would be nice if the 3600's would default hardware bug reports to
            BUG-SYMBOLICS-HARDWARE@OZ.

        I have been saying for about a year that this is a change which should
        be in a "local MIT" system which machines around here loaded.  
        Now that there is support for such a system in Release 5, maybe
        someone will do it.  (Or come up with a better solution.)
    There has been support for it for a year now!

Sounds like it might be possible for us to win.  Is there documentation
anywhere?
 3-Nov-83 14:28:33-EST,1918;000000000000
Date: Thu, 3 Nov 83 14:23 EST
From: "Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>
Subject: Bug-Hardware@OZ
To: Carl Hewitt <Hewitt%MIT-OZ%MIT-MC@MIT-MC.ARPA>
Cc: "/"///"Christopher C. Stacy///"/"" <CStacy%MIT-MC%MIT-MC@MIT-MC.ARPA>,
    Alan Bawden <Alan%MIT-MC%MIT-MC@MIT-MC.ARPA>,
    BUG-HARDWARE%MIT-MC%MIT-MC@MIT-MC.ARPA,
    BUG-ZMAIL@SCRC.SCRC.Symbolics,
    BUG-SYMBOLICS-HARDWARE%MIT-MC%MIT-MC@MIT-MC.ARPA
In-reply-to: The message of 3 Nov 83 11:58-EST from Carl Hewitt <Hewitt at MIT-OZ>
Message-ID: <831103142353.3.RWK@YUKON.SCRC.Symbolics>

    Date: Thursday, 3 November 1983, 11:58-EST
    From: Carl Hewitt <Hewitt at MIT-OZ>
	Date: Thu, 3 Nov 83 00:33 EST
	From: "Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>
	    Date: Wednesday, 2 November 1983, 17:51-EST
	    From: Christopher C. Stacy <CStacy at MIT-MC>
		Date: Wednesday, 2 November 1983, 17:44-EST
		From: Carl Hewitt <Hewitt%MIT-OZ@MIT-MC.ARPA>
		    Date: Wednesday, 2 November 1983, 15:06-EST
		    From: Alan Bawden <Alan at MIT-MC>
		    In HARDWARE in Release 5.0 [GC'd Beta Test rev 2], on Lisp Machine Keith Moon (3600):
		    Until somebody fixes this in some other way, I will add BUG-SYMBOLICS-HARDWARE
		    to the BUG-HARDWARE@OZ mailing list.
		Why do you think that Symbolics should get all the hardware bug reports
		for all MIT equipment?
		It would be nice if the 3600's would default hardware bug reports to
		BUG-SYMBOLICS-HARDWARE@OZ.

	    I have been saying for about a year that this is a change which should
	    be in a "local MIT" system which machines around here loaded.  
	    Now that there is support for such a system in Release 5, maybe
	    someone will do it.  (Or come up with a better solution.)
	There has been support for it for a year now!

    Sounds like it might be possible for us to win.  Is there documentation
    anywhere?
Yes, the Release 4.0 Release Notes.
 4-Nov-83 01:01:29-EST,1795;000000000000
Date: Friday, 4 November 1983, 01:03-EST
From: Christopher C. Stacy <CStacy at MIT-MC>
Subject: Bug-Hardware@OZ
To: "Robert W. Kerns" <RWK at YUKON.SCRC.Symbolics>
Cc: "Christopher C. Stacy" <CStacy at MIT-MC>,
    Carl Hewitt <Hewitt at MIT-OZ>, Alan Bawden <Alan at MIT-MC>,
    BUG-HARDWARE at MIT-MC, BUG-ZMAIL at SCRC.SCRC.Symbolics,
    BUG-SYMBOLICS-HARDWARE at MIT-MC
In-reply-to: <831103003314.2.RWK@YUKON.SCRC.Symbolics>

    Date: Thu, 3 Nov 83 00:33 EST
    From: "Robert W. Kerns" <RWK@YUKON.SCRC.Symbolics>
	Date: Wednesday, 2 November 1983, 17:51-EST
	From: Christopher C. Stacy <CStacy at MIT-MC>
	    Date: Wednesday, 2 November 1983, 17:44-EST
	    From: Carl Hewitt <Hewitt%MIT-OZ@MIT-MC.ARPA>
		Date: Wednesday, 2 November 1983, 15:06-EST
		From: Alan Bawden <Alan at MIT-MC>
		In HARDWARE in Release 5.0 [GC'd Beta Test rev 2], on Lisp Machine Keith Moon (3600):
		Until somebody fixes this in some other way, I will add BUG-SYMBOLICS-HARDWARE
		to the BUG-HARDWARE@OZ mailing list.
	    Why do you think that Symbolics should get all the hardware bug reports
	    for all MIT equipment?
	    It would be nice if the 3600's would default hardware bug reports to
	    BUG-SYMBOLICS-HARDWARE@OZ.

	I have been saying for about a year that this is a change which should
	be in a "local MIT" system which machines around here loaded.  
	Now that there is support for such a system in Release 5, maybe
	someone will do it.  (Or come up with a better solution.)
    There has been support for it for a year now!

Well, shoot me, but whenever I asked specifically about this (I hope
we are talking about the same thing) I was told that it was not
available yet or just ignored.  I will look at setting this up after
Rel5 is installed over here.
 4-Nov-83 02:11:23-EST,1933;000000000000
Date: 4 November 1983 02:12 EST
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: Bug-Hardware@OZ
To: CARL @ MIT-MC
cc: BUG-HARDWARE @ MIT-MC, BUG-ZMAIL @ MIT-MC

    Date: Wednesday, 2 November 1983, 17:44-EST
    From: Carl Hewitt <Hewitt%MIT-OZ@MIT-MC.ARPA>
    Subject: Bug-Hardware@OZ
    To: Alan Bawden <Alan at MIT-MC>
    Cc: BUG-HARDWARE, BUG-SYMBOLICS-HARDWARE, BUG-ZMail, Hewitt

	Date: Wednesday, 2 November 1983, 15:06-EST
	From: Alan Bawden <Alan at MIT-MC>
	Subject: Bug-Hardware@OZ
	To: BUG-HARDWARE, BUG-SYMBOLICS-HARDWARE, BUG-ZMail
	In HARDWARE in Release 5.0 [GC'd Beta Test rev 2], on Lisp Machine
        Keith Moon (3600):
	I had assumed that the mailing list BUG-HARDWARE@OZ included
        Symbolics hardware.  However I find that BUG-HARDWARE@OZ points
        only to BUG-MIT-HARDWARE@OZ.  This is unfortunate since this is the
        mailing list that ZMail automatically uses to report hardware bugs.
	Until somebody fixes this in some other way, I will add
        BUG-SYMBOLICS-HARDWARE to the BUG-HARDWARE@OZ mailing list.

    Why do you think that Symbolics should get all the hardware bug reports
    for all MIT equipment?

oh come on carl, he never said they SHOULD get the mit equipment breakage
reports. but maybe if they DO get them for a week they will get around to
implementing SOMETHING that will make hardware bug reports from
symbolics-built machines go by default to some list of people who can do
something about fixing the said broken lispms, rather than to a list of
people interested in keeping ITSs, cadrs, tweneces, and vaxen working.  the
point in question is causing fixers of symbolics hardware to know when
symbolics machines here are hardwarily broken; alan's forwarding does that,
in a crude fashion which will tend to encourage them to improve on it.

if kerns wants to remove himself, fine; he probably gets too much mail
anyway.
14-Nov-83 21:28:43-EST,580;000000000000
Date: 14 Nov 1983  21:29 EST (Mon)
Message-ID: <SR.CYPHER.11967687187.BABYL@MIT-SPEECH>
From: Scott Cyphers <SR.CYPHER@MIT-SPEECH>
To:   bug-hardware@MIT-OZ

Cadr12 has a problem where it will stop responding to chaos, i.e.
attempts to file serve it, finger it, status it, etc. think it is not
responding.  This is intermittent.  It has no problems sending things
over the chaosnet (except when it stops responding and the other end
of the connection thinks it has died and closes the connection) and
sending things out will revive it for a while.  Can anyone help us.
15-Nov-83 13:10:43-EST,435;000000000000
Date: Tuesday, 15 November 1983, 13:10-EST
From: Philippe Brou <PHILIP at MIT-OZ>
Subject: Poor screen quality
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in Release 4.5, site configuration 75, on Lisp Machine Robot-3:

Is there anyway to improve the quality
of the display on Robot3 (and Robot4)?

The "l", "i" and even "(" ")" are
almost invisible. Adjusting the intensity
or inverting the display doesn't help.

Philippe
15-Nov-83 13:25:24-EST,270;000000000000
Mail-From: WELG created at 15-Nov-83 13:22:43
Date: Tue 15 Nov 83 13:22-EST
From: W. Eric L. Grimson <WELG@MIT-OZ>
Subject: cadr-30
To: bug-lispm@MIT-OZ, bug-hardware@MIT-OZ

Cadr-30 is wedged is such a state that it no longer responds to
a cold boot command.

17-Nov-83 17:42:22-EST,8235;000000000000
Mail-From: RMS created at 17-Nov-83 17:41:53
Date: Thu 17 Nov 83 17:41-EST
From: mly
Sender: Richard M. Stallman <RMS@MIT-OZ>
Subject: cadr-1 disk error
To: bug-hardware@MIT-OZ

;;;(with-paid-political-advertisment
;;;  (format t "fascist twenex won't let mly (a tourist) log in"))

trying to cold-boot cadr 1 from band 2 (98.0 x8) to band 8 (97.25)

(cc)
CC contains saved state; type Control-S read fresh state from machine.
***********************************************
PC=23731   OBUS=0   (FATAL-DISK-ERROR 1)
IR= ( (M-1 ) LDB (BYTE-FIELD 30 0) C-PDL-BUFFER-POINTER-POP A-ZERO ) 
ERROR-STATUS JC-TRUE NO-OP ANY-ERR 
:why Machine being debugged is MIT-LISPM-1.
Disk error: Fault  Transfer-Aborted
  disk address: UNIT 0 CYLINDER 0 HEAD 0 SECTOR 0 
  last memory address touched by disk = 41020
Contents of disk error log in debugee's main memory 600-640:

Command 11 (Write) 
CCW-list pointer 40000 (low 16 bits)
Disk address: unit 0, cylinder 7, head 16, block 11 (0 7 14 9 decimal)
Memory address: 41020 (type bits 0)
Status: 1100020111  Transfer-Aborted (or wr. ovr.)  Fault  Interrupt  Idle

Command 11 (Write) 
CCW-list pointer 40000 (low 16 bits)
Disk address: unit 0, cylinder 7, head 16, block 11 (0 7 14 9 decimal)
Memory address: 41020 (type bits 0)
Status: 1100020111  Transfer-Aborted (or wr. ovr.)  Fault  Interrupt  Idle

Command 11 (Write) 
CCW-list pointer 40000 (low 16 bits)
Disk address: unit 0, cylinder 0, head 0, block 0 (0 0 0 0 decimal)
Memory address: 41020 (type bits 0)
Status: 600020101  Transfer-Aborted (or wr. ovr.)  Fault  Idle

Type :WHYSOFT to attempt to analyze the current software state.
:whysoft Machine being debugged is MIT-LISPM-1.

Microcode halted via ILLOP from FATAL-DISK-ERROR
Micro PC History (OPC's), oldest first:
   23750   (LOG-DISK-ERROR 16)
   23666   (DISK-COMPLETION-ERROR 2)
   23667   (DISK-COMPLETION-ERROR 3)
   23670   (DISK-COMPLETION-ERROR 4)
   23730   FATAL-DISK-ERROR
   23731   (FATAL-DISK-ERROR 1)
   00023   ILLOP
   00024   XWIPM
Backtrace of microcode subroutine stack:
   15  026377   (COLD-AWAIT-DISK 2)
   14  026362   (DISK-COPY-PART-3 10)
   13  025632   (DISK-RR-1 21)
   12  025575   (DISK-RESTORE-REGIONWISE-INC 1)
   11  000000   COPY-BUFFER-CCW-ORIGIN
   10  000000   COPY-BUFFER-CCW-ORIGIN
    7  000000   COPY-BUFFER-CCW-ORIGIN
    6  000000   COPY-BUFFER-CCW-ORIGIN
    5  000000   COPY-BUFFER-CCW-ORIGIN
    4  000000   COPY-BUFFER-CCW-ORIGIN
    3  000000   COPY-BUFFER-CCW-ORIGIN
    2  000000   COPY-BUFFER-CCW-ORIGIN
    1  000000   COPY-BUFFER-CCW-ORIGIN
    0  000000   COPY-BUFFER-CCW-ORIGIN

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 145
LAST-CC-COMMAND WRITE 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 0 SECTOR 1 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

RETRYING 

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 150
LAST-CC-COMMAND WRITE 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 0 SECTOR 1 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

RETRYING 

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 152
LAST-CC-COMMAND WRITE 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 0 SECTOR 1 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

RETRYING 

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 154
LAST-CC-COMMAND WRITE 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 0 SECTOR 1 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

RETRYING 

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 157
LAST-CC-COMMAND WRITE 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 0 SECTOR 1 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 162
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 0 SECTOR 0 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

RETRYING 

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 164
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 0 SECTOR 0 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

RETRYING 

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 167
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 0 SECTOR 0 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

RETRYING 

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 172
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 0 SECTOR 0 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

RETRYING 

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 174
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 0 SECTOR 0 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000
Warning: label check word is "", not "LABL".
Warning: label version is 83886336., not 1.
DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 177
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 0 SECTOR 1 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

RETRYING 

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 202
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 0 SECTOR 1 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

RETRYING 

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 205
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 0 SECTOR 1 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

RETRYING 

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 210
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 0 SECTOR 1 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

RETRYING 

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 213
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 0 SECTOR 1 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 4000

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 216
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 172 SECTOR 15 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 640400

RETRYING 

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 221
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 172 SECTOR 15 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 640400

RETRYING 

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 224
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 172 SECTOR 15 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 640400

RETRYING 

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 227
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 172 SECTOR 15 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 640400

RETRYING 

DISK-CONTROL-STATUS TRANSFER-ABORTED FAULT IDLE 
ECC ERROR PATTERN BITS 2100
ECC ERROR BIT POSITION 232
LAST-CC-COMMAND READ 
DISK-ADDRESS UNIT 0 CYLINDER 0 HEAD 172 SECTOR 15 
MEMORY-ADDRESS 41020
LAST-CC-COMMAND-LIST-POINTER 12
COMMAND-LIST 
12 640400
[Sorry, error while trying to print that.]
23-Nov-83 13:54:11-EST,278;000000000000
Received: from MIT-LISPM-24 by MIT-OZ via Chaosnet; 23 Nov 83 13:53-EST
Date: Wednesday, 23 November 1983, 14:00-EST
From: H. Keith Nishihara <Nis at MIT-OZ>
To: bug-hardware at MIT-OZ

cadr-25 does not listen to keyboard
does not seem to be monitor or keyboard
--keith
27-Nov-83 23:29:36-EST,528;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 27 Nov 83 23:29-EST
Date: Sunday, 27 November 1983, 18:51-EST
From: Philippe Brou <PHILIP at MIT-MC>
To: BUG-Hardware at MIT-OZ

In Hardware in MIT-Specific 19.5, System 94.41, ZMail 50.17,
Experimental Local-File 44.3, microcode 239, gc@34,
on Lisp Machine Twenty-three:

CADR-32 (the one next to the color TV on the
3rd floor) has or thinks it has only 64K 
of memory. This makes it absolutely useless.

Can anyone add more memory (at least up to 256K)?

Philippe
28-Nov-83 13:33:26-EST,372;000000000000
Mail-From: EHL created at 28-Nov-83 13:33:02
Date: Mon, 28 Nov 1983  13:33 EST
Message-ID: <EHL.11971270526.BABYL@MIT-OZ>
From: EHL@MIT-OZ
To:   bug-mit-hardware@MIT-OZ
cc:   boxer@MIT-MC
subject:cadr-20's keyboard...

...is broken.  Specifically, the hyphen-key and the
comma-key both want to generate a lot of spurious characters
whenever they are depressed.
30-Nov-83 01:23:15-EST,706;000000000000
Mail-From: JOHANN created at 30-Nov-83 01:22:53
Date: Wed 30 Nov 83 01:22-EST
From: John Amuedo <JOHANN@MIT-OZ>
Subject: Dead CADR's
To: bug-hardware@MIT-OZ


CADR-6 failed three times this evening, finally passing
on into nonfunctional Neverneverland (MTBF < 10 min.).
I am running LOD7, Symbolics release 4.3, System 222.296,
making heavy use of attached FPS-box (which appears quite
healthy).

CADR-4 (with attached CHROMA) has been inoperative for at
least two weeks.  I do not know what problems this machine
may have.

I am making heavy use of both of these machines right now,
and could use some assistance in getting both machines up
and running.

Thanks much,
John Amuedo

 1-Dec-83 08:29:20-EST,494;000000000000
Received: from MIT-LISPM-24 by MIT-OZ via Chaosnet; 1 Dec 83 08:29-EST
Date: Thursday, 1 December 1983, 08:35-EST
From: Kim A. Barrett <kab at MIT-OZ>
To: BUG-Hardware at MIT-OZ

In Hardware in System 97.25, CADR 1.0, ZMail 51.9, MIT-Specific 21.0,
microcode 257, ZM MIT, on Lisp Machine Twenty-four:

This machine got repeated disk errors in the PAGE partition.  Currently running, after
being cold booted (just got repeated errors when you tried to do anything after a
warm boot).
 1-Dec-83 08:43:05-EST,352;000000000000
Received: from MIT-LISPM-3 by MIT-OZ via Chaosnet; 1 Dec 83 08:42-EST
Date: Thursday, 1 December 1983, 08:48-EST
From: Richard M. Stallman <RMS at MIT-OZ>
To: BUG-Hardware at MIT-OZ

In Hardware in System 97.28, CADR 1.0, ZMail 51.9, MIT-Specific 21.0,
microcode 257, ZM MIT, on Lisp Machine Three:

keyboard on this machine is very sick...  
 3-Dec-83 18:34:55-EST,553;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 3 Dec 83 18:34-EST
Date: 3 December 1983 06:00 EST
From: David Vinayak Wallace <GUMBY @ MIT-MC>
Subject:  broken dover
To: BUG-HARDWARE @ MIT-MC

I shut off the dover spooler because the alto running spruce could not
talk to its disk.  Spinning the disk down and up again didn't help.

At the time it this happened, the dover itself was producing very poor
output -- the paper was smeared with toner and fuser oil, and had a
tendecy to jam.

So, what's the story on the second dover?

david
 3-Dec-83 18:53:41-EST,368;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 3 Dec 83 18:53-EST
Date: 3 December 1983 06:56 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: GUMBY @ MIT-MC
cc: BUG-HARDWARE @ MIT-MC


That *is* the second Dover; the old one is in a crate downstairs
in the basement.  I heard someone decided it was irreperable, but
I am not sure if that is true or not.
 4-Dec-83 23:11:55-EST,715;000000000000
Mail-From: JOHANN created at  4-Dec-83 23:11:41
Date: Sun 4 Dec 83 23:11-EST
From: John Amuedo <JOHANN@MIT-OZ>
Subject: Dead and Living CADR's
To: bug-hardware@MIT-OZ


Thanks to whomever repaired CADR-4 so quickly.
The users of Fellini's CHROMA are exceedingly
grateful.

CADR-6 unfortunately has not shown any signs
of life since its untimely demise three weeks
ago.  Any chance this problem might be solved
in the next few days?  If it appears not, I
would like to move the FPS-box and its
accompanying SPIRE band to another machine.

Would someone please send me a message about
the status of its repair?

Thanks again for getting CADR-4 back on the air.

Best regards,

John Amuedo

 5-Dec-83 09:31:34-EST,537;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 5 Dec 83 09:30-EST
Date: Monday, 5 December 1983, 09:35-EST
From: Alan Bawden <Alan at MIT-MC>
Subject: Mouse degradation
To: BUG-HARDWARE at MIT-AI, BUG-SYMBOLICS-HARDWARE at MIT-AI

In HARDWARE in Release 5.0 [GC'd Beta Test rev 3], dusty plum, on Lisp Machine Jimi Hendrix (3600):

The mouse currently connected to this machine, Mouse House serial number 05645,
Symbolics serial number 186, is starting to have the usual tracking problems.
(I still have my hammer and nail...)
 5-Dec-83 10:10:05-EST,407;000000000000
Mail-From: WELG created at  5-Dec-83 10:09:40
Date: Mon 5 Dec 83 10:09-EST
From: W. Eric L. Grimson <WELG@MIT-OZ>
Subject: cadr-30
To: bug-hardware@MIT-OZ

Cadr-30 just died with a disk error... to the point where it will not
respond to a warm or cold boot.  The error message printed before dyiing
was
 
Disk read error unit 0 cyl 100. surf. 3 sec 5.
status ECC-hard  Transfer-aborted.

eric
 5-Dec-83 14:42:57-EST,389;000000000000
Received: from MIT-LISPM-3 by MIT-OZ via Chaosnet; 5 Dec 83 14:42-EST
Date: Monday, 5 December 1983, 14:42-EST
From: Bruce R. Donald <brd at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ

In System 97.20, CADR 1.0, ZMail 51.7, MIT-Specific 21.0, microcode 257,
ZM MIT, on Lisp Machine Three:

CADR-3 is dying a lot while running in the lisp listener and
needs to be warm-booted frequently.
 5-Dec-83 20:26:45-EST,2613;000000000000
Received: from MIT-LISPM-30 by MIT-OZ via Chaosnet; 5 Dec 83 20:25-EST
Date: Monday, 5 December 1983, 20:23-EST
From: Patrick G. Sobalvarro <PGS at MIT-OZ>
Reply-to: BRD at MIT-OZ
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in System 97.26, CADR 1.0, ZMail 51.9, MIT-Specific 21.0,
microcode 257, GC@24, on Lisp Machine Thirty-one:

Here is the CC :WHY report on CADR-31's crashing. I twiddled the
above line to reflect CADR-31's state.

Insert your description of the circumstances, and how often the problem occurs:

CADR-31 was crunching a lot of floating point and died as follows:
The Garbage Collector was on if that matters, although it was not in GC
if that matters, and at least one flip had occured.
 
 --- BRD

[Warning: A-V-NIL's contents are garbage.
Assuming 24-bit pointers on target machine, since cannot tell for certain.]
Machine being debugged is MIT-LISPM-31.

[Warning: A-V-NIL's contents are garbage.
Assuming 24-bit pointers on target machine, since cannot tell for certain.]

[Warning: A-V-NIL's contents are garbage.
Assuming 24-bit pointers on target machine, since cannot tell for certain.]

Microcode halted via ILLOP from ARITH-ANY-XNM+6
[Warning: A-V-NIL's contents are garbage.
Assuming 24-bit pointers on target machine, since cannot tell for certain.]

Micro PC History (OPC's), oldest first:
   22072   (PGF-R 5)
   13531   (ARITH-ANY-XNM 3)
   13532   (ARITH-ANY-XNM 4)
   13533   (ARITH-ANY-XNM 5)
   13534   (ARITH-ANY-XNM 6)
   13535   (ARITH-ANY-XNM 7)
   00023   ILLOP
   00024   XWIPM
Backtrace of microcode subroutine stack:
   27  1213535   (ARITH-ANY-XNM 7)
   26  1213535   (ARITH-ANY-XNM 7)
   25  1213535   (ARITH-ANY-XNM 7)
   24  1213535   (ARITH-ANY-XNM 7)
   23  1213535   (ARITH-ANY-XNM 7)
   22  1213535   (ARITH-ANY-XNM 7)
   21  1213535   (ARITH-ANY-XNM 7)
   20  1213535   (ARITH-ANY-XNM 7)
   17  1213535   (ARITH-ANY-XNM 7)
   16  1213535   (ARITH-ANY-XNM 7)
   15  1213535   (ARITH-ANY-XNM 7)
   14  1213535   (ARITH-ANY-XNM 7)
   13  1213535   (ARITH-ANY-XNM 7)
   12  1213535   (ARITH-ANY-XNM 7)
   11  1213535   (ARITH-ANY-XNM 7)
   10  1213535   (ARITH-ANY-XNM 7)
    7  1213535   (ARITH-ANY-XNM 7)
    6  1213535   (ARITH-ANY-XNM 7)
    5  1213535   (ARITH-ANY-XNM 7)
    4  1213535   (ARITH-ANY-XNM 7)
    3  1213535   (ARITH-ANY-XNM 7)
    2  1213535   (ARITH-ANY-XNM 7)
    1  1213535   (ARITH-ANY-XNM 7)
    0  1213535   (ARITH-ANY-XNM 7)
Microcode state flags: in transporter

>>ERROR: 2131773662 NO ARRAY LEADER - QF-ARRAY-LEADER

[Sorry, error while trying to print that.]
 6-Dec-83 01:34:35-EST,1610;000000000000
Received: from MIT-LISPM-30 by MIT-OZ via Chaosnet; 6 Dec 83 01:34-EST
Date: Tuesday, 6 December 1983, 01:32-EST
From: Patrick G. Sobalvarro <PGS at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in System 97.28, CADR 1.0, ZMail 51.9, MIT-Specific 21.0,
microcode 257, GC@24, on Lisp Machine Thirty:

I can't disk-save into lod4 on cadr-31.  I don't know if it's only this band,
but it is certainly consistent and reproducible.

Machine being debugged is MIT-LISPM-31.
Disk error: Fault  Transfer-Aborted
  disk address: UNIT 0 CYLINDER 657 HEAD 0 SECTOR 0 
  last memory address touched by disk = 41020
Contents of disk error log in debugee's main memory 600-640:

Command 11 (Write) 
CCW-list pointer 40000 (low 16 bits)
Disk address: unit 0, cylinder 657, head 0, block 0 (0 431 0 0 decimal)
Memory address: 41020 (type bits 0)
Status: 40020111  Internal-parity  Transfer-Aborted (or wr. ovr.)  Fault  Interrupt  Idle

Microcode halted via ILLOP from FATAL-DISK-ERROR
Micro PC History (OPC's), oldest first:
   23750   (LOG-DISK-ERROR 16)
   23666   (DISK-COMPLETION-ERROR 2)
   23667   (DISK-COMPLETION-ERROR 3)
   23670   (DISK-COMPLETION-ERROR 4)
   23730   FATAL-DISK-ERROR
   23731   (FATAL-DISK-ERROR 1)
   00023   ILLOP
   00024   XWIPM
Backtrace of microcode subroutine stack:
    5  026377   (COLD-AWAIT-DISK 2)
    4  026362   (DISK-COPY-PART-3 10)
    3  025430   DISK-SR-2
    2  025403   (DISK-SAVE-REGIONWISE 1)
    1  000511   M-T-TO-STACK
    0  040164   QMLP

>>ERROR: NOTHING-TO-SWAP-OUT QF-FINDCORE

[Sorry, error while trying to print that.]
 6-Dec-83 10:06:53-EST,366;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 6 Dec 83 10:05-EST
Date: Tuesday, 6 December 3883, 10:02-EST
From: Richard Mlynarik <Mly at MIT-OZ>
Subject: cadr1 kbd
To: bug-hardware at MIT-OZ

The kbd for cadr 1 intermittently generates garbage, most
of which the software beeps at. "Stop-output" and "page"
are typical things which do get through unbeeped
 6-Dec-83 10:29:20-EST,312;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 6 Dec 83 10:28-EST
Date: Tuesday, 6 December 1983, 10:30-EST
From: Alan T. Sherman <SHERMA at MIT-MC>
Subject: mailing list
To: bug-hardware at ai, bug-symbolics-hardware at ai,
    bug-3600-hardware at ml

Please take me off your mailing list. Thanks, Alan
 7-Dec-83 11:15:03-EST,811;000000000000
Received: from MIT-LISPM-32 by MIT-OZ via Chaosnet; 7 Dec 83 11:14-EST
Date: Wednesday, 7 December 1983, 11:12-EST
From: Michael Erdmann <ME at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ, RMS at MIT-OZ

In HARDWARE in System 97.28, CADR 1.0, ZMail 51.9, MIT-Specific 21.0,
microcode 257, ZM MIT, on Lisp Machine Thirty-two:


Insert your description of the circumstances, and how often the problem occurs:

CADR-31 got a memory parity error and died, running system 97.20 microcode 257.
I think the memory parity errror (so sez CC) may explain yesterday's
errors.


[Warning: A-V-NIL's contents are garbage.
Assuming 24-bit pointers on target machine, since cannot tell for certain.]
Error printing debugging information:
  Unable to figure out page table area; virtual memory access will not work.
 7-Dec-83 11:17:59-EST,818;000000000000
Received: from MIT-LISPM-32 by MIT-OZ via Chaosnet; 7 Dec 83 11:17-EST
Date: Wednesday, 7 December 1983, 11:15-EST
From: Michael Erdmann <ME at MIT-OZ>
Reply-to: BRD at MIT-OZ
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in System 97.28, CADR 1.0, ZMail 51.9, MIT-Specific 21.0,
microcode 257, ZM MIT, on Lisp Machine Thirty-two:


Insert your description of the circumstances, and how often the problem occurs:

Cadr-31 crashing system running 97.20 microcode 257. Sorry Forgot to
mention that that was a "main Memory Parity Error" according to CC.

	     --- Brd.


[Warning: A-V-NIL's contents are garbage.
Assuming 24-bit pointers on target machine, since cannot tell for certain.]
Error printing debugging information:
  Unable to figure out page table area; virtual memory access will not work.
 8-Dec-83 13:47:11-EST,454;000000000000
Received: from MIT-LISPM-23 by MIT-OZ via Chaosnet; 8 Dec 83 13:45-EST
Date: Thursday, 8 December 1983, 13:43-EST
From: Philippe Brou <PHILIP at MIT-OZ>
To: BUG-Hardware at MIT-OZ

In Hardware in System 97.26, CADR 1.0, ZMail 51.9, MIT-Specific 21.0,
Experimental Touch_system 25.0, microcode 257, ZM MIT,
on Lisp Machine Twenty-three:

[BREAK] key does not function properly on 
keyboard. (sends 4 or 5 characters)
Console is next to 352.

 8-Dec-83 17:30:30-EST,400;000000000000
Mail-From: RMS created at  8-Dec-83 17:30:03
Date: Thu 8 Dec 83 17:30-EST
From: Richard M. Stallman <RMS@MIT-OZ>
Subject: CADR-1 chaosnet
To: bug-hardware@MIT-OZ

I think this hardware is not working.
The machine will not boot because it gets hung
trying to ask machines what time it is.
WHen it gets hung, it is waiting for chaosnet replies,
not halted.  The same software worked before.
 8-Dec-83 22:00:46-EST,260;000000000000
Received: from MIT-LISPM-1 by MIT-OZ via Chaosnet; 8 Dec 83 22:00-EST
Date: Thursday, 8 December 3883, 21:58-EST
From: Richard M. Stallman <RMS at MIT-OZ>
To: bug-hardware at MIT-OZ

I fixed the CADR-1 chaosnet interface by plugging the power supply in.
 9-Dec-83 10:08:06-EST,212;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 9 Dec 83 10:07-EST
Date: 9 December 1983 10:03 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC
cc: KMP @ MIT-MC


CADR-22 is down.
10-Dec-83 19:18:59-EST,253;000000000000
Mail-From: JOHANN created at 10-Dec-83 19:16:46
Date: Sat 10 Dec 83 19:16-EST
From: John Amuedo <JOHANN@MIT-OZ>
Subject: CADR-6
To: bug-hardware@MIT-OZ


Would someone who knows the status of repairs to CADR-6
please send me mail?

Thanks.

11-Dec-83 00:22:02-EST,378;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 11 Dec 83 00:21-EST
Date: 11 December 1983 00:16 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
Subject: chaosnet may be losing
To: BUG-HARDWARE @ MIT-MC
cc: KMP @ MIT-MC


Chaosnet connections from NE43-8A-HUB (at least to MC) are
poor, with very slow throughput, long delays, and sometimes
timing out of connections.
11-Dec-83 20:18:43-EST,603;000000000000
Mail-From: KMP created at 11-Dec-83 20:18:14
Date: Sun 11 Dec 83 20:18-EST
From: Kent M Pitman <KMP@MIT-OZ>
Subject: Cadr-22
To: bug-hardware@MIT-OZ
CC: kbe-i@MIT-OZ

Cadr-22 has been down since Friday morning. CStacy sent a rather brief
message saying just that it was down but didn't say much more than that.
Specifically, it seems to have full power. I checked the breakers. They
are fine. I power cycled the machine and tried booting it from the little
boot button on the machine but that didn't seem to do anything. If 
someone would please look at it, I'd appreciate it. Thanks. -kmp
12-Dec-83 08:26:59-EST,621;000000000000
Mail-From: AKR created at 12-Dec-83 08:26:38
Date: Mon, 12 Dec 1983  08:26 EST
Message-ID: <AKR.11974884761.BABYL@MIT-OZ>
From: AKR@MIT-OZ
To:   John Amuedo <JOHANN@MIT-OZ>
Cc:   bug-hardware@MIT-OZ
Subject: cadr-6
In-reply-to: Msg of 4 Dec 1983  23:11-EST from John Amuedo <JOHANN>


A broken ALU was replaced on cadr6 a week or 2 ago.
Has it been crashing since then?  It seemd to be up all the
time.  If it does crash, people should include more information
in the bug report (ie what they were doing when it crashed).
I was using it 2 days ago  and it worked fine.  However I
did not use the FPS box.
12-Dec-83 09:40:59-EST,812;000000000000
Mail-From: KMP created at 12-Dec-83 09:40:13
Date: Mon 12 Dec 83 09:40-EST
From: Kent M Pitman <KMP@MIT-OZ>
Subject: Avatar revived
To: BUG-HARDWARE@MIT-OZ

Hmm. It was having continued troubles just now, but I noticed that in spite
of my inability to type to it, today the wholine seemed to have a live clock.
So it occurred to me that the console cord might simply be loose; I had already
tried booting the keyboard and it made noises like it had a good connection,
but I guess that isn't sufficient to know all the cables are in place because
indeed the connector to the keyboard in the back of the machine was a little
loose and when I tightened it, the machine started behaving normally. So it
seems to be fine now. If I find later that this wasn't the problem, I'll send
a fresh bug report.
12-Dec-83 09:52:08-EST,588;000000000000
Mail-From: AKR created at 12-Dec-83 09:51:14
Date: Mon, 12 Dec 1983  09:51 EST
Message-ID: <AKR.11974900163.BABYL@MIT-OZ>
From: AKR@MIT-OZ
To:   Kent M Pitman <KMP@MIT-OZ>
Cc:   bug-hardware@MIT-OZ, kbe-i@MIT-OZ
Subject: Cadr-22
In-reply-to: Msg of 11 Dec 1983  20:18-EST from Kent M Pitman <KMP>


Cadr-22 should be working now.  There was a problem with the
IOB board flaking out.  Again, since the number of people
maintaining cadrs is epsilon, where epsilon is smaller than 1,
you should include as much information as possible with any
bug-hardware message.  Thanks. 
12-Dec-83 22:09:58-EST,1138;000000000000
Mail-From: JOHANN created at 12-Dec-83 22:08:35
Date: Mon 12 Dec 83 22:08-EST
From: John Amuedo <JOHANN@MIT-OZ>
Subject: CADR-6
To: AKR@MIT-OZ, BUG-HARDWARE@MIT-OZ, PHW@MIT-OZ, KAREN@MIT-OZ


CADR-6 has been down for over a month.  I have sent five
bug reports to BUG-HARDWARE with no response.  AKR suggests
CADR-6 "has been up all of the time" and that it "was used
two days ago".  This response is absurd.  I make heavy use
of this machine and the attached FPS box, as I explained in
my original message.  I have inquired weekly as to progress
related to its repairs, and there has been no response.  I
asked that I be informed if CADR-6 was likely to be down
for an extended period of time, so I could move the FPS box
to a working CADR.  It appears that whomever (if anyone) is
reading BUG-HARDWARE these days seems to have confused
CADR-6 with another machine.  I spend 8-10 hours daily near
its console, and have not seen it powered up in five weeks.
If an insumountable problem has been encountered in its
repair, I would appreciate a response so other arrangements
can be made.

Thanks,

John Amuedo

12-Dec-83 23:12:56-EST,2713;000000000000
Mail-From: AKR created at 12-Dec-83 23:10:09
Date: Mon, 12 Dec 1983  23:10 EST
Message-ID: <AKR.11975045596.BABYL@MIT-OZ>
From: AKR@MIT-OZ
To:   John Amuedo <JOHANN@MIT-OZ>
Cc:   BUG-HARDWARE@MIT-OZ, KAREN@MIT-OZ, PHW@MIT-OZ
Subject: CADR-6
In-reply-to: Msg of 12 Dec 1983  22:08-EST from John Amuedo <JOHANN>

Maybe someone should plug the power cord into cadr6's console
on the 7th floor, but cadr6 is certainly up as you can see:
(If the console is broken, you should send a message to bug-hardware
or tell Ron Wicken in 926 that the console is broken.)

[PHOTO:  Recording initiated  Mon 12-Dec-83 10:52PM]
 MIT TOPS-20 Command Processor 5(750)-2
@day$time 
 Monday, December 12, 1983 10:52:26PM-EST
@f @lm6
[MIT-LISPM-6]
       -                        MIT-LISPM-6 24:48     7th x8975 FPS Express, co
@telnet cadr6 eval 
 Trying... Open
(print-disk-label)
CADR-6: Trident T-300, New Label 3/16/83 by DPH
LABL version 1, 815 cylinders, 19 heads, 17 blocks/track, 323 blocks/cylinder
Current microload = MCR6, current virtual memory load (band) = LOD1
18 partitions, 7-word descriptors:
  MCR1 at block 17, 148 blocks long, "UCADR 253"
  MCR2 at block 165, 148 blocks long, "UCADR 238"
  MCR3 at block 313, 148 blocks long, "UCADR 979"
  MCR4 at block 461, 148 blocks long, "UCADR 201"
  MCR5 at block 609, 148 blocks long, "UCADR 239"
* MCR6 at block 757, 148 blocks long, "UCADR 257"
  MCR7 at block 905, 148 blocks long, "UCADR 963"
  PAGE at block 1053, 65485 blocks long, "Virtual Memory"
* LOD1 at block 66538, 24225 blocks long, "97.23, ZM MIT"
  LOD2 at block 90763, 24225 blocks long, "Rel 4.5"
  LOD3 at block 114988, 24225 blocks long, "Rel 4.3"
  METR at block 139213, 20000 blocks long, "Meter band"
  LOD8 at block 159213, 4225 blocks long, "CAL"
  LOD5 at block 163438, 20000 blocks long, "97.12, ZM MIT"
  DFIL at block 183438, 4225 blocks long, "LM File System"
  LOD6 at block 187663, 36000 blocks long, "94.39, gc@34"
  LOD7 at block 223663, 36675 blocks long, "Spire 11.44"
  FILE at block 260338, 2907 blocks long, "** LIVE Files **"(T)
(room)
Physical memory: 1400000 (384K), Free space: 51240047 (10576K), Wired pages 42+22 (16K)
WORKING-STORAGE-AREA....................(9 regions) 2112K allocated, 1537K used.
MACRO-COMPILED-PROGRAM..................(5 regions) 640K allocated, 532K used.
(NIL)
(si:print-herald)
MIT System, band 1 of CADR-6. (ZM MIT)
384K physical memory, 16127K virtual memory.
 System        97.23
 CADR           1.0
 ZMail         51.9
 MIT-Specific  21.0
 Microcode    257
MIT Lisp Machine Six, with associated machine OZ.
Connection closed
@pop
[PHOTO:  Recording terminated  Mon 12-Dec-83 10:53PM]
12-Dec-83 23:31:14-EST,724;000000000000
Mail-From: JOHANN created at 12-Dec-83 23:30:10
Date: Mon 12 Dec 83 23:30-EST
From: John Amuedo <JOHANN@MIT-OZ>
Subject: CADR-6
To: AKR@MIT-OZ, BUG-HARDWARE@MIT-OZ, PHW@MIT-OZ, KAREN@MIT-OZ


CADR-6's console APPEARS to be O.K., except that someone
seems to have scavenged its keyboard.  Can it be replaced
by a working spare?

The console was unplugged WEEKS ago when I reported the
original problem.  I assumed that it would be reconnected
as soon as that problem was resolved.  Had someone sent
me mail to that effect, I would have gladly plugged in
CADR-6's console upon hearing the repairs were done.

Thanks for getting this machine back on the air, and for
responding to my last message.

John

14-Dec-83 19:48:23-EST,1718;000000000000
Received: from MIT-ML by MIT-OZ via Chaosnet; 14 Dec 83 19:46-EST
Date: Wednesday, 14 December 1983, 19:50-EST
From: Sarah L. Ferguson <SASHA at MIT-ML>
Reply-to: BRD at OZ, ME at OZ
To: BUG-HARDWARE at MIT-OZ, rms at MIT-ML

In HARDWARE in System 97.20, CADR 1.0, ZMail 51.8, MIT-Specific 21.0,
microcode 257, ZM MIT, on Lisp Machine Thirty-one:


Insert your description of the circumstances, and how often the problem occurs:

CADR 32 was running 97.28 microcode 257 and died in the midst of a 
(write) file operation surrounded by lots of flonum crunching. The
Garbage Collector was on. This has happened at least ten times under
similar circumstances (i.e, sometimes occurs after 10 file operations,
sometimes after two). ME can show you the (brief) source code for
the file stuff if that helps.

-- Mike , Bruce.

Machine being debugged is MIT-LISPM-32.
Bus-interface errors since last reset:
  Parity error in data from processor

This program doesn't understand why the machine stopped (not ILLOP).

Micro PC History (OPC's), oldest first:
   23211   (XRGN1 10)
   05735   CDR-IS-NIL
   05736   (XFALSE 1)
   22126   (GET-MAP-BITS 12)
   22127   (GET-MAP-BITS 13)
   00023   ILLOP
   00024   XWIPM
   22127   (GET-MAP-BITS 13)
Backtrace of microcode subroutine stack:
    4  016512   (TRANS-OLD0 2)
    3  024711   (SG-LOAD-BLOCK-INTO-PDL-BUFFER 4)
    2  024763   (SGENT 12)
    1  025227   (SG-ENTER-NO-PREV 2)
    0  040164   QMLP
Microcode state flags: switching stack groups

Current stack group is: <Stack Group Lisp Listener 2>
Current process is: #<DTP-INSTANCE 50040204>"Lisp Listener 2"
Complete backtrace follows: (type Space to stop)

704720 0[0]

15-Dec-83 19:45:33-EST,1676;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 15 Dec 83 19:43-EST
Received: from MIT-LISPM-30 by MIT-OZ via Chaosnet; 15 Dec 83 19:39-EST
Date: Thursday, 15 December 1983, 19:40-EST
From: Patrick G. Sobalvarro <PGS%MIT-OZ@MIT-MC.ARPA>
Subject: CADR-6
To: JOHANN%MIT-OZ@MIT-MC.ARPA, AKR%MIT-OZ@MIT-MC.ARPA,
    BUG-HARDWARE%MIT-OZ@MIT-MC.ARPA, PHW%MIT-OZ@MIT-MC.ARPA,
    KAREN%MIT-OZ@MIT-MC.ARPA
In-reply-to: The message of 12 Dec 1983 22:08-EST from John Amuedo <JOHANN%MIT-OZ at MIT-MC.ARPA>

    Received: from MIT-MC by MIT-OZ via Chaosnet; 15 Dec 83 18:38-EST
    Date: Mon 12 Dec 83 22:08-EST
    From: John Amuedo <JOHANN%MIT-OZ@MIT-MC.ARPA>
    Subject: CADR-6
    To: AKR%MIT-OZ@MIT-MC.ARPA, BUG-HARDWARE%MIT-OZ@MIT-MC.ARPA,
	PHW%MIT-OZ@MIT-MC.ARPA, KAREN%MIT-OZ@MIT-MC.ARPA


    CADR-6 has been down for over a month.  I have sent five
    bug reports to BUG-HARDWARE with no response.  AKR suggests
    CADR-6 "has been up all of the time" and that it "was used
    two days ago".

Whoah.  John, CADR-6 has indeed been up.  I've used it several times while
you've been sending these messages, and I have checked to see if it was up, and
it indeed always was up, just as Alex told you.  All I can figure out is that
maybe someone with an office nearby doesn't like the sound of the console and
has been disconnecting it.  What you should have done was try to plug in the
console, or finger the machine, or something besides sending increasingly
strident messages to Alex.  I think that probably the best thing you could have
done is go talk to him if you didn't understand why he was telling you it was
up when it seemed to be down.
16-Dec-83 02:34:32-EST,367;000000000000
Received: from MIT-LISPM-24 by MIT-OZ via Chaosnet; 16 Dec 83 02:34-EST
Date: Friday, 16 December 1983, 02:33-EST
From: Kim A. Barrett <kab at MIT-OZ>
To: BUG-Hardware at MIT-OZ

In Hardware in System 97.28, CADR 1.2, ZMail 51.9, MIT-Specific 21.0,
microcode 257, ZM MIT, on Lisp Machine Twenty-four:

middle button on mouse #37 sticks in the down position.
16-Dec-83 12:49:54-EST,385;000000000000
Mail-From: RZ created at 16-Dec-83 12:49:22
Date: Fri, 16 Dec 1983  12:49 EST
Message-ID: <RZ.11975981166.BABYL@MIT-OZ>
From: RZ@MIT-OZ
To:   bug-hardware@MIT-OZ
cc:   rz@MIT-MC
Subj: Cadr15's disk

Cadr15's disk is again going off line.  At the moment it doesn't seem to
be able to reboot the machine.  I will call John Holden this afternoon
to have him take a look at it.
16-Dec-83 14:45:20-EST,710;000000000000
Mail-From: AKR created at 16-Dec-83 14:44:58
Date: Fri, 16 Dec 1983  14:44 EST
Message-ID: <AKR.11976002212.BABYL@MIT-OZ>
From: AKR@MIT-OZ
To:   RZ@MIT-OZ
cc:   bug-hardware@MIT-OZ
Subject: cadr15
In-reply-to: Msg of 16 Dec 1983  12:49-EST from RZ


Looks like cadr15 has inherited cadr16's drive lossage since,
unless I am confused, it was cadr16 that kept going off-line 
this past summer until one of the boards finally broke and was 
replaced by John Holden.
Maybe someone should mention that to him.  I wont be here later
this afternoon.

Re cadr16: I stuck 4 good memory boards into it last saturday, and
it was up until someone powered it down and moved it out of the 
machine room.
16-Dec-83 16:54:30-EST,13395;000000000000
Received: from MIT-LISPM-31 by MIT-OZ via Chaosnet; 16 Dec 83 16:53-EST
Date: Friday, 16 December 1983, 16:55-EST
From: Michael Erdmann <ME at MIT-OZ>
Reply-to: BRD at MIT-OZ
To: BUG-HARDWARE at MIT-OZ
CC: BRD at MIT-OZ

sender: BRD@OZ
In HARDWARE in System 97.28, CADR 1.3, ZMail 51.9, MIT-Specific 21.0,
microcode 257, ZM MIT, on Lisp Machine Thirty-one:


Insert your description of the circumstances, and how often the problem occurs:

While debugging machine CADR-32, system 97.28 microcode 257. Either an
Add, Comparison, or Byte-Extraction instruction failed; it was in CONSF
in UC-STORAGE-ALLOCATION. It was looking at a region that was completely
full, but it didn't realize that it was. The JUMP-GREATER-OR-EQUAL
should've jumped but didn't. Don't know it it's arguments were correct
but we verified that the storage they looked at was correct.

-- BRD (Bruce Donald).

Machine being debugged is MIT-LISPM-32.
Bus-interface errors since last reset:
  Parity error in data from processor

Microcode halted via ILLOP from PAGE-IN-GET-MAP-BITS+2
Micro PC History (OPC's), oldest first:
   23210   (XRGN1 7)
   23211   (XRGN1 10)
   05735   CDR-IS-NIL
   05736   (XFALSE 1)
   23063   (PAGE-IN-GET-MAP-BITS 2)
   23064   (PAGE-IN-GET-MAP-BITS 3)
   00023   ILLOP
   00024   XWIPM
Backtrace of microcode subroutine stack:
    6  023032   (SWAPIN1-GO 1)
    5  022070   (PGF-R 3)
    4  004417   (CONSF2 1)
    3  004357   (LCONS2 5)
    2  004236   (QCONS 2)
    1  000511   M-T-TO-STACK
    0  040164   QMLP

Current stack group is: <Stack Group MAIN-STACK-GROUP>
Current process is: #<DTP-INSTANCE 7002137>"Initial Process"
Complete backtrace follows: (type Space to stop)

207263 #<DTP-FEF-POINTER FILE-SYSTEM:READ-FILE-PROPERTY-LIST-STRING 2075744>[254] "UC;" "OPEN" #<DTP-INSTANCE 640252>
207226 #<DTP-FEF-POINTER FILE-SYSTEM:MULTIPLE-PLISTS-CHAOS 2076076>[266] #<DTP-INSTANCE 7056147> (#<DTP-INSTANCE 640252> #<DTP-INSTANCE 354717> #<DTP-INSTANCE 640272> #<DTP-INSTANCE 354736> #<DTP-INSTANCE 640312> #<DTP-INSTANCE 354755> #<DTP-INSTANCE 640332> #<DTP-INSTANCE 354774> #<DTP-INSTANCE 640352> #<DTP-INSTANCE 355013>) GLOBAL:NIL
207217 #<DTP-FEF-POINTER (METHOD FILE-SYSTEM:CHAOS-PATHNAME MULTIPLE-FILE-PLISTS) 2103520>[30] MULTIPLE-FILE-PLISTS (#<DTP-INSTANCE 640252> #<DTP-INSTANCE 354717> #<DTP-INSTANCE 640272> #<DTP-INSTANCE 354736> #<DTP-INSTANCE 640312> #<DTP-INSTANCE 354755> #<DTP-INSTANCE 640332> #<DTP-INSTANCE 354774> #<DTP-INSTANCE 640352> #<DTP-INSTANCE 355013>) GLOBAL:NIL

BOUND-LOC-POINTER-NOT-LOCATIVE 207201 #<DTP-FEF-POINTER FILE-SYSTEM:MULTIPLE-FILE-PLISTS 4556017>[121] (#<DTP-INSTANCE 640252> #<DTP-INSTANCE 354717> #<DTP-INSTANCE 640272> #<DTP-INSTANCE 354736> #<DTP-INSTANCE 640312> #<DTP-INSTANCE 354755> #<DTP-INSTANCE 640332> #<DTP-INSTANCE 354774> #<DTP-INSTANCE 640352> #<DTP-INSTANCE 355013>)

BOUND-LOC-POINTER-NOT-LOCATIVE 207167 #<DTP-FEF-POINTER SYSTEM-INTERNALS:SYSTEM-GET-FILE-PROPERTY-LIST 2117630>[102] #<DTP-INSTANCE 354717>

BOUND-LOC-POINTER-NOT-LOCATIVE 207160 #<DTP-FEF-POINTER SYSTEM-INTERNALS:SYSTEM-GET-CREATION-DATE 2117600>[34] #<DTP-INSTANCE 354717>

BOUND-LOC-POINTER-NOT-LOCATIVE 207152 #<DTP-FEF-POINTER SYSTEM-INTERNALS:FILE-NEWER-THAN-FILE-P 2117541>[22] #<DTP-INSTANCE 354717> #<DTP-INSTANCE 640252>

BOUND-LOC-POINTER-NOT-LOCATIVE 207137 #<DTP-FEF-POINTER SYSTEM-INTERNALS:QUEUE-FILES-AS-NEEDED 2115742>[75] ((GLOBAL:NIL GLOBAL:NIL (COMPILE ("Compile" "Compiling" "compiled") SYSTEM-INTERNALS:QC-FILE-1 ((GLOBAL:QUOTE LISP)) (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*)) CHANNELS #<SYSTEM-INTERNALS:SYSTEM "Channels" 15444236> SYSTEM-INTERNALS:FILE-NEWER-THAN-FILE-P (#<DTP-INSTANCE 640252>) #<DTP-INSTANCE 354717> #<DTP-INSTANCE 640252>) (GLOBAL:NIL GLOBAL:NIL (COMPILE ("Compile" "Compiling" "compiled") SYSTEM-INTERNALS:QC-FILE-1 ((GLOBAL:QUOTE LISP)) (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*)) CHANNELS #<SYSTEM-INTERNALS:SYSTEM "Channels" 15444236> SYSTEM-INTERNALS:FILE-NEWER-THAN-FILE-P (#<DTP-INSTANCE 640272>) #<DTP-INSTANCE 354736> #<DTP-INSTANCE 640272>) (GLOBAL:NIL GLOBAL:NIL (COMPILE ("Compile" "Compiling" "compiled") SYSTEM-INTERNALS:QC-FILE-1 ((GLOBAL:QUOTE LISP)) (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*)) CHANNELS #<SYSTEM-INTERNALS:SYSTEM "Channels" 15444236> SYSTEM-INTERNALS:FILE-NEWER-THAN-FILE-P (#<DTP-INSTANCE 640312>) #<DTP-INSTANCE 354755> #<DTP-INSTANCE 640312>) (GLOBAL:NIL GLOBAL:NIL (COMPILE ("Compile" "Compiling" "compiled") SYSTEM-INTERNALS:QC-FILE-1 ((GLOBAL:QUOTE LISP)) (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*)) CHANNELS #<SYSTEM-INTERNALS:SYSTEM "Channels" 15444236> SYSTEM-INTERNALS:FILE-NEWER-THAN-FILE-P (#<DTP-INSTANCE 640332>) #<DTP-INSTANCE 354774> #<DTP-INSTANCE 640332>) (GLOBAL:NIL GLOBAL:NIL (COMPILE ("Compile" "Compiling" "compiled") SYSTEM-INTERNALS:QC-FILE-1 ((GLOBAL:QUOTE LISP)) (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*)) CHANNELS #<SYSTEM-INTERNALS:SYSTEM "Channels" 15444236> SYSTEM-INTERNALS:FILE-NEWER-THAN-FILE-P (#<DTP-INSTANCE 640352>) #<DTP-INSTANCE 355013> #<DTP-INSTANCE 640352>))
207122 #<DTP-FEF-POINTER SYSTEM-INTERNALS:QUEUE-ONE-TRANSFORMATION 2115077>[122] #<SYSTEM-INTERNALS:TRANSFORMATION (COMPILE ("Compile" "Compiling" "compiled") SYSTEM-INTERNALS:QC-FILE-1 ((GLOBAL:QUOTE LISP)) (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*)) 15444743> GLOBAL:NIL
207104 #<DTP-FEF-POINTER SYSTEM-INTERNALS:PERFORM-TRANSFORMATIONS 2114202>[121] ((#<SYSTEM-INTERNALS:TRANSFORMATION (COMPILE ("Compile" "Compiling" "compiled") SYSTEM-INTERNALS:QC-FILE-1 ((GLOBAL:QUOTE LISP)) (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*)) 15444635> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (COMPILE ("Compile" "Compiling" "compiled") SYSTEM-INTERNALS:QC-FILE-1 ((GLOBAL:QUOTE LISP)) (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*)) 15444653> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (COMPILE ("Compile" "Compiling" "compiled") SYSTEM-INTERNALS:QC-FILE-1 ((GLOBAL:QUOTE LISP)) (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*)) 15444671> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (COMPILE ("Compile" "Compiling" "compiled") SYSTEM-INTERNALS:QC-FILE-1 ((GLOBAL:QUOTE LISP)) (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*)) 15444707> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (COMPILE ("Compile" "Compiling" "compiled") SYSTEM-INTERNALS:QC-FILE-1 ((GLOBAL:QUOTE LISP)) (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*)) 15444725> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (COMPILE ("Compile" "Compiling" "compiled") SYSTEM-INTERNALS:QC-FILE-1 ((GLOBAL:QUOTE LISP)) (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*)) 15444743> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (COMPILE ("Compile" "Compiling" "compiled") SYSTEM-INTERNALS:QC-FILE-1 ((GLOBAL:QUOTE LISP)) (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*)) 15444761> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (COMPILE ("Compile" "Compiling" "compiled") SYSTEM-INTERNALS:QC-FILE-1 ((GLOBAL:QUOTE LISP)) (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*)) 15444777> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (COMPILE ("Compile" "Compiling" "compiled") SYSTEM-INTERNALS:QC-FILE-1 ((GLOBAL:QUOTE LISP)) (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*)) 15445015> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (COMPILE ("Compile" "Compiling" "compiled") SYSTEM-INTERNALS:QC-FILE-1 ((GLOBAL:QUOTE LISP)) (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*)) 15445033> CHANNELS GLOBAL:NIL))
207066 #<DTP-FEF-POINTER SYSTEM-INTERNALS:PERFORM-TRANSFORMATIONS 2114202>[102] ((#<SYSTEM-INTERNALS:TRANSFORMATION (FASLOAD ("Load" "Loading" "loaded") SYSTEM-INTERNALS:FASLOAD-1 (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*) GLOBAL:NIL) 15444644> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (FASLOAD ("Load" "Loading" "loaded") SYSTEM-INTERNALS:FASLOAD-1 (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*) GLOBAL:NIL) 15444662> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (FASLOAD ("Load" "Loading" "loaded") SYSTEM-INTERNALS:FASLOAD-1 (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*) GLOBAL:NIL) 15444700> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (FASLOAD ("Load" "Loading" "loaded") SYSTEM-INTERNALS:FASLOAD-1 (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*) GLOBAL:NIL) 15444716> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (FASLOAD ("Load" "Loading" "loaded") SYSTEM-INTERNALS:FASLOAD-1 (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*) GLOBAL:NIL) 15444734> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (FASLOAD ("Load" "Loading" "loaded") SYSTEM-INTERNALS:FASLOAD-1 (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*) GLOBAL:NIL) 15444752> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (FASLOAD ("Load" "Loading" "loaded") SYSTEM-INTERNALS:FASLOAD-1 (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*) GLOBAL:NIL) 15444770> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (FASLOAD ("Load" "Loading" "loaded") SYSTEM-INTERNALS:FASLOAD-1 (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*) GLOBAL:NIL) 15445006> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (FASLOAD ("Load" "Loading" "loaded") SYSTEM-INTERNALS:FASLOAD-1 (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*) GLOBAL:NIL) 15445024> CHANNELS GLOBAL:NIL) (#<SYSTEM-INTERNALS:TRANSFORMATION (FASLOAD ("Load" "Loading" "loaded") SYSTEM-INTERNALS:FASLOAD-1 (SYSTEM-INTERNALS:*SYSTEM-DEFAULT-BINARY-FILE-TYPE*) GLOBAL:NIL) 15445042> CHANNELS GLOBAL:NIL))
207024 #<DTP-FEF-POINTER GLOBAL:MAKE-SYSTEM 2113772>[210] CHANNELS COMPILE DEFAULTED-BATCH NO-RELOAD-SYSTEM-DECLARATION
206777 #<DTP-FEF-POINTER SYSTEM-INTERNALS:*EVAL 4552375>[1247] (MAKE-SYSTEM (GLOBAL:QUOTE CHANNELS) (GLOBAL:QUOTE COMPILE) (GLOBAL:QUOTE DEFAULTED-BATCH) (GLOBAL:QUOTE NO-RELOAD-SYSTEM-DECLARATION))
206724 #<DTP-FEF-POINTER SYSTEM-INTERNALS:APPLY-LAMBDA 4553527>[1313] (GLOBAL:NAMED-LAMBDA SETUP-6 (GLOBAL:&OPTIONAL (LOAD-EDITOR-P (GLOBAL:QUOTE GLOBAL:T)) (LOAD-GMS-INTO-EDITOR-P GLOBAL:NIL)) (BATCH-WINDOW) (GRINDEF SETUP-6) (COND (LOAD-EDITOR-P (LOAD-6))) (COND (LOAD-GMS-INTO-EDITOR-P (NEW:LOAD-EDITOR))) (MAKE-SYSTEM (GLOBAL:QUOTE CHANNELS) (GLOBAL:QUOTE COMPILE) (GLOBAL:QUOTE DEFAULTED-BATCH) (GLOBAL:QUOTE NO-RELOAD-SYSTEM-DECLARATION)) (FASLOAD "oz:src:<brd.6dof>Fast") (MAKE-SYSTEM (GLOBAL:QUOTE NEW) (GLOBAL:QUOTE COMPILE) (GLOBAL:QUOTE DEFAULTED-BATCH) (GLOBAL:QUOTE NO-RELOAD-SYSTEM-DECLARATION)) (MAKE-SYSTEM (GLOBAL:QUOTE 6DOF) (GLOBAL:QUOTE COMPILE) (GLOBAL:QUOTE DEFAULTED-BATCH) (GLOBAL:QUOTE NO-RELOAD-SYSTEM-DECLARATION)) (SETUP-TERMINAL-E) (CHANNELS:INITIALIZE-VIEW GLOBAL:T) (SEND TV:INITIAL-LISP-LISTENER (GLOBAL:QUOTE SELECT))) (GLOBAL:NIL)
206717 (GLOBAL:NAMED-LAMBDA SETUP-6 (GLOBAL:&OPTIONAL (LOAD-EDITOR-P (GLOBAL:QUOTE GLOBAL:T)) (LOAD-GMS-INTO-EDITOR-P GLOBAL:NIL)) (BATCH-WINDOW) (GRINDEF SETUP-6) (COND (LOAD-EDITOR-P (LOAD-6))) (COND (LOAD-GMS-INTO-EDITOR-P (NEW:LOAD-EDITOR))) (MAKE-SYSTEM (GLOBAL:QUOTE CHANNELS) (GLOBAL:QUOTE COMPILE) (GLOBAL:QUOTE DEFAULTED-BATCH) (GLOBAL:QUOTE NO-RELOAD-SYSTEM-DECLARATION)) (FASLOAD "oz:src:<brd.6dof>Fast") (MAKE-SYSTEM (GLOBAL:QUOTE NEW) (GLOBAL:QUOTE COMPILE) (GLOBAL:QUOTE DEFAULTED-BATCH) (GLOBAL:QUOTE NO-RELOAD-SYSTEM-DECLARATION)) (MAKE-SYSTEM (GLOBAL:QUOTE 6DOF) (GLOBAL:QUOTE COMPILE) (GLOBAL:QUOTE DEFAULTED-BATCH) (GLOBAL:QUOTE NO-RELOAD-SYSTEM-DECLARATION)) (SETUP-TERMINAL-E) (CHANNELS:INITIALIZE-VIEW GLOBAL:T) (SEND TV:INITIAL-LISP-LISTENER (GLOBAL:QUOTE SELECT)))[76127] GLOBAL:NIL
206672 #<DTP-FEF-POINTER SYSTEM-INTERNALS:*EVAL 4552375>[565] (SETUP-6 GLOBAL:NIL)
206664 #<DTP-FEF-POINTER GLOBAL:PROGN 1604733>[35] ("MIT-ROBOT-1" (SETUP-6 GLOBAL:NIL))
206635 #<DTP-FEF-POINTER SYSTEM-INTERNALS:*EVAL 4552375>[1247] (PROGN "MIT-ROBOT-1" (SETUP-6 GLOBAL:NIL))
206606 #<DTP-FEF-POINTER GLOBAL:UNWIND-PROTECT 1644116>[42] (PROGN "MIT-ROBOT-1" (SETUP-6 GLOBAL:NIL)) ((TRY-TO-NOTIFY-LUSER "MIT-ROBOT-1"))
206557 #<DTP-FEF-POINTER SYSTEM-INTERNALS:*EVAL 4552375>[1247] (UNWIND-PROTECT (PROGN "MIT-ROBOT-1" (SETUP-6 GLOBAL:NIL)) (TRY-TO-NOTIFY-LUSER "MIT-ROBOT-1"))
206532 #<DTP-FEF-POINTER SYSTEM-INTERNALS:*EVAL 4552375>[636] (DO-WITH-NOTIFICATION "MIT-ROBOT-1" (SETUP-6 GLOBAL:NIL))
206524 #<DTP-FEF-POINTER GLOBAL:PROGN 1604733>[30] ((LOGIN (GLOBAL:QUOTE BRD)) (DO-WITH-NOTIFICATION "MIT-ROBOT-1" (SETUP-6 GLOBAL:NIL)) (MAPC (GLOBAL:FUNCTION ZWEI:LOAD-FILE-INTO-ZMACS) (GLOBAL:QUOTE ("SRC:<BRD.6DOF>DEBUGGING-ROUTINES.LISP" "SRC:<BRD.6DOF>BT.LISP"))))
206475 #<DTP-FEF-POINTER SYSTEM-INTERNALS:*EVAL 4552375>[1247] (PROGN (LOGIN (GLOBAL:QUOTE BRD)) (DO-WITH-NOTIFICATION "MIT-ROBOT-1" (SETUP-6 GLOBAL:NIL)) (MAPC (GLOBAL:FUNCTION ZWEI:LOAD-FILE-INTO-ZMACS) (GLOBAL:QUOTE ("SRC:<BRD.6DOF>DEBUGGING-ROUTINES.LISP" "SRC:<BRD.6DOF>BT.LISP"))))
206462 #<DTP-FEF-POINTER SYSTEM-INTERNALS:EVAL-ABORT-TRIVIAL-ERRORS 1573101>[44] (PROGN (LOGIN (GLOBAL:QUOTE BRD)) (DO-WITH-NOTIFICATION "MIT-ROBOT-1" (SETUP-6 GLOBAL:NIL)) (MAPC (GLOBAL:FUNCTION ZWEI:LOAD-FILE-INTO-ZMACS) (GLOBAL:QUOTE ("SRC:<BRD.6DOF>DEBUGGING-ROUTINES.LISP" "SRC:<BRD.6DOF>BT.LISP"))))
206414 #<DTP-FEF-POINTER SYSTEM-INTERNALS:LISP-TOP-LEVEL1 1572712>[256] #<DTP-INSTANCE 1000000>
206410 #<DTP-FEF-POINTER SYSTEM-INTERNALS:LISP-TOP-LEVEL 1571702>[35]

17-Dec-83 01:32:39-EST,1534;000000000000
Received: from MIT-LISPM-31 by MIT-OZ via Chaosnet; 17 Dec 83 01:32-EST
Date: Saturday, 17 December 1983, 01:34-EST
From: John Canny <JfC at MIT-OZ>
To: BUG-Hardware at MIT-OZ

In Hardware in System 97.28, CADR 1.0, ZMail 51.9, MIT-Specific 21.0,
microcode 257, ZM MIT, on Lisp Machine Thirty-one:

This machine seems to have a broken ALU. It has been in this 
condition for many months, and the problem show up in a variety
of ways. It is intermittent, but the probability of failure in
some cases is better than 50%. An example is

(setq a1 43768595357124346590207376.)
43768595357124346590207376.

(setq a2 26344128235843018797152384187812644185856.)
26344128235843018797152384187812644185856.

(* a1 a2)
1153045488790807156024020502483944696849152661357318354731726073856.

(* a1 a2)
1153045488790807156024020502484110850348625775841431330614261116928.

(- * **)
166153499473114484112975882535043072.

(setq ibase 8 base 8) 
10

**
1000000000000000000000000000000000000000

(haulong *)
166


The first of the two answers, by the way, is the correct one.  
They each occur with about equal frequency, and there are many other
pairs of bignums that have a variable product. I dont think the 
problem is confined to arithmetic, but this is the only example
I have which is reproduceable. 

This problem is serious because a lot of people are using this machine 
and getting strange or inconsistent results, or worse still, results 
that they assume are correct which are not.

- John
19-Dec-83 14:19:37-EST,247;000000000000
Mail-From: PGS created at 19-Dec-83 14:19:18
Date: Mon, 19 Dec 1983  14:19 EST
Message-ID: <PGS.11976783971.BABYL@MIT-OZ>
From: PGS@MIT-OZ
To:   bug-hardware@MIT-OZ
Subject:santa

We may have our first ten 256K memory boards by Christmas.
19-Dec-83 19:12:35-EST,332;000000000000
Received: from MIT-LISPM-1 by MIT-OZ via Chaosnet; 19 Dec 83 19:11-EST
Date: Monday, 19 December 1983, 19:12-EST
From: Robert P. Krajewski <RpK at MIT-OZ>
Subject: Cadr27 seems to be dead
To: BUG-Hardware at MIT-OZ

It was very unreliable before it crashed, and now it does not be either
via the keyboard or the red button.
20-Dec-83 17:55:24-EST,514;000000000000
Mail-From: DMS created at 20-Dec-83 17:54:56
Date: 20 Dec 1983  17:54 EST (Tue)
Message-ID: <DMS.11977085364.BABYL@MIT-OZ>
From: David Siegel <DMS@MIT-OZ>
Subject: NE43-7A-HUB is flacky
To:   Bug-Hardware@MIT-OZ

The NE43-7A terminal consentrator is having some trouble now and then.
The DC power and run LEDs go off, and MINITS crashes.  Rebooting 7A
doesn't help... you have to cycle the power off and on to get the
power LED to go back on.  This problem comes up around once a day.

Thanks
	-Dave
22-Dec-83 06:45:22-EST,217;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 22 Dec 83 06:45-EST
Date: 22 December 1983 06:45 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC


Something is wrong with the Ethernet.
27-Dec-83 09:59:54-EST,1802;000000000000
Received: from MIT-LISPM-30 by MIT-OZ via Chaosnet; 27 Dec 83 09:59-EST
Date: Tuesday, 27 December 1983, 10:02-EST
From: Patrick G. Sobalvarro <pgs at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in Bad Inconsistently updated System 98.16, CADR 3.3,
Experimental ZMail 53.5, MIT-Specific 22.0, microcode 305, ZM MIT,
on Lisp Machine Thirty:

CADR-31 wedges every time it tries to disk-save.  This makes it hard to update
the software on it.  I can't really tell whether the internal parity error
means that the disk has a bad spot on it, or that the drive loses when it tries
to write in burst mode, or what.

Machine being debugged is MIT-LISPM-31.
Disk error: Fault  Transfer-Aborted
  disk address: UNIT 0 CYLINDER 1007 HEAD 10 SECTOR 10 
  last memory address touched by disk = 41020
Contents of disk error log in debugee's main memory 600-640:

Command 11 (Write) 
CCW-list pointer 40000 (low 16 bits)
Disk address: unit 0, cylinder 1007, head 10, block 10 (0 519 8 8 decimal)
Memory address: 41020 (type bits 0)
Status: 1040020111  Internal-parity  Transfer-Aborted (or wr. ovr.)  Fault  Interrupt  Idle

Microcode halted via ILLOP from FATAL-DISK-ERROR
Micro PC History (OPC's), oldest first:
   25151   (LOG-DISK-ERROR 16)
   25067   (DISK-COMPLETION-ERROR 2)
   25070   (DISK-COMPLETION-ERROR 3)
   25071   (DISK-COMPLETION-ERROR 4)
   25131   FATAL-DISK-ERROR
   25132   (FATAL-DISK-ERROR 1)
   00023   ILLOP
   00024   XWIPM
Backtrace of microcode subroutine stack:
    5  027601   (COLD-AWAIT-DISK 2)
    4  027564   (DISK-COPY-PART-3 10)
    3  026627   DISK-SR-2
    2  026602   (DISK-SAVE-REGIONWISE 1)
    1  000442   M-T-TO-STACK
    0  040164   QMLP

>>ERROR: NOTHING-TO-SWAP-OUT QF-FINDCORE
[Sorry, error while trying to print that.]
28-Dec-83 14:38:00-EST,1694;000000000000
Received: from MIT-LISPM-32 by MIT-OZ via Chaosnet; 28 Dec 83 14:37-EST
Date: Wednesday, 28 December 1983, 14:38-EST
From: Christof Koch <koch at MIT-OZ>
Reply-to: KOCH at MIT-OZ, BRD at MIT-OZ
To: BUG-HARDWARE at MIT-OZ, RMS at MIT-OZ
CC: BRD at MIT-OZ, koch at MIT-OZ, ME at MIT-OZ

In HARDWARE in MIT-Specific 19.5, System 94.41, ZMail 50.17,
microcode 239, on Lisp Machine Thirty-two:

Insert your description of the circumstances, and how often the problem occurs:

While doing a lot of COMPLEX number crunching this happens consistently
and (it appears) on different machines (cadrs 23, 32, 31 and 30). I will try
to reproduce on other machines and send in bug reports. It invariably
crashes after 1/2 to 4 hours ; and have had same crash occur at least
20 times. Machine starts with same intial state and crashes some random
time later.

--  Bruce and Christof

Machine being debugged is MIT-LISPM-30.
Microcode halted via ILLOP from GET-MAP-BITS+12
Micro PC History (OPC's), oldest first:
   23210   (XRGN1 7)
   23211   (XRGN1 10)
   05735   CDR-IS-NIL
   05736   (XFALSE 1)
   22126   (GET-MAP-BITS 12)
   22127   (GET-MAP-BITS 13)
   00023   ILLOP
   00024   XWIPM
Backtrace of microcode subroutine stack:
    5  017024   (EXTRA-PDL-TRAP-1 1)
    4  017063   (EXTRA-PDL-TRAP-5 2)
    3  023340   P-B-MR0
    2  024670   (SGLV1 1)
    1  022057   (SBSER 14)
    0  040164   QMLP
Microcode state flags: switching stack groups

Current stack group is: <Stack Group MAIN-STACK-GROUP>
Current process is: #<DTP-INSTANCE 26242137>"Initial Process"
Complete backtrace follows: (type Space to stop)

210625 GLOBAL:NIL[0]
210462 GLOBAL:NIL[0]

28-Dec-83 22:06:22-EST,570;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 28 Dec 83 22:06-EST
Date: 28 December 1983 22:08 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  [TIM: Dead vt52 and vt125 in NE43-314]
To: BUG-HARDWARE @ MIT-MC

Date: 27 December 1983 15:04 EST
From: Tim McNerney <TIM at MIT-ML>
To:   BUG-VT52 at MIT-ML
Re:   Dead vt52 and vt125 in NE43-314

Both of these terminals are in GJC's corner of the room
(best characterized by the mess).

What is the correct procedure for dealing with these
problems?  Who should I contact about the vt125?

		--Tim McNerney
30-Dec-83 01:26:50-EST,362;000000000000
Mail-From: RMS created at 30-Dec-83 01:26:42
Date: Fri 30 Dec 83 01:26:42-EST
From: RMS@MIT-OZ
To: bug-hardware@MIT-OZ

CADR 1 got a c memory parity error.
The address was in the vicinity of 23104.
So many bits in that word were different from
the value I saw after rebooting that it perplexes me.
I am sure it was the same microcode version.
-------
 2-Jan-84 15:59:44-EST,282;000000000000
Mail-From: SAZ created at  2-Jan-84 15:59:26
Date: Mon 2 Jan 84 15:59-EST
From: David M. J. Saslav <SAZ@MIT-OZ>
Subject: Cadr-4
To: bug-hardware@MIT-OZ


Even after we power-cycled the disk, it wouldn't boot.
Could someone take a look at it?  

Dave, for the Music Group
 3-Jan-84 04:07:15-EST,731;000000000000
Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 3 Jan 84 04:06-EST
Date: Tuesday, 3 January 1984, 04:07-EST
From: Richard M. Stallman <rms at MIT-OZ>
To: BUG-Hardware at MIT-OZ

In Hardware in Don't-dump-a-band! Inconsistent (unreleased patches loaded) System 98.22,
CADR 3.4, ZMail 53.5, MIT-Specific 22.0, microcode 306, ZM MIT,
on Lisp Machine Eighteen:

CADR1 got a parity error in board 1, bank 2 while writing to the disk.
After this, warm booting died with a fatal disk error, cyl 9 head 6 block 9.
Cold booted and got another parity error writing to disk, again it board 1 bank 2,
at address 300552 which is not the same address that the first one was at.
I have no evidence as to which bits were losing.
 3-Jan-84 04:16:58-EST,243;000000000000
Mail-From: RMS created at  3-Jan-84 04:16:49
Date: Tue 3 Jan 84 04:16:49-EST
From: RMS@MIT-OZ
To: bug-hardware@MIT-OZ

CADR 1 got a parity error in board 1 bank 2 a few days ago too.
I couldn't determine which bit then either.
-------
 3-Jan-84 07:02:19-EST,1233;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 3 Jan 84 07:02-EST
Date: 3 January 1984 07:02 EST
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: OZ tape drive and funny smell
To: BUG-HARDWARE @ MIT-MC, NINTH-FLOOR @ MIT-MC

1) the black plastic of the MTA1 door has broken. the drive is usable
but caution must be observed. i called in DEC, they said they would
come in Tues. morning to look at it.

perhaps more importantly

2) there's a funny smell in the air in places. like a burned out
ballast in a fluorescent light. it's very strong in the ninth-floor
elevator lobby and the west-side hall (outside my office). but i was
on the seventh floor about 6:30am and noticed it there too. i poked
around the machine area up here but the smell was hardly noticeable
there, certainly didn't seem to be emanating from anything in
particular.  also, and perhaps associated, my office is cold (radiator
is blowing out unheated air) but over by MC it's warm. in other words,
maybe something is fried on the tenth floor.  of course, the smell and
the uneven heating/cooling may have separate causes (my office has
been cold all night, and i only noticed the smell in the past hour),
but it all should be looked into.
 3-Jan-84 23:15:02-EST,606;000000000000
Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 3 Jan 84 23:14-EST
Date: Tuesday, 3 January 1984, 23:06-EST
From: Richard M. Stallman <RMS at MIT-OZ>
To: bug-hardware at MIT-OZ

CADR 18 halted with a "micro stack parity error".
The micro stack pointer and the contents of the stack
all looked correct.
I tried proceeding and it halted the same way again.
I tried depositing the current stack pointer value
back into the stack pointer and then proceeded.  It ran.
This suggests that the parity error was in the micro stack pointer register.

Such a problem had happened to me once before.
 3-Jan-84 23:16:33-EST,363;000000000000
Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 3 Jan 84 23:16-EST
Date: Tuesday, 3 January 1984, 23:07-EST
From: Richard M. Stallman <RMS at MIT-OZ>
To: bug-hardware at MIT-OZ

CADR 27 halts something like once a day.  It is a hassle to debug
that machine so I haven't.  However, I have noticed that
the system menu has been on the screen each time.
 4-Jan-84 14:54:10-EST,452;000000000000
Mail-From: KOCH created at  4-Jan-84 14:51:51
Date: Wed 4 Jan 84 14:51:50-EST
From: KOCH@MIT-OZ
Subject: CADR-23
To: Bug-hardware@MIT-OZ

There seems to be a hardware bug in CADR-23 (the terminal is situated
just in fromt of 352). I am uinable to cold-boot the machine. Neither
from the keyboard, nor from the hardware. Even if I power the disk down and
up again, nothing seems to happen.
                                Christof

-------
 6-Jan-84 20:43:10-EST,292;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 6 Jan 84 20:41-EST
Date: Friday, 6 January 1984, 03:56-EST
From: RpK at MIT-OZ
Sender: LMFile at MIT-OZ
Subject: LM1
To: Bug-Hardware at MIT-OZ

Will someone please look at it ?  It probably has disk problems (will
not boot).

``Bob''
 8-Jan-84 16:53:41-EST,1177;000000000000
Mail-From: KMP created at  8-Jan-84 16:52:17
Date: Sun 8 Jan 84 16:52-EST
From: Kent M Pitman <KMP@MIT-OZ>
Subject: Avatar crashed (into?)
To: pa-cadr-users@MIT-OZ
CC: bug-hardware@MIT-OZ

Avatar died. I went upstairs and found the piece of clear acrylic that
is supposed to guard its front side only attached at one point and 
dangling at an odd angle. AKR looked it over and found a huge number
of bent pins, at least one of which was touching a ground it shouldn't
have been touching. Probably someone bumped or fell into the machine
causing the damage. If the cover had been securely in place, I'm not
convinced this would have happened, so remember if you open it to secure
it carefully. In any case, during straightening the bent pins, two broke
(one at a time of course). After patching around the first broken one, 
AKR and I decided it wasn't worth doing again on the second one (the
patch procedure is painful and messy) so we're leaving the machine down
until he or TC get a chance to fix it correctly -- probably tomorrow.

The 3600 version of the KBE is very recent (dumped yesterday) so should
suffice for any PA work in the meantime.
-kmp
10-Jan-84 11:25:48-EST,323;000000000000
Mail-From: KOCH created at 10-Jan-84 11:24:38
Date: Tue 10 Jan 84 11:24:37-EST
From: KOCH@MIT-OZ
Subject: CADR-23
To: BUG-hardware@MIT-OZ

CADR-23 seems to be broken again. It constantly stalls and requires
rebooting. Especially when trying to read a file from OZ
                              Christof

-------
10-Jan-84 14:19:32-EST,365;000000000000
Received: from MIT-LISPM-27 by MIT-OZ via Chaosnet; 10 Jan 84 14:17-EST
Date: Tuesday, 10 January 1984, 14:18-EST
From: The AI File Server <LMFile at MIT-OZ>
To: BUG-Hardware at MIT-OZ

In Hardware in System 97.28, microcode 257

Cadr-23 dies consistently while booting with D-MEM parity errors,
and D-MEM scan showed that two addresses were bad.
 
 JFC
13-Jan-84 11:14:03-EST,474;000000000000
Received: from MIT-ML by MIT-OZ via Chaosnet; 13 Jan 84 11:13-EST
Date: Friday, 13 January 1984, 11:15-EST
From: Gordon S. Linoff <GORDON at MIT-ML>
Subject: mailing list
To: BUG-hardware at ai, symbolics-hardware at ai,
    3600-hardware at ai at OZ

In hardware @ai, symbolics-hardware @ai,
3600-hardware @ai in Release 4.5, site configuration 62, on PI Project:

I don't know how I was put on these mailing lists, but
I would appreciate it if I were removed.
18-Jan-84 16:23:17-EST,790;000000000000
Mail-From: JMH created at 18-Jan-84 16:22:50
Date: Wed 18 Jan 84 16:22-EST
From: brd
Sender: John M. Hollerbach <JMH@MIT-OZ>
Subject: Line problems?
To: oaf@MIT-OZ, bug-hardware@MIT-OZ
CC: me@MIT-OZ, brd@MIT-OZ, jmh@MIT-OZ, karen@MIT-OZ, marty@MIT-OZ, terzop@MIT-OZ,
    philip@MIT-OZ

Hi. We just moved into 755 and think we're having line problems. 
There are two lines in the office, a plugbox and a line hanging from the
ceiling; neither works. 757 (Demetri and Philippe) has a plugbox that does not
work. 791 (JMH) also has a plugbox that does not work.

Should these lines be working? (i.e., have they never been installed, or
are they broken?) Before TLP left, he conveyed the impression that they
all should work. Is there some trick we should know about?

Bruce
18-Jan-84 17:17:23-EST,958;000000000000
Mail-From: PGS created at 18-Jan-84 17:16:41
Date: Wed, 18 Jan 1984  17:16 EST
Message-ID: <PGS.11984680582.BABYL@MIT-OZ>
From: PGS@MIT-OZ
To:   brd@MIT-OZ
Cc:   bug-hardware@MIT-OZ, jmh@MIT-OZ, karen@MIT-OZ, marty@MIT-OZ, me@MIT-OZ,
      oaf@MIT-OZ, philip@MIT-OZ, terzop@MIT-OZ
Subject: Line problems?
In-reply-to: Msg of 18 Jan 1984  16:22-EST from brd

    Date: Wednesday, 18 January 1984  16:22-EST
    From: brd
    Sender: John M. Hollerbach <JMH>
    To:   oaf, bug-hardware
    cc:   me, brd, jmh, karen, marty, terzop, philip
    Re:   Line problems?

    Hi. We just moved into 755 and think we're having line problems. 
    There are two lines in the office, a plugbox and a line hanging from the
    ceiling; neither works. 757 (Demetri and Philippe) has a plugbox that
    does not work. 791 (JMH) also has a plugbox that does not work.

I'll work on this stuff as soon as I get a chance.  That means in about a
week.
18-Jan-84 17:39:01-EST,516;000000000000
Mail-From: BRD created at 18-Jan-84 17:37:31
Date: 18 Jan 1984  17:37 EST (Wed)
Message-ID: <BRD.11984684373.BABYL@MIT-OZ>
From: "Bruce R. Donald" <BRD@MIT-OZ>
To:   PGS@MIT-OZ
Cc:   bug-hardware@MIT-OZ
Subject: Line problems?
In-reply-to: Msg of 18 Jan 1984  17:16-EST from PGS


Not a line problem. The problem appears to be a combination of not
enough free concentrator slots and what might be a bad concentrator
slot. We found a free one by swapping out someone who'd gone home.
The line seems ok.
19-Jan-84 12:25:49-EST,821;000000000000
Mail-From: PGS created at 19-Jan-84 12:25:01
Date: Thu, 19 Jan 1984  12:24 EST
Message-ID: <PGS.11984889624.BABYL@MIT-OZ>
From: PGS@MIT-OZ
To:   brd@MIT-OZ, bug-hardware@MIT-OZ, jmh@MIT-OZ, karen@MIT-OZ, marty@MIT-OZ,
      me@MIT-OZ, oaf@MIT-OZ, philip@MIT-OZ, terzop@MIT-OZ
Subject: concentrator problems
In-reply-to: Msg of 18 Jan 1984  17:16-EST from PGS

The reason the new 7th floor offices don't have terminal lines isn't because
the lines aren't there, and it isn't because the serial cards aren't there
(yow!).  It's because a piece of technician work hasn't been done on the
concentrator rack to let us plug in another 16 lines.  It's not a whole lot
of work, but TC is in Hawaii, so it'll take some extra time for the
technician allocation to happen, because I have to find out who to allocate.
19-Jan-84 17:21:34-EST,1036;000000000000
Mail-From: PGS created at 19-Jan-84 17:12:38
Date: Thu, 19 Jan 1984  17:12 EST
Message-ID: <PGS.11984941984.BABYL@MIT-OZ>
From: PGS@MIT-OZ
To:   bug-hardware@MIT-OZ, brd@MIT-OZ, jmh@MIT-OZ, karen@MIT-OZ, marty@MIT-OZ,
      me@MIT-OZ, oaf@MIT-OZ, philip@MIT-OZ, terzop@MIT-OZ
Subject: concentrator problems
In-reply-to: Msg of 18 Jan 1984  17:16-EST from PGS

I added a new frame to the rack and reconfigured NE43-7A so there are now 16
more lines on it.  That means that the concentrator end now has all the lines
plugged into it.  Whether or not they reach the offices isn't my business,
but it looks to me like many do not.

If you should find that there is a bad port on the concentrator, please let
BUG-HARDWARE know.  Don't just go pulling lines out of one port and plugging
them into others (unless the others are already empty).  If your terminal
type is wrong, log in on MC and read your ttyloc (do a :finger to get it),
and send me a message with the ttyloc and the correct terminal type, and I'll
fix it.
22-Jan-84 13:43:42-EST,342;000000000000
Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 22 Jan 84 13:43-EST
Date: Sunday, 22 January 1984, 13:44-EST
From: Robert P. Krajewski <RpK at MIT-OZ>
Subject: Cadr 27 down again
To: BUG-CADR at MIT-OZ
FCC: OZ:PS:<RPK.MAIL>CC.XMAIL
Message-ID: <[MIT-LISPM-18].1/22/84 13:44:08.RpK>

PC 531, leftmost decimal point on.

``Bob''
23-Jan-84 09:45:08-EST,295;000000000000
Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 23 Jan 84 09:44-EST
Date: Monday, 23 January 1984, 09:45-EST
From: Richard Mlynarik <Mly at MIT-OZ>
Subject: cadr27 will not boot.
To: bug-hardware at MIT-OZ
Message-ID: <[MIT-LISPM-18].23-Jan-84 09:45:33.Mly>

That's all I can say...
23-Jan-84 18:13:27-EST,533;000000000000
Mail-From: OAF created at 23-Jan-84 18:12:37
Date: Mon, 23 Jan 1984  18:12 EST
Message-ID: <OAF.11986001480.BABYL@MIT-OZ>
From: OAF@MIT-OZ
To:   bug-hardware@MIT-OZ


There is a frotzed port on NE43-7A-HUB:  Top left corner of the lower
construct.  I have put a piece of yaller paper over it.  Of course, 
the right thing to do is reboot minits one dark and stormy night, 
then see whether that port cometh back.  Of course.

Have fun, y'all.

Oded

PS:  Who the hell is ON this list?  Am I talking to myself again?
23-Jan-84 18:28:58-EST,2140;000000000000
Received: from MIT-LISPM-2 by MIT-OZ via Chaosnet; 23 Jan 84 18:27-EST
Date: Monday, 23 January 1984, 18:28-EST
From: Richard Mlynarik <kab at MIT-OZ>
Subject: cadr 27 dead
To: bug-hardware at MIT-OZ

Won't boot in any form
(cc:dcheck) produces the following:

CONTROLLER TYPE IS 3 (Unmodified Trident)
0-27
Some bits in DA register won't clear
 Now entering scope loop, writing 0 into 17377776 and reading it back.
000000000000000000000000000, 111111111111111111111111111, 222222222222222222222222222, 333333333333333333333333333, 444444444444444444444444444, 555555555555555555555555555, 666666666666666666666666666, 777777777777777777777777777, 888888888888888888888888888, 999999999999999999999999999, 101010101010101010101010101010101010101010101010101010, 111111111111111111111111111111111111111111111111111111, 121212121212121212121212121212121212121212121212121212, 131313131313131313131313131313131313131313131313131313, 141414141414141414141414141414141414141414141414141414, 151515151515151515151515151515151515151515151515151515, 161616161616161616161616161616161616161616161616161616, 171717171717171717171717171717171717171717171717171717, 181818181818181818181818181818181818181818181818181818, 191919191919191919191919191919191919191919191919191919, 202020202020202020202020202020202020202020202020202020, 212121212121212121212121212121212121212121212121212121, 222222222222222222222222222222222222222222222222222222, 232323232323232323232323232323232323232323232323232323, 242424242424242424242424242424242424242424242424242424, 252525252525252525252525252525252525252525252525252525, 262626262626262626262626262626262626262626262626262626, 272727272727272727272727272727272727272727272727272727
Testing first spurious-1 bit in DA register:
 Now entering scope loop, writing 0 and 1377777777 into 17377776 and reading it back.
;Back to top level in Lisp Listener 1.

(cc:dcheck)					;different this time.
CONTROLLER TYPE IS 3 (Unmodified Trident)
0-27
Some bits in DA register won't clear
 Now entering scope loop, writing 0 into 17377776 and reading it back.
;Back to top level in Lisp Listener 1.
23-Jan-84 19:26:43-EST,206;000000000000
Mail-From: RMS created at 23-Jan-84 19:26:18
Date: Mon 23 Jan 84 19:26:17-EST
From: RMS@MIT-OZ
Subject: CADR 1
To: bug-hardware@MIT-OZ

Cadr 1 gets errors in booting.  Probably disk errors.
-------
23-Jan-84 19:55:30-EST,1016;000000000000
Mail-From: PGS created at 23-Jan-84 19:52:57
Date: Mon, 23 Jan 1984  19:52 EST
Message-ID: <PGS.11986019749.BABYL@MIT-OZ>
From: PGS@MIT-OZ
To:   OAF@MIT-OZ
Cc:   bug-hardware@MIT-OZ
In-reply-to: Msg of 23 Jan 1984  18:12-EST from OAF

    Date: Monday, 23 January 1984  18:12-EST
    From: OAF
    To:   bug-hardware

    There is a frotzed port on NE43-7A-HUB:  Top left corner of the lower
    construct.  I have put a piece of yaller paper over it.  Of course, 
    the right thing to do is reboot minits one dark and stormy night, 
    then see whether that port cometh back.  Of course.

    PS:  Who the hell is ON this list?  Am I talking to myself again?

I'm on this list, and I did want to know.  That may be the board that you
gave me back after swapping boards on 9A for Buckley.  Was it the leftmost
port that occasionally screwed up on that board?  If so, I suggest we just
swap it with another board that I have and send that board back to TM and
tell them to give us another.
24-Jan-84 20:16:39-EST,745;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 24 Jan 84 20:16-EST
Date: Tuesday, 24 January 1984, 20:14-EST
From: Andrew A. Berlin <AAB at MIT-PYGMALION>
Subject: Cadr 2 dead
To: bug-hardware at oz
Cc: aab at oz


Cadr 2 does not respond to cold booting, either from the keyboard or
from the little button on the machine.

The grim scenario was as follows:
Someone had supdup'ed to mc.  I broke the connection and
attempted to booted the machine via the keyboard.  The clock stopped
and the cursor stopped blinking, but the two little lines
never appeared on the bottom of the screen.  The machine has
not been heard from since.

It appears (from the herald) that the microcode and band WERE 
compatible.

Help....

Andy
26-Jan-84 07:09:32-EST,637;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 26 Jan 84 07:09-EST
Date: 26 January 1984 07:08 EST
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: very bad location
To: BUG-HARDWARE @ MIT-MC

there's a new l-machine (that means 3600) in the lispm corral.
unfortunately, its console is on the floor in front of it. this is a very
bad place, because it's smack in the way of the path to the oz tape drives
from the cut in the railing next to the door. i use this path constantly.
would someone please move the console to a safer location before i trip
over it? (having it on the floor at all is marginal no matter where.) thx.
26-Jan-84 10:33:11-EST,500;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 26 Jan 84 10:33-EST
Received: from MIT-LENNON by MIT-OZ via Chaosnet; 26 Jan 84 10:32-EST
Date: Thursday, 26 January 1984, 10:33-EST
From: Daniel Huttenlocher <dph%MIT-OZ@MIT-MC.ARPA>
Subject: very bad location
To: CENT at MIT-MC, BUG-HARDWARE at MIT-MC
In-reply-to: The message of 26 Jan 84 07:08-EST from Pandora B. Berman <CENT at MIT-DM>

Move the console over a bit then.  It's just there until a long line
gets run down to the 8th floor.
26-Jan-84 17:19:37-EST,502;000000000000
Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 26 Jan 84 17:11-EST
Date: Thursday, 26 January 1984, 17:13-EST
From: Robert P. Krajewski <RpK at MIT-OZ>
Subject: LM27's tape drive
To: Bug-Cadr at MIT-OZ
Message-ID: <[MIT-LISPM-18].1/26/84 17:13:54.RpK>

The machine will not boot with the tape drive connected.  NGL's voltmeter says
that the (big) 5V power supply at the bottom of the rack is in actuality only
putting out 1V.  It should be checked out, and probably replaced.

``Bob''
27-Jan-84 18:55:38-EST,345;000000000000
Mail-From: DAVIS created at 27-Jan-84 18:55:24
Date: Fri 27 Jan 84 18:55-EST
From: Randy Davis <DAVIS@MIT-OZ>
Subject: 8A HUB
To: bug-hardware@MIT-OZ


The connection frmo 819 to the 8A HUB concentrator seems to have
gone away.  Nothing seems amiss in my office so I suspect a
plug pulled somewhere else.  Can someone check?

thanks
30-Jan-84 13:58:54-EST,402;000000000000
Received: from MIT-XX by MIT-OZ via Chaosnet; 30 Jan 84 13:57-EST
Date: Monday, 30 January 1984, 13:57-EST
From: Jeffrey N Eisen <JNE at MIT-LISPM-15>
Subject: Broken Mouse
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in Release 5.0 [Beta Test rev 4], Experimental Schema 7.0,
imperial purple, on Lisp Machine Apiary-8 (3600):

Left and Middle mouse buttons dead (right works) on mouse ser #05949
30-Jan-84 14:07:36-EST,475;000000000000
Received: from MIT-XX by MIT-OZ via Chaosnet; 30 Jan 84 14:07-EST
Date: Monday, 30 January 1984, 14:07-EST
From: Jeffrey N Eisen <JNE at MIT-LISPM-15>
Subject: Broken mouse
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in Release 5.0 [Beta Test rev 4], Experimental Schema 7.1,
imperial purple, on Lisp Machine Apiary-8 (3600):

Regarding last message of broken mouse #05949

Just realized it isn't just the mouse.
Same problem even if mouse is switched with another.
 9-Feb-84 19:29:11-EST,517;000000000001
Received: from SCRC-QUABBIN by MIT-OZ via Chaosnet; 9 Feb 84 19:28-EST
Received: from SCRC-EUPHRATES by SCRC-QUABBIN with CHAOS; Thu 9-Feb-84 19:29:06-EST
Date: Thursday, 9 February 1984, 19:28-EST
From: David A. Moon <Moon at SCRC-TENEX>
Subject: wrong terminal location
To: bug-hardware at MIT-OZ

The terminal location for the MINITS line in Alan Bawden's office is incorrect.
The hpone number given is Jim Miller's office I think.  If this isn't the right mailing
list, could you forward this?  Thanks.
10-Feb-84 12:54:58-EST,495;000000000000
Mail-From: M created at 10-Feb-84 12:54:38
Date: Fri 10 Feb 84 12:54:38-EST
From: James V. Mahoney <M@MIT-OZ>
Subject: Flakey Terminal Concentrator
To: bug-hardware@MIT-OZ

THe 7a concentrator is acting up.  My line, in room 768 does strange 
things, now and then.  It prints the minits prompt line over and over
for example.

Anyway, the terminal is totally dead now.  Rebooting the thing does
temp. fix problem, but I'm getting sick of rebooting it all the time.

-Dave
-------
10-Feb-84 18:07:25-EST,283;000000000000
Mail-From: DMS created at 10-Feb-84 18:07:15
Date: 10 Feb 1984  18:07 EST (Fri)
Message-ID: <DMS.11990719097.BABYL@MIT-OZ>
From: David Siegel <DMS@MIT-OZ>
Subject: ne43-7a-hub
To:   bug-hardware@MIT-OZ

NE43-7A just died again.  I'm fairly sure it has brain damage.

-Dave
13-Feb-84 18:11:25-EST,294;000000000000
Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 13 Feb 84 18:10-EST
Date: Monday, 13 February 1984, 18:12-EST
From: Richard Mlynarik <MLY at MIT-OZ>
To: bug-hardware at MIT-OZ

Cadr-18's cpt has become so tall that the first few scan lines are disappearing off the top of the screen.
17-Feb-84 10:52:44-EST,229;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 17 Feb 84 10:52-EST
Date: Friday, 17 February 1984, 08:50-EST
From: Richard Mlynarik <Mly at MIT-OZ>
Subject: cadr27 fukt once more
To: bug-hardware at oz

Totally dead. Sigh.
17-Feb-84 21:19:49-EST,528;000000000000
Mail-From: JOHANN created at 17-Feb-84 21:19:30
Date: Fri 17 Feb 84 21:19-EST
From: John Amuedo <JOHANN@MIT-OZ>
Subject: CADR-6
To: bug-hardware@MIT-OZ, bug-lispm@MIT-OZ, pgs@MIT-OZ


CADR-6's console is exhibiting the same symptoms
I saw in November.  Before anyone pronounces it
"healthy" again, could someone please take a look
at its monitor and tell me if you see all of the
funny little stripes.  What do these mean?

Tongue in cheek,

John

P.S. I would like to be able to use the FPS Box
this term.

18-Feb-84 21:09:25-EST,430;000000000000
Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 18 Feb 84 21:09-EST
Date: Saturday, 18 February 1984, 21:08-EST
From: Richard Mlynarik <Mly at MIT-OZ>
Subject: more cadr18 monitor problems
To: bug-hardware at MIT-OZ
Message-ID: <[MIT-LISPM-18].18-Feb-84 21:08:22.Mly>

Well, the new monior corrects the missing-top-few-scan-lines
problem, but now the video is scewed so that the lower left
lies out of view.
Thanks
21-Feb-84 00:31:45-EST,559;000000000000
Mail-From: JOHANN created at 21-Feb-84 00:25:40
Date: Tue 21 Feb 84 00:25-EST
From: John Amuedo <JOHANN@MIT-OZ>
Subject: FPS Box
To: bug-hardware@MIT-OZ


It appears someone has been performing some kind of exploratory surgery
on the FPS box attached to CADR-6.  Please send me mail before you attempt
any further "repairs".

CADR-6's monitor is sick, and its fan creates a small hurricane when plugged
in.  Any chance we can swap CADR-6's monitor for a working one?  I would like
to use CADR-6 and attached array processor this week.

John

23-Feb-84 22:40:05-EST,612;000000000000
Mail-From: JOHANN created at 23-Feb-84 22:39:42
Date: Thu 23 Feb 84 22:39-EST
From: John Amuedo <JOHANN@MIT-OZ>
Subject: CADR-6
To: bug-hardware@MIT-OZ


This message was sent from CADR-6's console on the 7th floor.
Thanks to whomever got it's monitor running again.  However,
the display quality still leaves a little to be desired;  it
if barely readable in either video reverse mode.  I will be
glad to help someone swap its monitor with a working one, if
someone will tell me where we should go looking for a working
one (that's not in use).

Thanks again to whomever fixed CADR-6,

John

25-Feb-84 17:12:08-EST,525;000000000000
Received: from MIT-LISPM-23 by MIT-OZ via Chaosnet; 25 Feb 84 17:11-EST
Date: Saturday, 25 February 1984, 17:12-EST
From: John Canny <JfC at MIT-OZ>
To: BUG-Hardware at MIT-OZ

In Hardware in System 98.34, CADR 3.6, ZMail 53.10, MIT-Specific 22.0,
microcode 306, ZM MIT, on Lisp Machine Twenty-three:

The label on CADR-23's disk says that it needs a new pack. After using
the machine a bit, I'm convinced that this is true. To whom should I 
send mail to get one ? Are there any 'spares' in very good condition ?
 6-Mar-84 21:50:59-EST,1869;000000000000
Mail-From: DCB created at  6-Mar-84 21:49:46
Date: 6 Mar 1984  21:49 EST (Tue)
Message-ID: <DCB.11997313204.BABYL@MIT-OZ>
From: Daniel Brotsky <DCB@MIT-OZ>
To:   Martin David Connor <MARTY@MIT-OZ>
Cc:   dcb@MIT-OZ, bug-hardware@MIT-OZ, pondy@MIT-OZ
Subject: The Amazing 8th Floor Concentrator Move a Success!
In-reply-to: Msg of 6 Mar 1984  02:16-EST from Martin David Connor <MARTY>

Thanks very much for all you work on the terminal wiring and so
forth; I think it will make a real difference in the day-to-day
quality of life.

Of course, there are always a few bugs... In particular, the
thinner of the two wires running from the 8A hub to 810 seems to
be dead.  (This is the one with the plastic tag around it at the
concentrator end; it is plugged into the 2nd socket down in the
rightmost column of 8A-hub sockets.)  I have gotten both
terminals in our office to work by using the thick wire in BOTH
of the sockets occupied by the two wires, so I am quite sure that
it is the connection wire that is dead and not the sockets or the
terminals.  However, when you come to our office you will see
that the thin wire is connected to a female AMP connector, while
the thick wire is connected to a male AMP connector.  Thus, I
cannot ascertain whether the hub-810 wire is faulty or whether
the AAA-AMP wire is faulty (or both).  Thus, I recommend bringing
another male-AMP-to-AAA connector when you check this all out.  I
have left our current AAA wire connected to the hub-810 wire; the
twosome is hanging on the front of the file cabinet next to our
terminals.

Thanks for fixing this whenever you manage to get to it,
	dan

P.S. The thin (faulty) hub-810 wire has no shell over the AMP
connector at the 810 end.  Perhaps you have a spare we could use?

P.P.S. I have left the cover plates off the back of both
terminals.
	d.
 7-Mar-84 00:35:15-EST,757;000000000000
Mail-From: MARTY created at  7-Mar-84 00:34:07
Date: 7 Mar 1984  00:34 EST (Wed)
Message-ID: <MARTY.11997343126.BABYL@MIT-OZ>
From: Martin David Connor <MARTY@MIT-OZ>
To:   Daniel Brotsky <DCB@MIT-OZ>
Cc:   bug-hardware@MIT-OZ, MARTY-CC@MIT-OZ, pondy@MIT-OZ
Subject: The Amazing 8th Floor Concentrator Move a Success!
In-reply-to: Msg of 6 Mar 1984  21:49-EST from Daniel Brotsky <DCB>

    Date: Tuesday, 6 March 1984  21:49-EST
    From: Daniel Brotsky <DCB>

    Thanks very much for all you work on the terminal wiring and so
    forth; I think it will make a real difference in the day-to-day
    quality of life.

You're welcome
	......

    Thanks for fixing this whenever you manage to get to it,
    	dan

Fixed.
  
  %=

 8-Mar-84 03:07:20-EST,775;000000000000
Received: from MIT-LISPM-1 by MIT-OZ via Chaosnet; 8 Mar 84 03:07-EST
Date: Thursday, 8 March 1984, 03:08-EST
From: Richard M. Stallman <RMS at MIT-OZ>
To: bug-hardware at MIT-OZ

CADR18 stopped, :WHY said "Micro Stack parity error".
The IR contained a CALL-CONDITIONAL-PAGE-FAULT
from 10337@c; the pc was that plus one.
The USP was 1; 1@u was the correct return-address
for the subroutine that was running, and 2@U contained 13565
which does not look anything like the pc the call might have pushed.

Restarting at the same instruction with @G ^P made the machine
continue running.  The same kind of error happened at the same
place after a few seconds of operation.  I continued it again
in the same way and it has been running for at least a minute since.
 8-Mar-84 13:57:05-EST,297;000000000000
Received: from MIT-LISPM-30 by MIT-OZ via Chaosnet; 8 Mar 84 13:52-EST
Date: Thursday, 8 March 1984, 13:52-EST
From: saund at MIT-OZ
Subject: sticky key on keyboard of cadr-31
To: bug-hardware at MIT-OZ

there is a marginal left control key on the 
keyboard of cadr-31 on the third floor.
12-Mar-84 01:14:01-EST,600;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 12 Mar 84 01:13-EST
Date: Monday, 12 March 1984, 01:15-EST
From: RpK at MIT-SPEECH
Sender: lsi.bassett at MIT-SPEECH
Subject: CADR27
To: BUG-Hardware at MIT-OZ

In Hardware in System 98.36, CADR 3.6, ZMail 53.13, MIT-Specific 22.0,
Experimental Local-File 48.3, Experimental FILE-Server 8.2,
Experimental LFS 3.3, Experimental MagTape 22.6, microcode 306, XFS/C,
on Lisp Machine Filecomputer:

Why is the tape drive not connected on this machine ?  I thought the
problem about the controlller was solved more than six weeks ago.

``Bob''
13-Mar-84 14:39:51-EST,384;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 13 Mar 84 14:39-EST
Date: Tuesday, 13 March 1984, 14:33-EST
From: Charles E. Leiserson <CEL at MIT-MC>
Subject: PI screen
To: BUG-HARDWARE at OZ

In HARDWARE in Release 4.5, site configuration 62, on PI Project:

The terminal screen for PI is fading fast.  Again.  Is there a reason we have
been having so much trouble with it?
14-Mar-84 10:28:52-EST,542;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 14 Mar 84 10:28-EST
Date: Wednesday, 14 March 1984, 10:15-EST
From: Daniel Weise <DANIEL at MIT-MC>
Subject: Morrison's monitor is sick.
To: BUG-HARDWARE at MIT-OZ
Cc: smurf at MIT-MC

In HARDWARE in Release 5.0 [Beta Test rev 7], FEP 18, on Lisp Machine Jim Morrison (3600):

It was totally fine a few moments ago then the image instantaneously
became dimmer, a few percent smaller, and none of the vertical lines it
generates are straight.  It's bothersome but not fatal.

Daniel
14-Mar-84 14:49:44-EST,510;000000000000
Mail-From: PGS created at 14-Mar-84 14:47:07
Date: Wed 14 Mar 84 14:47-EST
From: Patrick G. Sobalvarro <PGS@MIT-OZ>
Subject: CADR-31
To: bug-hardware@MIT-OZ

CADR-31 won't disk-save -- it wedges when one attempts a disk-save on it.  It
operates perfectly except for this, but, unfortunately, is next to useless if
we can't easily get up-to-date software on it.

This has been going on for months.  I would suggest swapping disks with
another machine to see if the problem goes away as a first cut.
14-Mar-84 14:56:17-EST,1576;000000000000
Received: from MIT-LISPM-30 by MIT-OZ via Chaosnet; 14 Mar 84 14:55-EST
Date: Wednesday, 14 March 1984, 14:55-EST
From: Richard Mlynarik <Mly at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in Don't-dump-a-band! Inconsistent (unreleased patches loaded) System 98.39,
CADR 3.6, ZMail 53.13, MIT-Specific 22.0, microcode 309, ZM MIT,
on Lisp Machine Thirty:

This is what disk-save on CADR-31 results in.

Machine being debugged is MIT-LISPM-31.
Disk error: Fault  Transfer-Aborted
  disk address: UNIT 0 CYLINDER 775 HEAD 17 SECTOR 17 
  last memory address touched by disk = 41020
Contents of disk error log in debugee's main memory 600-640:

Command 11 (Write) 
CCW-list pointer 40000 (low 16 bits)
Disk address: unit 0, cylinder 775, head 17, block 17 (0 509 15 15 decimal)
Memory address: 41020 (type bits 0)
Status: 1700020111  Transfer-Aborted (or wr. ovr.)  Fault  Interrupt  Idle

Microcode halted via ILLOP from FATAL-DISK-ERROR
Micro PC History (OPC's), oldest first:
   25150   (LOG-DISK-ERROR 16)
   25066   (DISK-COMPLETION-ERROR 2)
   25067   (DISK-COMPLETION-ERROR 3)
   25070   (DISK-COMPLETION-ERROR 4)
   25130   FATAL-DISK-ERROR
   25131   (FATAL-DISK-ERROR 1)
   00023   ILLOP
   00024   XWIPM
Backtrace of microcode subroutine stack:
    5  027600   (COLD-AWAIT-DISK 2)
    4  027563   (DISK-COPY-PART-3 10)
    3  026626   DISK-SR-2
    2  026601   (DISK-SAVE-REGIONWISE 1)
    1  000442   M-T-TO-STACK
    0  040164   QMLP

>>ERROR: NOTHING-TO-SWAP-OUT QF-FINDCORE
[Sorry, error while trying to print that.]
16-Mar-84 13:34:42-EST,241;000000000000
Mail-From: AKR created at 16-Mar-84 13:25:47
Date: Fri 16 Mar 84 13:25-EST
From: Alex Krymm <AKR@MIT-OZ>
Subject: This is the end...
To: bug-hardware@MIT-OZ


for cadr6's disk drive.  The heads are gone...
so is the pack obviously.
18-Mar-84 15:57:45-EST,557;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 18 Mar 84 15:57-EST
Date: 18 March 1984 15:56-EST
From: Devon S. McCullough <Devon @ MIT-MC>
Sender: ___025 @ MIT-MC
To: BUG-HARDWARE @ MIT-MC

The MIT-TAC has been unreliable this past week.  Over the last year or so
I have never had any trouble with line noise until this week.  Just now
it disconnected me, and when I re-dialled and tried to open a connection
to MC it just said "open error" so I looked up the MC dialup and tried
that, and it turns out it thinks I'm still logged in via the TAC.
19-Mar-84 18:26:40-EST,637;000000000000
Mail-From: MARX created at 19-Mar-84 18:25:28
Date: Mon, 19 Mar 1984  18:25 EST
Message-ID: <MARX.12000683883.BABYL@MIT-OZ>
From: MARX@MIT-OZ
To:   bug-hardware@MIT-OZ
Subject: cadr-9

i was working on cadr-9, supduped to oz
but momentarily quiet, when suddenly it
blew up (figuratively speaking i hope).

i got the error

trap: the subscript into #READTABLE 4543712`,
	77772, was beyond the length, 777, in si:

it then refused to cold-boot despite numerous
attempts, returning the same error.

		-=*=- rick

(This is being sent from MARX by RICKL. Address any
queries there. I won't know what to tell you - CM).
21-Mar-84 23:40:19-EST,257;000000000000
Received: from MIT-LISPM-1 by MIT-OZ via Chaosnet; 21 Mar 84 23:38-EST
Date: Wednesday, 21 March 1984, 23:37-EST
From: Richard M. Stallman <RMS at MIT-OZ>
To: bug-hardware at MIT-OZ

CADR18 has crashed many times today with micro stack parity errors.
24-Mar-84 15:53:12-EST,408;000000000000
Mail-From: HLV created at 24-Mar-84 15:52:53
Date: Sat, 24 Mar 1984  15:52 EST
Message-ID: <HLV.12001966832.BABYL@MIT-OZ>
From: HLV@MIT-OZ
To:   bug-hardware@MIT-OZ
Subject: 7A terminal concentrator

Is anything being done about the 7A terminal concentrator?
It must be rebooted (or power cycled) every few days, if not
more often.  Someone told me the power supply is defective.

Harry Voorhees
28-Mar-84 00:32:16-EST,339;000000000000
Received: from MIT-LISPM-9 by MIT-OZ via Chaosnet; 28 Mar 84 00:31-EST
Date: Wednesday, 28 March 1984, 00:33-EST
From: Christopher M. Fry <CFRY at MIT-OZ>
Subject: No mice
To: bug-mit-hardware at MIT-OZ
Cc: bug-music at MIT-OZ

Cadr-4 has had no mouse for at least several days.

Cadr-9 has only a broken mouse.

Help, please.
31-Mar-84 16:39:36-EST,612;000000000000
Mail-From: ALAN created at 31-Mar-84 16:39:10
Date: Sat, 31 Mar 1984  16:39 EST
Message-ID: <ALAN.12003810264.BABYL@MIT-OZ>
From: Alan Bawden <ALAN@MIT-OZ>
To:   bug-hardware@MIT-OZ
Subject: [HLV: mice]

Date: Friday, 30 March 1984  18:52-EST
From: HLV
To:   bug-lm
Re:   mice

A couple of mouses for CADR's on the 7th floor seem to be broken
or missing.  Are new ones being ordered?  Also, has anyone considered
optical mice (like the one in the 8th floor playroom), and are they
available with a sufficiently high resolution?  I would think that
they would be more reliable.

Harry Voorhees
 2-Apr-84 10:35:01-EST,1241;000000000000
Mail-From: ZVONA created at  2-Apr-84 10:34:42
Date: Mon, 2 Apr 1984  10:34 EST
Message-ID: <ZVONA.12004268201.BABYL@MIT-OZ>
From: ZVONA@MIT-OZ
To:   tk@MIT-OZ
cc:   bug-hardware@MIT-OZ
Subject: hardware accellerator

Can we get some of these?  I imagine GLR or Taft or someone could rig
up a compatibility box to make them usuable with the 3600s.


		        PYRAMID POWER !

		Scientific studies have PROVEN the
		mysterious powers of the PYRAMID!

		And now YOU can harness this awesome
		power for yourself! After YEARS OF
		SCIENTIFIC RESEARCH, Drias Enterprises
		is proud to announce the COMPUTER
		PYRAMID for your IBM-PC! This
		remarkable product of scientific
		engineering will allow your IBM-PC
		to operate MORE EFFICIENTLY and
		FASTER! Made from a remarkable new alloy
		which actually enhances the already
		awesome power of the pyramid, the
		DRIAS COMPUTER PYRAMID comes complete
		with a built in compass to keep your
		IBM-PC constantly pointing TRUE EAST!

		COMPLETELY IBM COMPATIBLE!

		Order NOW! Can you afford not to?

		Send a check or money order for $125.00
		to: DRIAS ENTERPRISES
		    PO Box CMU-145, Pittsburgh, PA, 15213

		(PA residents please add 6% sales tax)

 3-Apr-84 02:47:42-EST,356;000000000000
Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 3 Apr 84 02:47-EST
Date: Tuesday, 3 April 1984, 02:47-EST
From: RMS at MIT-OZ
Sender: ZZZ.RLK at MIT-OZ
To: bug-hardware at MIT-OZ

CADR 1 got a C mem parity error, at location 17541.
I warm booted and examined the location and it was unchanged.
So perhaps the parity bit was the one clobbered.
 3-Apr-84 10:55:05-EST,1203;000000000000
Mail-From: PGS created at  3-Apr-84 10:51:14
Date: Tue, 3 Apr 1984  10:51 EST
Message-ID: <PGS.12004533358.BABYL@MIT-OZ>
From: PGS@MIT-OZ
To:   hlv@MIT-OZ
Cc:   bug-hardware@MIT-OZ
Subject: [HLV: mice]
In-reply-to: Msg of 31 Mar 1984  16:39-EST from Alan Bawden <ALAN>

    Date: Saturday, 31 March 1984  16:39-EST
    From: Alan Bawden <ALAN>
    To:   bug-hardware
    Re:   [HLV: mice]

    Date: Friday, 30 March 1984  18:52-EST
    From: HLV
    To:   bug-lm
    Re:   mice

    A couple of mouses for CADR's on the 7th floor seem to be broken
    or missing.  Are new ones being ordered?  Also, has anyone considered
    optical mice (like the one in the 8th floor playroom), and are they
    available with a sufficiently high resolution?  I would think that
    they would be more reliable.

    Harry Voorhees

When you have a broken mouse (I really need a file saying this on my
directory), take it up to John Purbrick's office, room 912.  He has a
workbench with two boxes of mice on it.  One contains broken mice, and the
other contains working mice.  Leave your broken mouse and take a working one.
Attach a note to the broken mouse describing the symptoms.
 4-Apr-84 12:02:35-EST,1145;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 4 Apr 84 11:59-EST
Date: Wednesday, 4 April 1984, 12:00-EST
From: Richard Mark Soley <Soley at MIT-MC>
Subject: LM15 crash of 4/4/84
To: BUG-HARDWARE at OZ, RZ at MC

In HARDWARE in System 222.249, Zmail 74.46, site configuration 74, on Lisp Machine Sixteen:

LM15 just plain stopped.

Machine being debugged is MIT-LISPM-15.
Bus-interface errors since last reset:
  Unibus non-existent device
The running microcode is version 998.
This program doesn't understand why the machine stopped (not ILLOP).
The running microcode is version 998.
Micro PC History (OPC's), oldest first:
   25634   (P-B-MR1 3)
   25634   (P-B-MR1 3)
   25634   (P-B-MR1 3)
   25635   (P-B-MR1 4)
   25636   (P-B-MR1 5)
   25637   (P-B-MR1 6)
   25640   (P-B-MR1 7)
   25641   (P-B-MR1 10)
Backtrace of microcode subroutine stack:
    2  026070   QMAAD
    1  000404   (TRAP 21)
    0  040170   QMLP
Microcode state flags: switching stack groups

using old style obarray! 2120603206
>>Trap: There was an attempt to divide by zero in QF-SYMBOL-OLD.
[Sorry, error while trying to print that.]
 5-Apr-84 16:31:45-EST,600;000000000000
Received: from MIT-LISPM-1 by MIT-OZ via Chaosnet; 5 Apr 84 16:26-EST
Date: Thursday, 5 April 1984, 16:27-EST
From: Robert L. Krawitz <ZZZ.RLK at MIT-OZ>
To: BUG-HARDWARE at MIT-OZ


Machine being debugged is MIT-LISPM-18.
Processor error:
  Micro-Stack parity error
Micro PC History (OPC's), oldest first:
   04103   (XINSTANCE-LOC-1 10)
   04104   XINSTANCE-LOC-RESTART
   04105   (XINSTANCE-LOC-RESTART 1)
   04106   (XINSTANCE-LOC-RESTART 2)
   10327   (AREFI-INSTANCE-NEW 5)
   10330   (AREFI-INSTANCE-NEW 6)
   10336   AREFI-INSTANCE-NEW-1
   10337   (AREFI-INSTANCE-NEW-1 1)
 7-Apr-84 10:45:05-EST,265;000000000000
Mail-From: DPH created at  7-Apr-84 10:44:52
Date: Sat 7 Apr 84 10:44-EST
From: Daniel Huttenlocher <DPH@MIT-OZ>
Subject: lm15
To: bug-hardware@MIT-OZ

is still getting unibus nxm errors every few hours.  we need some other
solution to this problem.  sigh.
 7-Apr-84 13:10:18-EST,204;000000000000
Mail-From: DPH created at  7-Apr-84 13:09:04
Date: Sat 7 Apr 84 13:09-EST
From: Daniel Huttenlocher <DPH@MIT-OZ>
Subject: lm15
To: bug-hardware@MIT-OZ, rz@MIT-MC

is now using lm9's machine again.
10-Apr-84 17:31:31-EST,388;000000000000
Received: from MIT-LISPM-3 by MIT-OZ via Chaosnet; 10 Apr 84 17:21-EST
Date: Tuesday, 10 April 1984, 17:20-EST
From: Noble G. Larson <NGL at MIT-OZ>
To: BUG-Hardware at MIT-OZ

In Hardware in System 98.37, CADR 3.6, ZMail 53.13, MIT-Specific 22.0,
microcode 306, khc 4/2, on Lisp Machine Three:

CADR-5 is losing solidly, during cold boot.  Seems to be level 1 map parity error.
12-Apr-84 16:16:33-EST,243;000000000000
Mail-From: RILEY created at 12-Apr-84 15:47:44
Date: Thu 12 Apr 84 15:47-EST
From: Michael D. Riley <RILEY@MIT-OZ>
Subject: Cadr 6
To: bug-hardware@MIT-OZ

Cadr six does not respond to boot.  I need this cadr since
it has the FPS box.
14-Apr-84 14:59:34-EST,650;000000000000
Mail-From: BUCKLEY created at 14-Apr-84 14:59:14
Date: Sat, 14 Apr 1984  14:59 EST
Message-ID: <BUCKLEY.12007462088.BABYL@MIT-OZ>
From: BUCKLEY@MIT-OZ
To:   bug-hardware@MIT-OZ
cc:   buckley@MIT-OZ, eln@MIT-OZ
Subject: losing terminal

My office (749) has a non-participating terminal.  I have narrowed 
the problem down to the concentrator (7A) or wiring thereto.  The
terminal works when plugged in at another office.  Rebooting 7A did
not awaken the terminal so it probably isn't MINITS' fault; maybe
the port died or someone mucked with the connections.  But alas,
I don't know how to check this.  Can anyone help?

Steve Buckley
15-Apr-84 16:33:38-EST,512;000000000000
Mail-From: ECC created at 15-Apr-84 16:33:18
Date: Sun 15 Apr 84 16:33-EST
From: Eugene Ciccarelli <ECC@MIT-OZ>
Subject: AAA next to OZ
To: bug-hardware@MIT-OZ

This terminal is sending both CR and LF when you
type the Return key.  (Though just a CR when you
type a Control-M, luckily.)  I can't find a manual
for the AAA, so I can't check if it's just some
bit in Setup to toggle.  But someone ought to find
out and fix it -- can be risky or unsettling doing
things like

@delete *.*.*,
@@keep 1
16-Apr-84 02:36:54-EST,2040;000000000001
Received: from MIT-LISPM-1 by MIT-OZ via Chaosnet; 16 Apr 84 02:36-EST
Date: Monday, 16 April 1984, 02:35-EST
From: RMS at MIT-OZ
Sender: RpK at MIT-OZ
To: BUG-HARDWARE at MIT-OZ

Machine being debugged is MIT-LISPM-18.
Processor error:
  Micro-Stack parity error
Micro PC History (OPC's), oldest first:
   04103   (XINSTANCE-LOC-1 10)
   04104   XINSTANCE-LOC-RESTART
   04105   (XINSTANCE-LOC-RESTART 1)
   04106   (XINSTANCE-LOC-RESTART 2)
   10327   (AREFI-INSTANCE-NEW 5)
   10330   (AREFI-INSTANCE-NEW 6)
   10336   AREFI-INSTANCE-NEW-1
   10337   (AREFI-INSTANCE-NEW-1 1)

This program doesn't understand why the machine stopped (not ILLOP).
Micro PC History (OPC's), oldest first:
   04103   (XINSTANCE-LOC-1 10)
   04104   XINSTANCE-LOC-RESTART
   04105   (XINSTANCE-LOC-RESTART 1)
   04106   (XINSTANCE-LOC-RESTART 2)
   10327   (AREFI-INSTANCE-NEW 5)
   10330   (AREFI-INSTANCE-NEW 6)
   10336   AREFI-INSTANCE-NEW-1
   10337   (AREFI-INSTANCE-NEW-1 1)
Backtrace of microcode subroutine stack:
    1  010303   AREFI-RETURN
    0  040164   QMLP
Current stack group is: <Stack Group Flush file connections>
Current process is: #<DTP-INSTANCE 7713320>"Flush file connections"
Complete backtrace follows: (type Space to stop)

3263244 #<DTP-FEF-POINTER FILE-SYSTEM:HOST-UNIT-DORMANT 11301717>[0] #<DTP-INSTANCE 21346571>
3263234 #<DTP-FEF-POINTER (:METHOD FILE-SYSTEM:FILE-HOST-MIXIN :RESET-DORMANT-HOST-UNITS) 11302004>[63] :RESET-DORMANT-HOST-UNITS
3263221 #<DTP-FEF-POINTER (:METHOD SYSTEM-INTERNALS:VANILLA-FLAVOR :SEND-IF-HANDLES) 2424475>[70] :SEND-IF-HANDLES :RESET-DORMANT-HOST-UNITS
3263166 #<DTP-FEF-POINTER FILE-SYSTEM:RESET-DORMANT-HOST-UNITS 11301657>[70]

BOUND-LOC-POINTER-NOT-LOCATIVE 3263130 #<DTP-FEF-POINTER SYSTEM-INTERNALS:PROCESS-RUN-FUNCTION-INTERNAL 2435434>[100] NIL FILE-SYSTEM:RESET-DORMANT-HOST-UNITS NIL

BOUND-LOC-POINTER-NOT-LOCATIVE 
BIND-STACK-EXHAUSTED-DURING-USTACK-XFER 3263027 #<DTP-FEF-POINTER SYSTEM-INTERNALS:PROCESS-TOP-LEVEL 30457635>[246] NIL

18-Apr-84 23:50:20-EST,285;000000000000
Mail-From: RILEY created at 18-Apr-84 23:49:09
Date: Wed 18 Apr 84 23:49-EST
From: Michael D. Riley <RILEY@MIT-OZ>
Subject: CADR-6
To: bug-hardware@MIT-OZ

This is my second message about CADR 6.  It appears to be defunct
and I need to use the FPS box on it.  What gives??????
21-Apr-84 17:29:18-EST,717;000000000000
Mail-From: JFC created at 21-Apr-84 17:28:33
Date: Sat, 21 Apr 1984  17:28 EST
Message-ID: <JFC.12009324276.BABYL@MIT-OZ>
From: JFC@MIT-OZ
To:   akr@MIT-OZ
cc:   bug-hardware@MIT-OZ


Cadr-23 is making very frequent arithmetic errors in bignum
arithmetic. I'm almost certain that this is due to conditional jumps
being missed. I tried replacing the machines 74S181's with 74AS181's,
but some of these may have been bad because it wouldn't get all the
way through booting with the new chips. I've heard from Taft and Dph
that its possible to ease this problem by slowing the machines clock.
Could you do this sometime ? 

N.B. This is the machine that has only one good band left on its pack.

John
22-Apr-84 23:37:28-EST,294;000000000000
Mail-From: STRAZ created at 22-Apr-84 23:37:06
Date: Sun 22 Apr 84 23:37:06-EST
From: Steve Strassmann <STRAZ@MIT-OZ>
Subject: blek
To: bug-aaa@MIT-OZ, bug-hardware@MIT-OZ
cc: maria@MIT-OZ


My AAA (in room 703) has develped font cancer. Can anyone treat
these serif tumors?
-------
25-Apr-84 15:35:41-EST,618;000000000000
Mail-From: ECC created at 25-Apr-84 15:29:16
Date: Wed 25 Apr 84 15:29-EST
From: Eugene Ciccarelli <ECC@MIT-OZ>
Subject: Dialup trouble
To: bug-hardware@MIT-OZ

I called 8260, got the system greeting, but then found I could not type
anything -- each character elicited a beep.  I tried calling 8265 and
this time logged on ok, and proceeded to work (in EMACS).  Suddenly,
after perhaps 20 minutes or more, I couldn't type any more -- all my
characters just beeped, including ^C.  I redialed (8265 I think) and
am now on ok, sending this message.

Is this likely to be trouble at your end or in my modem?
25-Apr-84 16:19:02-EST,427;000000000000
Mail-From: ECC created at 25-Apr-84 16:18:39
Date: Wed 25 Apr 84 16:18-EST
From: Eugene Ciccarelli <ECC@MIT-OZ>
Subject: Dialup troubles P.S.
To: bug-hardware@MIT-OZ

The trouble kept recurring, on several different lines.  (I gave up
and am coming in through MC now.)  I also note that there is not a
single dialup user logged on now, which seems suspicious, and further
makes me think the problem is not at my end.
26-Apr-84 18:15:01-EST,438;000000000000
Mail-From: JFC created at 26-Apr-84 18:14:37
Date: Thu, 26 Apr 1984  18:14 EST
Message-ID: <JFC.12010643385.BABYL@MIT-OZ>
From: JFC@MIT-OZ
To:   oaf@MIT-OZ, pgs@MIT-OZ
cc:   bug-hardware@MIT-OZ
Subject: 7A concentrator


This animal has a bad power supply. It doesnt 
just go down, it goes out completely, no lights
on the panel, no flicker from the LED's on board.
Power cycling makes it go again. Are there any
spares ?

27-Apr-84 10:41:05-EST,539;000000000000
Mail-From: OAF created at 27-Apr-84 10:37:55
Date: Fri, 27 Apr 1984  10:37 EST
Message-ID: <OAF.12010822385.BABYL@MIT-OZ>
From: OAF@MIT-OZ
To:   JFC@MIT-OZ
Cc:   bug-hardware@MIT-OZ, pgs@MIT-OZ
Subject: 7A concentrator
In-reply-to: Msg of 26 Apr 1984  18:14-EST from JFC

Boyoboyoboy are you in luck.  There are not one but TWO unused
backplanes in that closet.  It can get replaced soon.

But are you really sure it's the power supply?  Did you measure
voltages with the machine busted?  What is yur favorite color?

Oded
27-Apr-84 17:10:59-EST,815;000000000000
Received: from MIT-LISPM-4 by MIT-OZ via Chaosnet; 27 Apr 84 17:10-EST
Date: Friday, 27 April 1984, 17:09-EST
From: Christopher Fry <cfry at MIT-OZ>
Subject: broken cadr keyboard
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in Release 5.0 [Beta Test rev 7], Experimental Useful 10.0,
Experimental TimeKit 12.0, Experimental Music 11.0,
Experimental Pitch 11.0, Experimental Enharm-Pitch 11.0,
Experimental Harmony 11.0, Experimental Staff 11.0,
Experimental Chroma 11.0, Experimental Play 9.0,
Experimental Linedit 7.0, Experimental Frets 8.0, Experimental FB 140.0,
Music 14 Apr - JRD, on Lisp Machine Four (LM-2):

The keyboard for cadr-9/15 in rm 702 is broken.
I've unpluged it and put a note on it.
Striking keys "t" and "k" cause a long string of characters to be sent.
How can I get this fixed?
 2-May-84 10:20:26-EDT,357;000000000001
Received: from MIT-LISPM-1 by MIT-OZ via Chaosnet; 2 May 84 10:18-EDT
Date: Wednesday, 2 May 1984, 10:19-EDT
From: Robert P. Krajewski <RpK at MIT-OZ>
Subject: Cadr27's tape drive
To: Bug-Hardware at MIT-OZ
Message-ID: <[MIT-LISPM-1].5/02/84 10:19:07.RpK>

This is fixed once, but then it broke about six weeks ago.
Is it going to be fixed again ?
 3-May-84 17:03:18-EDT,290;000000000000
Mail-From: KOCH created at  3-May-84 17:01:45
Date: Thu 3 May 84 17:01:45-EDT
From: KOCH@MIT-OZ
Subject: CADR 32
To: bug-hardware@MIT-OZ

Does anybody know what happened to CADR 32 (the one just before
Tommy Poggio's office. It appears to be permanently down?
   Christof
-------
 3-May-84 18:11:52-EDT,353;000000000000
Mail-From: JFC created at  3-May-84 18:09:59
Date: Thu, 3 May 1984  18:09 EDT
Message-ID: <JFC.12012466627.BABYL@MIT-OZ>
From: JFC@MIT-OZ
To:   KOCH@MIT-OZ
Cc:   bug-hardware@MIT-OZ
Subject: CADR 32
In-reply-to: Msg of 3 May 1984  17:01-EDT from KOCH


The machine by Tommy's office is CADR-23, not 32.
But your right about it being down.

 9-May-84 05:12:44-EDT,477;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 9 May 84 05:12-EDT
Date: Wednesday, 9 May 1984, 04:59-EDT
From: Robert P. Krajewski <RpK at MIT-OZ>
Subject: LM18's keyboard
To: BUG-Hardware at MIT-OZ
Message-ID: <[MIT-LISPM-18].5/09/84 04:59:14.RpK>

In Hardware in Don't-dump-a-band! Inconsistent (unreleased patches loaded) System 98.48,
CADR 3.6, ZMail 53.17, MIT-Specific 22.0, microcode 309, ZM MIT,
on Lisp Machine Eighteen:

The <Return> seems to be bouncy...
14-May-84 12:37:26-EDT,213;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 14 May 84 03:26-EDT
Date: 14 May 1984 03:21-EDT
From: Richard Mlynarik <MLY @ MIT-MC>
To: bug-hardware @ MIT-OZ

What exactly is the story with cadrs 30,31,32 ?
16-May-84 04:42:36-EDT,240;000000000001
Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 16 May 84 04:42-EDT
Date: Wednesday, 16 May 1984, 04:41-EDT
From: Richard M. Stallman <RMS at MIT-OZ>
To: bug-hardware at MIT-OZ

CADR5 appears to be down; its screen is turned off.
25-May-84 05:50:30-EDT,416;000000000000
Received: from MIT-LISPM-23 by MIT-OZ via Chaosnet; 25 May 84 05:50-EDT
Date: Friday, 25 May 1984, 05:51-EDT
From: Richard Mlynarik <Mly at MIT-OZ>
Subject: cadr 23 kbd
To: BUG-Hardware at MIT-OZ

In Hardware in Don't-dump-a-band! Inconsistent (unreleased patches loaded) System 98.56,
CADR 3.6, ZMail 53.17, MIT-Specific 22.0, microcode 309, ZM MIT,
on Lisp Machine Twenty-three:

Very bouncy break key.
26-May-84 18:24:53-EDT,434;000000000000
Received: from MIT-LISPM-4 by MIT-OZ via Chaosnet; 26 May 84 18:24-EDT
Date: Saturday, 26 May 1984, 18:20-EDT
From: zvona at MIT-OZ
Sender: saz at MIT-OZ
Subject: cadr9/15 glorked
To: bug-hardware at MIT-OZ
Cc: dph at MIT-OZ

Seems to be getting bad memory references.  CMEM-BANK 3. fails in cc-test-machine.  I can't 
run cc-run-mtest because it gets BAD-SYMBOL-TYPE breakpoints trying to load the memory map.  
Grumble. 
30-May-84 00:00:35-EDT,305;000000000000
Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 29 May 84 23:59-EDT
Date: Tuesday, 29 May 1984, 23:56-EDT
From: Richard M. Stallman <RMS at MIT-OZ>
Subject: cadr-1 disk error
To: bug-hardware at MIT-OZ

cylinder 170, head 11, sector 0.
This was printed by CC; I don't know what radix it uses.
13-Jun-84 23:20:01-EDT,3375;000000000000
Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 13 Jun 84 23:19-EDT
Date: Wednesday, 13 June 1984, 23:19-EDT
From: Robert P. Krajewski <RPK at MIT-OZ>
Subject: CADR1 woes
To: BUG-HARDWARE at MIT-OZ

In HARDWARE in Don't-dump-a-band! Inconsistent (unreleased patches loaded) System 98.61,
CADR 3.7, ZMail 53.17, MIT-Specific 22.1, microcode 309, ZM MIT,
on Lisp Machine Eighteen:

Ugh.  CADR1 won't boot.  I tried printing the disk label, but it was
munged after the PAGE band.  So I initialised the label, which cured the
label problems.  The label of CADR1 is now:

CADR-1: Trident T-300, Reintialized by RpK 13 Jun 84
LABL version 1, 815 cylinders, 19 heads, 17 blocks/track, 323 blocks/cylinder
Current microload = MCR1, current virtual memory load (band) = LOD1
18 partitions, 7-word descriptors:
* MCR1 at block 17, 148 blocks long, "UCADR 309"
  MCR2 at block 165, 148 blocks long, ""
  MCR3 at block 313, 148 blocks long, ""
  MCR4 at block 461, 148 blocks long, ""
  MCR5 at block 609, 148 blocks long, ""
  MCR6 at block 757, 148 blocks long, ""
  MCR7 at block 905, 148 blocks long, ""
  MCR8 at block 1053, 148 blocks long, "", 91 blocks free at 1201
  PAGE at block 1292, 65246 blocks long, ""
* LOD1 at block 66538, 24225 blocks long, "98.49"
  LOD2 at block 90763, 24225 blocks long, ""
  LOD3 at block 114988, 24225 blocks long, ""
  LOD4 at block 139213, 24225 blocks long, ""
  LOD5 at block 163438, 24225 blocks long, ""
  LOD6 at block 187663, 24225 blocks long, ""
  LOD7 at block 211888, 24225 blocks long, ""
  LOD8 at block 236113, 19132 blocks long, ""
  FILE at block 255245, 8000 blocks long, ""

But it still won't boot.

Machine being debugged is MIT-LISPM-1.

Microcode halted via ILLOP from CHAOS-RCV-INTR-LOOP+1
Micro PC History (OPC's), oldest first:
   25567   (CHAOS-INTR 22)
   25570   (CHAOS-INTR 23)
   25571   (CHAOS-INTR 24)
   25572   CHAOS-RCV-INTR-LOOP
   25573   (CHAOS-RCV-INTR-LOOP 1)
   25574   (CHAOS-RCV-INTR-LOOP 2)
   00023   ILLOP
   00024   XWIPM
Backtrace of microcode subroutine stack:
   30  025703   (CHAOS-XMT-2 2)
   27  025420   INTR-OUTDEV-BUSY-WAIT
   26  000000   COPY-BUFFER-CCW-ORIGIN
   25  000000   COPY-BUFFER-CCW-ORIGIN
   24  000000   COPY-BUFFER-CCW-ORIGIN
   23  000000   COPY-BUFFER-CCW-ORIGIN
   22  000000   COPY-BUFFER-CCW-ORIGIN
   21  000000   COPY-BUFFER-CCW-ORIGIN
   20  000000   COPY-BUFFER-CCW-ORIGIN
   17  000000   COPY-BUFFER-CCW-ORIGIN
   16  000000   COPY-BUFFER-CCW-ORIGIN
   15  000000   COPY-BUFFER-CCW-ORIGIN
   14  000000   COPY-BUFFER-CCW-ORIGIN
   13  000000   COPY-BUFFER-CCW-ORIGIN
   12  000000   COPY-BUFFER-CCW-ORIGIN
   11  000000   COPY-BUFFER-CCW-ORIGIN
   10  000000   COPY-BUFFER-CCW-ORIGIN
    7  000000   COPY-BUFFER-CCW-ORIGIN
    6  000000   COPY-BUFFER-CCW-ORIGIN
    5  000000   COPY-BUFFER-CCW-ORIGIN
    4  000000   COPY-BUFFER-CCW-ORIGIN
    3  000000   COPY-BUFFER-CCW-ORIGIN
    2  000000   COPY-BUFFER-CCW-ORIGIN
    1  000000   COPY-BUFFER-CCW-ORIGIN
    0  000000   COPY-BUFFER-CCW-ORIGIN
Halted due to unexpected page fault, VMA=1000, maps=0@1/ 0 2@2/ 0 ACCESS 0 STATUS 0 META 0 PHYS-PAGE 0 META BIT BREAKDOWN: OLDSPACE 0 EXTRA-PDL 0 REGION-REP 0 UNUSED 0

>>ERROR: 4205012411 ARRAY HEADER NOT DTP-ARRAY-HEADER - QF-ARRAY-SETUP
[Sorry, error while trying to print that.]
13-Jun-84 23:21:14-EDT,250;000000000000
Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 13 Jun 84 23:20-EDT
Date: Wednesday, 13 June 1984, 23:21-EDT
From: Robert P. Krajewski <RPK at MIT-OZ>
To: BUG-Hardware at MIT-OZ

CADR8 won't boot.  Always stops at uPC 25146, no lights...

16-Jun-84 11:15:24-EDT,303;000000000000
Mail-From: ZVONA created at 16-Jun-84 11:15:10
Date: Sat 16 Jun 84 11:15-EDT
From: David Chapman <ZVONA@MIT-OZ>
Subject: cadr-15
To: BUG-hardware@MIT-OZ

is repeatedly halting while cold booting.  It does so at different places, which suggests
flakey hardware.  I haven't tried to debug it yet.
23-Jun-84 04:46:59-EDT,576;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 23 Jun 84 04:46-EDT
Date: Friday, 22 June 1984, 00:15-EDT
From: Eugene C. Ciccarelli <ECC at MIT-MC>
Subject: bad mice
To: BUG-Hardware at MIT-OZ

In Hardware in System 98.59, CADR 3.7, ZMail 53.17, MIT-Specific 22.1,
microcode 309, gc@36, on Lisp Machine Two:

What is the procedure nowadays, when one discovers a mouse in distress?
The one that is on CADR-4 seems to have its right button stuck, or not
clicking or something.  Is there someone to whom these should be taken,
and some place to get replacement mice?
29-Jun-84 20:35:31-EDT,284;000000000000
Mail-From: JOHANN created at 29-Jun-84 20:35:03
Date: Fri 29 Jun 84 20:35-EDT
From: John Amuedo <JOHANN@MIT-OZ>
Subject: Ambassador in my office
To: bug-hardware@MIT-OZ


...no longer works.  I can't identify
the problem.  Any suggestions?

Thanks.
John Amuedo
Rm. 701

 2-Jul-84 21:17:29-EDT,1011;000000000000
Received: from MIT-LISPM-2 by MIT-OZ via Chaosnet; 2 Jul 84 21:16-EDT
Date: Monday, 2 July 1984, 21:18-EDT
From: Eugene Ciccarelli <ECC at MIT-OZ>
Subject: keyboard
To: BUG-Hardware at MIT-OZ

In Hardware in System 98.59, CADR 3.7, ZMail 53.17, MIT-Specific 22.1,
microcode 309, gc@36, on Lisp Machine Two:

I found the keyboard on CADR2 to be ineffective and have switched it
with the one on CADR31, since CADR31 doesn't seem to be usable.  I left
a note on the bad keyboard.  Here is what has happened:

The lispm was not responding to any characters typed.  No response to
C-M-C-M-Rubout.  I pulled the plug, waited a couple of minutes, and
powered it back on.  It sang its little tune, and the keyboard seemed
reset.  I booted it, but found it again frozen.  Another two on/offs,
the first with no effect, and the keyboard worked intermittently: it
would sing its reset tune every now and then, spontaneously, and there
seemed to be some spurious characters sometimes sent to the lispm.
 7-Jul-84 16:29:49-EDT,1290;000000000000
Received: from MIT-LISPM-4 by MIT-OZ via Chaosnet; 7 Jul 84 16:29-EDT
Date: Saturday, 7 July 1984, 16:29-EDT
From: Robert P. Krajewski <RpK at MIT-OZ>
Subject: Various CADR hardware problems
To: Bug-Hardware at MIT-OZ
CC: NGL at MIT-OZ, MLY at MIT-OZ
Message-ID: <[MIT-LISPM-4].7/07/84 16:29:33.RpK>

These problems have been kicking around for some time, and really ought
to be fixed:

(a) CADR18 dies randomly.  We suspect the problem to be memory parity
error.  Rumour has it this is a relatively easily problem to fix.

(b) CADR5 has a bad CHAOSnet interface.  As of yesterday, it was working
intermittently, but would usually cause higher levels of the CHAOSNet
software to hang (usually when packets had to be acknowledged in a STS,
it seems).  The bad bits will become evident by running CHAOS:CHATST on
the machine.

(c) CADR8's keyboard does not seem to work.

(d) CADR9 has disappeared from the face of the earth, it seems, to be
transformed into CADR15, a namespace server for Symbolics software.
CADR9 was formerly used by the Music Group -- don't they want it back ?
Either the real CADR15 ought to be fixed, or, judging from the last ten
weeks of Bug-LispM mail, a site the size of MIT really ought to have a
3600 as a namespace server.

``Bob''
 7-Jul-84 22:25:48-EDT,380;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 7 Jul 84 22:25-EDT
Date: 7 July 1984 21:52-EDT
From: Leigh L. Klotz <KLOTZ @ MIT-MC>
Subject: cadr-9
To: RPK @ MIT-MC, BUG-HARDWARE @ MIT-MC

I don't think "back" is the appropriate word for the music group's
wanting of cadr-9; unless I'm grossly mistaken, cadr-9 is a general
AI Lab machine semi-snarfed by the music group.
 7-Jul-84 22:27:23-EDT,1277;000000000000
Received: from MIT-SPEECH by MIT-OZ via Chaosnet; 7 Jul 84 22:26-EDT
Date: 7 Jul 1984  22:25 EDT (Sat)
Message-ID: <SR.EHPYC.12029552587.BABYL@MIT-SPEECH>
From: Scott Cyphers <SR.EHPYC@MIT-SPEECH>
To:   "Robert P. Krajewski" <RpK@MIT-OZ>
Cc:   Bug-Hardware@MIT-OZ, MLY@MIT-OZ, NGL@MIT-OZ
Subject: Various CADR hardware problems
In-reply-to: Msg of 7 Jul 1984 16:29-EDT from Robert P. Krajewski <RpK at MIT-OZ>

When I fixed Cadr15/9, a couple weeks ago, the memory board appeared
to be giving a data error without giving a parity error, so it went
undetected and caused other things to bring it to a halt when they
were given garbage to work with.  This was with the TI memory boards.
It may be something to watch out for, or it may have been a strange
case.  I didn't try to fix the TI board, so there is probably a memory
board around someplace that should be fixed (GLR might know where).

I also found lint-like dust in LM15 on the connectors inside the door,
and cleaning them off seemed to make it work better.  I suspect this
might help the other Cadrs as well.  It is less dusty over here, and
our two Cadrs tend to go about 3 months (i.e. 6 months per Cadr)
between diseases, and it's usually a wire wrap going bad or a memory
chip gone senile.
 8-Jul-84 01:16:30-EDT,996;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 8 Jul 84 01:16-EDT
Date: Sun, 8 Jul 1984  01:12 EDT
Message-ID: <PGS.12029582979.BABYL@MIT-OZ>
From: PGS@MIT-OZ
To:   "Leigh L. Klotz" <KLOTZ@MIT-MC>
Cc:   BUG-HARDWARE@MIT-MC, RPK@MIT-MC
Subject: cadr-9
In-reply-to: Msg of 7 Jul 1984  21:52-EDT from Leigh L. Klotz <KLOTZ at MIT-MC>

    Date: Saturday, 7 July 1984  21:52-EDT
    From: Leigh L. Klotz <KLOTZ at MIT-MC>
    To:   RPK at MIT-MC, BUG-HARDWARE at MIT-MC
    Re:   cadr-9

    I don't think "back" is the appropriate word for the music group's
    wanting of cadr-9; unless I'm grossly mistaken, cadr-9 is a general
    AI Lab machine semi-snarfed by the music group.

Nope, not quite.  CADR-4 is the general AI lab machine that was snarfed by
the music group, but everyone agreed it was okay if the music group didn't
have punt privileges on it.  CADR-9 was once in that position (years ago),
but Winston gave the music group the machine, so it really is theirs.
 8-Jul-84 20:07:52-EDT,247;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 8 Jul 84 20:07-EDT
Date: Sunday, 8 July 1984, 20:07-EDT
From: Robert P. Krajewski <RpK at MIT-OZ>
Subject: CADR31
To: BUG-Hardware at MIT-OZ

It's functioning, but the Chaos interface is not.

11-Jul-84 01:29:50-EDT,6020;000000000000
Received: from MIT-LISPM-1 by MIT-OZ via Chaosnet; 11 Jul 84 01:29-EDT
Date: Wednesday, 11 July 1984, 01:29-EDT
From: Robert P. Krajewski <RPK at MIT-OZ>
Subject: CADR18
To: BUG-Hardware at MIT-OZ

This machine is very flakey.  It seems to be a process parity error: testing
the machine elicits some errors in the shifter, but the memory tests seem to go
smoothly.

Here is a CC :MAIL diagnostic.  Sometimes, it will say ``processor parity
error.''

 Machine being debugged is MIT-LISPM-18.
[Loading CC symbols for Microcode 309]

This program doesn't understand why the machine stopped (not ILLOP).
Micro PC History (OPC's), oldest first:
   10340   (AREFI-INSTANCE-NEW-1 2)
   10340   (AREFI-INSTANCE-NEW-1 2)
   10340   (AREFI-INSTANCE-NEW-1 2)
   10340   (AREFI-INSTANCE-NEW-1 2)
   10341   (AREFI-INSTANCE-NEW-1 3)
   10342   AREFI-SET-ARRAY-NEW
   10343   AREFI-ARRAY-NEW
   10344   (AREFI-ARRAY-NEW 1)
Backtrace of microcode subroutine stack:
    1  010303   AREFI-RETURN
    0  040164   QMLP
Current stack group is: <Stack Group KBD SYS>
Current process is: #<DTP-INSTANCE 7713320>"KBD SYS"
Complete backtrace follows: (type Space to stop)

3263536 #<DTP-FEF-POINTER TV:SHEET-CAN-GET-LOCK-INTERNAL 11572746>[0] #<DTP-INSTANCE 3204114> #<DTP-INSTANCE 7713320> #<DTP-INSTANCE 3204114>
3263530 #<DTP-FEF-POINTER TV:SHEET-CAN-GET-LOCK 11572730>[34] #<DTP-INSTANCE 3204114> #<DTP-INSTANCE 7713320>
3263522 #<DTP-FEF-POINTER TV:SHEET-GET-LOCK 11573005>[47] #<DTP-INSTANCE 3204114>
3263375 #<DTP-FEF-POINTER TV:SHEET-EXPOSE 11602526>[154] (:EXPOSE T) #<DTP-FEF-POINTER (:INTERNAL (:METHOD TV:PEEK-WINDOW :COMBINED :EXPOSE) 0) 17012361>
3263365 #<DTP-FEF-POINTER (:METHOD TV:PEEK-WINDOW :COMBINED :EXPOSE) 17012341>[37] :EXPOSE T
3263355 #<DTP-FEF-POINTER (:METHOD TV:SELECT-MIXIN :BEFORE :SELECT) 11624014>[66] :SELECT
3263301 #<DTP-FEF-POINTER (:METHOD TV:PEEK-WINDOW :COMBINED :SELECT) 17012211>[206] :SELECT
3263266 #<DTP-FEF-POINTER (:METHOD TV:PEEK-FRAME :COMBINED :SELECT) 17012055>[120] :SELECT
3263260 #<DTP-FEF-POINTER (:METHOD TV:ESSENTIAL-WINDOW :MOUSE-SELECT) 11622554>[33] :MOUSE-SELECT
3263251 #<DTP-FEF-POINTER (:METHOD TV:BASIC-FRAME :COMBINED :MOUSE-SELECT) 16752415>[50] :MOUSE-SELECT
3263166 #<DTP-FEF-POINTER TV:KBD-SYS-1 30441241>[513] 120
3263130 #<DTP-FEF-POINTER SYSTEM-INTERNALS:PROCESS-RUN-FUNCTION-INTERNAL 2435434>[100] NIL #<DTP-FEF-POINTER TV:KBD-SYS-1 30441241> (120)
3263027 #<DTP-FEF-POINTER SYSTEM-INTERNALS:PROCESS-TOP-LEVEL 30457635>[246] NIL

Here are results of running some tests on CADR18:

;Reading at top level in Lisp Listener 1.
;Now using traditional syntax and semantics and base 8 in package USER.

(cc:cc-test-machine)
For best results, ground -TPTSE, 1C07-09 on CMEM boards...

Running Data paths test                 [CC-TEST-DATA-PATHS]
    [Running CC-TEST-IR-DP.]
    [Running CC-TEST-PC-DP.]
    [Running CC-TEST-MD-DP.]
    [Running CC-TEST-VMA-DP.]
    [Running CC-TEST-M-MEM-DP.]
    [Running CC-TEST-A-MEM-DP.]
    [Running CC-TEST-PP-DP.]
    [Running CC-TEST-PI-DP.]
    [Running CC-TEST-PDL-DP.]
    [Running CC-TEST-Q-DP.]
    [Running CC-TEST-C-MEM-DP.]
    [Running CC-TEST-LC-DP.]
    [Running CC-TEST-A-PASS-DP.]
    [Running CC-TEST-M-PASS-DP.]
    [Running CC-TEST-ALU-SHIFT-LEFT-DP.]
    [Running CC-TEST-ALU-SHIFT-RIGHT-DP.]
    [Running CC-TEST-UNIBUS-MAP-DP.]
    [Running CC-TEST-BUSINT-BUFFERS-DP.]

Running Fast address test               [CC-FAST-ADDRESS-TESTS]
    [Fast address test M-MEM]
    [Fast address test A-MEM]
    [Fast address test PDL-BUFFER]
    [Fast address test C-MEM]
    [Fast address test D-MEM]
    [Fast address test SPC]
    [Fast address test LEVEL-1-MAP]
    [Fast address test LEVEL-2-MAP]
    [Fast address test UNIBUS-MAP]

Running C-MEM Banks Fast Address test   [CC-FAST-ADDRESS-TEST-C-MEM-BANKS]

Running SPC Pointer test                [CC-TEST-SPC-POINTER]

Running Shifter logic test              [CC-TEST-SHIFTER-LOGIC]


LC failed to increment properly good 2000000, bad 77777777
LC failed to increment properly good 4000000, bad 2000002
LC failed to increment properly good 10000000, bad 77777777
LC failed to increment properly good 20000000, bad 10000002
LC failed to increment properly good 40000000, bad 77777777

Running OA Registers test               [CC-TEST-OA-REGS]
    OA-REG-LOW failure: IR-BIT is 2, M-BIT is 0 I has 1 in bit 1, OB0-1520-22272931

Running Dispatch test                   [CC-TEST-DISPATCH]

Running Clock test                      [CC-TEST-CLOCK]
  0	No	5D08-6	  243	  235
  1	No	5D08-3	  187	  180
  2	No	5D08-16	  187	  180
  3	No	5D08-14	  161	  160
  0	Yes	5D08-5	  243	  235
  1	Yes	5D08-4	  222	  220
  2	Yes	5D08-17	  205	  210
  3	Yes	5D08-15	  195	  200

Also, scope clock at 5A10-11; width of low phase should be about 75 ns

    Note that the standard cycle-time (5D08-16) has been increased to
    180ns from 170ns for greater reliability.

NIL
(cc:cc-run-mtest)
Main memory 768K
 Memory board 0
  Bank 0
  Bank 1
  Bank 2
  Bank 3
 Memory board 1
  Bank 0
  Bank 1
  Bank 2
  Bank 3
 Memory board 2
  Bank 0
  Bank 1
  Bank 2
  Bank 3
 Memory board 3
  Bank 0
  Bank 1
  Bank 2
  Bank 3
 Memory board 4
  Bank 0
  Bank 1
  Bank 2
  Bank 3
 Memory board 5
  Bank 0
  Bank 1
  Bank 2
  Bank 3
 Memory board 6
  Bank 0
  Bank 1
  Bank 2
  Bank 3
 Memory board 7
  Bank 0
  Bank 1
  Bank 2
  Bank 3
 Memory board 8
  Bank 0
  Bank 1
  Bank 2
  Bank 3
 Memory board 9
  Bank 0
  Bank 1
  Bank 2
  Bank 3
 Memory board 10
  Bank 0
  Bank 1
  Bank 2
  Bank 3
 Memory board 11
  Bank 0
  Bank 1
  Bank 2
  Bank 3
Level 1 map loaded for the low 256K addresses.
Level 2 map loaded.
Test 0 OK
Test 1 OK
Test 2 OK
Test 3 OK
Test 4 OK
;Back to top level in Lisp Listener 1.

The tests were succeeding when I decided to abort them.

Who is doing Lisp Machine hardware now, anyway ?
13-Jul-84 16:47:29-EDT,304;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 13 Jul 84 16:46-EDT
From: GSB@MIT-ML
Date: 07/13/84 16:43:10

GSB@MIT-ML 07/13/84 16:43:10
To: (BUG HARDWARE) at MIT-ML
Corwin is no longer talking to chaosnet.  This sometime between the time
mc was fixed and late thursday night;  not sure exactly.
13-Jul-84 19:39:34-EDT,522;000000000000
Received: from MIT-LISPM-27 by MIT-OZ via Chaosnet; 13 Jul 84 19:39-EDT
Date: Friday, 13 July 1984, 19:41-EDT
From: Kim A. Barrett <kab at MIT-OZ>
To: BUG-Hardware at MIT-OZ

In Hardware in System 98.67, CADR 3.8, ZMail 53.18, MIT-Specific 22.2,
Experimental Local-File 48.5, Experimental FILE-Server 8.5,
Experimental LFS 3.3, Experimental MagTape 22.6, microcode 309, XFS/C,
on Lisp Machine Filecomputer:

Cadr-2 just broke...  it was running fine, then stopped, and refused to
boot (or even begin to boot).
16-Jul-84 10:31:35-EDT,306;000000000000
Mail-From: DAVIS created at 16-Jul-84 10:31:19
Date: Mon 16 Jul 84 10:31-EDT
From: Randall Davis <DAVIS@MIT-OZ>
Subject: chaos?
To: bug-hardware@MIT-OZ


My terminal concentrator connection seems to be non-functional. Is
this local or part of a larger problem?  What's the prognosis in
any case?
16-Jul-84 10:58:52-EDT,462;000000000000
Mail-From: OAF created at 16-Jul-84 10:57:11
Date: Mon, 16 Jul 1984  10:57 EDT
Message-ID: <OAF.12031786490.BABYL@MIT-OZ>
From: OAF@MIT-OZ
To:   Randall Davis <DAVIS@MIT-OZ>
Cc:   bug-hardware@MIT-OZ, boris@MIT-OZ
Subject: concentrator notmakingittoyouroffice
In-reply-to: Msg of 16 Jul 1984  10:31-EDT from Randall Davis <DAVIS>

Huh?  Who?  What?

Oh.  Well, lessee what the  problem is.  Seems both you and Boris are
losing this morning.

Oded
17-Jul-84 09:42:32-EDT,336;000000000000
Received: from MIT-LISPM-2 by MIT-OZ via Chaosnet; 17 Jul 84 09:42-EDT
Date: Tuesday, 17 July 1984, 09:42-EDT
From: Robert P. Krajewski <RpK at MIT-OZ>
Subject: CADR4 is really dead
To: BUG-Hardware at MIT-OZ
Message-ID: <[MIT-LISPM-2].7/17/84 09:42:52.RpK>

It won't boot from the keyboard.

Just thought you'd like to know.
18-Jul-84 12:15:07-EDT,353;000000000000
Received: from MIT-HERMES by MIT-OZ via Chaosnet; 18 Jul 84 12:14-EDT
Received: by mit-hermes id AA00539; Wed, 18 Jul 84 12:14:38 edt
Date: Wed, 18 Jul 84 12:14:38 edt
From: David M. Siegel <dms@mit-hermes>
To: bug-hardware@oz
Subject: 9a-hub

9A-HUB does not seem to talk to oz and various other machines.
It boots up over the net ok, though.
19-Jul-84 21:06:18-EDT,1071;000000000000
Mail-From: MARTY created at 19-Jul-84 21:02:03
Date: 19 Jul 1984  21:02 EDT (Thu)
Message-ID: <MARTY.12032683035.BABYL@MIT-OZ>
From: Martin David Connor <MARTY@MIT-OZ>
To:   System@MIT-OZ, 8AI@MIT-OZ
Cc:   Bug-Hardware@MIT-OZ, Bug-Minits@MIT-OZ
Subject: 8th floor terminals connected to NE43-9A-HUB


The ninth floor terminal concentrator died, and since I didn't know
how to fix them really, but since lots of people asked me about it, I
did the following things to get back the ports.

PDH and I got the old 3B concentrator working (it is full of plaster
dust from 3rd floor construction).  We then plugged every spare
terminal line we saw into 3B.

9A is still broken, but a port is a port, so this should do for now.
All ports were set to be AAA's by the way.

If anyone who knows how wants to try and fix 9A, I have spares.

So anyway, sorry for the inconvenience, even sorrier I couldn't fix
the damn thing.  Oh well, maybe hack at it tomorrow or something...
Somebody who knows how should really find me and hack it.
oh well.

'nite.

21-Jul-84 12:22:22-EDT,1141;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 21 Jul 84 12:22-EDT
Date: 21 July 1984 12:22-EDT
From: Oded Anoaf Feingold <OAF @ MIT-MC>
Subject:  NO, damn it, Vulcan's tape drive is NOT broken!
To: CENT @ MIT-MC
cc: GSB @ MIT-MC, BUG-HARDWARE @ MIT-MC, SUNDAR @ MIT-MC
In-reply-to: Msg of 07/21/84 04:17:19 from CENT

The goddam VMS is broken!  The error with the tape drive was a loose
connector.  That has been fixed and SUNDAR made a niltape successfully
on it.  The present problem is strictly VMS's fault.  There has been
a similar idiocy with the printer:  It wakes up trying to run some process,
craps out and hangs, and will not release the printer to anybody.
Power-cycling did not help, and that tells me that nothing I know how to do
from the keyboard WILL help.

I know exactly nothing about repairing VMS software.  Please God and
the dogs of AI, for which I supposedly work, I shall never learn.
This is a DEC operating system, we have a service contract, let them
send out someone to fix it.  If we ran UNIX on that crock I would 
happily fuck with it.  We don't, I can't, I won't.

Phhhhhhhht!

Oded
28-Jul-84 19:12:55-EDT,461;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 28 Jul 84 19:12-EDT
Date: 28 July 1984 05:32-EDT
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: oops!
To: BUG-HARDWARE @ MIT-MC

i think i fucked up the net. i was going over to look at the MC console,
and brushed against the transceiver nest on the square pillar there.
since then, response has been an order of magnitude or two worse, and
MC won't talk to OZ. someone qualified should look into this.
 6-Aug-84 20:46:32-EDT,907;000000000000
Mail-From: JOHANN created at  6-Aug-84 20:45:48
Date: Mon 6 Aug 84 20:45-EDT
From: John Amuedo <JOHANN@MIT-OZ>
Subject: Ambassador in 701
To: bug-hardware@MIT-OZ


The Ambassador in my office repeatedly dies.  I do not
know whether this is the result of a network-related
problem, or the fault of my terminal.  Over the last
six months that terminal has been inoperable for at
least half of the time.  This is my second note to
BUG-HARDWARE about this problem.  Please tell me what
I need to do to fix this problem.

Mike Riley and I have been sharing this terminal.  We
would like to install a second Ambassador in 701, given
the unreliability of the existing device.  To whom
should I submit a request to have a second terminal
installed in that room?  Who will know whether the Lab
has an extra Ambassador already in stock, or do I need
to order one?

Thanks much,
John Amuedo

22-Aug-84 10:03:34-EDT,1039;000000000000
Received: from SCRC-QUABBIN by MIT-OZ via Chaosnet; 22 Aug 84 10:03-EDT
Received: from SCRC-NEPONSET by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 74116; Wed 22-Aug-84 10:01:40-EDT
Date: Wednesday, 22 August 1984, 10:02-EDT
From: David C. Plummer in disguise <DCP at SCRC-TENEX>
Subject: Keith Moon display problems
To: Joseph Lee Jones <JLJ at MIT-OZ>, Bug-hardware at MIT-OZ
cc: BUG-LISPM at MIT-OZ
In-Reply-To: The message of 21 Aug 84 15:56-EDT from Joseph Lee Jones <JLJ at MIT-OZ>
Message-ID: <840822100211.3.NFEP@NEPONSET.SCRC.Symbolics>

    Date: Tuesday, 21 August 1984, 15:56-EDT
    From: Joseph Lee Jones <JLJ at MIT-OZ>

    In Release 5.1, Experimental MIT 1.4, FEP 18, on Lisp Machine Keith Moon (3600):

    The display on Keith Moon had gotten falkey.  If you bump or lean on the console
    the screen goes blank until bumped or leaned on in just the right way again.

Please send hardware problems to bug-hardware (or other qualified
mailing lists) and keep bug-lispm for software problems.  Thanks.
22-Aug-84 22:25:02-EDT,502;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 22 Aug 84 22:24-EDT
Date: Wednesday, 22 August 1984, 22:22-EDT
From:  <SAUND at MIT-OZ>
Subject: bing-crosby
To: bug-hardware at MIT-OZ


Symbolics 3600  BING-CROSBY in the 8th floor playroom has halted
irretrievably twice in the past two days.  Tonight it could be
warm booted the first time it halted, but wouldn't warm boot the
second time.
I left it in the fep where   "show status"  prints out some program
counter values.
  -Eric Saund
31-Aug-84 16:49:38-EDT,522;000000000000
Mail-From: BUCKLEY created at 31-Aug-84 16:49:16
Date: Fri, 31 Aug 1984  16:49 EDT
Message-ID: <BUCKLEY.12043909211.BABYL@MIT-OZ>
From: BUCKLEY@MIT-OZ
To:   bug-hardware@MIT-OZ
cc:   buckley@MIT-OZ, marty@MIT-OZ, oaf@MIT-OZ

I think that there is some hardware lossage on 7A-HUB. Every once in a 
while one of my Emacs commands goes out to lunch for as much as a minute.
I can't believe that this is due to load on OZ. The OZ load factor
today was about 6 when the most recent offense was perpetrated.

Steve
 4-Sep-84 21:16:12-EDT,1012;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 4 Sep 84 21:15-EDT
Date: 4 September 1984 21:14-EDT
From: Jonathan D. Taft <TAFT @ MIT-MC>
Subject:  cadr-4 serial i/o
To: CFRY @ MIT-OZ
cc: BUG-HARDWARE @ MIT-MC, bug-music @ MIT-OZ, SAURON @ MIT-OZ,
    SAZ @ MIT-OZ

    Date: Tuesday, 4 September 1984, 20:34-EDT
    From: <CFRY at MIT-OZ>

        Date: Mon, 3 Sep 1984  22:56 EDT
        From: SAZ@MIT-OZ

        Jon Taft says that ... cadrs ...

     Could somebody ...
                    ... who can make the necessary mods?

There is no one responsible, willing, or available for maintaining
or working on CADR hardware anymore.  I am unwilling to field further
requests for such assistance.  Those that wish to use CADR's had better
become competent at understanding, maintaining, and modifying the
hardware as needed.  

p.s.:  I still occasionally use and maintain Cadr-8.  It has a serial
       port.  It wants it's serial port.  Please do not touch this
       machine.

18-Sep-84 10:04:04-EDT,431;000000000000
Mail-From: RICH created at 18-Sep-84 10:02:49
Date: 18 Sep 1984  10:02 EDT (Tue)
Message-ID: <RICH.12048553813.BABYL@MIT-OZ>
From: Charles Rich <RICH@MIT-OZ>
To:   bug-hardware@MIT-OZ
Subject: Dead Cadrs
CC:   DSD@MIT-OZ

FYI, There are two dead Cadr's in 800A.  One of them is Cadr18
and was working before it was moved from over the wall,
so it probably just needs re-hooking up.  The other is
unknown to me.
			-CR
18-Sep-84 20:34:19-EDT,682;000000000000
Mail-From: LCS.NHM created at 18-Sep-84 20:32:44
Date: Tue 18 Sep 84 20:32:43-EDT
From: LCS.NHM@MIT-OZ
Subject: CADR-19 needs to be fixed
To: bug-hardware@MIT-OZ
cc: nhm@MIT-XX

CADR-19 has been dead all summer, and we would very much like to get
it working again.  I don't think there's very much wrong with it, but
its been something of a nightmare trying to get anyone to fix it.  Is
there some chance that you would have time to look at it soon?

If there are any further impediments which stand in the way of getting
CADR-19 fixed, please let me know so I can try to do something about
them.  Thanks.

                           --- Norm Margolus


-------
19-Sep-84 18:13:22-EDT,871;000000000000
Mail-From: MARTY created at 19-Sep-84 18:13:02
Date: 19 Sep 1984  18:13 EDT (Wed)
Message-ID: <MARTY.12048905196.BABYL@MIT-OZ>
From: Martin David Connor <MARTY@MIT-OZ>
To:   Chaos-maint@MIT-MC, Bug-Hardware@MIT-OZ, Bug-Lispm-MIT@MIT-OZ
Subject: Subnet 6 lossage


I have removed TOTO and CADR27 from subnet 6.  It is getting flooded
with packets which seem to be coming from the file computer (CADR27).
To reporducibly destroy the subnet, go over to CADR27 and get a peek
window and click left on "HOSTAT".  The machine will wedge, and the
subnet will wedge as it sends endless packets.  You can try
warm-booting, but that doesn't always help.

In short, someone should look at CADR27.  I took TOTO off of 6 because
it cannot afford to crash with 45/60  users on NVTs.

I hope someone who is good at this sort of debugging will look closer
into it.

21-Sep-84 11:58:30-EDT,372;000000000000
Mail-From: AKR created at 21-Sep-84 11:57:54
Date: Fri, 21 Sep 1984  11:57 EDT
Message-ID: <AKR.12049361194.BABYL@MIT-OZ>
From: AKR@MIT-OZ
To:   bug-hardware@MIT-OZ
Cc:   net-hackers@MIT-OZ
Subject: subnet 6


I took cadr-25's transceiver of the chaos net yesterday evening.
It was wedging subnet 6.  It seems like subnet 6 is back to a
less broken state???

26-Sep-84 13:08:03-EDT,214;000000000000
Mail-From: JMH created at 26-Sep-84 13:06:06
Date: Wed 26 Sep 84 13:06:06-EDT
From: JMH@MIT-OZ
Subject: Broken cadrs
To: bug-hardware@MIT-OZ

Outside Poggio's office and also across from my office.
-------
 1-Oct-84 17:57:59-EDT,2029;000000000000
Mail-From: JOHANN created at  1-Oct-84 17:57:19
Date: Mon 1 Oct 84 17:57-EDT
From: John Amuedo <JOHANN@MIT-OZ>
Subject: CADR's 4, 9 and 15
To: bug-hardware@MIT-OZ


It has become increasingly difficult for the people
working on speech and music-related things to make
progress with these machines out of commission, or
unusable for their original purpose.  Mike Riley,
Jim Davis, David Saslav and myself presently rely
on CADR's for our research, primarily because these
machines are capable of supporting the specialized
hardware that we own for such purposes (e.g., FPS
box and CHROMA's).  Until a graceful transition of
this hardware to 3600's can be made, I would like
to request the following:

  1. A working CADR be designated for connection
  to the workstation outside 702, for use with
  one CHROMA.  For reasons of minimizing cable
  length, this CADR need reside in the adjacent
  7th floor machine room.

  2. A working CADR (or CADR-9, if operational)
  be designated for reconnection to the FPS
  array processor to support a SPIRE workstation,
  as originally intended.  CADR-9's console seems
  to have evaporated from the "hammock alcove".

  3.A working CADR be designated for connection
  to the workstation in 702, for use with the
  CHROMA that is situated there.  This will
  require relocating the console attached to the
  present "namespace server".  Also for reasons
  of cable length, it is desirable that this
  machine reside in the 7th floor machine room.

Please let me know exactly what obstacles lie in
the path of restoring these machines to their
original working state.  I am making separate
provision to have the special hardware involved
moved onto 3600's, but this will likely not be
possible until June.

Sorry about the impersonal nature of this note.  I
don't know who is worrying about CADR maintenance
these days, so I don't know to whom this flame
should be addressed.  Please excuse the formality.

Thanks a lot,

John Amuedo

 2-Oct-84 02:53:47-EDT,1579;000000000000
Mail-From: RMS created at  2-Oct-84 02:53:31
Date: Tue 2 Oct 84 02:53:31-EDT
From: RMS@MIT-OZ
Subject: Amuedo
To: bug-hardware@MIT-OZ

To the LMI CADR repair cadre: you should know that

1) there is no reason why the music people ought to have any sort of
privileged access to any CADRs.  Not only in my opinion (since I do
not recognize such privileges), but according to the "official"
lab philosophy, whose criteria Amuedo does not meet.

2) his request seems to be an attempt to sneak past everyone
a demand for such privileges.

3) Amuedo has adopted a strong pro-slime bias which he professes even
to the point of pressuring other people he works with against use of
MIT software, even threatening to fire them.  When he discusses this
subject he takes a totally amoral attitude of cold realpolitik.
Even those things he is asking for which are not outrageous in
themselves (such as to put the machines he wants to use higher on the
queue) are still special favors, and his position makes him less
deserving than average of any favors from you.

4) The original working state of the machines in question is not
the same as the state he is requesting.

Conclusion:
You should not give Amuedo any special consideration.  There is no
particular reason to set up CADRs as or where he is asking; and if
CADRs happen to be set up in those ways, they are still not "designated"
for him or for the uses he makes of them.

Note:
I am sending this to bug-hardware because I believe that justice
should be seen to be done, not just done.
-------
 3-Oct-84 19:00:20-EDT,826;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 3 Oct 84 18:59-EDT
Date: 3 October 1984 18:30-EDT
From: Glenn S. Burke <GSB @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC
cc: bug-vms @ SCRC-STONY-BROOK

I suspect that corwin may have a flakey chaos transceiver.  Every once
in a while, the machine hangs up;  the few times i've been able to do
enough to see anything at all, it was spending over 50% of its time on
the interrupt stack;  the chaosnet_ncp process accumulates some runtime,
but (i don't think) it's enough to account for how slow the machine gets.
Everything is always fine if there is no chaosnet_ncp process.

I don't think this is a software problem because it has never been documented
to occur on oberon, and did not on corwin until a few weeks ago.

[bug-vms:  seen this before?  know what causes it?]
 3-Oct-84 21:11:41-EDT,817;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 3 Oct 84 21:11-EDT
Received: from SCRC-YAMASKA by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 88179; Wed 3-Oct-84 20:02:52-EDT
Date: Wed, 3 Oct 84 20:02 EDT
From: "Mark A. Bell" <mbell@SCRC-QUABBIN.ARPA>
Subject: Corwin problems
To: GSB@MIT-MC.ARPA, BUG-HARDWARE@MIT-MC.ARPA
cc: bug-vms@SCRC-STONY-BROOK.ARPA
In-Reply-To: The message of 3 Oct 84 18:30-EDT from Glenn S. Burke <GSB at MIT-MC>
Message-ID: <841003200224.4.MBELL@YAMASKA.SCRC.Symbolics>

    Date: 3 October 1984 18:30-EDT
    From: Glenn S. Burke <GSB @ MIT-MC>

    I suspect that corwin may have a flakey chaos transceiver. 
	...
    [bug-vms:  seen this before?  know what causes it?]

MRL reported finding and fixing some bug in the PCDRIVER recently, but
he never sent us any details.
 4-Oct-84 15:53:51-EDT,383;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 4 Oct 84 15:48-EDT
Date: 4 October 1984 15:45-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  [RKU: forwarded]
To: BUG-HARDWARE @ MIT-MC

Date: 4 October 1984 14:37-EDT
From: Robert Kunstaetter <RKU>
To:   BUG-VT52

October 4, 1984

Please repair the terminal in room 373.

Thanks for your help.

         ...../Robert.
 9-Oct-84 01:54:47-EDT,391;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 9 Oct 84 01:54-EDT
Date: 9 October 1984 01:52-EDT
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: [RKU: forwarded -- bug-vt52]
To: RKU @ MIT-MC
cc: BUG-HARDWARE @ MIT-MC, BUG-RANDOM-PROGRAM @ MIT-MC

actually, LCS terminal complaints should be sent to VT52 (@ mc).
This has been this way for years and years.  I forwarded the
message on.
15-Oct-84 16:04:53-EDT,179;000000000000
Mail-From: MJB created at 15-Oct-84 15:47:46
Date: Mon 15 Oct 84 15:47-EDT
From: Mike J. Brooks <MJB@MIT-OZ>
To: bug-cadr@MIT-OZ

Cadr 32 seems to be sick, can anyone help?
18-Oct-84 13:50:59-EDT,210;000000000000
Mail-From: BKPH created at 18-Oct-84 13:48:21
Date: Thu, 18 Oct 1984  13:48 EDT
Message-ID: <BKPH.12056459189.BABYL@MIT-OZ>
From: BKPH@MIT-OZ
To:   bug-cadr@MIT-OZ


HI: CADR32 IS SICK.  PLEASE HELP.

22-Oct-84 13:57:43-EDT,488;000000000000
Received: from MIT-LISPM-31 by MIT-OZ via Chaosnet; 22 Oct 84 13:57-EDT
Date: Monday, 22 October 1984, 13:59-EDT
From: Robert P. Krajewski <RpK at MIT-OZ>
Subject: CADR control memory
To: BUG-Hardware at MIT-OZ
CC: RMS at MIT-OZ, MLY at MIT-OZ
Message-ID: <[MIT-LISPM-31].10/22/84 13:59:08.RpK>

Could the CADR maintenance entity, if there is such a thing, please be
informed that CADRs 4 and 31 do not have all their control memory ?
They need it to run system 99.

``Bob''
29-Oct-84 23:36:50-EST,293;000000000000
Received: from MIT-LISPM-4 by MIT-OZ via Chaosnet; 29 Oct 84 23:35-EST
Date: Monday, 29 October 1984, 23:38-EST
From: Richard M. Stallman <RMS at MIT-OZ>
To: bug-cadr at MIT-OZ

CADR31's memory is having severe trouble.  It thinks it has 208 k.
Yes, 208, which is not a multiple of 64.
30-Oct-84 09:54:42-EST,767;000000000000
Received: from MIT-AVATAR by MIT-OZ via Chaosnet; 30 Oct 84 09:53-EST
Date: Tuesday, 30 October 1984, 09:56-EST
From: Charles Rich <RICH at MIT-OZ>
Subject: Avatar
To: BUG-mit-hardware at MIT-OZ
Cc: Dick at MIT-OZ, Kmp at MIT-OZ

In Release 4.5, site configuration 61, Vanilla, on PA Lisp Machine Avatar:

In trying to recompile the Cake System, Avatar keeps freezing
at seemingly random points in the compilation and requires being
warm booted.  This has happened three times, and each time the
PC is at location 22564 (as observed from the LED's on the backplane).
Does this number suggest anything?  Is this likely to be a hardware
or a software problem?   Any idea when someone with the requisite
knowledge can look into this?

		Thanks, Chuck.
30-Oct-84 10:19:55-EST,985;000000000000
Mail-From: KMP created at 30-Oct-84 10:18:10
Date: Tue 30 Oct 84 10:18:07-EST
From: Kent M Pitman <KMP@MIT-OZ>
Subject: Re: Avatar
To: RICH@MIT-OZ
cc: BUG-mit-hardware@MIT-OZ, Dick@MIT-OZ, jtw@MIT-OZ, dph@MIT-OZ
In-Reply-To: Message from "Charles Rich <RICH at MIT-OZ>" of Tue 30 Oct 84 09:54:46-EST

My impression was that this is the symptom of some sort of network
problems. Avatar has had this same erratic behavior for many weeks now.
(To clarify, since we run Rel4.5, I mean real problems in Chaosnet itself,
not software problems such as the Rel5 network lossage. Perhaps some machine
is pestering Avatar incessantly or perhaps there is spurious noise on the
cable near Avatar or some such? I'm cc'ing this to some network people who
might be able to comment in a more informed way; I'm just guessing randomly)
-kmp

ps. i'll forward original message to those who didn't see it
    so if this seems out of context, check for an accompanying message.
-------
 2-Nov-84 02:13:18-EST,370;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 2 Nov 84 02:12-EST
Date: Friday, 2 November 1984, 02:15-EST
From: Howard D. Trachtman <Hdt at MIT-MC>
To: bug-hardware at MIT-MC

mit-lispm-27 doesn't seem to being talking over the chaos net at all.
according to this lispm however, it has pkt-forwarded 70K, pkt-over forwarded 3966, but
PKTS-BAD-CRC-1 were 612931.
 2-Nov-84 10:54:55-EST,1121;000000000000
Mail-From: RICH created at  2-Nov-84 10:54:31
Date: 2 Nov 1984  10:54 EST (Fri)
Message-ID: <RICH.12060370626.BABYL@MIT-OZ>
From: Charles Rich <RICH@MIT-OZ>
To:   BUG-HARDWARE@MIT-OZ
CC:   Custer@MIT-OZ, DICK@MIT-OZ, KMP@MIT-OZ
Subject: cadr22
In-reply-to: Msg of 1 Nov 1984  14:38-EST from David R. Custer <CUSTER>

David - I really would appreciate your looking at Cadr22.  I do not
think it is very likely to be a software (e.g. compiler) problem as it
dies at totally different places (i.e. different files) each time, but
always at the same PC location.  It may indeed be something of a
hardware nature that has to do with the network interface, as it is
reading files when it dies, or it may be some other hardware-related
problem.  As to KMP's message, we appreciate his sharing his hunch
with us, but this should not cause the problem not to be looking at by
people who know the Cadr hardware better.

Anyways, I have left the machine in its stuck state for you to look
at, and the error is easily reproducible.  Can we schedule a time
soon for it to get some attention?

		Thanks, Chuck.
 2-Nov-84 15:43:21-EST,350;000000000001
Mail-From: AAB created at  2-Nov-84 15:42:59
Date: Fri 2 Nov 84 15:42:59-EST
From: Andrew A. Berlin <AAB@MIT-OZ>
Subject: broken cadrs
To: bug-hardware@MIT-OZ


Cadr 2 died.  i.e., it's clock stopped and it refuses to cold boot.

Cadr 8 refuses to recognize the pressing of mouse buttons (I tried
3 different mice).

Foo.
Andy
-------
 2-Nov-84 20:35:41-EST,260;000000000000
Mail-From: AAB created at  2-Nov-84 20:35:22
Date: Fri 2 Nov 84 20:35:22-EST
From: Andrew A. Berlin <AAB@MIT-OZ>
Subject: cadr8 works
To: bug-hardware@MIT-OZ


Mice now work on cadr8.  Previous problem was probably a bug
in daedalus.

Andy
-------
 3-Nov-84 01:09:03-EST,253;000000000001
Received: from MIT-LISPM-4 by MIT-OZ via Chaosnet; 3 Nov 84 01:08-EST
Date: Saturday, 3 November 1984, 01:11-EST
From: Richard M. Stallman <RMS at MIT-OZ>
To: bug-cadr at MIT-OZ

CADR 31 seems to be having serious disk trouble.  It will not boot.
 5-Nov-84 04:40:18-EST,288;000000000001
Received: from MIT-MC by MIT-OZ via Chaosnet; 5 Nov 84 04:39-EST
Date: 5 November 1984 04:42-EST
From: Ronald D. Mabbitt <RDM @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC

Sigh.  The VT52 by the MC console seems to be down.  Someone should
probably look at it -- I'm too tired.        -rdm
 7-Nov-84 10:58:52-EST,447;000000000000
Mail-From: RICH created at  7-Nov-84 10:58:14
Date: 7 Nov 1984  10:58 EST (Wed)
Message-ID: <RICH.12061682023.BABYL@MIT-OZ>
From: Charles Rich <RICH@MIT-OZ>
To:   bug-system@MIT-OZ
CC:   Bug-Hardware@MIT-OZ
Subject: Chaos Net to Cadr22

Cadr22 is unable to get the time when it boots.  I suspect
this is a problem with the part of the Chaos net (Subnet 6?)
to which it is attached.  Is this problem known and under
repair????  -Chuck.
 7-Nov-84 14:41:36-EST,354;000000000000
Mail-From: KHC created at  7-Nov-84 14:40:21
Date: Wed 7 Nov 84 14:40:21-EST
From: Katie Cornog <KHC@MIT-OZ>
Subject: cadr-3 and chaos net
To: bug-hardware@MIT-OZ

I can't save any files off of cadr-3 because it seems something with the chaos
net isn't working. Is there any chance of getting this fixed in the 
not too distant future?
-------
 7-Nov-84 21:11:35-EST,371;000000000000
Mail-From: CUSTER created at  7-Nov-84 21:10:57
Date: Wed, 7 Nov 1984  21:10 EST
Message-ID: <CUSTER.12061793565.BABYL@MIT-OZ>
From: CUSTER@MIT-OZ
To:   Katie Cornog <KHC@MIT-OZ>
Cc:   bug-hardware@MIT-OZ
Subject: cadr-3 and chaos net
In-reply-to: Msg of 7 Nov 1984  14:40-EST from Katie Cornog <KHC>

Try sending bug reports to CHAOS-MAINT for choas problems.
 9-Nov-84 09:31:49-EST,1128;000000000000
Mail-From: RICH created at  9-Nov-84 09:30:44
Date: 9 Nov 1984  09:30 EST (Fri)
Message-ID: <RICH.12062190382.BABYL@MIT-OZ>
From: Charles Rich <RICH@MIT-OZ>
To:   "David R. Custer" <CUSTER@MIT-OZ>
Subject: Cadr22 & Chaos (Net)
CC:   Bug-Hardware@MIT-OZ, Choas-Maint@MIT-OZ, AKR@MIT-OZ, phw@MIT-OZ,
      Dick@MIT-OZ, KMP@MIT-OZ
In-reply-to: Msg of 8 Nov 1984  16:48-EST from David R. Custer <CUSTER>

David,

The chaos net is still broken to Cadr22 (and probably the Cadr
in 939).  I assume you saw GLR's long message about the condition
of subnet 6.  I would obviously like to see the cable fixed to Cadr22
or it moved to another net as soon as possible (it may then turn
out the previously evidenced hardware problem was in fact due
to the net as KMP surmised).

In any case, David, can you take care of getting Cadr22 reconnected to
the world?  I am not sure if this kind of thing was written into the
terms of the LMI service contract.  If not, I have separate funds
available to pay for whatever needs to be done, which I hereby
authorize.

Please let me know what you can do.

		Thanks, Chuck.
12-Nov-84 18:28:10-EST,437;000000000001
Received: from MIT-ROBOT-1 by MIT-OZ via Chaosnet; 12 Nov 84 18:27-EST
Date: Monday, 12 November 1984, 18:30-EST
From:  <HLV at MIT-OZ>
Subject: Wiggling screen
To: BUG-HARDWARE at MIT-OZ
Cc: dms at MIT-OZ

In Symbolics 3600 HARDWARE in System 242.356, Hardcopy 20.10, FEP 18,
This is broken, on Lisp Machine Captain Crunch (formerly Robot-1):

The writing on the screen wiggles horizontally on Captain Crunch,
even in milk.
14-Nov-84 09:40:10-EST,398;000000000001
Mail-From: GLR created at 14-Nov-84 09:39:43
Date: Wed, 14 Nov 1984  09:39 EST
Message-ID: <GLR.12063502739.BABYL@MIT-OZ>
From: Jerry Roylance <GLR@MIT-OZ>
To:   "W. Eric L. Grimson" <WELG@MIT-OZ>
Cc:   taft@MIT-OZ, Bug-Hardware@MIT-OZ
Subject: helping a turkey
In-reply-to: Msg of 14 Nov 1984  07:54-EST from W. Eric L. Grimson <WELG>


Cadr3 is fixed.

Cadr24 and Cadr25 don't boot.
16-Nov-84 15:34:27-EST,549;000000000001
Mail-From: RICH created at 16-Nov-84 15:33:05
Date: 16 Nov 1984  15:33 EST (Fri)
Message-ID: <RICH.12064091353.BABYL@MIT-OZ>
From: Charles Rich <RICH@MIT-OZ>
To:   bug-hardware@MIT-OZ
Subject: [DSD: 9th floor]

Date: Friday, 16 November 1984  14:05-EST
From: David Dickey <DSD>
To:   akr
cc:   dsd, rich
Re:   9th floor

   Your wiring is complete,all you must do is srew on your uhf connector,
        akr,make sure you get all the breaks in the line.there is one behind 
        XX and then are before the last set of tranceivers.
17-Nov-84 19:08:04-EST,575;000000000001
Mail-From: AKR created at 17-Nov-84 19:07:42
Date: Sat, 17 Nov 1984  19:07 EST
Message-ID: <AKR.12064392568.BABYL@MIT-OZ>
From: AKR@MIT-OZ
To:   bug-hardware@MIT-OZ
Subject: chaos, cadrs



System 98 has a microcode bug that wedges the Chaos Net.

Please use systems 94,97 or 99 until someone fixes this bug.

All cadrs on the 8th and 9th floor will run system 99.  On the
7th floor cadr2 and 23 do not have enough control memory to
run system 99.

Cadr2 has all the memory but something does not work on the 4th
bank.  cadr23 does not have enough 2147's.
19-Nov-84 14:56:23-EST,1140;000000000001
Mail-From: RICH created at 19-Nov-84 14:54:13
Date: 19 Nov 1984  14:54 EST (Mon)
Message-ID: <RICH.12064870707.BABYL@MIT-OZ>
From: Charles Rich <RICH@MIT-OZ>
To:   custer@MIT-OZ
CC:   Bug-Hardware@MIT-OZ
Subject: Avatar

Dave -

Thanks to all those responsible for re-laying subnet 6 and thus
reconnecting Avatar to the world.  Unfortunately, the new net
connection has not caused Avatar's halting behavior to go away.  The
symptom is still the same -- it always stops at the same PC location,
but at unpredictable points in what it is running.  Hopefully, now
that the chaosnet is connected to it again, you will be able to
hardware debug it soon.  I will leave it in the halted state for you.
		Thanks, Chuck.

P.S. One experiment I haven't done, yet, but will try this afternoon
is to put it in an infinite do loop and see if it dies.  Currently, I
have been testing it with a Make-System, it tends to halt either
during a compilation or a loading (both of involve i/o).  It
has never run for longer than 5-10 minutes doing this.  You
will be able to tell from the monitor how it got into the
halted state. -CR
21-Nov-84 05:20:39-EST,364;000000000001
Received: from MIT-MC by MIT-OZ via Chaosnet; 21 Nov 84 05:20-EST
Date: 21 November 1984 05:22-EST
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: flames?
To: BUG-HARDWARE @ MIT-MC

there is a strong smell of frying power supply in the lispm corral this
morning. i have not been able to localize it to any particular machine.
this should be looked into.
26-Nov-84 15:12:57-EST,506;000000000001
Received: from MIT-MERLIN by MIT-OZ via Chaosnet; 26 Nov 84 15:11-EST
Date: Monday, 26 November 1984, 15:12-EST
From: Charles Rich <RICH at MIT-OZ>
Subject: Cadr22 (aka Avatar)
To: Custer at MIT-OZ
Cc: Bug-Hardware at MIT-OZ

Dave - are  you out there?  I have received no reply to my
most recent message about fixing Cadr22.  As before, can you
give me a specific promise to look at it at some time in the
near future?  If it is during the day, I will be around to consult.
			-Thanks, Chuck.
26-Nov-84 16:02:07-EST,615;000000000001
Mail-From: KHC created at 26-Nov-84 15:57:15
Date: Mon 26 Nov 84 15:57:15-EST
From: Katie Cornog <KHC@MIT-OZ>
Subject: cadr3
To: bug-hardware@MIT-OZ
cc: khc@MIT-OZ

HELP! Cadr3 has some serious problems.
It often refuses to boot and dies inthe middle of
working (at unpredictable times)
Can you please try to remedy this asap??
If the bug is in a specific system please
let me know what system is ok to use.
I don't think it is strictly a system bug --- probably
a hardware or combined hardware software bug because
it seems to fail regardless of band (different system bands).
Thx, katie
-------
28-Nov-84 17:39:19-EST,1588;000000000001
Mail-From: RICH created at 28-Nov-84 17:38:16
Date: 28 Nov 1984  17:38 EST (Wed)
Message-ID: <RICH.12067259871.BABYL@MIT-OZ>
From: Charles Rich <RICH@MIT-OZ>
To:   custer@MIT-OZ
CC:   Bug-MIT-Hardware@MIT-OZ, Dick@MIT-OZ, KMP@MIT-OZ, RICH@MIT-OZ
Subject: Cadr22

Well, I think I may have gotten to the bottom of things.
It does appear to be a problem with disk.  Whether it is
physical or not, I am still not sure.  Anyways, what I did
is copy the PAGE band from Cadr7 to Cadr22 (they were exactly
the same size), with the thought that this would guarantee
overwriting that sector of the disk with new (parity'ed)
bits.

About half-way through, I got the following error message:

>> Disk Write Error Unit 0, Cyl 80, Surf 0, Sec. 0

Status Header-Compare
       Transfer Aborted

(the address being written to was 25840).

I retried the disk write several times and it kept failing.  The
first several retries, changed the Sec number to 3 and then 4, but
then it stayed at 4. Whether this is actually a damaged disk, or a
formatting problem, I don't know.  Obviously, the first thing
to try is to reformat the disk.  The old disk is on top of
Cadr22's drive.  However, before you do that for us, I want
to double check with Dick and KMP.  I don't think there is anything
there we can't lose, but Dick won't be back until next Monday.
I will send you a message then to confirm.

Meanwhile, I seem to be computing along ok with our backup
disk (glad we invested!).  I will let you know if problems
re-appear, but I hope they won't.

		Thanks, Chuck.
30-Nov-84 13:38:27-EST,409;000000000001
Received: from MIT-AVATAR by MIT-OZ via Chaosnet; 30 Nov 84 13:37-EST
Date: Friday, 30 November 1984, 13:37-EST
From: Charles Rich <RICH at MIT-OZ>
Subject: CADR Monitor
To: bug-hardware at MIT-OZ

The Cadr Monitor for Cadr22 in 800B has a case of the fine jitters
(AC ripple on a power supply?), which is quite sickening after a while.
Can this be looked at and fixed or replaced?
		Thanks, Chuck.
30-Nov-84 16:22:05-EST,522;000000000001
Mail-From: CUSTER created at 30-Nov-84 16:18:39
Date: Fri, 30 Nov 1984  16:18 EST
Message-ID: <CUSTER.12067769667.BABYL@MIT-OZ>
From: CUSTER@MIT-OZ
To:   Charles Rich <RICH@MIT-OZ>
Cc:   bug-hardware@MIT-OZ
Subject: CADR Monitor
In-reply-to: Msg of 30 Nov 1984 13:37-EST from Charles Rich <RICH>

There is a current brick wall in the negotiations for the LMI/MIT cadr 
contract.  Currently, we don't fix anything. 

You might ask LAUREL Simmons: she was the last person who delt with
getting monitors fixed.
 3-Dec-84 20:53:41-EST,403;000000000001
Received: from MIT-ROBOT-4 by MIT-OZ via Chaosnet; 3 Dec 84 20:53-EST
Date: Monday, 3 December 1984, 20:53-EST
From:  <PHILIP at MIT-OZ>
Subject: Monitor on RB4.
To: BUG-HARDWARE at MIT-OZ

In Symbolics 3600 HARDWARE in System 242.356, Hardcopy 20.10, on Lisp Machine Robot-4:

The image on Robot-4's monitor has moved
down to the point where the mouse-documentation
line isn't even visible.
 4-Dec-84 06:17:57-EST,612;000000000001
Received: from MIT-JANIS by MIT-OZ via Chaosnet; 4 Dec 84 06:17-EST
Date: Tuesday, 4 December 1984, 06:17-EST
From: Christopher Fry <cfry at MIT-OZ>
Subject: joplin serial port 1 broken
To: BUG-HARDWARE at MIT-OZ

In Symbolics 3600 HARDWARE in System 242.356, Hardcopy 20.10,
Experimental FB 210.0, FEP 18, on Lisp Machine Janis Joplin:

The serial port 1 appears to be spewing out bits 
continuously, at high speed, without
being asked to.

This port is important for my research.
If a symbolics repair person reads this message, please respond to
me so that I'll know that you at least saw it.
 5-Dec-84 09:37:26-EST,828;000000000001
Mail-From: RICH created at  5-Dec-84 09:36:09
Date: 5 Dec 1984  09:36 EST (Wed)
Message-ID: <RICH.12069007111.BABYL@MIT-OZ>
From: Charles Rich <RICH@MIT-OZ>
CC:   bug-mit-hardware@MIT-OZ, dick@MIT-OZ
TO:   Custer@MIT-OZ
Subject: Bad Disk from Cadr22

Dave -
The bad disk that used to be in Cadr22 and is now sitting
on top of it's disk cabinet can be reformatted now.
I don't personally know how to do this.  Are our relations
with you/LMI good enough to have this done by you or
your minions?  

		Thanks, Chuck.

P.S. Here is the disk diagnostic message

    >> Disk Write Error Unit 0, Cyl 80, Surf 0, Sec. 0

    Status Header-Compare
           Transfer Aborted

    (the address being written to was 25840).

P.P.S. Does reformatting include a check of the entire
disk surface for writability?
 7-Dec-84 14:40:31-EST,463;000000000001
Mail-From: FLECK created at  7-Dec-84 14:39:28
Date: Fri, 7 Dec 1984  14:39 EST
Message-ID: <FLECK.12069586617.BABYL@MIT-OZ>
From: FLECK@MIT-OZ
To:   bug-hardware@MIT-OZ, bug-symbolics-hardware@MIT-OZ


There seem to be a couple fewer mice on the 7th floor of the AI Lab
then there are lisp machines.  I don't know whether this represents a
shortage of CADR mice or 3600 mice, since people tend to swap mice
around when some are missing or broken.  

10-Dec-84 05:19:28-EST,278;000000000001
Mail-From: DCB created at 10-Dec-84 05:19:04
Date: Mon 10 Dec 84 05:19-EST
From: Daniel Brotsky <DCB@MIT-OZ>
Subject: 8C hub can't be booted
To: bug-hardware@MIT-OZ
CC: 8ai@MIT-OZ

maybe this has to do with air-conditioning failure in that
part of the 9th floor?
	dan
11-Dec-84 12:15:30-EST,286;000000000001
Mail-From: KHC created at 11-Dec-84 11:58:24
Date: Tue 11 Dec 84 11:58:24-EST
From: Katie Cornog <KHC@MIT-OZ>
Subject: cadr3
To: bug-hardware@MIT-OZ

Can one of you look at cadr3? It has died again,last Fri.
you can get the key from me, Noble or the key person.
katie
-------
13-Dec-84 23:37:02-EST,1025;000000000001
Received: from MIT-MC by MIT-OZ via Chaosnet; 13 Dec 84 23:36-EST
Date: 13 December 1984 23:17-EST
From: Pandora B. Berman <CENT @ MIT-MC>
Subject: MC crash
To: BUG-HARDWARE @ MIT-MC
cc: JNC @ MIT-MC, ALAN @ MIT-MC

this evening MC was down for a few hours because no one, apparently, wanted
to poke around inside it. it had gotten a BUGHALT, and then frozen when a
circuitbreaker tripped. according to the fault lights, the problem was AIR
FLOW CPU. JNC and I found the correct circuit breaker (on the inside of the
stuff mounted on the door of the second box from the left), and resetting
it provided the correct effect of letting the machine come up again. we
left the door open because it's a bitch to close, also because one of the
fans on the top of that cabinet isn't working. i believe Our Man Lester
knows that fan is a loser and just hasn't gotten around to fixing it.  for
several months. maybe someone can sit on him tomorrow morning and make him
do that?

also, MEM 160-177 is off; izzat ok?
17-Dec-84 15:36:40-EST,977;000000000001
Received: from MIT-MC by MIT-OZ via Chaosnet; 17 Dec 84 15:35-EST
Date: Mon 17 Dec 84 15:31:36-EST
From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
Subject: MH10's
To: bug-hardware@MIT-MC.ARPA
cc: JNC@MIT-XX.ARPA

	Well, the MH10's are sick. Ann says DEC can't localize the problem
(hah-hah, who ever would have guessed). I am trying to localize it with
binary search down through the memories, etc. If the system crashes, please
try and find may, as the MH's may be configured in some wierd and
non-standard way, and it would help if one person had all the info
about the failures.
	I am also going to post (inside the door to MH10 A) the manual
page on the hardware which says what all the swicthes do. It's all pretty
obvious, with the two exceptions that a) on the middle panel, the
"Lower Bound Address" and "Ext/Int 35 Intl" swicthes don't do anything,
and on the top panel, "34 Intl" goes between boxes and "35 Intl"
goes between controllers.
		Noel
-------
26-Dec-84 21:18:04-EST,654;000000000001
Received: from MIT-ROBOT-4 by MIT-OZ via Chaosnet; 26 Dec 84 21:17-EST
Date: Wednesday, 26 December 1984, 21:16-EST
From:  <PHILIP at MIT-OZ>
Subject: Broken FEP board
To: BUG-HARDWARE at MIT-OZ
Cc: philip at MIT-OZ

In Symbolics 3600 HARDWARE in System 242.356, Hardcopy 20.10, on Lisp Machine Robot-4:

Tried to power JIMI up today but kept getting 
  Disk sector n-1 not found 
  and checksum errors from the 3 other main boards.

I decided to swap the FEP board with the one in 
JOPLIN and it solved the problem, at least for JIMI.

The same error messages can now be obtained from
JOPLIN which still contains the broken FEP board.
11-Jan-85 17:10:51-EST,1762;000000000001
Received: from MIT-EECS by MIT-OZ via Chaosnet; 11 Jan 85 17:09-EST
Date: Fri 11 Jan 85 17:10:37-EST
From: S.HDT@MIT-EECS
Subject: [Ed Shaw <ESS@MIT-EECS>: Re: System 99/98 for Ford and Arthur.]
To: bug-hardware@MIT-OZ
cc: hdt@MIT-EECS, ess@MIT-EECS


    Mail-From: ESS created at 11-Jan-85 15:03:55
    Date: Fri 11 Jan 85 15:03:55-EST
    From: Ed Shaw <ESS@MIT-EECS>
    Subject: Re: System 99/98 for Ford and Arthur.
    To: RPK@MIT-OZ, Hdt@MIT-EECS
    cc: BCN@MIT-EECS, Hdt@MIT-MC, ZZZ.RLK@MIT-OZ
    In-Reply-To: Message from ""Robert P. Krajewski" <RPK@MIT-OZ>" of Thu 10 Jan 85 16:35:57-EST

        Well, sure enough, trying to boot system 99 causes a jump to microcode
    location 00000.  We have only 12K of control store, so if UCADR 320 needs
    more, we can't run it.  Maybe we can buy some more chips and plug them in,
    but I can make no promises at the present time.

        Anyone know where there are 48*4 Intel 2141-2 memory chips we can scarf?

    Ed
    -------
                ---------------

Mail-From: ESS created at 11-Jan-85 15:03:55
Date: Fri 11 Jan 85 15:03:55-EST
From: Ed Shaw <ESS@MIT-EECS>
Subject: Re: System 99/98 for Ford and Arthur.
To: RPK@MIT-OZ, Hdt@MIT-EECS
cc: BCN@MIT-EECS, Hdt@MIT-MC, ZZZ.RLK@MIT-OZ
In-Reply-To: Message from ""Robert P. Krajewski" <RPK@MIT-OZ>" of Thu 10 Jan 85 16:35:57-EST

    Well, sure enough, trying to boot system 99 causes a jump to microcode
location 00000.  We have only 12K of control store, so if UCADR 320 needs
more, we can't run it.  Maybe we can buy some more chips and plug them in,
but I can make no promises at the present time.

    Anyone know where there are 48*4 Intel 2141-2 memory chips we can scarf?

Ed
-------
-------
15-Jan-85 16:24:12-EST,1800;000000000001
Mail-From: RICH created at 15-Jan-85 16:20:26
Date: 15 Jan 1985  16:20 EST (Tue)
Message-ID: <RICH.12079828612.BABYL@MIT-OZ>
From: Charles Rich <RICH@MIT-OZ>
To:   bug-hardware@MIT-OZ
CC:   Custer@MIT-OZ, AKR@MIT-OZ, Dick@MIT-OZ, GLR@MIT-OZ, Taft@MIT-OZ, Rich@MIT-OZ
Subject: Advice on Broken Cadr22

TWIMC - Let me first apologize for the wide net of recipients
to this message.  I am not sure who should actually be able
to help fix broken Cadr's (possibly no one), but I am at least
looking for advice from someone.

A pattern of disk errors has developed with Cadr22.  A month
or two ago it would randomly die (requiring cold boot).  The
problem was tracked down to a disk error in the PAGE band.
The error was easily manifest by trying to copy the PAGE
band to itself.  Part way through, the following error occurs,
from which it will not recover.

    >> Disk Write Error Unit 0, Cyl 80, Surf 0, Sec. 0

    Status Header-Compare Transfer Aborted

    (the address being written to was 25840).

On the theory that the disk media was at fault, we switched
to a new disk and had no problems until today.  Today, a similar
phenonemon is happening.  I tried

(DISK-COMPARE 'CADR22 'PAGE 'PAGE)

and lo and behold, the following similar error:

Error: Disk Read-Compare Error Unit 0, Cyl 23, Surf 18, Sec. 4

Status ECC-Soft Transfer Aborted

(the address being written to was 7735).

===> obviously something is wrong and it ain't software.  Can someone
with the requisite experience volunteer to take a look at this?  (It is
very reproducible).  If not, can anyone suggest if it makes sense to
order service on the disk drive (which we can at least get), or is
this clearly something wrong in the Cadr (e.g. the disk controller)?

				Thanks, Chuck.
18-Jan-85 17:41:55-EST,1028;000000000001
Received: from MIT-MC by MIT-OZ via Chaosnet; 18 Jan 85 16:53-EST
Date: 18 January 1985 16:45-EST
From: Jonathan A Rees <JAR @ MIT-MC>
Subject:  AAA in 705
To: OAF @ MIT-MC, BUG-HARDWARE @ MIT-MC

This poor terminal (the AAA in NE43-705) is still not well.  I keep
having to adjust the pot at the far left corner of the horizontal PC
board inside the box.  There's no single setting for the pot which works
properly regardless of whether the terminal is warmed up or not.  I can
usually get it right if I fiddle with it but then if I leave it for a
day or so it gets out of whack again.  I'll try to leave it on and see
if it reaches a stable state, but I don't think that's a good long-term
solution since eventually it will be turned off for one reason or
another, so I'll either have to take the thing apart again at that time
or simply not put it back together (my current solution), neither of
which is convenient.

Could this terminal be swapped for one that works a little better?  Thanks.

Jonathan
21-Jan-85 22:22:43-EST,487;000000000001
Received: from MIT-MC by MIT-OZ via Chaosnet; 21 Jan 85 22:22-EST
Date: Monday, 21 January 1985, 22:01-EST
From: Christopher Fry <cfry at MIT-OZ>
Subject: Audio fails on Sid
To: BUG-HARDWARE at MIT-OZ

In Symbolics 3600 HARDWARE in System 242.356, Hardcopy 20.10,
Experimental FB 225.0, FEP 22, on Lisp Machine Sid Vicious:

A month ago or so the audio worked on Sid.
Now there is no sound when you attempt to use the audio.
No signal comes out of the headphone jack either.
23-Jan-85 10:48:33-EST,1215;000000000001
Mail-From: RICH created at 23-Jan-85 10:48:17
Date: 23 Jan 1985  10:48 EST (Wed)
Message-ID: <RICH.12081865300.BABYL@MIT-OZ>
From: Charles Rich <RICH@MIT-OZ>
To:   bug-hardware@MIT-OZ
Subject: Cadr22 (aka Avatar)
CC:   Custer@MIT-OZ, AKR@MIT-OZ, Rich@MIT-OZ

John Holden gave the T-300 on Cadr22 the complete go-over, and it was
indeed very dirty and out of alignment (boy is he a pro!).  As
predicted, the machine cannot make it through cold boot now, probably
because it cannot read its own old disk pack.  There is nothing on
the currently loaded pack which I need, so it can be reformatted.

In order to reformat, however, I need to use another Cadr through the
debugging cables.  David, are the cables still hooked up from Cadr22
to another machine on the 9th floor?  If so, can you tell me which
one, where it is located, and if I need a key to get to it?
Alternatively, if it is not too much trouble for you, (i.e. the cables
are hooked to a machine you will logged into anyways) can I persuade
you to run the formatting procedure for me?  If you just copy over any
working band, so I can boot, I can take care of the rest using
Edit-Disk-Label from there myself.

			Thanks, Chuck.
24-Jan-85 19:07:15-EST,456;000000000001
Mail-From: KHC created at 24-Jan-85 19:06:54
Date: Thu 24 Jan 85 19:06:54-EST
From: Katie Cornog <KHC@MIT-OZ>
Subject: cadr3
To: bug-hardware@MIT-OZ

hi,
CADR3 appears to be dead.
do any of you know what is wrong?
the console is in rm 901A, which is 
usually locked. People who have keys are
me and Noble and probably some others.

I'd like to use the machine soon
so if it's possible to fix it
I'd appreciate it.

Thanks, Katie
-------
 4-Feb-85 13:49:27-EST,448;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 4 Feb 85 13:49-EST
Date: 4 February 1985 13:47-EST
From: Jonathan A Rees <JAR @ MIT-MC>
Subject:  AAA in 705
To: BUG-HARDWARE @ MIT-MC
cc: KWH @ MIT-MC

Could something be done about this poor terminal?  It went bonkers
again, and turning the pot helped again, but leaving the thing open so
that the pot is always accessible doesn't seem like a good long-term
solution.

Thanks,
Jonathan
 5-Feb-85 07:42:25-EST,378;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 5 Feb 85 07:42-EST
Date: Tue 5 Feb 85 07:40:13-EST
From: Joe Ricchio <RICCHIO@MIT-XX.ARPA>
Subject: Re: AAA in 705
To: JAR@MIT-MC.ARPA, BUG-HARDWARE@MIT-MC.ARPA
cc: KWH@MIT-MC.ARPA, RICCHIO@MIT-XX.ARPA
In-Reply-To: Message from "Jonathan A Rees <JAR @ MIT-MC>" of Mon 4 Feb 85 13:47:00-EST

Check with OAF 3-8598.
-------
11-Feb-85 21:29:50-EST,490;000000000000
Mail-From: AKR created at 11-Feb-85 21:28:58
Date: Mon, 11 Feb 1985  21:28 EST
Message-ID: <AKR.12086962670.BABYL@MIT-OZ>
From: AKR@MIT-OZ
To:   RICH@MIT-MC
Cc:   bug-chaos@MIT-MC, Marty@MIT-MC, bug-hardware@MIT-OZ, JKS@MIT-OZ
Subject: Subnet 6 (what else?)
In-reply-to: Msg of 3 Feb 1985 04:35-EST from RICH at MIT-MC


Golem is guilty.  The chaos net transceiver has been disconnected until someone
figures out what is wrong with Golem.  Subnet 6 appears to be working again.
14-Feb-85 21:08:46-EST,558;000000000000
Received: from MIT-DUANE by MIT-OZ via Chaosnet; 14 Feb 85 21:06-EST
Date: Thursday, 14 February 1985, 00:51-EST
From:  <PHILIP at MIT-OZ>
Subject: Defective CART
To: BUG-HARDWARE at MIT-OZ, BUG-SYMBOLICS-HARDWARE at MIT-OZ,
    MAGNUSON at SCRC-STONY-BROOK
Cc: PHILIP at MIT-OZ

In Symbolics 3600 HARDWARE in System 242.356, Hardcopy 20.10, FEP 22, on Lisp Machine Duane Allman:

The CART drive on ALLMAN doesn't seem to work.
The software just hangs on "Cart Command" while doing (tape:carry-load
...)

As far as I know it has never worked.
15-Feb-85 11:21:57-EST,514;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 15 Feb 85 11:21-EST
Date: 15 February 1985 10:24-EST
From: Gerald Jay Sussman <GJS @ MIT-MC>
To: BUG-HARDWARE @ MIT-MC

Yesterday the ground-fault alarm went off in the 7th floor machine
room.  There were 7 spurious amperes in the safety-ground for the
room.  I traced the source to CADR-4 with a clamp-on ammeter.  I 
turned off CADR-4 and the fault disappeared.  For safety reasons
CADR-4 should remain off until the power supply problem is fixed.
 --GJS
20-Feb-85 20:36:25-EST,296;000000000000
Mail-From: GLR created at 20-Feb-85 20:35:41
Date: Wed, 20 Feb 1985  20:35 EST
Message-ID: <GLR.12089312264.BABYL@MIT-OZ>
From: Jerry Roylance <GLR@MIT-OZ>
To:   Bug-Hardware@MIT-OZ
Subject: Cadr-4 has a ground fault.


CADR-4 has been turned off; it has a ground fault (7.5A worth!).

21-Feb-85 17:48:20-EST,494;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 21 Feb 85 17:46-EST
Date: 21 February 1985 17:41-EST
From: Peter Szolovits <PSZ @ MIT-MC>
Subject:  Chaos net problem
To: BUG-HARDWARE @ MIT-MC
cc: PSZ @ MIT-MC

For the last couple of days, I seem not to be able to communicate over
Chaos between Oberon and MC.  E.g., Hostat MC on Oberon doesn't respond.
In fact, hostat Corwin on Oberon also did not, though hostat xx did.
Corwin seems to be having the same problems.  What's changed?
24-Feb-85 13:11:50-EST,396;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 24 Feb 85 13:11-EST
Date: 24 February 1985 12:57-EST
From: Glenn S. Burnout <GSB @ MIT-MC>
Subject: minimal optimal lossage
To: BUG-HARDWARE @ MIT-MC

Corwin and mc aren't talking.  Oberon and mc aren't talking.

I have not come across any other hosts to which corwin won't talk.

MC of course is the one i usually want corwin to talk to.
25-Feb-85 00:34:33-EST,933;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 25 Feb 85 00:34-EST
Date: Mon, 25 Feb 1985  00:27 EST
Message-ID: <AKR.LM.12090402975.BABYL@MIT-OZ>
From: AKR.LM%MIT-OZ@MIT-MC.ARPA
To:   "Glenn S. Burnout" <GSB@MIT-MC>
Cc:   BUG-HARDWARE@MIT-MC
Subject: minimal optimal lossage
In-reply-to: Msg of 24 Feb 1985  12:57-EST from Glenn S. Burnout <GSB at MIT-MC>

	Date: Sunday, 24 February 1985  12:57-EST
	From: Glenn S. Burnout <GSB at MIT-MC>

	Corwin and mc aren't talking.  Oberon and mc aren't talking.
	
	I have not come across any other hosts to which corwin won't talk.
	
	MC of course is the one i usually want corwin to talk to.

The MC-IO-11 chaos transceiver was disconnected from subnet 6?  I reconnected it
sunday afternoon and could not detect any problems caused by its presence.
Does anyone know why it was disconnected?

Connecting from MC to CORWIN and OBERON works again as far as I can tell.

25-Feb-85 14:10:15-EST,655;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 25 Feb 85 14:08-EST
Date: Mon 25 Feb 85 14:05:32-EST
From: J. Noel Chiappa <JNC@MIT-XX.ARPA>
Subject: Re: minimal optimal lossage
To: AKR.LM%MIT-OZ@MIT-MC.ARPA, GSB@MIT-MC.ARPA
cc: BUG-HARDWARE@MIT-MC.ARPA, JNC@MIT-XX.ARPA
In-Reply-To: Message from "AKR.LM%MIT-OZ@MIT-MC.ARPA" of Mon 25 Feb 85 00:38:17-EST

	Seems like bogosity in the VMS CHAOS layer that allowed them
to get faked out by this. Since the IO-11 wasn't sending routing
packets on subnet 6, they should automatically have routed to subnet
3 via subnet 1. That's what you get for having wired in entries in
routing tables.
-------
16-Mar-85 22:03:18-EST,314;000000000000
Mail-From: BAGLEY created at 16-Mar-85 22:02:37
Date: 16 Mar 1985  22:02 EST (Sat)
Message-ID: <BAGLEY.12095619538.BABYL@MIT-OZ>
From: Steven Christopher Bagley <BAGLEY@MIT-OZ>
To:   bug-hardware@MIT-OZ, bug-minits@MIT-OZ
Subject: 7A concentrator

I can't get the 7A concentrator to boot or reload.  Argh.
22-Mar-85 12:44:45-EST,650;000000000000
Received: from MIT-LISPM-8 by MIT-OZ via Chaosnet; 22 Mar 85 12:44-EST
Date: Friday, 22 March 1985, 12:45-EST
From: David A. Brown <David at MIT-OZ>
To: BUG-hardware at MIT-OZ

In System 98.78, CADR 3.10, ZMail 53.19, MIT-Specific 22.5,
microcode 309, ZM MIT, on Lisp Machine Eight:

This Cadr has a flaky right-hand meta key -- you have to
either push hard or wiggle the key to get a meta-character.

The interesting consequence of this is that the machine often
wont boot when you ctrl-meta-ctrl-meta-rubout, since it
doesn't register the right-hand meta key.  Because of this,
people often think this cadr is more seriously broken.
22-Mar-85 16:44:37-EST,331;000000000000
Mail-From: POTAK created at 22-Mar-85 16:43:36
Date: Fri 22 Mar 85 16:43:36-EST
From: "Sam Levitin" <POTAK@MIT-OZ>
Subject: 8C Hub
To: bug-hardware@MIT-OZ

I'm not sure if this is the right address, but ...

We've been having some trouble with 8C. Had to reboot it today.
Not critical, just a nuisance.

Potak
-------
22-Mar-85 17:41:46-EST,922;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 22 Mar 85 17:41-EST
Received: from MIT-ARTHUR by MIT-MC via Chaosnet; 22 MAR 85  17:41:40 EST
Date: Friday, 22 March 1985, 17:41-EST
From: Anonymous File Thief <anonymous at MIT-EECS>
To: BUG-Hardware at MIT-OZ

In Hardware in System 98.80, CADR 3.10, ZMail 53.19, MIT-Specific 22.5,
microcode 309, ZM MIT d, on Arthur Dent:

Synopsis:

Several and many functions appear broken when arriving at the site and
finding Arthur Dent alone, with the wholine displaying "Cold-Booted".

Most obvious symptom:

No, (and I mean zero) mouse feedback.

Current Solution:

I cold-boot the machine with meta-control-meta-control-rubout, which
allows me to use the machine without any problems that I have seen.

Additional Info:

No messages are displayed at the time of arrival at the site. i.e., no
garbage-collection messages, etc. just the standard herald.

23-Mar-85 23:49:41-EST,247;000000000000
Mail-From: AAB created at 23-Mar-85 23:48:58
Date: Sat 23 Mar 85 23:48:58-EST
From: Andrew A. Berlin <AAB@MIT-OZ>
Subject: Jimi Hendricks
To: bug-hardware@MIT-OZ


Jimi Hendricks screen is so jittery as to be almost unreadable.

-------
10-Apr-85 23:44:01-EST,396;000000000000
Mail-From: AGRE created at 10-Apr-85 23:23:02
Date: Wed 10 Apr 85 23:23-EST
From: Philip E. Agre <AGRE@MIT-OZ>
Subject: Sid Vicious
To: bug-hardware@MIT-OZ

barfed into the FEP with "Fatal disk error at unit ~O cylinder ~O
head ~O sector ~O" 0(8) 114(8) 2(8) 21(8) "Fatal ECC error".
Doesn't sound good.  But I booted it and it seems OK.  Is this
where I report such things?  

/phil
13-Apr-85 14:48:36-EST,480;000000000000
Mail-From: BAGLEY created at 13-Apr-85 14:47:46
Date: 13 Apr 1985  14:47 EST (Sat)
Message-ID: <BAGLEY.12102880414.BABYL@MIT-OZ>
From: Steven Christopher Bagley <BAGLEY@MIT-OZ>
To:   bug-hardware@MIT-OZ
Subject: 7A stills dies

The 7A concentrator just died again, and it took several tries to
reload and reboot.  If heat in that closet is in fact the problem, the
fan hack isn't working.  I suspect that all the cables around the
machine keep air from cooling it off.
22-Apr-85 10:05:14-EST,955;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 22 Apr 85 10:04-EST
Received: from MIT-TWEETY-PIE by MIT-MC via Chaosnet; 22 APR 85  10:05:07 EST
Date: Monday, 22 April 1985, 10:04-EST
From: Webster Dove <dove at MIT-BUGS-BUNNY>
Subject: loose power connector
To: Bug-Hardware at OZ
Message-ID: <850422100417.2.DOVE@TWEETY-PIE.MIT>

In Symbolics 3600 Hardware in Release 6.0, IP-TCP 29.0,
microcode TMC5-IO4-FPA-MIC 319, FEP 17, with UTIL, on Lisp Machine Tweety Pie:

We have had a 3600 for several years that has always had problems with
spontaneous halting.  The other day the cabinet started to smell.

We discovered that one of the screws attaching the 120vac line to the
solid-state power relay had not been properly tightened and was finally
overheating and sparking.  We suspect that many of our previous halts
were do to this (after fixing the problem there haven't been any).

Better check to see if your screws are loose too!
24-Apr-85 13:52:23-EST,712;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 24 Apr 85 13:51-EST
Date: Wed, 24 Apr 85 13:48:55 EST
From: Oded Anoaf Feingold <OAF@MIT-MC>
Subject:  pygmalion's tape dwive
To: CENT@MIT-MC
cc: cobb@MIT-OZ, bug-hardware@MIT-OZ
In-reply-to: Msg of Mon 22 Apr 85 23:38:04 EST from Pandora B. Berman <CENT>
Message-ID: <[MIT-MC].467927.850424.OAF>

I called Aviv regarding the bufted toggle on the spindle on
Pygmalion's tape dwive.  They will send a Mike McMurdy out on
Phriday morning, 04/26/85.  He knows to call me and Penny, but
failing that will phone around the lab until someone shows up
and lets him deal with the broken device.

Be helpful to him, if he should contact you.  Thanks.

Oded
30-Apr-85 11:04:11-EDT,323;000000000000
Received: from MIT-APIARY-3 by MIT-OZ via Chaosnet; 30 Apr 85 10:51-EDT
Date: Tue, 30 Apr 85 10:49 EDT
From: Eric Saund <SAUND@OZ>
Subject: mouse problem on AP-3
To: bug-hardware@OZ
Message-ID: <850430104959.1.SAUND@APIARY-3>

The right button of mouse SN 05019 on Lisp Machine Apiary-3
appears not to be working.
30-Apr-85 13:54:00-EDT,561;000000000000
Received: from MIT-LENNON by MIT-OZ via Chaosnet; 30 Apr 85 13:52-EDT
Date: Tue, 30 Apr 85 13:51 EDT
From: Harry Voorhees <HLV@OZ>
Subject: John Lennon flaky
To: BUG-HARDWARE@OZ
Message-ID: <"850430135101.1.hlv@OZ"@LENNON>

In Symbolics 3600 HARDWARE in Release 6.0, IP-TCP 29.0, AISite 8.6,
microcode TMC5-MIC 319, on Lisp Machine John Lennon:
Warm booted from: Lisp Listener 1.

This machine just required warm booting again as soon as it was cold booted.
I had just copied a band from DUANE to use, but that didn't fix things.

Harry Voorhees
 2-May-85 16:01:25-EDT,1347;000000000000
Received: from MIT-ROBOT-3 by MIT-OZ via Chaosnet; 2 May 85 15:59-EDT
Date: Thu, 2 May 85 15:58 EDT
From: Harry L. Voorhees <HLV@OZ>
Subject: Robot-3 crashed while garbage collecting
To: BUG-HARDWARE@OZ
Message-ID: <850502155801.1.HLV@ROBOT-3>

In Symbolics 3600 HARDWARE in Release 6.0, IP-TCP 29.0, AISite 8.6,
microcode TMC5-MIC 319, FEP 18, on Lisp Machine Robot-3:

Robot-3 just crashed while doing garbage collection in Release 6.  It
was necessary to cold boot the machine.  If this was not a hardware
error, please forward this message to the appropriate person.

The machine status at the time of crash was:

Lbus cont: Use-uncorrected-data, ignore-double-ecc-error, task-3-dismiss
Sequencer error status: A-memory-parity-error
Sequencer misc. status: CTOS-came-from-IFU, TSK-STOP (sequencer
     stopped), Errhalt-synch

3600 PC's:

Macro PC/(Even) 22070554
CPC/ 14260
 OPC+0/ 40021    OPC+10/ 54000
         40415            40410
         41442            51517
         40020            50707
         53312            50706
         41351            40173
         41125            52415
         41123            52414
Version 18 run-in prom

STACK:

si:safeguard-pointer  si:set-safeguard-bits  si:flip-ephereral-spaces
 si:gc-flip-ephemeral-spaces  si:gc-process  si:process-top-level
10-May-85 19:42:21-EDT,605;000000000000
Received: from MIT-MC by MIT-OZ via Chaosnet; 10 May 85 19:42-EDT
Date: Fri, 10 May 85 19:41:48 EST
From: David Vinayak Wallace <GUMBY@MIT-MC>
Subject:  aaa in 743
To: bug-hardware@MIT-OZ
Message-ID: <[MIT-MC].496139.850510.GUMBY>

The aaa in 743 has a software bug -- when it does an insert- or
delete-in-line it shifts all the text after the cursor right or left as the
cursor advances.

This is really annoying and has a tendency to make me seasick.  The
cleaning people are getting tired of throwing out the little seasick bags
and have asked me to report this.  So here it is.

david
12-May-85 13:38:05-EDT,679;000000000000
Received: from MIT-JANIS by MIT-OZ via Chaosnet; 12 May 85 13:37-EDT
Date: Sun, 12 May 85 13:37 EDT
From: Christopher G Atkeson <CGA@OZ>
Subject: console
To: BUG-HARDWARE@OZ
Message-ID: <850512133731.1.CGA@JANIS>

In Symbolics 3600 HARDWARE in Release 6.0, IP-TCP 29.0, AISite 9.1,
microcode TMC5-MIC 319, on Lisp Machine Janis Joplin:
Everything was fine until there was a sharp pop and all the stuff on my screen disappeared (leaving the usual background blue)
and no lines or black print of any sort. After about a minute the screen restored itself to normal condition. No smoke or smell of
burning components (yet). Thought you might like to know.
chris atkeson
15-May-85 15:55:30-EDT,908;000000000000
Received: from MIT-REAGAN by MIT-OZ via Chaosnet; 15 May 85 15:54-EDT
Received: from MIT-MICKEY-MOUSE by MIT-REAGAN via CHAOS with CHAOS-MAIL id 4961; Wed 15-May-85 15:55:26-EDT
Date: Wednesday, 15 May 1985, 15:53-EDT
From: Roland Ouellette <Roly at MIT-MC>
Subject: JOE-LOUIS's monitor
To: BUG-HARDWARE at OZ
Message-ID: <850515155345.1.ROLY@MICKEY-MOUSE.MIT>

In Symbolics 3600 HARDWARE in Release 6.0, IP-TCP 29.0,
microcode TMC5-MIC 319, FEP 18, on Lisp Machine Mickey Mouse:

Joe's monitor is very dim (it probably needs a new tube).
It also has a jumpy screen (like it did last fall).  It glitches so bad
that joe see's mouse blips comming off of its keyboard.  This is really
bad as the system menu comes up (mouse right twice) and then some button
gets pushed (arrest most of the time).  This problem could be caused by
bad connections in the boxes connecting his monitor.

Roland
15-May-85 16:47:42-EDT,766;000000000000
Received: from MIT-REAGAN by MIT-OZ via Chaosnet; 15 May 85 16:45-EDT
Received: from MIT-JOE-LOUIS by MIT-REAGAN via CHAOS with CHAOS-MAIL id 4963; Wed 15-May-85 16:45:49-EDT
Date: Wednesday, 15 May 1985, 16:44-EDT
From: Roland Ouellette <Roly at MIT-MC>
Subject: AXE (the first floor dover)
To: BUG-HARDWARE at OZ
Message-ID: <850515164404.1.ROLY@JOE-LOUIS.MIT>

Maybe this isn't the right place to send this, but........

Axe has been stopping about every 5-10 pages, apparantly because it
thinks that it has a paper jam.  It doesn't.  It probably has a bad
paper path sensor.

It also has a bad contact on the carriage, so that when the carriage is
not absoloutly heaved (seriously) into place it thinks that the fuser is
not warm yet.

Roland
15-May-85 18:26:19-EDT,676;000000000000
Mail-From: OAF created at 15-May-85 18:25:28
Date: Wed, 15 May 1985  18:25 EDT
Message-ID: <OAF.12111297731.BABYL@MIT-OZ>
From: OAF@MIT-OZ
To:   Roland Ouellette <Roly@MIT-MC>
Cc:   BUG-HARDWARE@MIT-OZ, ty@MIT-OZ, ricchio@MIT-XX
Subject: AXE (the first floor dover), jams and contacts
In-reply-to: Msg of 15 May 1985 16:44-EDT from Roland Ouellette <Roly at MIT-MC>


Jams:
Probably a bad voltage setting on the BOS/EOS pots.  (If it fails to see
those signals it thinks the paper's screwed up.  So sue me.)  TY can fix
that.

Carriage:  Probably a balky switch on the developer housing interlocks.
Try cycling the levers for that.  On second thought, don't.
21-Jun-85 13:09:01-EDT,322;000000000000
Mail-From: KOCH created at 21-Jun-85 13:08:54
Date: Fri 21 Jun 85 13:08:54-EDT
From: Christof Koch <KOCH@MIT-OZ>
Subject: Jim Morrison
To: bug-hardware@MIT-OZ

The mouse on Jim Morisson (7-th floor next to 793) does not work in the vertical direction.
Can somebody please have a look.
 Thanks
 Christof
-------
22-Jun-85 00:14:38-EDT,254;000000000000
Mail-From: PHILIP created at 22-Jun-85 00:14:18
Date: Sat 22 Jun 85 00:14:18-EDT
From: Philippe Brou <PHILIP@MIT-OZ>
Subject: Jim Morrison
To: bug-hardware@MIT-OZ

I fixed the mouse on Jim Morisson (disregard previous message from Koch).
-------
22-Jun-85 17:58:40-EDT,494;000000000000
Received: from MIT-HERMES by MIT-OZ via Chaosnet; 22 Jun 85 17:58-EDT
Received: by MIT-HERMES.ARPA (4.12/4.8) 
	id AA04253; Sat, 22 Jun 85 17:57:22 edt
Date: Sat, 22 Jun 85 17:57:22 edt
From: David M. Siegel <dms@mit-hermes>
To: bug-hardware@oz
Subject: problems with 8a-hub

For some strange reason, 8a-hub crashes when a power cycle a vt52 that
is connected to it. (The vt52 is sort of screwed up, and every now and
then it must be power cycled to make it work correctly)

-Dave
23-Jun-85 06:04:24-EDT,904;000000000000
Mail-From: PGS created at 23-Jun-85 06:04:15
Date: Sun, 23 Jun 1985  06:04 EDT
Message-ID: <PGS.12121386415.BABYL@MIT-OZ>
From: PGS@MIT-OZ
To:   "David M. Siegel" <dms@MIT-HERMES>
Cc:   bug-hardware@MIT-OZ
Subject: problems with 8a-hub
In-reply-to: Msg of 22 Jun 1985  17:57-EDT from David M. Siegel <dms at mit-hermes>

    Date: Saturday, 22 June 1985  17:57-EDT
    From: David M. Siegel <dms at mit-hermes>
    To:   bug-hardware at oz
    Re:   problems with 8a-hub

    For some strange reason, 8a-hub crashes when a power cycle a vt52 that
    is connected to it. (The vt52 is sort of screwed up, and every now and
    then it must be power cycled to make it work correctly)

    -Dave

Maybe there's a big spike going down the line when you power-cycle the vt52.
My suggestion is that you get Joe Ricchio to fix it (he works for LCS, not
us, but maybe he'll do it anyway).
24-Jun-85 09:41:20-EDT,566;000000000000
Mail-From: OAF created at 24-Jun-85 09:40:57
Date: Mon, 24 Jun 1985  09:40 EDT
Message-ID: <OAF.12121688008.BABYL@MIT-OZ>
From: OAF@MIT-OZ
To:   "David M. Siegel" <dms@MIT-HERMES>
Cc:   bug-hardware@MIT-OZ
Subject: problems with 8a-hub
In-reply-to: Msg of 22 Jun 1985  17:57-EDT from David M. Siegel <dms at mit-hermes>

The probable reason is that the VT52 sends break when it's power-cycled.
Given that we now have reliable DLV11-J cards in the Hubs instead of
shitty Tech Magic cards, terminals attached to certain ports will
reliably crash the hub.
24-Jun-85 12:46:41-EDT,506;000000000000
Received: from MIT-BUDDY by MIT-OZ via Chaosnet; 24 Jun 85 12:43-EDT
Date: Mon, 24 Jun 85 12:41 EDT
From: Harry L. Voorhees <HLV@OZ>
Subject: dim screen
To: BUG-HARDWARE@OZ
Message-ID: <850624124149.2.HLV@BUDDY>

In Symbolics 3600 HARDWARE in Release 6.0, IP-TCP 29.0, AISite 9.4,
Experimental COLOR 135.1, Experimental COLOR-DEMO 68.0,
Experimental COLOR-EDITOR 4.0, Experimental COLOR-PALETTE 2.0,
microcode TMC5-MIC 319, on Lisp Machine Buddy Holly:

The screen on Buddy Holly is very dim.
24-Jun-85 14:45:43-EDT,557;000000000000
Received: from MIT-XX by MIT-OZ via Chaosnet; 24 Jun 85 14:45-EDT
Date: Mon 24 Jun 85 14:43:24-EDT
From: "J. Noel Chiappa" <JNC@MIT-XX>
Subject: Re: problems with 8a-hub
To: PGS@MIT-OZ, dms@MIT-HERMES.ARPA
cc: bug-hardware@MIT-OZ, JNC@MIT-XX
In-Reply-To: Message from "PGS@MIT-OZ" of Sun 23 Jun 85 06:03:07-EDT

	I doubt that would croak the PDP11. It might fry the EIA
line interface chips. I like Oded's theory about the 'HALT on BREAK'
being enabled. Note, however, that this is on a jumper on the DLV11J
and can be disabled.
	Noel
-------
24-Jun-85 15:46:40-EDT,983;000000000000
Mail-From: PGS created at 24-Jun-85 15:46:20
Date: Mon, 24 Jun 1985  15:46 EDT
Message-ID: <PGS.12121754522.BABYL@MIT-OZ>
From: PGS@MIT-OZ
To:   OAF@MIT-OZ
Cc:   bug-hardware@MIT-OZ, "David M. Siegel" <dms@MIT-HERMES>
Subject: problems with 8a-hub
In-reply-to: Msg of 24 Jun 1985  09:40-EDT from OAF

    Date: Monday, 24 June 1985  09:40-EDT
    From: OAF
    To:   David M. Siegel <dms at MIT-HERMES>
    cc:   bug-hardware
    Re:   problems with 8a-hub

    The probable reason is that the VT52 sends break when it's power-cycled.
    Given that we now have reliable DLV11-J cards in the Hubs instead of
    shitty Tech Magic cards, terminals attached to certain ports will
    reliably crash the hub.

Well, about a month ago I checked all the cards in 8a, 8b, and 8c and made
sure that console halt was disabled.  It really was.  Have new cards been
installed in 8a?  Maybe the problem is with new cards; they come configured
with console halt enabled.
24-Jun-85 16:18:54-EDT,1061;000000000000
Received: from MIT-XX by MIT-OZ via Chaosnet; 24 Jun 85 16:18-EDT
Received: from MIT-HERMES.ARPA by MIT-XX.ARPA with TCP; Mon 24 Jun 85 16:16:30-EDT
Received: by MIT-HERMES.ARPA (4.12/4.8) 
	id AA11988; Mon, 24 Jun 85 16:16:58 edt
Date: Mon, 24 Jun 85 16:16:58 edt
From: David M. Siegel <dms@MIT-HERMES.ARPA>
Message-Id: <8506242016.AA11988@MIT-HERMES.ARPA>
To: JNC@MIT-XX.ARPA
Cc: PGS%MIT-OZ@MIT-XX.ARPA, bug-hardware%MIT-OZ@MIT-XX.ARPA, JNC@MIT-XX.ARPA
In-Reply-To: "J. Noel Chiappa"'s message of Mon 24 Jun 85 14:43:24-EDT
Subject: Re: problems with 8a-hub

   Date: Mon 24 Jun 85 14:43:24-EDT
   From: "J. Noel Chiappa" <JNC@MIT-XX.ARPA>

	   I doubt that would croak the PDP11. It might fry the EIA
   line interface chips. I like Oded's theory about the 'HALT on BREAK'
   being enabled. Note, however, that this is on a jumper on the DLV11J
   and can be disabled.
	   Noel
   -------

Yes, Oded is correct. I hit the break key on the termial and it halted
the concentrator. Someone might want to disable that "feature".

-Dave
26-Jun-85 14:11:43-EDT,1284;000000000000
Received: from MIT-APIARY-5 by MIT-OZ via Chaosnet; 26 Jun 85 14:09-EDT
Date: Wed, 26 Jun 85 14:08 EDT
From: Thomas Reinhardt <Tomr@OZ>
Subject: Lusing Eagle on AP6
To: BUG-HARDWARE@OZ
cc: TomR@MIT-XX, TomR@APIARY-6
Message-ID: <850626140801.1.TOMR@APIARY-5>

In Symbolics 3600 HARDWARE in Release 6.0, IP-TCP 29.0, AISite 9.4,
microcode TMC5-MIC 319, FEP 18, on Lisp Machine Apiary-5:

Apiary-6 [Fep1] unexpectedly died today with numerous Irrecoverable Disk Errors.

I reset the Fep, but to no avail.  

I then went upstairs, power cycled the Eagles and the 3600's. Again, to no 
good result.  I noted that the two green lights we out [behind or next to the
power supply] on the suspect Eagle.  I also noticed that [unlike other eagles] that
units Run and Ready Lights would go out when I would power cycle the 3600 processor.
I've never noticed that sort of thing...generally, the Eagles' Run Lights seem
independant of the main processing unit.

Anyway, after countless retries I finally managed to boot Apiary 6 by hand without
the Disk Sector n-1 Not Found or Too Many Sectors [?] error.

Do you think someone should look at this? or is this just an extention of the
current problem with the FEP??

Thank you for looking into this matter:


TOMR
 1-Jul-85 13:26:14-EDT,367;000000000000
Received: from MIT-HERMES by MIT-OZ via Chaosnet; 1 Jul 85 13:24-EDT
Received: by MIT-HERMES.ARPA (4.12/4.8) 
	id AA13503; Mon, 1 Jul 85 13:23:34 edt
Date: Mon, 1 Jul 85 13:23:34 edt
From: David M. Siegel <dms@mit-hermes>
To: bug-hardware@oz
Subject: ln01 is printing light

What do we do when this happens? Call Digital? Crank up the voltage on
the laser?
 1-Jul-85 20:00:11-EDT,1151;000000000000
Received: from MIT-PREP by MIT-OZ via Chaosnet; 1 Jul 85 19:59-EDT
Received: by MIT-PREP.ARPA (4.12/4.8) 
	id AA22447; Mon, 1 Jul 85 19:56:46 edt
Date: Mon, 1 Jul 85 19:56:46 edt
From: Scott Jones <saj@mit-prep>
To: bug-hardware@oz, dms@mit-hermes
Subject: Re:  ln01 is printing light

	From dms@mit-hermes Mon Jul  1 13:25:05 1985
	Received: from MIT-OZ by MIT-PREP (4.12/4.8) with CHAOS 
		id AA20778; Mon, 1 Jul 85 13:24:22 edt
	Message-Id: <8507011724.AA20778@MIT-PREP.ARPA>
	Received: from MIT-HERMES by MIT-OZ via Chaosnet; 1 Jul 85 13:24-EDT
	Received: by MIT-HERMES.ARPA (4.12/4.8) 
		id AA13503; Mon, 1 Jul 85 13:23:34 edt
	Date: Mon, 1 Jul 85 13:23:34 edt
	From: David M. Siegel <dms@mit-hermes>
	To: bug-hardware@oz
	Subject: ln01 is printing light
	
	What do we do when this happens? Call Digital? Crank up the voltage on
	the laser?
	
Yes, either solution will work. I have already done the former since
they broke it themselves when they came to "fix" it a few days ago.

--scott

ps: cranking up the voltage is a trivial operation, but you have to turn
the appropriate knob. Stop by and I'll show you how.
 8-Jul-85 15:59:33-EDT,539;000000000000
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 8 Jul 85 15:59-EDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 8 JUL 85  15:58:40 EDT
Received: from MIT-APIARY-6 by MIT-OZ via Chaosnet; 8 Jul 85 15:57-EDT
Date: Mon, 8 Jul 85 15:58 EDT
From: Gul A. Agha <AGHA@OZ>
Subject: Apiary 4
To: BUG-HARDWARE@MIT-MC.ARPA
Message-ID: <850708155803.1.AGHA@APIARY-6>

In Symbolics 3600 HARDWARE in Release 6.0, IP-TCP 29.0, AISite 9.5,
microcode TMC5-MIC 319, FEP 18, on Lisp Machine Apiary-6:

Apiary-4 is badly out of focus....
10-Jul-85 12:59:06-EDT,444;000000000000
Received: from MIT-APIARY-4 by MIT-OZ via Chaosnet; 10 Jul 85 12:58-EDT
Date: Wed, 10 Jul 85 12:59 EDT
From: Carl Hewitt <Hewitt@OZ>
Subject: Apiary 4's Screen
To: BUG-HARDWARE@OZ
cc: Hewitt@OZ
Message-ID: <850710125923.1.HEWITT@APIARY-4>

In Symbolics 3600 HARDWARE in Release 6.0, IP-TCP 29.0, AISite 9.5,
microcode TMC5-MIC 319, FEP 18, on Lisp Machine Apiary-4:

The screen on Ap4 is shaking miserably.  Needs immediate fixing!
21-Jul-85 10:48:12-EDT,267;000000000000
Mail-From: KCAVE created at 21-Jul-85 10:48:04
Date: Sun, 21 Jul 1985  10:48 EDT
Message-ID: <KCAVE.12128778115.BABYL@MIT-OZ>
From: KCAVE@MIT-OZ
To:   bug-hardware@MIT-OZ
Subject: mouse request


Would it be possible for the CADR in 901a to
have a mouse?

23-Jul-85 09:13:57-EDT,548;000000000000
Received: from MIT-GAUSS by MIT-OZ via Chaosnet; 23 Jul 85 09:13-EDT
Date: Tue, 23 Jul 85 09:13 EDT
From: Harry L. Voorhees <HLV@OZ>
Subject: Gauss's screen is blurred
To: BUG-HARDWARE@OZ
cc: hlv@OZ
Message-ID: <850723091308.1.HLV@GAUSS>

In Symbolics 3600 HARDWARE in Release 6.0, IP-TCP 29.0, AISite 9.5,
microcode TMC5-MIC 319, FEP 18, on Lisp Machine Karl Friedrich Gauss:

The left and right sides of Gauss's (nee Robot-1's) screen are blurry
unless the intensity is turned way down.  Perhaps its Gaussian blur?

Harry Voorhees
24-Jul-85 10:46:08-EDT,1079;000000000000
Received: from MIT-JIMI by MIT-OZ via Chaosnet; 24 Jul 85 10:45-EDT
Date: Wed, 24 Jul 85 10:45 EDT
From: Brian C. Williams <WILLIAMS@OZ>
Subject: Monitor problems
To: BUG-HARDWARE@OZ
Message-ID: <850724104525.1.WILLIAMS@JIMI>

In Symbolics 3600 HARDWARE in Release 6.0, IP-TCP 29.0, AISite 9.5,
microcode TMC5-MIC 319, on Lisp Machine Jimi Hendrix:

The image on Jimi's monitor has been quite fuzzy.

I thought this was caused by the extreme length of the cable running to the
monitor.  I have thus switched monitor's between Jimi and Moon.

As a result:

1) The monitor which is now on Jimi is clear, however the vertical lines are
   a bit uneven.  (In addition, it takes about a minute for the monitor to fall
   into synch once it has been powered on).

2) The monitor now on Moon seems to be a bit fuzzy and the contrast does not
   seem very strong.  

Finally, the extra monitor sitting in Jerry Roylance's office (741) does not
appear to be receiving a proper synch signal.  Instead the image is shifted
half a screen horizontally.

- Thanks
30-Jul-85 02:31:08-EDT,428;000000000000
Received: from MIT-GAUSS by MIT-OZ via Chaosnet; 30 Jul 85 02:30-EDT
Date: Tue, 30 Jul 85 02:31 EDT
From: Christopher Fry <cfry@OZ>
Subject: slow mouse
To: BUG-HARDWARE@OZ
cc: dtc@OZ
Message-ID: <850730023104.1.CFRY@GAUSS>

In Symbolics 3600 HARDWARE in Release 6.0, IP-TCP 29.0, AISite 9.5,
microcode TMC5-MIC 319, FEP 18, on Lisp Machine Karl Friedrich Gauss:

The mouse on this machine moves only unresponsively.
 1-Aug-85 10:34:17-EDT,552;000000000000
Received: from MIT-BUDDY by MIT-OZ via Chaosnet; 1 Aug 85 10:34-EDT
Date: Thu, 1 Aug 85 10:32 EDT
From: Harry Voorhees <HLV@OZ>
Subject: another blurry screen
To: BUG-HARDWARE@OZ
Message-ID: <"850801103241.1.hlv@OZ"@BUDDY>

In Symbolics 3600 HARDWARE in Release 6.0, IP-TCP 29.0, AISite 9.5,
Experimental COLOR 135.1, Experimental COLOR-DEMO 68.0,
Experimental COLOR-EDITOR 4.0, Experimental COLOR-PALETTE 2.0,
microcode TMC5-MIC 319, on Lisp Machine Buddy Holly:

The monitor of Buddy Holly is too blurry to be usuable.

Harry Voorhees
 2-Aug-85 23:22:39-EDT,580;000000000000
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 2 Aug 85 23:22-EDT
Date: Fri,  2 Aug 85 23:23:34 EDT
From: Pandora B. Berman <CENT@MIT-MC.ARPA>
Subject: ai transceiver busted?
To: LAUREL@MIT-MC.ARPA, OAF@MIT-MC.ARPA
cc: BUG-HARDWARE@MIT-MC.ARPA, ALAN@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].599155.850802.CENT>

AI was having trouble communicating. after poking around a bit, Alan
guessed that the transceiver might have gone bad, so we tried replacing it
with one of the bunch on the window ledge nearby. this worked. the suspect
transceiver is now on oded's desk.
 6-Aug-85 05:04:57-EDT,558;000000000000
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 6 Aug 85 05:04-EDT
Date: Tue,  6 Aug 85 05:04:47 EDT
From: Pandora B. Berman <CENT@MIT-MC.ARPA>
Subject: AI net connection loses
To: BUG-HARDWARE@MIT-MC.ARPA, BUG-ITS@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].602119.850806.CENT>

this morning i was using MC on my terminal. around 04:30 or so response
got very slow, then a few minutes ceased altogether. AI had lost its
net connection again, so i couldn't talk to MC, OZ, or anything else.
someone please fix -- i can't work well with no terminal.
 6-Aug-85 08:45:17-EDT,1109;000000000000
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 6 Aug 85 08:45-EDT
Date: Tue,  6 Aug 85 08:46:38 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  AI net connection loses
To: BUG-HARDWARE@MIT-MC.ARPA
cc: CENT@MIT-MC.ARPA
In-reply-to: Msg of Tue  6 Aug 85 05:04:47 EDT from Pandora B. Berman <CENT at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].602235.850806.ALAN>

    Date: Tue,  6 Aug 85 05:04:47 EDT
    From: Pandora B. Berman <CENT at MIT-MC.ARPA>
    this morning i was using MC on my terminal. around 04:30 or so response
    got very slow, then a few minutes ceased altogether. AI had lost its
    net connection again, so i couldn't talk to MC, OZ, or anything else.
    someone please fix -- i can't work well with no terminal.

Looks to me like this is the same thing that was happening yesterday
evening at around 8.  I don't think it is AI's problem.  It looked to me
then like subnet 6 was broken.  The symptoms were different than when AI's
tranceiver stopped working the other day: then I couldn't reach any other
host, last night I could reach some sites but not others.
 7-Aug-85 12:59:32-EDT,1010;000000000000
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 7 Aug 85 12:59-EDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 7 AUG 85  12:42:30 EDT
Date: Wed, 7 Aug 1985  11:53 EDT
Message-ID: <OAF.12133246507.BABYL@MIT-OZ>
From: OAF%MIT-OZ@MIT-MC.ARPA
To:   Alan Bawden <ALAN@MIT-MC.ARPA>
Cc:   BUG-HARDWARE@MIT-MC.ARPA, CENT@MIT-MC.ARPA
Subject: AI net connection loses
In-reply-to: Msg of 6 Aug 1985  08:46-EDT from Alan Bawden <ALAN at MIT-MC.ARPA>

I don't know what  this is apropos  of, but subnet 26  was down for  a
while today.  The piece of ethernet leading toward XX from  Hephaestus
has an  intermittent  open  45  feet  from  Hephaestus's  transceiver.
Probably someone pushed it this morning  to get at some cable  nearby,
and it opened and busted.   PAO and I moved  it again while trying  to
find the problem, and it suddenly came back to life.

If it breaks  again, probably  the first place  to look  is under  the
yellow brick road just by Heph.  Wiggle things, like, man...
13-Aug-85 16:23:07-EDT,787;000000000000
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 13 Aug 85 16:22-EDT
Received: from MIT-JIMI by MIT-MC.ARPA via Chaosnet; 13 AUG 85  14:21:33 EDT
Date: Tue, 13 Aug 85 14:21 EDT
From: Michael R. Brent <MICHAELB@OZ>
Subject: crash
To: BUG-HARDWARE@OZ
Message-ID: <850813142105.4.MICHAELB@JIMI>

In Symbolics 3600 HARDWARE in Release 6.0, IP-TCP 29.0, AISite 9.5,
microcode TMC5-MIC 319, on Lisp Machine Elvis Presley:

I was saving a file on oz when the following appeared:

Lisp stopped itself.

Halt reason: ("Proceedable disk error at unit ~O cylinder ~O head ~O sector ~O" 0(8) 222(8) 23(8) 21(8) "Irrecoverable disk overrun")

fep>


When I checked oz 5 minutes later it was down and gave the usual "did
not respond to a File 1 request" error.

-Sue Felshin
13-Aug-85 23:26:06-EDT,398;000000000000
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 13 Aug 85 23:25-EDT
Date: Tue, 13 Aug 85 23:26:49 EDT
From: Devon S. McCullough <DEVON@MIT-MC.ARPA>
Subject:  CADR-12 is not talking to Chaos
To: BUG-HARDWARE@MIT-MC.ARPA
cc: PSZ@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].611533.850813.DEVON>

...and Chaos is not talking to CADR-12 either.
It can't even get the date and time when booting.
25-Aug-85 16:03:08-EDT,886;000000000000
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 25 Aug 85 16:02-EDT
Date: Sun, 25 Aug 85 16:00:48 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject:  3600 cables suck
To: BUG-HARDWARE@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].623708.850825.ALAN>

There are now two busted 3600 cables that run from just outside my office
(723) into the 7th floor machine room.  It is definitely the cables; if I
use a fresh cable run between Keith Moon and the monitor outside my office
everything is fine, but using either of the installed cables the monitor
seems to have no horizontal sync.  I had a hard time finding one of the
ends of the cables in the machine room, so for our future convenience I
have labeled both ends of both cables (one is 723P, the other is 723Q).

If somebody could fix the connectors on one or both of these cables, or run
a new one, I would appreciate it.
 4-Sep-85 10:04:25-EDT,530;000000000000
Received: from MIT-BUDDY by MIT-OZ via Chaosnet; 4 Sep 85 10:04-EDT
Date: Wed, 4 Sep 85 10:03 EDT
From: Eric Saund <SAUND@OZ>
Subject: middle mouse on buddy-holly
To: bug-hardware@OZ
Message-ID: <850904100355.1.SAUND@BUDDY>

The middle mouse button doesn't work on lisp machine buddy-holly.
The mouse itself is good, the problem is in the console or elsewhere in
the hardware of the machine; buddy-holly's mouse, SN 05942, works on 
other machines, and other machines' good mice don't work on buddy-holly.
-Eric Saund
10-Sep-85 22:08:12-EDT,489;000000000000
Received: from MIT-BUDDY by MIT-OZ via Chaosnet; 10 Sep 85 22:08-EDT
Date: Tue, 10 Sep 85 22:06 EDT
From: Eric Saund <SAUND@OZ>
Subject: middle mouse on buddy-holly
To: bug-hardware@OZ
Message-ID: <850910220647.1.SAUND@BUDDY>

Someone replaced the mouse on buddy-holly.
The current mouse's serial number is 06674.
The middle mouse button is still not working, so the
mouse logic in the console must be broken, as
the person who replaced the mouse suggested
might be the case.
24-Sep-85 10:17:36-EDT,758;000000000000
Received: from MIT-JIMI by MIT-OZ via Chaosnet; 24 Sep 85 10:15-EDT
Date: Tue, 24 Sep 85 10:17 EDT
From: Brian C. Williams <WILLIAMS@OZ>
Subject: Lennon won't boot
To: BUG-HARDWARE@OZ
cc: cjl@OZ, glr@OZ
Message-ID: <850924101700.5.WILLIAMS@JIMI>

In Symbolics 3600 HARDWARE in Release 6.0, IP-TCP 29.0, AISite 10.5,
microcode TMC5-MIC 319, on Lisp Machine Jimi Hendrix:


Lennon won't boot. The previously intermittent memory error (double parity)
is now quite frequent. It did it twie last night, and when I booted this morning,
it wouldn't even make it through cold booting. Status this morning:

->OPC+0	14726		OPC+10	46262
	12012			43507
	55223			143726
	53643			53636
	41421			141476
	52544			45052
	54334			45725
	47643			42741
28-Sep-85 23:38:03-EDT,369;000000000000
Received: from MIT-AI.ARPA by MIT-OZ via Chaosnet; 28 Sep 85 23:37-EDT
Received: from MIT-JIMI by MIT-AI.ARPA via Chaosnet; 24 SEP 85  18:17:29 EDT
Date: Tue, 24 Sep 85 18:19 EDT
From: weld@OZ
Sender: WILLIAMS@OZ
Subject: lennon's monitor died
To: bug-hardware@OZ
cc: cjl@OZ, glr@OZ
Message-ID: <850924181908.9.WILLIAMS@JIMI>

Please fix lennon's monitor.

30-Sep-85 08:41:45-EDT,487;000000000000
Received: from MIT-RIEMANN by MIT-OZ via Chaosnet; 30 Sep 85 08:41-EDT
Date: Mon, 30 Sep 85 08:42 EDT
From: Eric Saund <SAUND@OZ>
Subject: middle mouse button on buddy-holly
To: bug-hardware@OZ
Message-ID: <850930084211.1.SAUND@RIEMANN>

The middle mouse button does not work on 
lisp machine Buddy-Holly.
(This has been broken for quite some time.)
It does not appear to be a problem with the 
mouse itself, but with something in the console
that interprets mouse signals.
 1-Oct-85 14:08:21-EDT,431;000000000000
Mail-From: RICH created at  1-Oct-85 14:02:28
Date: Tue 1 Oct 85 14:02-EDT
From: Charles Rich <RICH@MIT-OZ>
Subject: Cabling from 800B to 804
To: dsd@MIT-OZ
CC: Cadr@MIT-OZ, crisse@MIT-OZ, yishai@MIT-OZ

Dave, I forgot whether I mentioned to your that we now have an extra key to Rm
804 if you need access when Feldman or I are not around.  Crisse knows
where (lower left hand drawer of my desk) it is.
		Thanks, Chuck.
 7-Oct-85 10:10:55-EDT,534;000000000000
Received: from MIT-LENNON by MIT-OZ via Chaosnet; 7 Oct 85 10:10-EDT
Date: Mon, 7 Oct 85 10:11 EDT
From: Brian C. Williams <WILLIAMS@OZ>
Subject: Broken mouse on Lennon
To: BUG-HARDWARE@OZ
Message-ID: <851007101144.1.WILLIAMS@LENNON>

In Symbolics 3600 HARDWARE in Release 6.0, IP-TCP 29.0, AISite 10.6,
microcode TMC5-MIC 319, on Lisp Machine John Lennon:

Lennon's mouse will not track along the vertical axis.  I have tried
other mice on Lennon and they seem to work fine, thus the problem is
definitely in the mouse.
 8-Oct-85 08:57:58-EDT,381;000000000000
Received: from MIT-BUDDY by MIT-OZ via Chaosnet; 8 Oct 85 08:57-EDT
Date: Tue, 8 Oct 85 08:58 EDT
From: Eric Saund <SAUND@OZ>
Subject: middle mouse button on Buddy-Holly
To: bug-hardware@OZ
Message-ID: <851008085852.1.SAUND@BUDDY>

The middle mouse button on lisp machine
Buddy-Holly does not work.
I believe that it is the console that is
broken, not the mouse itself.
10-Oct-85 11:09:43-EDT,265;000000000000
Mail-From: RISTAD created at 10-Oct-85 11:09:31
Date: Thu 10 Oct 85 11:09-EDT
From: Eric Sven Ristad <RISTAD@MIT-OZ>
Subject: 8A concentrator
To: bug-hardware@MIT-OZ, marty@MIT-OZ


The 8A concentrator is down and won't boot.
Please fix it,
Thanks,
Eric
10-Oct-85 14:11:25-EDT,567;000000000000
Mail-From: MDC created at 10-Oct-85 14:10:59
Date: Thu 10 Oct 85 14:10:58-EDT
From: "Martin David Connor" <MDC@MIT-OZ>
Subject: Re: 8A concentrator
To: RISTAD@MIT-OZ
cc: bug-hardware@MIT-OZ
In-Reply-To: Message from "Eric Sven Ristad <RISTAD@MIT-OZ>" of Thu 10 Oct 85 11:09:45-EDT
Message-ID: <12150048715.43.MDC@MIT-OZ>


    Mail-From: RISTAD created at 10-Oct-85 11:09:31
    Date: Thu 10 Oct 85 11:09-EDT
    From: Eric Sven Ristad <RISTAD@MIT-OZ>

    The 8A concentrator is down and won't boot.
    Please fix it, Thanks, Eric

Done.
-------
11-Oct-85 16:37:50-EDT,461;000000000000
Received: from MIT-GAUSS by MIT-OZ via Chaosnet; 11 Oct 85 16:37-EDT
Date: Fri, 11 Oct 85 16:38 EDT
From: Harry L. Voorhees <HLV@OZ>
Subject: Guassian Blur
To: BUG-HARDWARE@OZ
Message-ID: <851011163825.1.HLV@GAUSS>

In Symbolics 3600 HARDWARE in Release 6.0, IP-TCP 29.0, AISite 10.6,
microcode TMC5-MIC 319, FEP 18, on Lisp Machine Karl Friedrich Gauss:

Gauss's console blurry again (or its still blurry, if you never
fixed it.)

Harry Voorhees
18-Oct-85 01:27:18-EDT,650;000000000000
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 18 Oct 85 01:27-EDT
Date: Fri, 18 Oct 85 01:22:19 EDT
From: Pandora B. Berman <CENT@MIT-MC.ARPA>
Subject: oz lpt fukt
To: BUG-HARDWARE@MIT-MC.ARPA, CJL@MIT-MC.ARPA
cc: SRA@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].683809.851018.CENT>

oz's la120 LPT has the absurd idea that it can only put 1 char on a line.
this is a hardware problem; it does this even in local mode. this should
get fixed. do we need to call dec to do this, or what?

btw, SRA (who helped me poke into the software until we remembered to try
it offline) suggests punting the current L12SPL spooler in favor of TCPSPL.
18-Oct-85 12:29:27-EDT,991;000000000000
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 18 Oct 85 12:29-EDT
Received: from MIT-XX.ARPA by MIT-MC.ARPA 18 Oct 85 12:24:16 EDT
Date: Fri, 18 Oct 1985  12:25 EDT
Message-ID: <SRA.12152126675.BABYL@MIT-XX.ARPA>
From: Rob Austein <SRA@MIT-XX.ARPA>
To:   CENT@MIT-MC.ARPA, BUG-HARDWARE@MIT-MC.ARPA, CJL@MIT-MC.ARPA
Cc:   sra@MIT-XX.ARPA
Subject: oz lpt fukt
In-reply-to: Msg of 18 Oct 1985  01:22-EDT from Pandora B. Berman <CENT@MIT-MC.ARPA>

In case anybody was confused about why I am recomending a program
called TCPSPL for a chaos-only machine....

TCPSPL is a LPTSPL clone that can handle two kinds of printers: tty
printers (like an LA120), and remote printers via the unix lpd
protocol.  If somebody were to hack the TCP code to use Chaosnet
instead (which should be trivial), you could use this spooler to let
OZ spool to Pravda and LeMonde, if such things amuse you.  Ask me if
you want more details.

This was an unsollicited non-political announcement.
21-Oct-85 12:37:26-EDT,361;000000000000
Received: from MIT-RIEMANN by MIT-OZ via Chaosnet; 21 Oct 85 12:37-EDT
Date: Mon, 21 Oct 85 12:34 EDT
From: Harry L. Voorhees <HLV@OZ>
Subject: Dead Lisp Machine Hilbert
To: BUG-HARDWARE@OZ
Message-ID: <851021123450.1.HLV@RIEMANN.AI.MIT.EDU>

Lisp Machine Hilbert is dead. The clock on the LBUS backplane 
seems to be gronked.

Noble Larson (NGL@OZ)
23-Oct-85 13:23:08-EDT,574;000000000000
Received: from MIT-HUREWICZ by MIT-OZ via Chaosnet; 23 Oct 85 13:22-EDT
Date: Wed, 23 Oct 85 13:20 EDT
From: Harry L. Voorhees <HLV@OZ>
Subject: Hilbert's console
To: BUG-HARDWARE@OZ
Message-ID: <851023132032.1.HLV@HUREWICZ.AI.MIT.EDU>

Hilbert's (nee Robot-2) console in Room 904 is completely
black.  The problem appears to be with the console, but there
may be something wrong with the machine too.
Hilbert's console remained dark after switiching it to
Hurewicz; Hurewicz's console on Hilbert worked but it made
a horrible gurgling noise.

Harry Voorhees
24-Oct-85 11:49:35-EDT,895;000000000000
Received: from MIT-DUANE by MIT-OZ via Chaosnet; 24 Oct 85 11:45-EDT
Date: Thu, 24 Oct 85 11:43 EDT
From: David Clemens <DTC@OZ>
Subject: Multiple Mouse buttons
To: BUG-HARDWARE@OZ
Message-ID: <851024114336.1.DTC@DUANE.AI.MIT.EDU>

In Symbolics 3670 HARDWARE in Release 6.0, IP-TCP 29.0, AISite 10.6,
microcode TMC5-IO4-MIC 319, FEP 22, on Lisp Machine Duane Allman:

I don't know whether or not this is a hardware bug, but on all of the other
lisp machines I've used, when multiple mouse buttons are pressed simultaneously,
the sum of the button values appears in tv:mouse-last-buttons, with 1=left,
2=middle, 4=right.  On Duane, each value works correctly when pressed individually,
but if any two are pressed at once, the value is 1, even if the middle and right
buttons are pressed together.

Is this a 3670 "feature", or a hardware or software bug?

Thanks,
DTC@MIT-OZ
26-Oct-85 21:11:04-EDT,451;000000000000
Received: from MIT-HUREWICZ by MIT-OZ via Chaosnet; 26 Oct 85 21:10-EDT
Date: Sat, 26 Oct 85 21:09 EDT
From: Sathya D.Narayanan <ads@OZ>
Subject: Access to Lisp Machine Hilbert for repairs
To: neal@SCRC-STONY-BROOK, BUG-HARDWARE@OZ, robot-facilities@OZ
Message-ID: <851026210918.1.ADS@HUREWICZ.AI.MIT.EDU>

Sorry that Room 904 was locked when you came to repair Lisp Machine
Hilbert.  I'm leaving the door unlocked for you.

Harry Voorhees
30-Oct-85 22:39:53-EST,335;000000000000
Received: from MIT-HUREWICZ by MIT-OZ via Chaosnet; 30 Oct 85 22:39-EST
Date: Wed, 30 Oct 85 22:40 EST
From: Christof Koch <KOCH@OZ>
Subject: Hilbert
To: BUG-HARDWARE@OZ
Message-ID: <851030224020.1.KOCH@HUREWICZ.AI.MIT.EDU>

The screen of Hilbert up in 904 is still very fuzzy and dim. Can't be used.
Could you check?
 Harry
30-Oct-85 22:42:01-EST,396;000000000000
Received: from MIT-HUREWICZ by MIT-OZ via Chaosnet; 30 Oct 85 22:41-EST
Date: Wed, 30 Oct 85 22:42 EST
From: hlv@OZ
Sender: KOCH@OZ
Subject: Hilbert's screen still broken
To: BUG-HARDWARE@OZ, neal@SCRC-STONY-BROOK
Message-ID: <851030224220.2.KOCH@HUREWICZ.AI.MIT.EDU>

Hilbert's screen is still dim and very fuzzy.  Its unusable.
Could you please fix it ASAP? Thanks,

Harry Voorhees
 5-Nov-85 03:25:23-EST,599;000000000000
Received: from MIT-LISPM-23 by MIT-OZ via Chaosnet; 5 Nov 85 03:25-EST
Date: Tuesday, 5 November 1985, 03:24-EST
From: Ed Barton <EB at MIT-OZ>
Subject: Cadr-8, Cadr-4 dead
To: Bug-Hardware at MIT-OZ


    I managed to set the current band on Cadr-8 to a band that won't boot.
The debugging cable for Cadr-8 runs to Cadr-4, which is not up and looks
like it is missing some boards; thus I can't use the debugging cable to
set the current band on Cadr-8 to something more reasonable.

    Sorry about all this.  The band that ran properly on Cadr-8 is LOD3,
with microcode load MCR2.

14-Nov-85 11:23:54-EST,561;000000000000
Received: from MIT-JANIS by MIT-OZ via Chaosnet; 14 Nov 85 11:22-EST
Date: Thu, 14 Nov 85 11:21 EST
From: Harry L. Voorhees <HLV@OZ>
Subject: Janis Joplin's console
To: BUG-HARDWARE@OZ
Message-ID: <851114112100.2.HLV@JANIS.AI.MIT.EDU>

In Symbolics 3600 HARDWARE in Release 6.0, IP-TCP 29.0, AISite 10.6,
microcode TMC5-MIC 319, on Lisp Machine Janis Joplin:

The console needs repair.  Periodically, every other scan line is shifted
over by 2 pixels, making the screen unreadable.  

Let's not take three weeks to fix this one.

Harry Voorhees
 2-Dec-85 01:49:30-EST,605;000000000000
Mail-From: BUCKLEY created at  2-Dec-85 01:49:08
Date: Mon, 2 Dec 1985  01:49 EST
Message-ID: <BUCKLEY.12163818222.BABYL@MIT-OZ>
From: BUCKLEY@MIT-OZ
To:   bug-hardware@MIT-OZ
Subject: bad concentrator or subnetwork

Terminal concentrator 8D is losing very badly. At frequent
intervals (e.g. every couple of EMACS lines) response dies
for a half minute or more.  This phenomenon occurs on multiple
terminals connected to various different machines.

I would appreciate getting a response to this message as soon as
possible. If this the wrong list to whine to please let me know.


Steve
 2-Dec-85 08:25:54-EST,1251;000000000000
Mail-From: PGS created at  2-Dec-85 08:25:45
Date: Mon, 2 Dec 1985  08:25 EST
Message-ID: <PGS.12163890425.BABYL@MIT-OZ>
From: PGS@MIT-OZ
To:   BUCKLEY@MIT-OZ
Cc:   bug-hardware@MIT-OZ
Subject: bad concentrator or subnetwork
In-reply-to: Msg of 2 Dec 1985  01:49-EST from BUCKLEY

    Date: Monday, 2 December 1985  01:49-EST
    From: BUCKLEY
    To:   bug-hardware
    Re:   bad concentrator or subnetwork

    Terminal concentrator 8D is losing very badly. At frequent
    intervals (e.g. every couple of EMACS lines) response dies
    for a half minute or more.  This phenomenon occurs on multiple
    terminals connected to various different machines.

The problem was a line running open and generating garbage at 9600 baud.
This seems to happen a lot.  Laurel, you might want to tell your line runners
(yow, do you have a football team yet?) not to connect lines that don't have
anything on the other end to concentrators.  This doesn't matter on the
mainframes much, because it's easy to spy on other channels and see what
they're doing and set their baud rates to 0 if necessary, but the
concentrators don't know how to do this, so they get very slow.

The guilty line was marked `206' (bizarre place to talk to).
 8-Dec-85 18:28:07-EST,523;000000000000
Received: from MIT-MC.ARPA by MIT-OZ via Chaosnet; 8 Dec 85 18:27-EST
Date: Sun,  8 Dec 85 18:29:43 EST
From: "Michael A. Patton" <MAP@MIT-MC.ARPA>
To: BUG-HARDWARE@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].746433.851208.MAP>

You probably know this already but, the LA36 (DECWriter) on MC is losing
its cookies.  It seems to have trouble printing things out, it slows down
to a near crawl and then drops characters.  The preceding information is
gleaned from having sat next to it for a few minutes using the VT52.
19-Dec-85 03:48:34-EST,667;000000000000
Received: from MIT-AI.ARPA by MIT-OZ via Chaosnet; 19 Dec 85 03:48-EST
Date: Thu, 19 Dec 85 03:48:40 EST
From: "Pandora B. Berman" <CENT%AI.AI.MIT.EDU@MC.LCS.MIT.EDU>
Subject: bug lists
To: BETTYD@OZ.AI.MIT.EDU
cc: bug-hardware@OZ.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].9066.851219.CENT>

    Date: Wed, 18 Dec 1985  09:35 EST
    From: BETTYD@MIT-OZ
    To:   bug-system@MIT-OZ
    My terminal and Marvin's are not working.
BUG-SYSTEM focuses mostly on software problems. terminals being
non-functional is almost always a situation where some piece of hardware
isn't working. so BUG-HARDWARE would have been a better list to send your
complaint to.
19-Dec-85 10:24:17-EST,448;000000000000
Mail-From: HBR created at 19-Dec-85 10:23:10
Date: Thu 19 Dec 85 10:23:09-EST
From: "Howard B. Reubenstein" <HBR@MIT-OZ>
Subject: Broken terminal in 803
To: bug-hardware@MIT-OZ
cc: HBR@MIT-OZ
Message-ID: <12168368245.93.HBR@MIT-OZ>

The ann arbor terminal in my office 803 is making funny sounds as
if some electrical components were arcing over. It seems to work
but I think its pretty unsafe.

Thanks for your help,
Howard
-------
23-Dec-85 00:37:24-EST,458;000000000000
Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 23 Dec 85 00:37-EST
Date: Mon, 23 Dec 85 00:41:21 EST
From: "Christopher C. Stacy" <CSTACY@MC.LCS.MIT.EDU>
To: GSB@MC.LCS.MIT.EDU, CBF@MC.LCS.MIT.EDU
cc: BUG-HARDWARE@MC.LCS.MIT.EDU
Message-ID: <[MC.LCS.MIT.EDU].764357.851223.CSTACY>

One of the Vadic modem boxes in the KLUDGE cabinet has
blown a 2a fuse, but I can't find any to snarf.
I wonder why it blew in the first place, ohwell.
23-Dec-85 09:24:19-EST,400;000000000000
Mail-From: ELIZABETH created at 23-Dec-85 09:24:03
Date: Mon, 23 Dec 1985  09:24 EST
Message-ID: <ELIZABETH.12169406064.BABYL@MIT-OZ>
From: ELIZABETH@MIT-OZ
To:   bug-hardware@MIT-OZ
Subject: Terminal problem

My terminal's screen shows nothing but a streak down the middle,
although it is communicating with the outside world (I could log in
but not see anything I'd typed...).

Thanks.
30-Dec-85 16:56:53-EST,1261;000000000000
Received: from GAUSS.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 30 Dec 85 16:56-EST
Date: Mon, 30 Dec 85 16:58 EST
From: Walter E. Gillett <GILLETT@OZ.AI.MIT.EDU>
Subject: cold boot doesn't work
To: BUG-HARDWARE@OZ.AI.MIT.EDU
cc: gillett@OZ.AI.MIT.EDU, hlv@OZ.AI.MIT.EDU
Message-ID: <851230165847.1.GILLETT@GAUSS.AI.MIT.EDU>

In Symbolics 3600 Hardware in Release 6.1, IP-TCP 29.13, 6-1-Patches 1.2,
AISite 11.6, microcode TMC5-MIC 336, FEP 127, FEP0:>v127-lisp.flod(2),
FEP0:>v127-loaders.flod(2), FEP0:>v127-debug.flod(1),
FEP0:>v127-info.flod(2), on Lisp Machine Karl Friedrich Gauss:

Symptoms: if I halt the machine by typing hyper-shift-function, then type "boot" to
the FEP prompt, the boot procedure begins normally.  However, the machine hangs
forever when it gets to the command "Clear Machine" and does not respond to any
keyboard input.  Sometimes the red fault light on the main processor is illuminated
at this point.  In order to unwedge the machine, I have found it necessary to push
the reset button on the main processor.  After this has been done, the machine can be
normally booted through the sequence "hello" and "boot".  Once booted successfully,
the machine seems to perform perfectly.

Walter Gillett (gillett@oz)
 4-Jan-86 16:07:34-EST,548;000000000000
Received: from MOON.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 4 Jan 86 16:07-EST
Date: Sat, 4 Jan 86 16:09 EST
From: Harry L. Voorhees <HLV@OZ.AI.MIT.EDU>
Subject: Lisp Machine Hilbert is broken
To: BUG-HARDWARE@OZ.AI.MIT.EDU
cc: tp@OZ.AI.MIT.EDU
Message-ID: <860104160940.1.HLV@MOON.AI.MIT.EDU>

The FEP on Hilbert appears to be broken.
It ignores some input from the keyboard,
and doesn't boot the machine successfully.

Since Hurewicz is still broken after 4 weeks, 
now neither of our vision lisp machines work.

Harry Voorhees
 6-Jan-86 10:42:34-EST,949;000000000000
Received: from DUANE.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 6 Jan 86 10:41-EST
Date: Mon, 6 Jan 86 10:42 EST
From: David M. Siegel <DMS@MIT-HERMES.ARPA>
Subject: Mess by Duane Allman
To: bug-hardware@OZ.AI.MIT.EDU
Message-ID: <860106104228.3.DMS@DUANE.AI.MIT.EDU>

Would it be possible for the area around Duane Allman to be cleaned up a
bit?  A video distribution box has been mounted on the wall yet none of
the cables are hooked into it. Fleck told me the cables going to it are
too short, so it isn't being used. Why not make longer cables? Or
instead, should we just leave the box hanging on the wall, unused? I
also think that the apple printer could probably be put in a better
place. Right now it is right behind the lisp machine terminal, about 5
inches from where you sit. It isn't very pleasant having the thing
printing away while you are trying to work. Does anyone have any ideas
where it could be moved? 

-Dave
 8-Jan-86 15:30:58-EST,581;000000000000
Received: from PREP.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 8 Jan 86 15:30-EST
Received: by prep; Wed, 8 Jan 86 15:32:03 est
Date: Wed, 8 Jan 86 15:32:03 est
From: x@prep.ai.mit.edu (Dean Elsner)
To: bug-aaa@oz
Cc: bug-hardware@oz, x@prep
Subject: ANOTHER dead AAA terminal @ 703

I recently stole the public AAA from the corridor on 7AI near the kitchen.
It is now in room 703 to replace a dead AAA. I did this to try to test & fix
the dead AAA, and have not been able to fix it. Would somebody please
diagnose & fix a dead AAA now living on the floor @703? Thanks!
12-Jan-86 14:35:46-EST,506;000000000000
Received: from POINCARE.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 12 Jan 86 14:34-EST
Date: Sun, 12 Jan 86 14:35 EST
From: Harry L. Voorhees <HLV@OZ.AI.MIT.EDU>
Subject: Lisp machine Gauss broken
To: BUG-HARDWARE@OZ.AI.MIT.EDU
Message-ID: <860112143504.1.HLV@POINCARE.AI.MIT.EDU>

Lisp machine gauss cannot be booted.  After typing "hello" or "boot"
to the fep it says "Drive 0 not ready."  I tried reset button on the
machine, and turned the power key off and on, but that didn't help.

Harry
19-Jan-86 12:48:38-EST,726;000000000000
Received: from HUREWICZ.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 19 Jan 86 12:48-EST
Date: Sun, 19 Jan 86 12:50 EST
From: Harry L. Voorhees <HLV@OZ.AI.MIT.EDU>
Subject: disk errors on Hurewicz
To: BUG-HARDWARE@OZ.AI.MIT.EDU
Message-ID: <860119125058.1.HLV@HUREWICZ.AI.MIT.EDU>

In Symbolics 3600 Hardware in Release 6.1, IP-TCP 29.13, 6-1-Patches 1.7,
AISite 11.10, microcode TMC5-MIC 336, FEP 127, FEP0:>v127-lisp.flod(2),
FEP0:>v127-loaders.flod(2), FEP0:>v127-debug.flod(1),
FEP0:>v127-info.flod(2), on Lisp Machine Witold Hurewicz:

The following Irrecoverable disk overruns were recently reported on
Hurewicz:

Unit Cyl Head Sector
  0  246  22   7
  0 1156  23  11
  0  300  23  13

Harry Voorhees
25-Jan-86 14:23:04-EST,792;000000000000
Received: from HUREWICZ.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 25 Jan 86 14:22-EST
Date: Sat, 25 Jan 86 14:21 EST
From: Harry L. Voorhees <HLV@OZ.AI.MIT.EDU>
Subject: Disk problems on Hurewicz
To: BUG-HARDWARE@OZ.AI.MIT.EDU
Message-ID: <860125142137.1.HLV@HUREWICZ.AI.MIT.EDU>

In Symbolics 3600 Hardware in Release 6.1, IP-TCP 29.13, 6-1-Patches 1.9,
AISite 11.10, microcode TMC5-MIC 336, FEP 127, FEP0:>v127-lisp.flod(2),
FEP0:>v127-loaders.flod(2), FEP0:>v127-debug.flod(1),
FEP0:>v127-info.flod(2), on Lisp Machine Witold Hurewicz:

Hurewicz's disk is still very unreliable.  The following irrecoverable
disk errors required not only booting the machine but powering in on and off.

Unit, sector, etc..
0  1041  13  4
   1053  16 12
   1034  3  10

Harry Voorhees
25-Jan-86 14:33:35-EST,422;000000000000
Received: from BUDDY.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 25 Jan 86 14:33-EST
Date: Sat, 25 Jan 86 14:32 EST
From: Harry L. Voorhees <HLV@OZ.AI.MIT.EDU>
Subject: more on Hurewicz
To: BUG-HARDWARE@OZ.AI.MIT.EDU
Message-ID: <860125143211.1.HLV@BUDDY.AI.MIT.EDU>

...In fact, just after sending that last message, Hurewicz had another
disk error.  The machine is unusable until this is fixed.

Harry Voorhees
 6-Feb-86 10:48:23-EST,1458;000000000000
Received: from REAGAN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 6 Feb 86 10:45-EST
Received: from HILBERT.AI.MIT.EDU by MIT-REAGAN.ARPA via CHAOS with CHAOS-MAIL id 21259; Thu 6-Feb-86 09:55:52-EST
Date: Thu, 6 Feb 86 09:54 EST
From: David J. Braunegg <DJB@OZ.AI.MIT.EDU>
Subject: lisp stopped itself
To: BUG-HARDWARE@OZ.AI.MIT.EDU
Message-ID: <860206095451.1.DJB@HILBERT.AI.MIT.EDU>

In Symbolics 3600 Hardware in Release 6.1, IP-TCP 29.13, 6-1-Patches 1.9,
AISite 11.12, Manip 5.19, Puma 5.15, microcode TMC5-MIC 336, FEP 127,
FEP0:>v127-lisp.flod(2), FEP0:>v127-loaders.flod(2),
FEP0:>v127-debug.flod(1), FEP0:>v127-info.flod(2), on Lisp Machine David Hilbert:

2/6/86 9:34:34

Lisp Stopped Itself while I was loading a file into a ZMACS buffer.
After 3 or 4 CONTINUEs, I was able to proceed.  This file has loaded on
other machines with no problem.

By the way, does this status information help any?  Do you want it
included in a bug report?

STATUS:

sequencer error status: a-memory-parity-error
sequencer miscellaneous status: tsk-stop (sequencer stopped), errhalt-sync
ecc syndrome 26, address 5xxxxx1 (lbus slot 2, bank 5)
3600 program counters:
	macro pc/ (odd)2156263
	cpc/ 723
       opc+0/	44545
	    1	44543
	    2	44542
	    3	44537
	    4	44536
	    5	44535
	    6	44533
	    7	53375
	    10	41106
	    11	40723
	    12	723
	    13	44545
	    14	44543
	    15	44542
	    16	44537
	    17	44536
 8-Feb-86 15:47:00-EST,710;000000000000
Received: from RIEMANN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 8 Feb 86 15:46-EST
Date: Sat, 8 Feb 86 15:43 EST
From: Harry Voorhees <HLV@OZ.AI.MIT.EDU>
Subject: Riemann's console needs adjusting
To: BUG-HARDWARE@OZ.AI.MIT.EDU
Message-ID: <"860208154352.1.hlv@OZ"@RIEMANN.AI.MIT.EDU>

In Symbolics 3600 Hardware in Release 6.1, IP-TCP 29.13, 6-1-Patches 1.9,
AISite 12.0, Macsyma 310.35, microcode TMC5-MIC 336, FEP 127,
FEP0:>v127-lisp.flod(2), FEP0:>v127-loaders.flod(2),
FEP0:>v127-debug.flod(1), FEP0:>v127-info.flod(2), on Lisp Machine Georg Friedrich Bernhard Riemann:

Riemann's screen needs  to be shifted downward.
The top line is off the visible part of the screen.

Harry Voorhees
16-Feb-86 13:33:12-EST,489;000000000000
Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 16 Feb 86 13:33-EST
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 16 FEB 86  13:33:51 EST
Date: Sun 16 Feb 86 13:22-EST
From: "David M. Siegel" <DMS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: MIT-AI-GW (MIT-KLUDGE) is dead.
To: bug-hardware@MC.LCS.MIT.EDU
CC: jnc@MC.LCS.MIT.EDU

MIT-AI-GW doesn't boot. When you hit the boot switch the run light
flashes on, and then turns off. Power cycling doesn't help.
16-Feb-86 23:39:31-EST,481;000000000000
Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 16 Feb 86 23:39-EST
Received: from HERMES.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 16 FEB 86  23:39:58 EST
Received: by hermes.AI.MIT.EDU; Sun, 16 Feb 86 13:13:48 est
Date: Sun, 16 Feb 86 13:13:48 est
From: dms@hermes.AI.MIT.EDU (David M. Siegel)
To: bug-hardware@mc
Cc: jnc@mc
Subject: MIT-KLUDGE (MIT-AI-GW) is dead.

Rebooting it doesn't help. The run light flashes on and then goes off
again. 

-Dave
17-Feb-86 23:05:11-EST,610;000000000000
Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 17 Feb 86 23:05-EST
Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 17 Feb 86 23:05:46 EST
Date: Mon 17 Feb 86 23:05:25-EST
From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
Subject: Re: MIT-KLUDGE (MIT-AI-GW) is dead.
To: dms@HERMES.AI.MIT.EDU, bug-hardware@MC.LCS.MIT.EDU
cc: JNC@XX.LCS.MIT.EDU
In-Reply-To: Message from "dms@hermes.AI.MIT.EDU (David M. Siegel)" of Sun 16 Feb 86 23:39:51-EST
Message-ID: <12184235652.15.JNC@XX.LCS.MIT.EDU>

	Well, it might work a little better if some pinhead hadn't turned
on the "HALT" switch.
-------
17-Feb-86 23:14:21-EST,771;000000000000
Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 17 Feb 86 23:14-EST
Received: from XX.LCS.MIT.EDU by MC.LCS.MIT.EDU 17 Feb 86 22:58:13 EST
Date: Mon 17 Feb 86 22:57:46-EST
From: "J. Noel Chiappa" <JNC@XX.LCS.MIT.EDU>
Subject: Re: MIT-AI-GW (MIT-KLUDGE) is dead.
To: DMS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, bug-hardware@MC.LCS.MIT.EDU
cc: JNC@XX.LCS.MIT.EDU
In-Reply-To: Message from ""David M. Siegel" <DMS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>" of Sun 16 Feb 86 13:33:51-EST
Message-ID: <12184234261.15.JNC@XX.LCS.MIT.EDU>

	This is not a bug. The machine has no boot card in it. You have to
load it over the console serial line from the timesharing machine. I have
asked people in the AI Lab to provide a boot card, but nobody's interested.
	Noel
-------
17-Feb-86 23:14:35-EST,381;000000000000
Mail-From: SHAFEI created at 17-Feb-86 23:14:25
Date: Mon, 17 Feb 1986  23:14 EST
Message-ID: <SHAFEI.12184237290.BABYL@MIT-OZ>
From: SHAFEI@OZ.AI.MIT.EDU
To:   bug-hardware@OZ.AI.MIT.EDU
Subject: Velo Binder


It's completely dead, and I've a thesis to submit. 
Do you have any idea when it'll work, or is there another one, somewhere?

					Thanx in advance.
-nayel
20-Feb-86 10:23:42-EST,701;000000000000
Received: from RIEMANN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 20 Feb 86 10:23-EST
Date: Thu, 20 Feb 86 10:24 EST
From: Harry L. Voorhees <HLV@OZ.AI.MIT.EDU>
Subject: Riemann's screen blurry
To: BUG-HARDWARE@OZ.AI.MIT.EDU
Message-ID: <860220102422.1.HLV@RIEMANN.AI.MIT.EDU>

In Symbolics 3600 Hardware in Release 6.1, IP-TCP 29.13,
6-1-Patches 1.10, AISite 13.2, Macsyma 310.35, microcode TMC5-MIC 336,
FEP 127, FEP0:>v127-lisp.flod(2), FEP0:>v127-loaders.flod(2),
FEP0:>v127-debug.flod(1), FEP0:>v127-info.flod(2), on Lisp Machine Georg Friedrich Bernhard Riemann:

The edges of Riemann's screen are blurry when the intensity is turned
up.  (Riemann is near the TV on the 7th floor.)
 5-Mar-86 10:49:08-EST,612;000000000000
Received: from GAUSS.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 5 Mar 86 10:48-EST
Date: Wed, 5 Mar 86 10:48 EST
From: Harry L. Voorhees <HLV@OZ.AI.MIT.EDU>
Subject: Gauss's screen is blurry
To: BUG-HARDWARE@OZ.AI.MIT.EDU
Message-ID: <860305104857.1.HLV@GAUSS.AI.MIT.EDU>

In Symbolics 3600 Hardware in Release 6.1, IP-TCP 29.13,
6-1-Patches 1.11, AISite 13.4, Macsyma 310.35, microcode TMC5-MIC 336,
FEP 127, FEP0:>v127-lisp.flod(2), FEP0:>v127-loaders.flod(2),
FEP0:>v127-debug.flod(1), FEP0:>v127-info.flod(2), on Lisp Machine Karl Friedrich Gauss:

The edges of Gauss's screen are blurry.--Harry
 6-Mar-86 09:40:28-EST,700;000000000000
Received: from RIEMANN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 6 Mar 86 09:40-EST
Date: Thu, 6 Mar 86 09:40 EST
From: Harry L. Voorhees <HLV@OZ.AI.MIT.EDU>
Subject: Riemann's screen out of whack
To: BUG-HARDWARE@OZ.AI.MIT.EDU
Message-ID: <860306094056.1.HLV@RIEMANN.AI.MIT.EDU>

In Symbolics 3600 Hardware in Release 6.1, IP-TCP 29.13,
6-1-Patches 1.11, AISite 13.4, Macsyma 310.35, microcode TMC5-MIC 336,
FEP 127, FEP0:>v127-lisp.flod(2), FEP0:>v127-loaders.flod(2),
FEP0:>v127-debug.flod(1), FEP0:>v127-info.flod(2), on Lisp Machine Georg Friedrich Bernhard Riemann:

The bottom of Riemann's screen has weird stripes across it.
It looks like every other scan line is off.

Harry
 7-Mar-86 12:52:19-EST,5010;000000000000
Received: from REAGAN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 7 Mar 86 12:51-EST
Received: from POINCARE.AI.MIT.EDU by MIT-REAGAN.ARPA via CHAOS with CHAOS-MAIL id 25056; Fri 7-Mar-86 08:58:21-EST
Date: Fri, 7 Mar 86 08:56 EST
From: John C. Mallery <JCMA@MIT-AI.ARPA>
Subject: Tape drive losing on Poincare
To: BUG-LISPM@OZ.AI.MIT.EDU, bug-hardware@OZ.AI.MIT.EDU
Message-ID: <860307085655.1.JCMA@POINCARE.AI.MIT.EDU>

In Symbolics 3670 Release 6.1, IP-TCP 29.13, 6-1-Patches 1.11,
AISite 13.4, Macsyma 310.35, COLOR 135.50, COLOR-EXTENSIONS 4.6,
COLOR-DEMO 68.7, COLOR-EDITOR 4.1, COLOR-PALETTE 2.1, IMAGES 56.21,
MENU 6.1, microcode TMC5-IO4-FPA-COLOR-MIC 336, FEP 127,
FEP0:>v127-lisp.flod(2), FEP0:>v127-loaders.flod(2),
FEP0:>v127-debug.flod(1), FEP0:>v127-info.flod(2), on Lisp Machine Jules Henri Poincare:



>>Error: Hard tape error: FEP/Command error: 40_16. (Accept timeout)
While in the function (:METHOD TAPE:CART-TAPE-STREAM-MIXIN :COMMAND)  (:METHOD TAPE:CART-TAPE-STREAM-MIXIN :AFTER :INIT)  (:INTERNAL (:METHOD TAPE:CART-OUTPUT-STREAM :COMBINED :INIT) 0)

(:METHOD TAPE:CART-TAPE-STREAM-MIXIN :COMMAND):  (P.C. = 33)
   Arg 0 (SELF): #<CART-OUTPUT-STREAM 24245433>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor TAPE:CART-TAPE-STREAM-MIXIN -- 17. IV's, 0. FL's 171075351>
   Arg 2 (SI:OPERATION): :COMMAND
   Arg 3 (TAPE:CODE): 1
   --Defaulted args:--
   Arg 4 (TAPE:IGNORE-ERROR): NIL

(:METHOD TAPE:CART-TAPE-STREAM-MIXIN :AFTER :INIT):  (P.C. = 254)
   Arg 0 (SELF): #<CART-OUTPUT-STREAM 24245433>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor TAPE:CART-TAPE-STREAM-MIXIN -- 17. IV's, 0. FL's 171075351>
   Arg 2 (SI:OPERATION): :INIT
   Rest arg (IGNORE): (#<DTP-LOCATIVE 500310>)

(:INTERNAL (:METHOD TAPE:CART-OUTPUT-STREAM :COMBINED :INIT) 0):  (P.C. = 12)
   Arg 0 (SELF): #<CART-OUTPUT-STREAM 24245433>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor TAPE:CART-OUTPUT-STREAM -- 0. IV's, 6. FL's 171075331>
   Arg 2 (SI:.OPERATION.): :INIT
   Rest arg (SI:.DAEMON-CALLER-ARGS.): (#<DTP-LOCATIVE 500310>)

(:METHOD TAPE:CART-TAPE-STREAM-MIXIN :WHOPPER :INIT):  (P.C. = 52)
   Arg 0 (SELF): #<CART-OUTPUT-STREAM 24245433>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor TAPE:CART-TAPE-STREAM-MIXIN -- 17. IV's, 0. FL's 171075351>
   Arg 2 (SI:.WHOPPER-CONTINUATION.): #<DTP-COMPILED-FUNCTION (:INTERNAL (:METHOD TAPE:CART-OUTPUT-STREAM :COMBINED :INIT) 0) 67033247>
   Arg 3 (SI:.OLD-SELF-MAPPING-TABLE.): #<Map to flavor TAPE:CART-OUTPUT-STREAM -- 0. IV's, 6. FL's 171075331>
   Arg 4 (SI:.OPERATION.): :INIT
   Rest arg (ARGS): (#<DTP-LOCATIVE 500310>)

(:METHOD TAPE:CART-OUTPUT-STREAM :COMBINED :INIT):  (P.C. = 13)
   Arg 0 (SELF): #<CART-OUTPUT-STREAM 24245433>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor TAPE:CART-OUTPUT-STREAM -- 0. IV's, 6. FL's 171075331>
   Arg 2 (SI:.OPERATION.): :INIT
   Rest arg (SI:.DAEMON-CALLER-ARGS.): (#<DTP-LOCATIVE 500310>)

INSTANTIATE-FLAVOR:  (P.C. = 445)
   Arg 0 (SI:FLAVOR-NAME): TAPE:CART-OUTPUT-STREAM
   Arg 1 (SI:INIT-PLIST): #<DTP-LOCATIVE 500310>
   Arg 2 (SI:SEND-INIT-MESSAGE-P): :MAYBE
   --Defaulted args:--
   Arg 3 (SI:RETURN-UNHANDLED-KEYWORDS-P): NIL
   Arg 4 (SI:AREA-TO-CONS-INSTANCE-IN): NIL

MAKE-INSTANCE:  (P.C. = 6)
   Arg 0 (SI:FLAVOR-NAME): TAPE:CART-OUTPUT-STREAM
   Rest arg (SI:INIT-OPTIONS): (:DIRECTION :OUTPUT :REEL NIL :LOCK-REASON "local machine" :NUMBER-OF-BUFFERS NIL)

TAPE:MAKE-CART-TAPE-STREAM:  (P.C. = 37)
   Rest arg (ARGS): (:DIRECTION :OUTPUT :REEL NIL :LOCK-REASON "local machine" :NUMBER-OF-BUFFERS NIL)

TAPE:MAKE-STREAM:  (P.C. = 532)
   Rest arg: (:DIRECTION :OUTPUT :UNIT "CART" :HOST #<LISPM-HOST POINCARE 43310207>)

TAPE:FEP-TAPE-GET-OUTPUT-STREAM:  (P.C. = 32)
   --Defaulted args:--
   Arg 0 (TAPE:HOST): #<LISPM-HOST POINCARE 43310207>

TAPE:WRITE-FEP-FILES-TO-TAPE:  (P.C. = 12)
   --Defaulted args:--
   Arg 0 (TAPE:MIC-NAME): NIL

SI:*EVAL:  (P.C. = 401)
   Arg 0 (SI:FORM): (TAPE:WRITE-FEP-FILES-TO-TAPE)
   Local 0 (SI:FORM): NIL
   --Defaulted args:--
   Arg 1 (SI:ENV): NIL
   Arg 2 (SI:HOOK): NIL

(:INTERNAL SI:LISP-COMMAND-LOOP-INTERNAL 0):  (P.C. = 152)
   Arg 0 (COMPILER:.LEXICAL-ENVIRONMENT-POINTER.): #<DTP-LOCATIVE 500047>

TV:WITH-NOTIFICATION-MODE-INTERNAL:  (P.C. = 16)
   Arg 0 (TV:NEW-MODE): :BLAST
   Arg 1 (TV:STREAM): #:TERMINAL-IO-SYN-STREAM
   Arg 2 (TV:CONTINUATION): #<LEXICAL-CLOSURE (:INTERNAL SI:LISP-COMMAND-LOOP-INTERNAL 0) 500054>

SI:LISP-COMMAND-LOOP-INTERNAL:  (P.C. = 54)
   Arg 0 (SI:NAME): "Lisp Top Level"
   Arg 1 (SI:ABORT-FUNCTION): NIL
   Arg 2 (SI:READ-FUNCTION): NIL
   Arg 3 (SI:EVAL-FUNCTION): NIL
   Arg 4 (SI:PRINT-FUNCTION): NIL

SI:LISP-COMMAND-LOOP:  (P.C. = 67)
   Arg 0: #<LISP-LISTENER Lisp Listener 1 43200064 exposed>
   Rest arg: (:NAME "Lisp Top Level")

SI:LISP-TOP-LEVEL1:  (P.C. = 5)
   Arg 0 (SI:STREAM): #<LISP-LISTENER Lisp Listener 1 43200064 exposed>

SI:LISP-TOP-LEVEL:  (P.C. = 7)
 8-Mar-86 15:46:31-EST,670;000000000000
Received: from GAUSS.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 8 Mar 86 15:46-EST
Date: Sat, 8 Mar 86 15:44 EST
From: Harry Voorhees <HLV@OZ.AI.MIT.EDU>
Subject: Hurewicz's disk flaky again
To: BUG-HARDWARE@OZ.AI.MIT.EDU
Message-ID: <"860308154459.1.hlv@OZ"@GAUSS.AI.MIT.EDU>

Paul,

Hurewicz's disk is apparently fucked up again.  The machine crashed
twice in the last two days, today because of "Disk hardware or microtask
hung" error.  See the bug log on the table in 902.  If you can't
identify the problem, couldn't you try replacing the disk or something?
Its really frustrating to lose hours of work due to an unreliable
machine.  Thanks.

Harry
 8-Mar-86 16:16:41-EST,892;000000000000
Received: from HILBERT.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 8 Mar 86 16:16-EST
Date: Sat, 8 Mar 86 16:15 EST
From: Harry L. Voorhees <HLV@OZ.AI.MIT.EDU>
Subject: Hilbert is flaky too
To: BUG-HARDWARE@OZ.AI.MIT.EDU
Message-ID: <860308161529.1.HLV@HILBERT.AI.MIT.EDU>

In Symbolics 3600 Hardware in Release 6.1, IP-TCP 29.13,
6-1-Patches 1.11, AISite 13.4, Macsyma 310.35, Manip 5.19, Puma 5.15,
microcode TMC5-MIC 336, FEP 127, FEP0:>v127-lisp.flod(2),
FEP0:>v127-loaders.flod(2), FEP0:>v127-info.flod(2),
FEP0:>v127-debug.flod(1), on Lisp Machine David Hilbert:

Paul,

Hilbert just crashed to a page fault on unallocated VMA....error.  It
crashed while the garbage collector was on.  This is the same problem
that kept occurring earlier this year.  Fortunatlely, warm booting it
was successful, but I wouldn't be surprised if it crashes irrecoverably
soon.

Harry
15-Apr-86 02:33:49-EST,731;000000000000
Received: from MOSCOW-CENTRE.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 15 Apr 86 02:33-EST
Date: Tue, 15 Apr 86 02:32 EST
From: David M. J. Saslav <saz@OZ.AI.MIT.EDU>
Subject: blankline bug
To: BUG-ZWEI@OZ.AI.MIT.EDU, BUG-hardware@OZ.AI.MIT.EDU
Message-ID: <860415023244.6.SAZ@MOSCOW-CENTRE.AI.MIT.EDU>

In Symbolics 3640 Editor in Release 6.1, IP-TCP 29.13, 6-1-Patches 1.13,
AISite 14.5, Macsyma 318.23, FORTRAN 49.4, PASCAL 31.0,
microcode TMC5-IO4-COL-MIC 353, FEP 127, FEP0:>V127-LISP.FLOD(2),
FEP0:>V127-LOADERS.FLOD(3), FEP0:>V127-INFO.FLOD(2),
FEP0:>V127-DEBUG.FLOD(1), on Lisp Machine Moscow Centre:

creating and deleting blanklines in editor settings causes
a weird screen glitch on this machine.




18-Apr-86 10:41:56-EST,450;000000000000
Received: from GAUSS.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 18 Apr 86 10:41-EST
Date: Fri, 18 Apr 86 10:41 EST
From: Harry Voorhees <HLV@OZ.AI.MIT.EDU>
Subject: Hurewicz's disk still flaky
To: BUG-HARDWARE@OZ.AI.MIT.EDU
Message-ID: <"860418104148.1.hlv@OZ"@GAUSS.AI.MIT.EDU>

Hurewicz is still having disk problems.  The machine is unusable, as it can't
be booted.  The error is

Proceedable disk error  0 1006 14 13.

Harry Voorhees
30-Apr-86 14:45:51-EDT,368;000000000000
Received: from DEEP-THOUGHT.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 30 Apr 86 14:45-EDT
Date: Wed 30 Apr 86 14:43:56-EDT
From: David C. Anderson <DCA@DEEP-THOUGHT.MIT.EDU>
Subject: la120 manual
To: bug-hardware@OZ.AI.MIT.EDU
Message-ID: <12203007807.35.DCA@DEEP-THOUGHT.MIT.EDU>

Do you have a copyable la120 service manual we can borrow?

						dca
-------
 1-May-86 06:10:03-EDT,693;000000000000
Received: from AI.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 1 May 86 06:09-EDT
Date: Thu,  1 May 86 06:09:52 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: la120 manual
To: DCA@DEEP-THOUGHT.MIT.EDU
cc: bug-hardware@OZ.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].33426.860501.CENT>

    Date: Wed 30 Apr 86 14:43:56-EDT
    From: David C. Anderson <DCA@DEEP-THOUGHT.MIT.EDU>
    Subject: la120 manual
    To: bug-hardware@OZ.AI.MIT.EDU
    Do you have a copyable la120 service manual we can borrow?
						    dca

we have a (two, actually, that i can lay my hands on) LA120 user guide.
it's 100+ pages and seems relatively thorough. is this what you are
looking for?
 1-May-86 13:36:54-EDT,1257;000000000000
Received: from DEEP-THOUGHT.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 1 May 86 13:36-EDT
Date: Thu 1 May 86 13:35:37-EDT
From: Alan Wu <ALW@DEEP-THOUGHT.MIT.EDU>
Subject: Re: la120 manual
To: CENT@AI.AI.MIT.EDU
cc: DCA@DEEP-THOUGHT.MIT.EDU, bug-hardware@OZ.AI.MIT.EDU
In-Reply-To: <[AI.AI.MIT.EDU].33426.860501.CENT>
Message-ID: <12203257512.19.ALW@DEEP-THOUGHT.MIT.EDU>

     Maybe or maybe not.  We already have the "LA120 User Guide"
(EK-LA120-UG-004).  What we're looking for is the "maintenance manual"
or "service manual" or "technical manual" that tells us how to fix the
things.  We're having problems with a pair of LA120's which keep
breaking down every few weeks, and we'd like to borrow the manual long
enough for us to figure out if there's some subtle point about their
repair that we're overlooking.

     One place we know this manual should exist is in the microfiche
set which DEC publishes to cover all the hardware they sell.
Unfortunately, we're not sure if anybody at MIT has such a fiche set
or not.  A hardcopy version would also be useful (easier to read).

     In any case, thanks for responding.  We'd appreciate it if you
could forward this message to anybody who might be able to help us.
--Alan
-------
 7-May-86 15:45:59-EDT,1010;000000000000
Received: from REAGAN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 7 May 86 15:45-EDT
Received: from HUREWICZ.AI.MIT.EDU by MIT-REAGAN.ARPA via CHAOS with CHAOS-MAIL id 31305; Wed 7-May-86 15:46:44-EDT
Date: Wed, 7 May 86 15:46 EDT
From: Aaron F. Bobick <AFB@OZ.AI.MIT.EDU>
Subject: Gauss Console
To: BUG-HARDWARE@OZ.AI.MIT.EDU
Message-ID: <860507154629.1.AFB@HUREWICZ.AI.MIT.EDU>

In Symbolics 3600 Hardware in Release 6.1, IP-TCP 29.13,
6-1-Patches 1.14, AISite 14.7, Macsyma 318.23, FORTRAN 49.4, PASCAL 31.0,
microcode TMC5-COL-MIC 353, FEP 127, Fep0:>v127-lisp.flod(2),
Fep0:>v127-loaders.flod(2), Fep0:>v127-debug.flod(1),
Fep0:>v127-info.flod(2), on Lisp Machine Witold Hurewicz:

The console on Gauss is not working.  We (AFB and PAO) plugged the cable
into the Hurewicz console, and Gauss was working fine.

(Someone was working on the Gauss' console earlier this morning.  Said
it was a power supply problem -- machine stopped working about 3 hours
after he left.)

Aaron Bobick

 8-May-86 07:16:01-EDT,484;000000000000
Received: from MC.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 8 May 86 07:15-EDT
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 8 MAY 86  07:17:22 EDT
Date: Thu,  8 May 86 07:17:23 EDT
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Subject: broken tty
To: BUG-HARDWARE@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].36103.860508.CENT>

the MX system console (LA120) is broken; it can't hear its keyboard.  this
is a large mistake and should be corrected posthaste.
16-May-86 14:51:02-EDT,1122;000000000000
Received: from REAGAN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 16 May 86 14:50-EDT
Received: from DUANE.AI.MIT.EDU by MIT-REAGAN.ARPA via CHAOS with CHAOS-MAIL id 32448; Fri 16-May-86 14:48:16-EDT
Date: Fri, 16 May 86 14:46 EDT
From: Harry L. Voorhees <HLV@OZ.AI.MIT.EDU>
Subject: Disk errors on DUANE now
To: bug-symbolics-hardware@OZ.AI.MIT.EDU, BUG-HARDWARE@OZ.AI.MIT.EDU
Message-ID: <860516144637.2.HLV@DUANE.AI.MIT.EDU>

In Symbolics 3670 Hardware in Release 6.1, IP-TCP 29.13,
6-1-Patches 1.15, AISite 14.8, microcode TMC5-IO4-COL-MIC 353, FEP 127,
FEP0:>v127-lisp.flod(5), FEP0:>v127-loaders.flod(5),
FEP0:>v127-debug.flod(10), FEP0:>v127-info.flod(5),
on Lisp Machine Duane Allman:
Warm booted from: Zmail background,
ADDRESS-SPACE-WARNING, Lisp Listener 1.

Lisp stopped itself while garbage collecting and paging on Duane.  

Fatal disk error at unit 0, cyl 326, head 7, sector 0(8). "Fatal ECC error"

The machine was warm bootable once I turned the garbage collector off,
but this error at the same disk location occurred three times while
attempting to warm boot it.

Harry Voorhees
30-May-86 04:32:33-EDT,489;000000000000
Received: from REAGAN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 30 May 86 04:32-EDT
Received: from BUDDY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 34005; Fri 30-May-86 04:29:47-EDT
Date: Fri, 30 May 86 04:30 EDT
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: 3600 broken keyboard
To: bug-hardware@OZ.AI.MIT.EDU
Message-ID: <860530043058.4.CFRY@BUDDY.AI.MIT.EDU>

Look around buddy [ne43-708] or duane for a 3600 keyboard
with a severly damaged space bar.
 3-Jun-86 14:21:40-EDT,1035;000000000000
Received: from REAGAN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 3 Jun 86 14:21-EDT
Received: from MOSCOW-CENTRE.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 34501; Tue 3-Jun-86 14:22:49-EDT
Date: Tue, 3 Jun 86 14:21 EDT
From: Jerry Roylance <GLR@OZ.AI.MIT.EDU>
Subject: Wronski receiving Irrecoverable disk search errors every few minutes
To: BUG-HARDWARE@OZ.AI.MIT.EDU
Message-ID: <860603142134.1.GLR@MOSCOW-CENTRE.AI.MIT.EDU>

In Symbolics 3640 Hardware in Release 6.1, IP-TCP 29.13,
6-1-Patches 1.15, AISite 16.1, Macsyma 318.23, FORTRAN 49.4, PASCAL 31.0,
Japanese 24.2, microcode TMC5-IO4-COL-MIC 353, FEP 127,
FEP0:>v127-lisp.flod(5), FEP0:>v127-loaders.flod(5),
FEP0:>v127-info.flod(5), FEP0:>v127-debug.flod(10), on Lisp Machine Moscow Centre:

 Wronski (rm. 745) is receiving irrecoverable disk search errors every few minutes.
This occurs whenever I do much in the way of file transactions.  On top of the
monitor are two sheets of paper showing the results of :Show Status for two
crashes.
11-Jun-86 14:23:31-EDT,1026;000000000000
Received: from REAGAN.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 11 Jun 86 14:23-EDT
Received: from TAYLOR.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 36116; Wed 11-Jun-86 14:22:24-EDT
Date: Wed, 11 Jun 86 14:21 EDT
From: Walter E. Gillett <GILLETT@PYGMALION.AI.MIT.EDU>
Subject: console problem
To: BUG-HARDWARE@OZ.AI.MIT.EDU
Message-ID: <"860611142138.1.gillett@PYGMALION"@TAYLOR.AI.MIT.EDU>

In Symbolics 3640 Hardware in Release 6.1, IP-TCP 29.13,
6-1-Patches 1.16, AISite 16.2, Macsyma 318.23, FORTRAN 49.4, PASCAL 31.0,
Japanese 24.2, microcode TMC5-IO4-COL-MIC 353, FEP 127,
FEP0:>v127-lisp.flod(5), FEP0:>v127-loaders.flod(5),
FEP0:>v127-info.flod(5), FEP0:>v127-debug.flod(10), on Lisp Machine Brook Taylor:

Some imbecile seems to have spilled coffee on the keyboard/mouse of this
machine (Brook Taylor, 7th floor, near the TV).  The "k" is sticky, as
are the middle and right keys on the mouse.  I would appreciate it if
someone could check it out.  Thanks.

Walter (gillett@oz)
