Haiku doesn't mbr boot on AMD Ryzen systems

[kallisti5]

Test hardware:

• Ryzen 1800X
• 32 GB DDR4 RAM
• USB 3 drive in USB 2.0 port

hrev51006

needed 2 slow samples for TSC calibration
options = 0
No APM available.
smp: using ACPI to detect MP configuration
smp: local apic address is 0xfee00000
smp: found local APIC with id 0
smp: found local APIC with id 1
smp: found local APIC with id 2
smp: found local APIC with id 3
smp: found local APIC with id 4
smp: found local APIC with id 5
smp: found local APIC with id 6
smp: found local APIC with id 7
smp: found local APIC with id 8
smp: found local APIC with id 9
smp: found local APIC with id 10
smp: found local APIC with id 11
smp: found local APIC with id 12
smp: found local APIC with id 13
smp: found local APIC with id 14
smp: found local APIC with id 15
smp: found io APIC with id 17 and address 0xfec00000
smp: found io APIC with id 18 and address 0xfec01000
VESA version = 3.0, capabilities 1
OEM string: AMD ATOMBIOS
 0x100: 640 x 400 x 8 (a = 187, mem = 4, phy = e0000000, p = 1, b = 1)
        mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
 0x101: 640 x 480 x 8 (a = 187, mem = 4, phy = e0000000, p = 1, b = 1)
        mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
 0x103: 800 x 600 x 8 (a = 187, mem = 4, phy = e0000000, p = 1, b = 1)
        mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
 0x105: 1024 x 768 x 8 (a = 187, mem = 4, phy = e0000000, p = 1, b = 1)
        mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
 0x107: 1280 x 1024 x 8 (a = 187, mem = 4, phy = e0000000, p = 1, b = 1)
        mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
 0x110: 640 x 480 x 16 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 5 10 g: 5 5 b: 5 0 dcmi: 0
 0x111: 640 x 480 x 16 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
 0x113: 800 x 600 x 16 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 5 10 g: 5 5 b: 5 0 dcmi: 0
 0x114: 800 x 600 x 16 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
 0x116: 1024 x 768 x 16 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 5 10 g: 5 5 b: 5 0 dcmi: 0
 0x117: 1024 x 768 x 16 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
 0x119: 1280 x 1024 x 16 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 5 10 g: 5 5 b: 5 0 dcmi: 0
 0x11a: 1280 x 1024 x 16 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
 0x163: 1280 x 960 x 8 (a = 187, mem = 4, phy = e0000000, p = 1, b = 1)
        mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
 0x165: 1280 x 960 x 16 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
 0x166: 1280 x 960 x 32 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
 0x121: 640 x 480 x 32 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
 0x122: 800 x 600 x 32 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
 0x123: 1024 x 768 x 32 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
 0x124: 1280 x 1024 x 32 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
 0x143: 1400 x 1050 x 8 (a = 187, mem = 4, phy = e0000000, p = 1, b = 1)
        mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
 0x145: 1400 x 1050 x 16 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
 0x146: 1400 x 1050 x 32 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
 0x173: 1600 x 1200 x 8 (a = 187, mem = 4, phy = e0000000, p = 1, b = 1)
        mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
 0x175: 1600 x 1200 x 16 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
 0x176: 1600 x 1200 x 32 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
 0x1d1: 1920 x 1200 x 8 (a = 187, mem = 4, phy = e0000000, p = 1, b = 1)
        mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
 0x1d2: 1920 x 1200 x 16 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
 0x1d4: 1920 x 1200 x 32 (a = 187, mem = 6, phy = e0000000, p = 1, b = 1)
        mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
Using mode 0x123
VESA compatible graphics!
EDID1: 4f
EDID2: ebx 102
EDID3: 4f
Vendor: DEL
Product ID: 41082
Serial #: 810955852
Produced in week/year: 34/2014
EDID version: 1.3
Type: Digital
Size: 52 cm x 32 cm
Gamma=2.2
White (X,Y)=(0.313,0.329)
Supported Future Video Modes:
1280x960@60Hz (id=16513)
1280x1024@60Hz (id=32897)
1600x1200@60Hz (id=16553)
1680x1680@60Hz (id=179)
1920x1080@60Hz (id=49361)
Supported VESA Video Modes:
720x400@70Hz
640x480@60Hz
800x600@60Hz
1024x768@60Hz
Additional Video Mode (1920x1200@59Hz):
clock=154 MHz
h: (1920, 1968, 2000, 2080)
v: (1200, 1203, 1209, 1235)
size: 51.799 cm x 32.399 cm
border: 0 cm x 0 cm
Serial Number: YMYH148M0V4L
Monitor Name: DELL U2412M
Horizontal frequency range = 30..83 kHz
Vertical frequency range = 50..61 Hz
Maximum pixel clock = 170 MHz
crtc: h 1968/2000/2080, v 1203/1209/1235, pixel clock 154000000, refresh 6019
Welcome to the Haiku boot loader!
number of drives: 5

