#5138: PANIC: remove page 0x82868278 from cache 0xd19e7680: page still has mappings! ---------------------------+------------------------------------------------ Reporter: mmadia | Owner: bonefish Type: bug | Status: new Priority: normal | Milestone: R1 Component: System/Kernel | Version: R1/Development Keywords: | Blockedby: Platform: All | Blocking: 5216 ---------------------------+------------------------------------------------ Comment(by anevilyak): Update: I likewise managed to hit a hang with the scheduling recorder. However, I did eventually panic in acquire_spinlock: {{{ PANIC: acquire_spinlock(): Failed to acquire spinlock 0x80130678 for a long time! kdebug> bt stack trace for thread 5205 "scheduling_recorder" kernel stack: 0x91cd7000 to 0x91cdb000 user stack: 0x7efef000 to 0x7ffef000 frame caller <image>:function + offset 0 91cdaae8 (+ 32) 8006b5c1 <kernel_x86> invoke_command_trampoline(void*: 0x91cdab68) + 0x0015 1 91cdab08 (+ 12) 800d8173 <kernel_x86>:arch_debug_call_with_fault_handler + 0x001b 2 91cdab14 (+ 48) 8006946a <kernel_x86>:debug_call_with_fault_handler + 0x0051 3 91cdab44 (+ 64) 8006b96a <kernel_x86>:invoke_debugger_command + 0x00bb 4 91cdab84 (+ 48) 8006ba87 <kernel_x86> invoke_pipe_segment(debugger_command_pipe*: 0x8012aa22, int32: 0, char*: NULL) + 0x0083 5 91cdabb4 (+ 32) 8006bb4f <kernel_x86>:invoke_debugger_command_pipe + 0x008b 6 91cdabd4 (+ 128) 8006f8ee <kernel_x86> ExpressionParser<0x91cdaca4>::_ParseCommandPipe(int&: 0x91cdaca0) + 0x0aae 7 91cdac54 (+ 48) 800720b7 <kernel_x86> ExpressionParser<0x91cdaca4>::EvaluateCommand(char const*: 0x8012aa20 "bt", int&: 0x91cdaca0) + 0x06df 8 91cdac84 (+ 192) 80072230 <kernel_x86>:evaluate_debug_command + 0x0084 9 91cdad44 (+ 96) 8006a3ba <kernel_x86> kernel_debugger_internal(char const*: 0x1 "<???>", int32: -1848791600) + 0x03a7 10 91cdada4 (+ 16) 8006a51b <kernel_x86>:kernel_debugger + 0x0019 11 91cdadb4 (+ 160) 8006a5f5 <kernel_x86>:panic + 0x002a 12 91cdae54 (+ 48) 80056d13 <kernel_x86>:acquire_spinlock + 0x003a 13 91cdae84 (+ 48) 80041990 <kernel_x86> ConditionVariable<0x81bc8734>::Add(ConditionVariableEntry*: 0x91cdaed8) + 0x0022 14 91cdaeb4 (+ 80) 80075a37 <kernel_x86> SystemProfiler<0x81bc86c0>::NextBuffer(uint32: 0xbf280 (782976), unsigned long long*: 0x91cdaf2c) + 0x00af 15 91cdaf04 (+ 64) 8007669d <kernel_x86>:_user_system_profiler_next_buffer + 0x00a2 16 91cdaf44 (+ 100) 800d8761 <kernel_x86>:handle_syscall + 0x00be user iframe at 0x91cdafa8 (end = 0x91cdb000) eax 0xd8 ebx 0x2039fc ecx 0x7ffeee4c edx 0xffff0114 esi 0xbf280 edi 0x7ffeef48 ebp 0x7ffeef68 esp 0x91cdafdc eip 0xffff0114 eflags 0x246 user esp 0x7ffeee4c vector: 0x63, error code: 0x0 17 91cdafa8 (+ 0) ffff0114 <commpage>:commpage_syscall + 0x0004 18 7ffeef68 (+ 52) 00201363 <_APP_>:_start + 0x0053 19 7ffeef9c (+ 64) 001052c3 </boot/system/runtime_loader@0x00100000>:unknown + 0x52c3 20 7ffeefdc (+ 0) 7ffeefec 172038:scheduling_recorder_main_stack@0x7efef000 + 0xffffec }}} The exact invocation was {{{ rm -rf generated/objects ; scheduling_recorder ~/sched_data jam -qj2 }}} Interestingly I didn't hit this problem when recording just jam -qj2 kernel, and I also note that it was towards the end of the "patience..." portion of jam. Anything worth investigating if I hit it again? -- Ticket URL: <http://dev.haiku-os.org/ticket/5138#comment:14> Haiku <http://dev.haiku-os.org> Haiku - the operating system.