Haiku only boots with "Ignore memory beyond 4GB" turned on.

[LSS37040]

Motherboard: ASRock X99M Killer/3.1

CPU: Xeon E5-2699v4 (22C, HT disabled in BIOS)

RAM: 128GB DDR4 (32GB x4)

Video Card: Quadro K6000 (12GB)

Recently I've been trying to get Haiku 32-bit booting on this board, but it's not straightforward.

By default it would freeze on Haiku logo with no icons lighting up. If I turn on the "Ignore memory beyond 4GB" safe mode option, then it boots fine.

As of R1/beta5 I can actually boot, make partition and install Haiku 32-bit on this board without any major blockade, as long as I turn on that particular safe mode option, but it's not ideal since:

• I have to manually invoke boot menu (by keep pressing left SHIFT) every time I choose to boot it.
• Maybe it's the video card I'm using, the system has only about 1.4GB of accessible RAM in below 4GB range, which is rather small in comparison. I'm not sure why exactly, however.

On the other hand, I also tried booting R1/beta5 64-bit (via USB and via CSM) on this same board as a reference, but the attempts were not successful even after I toggled "Ignore memory beyond 4GB". It's not important for the scope of this issue, however, as I intend to use the 32-bit version on this board.

The question here is where I should start with investigating why the board can't boot with the default setting (without "Ignore memory beyond 4GB"), as well as how to make the safe mode option toggle persistent without having to manually invoke the boot menu every time.

By the way, I did try enabling debug outputs, but it's not that simple, as some parts of the boot process do not like being delayed by debug outputs (most likely paging-related options), and would KDL if blocked for too long.

[LSS37040]

Just tried enabling on-screen debug output and without paging, but it seems when "Ignore memory beyond 4GB" isn't turned on (that is, booting normally), nothing is showing up when the boot logo appears and apparently hangs (no icons lighting up after long enough). In some cases (not 100%) I can make the system reboot via CTRL-ALT-DEL, however.

By the way, how much memory does Haiku 32-bit support at maximum (including PAE)? AFAIK PAE normally allowed 36-bit (up to 64GB). I wonder if Haiku has any option to limit maximum available memory in a more flexible manner (e.g. limiting to 16GB) so as to investigate whether Haiku is having trouble handling this much RAM on this board (128GB in this case)...

[madmax]

as well as how to make the safe mode option toggle persistent

I've never tried it myself with that specific option, but you'd edit /boot/home/config/settings/kernel/drivers/kernel and add a line with 4gb_memory_limit true (or just uncomment the one that's already there).

[LSS37040]

I've never tried it myself with that specific option, but you'd edit /boot/home/config/settings/kernel/drivers/kernel and add a line with 4gb_memory_limit true (or just uncomment the one that's already there).

Thank you very much. I've found the config file and uncommented the line in question. Now Haiku can boot without having to invoke the boot menu every time.

Just checked the memory info from About screen:

• It shows the total amount of installed RAM regardless (in my case, 130992 MiB).
• The 4gb_memory_limit indeed disabled all RAM mapped past 4GB boundary which would be accessed via PAE. The percentage near the amount of memory in use did reflect to the amount of memory actually available (that would be about 1.42GiB in my case).

If it's somehow possible to just set a RAM limit (e.g. 8GB or 16GB) without disabling PAE altogether, it might be helpful with investigating the underlying cause of why it's not booting correctly with default settings...

[waddlesplash]

Odds are that this is just another instance of #19009. You will need a serial capture to determine that though; those messages aren't displayed in the onscreen debug output.

[LSS37040]

Just hooked a serial cable on that system and I got the following output...

PANIC: error allocating early page!

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 81004da4 (+ 32) 8014100f 1 81004db0 (+ 12) 8012f33a 2 81004de0 (+ 48) 800a60a0 3 81004e30 (+ 80) 800a74a0 4 81004e70 (+ 64) 800a782f 5 81004e90 (+ 32) 800a7b3f 6 81004ee0 (+ 80) 8011329a 7 81004f40 (+ 96) 8011f041 8 81004fd0 (+ 144) 80117e01 9 81004ff0 (+ 32) 8005f088

kdebug>

That's all of it. So it apparently KDL'd very early.

The cause of the KDL looks really similar to #19009, though.