System does not run with "-march=znver4" or "-march=native" aocc (clang) compiler option

[M-Stenzel]

Hallo,

FYI:
I tested compiling the latest (6.12.6) version on x86_64 with AMD's aocc version 5 (clang 17.0.6), but the boot process stalls at "Loading initial ramdisk."

See the question I raised here:

https://forums.opensuse.org/t/self-compiled-linux-6-12-6-kernel-issues-with-initial-ramdisk/181413

If I compile with "-mtune=znver4" the boot process continues without any issues.

[nathanchance]

Couple of initial thoughts to start narrowing down why this is happening.

1. Does this happen with upstream LLVM? Ideally, I would test the same version as AOCC (17.0.6) and the latest (19.x); I have some available on kernel.org if you have no other access. That would help narrow down if this is a bug in upstream LLVM or the downstream parts of AOCC, as we tend to work upstream as much as possible (but could certainly help formulate a bug report). This may also help narrow down if this is a regression or some thing that has never worked.
2. Does this reproduce in a virtual machine? I have a Zen 4 server right now so I could potentially look further into this if it reproduces via QEMU / KVM but I cannot risk making my machine unbootable by testing directly on bare metal. Your configuration would help here as well.

[M-Stenzel]

Couple of initial thoughts to start narrowing down why this is happening.

1. Does this happen with upstream LLVM? Ideally, I would test the same version as AOCC (17.0.6) and the latest (19.x); I have some available on kernel.org if you have no other access. That would help narrow down if this is a bug in upstream LLVM or the downstream parts of AOCC, as we tend to work upstream as much as possible (but could certainly help formulate a bug report). This may also help narrow down if this is a regression or some thing that has never worked.

Well, I only tested with the official aocc version 5 from AMD. I already spent some time with that...

2. Does this reproduce in a virtual machine? I have a Zen 4 server right now so I could potentially look further into this if it reproduces via QEMU / KVM but I cannot risk making my machine unbootable by testing directly on bare metal. Your configuration would help here as well.

I did not test this in a virtual machine myself. And yes, I made my system unbootable, because I did not make sure, that a "safe" kernel was left to boot from.

Thanks.

[M-Stenzel]

Couple of initial thoughts to start narrowing down why this is happening.

... Your configuration would help here as well.

config.txt

N. B. Note CONFIG_MK8=y in the config file!

In the file arch/x86/Makefile I changed

cflags-$(CONFIG_MK8) += -march=k8

to

cflags-$(CONFIG_MK8) += -march=znver4

to have the compiler option changed.

Regards.