[Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

evorster · 2025-09-07 13:59:21

Firstly, I am sure it shuts down:
Fans stop, keyboard lights go out, apart from the power button light. Hitting the power button powers up the laptop again.

In Windows, I can run this laptop as hard as I please in Hybrid mode, and it does not shut down unexpectedly.
This is true for Windows, Quiet, Performance and Turbo modes selected in Armoury Crate.
I see package power draws of up to 160W, all cores maxed and both GPU maxed as well, and the thing is completely stable. So, not temperature / hardware related at all.

It shuts down in Hybrid mode on my long-running Arch install, and with a fresh bare CachyOS install. Kernels do not make a whit of difference, with exactly the same behaviour on LTS kernel, G14 kernel and CachyOS kernel.

In AsusMuxDgpu mode it is completely stable, and does not shut down under load, no matter what I throw at it.

I am not sure when exactly it started doing this, as I work rotations on a ship.
When travelling, and on the ship, I usually use Hybrid mode to save a bit of power, but when I am home and have an external monitor plugged in I run it in AsusMuxDgpu mode as the external monitor does not wake up properly from sleep in Hybrid mode when the refresh rates are higher than 30Hz. Hopefully that is a completely different issue.
The last time it ran on Hybrid mode and did not shut down was around 26 July 2025. I then used AsusMuxDgpu mode exclusively until 2 September 2025, and when switching to Hybrid mode it shut down unexpectedly for the first time.

The journal has been completely normal for these events, with the exception that it stops abruptly, with no indication of an error anywhere.
So far I have tried countless combinations of ASPM and ACPI options, as well as CPU governors. All make no difference to the symptoms.

Chatting to the Linux Asus guys on discord has been fruitless as well, apart from this one thing;
nvidia-powerd.service gives this one error message:

Sep 07 14:30:56 Scar nvidia-powerd[1122]: ERROR! Client (presumably SBIOS) has requested to disable Dynamic Boost DC controller

I see that asusctl is able to drive the nv boost, which I am assuming is the same thing.

So, I am asking the experts in here...
What are my next troubleshooting steps?

Unfortunately I am behind a very slow and unreliable internet connection while I am on the ship. so I cannot just rewind my install to two months ago and see if the issue is caused by a software update.
Some tips on getting more fine-grained logging might be useful.

      /\          evert@Evert
     /  \         -----------
    /    \        OS: Arch Linux x86_64
   /      \       Host: ROG Strix G733PYV_G733PYV (1.0)
  /   ,,   \      Kernel: Linux 6.16.5-2-cachyos
 /   |  |   \     Uptime: 1 min
/_-''    ''-_\    Packages: 1714 (pacman), 6 (flatpak)
                  Shell: fish 4.0.2
                  Display (NE173QHM-NZ2): 2560x1440 @ 1.5x in 17", 240 Hz [Built-in] *
                  Display (DELL U3014): 2560x1600 in 30", 60 Hz [External]
                  DE: KDE Plasma 6.4.4
                  WM: KWin (Wayland)
                  WM Theme: Breeze
                  Theme: Breeze (Light) [Qt], Breeze [GTK2/3]
                  Icons: breeze [Qt], breeze [GTK2/3/4]
                  Font: Noto Sans (10pt) [Qt], Noto Sans (10pt) [GTK2/3/4]
                  Cursor: breeze (24px)
                  Terminal: konsole 25.8.0
                  Terminal Font: Hack (12pt)
                  CPU: AMD Ryzen 9 7945HX3D (32) @ 5.46 GHz
                  GPU 1: AMD Radeon 610M [Integrated]
                  GPU 2: NVIDIA GeForce RTX 4090 Laptop GPU [Discrete]
                  Memory: 4.45 GiB / 62.00 GiB (7%)
                  Swap: 0 B / 100.00 GiB (0%)
                  Disk (/): 107.81 GiB / 150.00 GiB (72%) - btrfs
                  Disk (/home): 2.69 TiB / 3.40 TiB (79%) - btrfs
                  Disk (/home/evert/Videos): 2.59 TiB / 3.39 TiB (76%) - btrfs
                  Local IP (wlp4s0): 192.168.111.53/24
                  Battery (GA50358): 100% [AC Connected]
                  Locale: en_GB.UTF-8

Last edited by evorster (2025-09-18 08:19:32)

mwohah · 2025-09-07 20:07:39

This post spoke to me because I'm experiencing a rather similar issue I also posted about here recently. My journey is still ongoing but you may be able to gather some things to try and help debug from my and Seth's posts there.

Is it correct that the device also has an AMD 7000 series CPU and a MediaTek Wi-Fi controller? Since so far my problems seem to point to something Wi-Fi-related.

It gets stranger because my installation is about a year old (not recent) and didn't haven any problems previously; around end of July is also around the time I had no issues and it started a few weeks ago, coincidentally (or not).

evorster · 2025-09-08 03:34:45

CPU: AMD Ryzen 9 7945HX3D (32) @ 5.46 GHz

I am going through the troubleshooting you and Seth did, and while it seems awfully similar, it is just different enough for me to not try things willy-nilly.

I did make a hardware change between when it worked and when it started shutting down in Hybrid mode.
I swapped out my nvme drives, a Crucial 4Tb and a Lexar 4Tb for two Samsung 990 Pro 4Tb.

To trigger this shutdown, I just run s-tui and stress test the CPU, and the system shuts down in a few seconds in Hybrid mode, and runs indefinitely in AsusMuxDgpu mode.

Last edited by evorster (2025-09-09 18:57:39)

evorster · 2025-09-08 09:54:31

One interesting thing... The two main reasons for swapping the nvme for the Samsung drives were that the Samsung drives support better idle power states. However, they trigger a kernel quirk:

nvme 0000:02:00.0: platform quirk: setting simple suspend
nvme 0000:08:00.0: platform quirk: setting simple suspend

Could it be that this simple fact is causing the nvidia drivers to disable nvboost?
Is it even remotely possible that this could be the reason that my system has started misbehaving on Hybrid mode?

If that is the case, this would point to a BIOS bug, one which is ignored in Windows, maybe?
Makes me wonder if I can work around this by specifying that my OS is some version of Windows on the kernel parameters...

How would I be able to check if Windows is not also being annoyed by these drives in this system?

Fortunately for me, I have the two drives that were swapped out with me, so I could, in theory, swap them back in. But I would much rather have the more performant and very much more expensive Samsung drives working...

evorster · 2025-09-08 13:54:27

Where do I find the acpi _OSI version strings currently supported by the linux kernel? This laptop came with Windows 11, and I am thinking that maybe if the BIOS thinks this is a specific version of Windows running it might not hobble the machine...

seth · 2025-09-09 08:24:12

acpi_osi=! acpi_osi="Windows 2022"

https://learn.microsoft.com/en-us/windo … inacpi-osi

Edits:

         :++===++==================-       :++-           OS: CachyOS x86_64

https://bbs.archlinux.org/misc.php?action=rules

         .====++==============++++++++++*-                CPU: AMD Ryzen 9 7945HX3D (32) @ 5.46 GHz

https://wiki.archlinux.org/title/Ryzen#Troubleshooting

I see package power draws of up to 160W, all cores maxed and both GPU maxed as well, and the thing is completely stable. So, not temperature / hardware related at all.

Did you track temperatures on linux as well?

Also sanity check: 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

I swapped out my nvme drives, a Crucial 4Tb and a Lexar 4Tb for two Samsung 990 Pro 4Tb.

Do you still have the old nvme?

To trigger this shutdown, I just run s-tui and stress test the CPU, and the system shuts down in a few seconds in Hybrid mode, and runs indefinitely in AsusMuxDgpu mode.

AsusMuxDgpu means you're not using the APU but graphics are handled by the GPU?
Most likely PBO, can you adjust the curve optimizer?

Last edited by seth (2025-09-09 08:31:59)

evorster · 2025-09-09 13:59:05

Thanks for the reply!

I tried with: acpi_osi=! acpi_osi="Windows 2022", but the system would just hang after waking up the two Samsung nvme.
So, I am back to booting with just a kernel parameter to supply an EDID for my external monitor, and nothing else.

Windows itself does not have a problem with the two nvme drives, and runs stably. (I only keep the Windows partition around for testing and firmware installs, not for any actual use, but I have stress tested the components in Windows, and no shutdown occurred in any mode, and under any load)

This is indeed an Arch Linux install, I just use the CachyOS kernel and packages as available, as they are specifically compiled for my CPU architecture.
This issue happens on the g14 kernel by Asus as well, and on the Arch LTS kernel.

I still have the old nvme, and swapped them in for a test.
Unfortunately, the same issue popped up, ie: in Hybrid mode the laptop just shut down under slight load. So, I swapped the Samsung drives back in.

For the Ryzen optimizations...
As this is a laptop, the BIOS is very basic. So, no curve optimizer, and I have all the overclocking switches disabled in the BIOS, for anything that it does have.
Enabled is advanced power management, and Armory controls. Disabling these makes no difference to the issue.

The BIOS does not allow for voltages for anything to be set, no timings for dram, nothing.
At most I can disable some peripherals, like the USB ports, the on-board camera, wifi/bluetooth and the network adapter.

Also, it does not seem to matter if the laptop is in performance or powersave mode, or anywhere in between.
The shutdown occurs in Hybrid mode under moderate to high loads, and never occurs in AsusMuxDgpu mode.
This leads me to think that it is not related to C states of the CPU.

Asus Gpu modes are as follows:
Hybrid : iGPU (AMD in this case) handles screen output through the MUX to the laptop panel, and light tasks. For heavy GPU tasks, the nVidia dGPU kicks in and takes over for that task.
AsusMuxDgpu: the iGPU is on, but completely idle. It does not handle any display or application. The nVidia GPU drives all monitors and does all tasks.
There is a third mode, where the dGPU is completely disabled, and never takes over any tasks, but in this mode the external monitor does not work, and so I have never used it.

Windows and Linux do not share an EFI partition on this laptop. Windows has its EFI partition on the one nvme drive, and Linux has its EFI partition on the other drive. I never hibernate the laptop in any case in either operating system, and this has been turned off in Windows, and was never turned on in Linux, and any attempts to hibernate has been disabled.

I am now running with loglevel 7, and seeing if I see anything untoward.

Many thanks for the insights so far. If you think of anything else I can poke at, that would be great.

I guess my next step would be to decode the ACPI tables and see if I see anything weird in there, but there is so much magic happening there that I really don't understand most of it.

seth · 2025-09-09 15:26:22

Windows and Linux do not share an EFI partition on this laptop.

irrelevant

I never hibernate the laptop in any case in either operating system, and this has been turned off in Windows

nb. that windows by default hibernates instead of shutting down, so make sure that feature is indeed (still) disabled, but since strictly the hybrid mode is affected I don't even think it's that likely to be the cause.
You could test the hybrid mode on the dock/external power (afaiu you probably only ever ran into this while also on battery?)

The shutdown occurs in Hybrid mode under moderate to high loads, and never occurs in AsusMuxDgpu mode.
This leads me to think that it is not related to C states of the CPU.

The common problem is not triggered by any absolute load and the concern would be that in hybrid mode the CPU is also the GPU.
=> https://archlinux.org/packages/extra/x86_64/corectrl/

You could also test the IGPU/APU-only mode (w/ the expectation rather being that it shows the same behavior)

Fwwi, your OP make it look like your os-release is full of cachyos stuff

evorster · 2025-09-09 16:41:56

Yes, the initial post here was made from a CachyOS install. For that, I do apologize.

The excuse here is that I tried a clean install of a different operating system to make sure that it was not something that I did to my Arch install that caused this issue.
I was writing some software that interfaces with asusd, and may have angered the BIOS by setting some variable that may have stuck. Then again, I never set any variable directly in the BIOS, always through asusctl or the kernel exposed control knobs, so this also seems unlikely.
Especially since I flashed the BIOS and then did the old trick of holding the power button down for a minute which is supposed to clear all the BIOS registers.

I'm back on the same Arch install that I first noticed this issue on. Cachy does a few things differently, some of which I like, and some of which I don't like. I particularly like the idea of snapper, but that is something I'll play with once this issue is sorted. I see that it is an Arch package as well, but I digress.

Back to the issue at hand. The shutdowns occur on AC power, supplied by the 300W power brick that came with the laptop, and with the battery fully charged.
I think it is unlikely that it is a power supply issue, as in Windows and in AsusMuxDgpu modes I can draw significant amounts of power without issue.

This being a thermal issue is also unlikely, but not impossible.
I do see temperatures snap up very quickly when running stress tests, but this is also true for Windows and AsusMuxDgpu modes, and between the fans ramping up and the CPU throttling back from 5.4Ghz to 4Ghz it seems normal. It has also been the case before this issue started affecting this hardware.
The consideration here as you mentioned is that the AMD GPU and the CPU share a die, and the nVidia GPU does not. But this has not been an issue up to a month ago when I ran this configuration without issue. Also, the AMD GPU (610M) is a puny little one that hardly draws power.

The corecontrol utility seems interesting, and I'll have a play with it in due time. Thanks for the link, I was unaware of this utility.

It is unfortunate that I am at the moment on ship with a very slow and flaky internet connection, so I can't just roll back the install to a known good date to see if it was a software update that is causing this issue. In a few weeks I'll try that when I am home again with a proper internet link.

I'll try the iGPU only mode next, and if this triggers the issue, I'll upload new journals of the run and subsequent run at loglevel 7. Maybe that will shed some light on the root cause here.

evorster · 2025-09-09 17:53:41

So, some more testing was done.

This is a normal boot in AsusMuxDgpu mode. In this one I switched to Hybrid mode and rebooted normally:
http://0x0.st/KqRR.txt

This was the next boot, this time in Hybrid mode.
I ran sudo s-tui, and the laptop shut down:
http://0x0.st/KqRD.txt

Next I booted again, and switched to Integrated mode, and rebooted:
http://0x0.st/KqRk.txt

This is the next boot, in Integrated mode.
Ran sudo s-tui, and the system shut down:
http://0x0.st/KqRF.txt

This is the next boot, also in integrated mode.
http://0x0.st/Kq7K.txt

I noticed some kernel oops in the last few boots, so I rebooted once again, and this time no oops:
http://0x0.st/Kq7Z.txt

After this testing, I switched back to AsusMuxDgpu mode and rebooted.
Then it occurred to me that the common thread here is the amd drivers and firmware for the GPU.
So, I downgraded those two only to:

yay -U amd-ucode-1:20250708-2-any.pkg.tar.zst
yay -U linux-firmware-amdgpu-1:20250708-2-any.pkg.tar.zst

Switched back to Hybrid mode, and ran sudo s-tui again.
This time it actually stayed up quite a bit longer, with the fans almost getting to full speed before shutting down again on it's own.

So, it is a bit of an emotional rollercoaster.

In any case, I am a little concerned that this testing might be introducing thermal spikes that can't be good for my hardware. When it powers down, it goes hard. Even though the power is cut to the CPU, it is also cut to the cooling fans so there may be a thermal spike afterwards. In any case, when I manually boot it up a second or so later the fans are not going crazy, so it may be all right.

Still, this is not the sort of test I want to be doing too often for fear of physically damaging something. Not only is this a fairly expensive piece of kit, I am also very far away from any repair shop in the middle of the ocean.

Last edited by evorster (2025-09-09 17:55:47)

killertofus · 2025-09-09 18:34:57

cachy os is not Arch and is not supported here.

https://bbs.archlinux.org/misc.php?action=rules

evorster · 2025-09-09 18:37:00

killertofus wrote:

cachy os is not Arch and is not supported here.

https://bbs.archlinux.org/misc.php?action=rules

Right, but this is an Arch install, so should be supported.

seth · 2025-09-09 18:47:02

I think it is unlikely that it is a power supply issue, as in Windows and in AsusMuxDgpu modes I can draw significant amounts of power without issue.

nb. that the concerned Ryzen issue is also not affected by overall power supply - it's the cpu shifting around loads and then tripping into a hole on a dime.

this has not been an issue up to a month ago when I ran this configuration without issue

The situation is also aggravating, so it's not uncommon to only show up over time - if you suspect a kernel regression, you could downgrade to / install an older kernel (this is, unlike for most other packages, usually fine-sh as long as you don't try to boot a kernel from 5 years ago)
W/o any internet access, you might easily still have cached entries in /var/cache/pacman/pkg

