[8186] in linux-scsi channel archive
Re: recovery behaviour with 1 bad + 1 good drive (aic7xxx)
daemon@ATHENA.MIT.EDU (Matthias Andree)
Wed Feb 23 12:54:12 2000
Date: Wed, 23 Feb 2000 18:30:41 +0100
From: Matthias Andree <ma@dt.e-technik.uni-dortmund.de>
To: Ishikawa <ishikawa@yk.rim.or.jp>
Cc: Guest section DW <dwguest@win.tue.nl>,
linux-scsi@vger.rutgers.edu
Message-ID: <20000223183041.D4697@krusty.e-technik.uni-dortmund.de>
Mail-Followup-To: Ishikawa <ishikawa@yk.rim.or.jp>,
Guest section DW <dwguest@win.tue.nl>, linux-scsi@vger.rutgers.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <38B36A28.645716E7@yk.rim.or.jp>; from ishikawa@yk.rim.or.jp on Wed, Feb 23, 2000 at 02:03:36PM +0900
> - SCSI bus slowed down due to certain errors. Again, I forgot
> what caused this type of messages, but there are occasions
> when the SunOS reported that the transfer between certain
> devices is graded down to a slower speed after seeing certain
> type of errors. I think this DOES involve RESET.
AFAICS, there is no reason, the speed is negotiated for every transfer,
it's just cached at some point.
> Anyway, it would be nice to see linux's SCSI system to become more robust
> in terms of handling these exceptional cases.
> These are exceptional indeed, but when they happen, we are
> often in a mess.
Still, it's a normal condition that a drive fails, be it that bad
blocks are not transparently reassigned, be it that a CD-ROM is
scratched.
> I would rather see the system run at reduced scsi bus
> speed if necessary and/or a process or two become hung
> than to face a non-working system not responding to our keyboard
> in the morning.
No way. If the bus goes too fast, let the machine crash hard. The
administrator can switch the speed, not the machine itself. If the bus
cable is too long, the user should know that and set a lower speed.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
