From owner-cvs-all Thu Jan 29 00:15:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA26399 for cvs-all-outgoing; Thu, 29 Jan 1998 00:15:52 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA26345; Thu, 29 Jan 1998 00:15:36 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id TAA18259; Thu, 29 Jan 1998 19:13:53 +1100 Date: Thu, 29 Jan 1998 19:13:53 +1100 From: Bruce Evans Message-Id: <199801290813.TAA18259@godzilla.zeta.org.au> To: bde@zeta.org.au, mike@smith.net.au Subject: Re: cvs commit: src/sys/i386/isa wfd.c Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-sys@FreeBSD.ORG, msmith@FreeBSD.ORG Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe cvs-all" >> >> > All known versions of this drive (firmware 21.* and 23.*) will lock up >> >> > if presented with a read/write request of > 64 blocks. In the presence >> >> > of such a unit, I/O requests of > 64 blocks are fragmented to avoid >> >> > this. >> >> ... >> >> You could simply reject such transfers. >> > >> >And then what happens to them? I spent some time trying to understand >> >> Nothing good. > >Then why would rejecting the transfers be useful? It wouldn't. > >> The driver strategy function may reduce the count >> to whatever it wants. > >It was not clear that this was legitimate; I infer from this that the >correct approach is to return a nonzero value in b_resid, which will >cause another call to the strategy routine. Is that correct? Will >this work on 2.2? It's certainly a *much* tidier approach than what I >am currently doing. Only for raw i/o. bread() and bwrite() don't even look at b_resid. They depend on the initial count being smaller than MAXBSIZE (getblk() enforces this by panicing if the count is larger), and on all drivers not truncating counts smaller than this size or counts that would be truncated not being used. >Is this a lower-performance approach than queueing multiple ATAPI >requests? Do we care about performance with such a slow device? It's probably insignificantly lower-performance even on much faster devices. >> xx_bdevsw.d_maxio = ; >> >> immediately after xx_bdevsw is initialized. > >... so you can't change it on the fly? This is a serious defect. Why would you want to change it? You can probably change it, but the changes won't affect queued requests. Bruce