From owner-cvs-all Thu Jan 29 00:25:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA28462 for cvs-all-outgoing; Thu, 29 Jan 1998 00:25:17 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA28435; Thu, 29 Jan 1998 00:25:10 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id SAA02267; Thu, 29 Jan 1998 18:48:18 +1030 (CST) Message-Id: <199801290818.SAA02267@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Bruce Evans cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-sys@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/isa wfd.c In-reply-to: Your message of "Thu, 29 Jan 1998 19:13:53 +1100." <199801290813.TAA18259@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Jan 1998 18:48:17 +1030 From: Mike Smith 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. Dare I ask, then, why you suggested I should? > >> 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. Then it strikes me that you're suggesting a non-solution. Any other ideas? > >> 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. I could imagine wanting to change it in response to device behaviour (eg. overrun/underrun conditions, errors, etc.). In the light of queued requests this is certainly not helpful though. Time for CAM to take over. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\