Hi - The clist and buffer cache UMRs are initialized at system boot time. And I haven't been around a UNIBUS system for a long time and the memory of having to deal with UMRs has faded. There are only 31 total - so a few allocated here, a few allocated there could result in not having enough. Swapping. The kernel has to always be able to get UMRs to be able to swap out a process. The memory is fuzzy but I think the kernel reserved 7 as to be able to swap 56KB at a time of a process but it could get by with less. One UMR is 'reserved' by the hardware to cover the "I/O Page". The clist takes up 1 UMR for DMA terminal devices. Ethernet of course takes a UMR or two. At one time a couple of the ethernet drivers (DEUNA) were a bit braindamaged and allocated more UMRs than they needed - I fixed that though. MSCP and TMSCP devices need UMRs to map their command and response rings. The initial MSCP driver was definitely suboptimal in that regard - again, something I tended to (the problem showed up when more than 1 controller was present in a system). Those UMRs are permanently allocated at boot time by the drivers when they initialize. Tape drivers need to have UMRs (although I don't know of too many folks with the old TE16 drives around on a UNIBUS system) available. It started adding up and on a system with several types of devices each of which wanted to reserve a couple UMRs the available pool for dynamic use (by tapes and swapping) was sometimes too small. Cheers, Steven Schultz