[694] in linux-scsi channel archive

home help back first fref pref prev next nref lref last post

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?"

home help back first fref pref prev next nref lref last post