PANIC: ASSERT FAILED in vm_page.cpp when booting cd

[idefix]

When I boot the latest Alpha 2 nightly cd (​haiku-r1a2-rc-r36601-x86gcc2hybrid-cd.zip) on my Dell Latitude Cpi D233ST (PII 233 MHz, 64 MB) it goes immediately in KDL when the boot screen is shown. The panic looks a lot like ticket:5208, but is at another position in vm_page.cpp and the backtrace is different:

Welcome to kernel debugger output!
Haiku revision: 36601
CPU 0: type 0 family 6 extended_family 0 model 5 extended_model 0 stepping 2, string 'GenuineIntel'
CPU 0: features: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr 
heap_add_area: area -1 added to small heap 0x83800000 - usable range 0x83804000 - 0x83a00000
heap_add_area: area -1 added to medium heap 0x83a00000 - usable range 0x83a01000 - 0x83b33000
heap_add_area: area -1 added to large heap 0x83b33333 - usable range 0x83b34000 - 0x83c00000
add_memory_type_range(4, 0x0, 0xa0000, 6)
add_memory_type_range(5, 0xe0000, 0x20000, 6)
add_memory_type_range(80, 0xe0000000, 0x180000, 0)
PANIC: ASSERT FAILED (/storage/Build-O-Matic/active_worker/output/haiku/src/system/kernel/vm/vm_page.cpp:3419): ( page->State() != PAGE_STATE_FREE && page->State() != PAGE_STATE_CLEAR); page: 0x83caa800
Welcome to Kernel Debugging Land...
Thread 0 "" running on CPU 0
stack trace for thread 0 ""
    kernel stack: 0x00000000 to 0x00000000
frame               caller     <image>:function + offset
 0 81004c44 (+  32) 800ff4b6   
 1 81004c64 (+  16) 80073b6b   
 2 81004c74 (+  12) 8010704a   
 3 81004c80 (+  48) 80075603   
 4 81004cb0 (+  64) 80073d8f   
 5 81004cf0 (+  48) 800740f0   
 6 81004d20 (+  48) 80075974   
 7 81004d50 (+  64) 800f0669   
 8 81004d90 (+ 256) 800dfc5b   
 9 81004e90 (+  96) 800e86f4   
10 81004ef0 (+ 144) 80074888   
11 81004f80 (+  48) 80075292   
12 81004fb0 (+  64) 8004e91e   

Continuing the KDL doesn't really get it any further (see attached serial log​).

[idefix]

Serial log showing PANIC: ASSERT FAILED in vm_page.cpp

[bonefish]

Decoding the matrix:

frame               caller     <image>:function + offset
 0 81004c14 (+  32) 800ff4b6  arch_debug_stack_trace
 1 81004c34 (+  16) 80073b6b  stack_trace_trampoline
 2 81004c44 (+  12) 8010704a  arch_debug_call_with_fault_handler
 3 81004c50 (+  48) 80075603  debug_call_with_fault_handler
 4 81004c80 (+  64) 80073d8f  kernel_debugger_loop
 5 81004cc0 (+  48) 800740f0  kernel_debugger_internal
 6 81004cf0 (+  48) 80075974  panic
 7 81004d20 (+  64) 800ead2a  set_page_state
 8 81004d60 (+  48) 800f0696  vm_page_set_state
 9 81004d90 (+ 256) 800dfc5b  vm_create_anonymous_area
10 81004e90 (+  96) 800e86f4  create_area
11 81004ef0 (+ 144) 80074888  syslog_init_post_vm
12 81004f80 (+  48) 80075292  debug_init_post_vm
13 81004fb0 (+  64) 8004e91e  _start

I'll look into fixing the problem, but I suspect the underlying issue is that it's really early in the kernel initialization and there's already insufficient memory. Booting with only 64 MB RAM from CD is probably just not possible ATM.

[idefix]

Well, it used to work. :)

I'm currently finding out when it stopped working. At this moment I know it was somewhere between hrev35718 and hrev36022. Testing hrev35864 next...

[idefix]

The hrev35962 nightly cd (​haiku-nightly-r35962-x86gcc2hybrid-cd.zip) boots, but hrev35981 (​haiku-nightly-r35981-x86gcc2hybrid-cd.zip) shows the panic.

[bonefish]

The bug is fixed in hrev36634 (trunk).

I've tested with 64 MB in qemu and the ISO CD boots to the installer, but very slowly and USB already reports memory allocation errors. DriveSetup can't be started, though. The anyboot CD doesn't even get to the installer.

[idefix]

That was fast, thanks!

I will test it when there is a new nightly (assuming that it goes into the Alpha 2 branch). And yes, I know that 64 MB is really tight, but I was hoping that with changeset:36552 it would boot into Installer (which it didn't do before).

[idefix]

Tested with Alpha 2: the good news is that it boots again, but it now ignores most of the boot options I set in the bootloader. I will further investigate this problem and open a new ticket when I have gathered enough information.