Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

Elmario · 2026-01-29 04:21:33

Hello!
I yesterday received update 6.18.7. I usually have three Kernels installed, so in case one fails, I have other ones left to simply switch from Grub.
The Kernels are the default arch, Zen and the G14 Kernel specifically optimized for the Asus G14 notebooks.

Since the update my standard kernel (Zen) would not boot anymore,. Also switching to the arch kernel does not help. They both crash about halfway the boot process and the screen shows graphical glitches, like the contents being refreshed very slowly from top to bottom and such.
Both kernels are installed in version 6.18.7. I saw there was an amdgpu update in this version. So I see this as the most probable culprit.

So the last kernel that my notebook now is running with, is the G14 kernel, which still is the older version 6.18.6.
I am in fear, that if this kernel gets updated, too, this will make my system completely unuseable. (One could hope that the G14 devs would in theory recognize there's an issue with this kernel version on the G14 notebooks, and thus avoid this version, but who knows?)

So my question is:
What would be the right thing to do now, for preventing this worst case as good as possible?
Should I just add the G14 kernel to pacman's Ignore list, so it stays old? I always see this as a terrible workaround, as one might forget to remove the Ignore, having the package outdated forever.
And what would I do best about the default arch and the Zen kernel? There's the same issue: If I now downgrade them and add them to Ignore, how would I later remember removing them form Ignore, when they are (hopefully) ever working again?
And how would I even know they are working again, before even trying? I mean, all this Ignoring and later removing just for checking if it now is working again, is an annoying procedure.

Aren't there better solutions for coping with such issues?

And, additionally: Is there a way for automatically always having the previous kernel installed, to then be removed when the next kernel update comes? I remember such mechanics from other Linux distributions I have been using earlier, maybe there's a package on arch just doing this? (The lack of this feature as default is the reason why I am having multiple different kernels installed, as a weird workaround).

Thank you!

Last edited by Elmario (2026-01-29 05:23:20)

aurelijus · 2026-01-29 07:26:30

Hello! I have the same laptop and the same issue (probably)

If you're unable to boot, you can add the following kernel parameter `modprobe.blacklist=amdgpu`.

In my case, the problem apparently was `supergfxctl`. After removing this package I can boot normally.

Elmario · 2026-01-29 09:25:36

Hello and thank you!
This may well be, as once in the many times I tried booting the problematic kernel , I saw a message about supergfxctl and also AsusArmoury. But I am using a very specific config, with the dGPU permanantly disabled and my tools manually set to use the APU's iGPU. Thus I am dependent on the Asus tools
And wouldn't your workaround just disable all 3D and other GPU acceleration for the system? I am using the graphics intensely for different purposes form gaming to AI..
Btw: Which kernel are you normally using on this notebook? Does the G14 kernel (besides from being old enough to still work in this case) have any actual advantage for the Zephyrus G14? (I have the 2022 model I think..)

And thank you very much - it often is already relieving to know, that one isn't the only one suffering from a problem, and that probably there'll be a fix soon, when it effects many people.

Last edited by Elmario (2026-01-29 09:26:35)

aurelijus · 2026-01-29 10:09:58

I'm using the default Arch kernel, but then, I don't have any special requirements.

As for supergfxctl, it's only used to switch between Integrated/Hybrid modes. After removing it, I was able to boot with regular parameters (removed the modprobe.blacklist=amdgpu), and GPU acceleration is working normally.

Elmario · 2026-01-30 02:50:11

Thanks. I want to keep the notebook in pure Integrated mode, that#s why I need it. But in case even the last kernel stops working, removing ti may be the last resort to make it boot again. I still hope they will fix the issue, though. I guess I will have to block updates for the 14 kernel then, as there's no other solution.

loqs · 2026-01-30 03:23:20

Please post the journal for a boot with the issue preferably from the standard linux kernel. Have you considered bisecting between 6.18.6 and 6.18.7? Have you found any similar bug reports on https://gitlab.freedesktop.org/drm/amd/-/issues?

Elmario · 2026-01-30 15:10:20

Hello!

The log is there: https://paste.c-net.org/LivinLiege (It was too long for the forum).

I could not find this issue on gitlab, searching for: 6.18.7 or supergfx or 680m or boot crash.

What do you mean with 'bisecting'? Like compiling the kernel from gitlab in incremental steps from the older one to the new one? I fear I don't understand 3% of git for whats needed to doing so

loqs · 2026-01-30 16:54:23

Is the following new in 6.18.7?

Jan 30 15:43:49 work kernel: watchdog: BUG: soft lockup - CPU#8 stuck for 27s! [supergfxd:827]
Jan 30 15:43:49 work kernel: CPU#8 Utilization every 4000ms during lockup:
Jan 30 15:43:49 work kernel: 	#1:   1% system,	  0% softirq,	  0% hardirq,	  0% idle
Jan 30 15:43:49 work kernel: 	#2:   1% system,	  0% softirq,	  0% hardirq,	  0% idle
Jan 30 15:43:49 work kernel: 	#3:   1% system,	  0% softirq,	  0% hardirq,	  0% idle
Jan 30 15:43:49 work kernel: 	#4:   1% system,	  0% softirq,	  0% hardirq,	  0% idle
Jan 30 15:43:49 work kernel: 	#5:   1% system,	  0% softirq,	  0% hardirq,	  0% idle
Jan 30 15:43:49 work kernel: Modules linked in: wireguard libcurve25519 ip6_udp_tunnel udp_tunnel f2fs uhid at24 cmac ee1004 algif_hash algif_skcipher af_alg bnep cdc_mbim cdc_wdm snd_acp6x_pdm_dma snd_soc_dmic snd_soc_acp6x_mach snd_sof_amd_acp70 snd_sof_amd_acp63 snd_sof_amd_vangogh snd_sof_amd_rembrandt snd_sof_amd_renoir squashfs snd_sof_amd_acp intel_rapl_msr amd_atl snd_sof_pci intel_rapl_common loop snd_sof_xtensa_dsp snd_sof snd_sof_utils snd_pci_ps snd_soc_acpi_amd_match snd_amd_sdw_acpi soundwire_amd soundwire_generic_allocation kvm_amd soundwire_bus spd5118 hid_multitouch snd_hda_codec_alc269 snd_soc_sdca snd_hda_scodec_component kvm snd_hda_codec_realtek_lib snd_soc_core snd_hda_codec_generic snd_compress snd_hda_codec_atihdmi btusb irqbypass ac97_bus snd_hda_codec_hdmi polyval_clmulni btmtk snd_pcm_dmaengine ghash_clmulni_intel cdc_ncm btrtl iwlmvm snd_rpl_pci_acp6x snd_usb_audio snd_hda_intel aesni_intel btbcm cdc_ether snd_acp_pci btintel snd_usbmidi_lib snd_amd_acpi_mach rapl wmi_bmof sp5100_tco usbnet snd_hda_codec
Jan 30 15:43:49 work kernel:  snd_acp_legacy_common snd_ump pcspkr mii mac80211 i2c_piix4 snd_rawmidi bluetooth k10temp snd_hda_core ptp snd_pci_acp6x i2c_smbus snd_seq_device pps_core snd_intel_dspcfg libarc4 snd_intel_sdw_acpi mc snd_pci_acp5x snd_hwdep snd_rn_pci_acp3x snd_pcm snd_acp_config snd_soc_acpi ucsi_acpi snd_pci_acp3x snd_timer typec_ucsi snd soundcore typec iwlwifi roles amd_pmf ryzen_smu(OE) thunderbolt mousedev joydev amdtee i2c_hid_acpi i2c_hid ccp amd_sfh tee amd_pmc acpi_tad mac_hid cfg80211 iptable_nat nf_nat nf_conntrack ip_tables hid_sony dm_mod nf_defrag_ipv6 sg x_tables ff_memless uinput ntsync crypto_user pkcs8_key_parser nf_defrag_ipv4 nfnetlink zram 842_decompress 842_compress lz4hc_compress lz4_compress sdhci_pci sdhci_uhs2 sdhci cqhci mmc_core nvme nvme_core nvme_keyring nvme_auth hkdf vfat fat uas hid_asus usb_storage amdgpu amdxcp i2c_algo_bit asus_nb_wmi drm_ttm_helper asus_wmi ttm sparse_keymap drm_exec platform_profile drm_panel_backlight_quirks rfkill gpu_sched drm_suballoc_helper video wmi drm_buddy
Jan 30 15:43:49 work kernel:  drm_display_helper cec
Jan 30 15:43:49 work kernel: CPU: 8 UID: 0 PID: 827 Comm: supergfxd Tainted: G     U     OE       6.18.7-arch1-1 #1 PREEMPT(full)  696da3eef26f0e218c3f35c7e36627e4a770bb62
Jan 30 15:43:49 work kernel: Tainted: [U]=USER, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Jan 30 15:43:49 work kernel: Hardware name: ASUSTeK COMPUTER INC. ROG Zephyrus G14 GA402RK/GA402RK, BIOS GA402RK.319 06/06/2023
Jan 30 15:43:49 work kernel: RIP: 0010:amdgpu_device_rreg.part.0+0x38/0xf0 [amdgpu]
Jan 30 15:43:49 work kernel: Code: 00 00 00 53 48 89 fb 48 83 ec 08 48 3b 97 e8 08 00 00 73 18 a8 02 75 09 f6 87 f0 58 05 00 10 75 78 48 03 93 f0 08 00 00 8b 0a <eb> 11 48 8b 87 38 09 00 00 48 89 d6 e8 77 aa fc cd 89 c1 66 90 48
Jan 30 15:43:49 work kernel: RSP: 0018:ffffd4314f68bb80 EFLAGS: 00000286
Jan 30 15:43:49 work kernel: RAX: 0000000000000000 RBX: ffff8f0851100000 RCX: 00000000ffffffff

On bisection if it helps I can provide you with a step by step guide or build the kernel for each step for you. With the latter you would still need to test it yourself and report back.

topcat01 · 2026-01-30 17:14:52

Regarding the question of a safe upgrade method, I often have both linux and linux-lts installed. When upgrading, I IgnorePkg linux-lts. If linux runs fine after the upgrade, then eventually I will explicitly -Su the lts kernel (without -y). This way I have one working kernel.

Elmario · 2026-01-31 16:30:05

loqs wrote:

Is the following new in 6.18.7?

Yes, this error did not occur before. It most certainly is THE error making the system crash. The screen distortion while booting starts with this message and the systems reboots automatically a few seconds after this.

loqs wrote:

On bisection if it helps I can provide you with a step by step guide or build the kernel for each step for you. With the latter you would still need to test it yourself and report back.

This would be very nice of you. At least I can try helping to isolate the issue. And the realtime messages on screen mentioned supergfx as aurelijus already has had, too, I think it's rather probable that the issue stems from the recent amdgpu changes. So the process could probably be shortened by omitting just this amdgpu changes, I assume.

topcat01 wrote:

Regarding the question of a safe upgrade method, I often have both linux and linux-lts installed. When upgrading, I IgnorePkg linux-lts. If linux runs fine after the upgrade, then eventually I will explicitly -Su the lts kernel (without -y). This way I have one working kernel.

Thanks, yes. I have installed linux-lts now, too in addition to adding linux-g14 to pacman's Ignore list until the issue is fixed in mainline. (I guess with 'If linux runs fine after the upgrade' you meant the 'normal' kernel update that comes next after the next later lts kernel to the one already installed is running fine?)

Last edited by Elmario (2026-01-31 16:50:13)

loqs · 2026-01-31 20:19:33

@Elmario have you checked if the issue is still present in linux 6.18.8?

topcat01 · 2026-01-31 21:28:08

@Elmario Yes, I meant the "linux" kernel. This is just to avoid having to use a USB key to recover from any major failure on upgrade.

Elmario · 2026-02-03 07:05:47

loqs wrote:

@Elmario have you checked if the issue is still present in linux 6.18.8?

Hello! I installed linux-cachy 6.18.8, as it's the only premade 6.18.8 kernel I found. And it still has the same problem.

Also I could not find any post regarding this issue, yet.
It's so sad, that's the third time hardware became unusable for me due to kernel updates And posting bugs to the kernel devs is utterly impossible without being an expert. I tried mutiple times through the years and after switching from on tracker to another, none board to another and whatever, after wasting a lot of hours it always ended in nothingness.

topcat01 wrote:

@Elmario Yes, I meant the "linux" kernel. This is just to avoid having to use a USB key to recover from any major failure on upgrade.

OK, it's clear now, thank you!

Last edited by Elmario (2026-02-03 07:08:06)

Elmario · 2026-02-03 11:06:18

So, I found that it's enough to disable the supergfxd service.
After that all kernels newer than 6.18.6 boot fine. It#s even working to manually start the service after the GUI has loaded then.
so I worked around the problem by modifying the unit file of the service to start later:

ladmin@work:~$cat /etc/systemd/system/graphical.target.wants/supergfxd.service
[Unit]
Description=SUPERGFX
StartLimitInterval=200
StartLimitBurst=2
#Before=graphical.target
#Before=multi-user.target
#Before=display-manager.service
#Before=nvidia-powerd.service
After=display-manager.service
After=systemd-user-sessions.service

[Service]
Environment=IS_SERVICE=1
Environment=RUST_LOG=debug
ExecStart=/usr/bin/supergfxd
Restart=on-failure
Restart=always
RestartSec=1
Type=dbus
BusName=org.supergfxctl.Daemon
SELinuxContext=system_u:system_r:unconfined_t:s0
#SELinuxContext=system_u:object_r:modules_object_t:s0

[Install]
#WantedBy=getty.target
WantedBy=graphical.target
ladmin@work:~$

I'm not sure if this is more of a workaround or an actual 'solution' as the depths of all those propietary Asus shenanigans are very specific of course .. and so I don't know where it should be 'fixed' at .. the kernel or at the asus-linux project making supergfxctl.

Last edited by Elmario (2026-02-03 11:42:07)

VanFinale · 2026-02-04 00:07:18

I'm having the same issue my system will not boot with supergfx enabled. Even with the fix/workaround posted Elmario posted. Even after I'm booted and logged in if I start supergfx my computer becomes unresponsive. Have to force a shutdown. Using a GA402RK with an AMDGPU.

tomaszc · 2026-02-04 00:21:15

I am experiencing the exact same symptoms as VanFinale on the same laptop model. The issue occurs on the following kernels:
- linux-g14 6.18.7.arch1-1.2
- linux-zen 6.18.7.zen1-1

Additionally, if I manually start the supergfxctl service after logging in, the system completely freezes. The only way to recover is a hard reboot via SysRq, as the supergfxctl process becomes unresponsive and cannot be killed.

I have tested both the version from the g14 repository and the one built from AUR:
- g14/supergfxctl 5.2.7-2
- aur/supergfxctl 5.2.7-2

Elmario · 2026-02-04 08:51:32

Hello!

As I am intensely using GPU hardware acceleration in many ways all the time (video de/encoding, CGI, gaming, AI ..) I always had stability issues with the APU, while the dGPU btw. ran fine. But I want the dGPU permanently disabled for saving power and keeping the notebook cool and quiet (=increased hardware lifetime), and the APU's performance simply is enough, usually..
Thus my kernel command line is modified, which was required for me before kernel 6.18.7+ already, to make the system stable. Maybe the combination of these parameters with now the 'workaround' I posted above in addition, is why it's working for me and not for you since kernel 6.18.7.

That's my kernel command line (using cachy kernel currently, adapt it to the default kernel as needed, it's working like this with the current stable Arch kernel 6.18.7, too; I tried!):

