Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753306Ab1EHUaC (ORCPT ); Sun, 8 May 2011 16:30:02 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:53542 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750753Ab1EHU37 (ORCPT ); Sun, 8 May 2011 16:29:59 -0400 Subject: Re: [PATCH] sym53c8xx_2: avoid data corruption when disk rejects commands with QUEUE FULL From: James Bottomley To: Mikulas Patocka Cc: Matthew Wilcox , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Sun, 08 May 2011 15:29:55 -0500 Message-ID: <1304886595.4865.3.camel@mulgrave.site> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2735 Lines: 65 On Sun, 2011-05-08 at 21:00 +0200, Mikulas Patocka wrote: > [ the maintainer is not responding, so I'm sending this to other people ] > > sym53c8xx_2: avoid data corruption when disk rejects commands with QUEUE > FULL Could you describe the corruption, with logs? The behaviour you list below should may cause disk errors to the filesystem, but it shouldn't cause corruption. > When the controller encounters an error (including QUEUE FULL or BUSY > status), it aborts all not yet submitted requests in the function > sym_dequeue_from_squeue. This would be a driver bug: QUEUE_FULL or BUSY should never cause aborts of outstanding commands. > This function aborts them with DID_SOFT_ERROR. > > If the disk has a full tag queue, the request that caused the overflow is > aborted with QUEUE FULL status (and the scsi midlayer properly retries it > until it is accepted by the disk), but other requests are aborted with > DID_SOFT_ERROR --- for them, the midlayer does just a few retries and then > signals the error up to sd. > > The result is that disk returning QUEUE FULL causes request failures. > > The error was reproduced on 53c895 with COMPAQ BD03685A24 disk (rebranded > ST336607LC) with command queue 48 or 64 tags. The disk has 64 tags, but > under some access patterns it return QUEUE FULL when there are less than > 64 pending tags. The SCSI specification allows returning QUEUE FULL > anytime and it is up to the host to retry. > > Signed-off-by: Mikulas Patocka > > --- > drivers/scsi/sym53c8xx_2/sym_hipd.c | 4 ++++ > 1 file changed, 4 insertions(+) > > Index: linux-2.6.36-rc5-fast/drivers/scsi/sym53c8xx_2/sym_hipd.c > =================================================================== > --- linux-2.6.36-rc5-fast.orig/drivers/scsi/sym53c8xx_2/sym_hipd.c 2010-09-27 10:25:59.000000000 +0200 > +++ linux-2.6.36-rc5-fast/drivers/scsi/sym53c8xx_2/sym_hipd.c 2010-09-27 10:26:27.000000000 +0200 > @@ -3000,7 +3000,11 @@ sym_dequeue_from_squeue(struct sym_hcb * > if ((target == -1 || cp->target == target) && > (lun == -1 || cp->lun == lun) && > (task == -1 || cp->tag == task)) { > +#ifdef SYM_OPT_HANDLE_DEVICE_QUEUEING > sym_set_cam_status(cp->cmd, DID_SOFT_ERROR); > +#else > + sym_set_cam_status(cp->cmd, DID_REQUEUE); > +#endif This isn't a good idea ... that return code causes retries for ever. I think the correct fix is just to make the QUEUE_FULL handling in the driver work. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/