quoted text >
> 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
_______________________________________________