linux	/boot/vmlinuz-linux-cachyos root=UUID=b0be043f-a4d2-4942-a774-92e16ecf5193 rw zswap.enabled=1 rootfstype=ext4 loglevel=3 amdgpu.audio=0 amd.ppfeaturemask=0xfff7ffff usbcore.autosuspend=-1 btusb.enable_autosuspend=0 amd_pstate=passive resume=UUID=992be7b9-d215-4446-aecf-90e3c441b73b amdgpu.noretry=0

You should not use my resume parameter of course, as it's just the specific UUID of my swap partition for making hibernation work, same for the root partition's UUID.
AFAIR it's just the 'amd.ppfeaturemask=0xfff7ffff ', 'amd_pstate=passive' and 'amdgpu.noretry=0' parameters that I really added for APU stability, while the others have different reasons.

(Btw: In case you have trouble or annoyance fiddling around with Grub: I am using the GRUB Customizer GUI since I needed all these changes, which makes it easy to add or modify entries!)

Wish you luck, please report if it's working for you!

PS: Yes, it's the 'infamous' Asus ROG Zephyrus G14 GA402RK, with soldered 8GByte RAM and an insane 64GByte SO-DIMM I added, which btw. despite AMD's claims the APU could only use 64GByte overall, is working with full overall 72GByte for me, as we are talking about stability!)

