#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:15 mmadia]: > Replying to [comment:12 bonefish]: > > Maybe Matt can confirm that the panic() has become more easy to reproduce with a current revision. > > > > I'm hoping that further optimization might make the bug even more easy to reproduce, so that someone (*duck* :-)) can tackle it. Especially that the system freezes and doesn't enter KDL is extremely annoying. > > Yup, one build cycle of `jam -aqj3 @alpha-raw` in r34965-gcc2hybrid was enough to generate it. The uptime was between 20~30 minutes. I'll build the image with just {{{ > # define ENABLE_TRACING 1 > # define MAX_TRACE_SIZE (300 * 1024 * 1024) > #define SYSCALL_TRACING_IGNORE_KTRACE_OUTPUT 1 > #define VM_CACHE_TRACING 2 > }}} Great! So if you can reproduce the bug with VM cache tracing enabled, now, it would be great, if you found the time to track it down as described in [comment:5 comment 5]. Even better, if it could be done with VM_CACHE_TRACING_STACK_TRACE enabled. -- Ticket URL: <http://dev.haiku-os.org/ticket/5138#comment:17> Haiku <http://dev.haiku-os.org> Haiku - the operating system.