From owner-freebsd-current@FreeBSD.ORG Mon Dec 17 19:13:55 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8DEF16A41A for ; Mon, 17 Dec 2007 19:13:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id BAC6A13C459 for ; Mon, 17 Dec 2007 19:13:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 71CAE4A017; Mon, 17 Dec 2007 14:13:54 -0500 (EST) Date: Mon, 17 Dec 2007 19:13:54 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Thierry Herbelot In-Reply-To: <200712171935.10911.thierry@herbelot.com> Message-ID: <20071217191047.D57519@fledge.watson.org> References: <200712171935.10911.thierry@herbelot.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: -current kernel panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 17 Dec 2007 19:13:56 -0000 On Mon, 17 Dec 2007, Thierry Herbelot wrote: > db> where > Tracing pid 11 tid 100003 td 0xc2763880 > kdb_enter(c0aff8da,0,c0afaad4,dd238a2c,0,...) at kdb_enter+0x32 > panic(c0afaad4,c0b018c6,c0b01376,742,c0c1a680,...) at panic+0x124 > sched_switch(c2763880,0,1,17b,86a5c2a4,...) at sched_switch+0xe6 > mi_switch(1,0,c0b03bf0,2e2,c2736e60,...) at mi_switch+0x217 > turnstile_wait(c2736e60,c36dbaa0,0,184,c1474708,...) at turnstile_wait+0x4cb > _mtx_lock_sleep(c1474708,c2763880,0,c0b213d7,726,...) at _mtx_lock_sleep+0x18e > _mtx_lock_flags(c1474708,0,c0b213d7,726,c0b04452,...) at _mtx_lock_flags+0xef > uma_zalloc_arg(c1472960,0,2,2,dd238b9e,...) at uma_zalloc_arg+0xd3 > malloc(2,c0bb1a40,2,131,208bb0,...) at malloc+0xd2 > getenv(c0b2dfe8,c0c20a80,c2763880,3,dd238cc8,...) at getenv+0xa6 > cpu_idle_default(dd238cf8,c077d839,c0c20a80,0,c0b01376,...) at > cpu_idle_default+0x13 > cpu_idle(c0c20a80,0,c0b01376,322,c0c1a680,...) at cpu_idle+0x28 > sched_idletd(0,dd238d38,c0afc024,30c,c2761804,...) at sched_idletd+0x249 > fork_exit(c077d5f0,0,dd238d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xdd238d70, ebp = 0 --- Well, that's something of an ugly thread. The idle thread should not be calling the kernel getenv() as it involves locks, and worse yet, the potential for memory allocation. The idle thread is not allowed to yield in such a way as it becomes unrunnable, or we will find ourselves in a situation where there is no idle thread for a CPU, and always having an idle thread is an invariant. I am a bit unclear on how that could happen, I don't se an obvious call to getenv() in the cpu idle default code on i386 or amd64. Robert N M Watson Computer Laboratory University of Cambridge