Last edited by Elmario (2026-02-04 12:45:20)

tomaszc · 2026-02-04 17:16:55

From what I found on the 'Linux on Asus ROG' Discord:
https://discord.com/channels/7251259347 … 3223338229
And in the Asusctl installation guide on ArchLinux:
https://asus-linux.org/guides/arch-guide/

WARNING supergfxctl is being phased out and its use is unadvised. During this transitioning period where an alternative is unavailable, unless you require vfio for virtual machines or have problems turning off your dGPU don't install it!

The supergfxctl program is being phased out and its use is not recommended.
Instead, the graphics card can be controlled using "asusctl armoury', but this requires the linux-g14 kernel or 6.19 which will be released in a few days.
In the future, control will be possible through rog-control-center.

Elmario · 2026-02-04 18:05:02

Thanks for the info! The asus-linux project is rather obscure to me, especially because of the reliance on something as terrible, confusing and overloaded as discord, which is the most unsuitable way of trying to provide support I have ever seen..

And: Argh! Rog Conrol Center does not run on X11 anymore, because they think no one is allowed to use XFCE. Linux devs are becoming too patronizing

I hope it will work using asusctl, though. I did not see any option for switching the graphics, yet:

sudo asusctl
[sudo] Passwort für ladmin: 
One of the following subcommands must be present:
    help
    aura
    leds
    profile
    fan-curve
    anime
    slash
    scsi
    armoury
    backlight
    battery
    info

