https://bugzilla.kernel.org/show_bug.cgi?id=222191
Bug ID: 222191
Summary: [ACPI] ASUS TUF F15 FX507VV: LID0 missing _PRW, GPE
0x02 not armed during s2idle
Product: ACPI
Version: 2.5
Hardware: Intel
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: Power-Sleep-Wake
Assignee: [email protected]
Reporter: [email protected]
Regression: No
Created attachment 311276
--> https://bugzilla.kernel.org/attachment.cgi?id=311276&action=edit
ACPI debug data for ASUS TUF F15 FX507VV (BIOS 330): dmidecode, acpidump,
dmesg, and disassembled dsdt.dsl showing active LID0 missing _PRW.
[1.] One line summary of the problem:
ASUS TUF F15 FX507VV (BIOS 330): LID0 missing _PRW, GPE 0x02 not armed during
s2idle, internal wake sources (lid/keyboard/power button) fail
[2.] Full description of the problem/report:
Hardware:
Model: ASUS TUF Gaming F15 FX507VV_FX507VV (BIOS FX507VV.330)
CPU: 13th Gen Intel Core i7-13700H
GPU: Intel Iris Xe + NVIDIA RTX 4060 Max-Q / Mobile
OS: Ubuntu 26.04.1 LTS (Resolute Raccoon)
Kernel: 7.0.0-38-generic
Symptom:
The system enters s2idle correctly (power LED "breathes", fans/keyboard
backlight off), but cannot be resumed using the internal keyboard, power
button, or by opening the lid. Only a USB wireless mouse can wake the system
(and only if it was connected before suspend). journalctl consistently ends at
PM: suspend entry (s2idle) with no suspend exit line. This is not a freeze —
the firmware/EC considers itself asleep; the wake event never reaches the CPU.
Root cause (confirmed via DSDT disassembly):
The active lid device \_SB.PC00.LPCB.LID0 has no _PRW object. There is a second
LID0 under \_SB.PC00.LPCB.H_EC, but its _STA returns Zero (disabled). As a
result:
LID0 does not appear in /proc/acpi/wakeup at all.
The EC's wake events for lid, power button, and keyboard arrive on GPE 0x02
(_GPE._L02 → ECLV()), but because no device claims that GPE for wake, Linux
does not keep GPE 0x02 enabled during s2idle.
This is not NVIDIA-related: blocking the NVIDIA driver
(module_blacklist=nvidia,nvidia_drm,nvidia_modeset,nvidia_uvm) still reproduces
the failure. It is also not a kernel regression — the same behavior is observed
on this machine across kernel versions, and the DSDT content is independent of
the running kernel.
Verified workaround (SSDT overlay):
Injecting _PRW (0x02, Zero) into \_SB.PC00.LPCB.LID0 via a 93-byte SSDT loaded
through GRUB_EARLY_INITRD_LINUX_CUSTOM fixes the problem. After reboot:
journalctl -b -k | grep "Table Upgrade" → ACPI: Table Upgrade: install [SSDT-
FIXUP- LIDWAKE]
grep LID0 /proc/acpi/wakeup → LID0 S0 *enabled platform:PNP0C0D:01
After this, internal keyboard, power button, and lid opening all successfully
wake the system. A sister model (FX507ZI4, same BIOS 330) has the same DSDT
defect and is fixed by the identical _PRW injection.
Request:
Please consider a DMI-based ACPI quirk for affected ASUS TUF FX507 series
boards that lack _PRW on the active LID0, so that GPE 0x02 is armed during
s2idle without requiring a user-space SSDT override. Similar platform quirks
already exist for other ASUS models (e.g., gpiolib-acpi-quirks.c additions).
[3.] Keywords:
ACPI, s2idle, power-management, wakeup, ASUS, LID0, _PRW
[4.] Kernel information:
text
$ uname -r
7.0.0-38-generic
/proc/version:
text
Linux version 7.0.0-38-generic (buildd@...) ... Ubuntu 26.04.1 LTS
[5.] Most recent kernel version which did not have the bug:
Not applicable — the defect is in the platform firmware (DSDT), not the kernel.
The same DSDT content is exposed regardless of kernel version. The bug is
present on all kernels tested with this machine.
[6.] Output of Oops.. message:
No Oops. The system does not crash; it simply fails to wake from s2idle. No
kernel panic or splat is produced.
[7.] A small shell script or example program which triggers the problem:
bash
# Reproducer: suspend to idle and attempt wake via internal lid/keyboard/power
button
cat /sys/power/mem_sleep # confirm [s2idle]
grep LID0 /proc/acpi/wakeup # no output → bug present
systemctl suspend
# After suspend: press a key, press power button, or close/open lid
# Expected fix: system resumes. Observed bug: nothing happens; only USB mouse
wakes.
[8.] Environment:
8.1. DMI / system identification:
text
$ sudo dmidecode -s system-product-name
ASUS TUF Gaming F15 FX507VV_FX507VV
$ sudo dmidecode -s bios-version
FX507VV.330
$ sudo dmidecode -s bios-release-date
(请自行填写)
8.2. Processor information:
text
$ grep "model name" /proc/cpuinfo | head -1
model name : 13th Gen Intel(R) Core(TM) i7-13700H
8.3. /proc/acpi/wakeup (before fix):
LID0 is absent from the list. The only enabled wake sources relevant to
resuming are PCIe/USB controllers (e.g., XHCI, PEG1, RP07), which is why a USB
mouse can wake the system but internal EC-based sources cannot.
8.4. /proc/acpi/wakeup (after fix):
text
LID0 S0 *enabled platform:PNP0C0D:01
8.5. Relevant DSDT excerpt (disassembled):
asl
Scope (\_SB.PC00.LPCB)
{
Device (LID0)
{
Name (_HID, EisaId ("PNP0C0D"))
Method (_LID, 0, NotSerialized) { ... }
// NO _PRW HERE
}
}
(Full dsdt.dsl attached.)
[X.] Other notes, patches, fixes, workarounds:
User-space workaround (confirmed working): 93-byte SSDT injecting _PRW (0x02,
Zero) into \_SB.PC00.LPCB.LID0, loaded as early initrd via
GRUB_EARLY_INITRD_LINUX_CUSTOM="acpi_override.cpio". This is a workaround, not
a proposed upstream patch.
Sister model confirmation: FX507ZI4 (BIOS 330) has the identical LID0 _PRW
omission and is fixed by the same injection. This suggests a BIOS-level
omission across the FX507 series, not a one-off board anomaly.
Suggested upstream direction: A DMI-based quirk that recognizes affected ASUS
FX507 boards and supplies the missing _PRW for the active LID0 at ACPI table
load time, so no user-space SSDT is required.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
acpi-bugzilla mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
