Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#5208 closed bug (fixed)

KDL booting from CD with assertion failure in vm_page.cpp

Reported by: laplace Owned by: bonefish
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: VM Cc:
Blocked By: Blocking: #5215
Platform: All

Description

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

Attachments (2)

stack_trace.png (30.9 KB ) - added by laplace 11 years ago.
Stack trace
serial.txt (76.1 KB ) - added by laplace 11 years ago.
Serial debug output

Download all attachments as: .zip

Change History (16)

comment:1 by anevilyak, 11 years ago

Owner: changed from axeld to bonefish
Status: newassigned
Version: R1/alpha1R1/Development

comment:2 by bonefish, 11 years ago

A stack trace would be much appreciated.

by laplace, 11 years ago

Attachment: stack_trace.png added

Stack trace

comment:3 by laplace, 11 years ago

See screen shot with stack trace: Stack trace

comment:4 by bonefish, 11 years ago

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.

by laplace, 11 years ago

Attachment: serial.txt added

Serial debug output

comment:5 by laplace, 11 years ago

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.

comment:6 by mmlr, 11 years ago

Blocking: 5215 added

(In #5215) Duplicate of #5208.

comment:7 by bonefish, 11 years ago

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.

comment:8 by bonefish, 11 years ago

Status: assignedin-progress

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

comment:9 by bonefish, 11 years ago

Resolution: fixed
Status: in-progressclosed

Fixed in hrev34948.

comment:10 by bga, 11 years ago

Resolution: fixed
Status: closedreopened

Still happening to me in hrev34952. Same stack trace.

comment:11 by bga, 11 years ago

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

comment:12 by laplace, 11 years ago

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

comment:13 by bonefish, 11 years ago

Resolution: fixed
Status: reopenedclosed

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).

comment:14 by laplace, 11 years ago

Thanks for fixing it and the clarification.

Note: See TracTickets for help on using tickets.