[WORKAROUND] shutdown will reboot to failed boot (6.8.4 and 6.8.5)

d.ALT · 2024-04-12 09:04:10

Arch preforms reboot instead of shutdown.

When shutting-down (from Plasma or within Konsole # poweroff), computer will instead reboot.
Such reboot will then always fail with output posted in the attached photo.
Happens on 6.8.4.arch1-1 (and on linux-ck-generic-v3-6.8.1-1-x86_64).

[...]

Welcome to Arch Linux!

** 296111 printk messages dropped **
[ 245.507137] INFO: task systemd:1 blocked for more than 122 seconds.
[ 245.507164]	Tainted: P	OE	6.8.4-arch1-1 #1
[ 245.507176] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

[...]

[ 607.773801] INFO: rcu_tasks detected stails on task:
[ 607.773822] 000000002232511d: .. nvcsw: 3/3 holdout: 1 idle_spu: -1/5

[...]

[ 1130.788737] usb usb1-port13: disabled by hub (EMI?), re-enabling...

[...]

Not on my PC atm, please let me know what more infos do you need.

Wifi+Bluetooth: https://www.tp-link.com/us/home-network … ifications
CPU: Ryzen 7 1700
GPU: nVIDIA GTX1600 SUPER (https://archlinux.org/packages/extra/x8 … idia-dkms/)
SWAP: zram (NO swapfile, NO zswap)

Kernel's commandline has:

nvidia.NVreg_TemporaryFilePath="/var/tmp" nvidia.NVreg_PreserveVideoMemoryAllocations=1 nvidia_drm.fbdev=1 nvidia_drm.modeset=1

nvidia_drm.conf:

options nvidia_drm fbdev=1 modeset=1

nvidia.conf:

options nvidia NVreg_UsePageAttributeTable=1 NVreg_TemporaryFilePath="/var/tmp" NVreg_PreserveVideoMemoryAllocations=1

Thanks

Last edited by d.ALT (2024-04-13 13:38:59)

seth · 2024-04-12 09:46:42

The remedy is then that you reboot or shutdown the system w/ the power button out of the failed reboot?
Can you post the journal of the previous boot (the one where you wanted to shutdown) and try to preserve the one w/ the failed boot using https://wiki.archlinux.org/title/Keyboa … el_(SysRq)
?

On a hunch: add "noresume" to the kernel parameters, https://bbs.archlinux.org/viewtopic.php … 9#p2162819
Theory being that the UEFI thinks it's time to wake up from hibernation - also see https://bbs.archlinux.org/viewtopic.php?id=290126

d.ALT · 2024-04-12 19:33:55

seth wrote:

you reboot or shutdown the system w/ the power button out of the failed reboot?

Precisely.
Keyboard (and mouse) is 100% dead: both Num Lock and CAPS Lock indicators are NOT responding.

seth wrote:

post the journal of the previous boot (the one where you wanted to shutdown)

http://0x0.st/X-Q6.txt

seth wrote:

preserve the one w/ the failed boot using https://wiki.archlinux.org/title/Keyboa … el_(SysRq)

Nope.

But! ... I managed to get some output on e letter of the sequence: Alt+SysRq+r+e.
This, sadly, led me to still NO journalctl, due to issuing the above sequence before Systemd is started (I suppose).
I press the sequence immediately after I see some display activity (from "light black" to "bright dark black") after rEFInd boots Arch.
Anyway, the output is a veryveryvery fast and looooooooong repeated continuous list of:

piceport 0000:00:01.3: PME: Spurious native interrupt!

That message goes repeatedly printed on screen for >8mins (after that I got tired and restarted via Reset Button)

seth wrote:

add "noresume" to the kernel parameters

Does nothing

Maniaxx · 2024-04-12 20:13:59

What mainboard is it? Did you check for BIOS update? Looks like the system is partially in wrong sleep-state. Check the BIOS settings and disable suspend-to-ram, suspend-to-disk and other ACPI sleep-states (only keep S0, S5).
Not sure if 'reboot=' is related to shutdown as well but i once had the opposite problem (reboot led to shutdown) on an old HP/Compaq laptop. I could fix it by setting kernel parameter 'reboot=w,p'. Here is little bit more about it.

seth · 2024-04-12 22:32:27

piceport 0000:00:01.3: PME: Spurious native interrupt!

re-check what Alt+SysRq+r does

The journal of the previous boot ends early, the shutdown migth have lead to a CPU hiccup, https://wiki.archlinux.org/title/Ryzen#Troubleshooting
If you run "systemctl halt" or add "acpi=off" to the kernel commandline, does the system still reboot?
Speaking of which: what if you remove "nowatchdog"?

d.ALT · 2024-04-13 12:33:16

Maniaxx wrote:

What mainboard is it? Did you check for BIOS update? Looks like the system is partially in wrong sleep-state. Check the BIOS settings and disable suspend-to-ram, suspend-to-disk and other ACPI sleep-states (only keep S0, S5).

ASUS PRIME X370-PRO with latest UEFI update (I update on January). I use suspend-to-RAM a lot: I'd like to keep using that functionality.

seth wrote:

If you run "systemctl halt" or add "acpi=off" to the kernel commandline, does the system still reboot?
Speaking of which: what if you remove "nowatchdog"?

# systemctl halt causes freeze (or Kernel Panic?) and I canNOT perform SysRq, but a journal is saved: http://0x0.st/X-LM.txt
This is interesting: on screen appears a glitched white square in the upper-right corner (the same you see in the photo attached to post #3)

... acpi=off ... causes Arch failing to complete the whole boot phase, but a journal is saved: http://0x0.st/X-L1.txt

... nowatchdog ... does nothing.

Side notes:

suspend (and resume) works perfectly (as it have always done since from I'm using Arch onto this machine)
upgraded 6.8.5-arch1-1 to, issue persist

d.ALT · 2024-04-13 13:36:35

As for "now", my issue is solved thanks to linux-lts 6.6.26-1.

seth wrote:

The journal of the previous boot ends early, the shutdown migth have lead to a CPU hiccup, https://wiki.archlinux.org/title/Ryzen#Troubleshooting

In the early days of Ryzen bugs (my 7 1700 was* affected by 4.3 Soft lock freezing) I workaround the freezes (was around ... 2018? 2019?) using NOT what is suggested in 4.3 Soft lock freezing, but by setting in UEFI the option Typical current idle as suggested in 4.4 Freeze on shutdown, reboot and suspend.
Thus, in my case, the problem addressed in section 4.3, was solved thanks to the solution in step 4.4... Pretty weird, uh?

Anyway... At some point in time, due to a new Kernel Release and/or a new ASUS' UEFI Release (I don't remember), problem was "magically" solved* and I managed to get my Ryzen working perfectly fine even though I had set Low current idle afterwards!

(*)was because is related to a software implementation which solved the bug, obviously, since my CPU still is hardware bugged (and always will be)

journalctl of working linux-lts

Last edited by d.ALT (2024-04-13 13:43:28)

seth · 2024-04-13 13:40:01

# systemctl halt causes freeze (or Kernel Panic?) and I canNOT perform SysRq

Nothing of that, it causes https://i.stack.imgur.com/jbD97.png
So there's no issue w/ halting the system, the misbehavior comes from the poweroff hint.
Have you tried to undo the previous mitigation?

Ftr, the acpi=off system boots, but the nvidia device can't be probed so you end up w/ no output.
Booting the multi-user.target (along nomodeset) will most likely still work.

d.ALT · 2024-04-13 13:48:35

<EDIT>

seth wrote:

Ftr, the acpi=off system boots, but the nvidia device can't be probed so you end up w/ no output.
Booting the multi-user.target (along nomodeset) will most likely still work.

http://0x0.st/X-9P.txt < $ sudo poweroff leads to NO shutdown at all.
Screen goes black but stays on (monitor's LED indicator remains active, like there was still output signal from GPU) instead of changing its status into Standby/No Signal.
Keyboard is unresponsive: both Num Lock and CAPS Lock indicators are NOT responding.

Sorry... Here's the correct journalctl: http://0x0.st/X-9L.txt
It seems Arch is indeed shutting-down correctly.
</EDIT>

seth wrote:

# systemctl halt causes freeze (or Kernel Panic?) and I canNOT perform SysRq
Nothing of that, it causes https://i.stack.imgur.com/jbD97.png

Oh... Yeah, that's what halt does, yes!
Now I remember: I just need to press the Power Button, indeed!! Shame on me

seth wrote:

Have you tried to undo the previous mitigation?

Which??? Do you want me to try by removing ... mitigations=off ... ?

Last edited by d.ALT (2024-04-13 14:19:53)

seth · 2024-04-13 14:35:53

which?

the solution in step 4.4

Though I guess you did?

managed to get my Ryzen working perfectly fine even though I had set Low current idle afterwards!

So then what if you re-establish that mitigation?

Since this is a regression, has it affected every 6.8 kernel? Also 6.7?
Or only 6.8.4,5?

d.ALT · 2024-04-14 10:12:41

seth wrote:

which?
the solution in step 4.4
Though I guess you did?

Yup! None works: Typical current idle, AUTO and Low current idle .

seth wrote:

managed to get my Ryzen working perfectly fine even though I had set Low current idle afterwards!
So then what if you re-establish that mitigation?

See above.

seth wrote:

Since this is a regression, has it affected every 6.8 kernel? Also 6.7?
Or only 6.8.4,5?

$ uname -srno
Linux ARCH-RYZEN 6.7.9-arch1-1 GNU/Linux

Is working fine, here's the journalctl: http://0x0.st/X-y8.txt

Arch Linux

#1 2024-04-12 09:04:10

[WORKAROUND] shutdown will reboot to failed boot (6.8.4 and 6.8.5)

#2 2024-04-12 09:46:42

Re: [WORKAROUND] shutdown will reboot to failed boot (6.8.4 and 6.8.5)

#3 2024-04-12 19:33:55

Re: [WORKAROUND] shutdown will reboot to failed boot (6.8.4 and 6.8.5)

#4 2024-04-12 20:13:59

Re: [WORKAROUND] shutdown will reboot to failed boot (6.8.4 and 6.8.5)

#5 2024-04-12 22:32:27

Re: [WORKAROUND] shutdown will reboot to failed boot (6.8.4 and 6.8.5)

#6 2024-04-13 12:33:16

Re: [WORKAROUND] shutdown will reboot to failed boot (6.8.4 and 6.8.5)

#7 2024-04-13 13:36:35

Re: [WORKAROUND] shutdown will reboot to failed boot (6.8.4 and 6.8.5)

#8 2024-04-13 13:40:01

Re: [WORKAROUND] shutdown will reboot to failed boot (6.8.4 and 6.8.5)

#9 2024-04-13 13:48:35

Re: [WORKAROUND] shutdown will reboot to failed boot (6.8.4 and 6.8.5)

#10 2024-04-13 14:35:53

Re: [WORKAROUND] shutdown will reboot to failed boot (6.8.4 and 6.8.5)

#11 2024-04-14 10:12:41

Re: [WORKAROUND] shutdown will reboot to failed boot (6.8.4 and 6.8.5)

Board footer