Date: Thu, 29 Jan 1998 18:12:46 +1030 From: Mike Smith <mike@smith.net.au> To: Bruce Evans <bde@zeta.org.au> 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 Message-ID: <199801290742.SAA02142@word.smith.net.au> In-Reply-To: Your message of "Thu, 29 Jan 1998 03:35:00 %2B1100." <199801281635.DAA13107@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> > >> > 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 = <max i/o size in bytes>; > > 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. \\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801290742.SAA02142>