evorster · 2025-09-09 19:18:38

Thanks for the reply!
I sanitized the OP post to remove anything Cachy specific.
That should keep the moderators at bay.

I also booted into Windows to ensure that hibernation is still off. I only allot a small portion of my storage space to Windows in any case, and with 64Gb of RAM the hibernation file is massive. So, hibernation has been removed earlier, and confirmed to still be gone.

The corectl package looks interesting, but on my system I don't get nearly the same amount of control that is shown in the video. Could be an AMD thing.

I have a cache of older packages, and will try the downgrade to when I got off this ship the last time, and was running Hybrid mode and editing video without it shutting down. I'll get the exact date and go from there.

If you were wondering why I am running this hardware as hard as I am, it is because I do media creation on this laptop, and quite often the CPU and GPU are at their max for long periods of time.
The fact that s-tui can trigger the shutdown is a blessing in disguise, as I am not losing important work while getting to the root of this.

If this is a kernel issue it won't be the first one that I had to go bisect a kernel to get to the bottom of. The last time was this very same laptop not shutting down while having an external display connected. I think it was around 6.14... I just hope that I don't crater this laptop while looking for this problem.
I don't undervolt or overclock, and never rice my systems.
If I need faster, I get something that _is_ faster. Stability is my main goal, and this is why this issue is so disconcerting to me.

