[694] in linux-scsi channel archive
Re: Serious problem with SCSI error handling
daemon@ATHENA.MIT.EDU (Jurgen Botz)
Sat Oct 14 01:13:26 1995
To: ncr53c810@mroe.cs.colorado.edu, linux-scsi@vger.rutgers.edu
In-reply-to: Your message of "Fri, 13 Oct 1995 16:41:45 +1000."
<199510130641.QAA09426@fangorn.cs.monash.edu.au>
Date: Fri, 13 Oct 1995 15:23:15 -0400
From: Jurgen Botz <jbotz@orixa.mtholyoke.edu>
Update on my problems with SCSI error handling... I now believe that
the SCSI error-handling code gets flakey as a result of the GCC i486
strength-reduce bug. If this is so, it would be the first known
example of this bug biting the kernel. I would encourage everybody
who has been having problems to try recompiling the kernel with an
explicit -fno-strength-reduce. Even better, turn of strength-reduce
in your gcc 'specs' file to ensure that you'll never be bitten by this
bug. For those who don't know about it, the -fstrength-reduce
optimization in gcc generates incorrect code on i486 machines under
certain fairly specific (and rare) circumstances. This optimization
is normally included with '-O2', which is the default optimization for
kernel compiles. This bug exists in all recent versions of gcc through
2.7.0.
I still have bad blocks on my disks, and I'm still not sure that Linux
handles this condition as well as it might, but without strength-reduce
optimization I get consistent behavior and no kernel panics/lock-ups.
Before I got reports of different bad sectors on a second scan, and
occasional panics/lock-ups.
If anyone else whose been having problems can confirm that things get
better after recompiling with strength-reduce, that would be helpful.
--
Jurgen Botz, jbotz@mtholyoke.edu C:\ONGRATNS.W95!
"Unix? What's that? Is that like Linux?"