#5474 closed bug (not reproducible)
[kernel] PANIC: got an in use page 0x8107c040 from the free pages list
| Reported by: | diver | Owned by: | mmlr |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | System/Kernel | Version: | R1/Development |
| Keywords: | port heap | Cc: | |
| Blocked By: | Blocking: | #5864, #6960, #8025, #10498 | |
| Platform: | All |
Description
I was playing with HaikuLauncher and Arora comparing site rendering when I got this panic.
Observed with hrev35610 in VirtualBox 3.0.12
Attachments (2)
Change History (22)
by , 15 years ago
comment:1 by , 15 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:2 by , 15 years ago
BTW just to avoid any misunderstandings the page in this case isn't a page in the VM page sense, it is a heap "page" which is a part of a heap area. In any case since this is only happening in the port code it's probably an edge case the separate port heap exposes. It might just be an unfortunate heap config for example. Can take a look in any case. As always a reproducible test case would be very much appreciated of course.
comment:4 by , 15 years ago
| Milestone: | R1 → R1/alpha2 |
|---|
comment:5 by , 15 years ago
| Keywords: | port heap added |
|---|
comment:6 by , 14 years ago
| Milestone: | R1/alpha3 → R1/beta1 |
|---|
comment:8 by , 13 years ago
| Blocking: | 8025 added |
|---|
(In #8025) Replying to humdinger:
Attached the KDL and a backtrace, which looks almost identical...
They should, as the back traces are just started from different points within the kernel debugger. Unless the automatic back trace wraps and isn't fully readable, there's no need to add another one.
Anyway, closing as dup of #5474.
comment:9 by , 13 years ago
Got another one of those: "PANIC: got an in use page 0x001b7040 from the free page list".
Attaching KDL pic here, just in case. Sorry, it's blurry as hell...
comment:11 by , 11 years ago
| Cc: | added |
|---|
comment:12 by , 11 years ago
| Milestone: | R1/beta1 → R1/alpha5 |
|---|---|
| Priority: | normal → high |
comment:13 by , 10 years ago
| Milestone: | R1/alpha5 → R1/beta1 |
|---|
comment:14 by , 10 years ago
Last time this was reported is hrev45824, 1.5 years ago. Does it still happen?
comment:16 by , 10 years ago
But that was with my (back then) months-old setup so 12 months + n months = 1.5 years makes perfect sense yes.
Anyway, zero report whatsoever since that occurence here (neither from me, dsuden, or clients).
PS - can an admin please un-Cc me (wether this gets closed or not regardless) as I use the Cc property to know which tickets I want to keep on my 'radar screen', and this one I no longer need, thanks. Or maybe that kind of operation needs to be done with a separate email, please kindly tell me how if so.
comment:17 by , 10 years ago
| Cc: | removed |
|---|
comment:18 by , 10 years ago
| Milestone: | R1/beta1 → R1 |
|---|
Moving out of beta1 then, not happening often enough to be troublesome I think.
comment:19 by , 6 years ago
| Resolution: | → not reproducible |
|---|---|
| Status: | assigned → closed |
No more reports since that one, so that's 5.5 years with nobody seeing this. Closing as not reproducible.
comment:20 by , 5 years ago
| Milestone: | R1 |
|---|
Remove milestone for tickets with status = closed and resolution != fixed
I got that, too, a few weeks ago (which led me to add the page address to the panic).