Re: panic at sched_add_internal

	Oops, another panic has happend.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[thread 100154]
Stopped at      sched_switch+0x27:      testb   $0x1,0x20(%esi)
db> trace
sched_switch(c4b76000,0,2628fe5d,0,3aeb7d59) at sched_switch+0x27
mi_switch(2,0,c07bf310,f3,10000) at mi_switch+0x1c2
ast(e41fcd48) at ast+0x3cb
doreti_ast() at doreti_ast+0x17
db> reset
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

	$ nm /boot/kernel/kernel.debug | grep sched_switch
	c05c33b0 T sched_switch
	$ addr2line -e /boot/kernel/kernel.debug 0xc05c33d7
	/usr/src/sys/kern/sched_ule.c:1147

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
void
sched_switch(struct thread *td, struct thread *newtd)
{
[...]
	 * If the KSE has been assigned it may be in the process of switching
	 * to the new cpu.  This is the case in sched_bind().
	 */
-->	if ((ke->ke_flags & KEF_ASSIGNED) == 0) {
		if (td == PCPU_GET(idlethread))
			TD_SET_CAN_RUN(td);
		else if (TD_IS_RUNNING(td)) {
[...]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -