Subject: Re: ahc and Semantics of the "COMPLETE" return code
To: Manuel BOUYER <email@example.com>
From: Justin T. Gibbs <firstname.lastname@example.org>
Date: 06/23/1997 13:10:12
>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. email@example.com
Justin T. Gibbs
FreeBSD: Turning PCs into workstations