From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDfJS-0003GJ-KY for qemu-devel@nongnu.org; Thu, 26 Nov 2009 09:27:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDfJN-0003D4-Da for qemu-devel@nongnu.org; Thu, 26 Nov 2009 09:27:14 -0500 Received: from [199.232.76.173] (port=41370 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDfJN-0003CR-2G for qemu-devel@nongnu.org; Thu, 26 Nov 2009 09:27:09 -0500 Received: from cantor2.suse.de ([195.135.220.15]:34751 helo=mx2.suse.de) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NDfJL-00074A-2b for qemu-devel@nongnu.org; Thu, 26 Nov 2009 09:27:07 -0500 Message-ID: <4B0E9036.2070400@suse.de> Date: Thu, 26 Nov 2009 15:27:02 +0100 From: Hannes Reinecke MIME-Version: 1.0 Subject: Re: [Qemu-devel] [sneak preview] major scsi overhaul References: <4AF4ACA5.2090701@redhat.com> <200911161853.34668.paul@codesourcery.com> <4B0BCAA1.3090400@redhat.com> <200911241351.03650.paul@codesourcery.com> <4B0D5D36.6080100@redhat.com> <4B0E2EC8.7040309@suse.de> <4B0E3B90.5080001@redhat.com> <4B0E5EFD.6060701@suse.de> <4B0E60AF.9000508@redhat.com> <4B0E6496.1060203@suse.de> <4B0E8EF6.2080106@redhat.com> In-Reply-To: <4B0E8EF6.2080106@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Paul Brook , qemu-devel@nongnu.org Gerd Hoffmann wrote: > On 11/26/09 12:20, Hannes Reinecke wrote: >> Gerd Hoffmann wrote: >>> /me looks at drivers/scsi/sd.c:sd_done() >>> >>> I can't see any sane way to tell linux that the request was too big. >>> >> residuals is the key: >> >> drivers/scsi/scsi.c:scsi_finish_command() >> >> >> good_bytes =3D scsi_bufflen(cmd); >> if (cmd->request->cmd_type !=3D REQ_TYPE_BLOCK_PC) { >> int old_good_bytes =3D good_bytes; >> drv =3D scsi_cmd_to_driver(cmd); >> if (drv->done) >> good_bytes =3D drv->done(cmd); >=20 > drv->done() actually is sd_done() mentioned above. >=20 > sd_done() tries to figure how many sectors it actually got for serious > errors. I don't feel signaling "medium error" for the first sector > behind our limit just because we'd like to have smaller requests. >=20 >> /* >> * USB may not give sense identifying bad sector and >> * simply return a residue instead, so subtract off the >> * residue if drv->done() error processing indicates no >> * change to the completion length. >> */ >> if (good_bytes =3D=3D old_good_bytes) >> good_bytes -=3D scsi_get_resid(cmd); >=20 > Poor mans bad sector identification. Same issue as above IMHO. On top > of that I wouldn't expect all other guest OSes having the same quirk in > there to handle usb disks. >=20 Sigh. Communication seems to be tricky here. Please, just ignore scsi_finish_command(), it's not doing anything useful here. Do skip this and study the next snipped, scsi_io_completion(): drivers/scsi/scsi_lib.c:scsi_io_completion() /* * A number of bytes were successfully read. If there * are leftovers and there is some kind of error * (result !=3D 0), retry the rest. */ if (scsi_end_request(cmd, error, good_bytes, result =3D=3D 0) =3D=3D NUL= L) return; scsi_end_request is being called with the number of bytes _actually proce= ssed_, which might be less than the number of bytes requested. And the remainder will be retried by the upper layers. Cheers, Hannes --=20 Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg GF: Markus Rex, HRB 16746 (AG N=FCrnberg)