KDL booting from CD with assertion failure in vm_page.cpp

[laplace]

KDL when booting the gcc2 haiku-cd.iso from hrev34937 in VM Fusion 3.0.1:

PANIC: ASSERT FAILED (../vm_page.cpp:2286): page->state != PAGE_STATE_FREE && page->state != PAGE_STATE_CLEAR

Virtual machine configuration:
1 CPU
1024 MB RAM
10 GB HDD (SCSI) with one NTFS partition

[bonefish]

A stack trace would be much appreciated.

[laplace]

Stack trace

[laplace]

See screen shot with stack trace:

[bonefish]

That's early in the boot process as such not particularly serious, since it's all single-threaded at this point and the operation will simply be a no-op. It indicates, however, that a physical page that is mapped has not been allocated, which is something that should be investigated. This might take a few iterations. The following information would be of interest for the first round:

• A "call 13 -1" will yield the address of the page in question. "page <address>" will print information about the page.
• "call 15 -3"
• How many times do you have to continue for the boot process to continue? If it's more than a few times, don't bother to find out.

[laplace]

Serial debug output

[laplace]

Reduced VM memory size to 512 MB.

call 13 -1

kdebug> call 13 -1
thread 0, 
80204ec0 800db631   <kernel_x86>:vm_page_set_state(0x83506140)
kdebug> page 0x83506140
PAGE: 0x83506140
queue_next,prev: 0x8300bb34, 0x835063a8
physical_number: 1fef0
cache:           0x00000000
cache_offset:    0
cache_next:      0x00000000
type:            0
state:           free
wired_count:     0
usage_count:     0
busy_writing:    0
accessor:        0
area mappings:

call 15 -3

thread 0, 
80204f30 800d2f83   <kernel_x86>:vm_free_unused_boot_loader_range(0x80000000, 0x1800000, 0x80204fa0)

"count" about 13 times to get to the "folder" icon in the boot screen.

See serial.txt for more details.

[mmlr]

(In #5215) Duplicate of #5208.

[bonefish]

Sorry, apparently I was a bit cross-eyed. This interesting parameters are those of unmap_and_free_physical_pages(), that is "call 14 -3".

The page itself looks OK, though it has a conspicuously high number (close to the end of the 512 MB), while that early in the boot process only the early pages should be used.

[bonefish]

I can reproduce the problem on a machine where I have VMware install. Investigating...

[bonefish]

Fixed in hrev34948.

[bga]

Still happening to me in hrev34952. Same stack trace.

[bga]

In case this is relevant, I am running VMWare Player with 2 Gb of RAM and 2 virtual CPUs. Build is a GCC2 build.

[laplace]

I am sorry to confirm BGAs observation.
I did a clean build (removed folders attributes, objects and temp from folder "generated").

[bonefish]

As of hrev34954 already free pages won't be freed by unmap_and_free_physical_pages() anymore, which gets around the assertion. If you guys want to investigate this further, feel free, but since I can't reproduce the problem with VMware 1 and I'm not particularly motivated to ping-pong debug this, I won't pursue it. The likely cause is that the ACPI or HPET code in the boot loader map the same physical page more than once, which is not really a problem, but led to it being freed multiple times by unmap_and_free_physical_pages() (once for each mapping).

[laplace]

Thanks for fixing it and the clarification.