The scheduler activation code seems to assume that 
the on virtual processor LWP is either
	- on a CPU
	- on the run queue after an involuntary preemption
( With the exception caused by sa_switch() when it runs out of cached LWPs
- but this looks like a known "work in progress" problem) 
 
However a few potentially long running kernel functions try to avoid
hogging the CPU by yielding it.
Example: 
	amap_wipeout():
		....
		if (curlwp->l_cpu->ci_schedstate.spc_flags & SPCF_SHOULDYIELD)
				preempt(1);
	(Other preempt calls in genfs_putpages(), lfs functions)

preempt() can put an on virtual processor SA LWP on the run queue where
another freshly unblocked SA LWP could sa_vp_repossess() the virtual
processor. sa_vp_repossess() would then just recycle the original LWP 
destroying all in kernel context and preventing any return to the yielding
kernel function. This could cause interesting problems ...

Maybe scheduler activation LWPs possessing the virtual processor
should not voluntarily yield the CPU for now?

	Stephan