--- On Sun, 2/3/08, Mike Snitzer <[EMAIL PROTECTED]> wrote: > From: Mike Snitzer <[EMAIL PROTECTED]> > Subject: Re: [PATCH] [SCSI] sd: make error handling more robust (v2) > To: "James Bottomley" <[EMAIL PROTECTED]> > Cc: "Tony Battersby" <[EMAIL PROTECTED]>, "linux-scsi@vger.kernel.org" > <linux-scsi@vger.kernel.org>, "Luben Tuikov" <[EMAIL PROTECTED]>, "Salyzyn, > Mark" <[EMAIL PROTECTED]> > Date: Sunday, February 3, 2008, 7:14 AM > On Feb 2, 2008 5:06 PM, James Bottomley > <[EMAIL PROTECTED]> wrote: > > > > On Fri, 2008-02-01 at 12:03 -0500, Tony Battersby > wrote: > > > This patch fixes a problem with some out-of-spec > SCSI disks that report > > > hardware or medium errors incorrectly. Without > the patch, the kernel > > > may silently ignore a failed write command or > return corrupted data on a > > > failed read command. > > > > > > Signed-off-by: Tony Battersby > <[EMAIL PROTECTED]> > > > --- > > > > > > This is a simplified version of the original > patch that fixes just the > > > problem at hand, without trying to handle other > theoretical out-of-spec > > > cases. > > > > Actually, to restore the original check, this is what > we want, isn't it? > > Ok, so I also made the sector division logic > futureproof for the day we > > have > 4096 sector devices ... > > > > James > > > > --- > > > > >From 5ae2e4a8ff095aab5997f17068d3e4212c33f039 Mon > Sep 17 00:00:00 2001 > > From: Tony Battersby <[EMAIL PROTECTED]> > > Date: Fri, 1 Feb 2008 12:03:27 -0500 > > Subject: [SCSI] sd: make error handling more robust > > > > This patch fixes a problem with some out-of-spec SCSI > disks that report > > hardware or medium errors incorrectly. Without the > patch, the kernel > > may silently ignore a failed write command or return > corrupted data on a > > failed read command. > > > > Signed-off-by: Tony Battersby > <[EMAIL PROTECTED]> > > Cc: Stable Tree <[EMAIL PROTECTED]> > > Signed-off-by: James Bottomley > <[EMAIL PROTECTED]> > > I've verified that this patch fixes the 2.6.22.16 SCSI > IO error > propagation issue I had when physically pulling a drive > from an > enclosure connected to an aacraid controller.
Just as in your case and Tony's case, which I presume uses the same RAID firmware vendor, it would've probably been better if the RAID firmware vendor fixed the firmware to not set the VALID bit if the INFORMATION field is not valid. Luben - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
