Behavior of spi$cmd_buffer_Alloc  and spi$map_buffer

Spi$Cmd_buffer_alloc

pkcdriver - Can return error on overlarge buffer request or if
	debug code exists. Returns 0 as cmd buffer address if none
	was allocated from spdt$ps_rl_cmd_slot_alloc.

Cmd slot alloc routine in scsi2common. Comment says optional
	debugging code can return error, but I see no such in there.
	Looks like it always stalls and returns success eventually.

pkedriver - Returns error only if input cmd is too big.

pkjdriver - Returns error if alloc too large or on "optional debug"
	code (which seems not to be there).

pkqdriver - Err if size larger than qbuf or if RSPID cannot be
	allocated or if get_qbuf returns error. If fork and wait
	fails, returns error. Thus it can be dynamic. Ditto alloc
	rspid. Otherwise it waits.
	Does not return 0, just leaves value alone if fails.

pksdriver - Error if buffer too big. Calls scsi2common to allocate
	a command slot. Would return 0 in return if that failed, but
	that is another mystery "debug code" case. Otherwise stalls
	and retries. (This is where I thought a zero return could
	occur.)

pkzdriver - success all the time.


I conclude by this that the pkq rspid alloc failure is the only case
	where something dynamic may happen, and 0 is not returned
	there. Thus the sensible thing in dkdriver would seem to be
	never to wait, but some retries on the fork and wait may
	be ok. Whether to delay is a question here; it would seem
	to increase chances of success, but in most error cases
	a bugcheck in the port driver is probably better.


spi$buffer_map

pkcdriver - uses scsi2common. Can return ioc$load_map errors.

pkedriver - map_buffer returns normal always. map_buffer_mr can
	return failure to alloc map regs on high prio...else
	loops.

pkjdriver - always returns success

pkqdriver - loops, should return success

pksdriver - success

pkzdriver - success


Thus pkc and pke seem to be the only places where errors can return.
Paranoia seems ok for now, but maybe this can all be cleaned up via
retries at port level. Most of the time retries are already performed,
so I question whether order is currently being preserved among threads
in this case...