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.Received on Wed May 21 2003 - 04:41:55 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:08 UTC