Is the asusctl GPU-switching still in development?

Edit:
Sorry, now I got it - you said armoury. I never even botherd any of this genuine Asus stuff .. never even used Windows on this notebook. So I don't know what armoury is and how it works, but I will try to find out

guess it's:

sudo asusctl armoury set dgpu_disable

with an added 0 or 1 for switching the dGPU on and off.
Siwtching the mux does not seem to work:

sudo asusctl armoury set gpu_mux_mode 0
Multiple asusd interfaces devices found

Error: org.freedesktop.DBus.Error.Failed: Failed with std::io error: No such device (os error 19)

Software version: 6.3.2
  Product family: ROG Zephyrus G14
      Board name: GA402RK

Supported interfaces:

[
    "xyz.ljones.Anime",
    "xyz.ljones.AsusArmoury",
    "xyz.ljones.AsusArmoury",
    "xyz.ljones.AsusArmoury",
    "xyz.ljones.AsusArmoury",
    "xyz.ljones.Platform",
    "xyz.ljones.FanCurves",
    "xyz.ljones.Aura",
    "xyz.ljones.AsusArmoury",
    "xyz.ljones.AsusArmoury",
    "xyz.ljones.AsusArmoury",
]

Supported properties on Platform:

[
    ChargeControlEndThreshold,
    ThrottlePolicy,
]