It could be just an XHCI issue... however those generally in boot partition panics.

[kallisti5]

A more complete log from a UEFI boot is in #13372 (XHCI crash though)

[kallisti5]

Issues:

• XHCI: Nonfunctional
• Intel I211: Nonfunctional
• MBR boot: Hard lock in early loader

[kallisti5]

syslog, EFI + AHCI boot

[kallisti5]

listdev, EFI + AHCI boot

[kallisti5]

sysinfo, EFI + AHCI boot

[kallisti5]

I was able to get the system booted by:

Setting up a SATA drive with:

• GPT, two partition
• First partition:
  • type ef00
  • mkfs.msdos -F32
  • haiku_loader.efi -> EFI/BOOT/bootx64.efi
• Second partition:
  • Type eb00
  • Haiku raw image dd'ed or formatted + installed.

So pretty much avoid using XHCI + legacy boot and things will boot.

[jua]

Please specify the mainboard that was used in the ticket description and title. This problem seems to be specific to the mainboard or its BIOS.

At least on my Ryzen system with an Asus Prime B350-PLUS mainboard, booting from MBR gcc2h nightly works just fine...

[kallisti5]

Asus Prime X370-PRO

If yours is working, it could be just related to XHCI again which would make this a duplicate of #13372

[mpxlbs]

I have the same issue on my x370 Prime Pro by ASUS with an 1800x (new version without the hardware bug). Tried toggling XHCI and legacy boot, but to no avail. Same message, although I have a different monitor brand, different resolution and hertz available.

Using BIOS 4008 (latest). Tried Haiku on it when I got the board as new and have been trying on newer BIOS revisions over time.

The only build I've been able to boot is the (very old) EFI build by jessicah that's been available before.

[korli]

Replying to mpxlbs:

I have the same issue on my x370 Prime Pro by ASUS with an 1800x (new version without the hardware bug). Tried toggling XHCI and legacy boot, but to no avail. Same message, although I have a different monitor brand, different resolution and hertz available.

Did you check with the EFI iso?

[mpxlbs]

Korli, I added the information in my edit. In short, I tried the old EFI build and it works. However, it hasn't been updated in a very long time, right?

[korli]

Replying to mpxlbs:

Korli, I added the information in my edit. In short, I tried the old EFI build and it works. However, it hasn't been updated in a very long time, right?

Right, but you should be able to update to the latest hrev, provided you have a working network.

[mpxlbs]

korli, first off, thank you for the reply.

I only have the built in network chip, and thus have been unable to do an update, sorry. Is there another way to update?

[roiredxsoto]

Good day,

I can boot, and run Haiku on a Ryzen box (non EFI iso prebeta hrev52295 released by kallisti5) Safe mode options on:

• Ignore memory over 4GB
• Safe video mode (VESA)

Other than that, there are issues when plugging/unplugging certain USB devices, resulting in system lock, or directly KDL.

I add the syslogs, and later when I am on the ryzen box will add pertinent information.

Regards, RR

[roiredxsoto]

"Previous" boot syslog after installing Haiku hrev52295 pre beta on Ryzen

[roiredxsoto]

"Old" syslog after installing Haiku on hrev52295 pre beta

[roiredxsoto]

"Previous" syslog after rebooting Haiku hrev52295 prebeta on Haiku. Reboot consequence of KDL appearing when plugging in Wacom A6 tablet

[roiredxsoto]

"Old" syslog after rebooting hrev52295 prebeta on Ryzen. Reboot consequence of KDL after plugging in Wacom A6 tablet

[roiredxsoto]

Syslog after rebooting hrev52295 prebeta (with Wacom A6 tablet unplugged). Reboot caused by plugging in Wacom A6 tablet.

[roiredxsoto]

uname, listdev, listusb on Ryzen running hrev52295 prebeta

[kallisti5]

That's related to our wacom driver and not the Ryzen system. I've seen that crash plugging and unplugging a wacom tablet a few years ago.

[roiredxsoto]

Replying to kallisti5:

That's related to our wacom driver and not the Ryzen system. I've seen that crash plugging and unplugging a wacom tablet a few years ago.

Hello kallisti5, Strange, because It does not happen with the laptop on hrev52355 now, and I can't recall any issue with the wacom and the laptop since I installed rolling Haiku there. Then again, the laptop only has USB 2.0, and even the Ryzenbox is set to compatibility, some issue might be going on with USB, as the kvm switch didn't work plugged into the USB 3.0 port, and works plugged into the 2.0 now. Changing from input 1 (work PC) to input 2 (Haiku) always locks Haiku, so might be related. I can't tell, I just presume. Thank you. RR

[mmlr]

The syslog shows that there is a problem with finding an interrupt routing for the IO-MMU and therefore switching to IO-APICs is aborted:

https://dev.haiku-os.org/attachment/ticket/13370/20180918-RR-wacom-previous_syslog.txt#L1548

Using modern systems without IO-APICs isn't really a good idea as it will lead to lots of shared interrupts and is generally not well tested (by hardware vendors and in Haiku).

