Copyright (c) 1999 Massachusetts Institute of Technology

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or (at
your option) any later version.

This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
------------------------------

			KL10 Folklore

Sometimes an MF10 memory gets hung.  Often the INC RQ light will be
on. Sometimes raising the RESET switch inside the memory's front door
will help; sometimes a module in the port control is fried.  (Any of
several modules.)

TU41 blower belt has to correct belt, has to not be worn out, and has
to have pulleys aligned.  Otherwise it drops off or breaks and tape
rotates backwards.

RP04 oscillating seeks & Maytag mode when loading => tachometer output
needs to be adjusted.

When powering machine back on, circuit breaker in disk DF10 may trip.

When powering machine back on, sometimes disk #0 needs to be stopped,
powered off and on, and started again, to reset the two-massbus
switch.

If DECtape motor doesn't win, may be G848 seating problem.

If kicking the LA36 causes power fail, "power warn" lead to top left
edge of CPU backplane needs to be disconnected.  (Apparently the other
end is unconnected.) [Missing ECO in 863.]

Bad door-open switches (?) in MF10.  Memories have to be operated with
over-ride turned on.

Apparently power supplies in CPU and IO box can drift voltages.

Apparently air-flow sensors can fail sporadically.  I am told that
disconnecting one => indication of good airflow.

RP04 attention/error conditions are super-random.

Often mysterious marginality is caused by bad seating of modules.

CONO'ing a PI channel off doesn't necessarily prevent it from
interrupting. It works to have each interrupt routine do CONSO to make
sure the channel is enabled, and dismiss if not.

Before running a memory diagnostic, do PE0, because the memory
diagnostics don't know how to handle parity faults.

MF10's always fail solidly.

Obscure cases in the microcode tend to have bugs.  E.g.  you could
interrupt out of a PI cycle, hence BLKI/BLKO as interrupt instructions
tended to be flakey.