Btw: I just noticed the dGPU switching seems to be working with 'Linux work 6.18.8-1-cachyos #1 SMP PREEMPT_DYNAMIC Fri, 30 Jan 2026 16:11:37 +0000 x86_64 GNU/Linux' already.

Correction: Opposed to last time I tried, rog-control-center actually builds currently using the method shown on Github. Sadly, as it's 'not supported' this will remain a rare occassion, I assume.
The GUI does not show any option I cared about, anyway.. The section under 'armoury' is just empty. If only I knew how to manually set the mux setting in '/etc/asusd/asusd.ron' .. the dGPU setting is given there as a default, luckily.

Edit:
OK, found the MUX setting's name in the sources:

(
    charge_control_end_threshold: 65,
    base_charge_control_end_threshold: 0,
    disable_nvidia_powerd_on_battery: true,
    ac_command: "",
    bat_command: "",
    platform_profile_linked_epp: true,
    platform_profile_on_battery: Quiet,
    change_platform_profile_on_battery: true,
    platform_profile_on_ac: Quiet,
    change_platform_profile_on_ac: true,
    profile_quiet_epp: Power,
    profile_balanced_epp: Power,
    profile_custom_epp: Performance,
    profile_performance_epp: Power,
    ac_profile_tunings: {
        Performance: (
            enabled: false,
            group: {},
        ),
        Quiet: (
            enabled: false,
            group: {},
        ),
        LowPower: (
            enabled: true,
            group: {
                PptApuSppt: 35,
                PptPlatformSppt: 30,
            },
        ),
        Balanced: (
            enabled: false,
            group: {},
        ),
    },
    dc_profile_tunings: {
        Balanced: (
            enabled: false,
            group: {},
        ),
        Quiet: (
            enabled: false,
            group: {},
        ),
    },
    armoury_settings: {
        PanelOverdrive: 0,
        DgpuDisable: 1,
        GpuMuxMode: 0,
    },
)

When uninstalling supergfxctl it claims that asusctl optionally required supergfxctl, but the switching is working anyway.

Last edited by Elmario (2026-02-04 19:47:05)

rebelCoder · 2026-02-08 17:39:42

Seeking Stability Benchmarks: GA402RK (2022 G14) – What is your "Golden" Linux Config?

I have been struggling with my ROG Zephyrus G14 GA402RK for many months now. The amount of time I have wasted trying to get this machine to just function while I have actual work to do is absolutely insane. I am a developer and I need both GPUs functioning reliably — when it works, it’s great, but it rarely stays working.

I’ve spent a combined month of my life messing with kernels, boot parameters, and BIOS versions (312–319) across countless distros. The configuration below has been the most stable so far, but I still suffer from random freezes. I have seen this same behavior on CachyOS (LTS, Regular, and G14 kernels), but regular Arch LTS seems to be the least prone to immediate total failure.

As of today, it finally looks semi-stable (update: froze 4 times while crafting this message) after a full day of non-stop crashes and random attempts at fixes. I want to see exactly what other owners are running for long-term stability.

