Subject: Re: ahc and Semantics of the "COMPLETE" return code
To: Matthew Jacob <firstname.lastname@example.org>
From: Justin T. Gibbs <email@example.com>
Date: 06/23/1997 23:55:55
>>From tech-kern-owner-mjacob=feral.com@NetBSD.ORG Mon Jun 23 11:18:37 1997
>>>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).
>Unless, like NASA, you modify things to increase MAXPHYS to 1MB or better.
In that case, I certainly hope that you are dealing with "mostly contiguous"
buffers so that the target driver will always be able to service the request.
The aic7xxx driver can transfer up to 16MB at a time if it doesn't run
out of S/G segments. The current FreeBSD driver has the number of segments
reduced to 17 just to reduce the amount of wasted space taken up by the
driver, and anyone who expects to be able to do larger transfers should
be aware of this change.
Pluto made a few changes to physio to allow a user process to specify a
physical address to a chunck of device memory and the I/O we do can
also be quite large, but it's always to a contiguous piece of memory, so
the S/G list length doesn't affect us.
Justin T. Gibbs
FreeBSD: Turning PCs into workstations