How to improve amdgpu boot time?

seth · 2023-10-14 15:24:54

The system doesn't stall during the activation, actually SDDM starts before.

Oct 14 16:46:51 archlinux kernel: [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0
Oct 14 16:46:51 archlinux kernel: simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device

Add nvidia_drm.modeset=1 (yes I know, it'll prevent the simpledrm device) and in doubt "initcall_blacklist=simpledrm_platform_driver_init" to the https://wiki.archlinux.org/title/Kernel_parameters

Next step: try the behavior of the LTS kernel.

Beesh · 2023-10-14 15:56:51

Unfortunately those both tries failed too

1) first run:
nvidia_drm.modeset=1
initcall_blacklist=simpledrm_platform_driver_init

journalctl -b

Oct 14 17:32:41 Thripperino-arch systemd-timesyncd[1373]: Network configuration changed, trying to establish connection.
Oct 14 17:33:04 Thripperino-arch systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Oct 14 17:33:11 Thripperino-arch systemd-timesyncd[1373]: Contacted time server 162.159.200.1:123 (2.pool.ntp.org).
Oct 14 17:33:11 Thripperino-arch systemd-timesyncd[1373]: Initial clock synchronization to Sat 2023-10-14 17:33:11.444277 CEST.
Oct 14 17:33:27 Thripperino-arch kernel: amdgpu 0000:03:00.0: amdgpu: STB initialized to 2048 entries

2) second run:
nvidia_drm.modeset=1
initcall_blacklist=simpledrm_platform_driver_init
LTS

journalctl -b

Oct 14 17:45:12 Thripperino-arch systemd-networkd[1180]: lab: Gained IPv6LL
Oct 14 17:45:35 Thripperino-arch systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Oct 14 17:46:00 Thripperino-arch kernel: amdgpu 0000:03:00.0: amdgpu: STB initialized to 2048 entries

and beside the delay, that journal recession persist too:

Oct 14 18:10:28 archlinux systemd[1]: Reached target Switch Root.
Oct 14 18:10:28 archlinux systemd[1]: Starting Switch Root...
Oct 14 18:10:29 archlinux systemd[1]: Switching root.
Oct 14 18:10:29 archlinux systemd-journald[562]: Journal stopped
Oct 14 18:10:20 archlinux kernel: Linux version 6.5.7-arch1-1 (linux@archlinux) (gcc (GCC) 13.2.1 20230801, GNU ld (GNU Binutils) 2.41.0) #1 SMP PREEMPT_DYNAMIC Tue, 10 Oct 2023 21:10:21 +0000
Oct 14 18:10:20 archlinux kernel: Command line: initrd=amd-ucode.img initrd=initramfs-linux.img rd.luks.name=4ae5adb5-cfaa-468e-8de1-e1fc97f53969=root root=/dev/mapper/root nowatchdog quiet splash plymouth rw
Oct 14 18:10:20 archlinux kernel: BIOS-provided physical RAM map:
Oct 14 18:10:20 archlinux kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
Oct 14 18:10:20 archlinux kernel: BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved
Oct 14 18:10:20 archlinux kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000003ffffff] usable

Last edited by Beesh (2023-10-14 16:49:05)

seth · 2023-10-14 16:17:53

*grumpf*

Are you loading amd_pmc?

lsmod | grep pmc

What if you disable the STB there

amd_pmc.enable_stb=0

(There's an awesome amount of ACPI errors, this might be your board…)

Beesh · 2023-10-14 16:44:39

1) first run

amd_pmc enabled

...
MODULES=(amd_pmc)
...

delay still there

journalctl -b

2) second run
amd_pmc enabled

...
MODULES=(amd_pmc)
...

amd_pmc.enable_stb=0

title Arch Linux
linux vmlinuz-linux
initrd amd-ucode.img
initrd initramfs-linux.img
options rd.luks.name=4ae5adb5-cfaa-468e-8de1-e1fc97f53969=root root=/dev/mapper/root amd_pmc.enable_stb=0 nowatchdog quiet splash plymouth rw

delay still there

journalctl -b

seth wrote:

