From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ko005-0006tt-0w for qemu-devel@nongnu.org; Thu, 09 Oct 2008 14:12:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ko004-0006th-Io for qemu-devel@nongnu.org; Thu, 09 Oct 2008 14:12:36 -0400 Received: from [199.232.76.173] (port=39420 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ko004-0006te-CF for qemu-devel@nongnu.org; Thu, 09 Oct 2008 14:12:36 -0400 Received: from mail-gx0-f19.google.com ([209.85.217.19]:61925) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ko004-0001lP-Aw for qemu-devel@nongnu.org; Thu, 09 Oct 2008 14:12:36 -0400 Received: by gxk12 with SMTP id 12so383822gxk.10 for ; Thu, 09 Oct 2008 11:12:34 -0700 (PDT) Message-ID: Date: Thu, 9 Oct 2008 21:12:34 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] [PATCH] [v2] scsi-disk: correct SCSI error reporting In-Reply-To: <1223570090.4143.22.camel@frecb07144> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1223570090.4143.22.camel@frecb07144> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 10/9/08, Laurent Vivier wrote: > Hi, > > scsi-disk.c seems to not report to SCSI controller (through completion() > routine) the good error value. > > I've tested this by using a little program trying to read beyond the > end of the disk (see attachment read10.c) > > On real disk: > > # ./read10 /dev/sg0 > READ_10 duration=40 millisecs, resid=0, msg_status=0 status=2 sense=0 > driver_status 8 > > If I use this command with qemu and a scsi disk, the result is: > > # ./read10 /dev/sg0 > sym0: bad DSA (5da40ff) in done queue. > sd 0:0:0:0: ABORT operation started > sym0: SCSI BUS reset detected. > sym0: SCSI BUS has been reset. > sd 0:0:0:0: ABORT operation complete. > sd 0:0:0:0: ABORT operation started > sd 0:0:0:0: ABORT operation failed. > sd 0:0:0:0: DEVICE RESET operation started > target0:0:0: control msgout: c. > lsi_scsi: error: Unimplemented message 0x0c > target0:0:0: has been reset > sd 0:0:0:0: DEVICE RESET operation complete. > sd 0:0:0:0: DEVICE RESET operation started > target0:0:0: control msgout: c. > lsi_scsi: error: Unimplemented message 0x0c > target0:0:0: has been reset > sd 0:0:0:0: DEVICE RESET operation complete. > sd 0:0:0:0: M_REJECT received (0:0). > sd 0:0:0:0: M_REJECT received (0:0). > READ_10 duration=30032 millisecs, resid=0, msg_status=0 status=0 sense=0 > driver_status 0 > > The following patch corrects this issue by sending to the controller not > the sense key but the status code. > > The result of the command is now: > > # ./read10 /dev/sg0 > READ_10 duration=0 millisecs, resid=0, msg_status=0 status=2 sense=0 > driver_status 8 > > This patch has been tested with linux (x86_64 and sparc) and windows XP. > > The VERIFY commands has been implemented (empty) because previously it > was simply ignored (and it is needed by windows to format disks). > > Changelog: > > [v2] The v1 was very close to the (reversed) patch of Marcelo Tosatti > (r4260) which was breaking sparc scsi support. In fact, management of > invalid LUN was wrong: on an invalid LUN, disk sends a SCSI status of > "CHECK_CONDITION" and the driver sends "REQUEST_SENSE" to retrieve the > sense key. The disk must accept and answer to this request (to send the > sense key ILLEGAL_REQUEST). Moreover, INQUIRY with an invalid LUN must > answer with PERIPHERAL QUALIFIER field set to 011b and PERIPHERAL DEVICE > TYPE field set to 1Fh. This patch fixes LUN handling and does not cause problems like the earlier one. I'd like to apply this in a few days, unless there are objections.