From owner-freebsd-current@FreeBSD.ORG Wed May 21 06:41:55 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17F5F37B401 for ; Wed, 21 May 2003 06:41:55 -0700 (PDT) Received: from mail.tcoip.com.br (erato.tco.net.br [200.220.254.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8954143FA3 for ; Wed, 21 May 2003 06:41:52 -0700 (PDT) (envelope-from dcs@tcoip.com.br) Received: from tcoip.com.br ([10.0.2.6]) by mail.tcoip.com.br (8.11.6/8.11.6) with ESMTP id h4LDfUl23019; Wed, 21 May 2003 10:41:30 -0300 Message-ID: <3ECB820A.1030507@tcoip.com.br> Date: Wed, 21 May 2003 10:41:30 -0300 From: "Daniel C. Sobral" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4a) Gecko/20030416 X-Accept-Language: en-us, en, pt-br, ja MIME-Version: 1.0 To: Julian Elischer References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: CURRENT Subject: Re: /dev/null and KSE panic 100% reproducible X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2003 13:41:55 -0000 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@tco.net.br Daniel.Sobral@tcoip.com.br dcs@tcoip.com.br Outros: dcs@newsguy.com dcs@freebsd.org capo@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.