(There's an awesome amount of ACPI errors, this might be your board…)

It's the board fault indeed, I was already keeping an eye on that but it seems that the problem is at the vendor will, I can only stay on the latest firmware.

Last edited by Beesh (2023-10-14 16:54:34)

seth · 2023-10-14 20:32:19

There's no point in adding the module to the initramfs or explicitly loading it - if it's not loaded implicitly, it won't do anything.

The last thing before the delay that happens on the device is actually

Oct 14 18:33:39 Thripperino-arch kernel: input: HDA ATI HDMI HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.1/sound/card0/input25
Oct 14 18:33:39 Thripperino-arch kernel: input: HDA ATI HDMI HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.1/sound/card0/input26
Oct 14 18:33:39 Thripperino-arch kernel: input: HDA ATI HDMI HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.1/sound/card0/input27
Oct 14 18:33:39 Thripperino-arch kernel: input: HDA ATI HDMI HDMI/DP,pcm=10 as /devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.1/sound/card0/input28
Oct 14 18:33:39 Thripperino-arch kernel: input: HDA ATI HDMI HDMI/DP,pcm=11 as /devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.1/sound/card0/input29

"amdgpu.audio=0"
And while at it anyway, maybe also the other usual suspects:
"amdgpu.runpm=0 amdgpu.bapm=0 amdgpu.aspm=0 pcie_aspm=off"

Beesh · 2023-10-15 08:13:08

I'm not implicitly loading it, so I removed it from initramfs.

Unfortunately even those kernel parameters led to nothing.

journal -b

seth · 2023-10-15 08:39:50

The audio device is sill there/used. No idea whether it's really relevant (the access is almost a minute before STB), but

pci-stub.ids=1002:ab28

Since this is most likely not gonna help either, the next broadsword would be "acpi=off". This has multiple repercussions and is not a viable solution, but maybe helps to figure where the delay is coming from.

Beesh · 2023-10-15 09:02:19

seth wrote:

The audio device is sill there/used. No idea whether it's really relevant (the access is almost a minute before STB), but
pci-stub.ids=1002:ab28
Since this is most likely not gonna help either, the next broadsword would be "acpi=off". This has multiple repercussions and is not a viable solution, but maybe helps to figure where the delay is coming from.

disabling acpi won't let me boot at all, it doesn't even reach the dm-crypt prompt

seth · 2023-10-15 13:57:09

Does "pci=noacpi" work?

Beesh · 2023-10-15 17:27:47

just tried, black screen after bootloader and all peripherals disabled
the light at the end of this tunnel is fading away

seth · 2023-10-15 20:29:38

Simplify the system as possible, remove all external HW (replace the gaming stuff w/ a $5 keyboard) and boot the install iso. Does the AMD GPU take its time in that context as well?

Beesh · 2023-10-16 17:24:59

I already did the peripherals free try (see #11) but booting the live iso gave me the final answer, this is where the stall happens:

live boot errors

I don't recall this problem in the past, so was probably some motherboard firmware update that worsened the linux stability.

Am I done for good with this?

edit: this seems to be related. There's hope for this kind of bug reporting to be looked on, kernel side?

Last edited by Beesh (2023-10-16 18:02:28)

seth · 2023-10-16 19:00:53

Does the iso boot stop there? And/or does the amdgpu device also just time out? (Not sure whether the display output is relevant, I guess the iso has the "quiet" parameter in place)
If the boot continues, did you inspect the journal of the iso?
(However, since it also stalls, it's some HW thing for sure and not just one of your many services)

I already did the peripherals free try (see #11)

Yes, but not w/ the iso (in case this was some HW/SW interplay)

If this is a regression, you could try to downgrade the board FW?
Though, if the only problem really is a 1m delay during the boot, I'd probably not risk that…

Beesh · 2023-10-16 19:11:17

seth wrote:

If this is a regression, you could try to downgrade the board FW?
Though, if the only problem really is a 1m delay during the boot, I'd probably not risk that…

On a funny note, that's exactly what I said to myself out loud as soon as I realized it could be a firmware problem.

seth wrote:

Does the iso boot stop there? And/or does the amdgpu device also just time out? (Not sure whether the display output is relevant, I guess the iso has the "quiet" parameter in place)
If the boot continues, did you inspect the journal of the iso?

It has the same symptoms: the iso boot continues after stalling ~50 seconds on that screen. As soon as I can I'll extract and post here the live arch journal logs

Last edited by Beesh (2023-10-16 19:12:59)

seth · 2023-10-17 07:26:32

Does the board have more than one PEG slot?
Even if not, does the GPU behave the same in a different slot?

Beesh · 2023-10-17 07:48:25

journal -b
dmesg -t

on live boot tests journal do not report the delay but dmesg do.
I also did a run with every peripherals detached, with only an old membrane keyboard attached, but problem is still there.

seth wrote:

Does the board have more than one PEG slot?
Even if not, does the GPU behave the same in a different slot?

I could do that but I'm not eager to find out that the culprit is on hardware configuration, because changing components or their layout is out of question right now. Nevertheless I'm gonna try out some uefi pci-e tweaking.

Arch Linux

#26 2023-10-14 15:24:54

Re: How to improve amdgpu boot time?

#27 2023-10-14 15:56:51

Re: How to improve amdgpu boot time?

#28 2023-10-14 16:17:53

Re: How to improve amdgpu boot time?

#29 2023-10-14 16:44:39

Re: How to improve amdgpu boot time?

#30 2023-10-14 20:32:19

Re: How to improve amdgpu boot time?

#31 2023-10-15 08:13:08

Re: How to improve amdgpu boot time?

#32 2023-10-15 08:39:50

Re: How to improve amdgpu boot time?

#33 2023-10-15 09:02:19

Re: How to improve amdgpu boot time?

#34 2023-10-15 13:57:09

Re: How to improve amdgpu boot time?

#35 2023-10-15 17:27:47

Re: How to improve amdgpu boot time?

#36 2023-10-15 20:29:38

Re: How to improve amdgpu boot time?

#37 2023-10-16 17:24:59

Re: How to improve amdgpu boot time?

#38 2023-10-16 19:00:53

Re: How to improve amdgpu boot time?

#39 2023-10-16 19:11:17

Re: How to improve amdgpu boot time?

#40 2023-10-17 07:26:32

Re: How to improve amdgpu boot time?

#41 2023-10-17 07:48:25

Re: How to improve amdgpu boot time?

Board footer