Thanks for your support, Seth. Hopefully we'll turn up something interesting and find a workaround in software.

evorster · 2025-09-15 16:24:28

So, finally I have tracked it down.
Or, at least I am getting closer, and need your help again, please.
My system is now stable, rolled back to 27th of June 2025.
If I install these two packages, the issue shows itself:

2  core/amd-ucode              20250613.12fe085f-9 -> 20250627-1
1  core/linux-firmware-amdgpu  20250613.12fe085f-9 -> 20250627-1

As far as I can tell, these two packages point at the same code here:
https://gitlab.com/kernel-firmware/linux-firmware

Between those two dates, quite a lot of code has gone into this repo.
If it was just a single package, I could git bisect it to find the exact commit that causes this issue, but since these two packages are both installed and both point at the same code, I am a little bit at a loss of how to proceed.

Then, even if I find the exact commit that causes this issue, I don't know where to report it. The repo understandably does not have an issue tracker.

I have since updated my system to fully up to date, just keeping those two packages at their earlier version, and so far it is looking good, with no unexpected shutdowns.

Last edited by evorster (2025-09-15 17:03:11)

seth · 2025-09-15 18:46:10

amd-ucode and linux-firmware-amdgpu don't have a string relationship (they both address hardware sold by AMD)
What's the output of "lscpu"?
There's a chance amd-ucode is completely inert, https://gitlab.com/kernel-firmware/linu … type=heads