I don't think the IO-MMU should get an interrupt line at all, but it looks like the interrupt pin is still set in the PCI registers (causing the IO-APIC setup code to try and find a routing). The interrupt line is however unset. It may be a good idea to ignore a failure to find an interrupt routing for devices that previously weren't assigned an interrupt at all, because they wouldn't have an interrupt line under the PIC either.

The code avoids using IO-APICs in case anything does not add up. This made sense at the time this code was written as IO-APICs were sometimes just buggy and using them instead of the traditional PIC would generally make things worse. In todays systems however using the IO-APIC is the expected norm and using the PIC is the neglected option that will probably make things worse. So alternatively the IO-APIC code could be made less conservative overall.

[mmlr]

Looking at the code, we actually do ignore a missing routing in case the interrupt line is 0. In this case it isn't 0 but 0xff, which is invalid and generally treated the same as 0 in the rest of the code. Ignoring the missing routing on 0xff seems like the way to go here.

[waddlesplash]

Done in hrev52357. Leaving ticket open for testing, and to discuss what changes we want to make for IO-APIC.

[roiredxsoto]

Good day,

Tested new updates by changing the Haiku repo from beta branch to rolling/master. Now on hrev 52358 and it boots fine. Still needed 4GB limit for ram and the Vesa safe graphics. I added the new syslogs.

The USB issue is still there, therefore I presume it needs its own ticket.

Thanks a lot. Regards, RR

[roiredxsoto]

Previous Syslog with hrev52358

[roiredxsoto]

Current syslog with hrev52358 after resetting boot manager to 4GB limit in order to boot the box

[cb88]

Linux has ran into some Ryzen booting issues also referencing here:

It is worth nothing desktop ryzen has different issues than mobile ryzen which for me doesn't boot in any configuration with Haiku (hangs in bootloader). Again hardware offer is still valid x370 ITX + Athlon 200GE!

Ryzen 2500U won't boot recent kernels without mce=off ​https://bugzilla.kernel.org/show_bug.cgi?id=201291

WARNING in the smp_call_function_single() on Ryzen 2500U ​https://bugzilla.kernel.org/show_bug.cgi?id=201213

[mpxlbs]

Hello.

Writing this from Haiku hrev52713.

Asus Prime X370 Pro / Ryzen 1800x.

USB 3 booting works. MBR booting does not work. Booting the UEFI entry on the USB works. Have to select fail-safe video driver.

USB keyboard and mouse work. They did not work before. Might be I'm using the latest BIOS and it fixes some bugs, but I think it's the latest hrev.

Installed HaikuOS to SATA drive and followed the EFI guide on the HaikuOS homepage to download and install the EFI boot entry on the first partition.

Network works as well, which it did not with a very much earlier hrev.

Sound does not work from neither onboard or dedicated audio card, that's another issue though. Also, copy or moving files gives kernel panic with SMAPI errors, that's another issue as well (disable SMAPI in boot options in haiku boot mgr.)

All in all, very happy.

[waddlesplash]

Sound does not work from neither onboard or dedicated audio card, that's another issue though. Also, copy or moving files gives kernel panic with SMAPI errors, that's another issue as well (disable SMAPI in boot options in haiku boot mgr.)

Are you on a nightly build or the beta? Please check first if this is reproducible under a recent nightly build. If it is, please file a ticket.

[mpxlbs]

waddlesplash, I have created two new tickets. This is on nightly build. I haven't gotten around to the SMAPI error yet. I have to read up on SMAPI first before knowing exactly what to report. Either way, I got two other tickets, both for graphics and sound..

[waddlesplash]

It's just SMAP, not SMAPI. And you just need to file a ticket with a picture of the panic and a description of how you triggered it. We'll take it from there.

[mpxlbs]

Ok, will do tomorrow. It happened every time I tried to copy a file, saw that SMAP triggered a kernel panic in KDL and just disabled it.

[waddlesplash]

Can someone please retest this under a recent (64-bit) nightly?

[mpxlbs]

@waddlesplash

Downloaded hrev53050 (x64).

Boots fine with USB in USB2 slot (MBR boot). Can use USB3 keyboard on startup menu to select fail safe modes, volume,etc. (In my case, ignore memory over 4GB and use fail safe graphics mode).

USB3 does not work to boot from (can't find boot partition).

USB3 mouse/keyboard does not work.

Boots fine otherwise. Maybe my system is a unicorn, but here are the results you asked for.

PRIME X370-PRO AMD Ryzen 1800x

[waddlesplash]

Please open a new ticket and attach a syslog so I can look into your USB3 mouse/keyboard not working.

Do you still need the "4GB memory limit", or does it now boot with that off?

[mpxlbs]

The lights would not start to glow (boot icons) without the "4GB memory limit" switched on.

[kallisti5]

This one has morphed into https://dev.haiku-os.org/ticket/14659 thanks to waddlesplash and mmlr!

I'm closing this one since the fault has shifted to something with some actual debuggable error messages in https://dev.haiku-os.org/ticket/14659

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone