gaze15 keyboard input and battery monitor issue on firmware 2021-03-19_af2fbdf

[bflanagin]

Issue is hard to duplicate due to its seemingly random occurrence. However, once triggered the systems battery monitor can no longer estimate the time left on the battery. At the same time the input from the keyboard becomes delayed to the point where the user would be forced to power off the laptop in order to regain both battery monitoring and keyboard.

Here is the journalctl -b0 output:
keyboard_issue.txt

The system wasn't under load when the issue happened.

[jackpot51]

Can you add this to the kernel parameters:

acpi.aml_debug_output=1

[bflanagin]

acpi.aml_debug_output=1 fails using sysctl -w with:

sysctl: cannot stat /proc/sys/acpi/aml_debug_output: No such file or directory

This is with 5.11 however the input error happened on the older kernel as well.

[jackpot51]

Use sudo kernelstub -a acpi.aml_debug_output=1 and then reboot

[serioustable]

I've experienced this same thing on a gaze15. This has typically happened under some sort of heavy load, such as compiling Unreal Engine 4 or most recently, running No Man's Sky. I've seen this resolved by leaving the laptop for about 10 minutes, then shutting it off and rebooting. Keyboard becomes responsive again and battery estimate is displayed.

This has happened under Nvidia Graphics; I haven't tried to replicate under Hybrid yet.

Kernel is 5.13.9-xanmod1

[serioustable]

Following the advice of support, I used the same command as recommended by @jackpot51:

sudo kernelstub -a acpi.aml_debug_output=1

After entering the command into Terminal and rebooting, I've attempted to replicate the issue by playing through No Man's Sky over the last hour. Thus far, I haven't experienced the issue again. I will continue to test with both No Man's Sky and other games that may require shader compilation to see if I can cause the same issue again.

[serioustable]

system76-logs.zip

I was able to replicate this issue by simultaneously:

• Downloading and installing Final Fantasy XIV via the XIVLauncher from Lutris, and
• Installing dotnet48 and vcrun2019 into a new prefix.

Attached are the logs generated by the System76 Driver application while the issue was occurring; I was able to bypass the problem by plugging in an external USB keyboard, which allowed the external keyboard to type normally; while the keyboard was plugged in, the on-board keyboard was still experiencing the issues described. Battery level was also displayed as "Estimating..." during this time.

[bflanagin]

I was finally able to replicate the issue on my gaze15 as well.
keyboardIssue-08202021.txt

[thefirethirteen]

gaze15 owner here with (mostly) the same issue, only this time on firmware 2022-11-21_b337ac6. I've observed this issue when booting Pop!_OS or Windows 11. My observations only cover the keyboard being delayed. While I have observed battery issues, I have not yet identified a probable cause.

My issue typically occurs after a reboot. The issue can be avoided if the user fully shuts down the machine and starts it back up, instead of rebooting.

Observed behaviour is slow keyboard input when entering a system's encryption password (Pop!_OS or Windows). After the system boots the OS feels sluggish and some things don't work right, such as a Bluetooth mouse in Pop!_OS.

I can easily spot when the issue is happening due to the aforementioned Bluetooth mouse issue.

[electron-farmer]

Additional reproduction on gaze15 — confirmed thermal trigger + specific ACPI methods identified

Hardware: System76 gaze15
BIOS: 1.07.11a (2020-12-02)
OS: Pop!_OS 24.04 LTS
Kernel: 6.18.7-76061807-generic

---

I've hit this issue twice today (2026-05-15), both times resulting in a hard lockup requiring a battery pull (more severe than the delayed keyboard described above — complete freeze, shutdown hangs at the bottom of the stack even after systemd reaches poweroff).

What the kernel logs show

The failure is a cascade of AE_TIME timeouts on \_SB.WMI.SCMD and \_SB.WMI.WMBB, firing every 2–3 seconds for ~2 minutes before the system becomes unresponsive:

May 15 23:22:41 kernel: ACPI Error: AE_TIME, Returned by Handler for [EmbeddedControl] (20250807/evregion-301)
May 15 23:22:41 kernel: ACPI Error: Timeout from EC hardware or EC device driver (20250807/evregion-311)
May 15 23:22:41 kernel: Initialized Arguments for Method [SCMD]:  (3 arguments defined for method invocation)
May 15 23:22:41 kernel:   Arg0: Integer 0000000000000000
May 15 23:22:41 kernel:   Arg1: Integer 0000000000000067   ← fan control command
May 15 23:22:41 kernel:   Arg2: Buffer(4) F9 FF 00 F0
May 15 23:22:41 kernel: ACPI Error: Aborting method \_SB.WMI.SCMD due to previous error (AE_TIME)
May 15 23:22:41 kernel: ACPI Error: Aborting method \_SB.WMI.WMBB due to previous error (AE_TIME)

This repeats every 2–3 seconds. Arg1=0x67 is the WMI fan control command. The EC is being hammered with fan speed requests it can't respond to within the ACPI timeout window, and once it falls behind it never recovers.

i915 DRM vblank misses also appear simultaneously — consistent with the EC monopolizing IRQ resources.

Confirmed thermal trigger

I have an OTel → SignOz monitoring pipeline shipping node_hwmon_temp_celsius and node_load* from this machine. The data from the crash window is unambiguous:

Time (local)	CPU temp peak (coretemp)	thermal_zone0	load1
T-3min	74°C	68°C	2.35
T-2min	84°C	84°C	3.34
T-1min	87°C	84°C	2.68
T-0 (crash)	86°C	84°C	3.63
T+1min	drops to 65°C	82°C	3.50 ← last metric before OTel died

Cores were pinned at 84–87°C for 3+ minutes before the EC storm started. No disk I/O — pure CPU workload. The system76 WMI stack was escalating fan control SCMD calls to try to manage thermals, and the EC firmware couldn't keep up.

The sudden CPU temp drop at T+1min (86°C → 65°C) is consistent with thermal throttling kicking in at the same time as the EC storm, rather than the system actually cooling — the EC was already failing to respond when the throttle happened.

Connection to earlier comments

This matches the pattern described by @serioustable ("typically happened under some sort of heavy load, such as compiling Unreal Engine 4 or running No Man's Sky") — the common thread is sustained high CPU/GPU thermal load. The EC gets overwhelmed managing fan speeds via SCMD 0x67 at high temps and stops responding to ACPI.

Re: acpi.aml_debug_output=1

I'll add this kernel parameter now and report back with AML debug output on the next occurrence. Given this has happened twice today it should reproduce soon.

---

Update 2026-07-05 MDT / 2026-07-06 UTC — reproduced again with AML debug enabled

Same machine reproduced the same externally-visible symptoms again on 2026-07-05: keyboard/input became unusable, reboot/shutdown did not complete cleanly, and the next successful boot did not start until several minutes later.

System at time of repro:

• Hardware: System76 gaze15
• BIOS: 1.07.11a (2020-12-02)
• OS: Pop!_OS 24.04 LTS
• Kernel: 6.18.7-76061807-generic
• Kernel command line included acpi.aml_debug_output=1
• Packages:
  • system76-dkms 1.0.22~1768591124~24.04~5256643
  • system76-driver 24.04.20~1781042979~24.04~3bc39b7
  • system76-firmware-daemon 1.0.76~1779994942~24.04~91111ff
  • system76-power 1.2.8~1772053322~24.04~feb0f78

Boot/reboot timeline

journalctl --list-boots shows the affected boot ending at 2026-07-05 22:13:40 MDT, followed by the next successful boot at 22:19:52 MDT:

-1 b3d55ebbae1546a6acc404fd68d969e3 Thu 2026-07-02 21:45:43 MDT Sun 2026-07-05 22:13:40 MDT
 0 2171198ec84b4464a707724be64e3e20 Sun 2026-07-05 22:19:52 MDT Sun 2026-07-05 22:26:11 MDT

That leaves a ~6 minute gap after the shutdown path reached systemd-shutdown, consistent with the prior shutdown/restart hang behavior.

Kernel/ACPI failure signature

The first EC timeout appeared at 22:11:39 MDT. From 22:11:39 through 22:13:37, the kernel logged the same AE_TIME failure cascade every ~2-3 seconds:

Jul 05 22:11:39 kernel: ACPI Error: AE_TIME, Returned by Handler for [EmbeddedControl] (20250807/evregion-301)
Jul 05 22:11:39 kernel: ACPI Error: Timeout from EC hardware or EC device driver (20250807/evregion-311)
Jul 05 22:11:39 kernel: Initialized Arguments for Method [SCMD]:  (3 arguments defined for method invocation)
Jul 05 22:11:39 kernel:   Arg0: Integer 0000000000000000
Jul 05 22:11:39 kernel:   Arg1: Integer 0000000000000067
Jul 05 22:11:39 kernel:   Arg2: Buffer(4) FF 00 D9 F1
Jul 05 22:11:39 kernel: ACPI Error: Aborting method \_SB.WMI.SCMD due to previous error (AE_TIME) (20250807/psparse-529)
Jul 05 22:11:39 kernel: ACPI Error: Aborting method \_SB.WMI.WMBB due to previous error (AE_TIME) (20250807/psparse-529)

Counts from the failure window (22:11:30-22:13:45):

AE_TIME=48
EC_timeout=48
SCMD_abort=48
WMBB_abort=48
i915_atomic=16
i2c_hid_incomplete=1

AML debug output is now available, and it confirms that all 48 failed SCMD calls used Arg1=0x67:

48 0x67

That matches the fan-control command identified in the previous repro. Arg2 varied across the repeated calls, with representative buffers including:

FF 00 D9 F1
00 0B FF F0
3C 00 00 F4
00 FF 8F F3

Concurrent side effects also match the earlier failure pattern:

Jul 05 22:11:54 kernel: i2c_hid_acpi i2c-ELAN0412:00: i2c_hid_get_input: incomplete report (14/1024)
Jul 05 22:11:55 kernel: i915 0000:00:02.0: [drm] *ERROR* Atomic update failure on pipe A (...)

The i915 atomic update failures continued during the EC storm, with 16 occurrences in the same window.

Shutdown/reboot evidence

Reboot was requested at 22:13:34 MDT while the EC timeout storm was still ongoing:

Jul 05 22:13:34 systemd-logind[1147]: The system will reboot now!
Jul 05 22:13:34 systemd-logind[1147]: System is rebooting.
Jul 05 22:13:35 system76-power[1082]: [INFO] caught signal: SIGTERM

The encrypted volume teardown failed again:

Jul 05 22:13:40 systemd-cryptsetup[280917]: Device cryptdata-1yjt is still in use.
Jul 05 22:13:40 systemd-cryptsetup[280917]: Failed to deactivate 'cryptdata-1yjt': Device or resource busy
Jul 05 22:13:40 systemd[1]: systemd-cryptsetup@cryptdata\x2d1yjt.service: Failed with result 'exit-code'.

The shutdown path reached the reboot target, then the journal stopped at systemd-shutdown:

Jul 05 22:13:40 systemd[1]: Finished systemd-reboot.service - System Reboot.
Jul 05 22:13:40 systemd[1]: Reached target reboot.target - System Reboot.
Jul 05 22:13:40 systemd-shutdown[1]: Syncing filesystems and block devices.
Jul 05 22:13:40 systemd-shutdown[1]: Sending SIGTERM to remaining processes...

Next kernel boot did not begin until 22:19:52 MDT.

Temperature/load data from OTel/SigNoz

I also pulled the host metrics from the OTel/SigNoz pipeline. Metrics were present until 22:12:44 MDT, then stopped before the final shutdown entries. This repro was warm, but unlike the May 15 event, the highest CPU temperature sample was several minutes before the first EC timeout rather than exactly at the onset.

Minute buckets around the failure:

Time MDT	coretemp max	ACPI thermal zone	load1	load5	load15
22:00	79°C	75°C	1.52	1.61	1.60
22:01	84°C	71°C	2.11	1.75	1.65
22:02	74°C	74°C	1.67	1.69	1.63
22:03	81°C	74°C	1.99	1.76	1.66
22:04	71°C	81°C	1.85	1.77	1.67
22:05	81°C	75°C	1.62	1.70	1.65
22:06	90°C	74°C	1.60	1.67	1.64
22:07	79°C	75°C	1.36	1.58	1.61
22:08	74°C	75°C	1.20	1.49	1.58
22:09	74°C	76°C	1.80	1.57	1.60
22:10	75°C	72°C	1.82	1.62	1.61
22:11	77°C	75°C	1.64	1.58	1.60
22:12	72°C	75°C	4.73	2.46	1.90

Top sensor maxima during 22:00-22:13 MDT:

coretemp Package id 0: 90°C at 22:06:44
coretemp Core 4:      90°C at 22:06:44
x86_pkg_temp:         83°C at 22:09:44
acpitz:               81°C at 22:04:44
pch_cometlake:        73°C at 22:09:44
nvme max:             50.8°C at 22:12:44

There are still no fan RPM or PWM metrics exported for this host in SigNoz (node_hwmon_fan_* / node_hwmon_pwm* absent), so I cannot correlate the repeated SCMD 0x67 fan-control calls with actual fan response/RPM.

Interpretation

This is another reproduction of the same EC hang pattern with better AML debug output:

• EC stops responding to ACPI EmbeddedControl transactions.
• \_SB.WMI.SCMD / \_SB.WMI.WMBB repeatedly abort with AE_TIME.
• Every failed SCMD call in this capture uses Arg1=0x67.
• i915 display timing failures and one i2c HID input failure appear during the storm.
• Shutdown/reboot reaches late shutdown, but encrypted volume teardown fails and there is a multi-minute gap before the next boot.

The new distinction is that this capture does not show the same sustained 84-87°C CPU plateau immediately before failure. It still shows recent thermal activity (90°C peak ~5 minutes before first timeout, ACPI zone up to 81°C), but the stronger invariant across both captures is now the SCMD 0x67 / EmbeddedControl timeout storm itself.