evorster · 2025-09-16 02:38:54

Hi, thanks for the reply!

Here is the output of lscpu:

Architecture:                x86_64
  CPU op-mode(s):            32-bit, 64-bit
  Address sizes:             48 bits physical, 48 bits virtual
  Byte Order:                Little Endian
CPU(s):                      32
  On-line CPU(s) list:       0-31
Vendor ID:                   AuthenticAMD
  Model name:                AMD Ryzen 9 7945HX3D with Radeon Graphics
    CPU family:              25
    Model:                   97
    Thread(s) per core:      2
    Core(s) per socket:      16
    Socket(s):               1
    Stepping:                2
    Frequency boost:         enabled
    CPU(s) scaling MHz:      35%
    CPU max MHz:             5456.6582
    CPU min MHz:             427.3290
    BogoMIPS:                4591.04
    Flags:                   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rd
                             tscp lm constant_tsc rep_good amd_lbr_v2 nopl xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16
                              sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch
                              osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibp
                             b stibp ibrs_enhanced vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt c
                             lwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local user_shstk avx512_b
                             f16 clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilt
                             er pfthreshold avic vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx
                             512_vpopcntdq rdpid overflow_recov succor smca fsrm flush_l1d amd_lbr_pmc_freeze
Virtualization features:     
  Virtualization:            AMD-V
