You are not logged in.
If you boot with amdgpu blacklisted, make sure it is not loaded in the lsmod output can you still reproduce the issue?
Offline
If you boot with amdgpu blacklisted, make sure it is not loaded in the lsmod output can you still reproduce the issue?
Should I do 'blacklist amdgpu' or 'install amdgpu /bin/true'?
Offline
I would try blacklisting from the bootloader as that is the quickest to test and does not persist beyond that boot. If the module is still loaded then move onto 'install amdgpu /bin/true'.
Offline
"module_blacklist=amdgpu" will prevent the module from being loaded at all (you cannot even insmod it anymore) "modprobe.blacklist=amdgpu" will prevent auto-loading by HW alias.
Offline
"module_blacklist=amdgpu" and "modprobe.blacklist=amdgpu" lead both to the black screen with just a "_"
Offline
Same situation as before.
@loqs, did you see https://bbs.archlinux.org/viewtopic.php … 5#p2123755 suggesting that nomodeset+multi-user allows reboots?
Offline
For whatever reason I just had a correct restart once but now it's back to not powering off if I do it again. Here is a journal of when it actually did restart: https://0x0.st/HVdM.txt
Offline
Please don't copy and paste out of the pager, it truncates lines.
(modinfo amdgpu; systool -vm amdgpu) | curl -F 'file=@-' 0x0.st
Offline
Please don't copy and paste out of the pager, it truncates lines.
Noted, didn't notice. sry.
(modinfo amdgpu; systool -vm amdgpu) | curl -F 'file=@-' 0x0.st
Edit: I tried restarting it a couple of times and maybe in 10% of the cases it's acutally restarting/shutting down. Here are non-trucated logs:
No restart: https://0x0.st/HVnc.txt
Restart: https://0x0.st/HVnm.txt
Last edited by DinoNugget1337 (2023-09-30 13:46:33)
Offline
Nothing amdgpu and only minimal ACPI difference:
-ACPI: SSDT 0xFFFFA10040F7D800 00078C (v02 PmRef Cpu0Ist 00003000 INTL 20160527)
+ACPI: SSDT 0xFFFF8C684150F800 00078C (v02 PmRef Cpu0Ist 00003000 INTL 20160527)
-ACPI: SSDT 0xFFFFA10040F8F400 000400 (v02 PmRef Cpu0Cst 00003001 INTL 20160527)
+ACPI: SSDT 0xFFFF8C684151B400 000400 (v02 PmRef Cpu0Cst 00003001 INTL 20160527)
-ACPI: SSDT 0xFFFFA10040F81000 000EF1 (v02 PmRef ApIst 00003000 INTL 20160527)
+ACPI: SSDT 0xFFFF8C6841510000 000EF1 (v02 PmRef ApIst 00003000 INTL 20160527)
-ACPI: SSDT 0xFFFFA10040F8C800 000317 (v02 PmRef ApHwp 00003000 INTL 20160527)
+ACPI: SSDT 0xFFFF8C684151D400 000317 (v02 PmRef ApHwp 00003000 INTL 20160527)
-ACPI: SSDT 0xFFFFA10040F8FC00 00030A (v02 PmRef ApCst 00003000 INTL 20160527)
+ACPI: SSDT 0xFFFF8C684151BC00 00030A (v02 PmRef ApCst 00003000 INTL 20160527)
You've already disabled amdgpu.aspm and there's no parameter to control the wacko AGP value.
Since it's apparently a race condition, try
a) https://wiki.archlinux.org/title/Kernel … _KMS_start
b) to plug the GPU into a different(?) PCI (PEG?) slot
Offline
Since it's apparently a race condition, try
Sorry for being a noob but what indicates this being a race condition? I'm really interested in knowing what makes this issue appear in Arch but never in Mint? A few weeks back I tried out endevourOS where I encountered the same problem which made me go back to Mint where it worked again. Some amdgpu firmware stuff? As far as I understand Mint is based on Ubuntu LTS which doesn't have up-to-date linux-firmware so by default my RX 7800 XT wasn't working there. What I did there is to get the latest linux-firmware from git so Linux Mint has that.
So as far as I understood I added amdgpu to MODULES in /etc/mkinitcpio.conf and did mkinitcpio -p rebooted twice and same problem. Did I do that correctly?
b) to plug the GPU into a different(?) PCI (PEG?) slot
Only have one PCIe x16 other ones are x8,x4
Last edited by DinoNugget1337 (2023-09-30 15:58:16)
Offline
what indicates this being a race condition?
The behavior (on arch) is non-deterministic and depends on a kernel module that's loaded during the boot.
Mint is based on Ubuntu LTS which doesn't have up-to-date linux-firmware so by default my RX 7800 XT wasn't working there. What I did there is to get the latest linux-firmware from git so Linux Mint has that.
Errrrm… did the reboot work after you got your GPU to work on Mint?
(A Mint log sounds even more interesting now, cause rebooting w/o GPU works on arch, too)
Did I do that correctly?
Yes, the updated log should reflect that by showing the amdgpu module much earlier during the boot.
Only have one PCIe x16 other ones are x8,x4
Does the GPU still initialize in one of those?
(The idea would be some™ overlappign address space and the GPU interferin w/ the ACPI this way)
Does
pci=noacpi acpi=noirq noapic
help?
Alternatively
acpi=rsdt
instead of noirq?
Offline
Possibly try late loading KMS by removing the kms hook and amdgpu module from mkinitcpio.conf then regenrate the initrd and reboot.
Offline
Errrrm… did the reboot work after you got your GPU to work on Mint?
(A Mint log sounds even more interesting now, cause rebooting w/o GPU works on arch, too)
Yes, reboot and shutdown always worked, no problems there.
Yes, the updated log should reflect that by showing the amdgpu module much earlier during the boot.
Ok, then it did not help. Will try to swap my GPU in another slot tomorrow.
pci=noacpi acpi=noirq or rsdt noapic
None of these help either. 'pci=noacpi doesn't even let me boot
late loading KMS by removing the kms hook and amdgpu module from mkinitcpio.conf
Also doesn't work.
Offline
Ok.....so I wanted to put my GPU into the x8 slot but the power cables didn't reach until that point and I also had to open the back so I didn't bother.
Then I reset my bios and made sure fastboot is disabled, completely erased ALL data including Windows after backing up some stuff on my laptop. With everything wiped I reinstalled Arch, but this time with archinstall instead of doing it manually, to see if it would work then but still the same problem.
Edit: Any idea why "sudo systemctl reboot --force --force" always reboots/powers off completely?
Last edited by DinoNugget1337 (2023-10-01 10:24:03)
Offline
Edit: Any idea why "sudo systemctl reboot --force --force" always reboots/powers off completely?
Whoa, that's news. Isn't? Did I miss that?
If --force is specified twice, the operation is immediately executed without terminating any processes or unmounting any file systems.
This may result in data loss.
Note that when --force is specified twice the halt operation is executed by systemctl itself, and the system manager is not contacted.
This means the command should succeed even when the system manager has crashed.
The journal didn't sugggest any related issues, but here we are.
Is "--force --force" required or do you get away w/ a single one?
Is this only after the archinstall install? Did you try before?
Please an updated system journal for the boot:
sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st
Last edited by seth (2023-10-01 13:30:00)
Offline
Tried that on my previous arch install last night and "--force --force" worked there as well. Only one "--force" doesn't work. Also, since I removed Windows I now installed Mint again, alongside of Arch, so I can try out stuff there now as well if needed. Newest firmware and 6.5.5 kernel and no issue in Mint, just in arch.
Mint, new firmware, 6.5.5 kernel - always working - http://0x0.st/HWsG.txt
Arch, normal reboot via button in menu - not working - http://0x0.st/HWzi.txt
Arch, one "--force" - not working - http://0x0.st/HWzA.txt
Arch, "--force --force" - always working - http://0x0.st/HWzK.txt
Offline
More interesting
Oct 01 15:56:17 archlinux systemd[1]: Using hardware watchdog 'iTCO_wdt', version 6, device /dev/watchdog0
Oct 01 15:56:17 archlinux systemd[1]: Watchdog running with a timeout of 10min.
Oct 01 15:56:17 archlinux kernel: watchdog: watchdog0: watchdog did not stop!
Oct 01 15:56:17 archlinux systemd-shutdown[1]: Using hardware watchdog 'iTCO_wdt', version 6, device /dev/watchdog0
Oct 01 15:56:17 archlinux systemd-shutdown[1]: Watchdog running with a timeout of 10min.
Oct 01 15:56:17 archlinux systemd-shutdown[1]: Syncing filesystems and block devices.
Oct 01 15:56:17 archlinux systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Oct 01 15:56:17 archlinux systemd-journald[295]: Received SIGTERM from PID 1 (systemd-shutdow).
module_blacklist=iTCO_wdt
Offline
module_blacklist=iTCO_wdt
Also doesn't work: http://0x0.st/HWzn.txt
Offline
It worked to make the watchdog disappear, but apparently it wasn't the cause
Are there any errors on the console after the halt?
Fwwi the Mint takedown is actually way messier, but this here
Received SIGTERM from PID 1 (systemd-shutdow)
doesn't show up…
What if you "disable" the journal?
https://man.archlinux.org/man/journald. … en#OPTIONS
Storage=none
Offline
If I understand correctly, this is a desktop with a single AMD GPU, correct? Is it possible to disable the AMD GPU in the BIOS and enable the integrated gpu?
Last edited by topcat01 (2023-10-01 23:58:17)
Offline
What if you "disable" the journal?
https://man.archlinux.org/man/journald. … en#OPTIONSStorage=none
Nope, also doesn't work
Is it possible to disable the AMD GPU in the BIOS and enable the integrated gpu?
Yes, I have tried this and with integrated gpu the reboot is always working: http://0x0.st/HWXc.txt
Offline
Also has
Oct 02 00:13:13 archlinux systemd-journald[296]: Received SIGTERM from PID 1 (systemd-shutdow).
so more red herrings.
We know
a) it's related to amdgpu (+modesetting) b/c of "nomodeset" and i915 working
b) it's related to systemd (because "--force --force" ./. "--force")
Are there any errors on the console after the halt?
Offline
Are there any errors on the console after the halt?
How/Where would I see that?
Offline
On your monitor at the end of the shotdown when the system doesn't power off.
It won't get logged to the journal anymore at this point.
You might have to get rid of the "quiet" parameter and possibly add https://wiki.archlinux.org/title/Genera … l_messages
Offline