hi,

this error is basically a design flaw in the various disk drivers.
the scsi code is trying to allocate some memory to track the processing
of an i/o that's being initiated, but that allocation fails, so the
driver just fails the i/o.  a better response to this low-memory condition
would be to put the request (the struct buf) on a queue until some other
i/o completes, at which point we can reuse the scsipi_xfer structure
for the new i/o.  if we also set a low-water mark on the scsipi_xfer pool,
we'll be guaranteed that there is always some memory which will be able
to be used for this purpose (though we may have to wait a bit).
the lower level drivers that allocate memory as well (such as ncr53c9x)
should do this same thing to guarantee that they will have the memory
they need.

-Chuck


On Tue, Feb 17, 2004 at 12:01:48PM +0000, Julian Coleman wrote:
> My gateway/firewall machine died yesterday - no response to network.  On the
> console was a stream of "unable to allocate scsipi_xfer" messages.  It would
> let me log in but not much else.  What could cause the call to pool_get()
> (scsipi_base.c:466) to fail?  What can I use to debug/watch for this when it
> happens again?
> 
> Machine is a sparc 5 clone, 1.6ZG, bridge + ipf on 3 interfaces, and just
> ipf on a 4th.
> 
> Thanks,
> 
> J
> 
> -- 
>   My other computer also runs NetBSD    /        Sailing at Newbiggin
>         http://www.netbsd.org/        /   http://www.newbigginsailingclub.org/