Caches (sum of all):         
  L1d:                       512 KiB (16 instances)
  L1i:                       512 KiB (16 instances)
  L2:                        16 MiB (16 instances)
  L3:                        128 MiB (2 instances)
NUMA:                        
  NUMA node(s):              1
  NUMA node0 CPU(s):         0-31
Vulnerabilities:             
  Gather data sampling:      Not affected
  Ghostwrite:                Not affected
  Indirect target selection: Not affected
  Itlb multihit:             Not affected
  L1tf:                      Not affected
  Mds:                       Not affected
  Meltdown:                  Not affected
  Mmio stale data:           Not affected
  Old microcode:             Not affected
  Reg file data sampling:    Not affected
  Retbleed:                  Not affected
  Spec rstack overflow:      Mitigation; Safe RET
  Spec store bypass:         Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:                Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:                Mitigation; Enhanced / Automatic IBRS; IBPB conditional; STIBP always-on; PBRSB-eIBRS Not affected; BHI Not affected
  Srbds:                     Not affected
  Tsa:                       Vulnerable: No microcode
  Tsx async abort:           Not affected

If it is completely intert, then I can uninstall amd-ucode and just focus on linux-firmware-amdgpu, right?

seth · 2025-09-16 06:09:43

"Unfortunately" it's not.

    CPU family:              25 # 0x19
    Model:                   97 # 0x61
    Stepping:                2 # 0x02

