>Now, about this specific ahc error (and this is why I've put Justin in Cc:)
>This error is quite reproductible, bus this sounds like a resources shortage
>rather than a real error.

No, it is a real error.  With 256 S/G segments, you can represent, worst
case, a 1MB I/O.  Since the kernel can only generate up to 64k I/Os, this
is a "can't happen" condition (we should only use 17 S/G segments max).
FreeBSD saw a similar problem perhaps a year and a half ago and it was
caused by a sign extension bug somewhere. You could ask phk@FreeBSD.org for
details since he tracked down and fixed the bug. 

>The process causing the error (and staying in the
>"D" state) can be doing large or small IO's, on an ffs or ext2fs.
>I think the reason ext2fs triggers this more easily is because it uses a lot
>of small blocks (1k blocks without clustering). So the question is:
>should't the driver return an error code wich would cause the command to be
>tried again, rather than an EIO ?

XS_DRIVER_STUFFUP should simply never be used.  It's never been handled
correctly by either the FreeBSD or NetBSD code.  I haven't had the time to
remove all of the calls since I made that observation though.

>--
>Manuel Bouyer, LIP6, Universite Paris VI.                 bouyer@masi.ibp.fr
>--

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================