3/60 panics, tape vs. Wren V
>probability - eg. 90% of the time), when I try to access the tape
>drive (eg. to backup sd2 onto tape)...
Apparently, the 3/60 vs. tape drive vs. 4.1.1 problem was "solved" by
sun-managers in early April and summarized by
rodney@snowhite.cis.uoguelph.ca.
It appears to be a software problem which can be avoided by *building*
the *full* GENERIC kernel on the problem machine.
I re-built the GENERIC kernel and have been running with it for about
two days now. I have not been able to crash the machine by accessing
the tape. This does not conclusively prove that my problem has gone
away, but it is already behaving much better than before.
In addition to the apparent improved reliability, I am certain that
the machine performs better overall with this rebuilt GENERIC kernel!
Windows pop open more promptly and cursor entries and exits are
recognized sooner. I'd been running the GENERIC_SMALL kernel (with
one minor change) for about a month and was absolutely convinced that
4.1.1 had pushed my machine over the memory-knee where the machine had
become a pig. With the rebuilt GENERIC kernel, I'm getting a response
more reminiscent of 4.0.3.
[My personal feeling, from watching clues go by, is that a bug has
been introduced into one of the SCSI drivers (tape or disk) - maybe
with the timing and/or tracking of phase changes, especially if
disconnects were happenning (eg. maybe the disk disconnects when doing
a long seek (I'm using a 553M partition) or a disconnect when the tape
is loaded and does its rewind). If the disk driver were buggy, this
might explain decreased system performance, especially when you have
a number of paged-out windows.]
kirk@zabriskie.berkeley.edu apparently has been given a non-released
patch to "locore".
I'm certain that I had tried using the full GENERIC kernel directly
from the distribution tape as an attempted solution, when my problems
started. This did not help - so, I conclude that you have to re-build
the GENERIC kernel (who says that there's no magic left in the
world?).
Many thanks to all of those who responded. Since another summary was
posted recently, I won't use up bandwidth re-posting it. I'll gladly
email it to anyone who requests it.
Paul Tarvydas
TS Controls
(416)-234-0889
tarvydas@tsctrl.uucp
on failure:tarvydas@turing.toronto.edu
