#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 bonefish): Replying to [comment:18 mmadia]: > "page <page address>" didn't list any area mappings. so, i included "areas" just in case. After continuing for a few times, a different KDL appeared and required a hard reboot. I'll rebuild 34965 with VM_CACHE_TRACING_STACK_TRACE enabled. There two different mechanisms to keep track of page mappings. One is an explicit list of area mappings (which is empty in this case), the other is the page's "wired_count". wired_count is 1 for the page, so it is (or at least thinks it is) indeed mapped. It's just harder to find out where. In r34979 I added the switch "-m" to the "page" command, which searches through all teams' address spaces to find the mappings for the page. That should list the area in your case too. Unless it belongs to a team that is already in the process of being destroyed that is. Since static symbols are available again, the stack trace contains a line like: {{{ 15 ffffbee8 (+ 64) 800d311e <kernel_x86> delete_area(VMAddressSpace*: 0x80fbe000, VMArea*: 0x817a95a0) + 0x014e }}} Please print the info for that area too ("area address ..."). It's probably not the area the page is still mapped in, but might be of interest nonetheless. (The "call ..." commands to get the parameters of the function aren't necessary in this case.) The complete area listing is not so interesting. -- Ticket URL: <http://dev.haiku-os.org/ticket/5138#comment:19> Haiku <http://dev.haiku-os.org> Haiku - the operating system.