From owner-cvs-all Wed Jan 28 23:50:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA22895 for cvs-all-outgoing; Wed, 28 Jan 1998 23:50:04 -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 XAA22826; Wed, 28 Jan 1998 23:49:41 -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 SAA02142; Thu, 29 Jan 1998 18:12:47 +1030 (CST) Message-Id: <199801290742.SAA02142@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Bruce Evans cc: mike@smith.net.au, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-sys@FreeBSD.ORG, msmith@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/isa wfd.c In-reply-to: Your message of "Thu, 29 Jan 1998 03:35:00 +1100." <199801281635.DAA13107@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Jan 1998 18:12:46 +1030 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe cvs-all" > > >> > Modified files: > >> > sys/i386/isa wfd.c > >> > Log: > >> > Fix operation with the Iomega Zip 100 ATAPI. > >> > 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. > >> > > >> > Revision Changes Path > >> > 1.3 +92 -13 src/sys/i386/isa/wfd.c > >> > >> 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? > 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. Is this a lower-performance approach than queueing multiple ATAPI requests? Do we care about performance with such a slow device? > >it was important that the fix be backportable. If d_maxio actually > >works (I recall John's commit implying that it wasn't completely done > >yet), then it would make sense to shift to using that for -current once > >we know that the fragmentation approach works. > > I think it works for wd, but many drivers are missing support for it. > It only takes one line per driver: > > xx_bdevsw.d_maxio = ; > > immediately after xx_bdevsw is initialized. ... so you can't change it on the fly? This is a serious defect. Thanks for the advice; it's greatly appreciated. -- \\ 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. \\