Microcode patches in microcode_amd_fam19h.bin:
…
  Family=0x19 Model=0x61 Stepping=0x02: Patch=0x0a60120a Length=5568 bytes

But you can try downgrades of those packages independently.

evorster · 2025-09-16 08:47:54

Done some more testing...
With the latest amd-ucode installed, the issue is not present.
With linux-firmware-amdgpu updated past 2025/06/27 the system shuts down when using the amd gpu and is under slight load.

So, there is no git package for linux-firmware-amdgpu, so how do I go about bisecting this, and where to I report my findings?

seth · 2025-09-16 12:18:38

Sep 09 15:19:55 Evert.Strix kernel: amdgpu 0000:09:00.0: amdgpu: [drm] Display Core v3.2.334 initialized on DCN 3.1.5

https://gitlab.com/kernel-firmware/linu … type=heads
https://gitlab.freedesktop.org/drm/amd/-/issues/

Edit: the firmwares are blackboxes, privy to AMD only.
File the bug there and point out the good and the bad version of the file - they'll need to take it from there.

Last edited by seth (2025-09-16 12:19:51)

evorster · 2025-09-16 16:57:42

Thanks again for the reply, and pointing me in the right direction.

The troubleshooting with the amdgpu guys is being done here:
https://gitlab.freedesktop.org/drm/amd/-/issues/4581

Arch Linux

#1 2025-09-07 13:59:21

[Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#2 2025-09-07 20:07:39

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#3 2025-09-08 03:34:45

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#4 2025-09-08 09:54:31

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#5 2025-09-08 13:54:27

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#6 2025-09-09 08:24:12

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#7 2025-09-09 13:59:05

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#8 2025-09-09 15:26:22

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#9 2025-09-09 16:41:56

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#10 2025-09-09 17:53:41

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#11 2025-09-09 18:34:57

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#12 2025-09-09 18:37:00

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#13 2025-09-09 18:47:02

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#14 2025-09-09 19:18:38

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#15 2025-09-15 16:24:28

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#16 2025-09-15 18:46:10

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#17 2025-09-16 02:38:54

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#18 2025-09-16 06:09:43

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#19 2025-09-16 08:47:54

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#20 2025-09-16 12:18:38

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

#21 2025-09-16 16:57:42

Re: [Resolved] Asus AMD Advanced Optimus Laptop shuts down on amdgpu.

Board footer