I’m experiencing an issue that I have no idea how to fix. After rebooting (or shutting down and starting up) from Linux (Manjaro), my system fails to boot, and it hangs before POSTing, showing Code 30 on the motherboard debug LED. A full power cycle (shutdown + psu switch + mashing power button) is required to boot successfully.
Code 30 is “System waking up from sleep (S3)” so I went in the direction of disabling every single instance of hibernation and sleep in BIOS and in the system too, to no avail.
System Info
Distro: Manjaro (up to date)
Kernel: 6.12.28-1
Motherboard: ASrock B550 Steel Legend
BIOS version: 3.61 (Beta) (updated from 2.40, didn’t fix the problem)
CPU: R7 5800X3D
GPU: RTX3090
RAM: 32GB DDR4 3200Mhz (xmp on)
Bootloader: rEFInd (has a separate partition)
Windows dual-boot: Yes (Windows works fine)
Symptoms
After rebooting from Linux, system hangs before POST
Motherboard displays POST code 30 (ACPI S3 resume), and fans spin at full speed
System only boots after full power-off (PSU switch → mash on power button → PSU switch back on → power on)
Windows 11 reboots and shuts down, then starts up without issue
RGB/USB devices (e.g. Razer Chroma) also fail to reinitialize properly after reboot until full power cycle
Things I’ve Tried
Updated BIOS to latest version (3.61 [Beta] from 2.40)
Disabled Suspend to RAM / ACPI S3 in BIOS
Disabled Fast Boot in BIOS
Disabled USB power during S5/S4
Kernel param: noresume
Verified /sys/power/resume = 0
Checked dmesg for resume attempts — none
Disabled USB autosuspend: usbcore.autosuspend=-1
Windows reboots and starts up cleanly every time
(OpenRGB also fails to detect devices after reboot, only works after power cycle, not sure if that’s related. e.g. a razer chroma. works on windows)
What I Haven’t Tried Yet
Booting into an older kernel (e.g. 6.6)
Has anyone experienced something like this? I’ve been troubleshooting for days, and I really feel like just dropping the entire thing and returning to Windows…
Topic nearly completely matches this one
However, sadly the BIOS update didn’t fix it for me.
It also looks like my direction of disabling hibernation and sleep is not the right one…
Hi, thanks a lot for the quick reply and the welcome.
Here are the settings in Windows 11:
PS C:\Users\hunty> powercfg /a
The following sleep states are not available on this system:
Standby (S1)
The system firmware does not support this standby state.
Standby (S2)
The system firmware does not support this standby state.
Standby (S3)
The system firmware does not support this standby state.
Hibernate
Hibernation has not been enabled.
Standby (S0 Low Power Idle)
The system firmware does not support this standby state.
Hybrid Sleep
Standby (S3) is not available.
Hibernation is not available.
Fast Startup
Hibernation is not available.
So yeah it’s off, I always turn it off so it’s been like this for years now.
I don’t think either of those things will make a difference, and especially not refind, given that your system doesn’t even reach refind yet when the hang occurs. It’s still in the firmware environment.
I don’t think changing the kernel would make a difference either. It’s possible — some quirk in the kernel’s shutdown code that’s specific to your hardware — but I really doubt it.
Come to think of it, it could very likely be that Asrock is deviating from the standard here with its firmware and thus its ACPI table in order to “fix” its firmware. The quirk will probably be known on Windows, and they have a rule for it internally, but nothing has been noted for Linux, which adheres to standards. This wouldn’t be the first time something like this has happened.
The quirk seems to be that Linux executes a warm reboot via ACPI, but this is recognized by the firmware as a suspend command. That would be the obvious assumption.
Since Windows claims that the UEFI does not support S3, that is probably where the error lies:
So: Linux → Reboot → ACPI Reboot is somewhat linked to the dead S3 Standby on the firmware → Therefore error 30
As workaround, you could try to do a cold reboot:
reboot= [KNL]
Format (x86 or x86_64):
[w[arm] | c[old] | h[ard] | s[oft] | g[pio]] | d[efault] \
[[,]s[mp]#### \
[[,]b[ios] | a[cpi] | k[bd] | t[riple] | e[fi] | p[ci]] \
[[,]f[orce]
Where reboot_mode is one of warm (soft) or cold (hard) or gpio
(prefix with 'panic_' to set mode for panic
reboot only),
reboot_type is one of bios, acpi, kbd, triple, efi, or pci,
reboot_force is either force or not specified,
reboot_cpu is s[mp]#### with #### being the processor
to be used for rebooting.
Earlier you stated that it doesn’t always happen. In other words, there is a randomness involved. This leads me to suspect that it’s either one of the two following potential causes…
A physical flaw in one of the components on the motherboard.
A problem with your power supply, and/or with the power cables to the various components in your machine.
Yeah, though just now it happened 5/5 times… I remembered as I could actually reboot yesterday once without code 30… but I’ve been rebooting so much for testing that I might have just imagined it.
To be honest I just don’t know why the problem doesn’t happen in Windows, if there would be a hardware fault then I’d expect it to appear there too, but I can restart / startup there 10/10 times correctly.
You’re right, I didn’t type it correctly here on the forum, but I added it to the params like this reboot=cold
commit 32b7c46c4dae93fb5e9a8c2f33fefbb160d2808f
Author: Gautham R. Shenoy gautham.shenoy@amd.com
Date: Thu May 29 14:21:43 2025 +0530
acpi-cpufreq: Fix nominal_freq units to KHz in get_max_boost_ratio()
commit cb6a85f38f456b086c366e346ebb67ffa70c7243 upstream.
commit 083466754596 ("cpufreq: ACPI: Fix max-frequency computation")
modified get_max_boost_ratio() to return the nominal_freq advertised
in the _CPC object. This was for the purposes of computing the maximum
frequency. The frequencies advertised in _CPC objects are in
MHz. However, cpufreq expects the frequency to be in KHz. Since the
nominal_freq returned by get_max_boost_ratio() was not in KHz but
instead in MHz,the cpuinfo_max_frequency that was computed using this
nominal_freq was incorrect and an invalid value which resulted in
cpufreq reporting the P0 frequency as the cpuinfo_max_freq.
Fix this by converting the nominal_freq to KHz before returning the
same from get_max_boost_ratio().
I think I had a revelation, I used this kernel param: shutdown=poweroff
And… I just had 2 successful shutdowns and startups. Not sure if it helps reboots too, haven’t experimented much, I’ll do some more shutdown and restarts later to see, but this is promising…
Maybe someone smarter than me can explain why this helps?
Thanks, I’ll give this a shot if problems persist.
Time back, I was having a hardware issue that happened on Linux but not on Windows. Someone told me back then, that Linux tends to be much stricter with everything working as it should than Windows. For me, it was a cable that wasn’t pushed all the way, so the contact was a bit wobbly. Being strict with that helps prevent data loss etc, which is good considering how common Linux is in critical systems, like major servers.
I did some digging and what seems to be the case is that GPT hallucinated this param and it doesn’t exist, lol. (yes i know, I was desperate ) It’s very funny though that the frequency of code 30 startups dropped significantly, because I didn’t try anything else except this (apparently nonexistent) param.
Now I get code 30 in like 1 out of 6 boots, before it was every single boot.
I’m out of options I think, I guess I’ll shoot asrock support an email, probably pointless but why not…
Of course, you are right, this is why I wanted to clarify in a separate post, and why I didn’t mark it as a solution either, but at the time it seemed to affect something so that’s why I mentioned it. Sorry about it.
) It’s very funny though that the frequency of code 30 startups dropped significantly, because I didn’t try anything else except this (apparently nonexistent) param.