Please share your configuration using the template below:

BIOS Version:
Kernel Version:
Boot Parameters:
External Monitor: (Port / Input / Specs)
BIOS Settings: (APM & Armoury Crate status)
supergfxctl: (Enabled / Disabled / Uninstalled)
Custom Patches: (asus-linux, udev, etc.)
Desktop Stability: (Sleep / Wake reliability)
Battery Stability: (Freezes on disconnect or cold boot?)
Additional Notes:

My Current Setup (Testing Phase):

BIOS Version: 318
Kernel Version: 6.12.69-1-lts (Arch Official), but the same behaiviour on Cachy LTS/Stable and g14
Boot Parameters: amd_pstate=guided acpi_osi="Windows 2020" processor.max_cstate=3 idle=nomwait (still freezes)
External Monitor: Left Type-C (DP Alt), 2K @ 180Hz, VRR On
BIOS Settings: Advanced Power Management & Armoury Crate Support both Disabled
supergfxctl: Uninstalled (but the same issues with it enabled in Hybrid and AmdMuxDgpu)
Custom Patches: None currently
Desktop Stability: Most stable so far, but still random freezes on AC
Battery Stability: Historically poor. Disconnecting power/peripherals freezes the machine after a few minutes, and starting cold off battery power causes the same behavior.

Additional Notes

Critical Errors in Current Boot Log (Session 0):

ACPI Symbol Failure:
Could not resolve symbol [_SB.PCI0.GPP0...VGA._STA.GC00], AE_NOT_FOUND.
The BIOS is missing the code required to check the power status of the discrete GPU.
USB Port 3 Timeout:
device not accepting address 9, error -71 and unable to enumerate.
A hardware handshake failure on Port 3 is causing the USB bus to reset repeatedly.
GPU Firmware Mismatch:
amdgpu: SMU driver if version not matched (0x0f vs 0x13).
The kernel driver version (15) does not match the GPU's loaded power management firmware (19).
Input Driver Error:
asus 0003:0B05:19B6.0003: probe with driver asus failed with error -12.
The ASUS N-Key (keyboard / hotkeys) driver failed to initialize its memory.

Exact Reasons for Previous Freezes / Crashes:

Memory Violation (Session -7):
BUG: kernel NULL pointer dereference, address: 0000000000000000.
A driver attempted to write to address zero, which is a fatal operation.
Supervisor Write Access Violation:
#PF: supervisor write access in kernel mode.
A driver attempted to modify protected kernel memory.
Page Fault:
#PF: error_code(0x0002) - not-present page.
The CPU accessed memory that did not exist or had been swapped out.
Bluetooth Logic Loop (Session -2):
Bluetooth: hci0: ACL packet for unknown connection handle 3837.
The Bluetooth driver entered an infinite loop processing stale data.
Journal Rotation Error:
systemd-journald: Time jumped backwards, rotating.
Likely RTC or clock failure during a crash, causing log corruption.

General Observations:

Freezes can occur before the OS boots (GRUB, Limine, systemd-boot).
I must select a kernel immediately to avoid a hang.
Currently investigating a reported Mesa / Chromium Engine / Electron bug causing system-wide freezes on AMD GPU systems.

Last edited by rebelCoder (2026-02-08 17:46:44)

tomaszc · 2026-02-08 18:37:49

Your description sounds like a problem unrelated to Linux itself to me. Especially the part about freezing before the OS boots.

I've used various configurations, mainly BIOS 505.U4 (the Asus BIOS release with USB4 support) and Linux-ZEN.
But currently, I'm using Linux-G14 (due to the issue described in this thread) and BIOS 3.19 (because I don't want USB4 on the left port).

I don't use any kernel flags related to the graphics card.

In both configurations, I haven't experienced the issue you're having. Sure, the system can freeze when switching supergfxctl settings, or even currently asusctl, but if I don't touch anything, it doesn't freeze.
That said, I admit I've mostly used integrated graphics-only mode so far, with the dedicated GPU disabled. Currently, I'm using dynamic switching, but that doesn't freeze the system either.

I think you could try resetting the BIOS to factory defaults (which you might have already done) + the so-called EC Reset:
https://www.asus.com/support/faq/1050239/

rebelCoder · 2026-02-08 18:55:15

If you are mostly/very stable, it would be very helpful to see your configs in full, if you don't mind, so we can collect real, detailed examples:

BIOS Version: 319
Kernel Version: 6.18 g14
Boot Parameters: (any at all?)
External Monitor: (Port / Input / Specs) (any at all?)
BIOS Settings: (APM & Armoury Crate status) (anything here?)
supergfxctl: (Enabled / Disabled / Uninstalled) (you are suing it with g14 kernel it seems in Hybrid)
Custom Patches: (asus-linux, udev, etc.) (anything?)
Desktop Stability: (Sleep / Wake reliability) (you said that in "desktop" mode it is solid)
Battery Stability: (Freezes on disconnect or cold boot?) (what about this?)
Additional Notes:

About

tomaszc wrote:

I think you could try resetting the BIOS to factory defaults (which you might have already done) + the so-called EC Reset:
https://www.asus.com/support/faq/1050239/

Yep. Tried it all. Did this on every Bios upgrade.

Last edited by rebelCoder (2026-02-08 18:59:43)

tomaszc · 2026-02-08 20:03:04

I've used various configurations, so I'll list what worked for me for each item.

BIOS Version: 319, 505.U4 (I also had earlier U4 versions and they worked fine)

Kernel Version: 6.18.7-arch1-1.2-g14, previously linux-zen up to version 6.18.6

Boot Parameters: No additional parameters added, but I see that linux-g14 in

cat /proc/cmdline

automatically adds:

ibt=off pm_debug_messages amd_pmc.dyndbg="+p" acpi.dyndbg="file drivers/acpi/x86/s2idle.c +p"

External Monitor: Full HD 60Hz (tested on: left and right USB-C > docking station > monitor, HDMI > monitor)

BIOS Settings: (APM & Armoury Crate status):
- ErP: Disabled
- ArmouryCrate Control Interface Support > Enabled

supergfxctl: (Enabled / Disabled / Uninstalled): Currently uninstalled with linux-g14, until recently installed with linux-zen up to 6.18.6

Custom Patches: (asus-linux, udev, etc.): No, but the linux-g14 kernel itself includes asus-linux patches

Desktop Stability: (Sleep / Wake reliability): I don't use sleep mode

Battery Stability: (Freezes on disconnect or cold boot?): Mostly plugged in (dedicated charger, PD, or both at once), but sometimes runs on battery too and I haven't noticed any issues

Additional Notes:
(none)

I still think your issue isn't related to the operating system, unless it concerns sleep/wake cycles.

Does the freeze before the bootloader happen after sleep and wake for you?
Have you temporarily checked if the same problem occurs on Windows?

rebelCoder · 2026-02-08 20:45:31

Thanks for your response, as building stats of what people run should, in theory, let us reproduce the software stack and get it working good.

BIOS Version: 319, 505.U4 (I also had earlier U4 versions and they worked fine)

Do you remember if 318 or any previous version had issues in your tests?

Boot Parameters: No additional parameters added, but I see that linux-g14 in
ibt=off pm_debug_messages amd_pmc.dyndbg="+p" acpi.dyndbg="file drivers/acpi/x86/s2idle.c +p"

Yes, those are just debug flags, not params that change/modify anything

BIOS Settings: (APM & Armoury Crate status):
- ErP: Disabled
- ArmouryCrate Control Interface Support > Enabled

Interesting, my research indicated that ACT has to be disabled, as asusctl controls all the G14 stuff separately, and there might be a conflict. asusctl works fine with it disabled for me.

Custom Patches: (asus-linux, udev, etc.): No, but the linux-g14 kernel itself includes asus-linux patches

Desktop Stability: (Sleep / Wake reliability): I don't use sleep mode

You never suspend/hibernate your laptop? Interesting?

Battery Stability: (Freezes on disconnect or cold boot?): Mostly plugged in (dedicated charger, PD, or both at once), but sometimes runs on battery too and I haven't noticed any issues

Here, I understand that you can have the G14 fully plugged in, work on it, then just unplug all the power and work off the battery, and there are no freezes/crashes, and you can keep switching between AC/battery just fine. If this is the right interpretation, this rarely worked for me. Interesting. I'm still testing the current setup. Looks promising.

I still think your issue isn't related to the operating system, unless it concerns sleep/wake cycles.

This one is odd: so the bootloader (GRUB, Lemine, or systemd) loads, and it might freeze before I select the kernel. But if I manage to press E to go into editing mode to select one and it starts booting, it does not freeze at all until it gets into the OS (where it might freeze later). This is not a problem as long as my session does not freeze and has a working sleep/wake cycle.

Does the freeze before the bootloader happen after sleep and wake for you?

Only on a fresh boot, as suspend mode I use does not do a deep sleep.

Have you temporarily checked if the same problem occurs on Windows?

I have not had Windows on it since day one. If I exhaust all the options that I am testing now and what others like you report here, I might test Windows to see if it is indeed a hardware issue (I doubt it)

