Re: -current kernel panic

On Mon, Dec 17, 2007 at 07:13:54PM +0000, Robert Watson wrote:
>
> 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.


See sys/i386/i386/machdep.c r1.663, Rui put the macbook test in the
wrong function. It should be fixed now.


Andrew