-current kernel panic
Robert Watson
rwatson at FreeBSD.org
Mon Dec 17 11:13:56 PST 2007
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
More information about the freebsd-current
mailing list