In theory, if one of us reports a full set of configs (template I shared above) and confirms that sleep/wake always works and freezes are not there, we should be able to replicate it. What puzzles me, you are saying you have not added any additional params and use the default G14 kernel params. I have booted into it now. And there is no chance I will not get a freeze if I do not add the 4 params I shared in my template/report. Very odd. Maybe it has something to do with the RAM we have installed and the different monitors we use. I hope others can report their templates and share stability.

Last edited by rebelCoder (2026-02-08 20:46:11)

tomaszc · 2026-02-08 23:54:17

I also don't use Windows – I removed it right after buying the laptop. But I have it on an external drive because I needed it for things like PD firmware updates, which is one of the steps after a USB4-supporting BIOS update. Maybe you could do the same to test on the officially supported OS and drivers? Windows doesn't install on external drives by default, but there's a workaround.

I have a feeling that pursuing the path we're on raises more questions than answers. Everything could depend on BIOS version, BIOS settings, kernel version, boot parameters, or even additional /etc config. That creates hundreds of possible combinations and makes it easy to miss something.

Therefore, I propose a different approach:

1. Set asusctl like this:

asusctl armoury list
Multiple asusd interfaces devices found
boot_sound:
 current: [(0),1]

charge_mode:
 current: [0,1,2]

dgpu_disable:
 current: [(0),1]

gpu_mux_mode:
 current: [0,(1)]

panel_overdrive:
 current: [(0),1]

ppt_apu_sppt:
 current: 15..[80]..80
 default: 80

ppt_platform_sppt:
 current: 30..[115]..115
 default: 115

This enables hybrid mode for me, and it seems important because when I set it to integrated graphics only, the setting survived BIOS reset.

2. Reset BIOS to defaults (F9)
3. Boot from LiveCD CachyOS Handheld from the first GRUB entry, without adding extra kernel parameters. (I chose it because: Arch-based, has graphics mode out of the box, recommended by asus-linux: https://asus-linux.org/guides/arch-guide/)

What happens for me:
- System boots
- Hybrid mode active, lspci shows both GPUs:

lspci | grep Radeon
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 23 [Radeon RX 6650 XT / 6700S / 6800S] (rev c0)
07:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt [Radeon 680M] (rev c7)
07:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Radeon High Definition Audio Controller

- Can use either GPU with DRI_PRIME variable:

sudo su -
pacman -Sy mesa-utils

# From user:
[liveuser@CachyOS ~]$ DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
OpenGL renderer string: AMD Radeon RX 6800S (radeonsi, navi23, LLVM 21.1.6, DRM 3.64, 6.18.6-1-cachyos-deckify)
[liveuser@CachyOS ~]$ DRI_PRIME=0 glxinfo | grep "OpenGL renderer"
OpenGL renderer string: AMD Radeon 680M (radeonsi, rembrandt, LLVM 21.1.6, DRM 3.64, 6.18.6-1-cachyos-deckify)

- Sleep/wake works, and after wake the system seems to function normally

Not sure if you'll like the idea, but maybe you could try something like this?

Earlier I said I don't use sleep because I really don't. Sure, I've probably used it occasionally, but that was many kernel versions ago, maybe even on different BIOS, so it doesn't add much insight.
Now I tested sleep on my main system and CachyOS – both work fine. Assuming success = sleep, wake, and functional system afterward.

Arch Linux

#1 2026-01-29 04:21:33

Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#2 2026-01-29 07:26:30

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#3 2026-01-29 09:25:36

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#4 2026-01-29 10:09:58

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#5 2026-01-30 02:50:11

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#6 2026-01-30 03:23:20

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#7 2026-01-30 15:10:20

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#8 2026-01-30 16:54:23

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#9 2026-01-30 17:14:52

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#10 2026-01-31 16:30:05

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#11 2026-01-31 20:19:33

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#12 2026-01-31 21:28:08

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#13 2026-02-03 07:05:47

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#14 2026-02-03 11:06:18

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#15 2026-02-04 00:07:18

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#16 2026-02-04 00:21:15

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#17 2026-02-04 08:51:32

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#18 2026-02-04 17:16:55

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#19 2026-02-04 18:05:02

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#20 2026-02-08 17:39:42

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#21 2026-02-08 18:37:49

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#22 2026-02-08 18:55:15

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#23 2026-02-08 20:03:04

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#24 2026-02-08 20:45:31

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

#25 2026-02-08 23:54:17

Re: Crash on boot with Asus G14 (amdgpu) since Kernel to 6.18.7

Board footer