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

I have a hunch that the allocation is failing because something else
has used up all the available memory.  Presumably setting a low-water mark
(say 1) on the scsipi_xfer pool will ensure that there is at least some
memory available for disk I/O.  In this case, that might be enough - the
normal disk activity is the ipf log (low rate).  But, I'm not sure it will
solve the original problem - at a guess something else will end up with no
memory instead ;-)


Thanks,

J

-- 
  My other computer also runs NetBSD    /        Sailing at Newbiggin
        http://www.netbsd.org/        /   http://www.newbigginsailingclub.org/