/dev/null and KSE panic 100% reproducible

[Daniel C. Sobral]

Julian Elischer wrote:
> 
> the stack trace you showed is in the context of a clock interrupt,
> (or at least, SOME interrupt). The possibility is that the clock
> interrupt is recalculating priorities but somehow it's happenning when
> the system is already messing up it's scheduling data..
> 
> Someone put the following code into kern/kern_switch.c
>         /*
>          * Only allow non system threads to run in panic
>          * if they are the one we are tracing.  (I think.. [JRE])
>          */
>         if (panicstr && ((td->td_proc->p_flag & P_SYSTEM) == 0 &&
>             (td->td_flags & TDF_INPANIC) == 0))
>                 goto retry;
> 
> 
> It has the effect of throwing away threads that it has taken off teh run
> queue if we are in a panic.
> 
> at a later time anything that goes through these threads will assume
> they are still on teh run queue and panic becasue they are not..
> 
> try the following:
> 
> change it to:
> 
>         if (panicstr && ((td->td_proc->p_flag & P_SYSTEM) == 0 &&
>             (td->td_flags & TDF_INPANIC) == 0)) {
> 		/* note that it is no longer on the run queue */
> 		TD_SET_CAN_RUN(td);
> 	         goto retry;
> 	}

This stopped the panics (the double panics, I should say).

> if it fails you may try TD_SET_SUSPENDED(td) instead, but I think this
> is better.

This I haven't tried.

-- 
Daniel C. Sobral                   (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
VIVO Centro Oeste Norte
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: Daniel.Capo at tco.net.br
         Daniel.Sobral at tcoip.com.br
         dcs at tcoip.com.br

Outros:
	dcs at newsguy.com
	dcs at freebsd.org
	capo at notorious.bsdconspiracy.net

	A horse breeder has his young colts bottle-fed after they're three
days old.  He heard that a foal and his mummy are soon parted.