>   Yesterday, while installing NetBSD, I succesfully reached the point, where
> I'd got to put the base, comp, and etc archives on my NetBSD partitions. 
> When tarred out the base.tgz (I've got on a GemDOS partition) the NetBSD told
> me that : st_pool is exhausted, binpatch 'st_ppol_size' to get more. 
>   And the tar did its job VERY slow. Now i don't know what to do, so please,
> help me.
Let me first explain the st_pool:
	The st_pool is a pool of st-memory blocks (addresses below 16Mb). Some
system components like the video and the ST-DMA controller can only access
memory below 16Mb. The pool is pre-allocated and the size is bounded by
'st_pool_size'.

The amount of memory used by the video is determined by the screen resolution
you use. An ST-HIGH screen uses 32Kb, an TT-MID 150Kb. I don't know the
exact figures for the Falcon modes. So selecting a 'proper' screen size
is a possibility to free up some of the st-pool.

The Falcon SCSI-driver also uses some memory from this pool. When I/O
is initiated on a physically non-contiguous memory block, the driver tries
to allocated a block from the pool (that is contiguous) and bounces the
request through that block. This is due to the fact that I could not find
a way to do broken-up DMA requests on the Falcon. If anybody can fix this,
_please_ do. If the requested memory is not available, the driver uses
programmed-io (which is _very_ slow).

The kernels I distribute are made to boot on systems with only 4Mb ram. So
the st_pool_size is quite low (+/- 90Kb). They also have 2 virtual consoles
configured. When you use ST-HIGH as video mode (on the Falcon, you should
boot in ST_HIGH to accomplish this), you should have enough room to satisfy
most of the SCSI-driver's requests. Other video modes might lead to pool
exhaustion.

The binpatch program mentioned is _not_ in the standard distribution.
I'll put it in the util.NetBSD directory as soon as possible. The program
let you patch global vars in the kernel. St_pool_size is one of them.

Leo.