Date: Thu, 29 Jan 1998 18:48:17 +1030 From: Mike Smith <mike@smith.net.au> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-sys@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/isa wfd.c Message-ID: <199801290818.SAA02267@word.smith.net.au> In-Reply-To: Your message of "Thu, 29 Jan 1998 19:13:53 %2B1100." <199801290813.TAA18259@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>>> 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 = <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. > > 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. \\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801290818.SAA02267>