[SOLVED] Display problems with my AMD Radeon RX 5600 XT PCIe card

jsbjsb001 · 12-13-2020, 08:01 PM

From the response I've gotten from OpenMandriva, it seems it wasn't anything I was doing that was causing the kernel build to fail. It seems the tool-chain packages for OpenMandriva Lx 4.1 are simply too old to be able to build the latest kernel from kernel.org on OpenMandriva Lx 4.1 But apparently kernel 5.9.14 is installed in the "rolling" release of OpenMandriva, and kernel 5.10-rc7 is also available in it. So it looks like it's not going to be possible to build the latest kernel on OpenMandriva Lx 4.1

The "rock" releases (that I'm currently using - 4.1) have apparently been successfully converted to "rolling" releases, and they've posted a link to some information about doing it from what I understand in the thread I started on OpenMandriva's forum. So I'll snapshot my current install's root partition with Clonezilla first in case it borks my system, and then see if I can successfully convert my install to the "rolling" release to get the latest kernel.

I'll post back later on and hopefully be able to say it worked...

cynwulf · 12-14-2020, 02:37 AM

https://www.kernel.org/doc/html/late...s_install.html

Odd that the mainline kernel gives the same error.

Are you using your existing config and issuing "make oldconfig"?

I assume the distribution has a development branch with newer kernels? Can you pull source code from that and attempt a backport? Even a config from a 5.9.x might be enough.

jsbjsb001 · 12-14-2020, 06:48 AM

Thanks for the link.

Quote:

Originally Posted by cynwulf

...
Are you using your existing config and issuing "make oldconfig"?

I copied the old config from kernel 5.5 over to the source directory of both kernels I tried to compile (the stable and mainline kernels I downloaded). I've just tried make oldconfig but I'm pretty sure I've seen the same screen before where the kernel's build system asked me to choose options for the new options that kernel 5.5 didn't have that the newer kernels do. In any case it's compiling yet again now, so we'll see if it finishes this time. Although, I gotta say I'm not optimistic that it will actually build it this time, and I'm pretty sure I'll get the same error again.

Quote:

I assume the distribution has a development branch with newer kernels? Can you pull source code from that and attempt a backport? Even a config from a 5.9.x might be enough.

I believe it's the "cooker" branch that OpenMandriva uses for it's development branch, and if you read the replies I got in the thread I started at OpenMandriva's forums, they copied what was in their "cooker" branch to their "rolling" branch/release. So now the "rolling" release apparently has both of the kernels I downloaded the source for as packages in the "rolling" release.

Although, and like I said in the thread over at OpenMandriva's forums, dnf wants to download 4.3GiB worth of updates to convert my installation to a "rolling" release. But that will breach my data download limit, so I'll have to wait until maybe tomorrow to buy some more data so I can download the update packages. So I've deferred that plan until at least tomorrow - but already have modified dnf's repolist to point to the "rolling" release's repo's.

jsbjsb001 · 12-14-2020, 09:11 AM

It looks like I was right not to be optimistic about it, as it's failed again with the same error as before.

Code:

MODPOST vmlinux.symvers
  MODINFO modules.builtin.modinfo
  GEN     modules.builtin
  LD      .tmp_vmlinux.kallsyms1
  KSYMS   .tmp_vmlinux.kallsyms1.S
  AS      .tmp_vmlinux.kallsyms1.S
  LD      .tmp_vmlinux.kallsyms2
  KSYMS   .tmp_vmlinux.kallsyms2.S
  AS      .tmp_vmlinux.kallsyms2.S
  LD      vmlinux
  SORTTAB vmlinux
inconsistent ORC unwind table entries in file: vmlinux
Failed to sort kernel tables
make: *** [Makefile:1170: vmlinux] Error 1

So it looks like OpenMandriva Lx 4.1 is unable to compile either the mainline or stable kernels from kernel.org When I get more data to download the update packages, I'll have to finish converting my installation to a "rolling" install instead. As you can see, as soon as it finishes compiling the object code and tries to link the kernel's executable, it fails every time at that point. The above was the mainline kernel.

cynwulf · 12-14-2020, 10:20 AM

I forgot about your thread at their site the tool chain being too old may rule out any further attempts. Seems odd though. I suspect it's an llvm/clang specific issue.

I've been able to build 5.9.x and a recent 5.10 rc kernel on Debian buster without issue - but the intel display driver GPU hang bug has prevented me from using actually running either of those kernels and I'm stuck with 4.19. (edit: point being - that's an old too chain as well, probably older)

Your changes to CONFIG_UNWINDER_ORC, however would get reverted if you did not choose another unwinder. The options are:

Code:

CONFIG_UNWINDER_ORC=y
# CONFIG_UNWINDER_FRAME_POINTER is not set
# CONFIG_UNWINDER_GUESS is not set

This commit seems to suggest that the frame pointer unwinder works for clang: https://lkml.org/lkml/2019/8/1/1090 (that relates to arm by the way, but still seems relevant)

So you could make the following config change and give it one last shot:

Code:

#CONFIG_UNWINDER_ORC=y
CONFIG_UNWINDER_FRAME_POINTER=y
# CONFIG_UNWINDER_GUESS is not set

jsbjsb001 · 12-15-2020, 02:52 AM

Quote:

Originally Posted by cynwulf

...I suspect it's an llvm/clang specific issue.
...

Well, good news and bad news... it looks like you were right about having to set one of the unwinders, as when I commented out the orc unwinder and set the frame pointer unwinder it did in fact honor the change this time and used the frame pointer unwinder instead of the orc unwinder. Bad news is, it's still failed, although it did seem to get further this time. So based on the output in the code box below, I think we can confirm it's a LLVM/Clang issue. So it seems LLVM/Clang that I have on OpenMandriva 4.1 simply doesn't like the latest kernel. And I'd be willing to bet that trying the guess unwinder is likely to fail too. So I'll start the conversion process to convert my installation to "rolling" now I have bought more data.

I'll report back once the upgrade has finished and I can verify if the latest kernel fixes my problems with amdgpu or not.

Code:

MODPOST vmlinux.symvers
  MODINFO modules.builtin.modinfo
  GEN     modules.builtin
  LD      .tmp_vmlinux.kallsyms1
  KSYMS   .tmp_vmlinux.kallsyms1.S
  AS      .tmp_vmlinux.kallsyms1.S
  LD      .tmp_vmlinux.kallsyms2
  KSYMS   .tmp_vmlinux.kallsyms2.S
  AS      .tmp_vmlinux.kallsyms2.S
  LD      vmlinux
  SORTTAB vmlinux
  SYSMAP  System.map
  CC      arch/x86/boot/a20.o
  AS      arch/x86/boot/bioscall.o
  CC      arch/x86/boot/cmdline.o
  AS      arch/x86/boot/copy.o
  HOSTCC  arch/x86/boot/mkcpustr
  CPUSTR  arch/x86/boot/cpustr.h
  CC      arch/x86/boot/cpu.o
  CC      arch/x86/boot/cpuflags.o
  CC      arch/x86/boot/cpucheck.o
  CC      arch/x86/boot/early_serial_console.o
  CC      arch/x86/boot/edd.o
  LDS     arch/x86/boot/compressed/vmlinux.lds
  AS      arch/x86/boot/compressed/kernel_info.o
  AS      arch/x86/boot/compressed/head_64.o
  VOFFSET arch/x86/boot/compressed/../voffset.h
  CC      arch/x86/boot/compressed/misc.o
  CC      arch/x86/boot/compressed/string.o
  CC      arch/x86/boot/compressed/cmdline.o
  CC      arch/x86/boot/compressed/error.o
  OBJCOPY arch/x86/boot/compressed/vmlinux.bin
  RELOCS  arch/x86/boot/compressed/vmlinux.relocs
  ZSTD22  arch/x86/boot/compressed/vmlinux.bin.zst
  HOSTCC  arch/x86/boot/compressed/mkpiggy
  MKPIGGY arch/x86/boot/compressed/piggy.S
  AS      arch/x86/boot/compressed/piggy.o
  CC      arch/x86/boot/compressed/cpuflags.o
  CC      arch/x86/boot/compressed/early_serial_console.o
  CC      arch/x86/boot/compressed/kaslr.o
  CC      arch/x86/boot/compressed/ident_map_64.o
  CC      arch/x86/boot/compressed/idt_64.o
  AS      arch/x86/boot/compressed/idt_handlers_64.o
  AS      arch/x86/boot/compressed/mem_encrypt.o
  CC      arch/x86/boot/compressed/pgtable_64.o
  CC      arch/x86/boot/compressed/acpi.o
  LD      arch/x86/boot/compressed/vmlinux
ld: /builddir/build/BUILD/llvm-project-llvmorg-9.0.1/lld/ELF/SyntheticSections.h:1153: lld::elf::Partition &lld::elf::SectionBase::getPartition() const: Assertion `isLive()' failed.
Stack dump:
0.      Program arguments: ld -m elf_x86_64 -pie --no-dynamic-linker -T arch/x86/boot/compressed/vmlinux.lds arch/x86/boot/compressed/kernel_info.o arch/x86/boot/compressed/head_64.o arch/x86/boot/compressed/misc.o arch/x86/boot/compressed/string.o arch/x86/boot/compressed/cmdline.o arch/x86/boot/compressed/error.o arch/x86/boot/compressed/piggy.o arch/x86/boot/compressed/cpuflags.o arch/x86/boot/compressed/early_serial_console.o arch/x86/boot/compressed/kaslr.o arch/x86/boot/compressed/ident_map_64.o arch/x86/boot/compressed/idt_64.o arch/x86/boot/compressed/idt_handlers_64.o arch/x86/boot/compressed/mem_encrypt.o arch/x86/boot/compressed/pgtable_64.o arch/x86/boot/compressed/acpi.o drivers/firmware/efi/libstub/lib.a -o arch/x86/boot/compressed/vmlinux 
 #0 0x00007fcc9b31af72 (/usr/lib64/libLLVMSupport.so.9.0+0x210f72)
 #1 0x00007fcc9b31853e llvm::sys::RunSignalHandlers() (/usr/lib64/libLLVMSupport.so.9.0+0x20e53e)
 #2 0x00007fcc9b31b194 (/usr/lib64/libLLVMSupport.so.9.0+0x211194)
 #3 0x00007fcc9ad76b60 __restore_rt (/lib64/libc.so.6+0x44b60)
 #4 0x00007fcc9ad76ad7 raise (/lib64/libc.so.6+0x44ad7)
 #5 0x00007fcc9ad5755d abort (/lib64/libc.so.6+0x2555d)
 #6 0x00007fcc9ad57431 _nl_load_domain.cold (/lib64/libc.so.6+0x25431)
 #7 0x00007fcc9ad67962 (/lib64/libc.so.6+0x35962)
 #8 0x00007fcc9b7944ec (/usr/lib64/liblldELF.so.9.0+0x2594ec)
 #9 0x00007fcc9b829595 (/usr/lib64/liblldELF.so.9.0+0x2ee595)
#10 0x00007fcc9b7f97af (/usr/lib64/liblldELF.so.9.0+0x2be7af)
#11 0x00007fcc9b7f597a void lld::elf::writeResult<llvm::object::ELFType<(llvm::support::endianness)1, true> >() (/usr/lib64/liblldELF.so.9.0+0x2ba97a)
#12 0x00007fcc9b6821a4 void lld::elf::LinkerDriver::link<llvm::object::ELFType<(llvm::support::endianness)1, true> >(llvm::opt::InputArgList&) (/usr/lib64/liblldELF.so.9.0+0x1471a4)
#13 0x00007fcc9b672556 lld::elf::LinkerDriver::main(llvm::ArrayRef<char const*>) (/usr/lib64/liblldELF.so.9.0+0x137556)
#14 0x00007fcc9b670435 lld::elf::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&) (/usr/lib64/liblldELF.so.9.0+0x135435)
#15 0x0000000000202848 (/usr/bin/lld+0x202848)
#16 0x00007fcc9ad58e6b __libc_start_main (/lib64/libc.so.6+0x26e6b)
#17 0x000000000020202a (/usr/bin/lld+0x20202a)
/bin/sh: line 1: 339159 Aborted                 (core dumped) ld -m elf_x86_64 -pie --no-dynamic-linker -T arch/x86/boot/compressed/vmlinux.lds arch/x86/boot/compressed/kernel_info.o arch/x86/boot/compressed/head_64.o arch/x86/boot/compressed/misc.o arch/x86/boot/compressed/string.o arch/x86/boot/compressed/cmdline.o arch/x86/boot/compressed/error.o arch/x86/boot/compressed/piggy.o arch/x86/boot/compressed/cpuflags.o arch/x86/boot/compressed/early_serial_console.o arch/x86/boot/compressed/kaslr.o arch/x86/boot/compressed/ident_map_64.o arch/x86/boot/compressed/idt_64.o arch/x86/boot/compressed/idt_handlers_64.o arch/x86/boot/compressed/mem_encrypt.o arch/x86/boot/compressed/pgtable_64.o arch/x86/boot/compressed/acpi.o drivers/firmware/efi/libstub/lib.a -o arch/x86/boot/compressed/vmlinux
make[2]: *** [arch/x86/boot/compressed/Makefile:104: arch/x86/boot/compressed/vmlinux] Error 134
make[1]: *** [arch/x86/boot/Makefile:115: arch/x86/boot/compressed/vmlinux] Error 2
make: *** [arch/x86/Makefile:266: bzImage] Error 2

jsbjsb001 · 12-15-2020, 06:08 AM

Great news!

The system upgrade completed without any issues and I've now got kernel 5.9.14 (from packages)! I tried to reproduce the freezing of the display and no matter how many maps I looked at, and no matter how many times I zoomed in and out, no freezing occurred! Video playback is far more stable, and there doesn't seem to be any interruptions when connecting to my wifi access point. I've not tested the HDMI audio problem so I cannot confirm if that's fixed or not, but I can live with that since I've got my two speakers connected directly to the integrated sound anyway.

So I can confirm that nearly all of the problems I was having, if not all, have in fact been SOLVED! So I will mark the thread as [SOLVED].

And I even learnt a few things about compiling kernel's that I didn't expect, nor plan to learn - albeit unsuccessfully compiling the kernel.

Thanks to everyone for the help!

cynwulf · 12-15-2020, 08:14 AM

Ah, bad luck / good luck.

That last error has me baffled...

Good that it's working now though.

jsbjsb001 · 12-15-2020, 08:38 AM

Other than LLVM/Clang on my previous install apparently dislikes the latest kernel sources for whatever reason, I don't know what it's problem is either...

Although, I feel like downloading the latest kernel (5.10.1) and seeing if my new install will actually compile it this time. As it would nice to be able to do it at least once.

mrmazda · 12-20-2020, 01:59 AM

Quote:

Originally Posted by jsbjsb001

It's really tempting to try some rpm packages from another distro, it really is...

The reason I suggested Mageia is that like OpenMandriva, it's progeny of Mandrake -> Mandriva. You may be able to install it using rpm -i. If it installs but doesn't work, it doesn't work, so you boot the prior kernel and rpm -e it.

I use a Mageia rpm of fbset on openSUSE, which dropped fbset from its mirrors many moons ago.