Machines with large amounts of RAM

Feedback Hardware
1

The October report says that waddlesplash fixed booting on machines with large amount of RAM, which I was waiting for about 3 years. That may work on some machines, but still doesn’t on others.

rev 58309 boots from USB on an Intel NUC 10th generation with 64GB RAM, but panics on an AMD Threadripper 3970X with 128GB RAM. The Intel machine is much simpler, with one NVME SSD, but the AMD has a large number of SSDs and HDDs (being used mainly as as data storage and media server). I kind of gave up running Haiku on that machine. In another 3 years it will certainly be replaced!

1 Like
2

Without the text of the panic it’s difficult to even guess at the problem or look if it’s already reported on the bug tracker.

3

Photo of the panic screen for USB booting on the AMD machine:

20241109_114749
20241109_1147491920×1007 299 KB

To me it’s obvious what’s happening: the boot loader looks for the boot partition on the wrong disk. That machine has a boot partition on another disk, that is used for booting my other systems: FreeBSD, Linux and Windows.

Of course that’s not happening on the Intel machine which has only one disk.

Also, when booting from USB disk the boot loader should not look for boot partitions on machine’s disks, as the USB already has it’s own boot partition.

4

A bit more info that could be useful:

The motherboard of the AMD machine has 6 SATA ports and 2 NVME ports, all of them numbered. The HDD with the boot partition is plugged in the 1st SATA port. The SSD with partitions for operating systems, including Haiku, is plugged in the 1st NVME port.

Nevertheless, on each boot, UEFI does NOT allocate the various disks according to the MB port. For example, on one boot the SSD with OSes is /dev/nvme0n1 (on Linux), while on the next boot it can be the same or can be /dev/nvme1n1. It is fully random.

The operating systems are booted through GRUB. FreeBSD and Windows boot loaders are smart enough to determine on which disk the respective OS partition is located and boot correctly every time, regardless how UEFI allocates the devices. Linux is not that smart, but it can be helped to determine the disk with the OS partition by using an initrd.

Ideally, the Haiku boot loader should try to find out on which disk the ESP boot partition is located, then on which disk the Haiku partition is located, then boot the system.

1 Like
5

Typing ‘syslog’ in KDL, you could check whether disks and partitions are correctly found at least.

6

Can’t type anything. The panic probably happens before the keyboard is detected.

7

usb keyboard? if so it may just not work. If you see a kdl the keyboard should definetely have been initialized already.

8

Yes, it’s an USB keyboard.
And no, the keyboard is dead.

I think it’s too much fuss to get Haiku working on that machine, so I’m giving up.
I can accept that the developers cannot cover all possible hardware configurations.

At least I’m having fun with it on the Intel NUC!