From owner-cvs-sys  Wed Jan 28 23:49:53 1998
Return-Path: <owner-cvs-sys>
Received: (from daemon@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id XAA22843
          for cvs-sys-outgoing; Wed, 28 Jan 1998 23:49:53 -0800 (PST)
          (envelope-from owner-cvs-sys)
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 <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 
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 <mike@smith.net.au>
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> >> >  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.  \\