Re: -current kernel panic

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