[Bug] Spontaneous emergency reset ("software wrote 0xE to 0xCF9") on AMD Ryzen 9 8945HX (Lenovo Legion R9000P 2025) with 7.3.0-rc2 -- twice in one day, no Oops/panic logged

[Starry2233 <qu20121118@yeah.net>]

Hi,




I'm running the Ubuntu mainline 7.3.0-rc2 build on a Lenovo Legion R9000P

2025 and since switching to the 7.3 rc's the machine will, every so often,

just hard reset itself out of nowhere. No timeout, nothing written to the

log right before -- the box is mid-work and then it's gone, rebooted like

someone pressed reset.




The AMD FCH reset-reason decoder says both resets were an emergency software

reset (0xE written to the 0xCF9 reset control register), not a clean reboot

and not a power loss. On 7.3.0-rc1 the exact same symptom showed up as a

sudden power-off instead; on rc2 it comes back as a warm emergency reset.

Either way, no Oops, no panic, no MCE, no hung-task/lockup message anywhere

- the journal is alive until the very last line and then the machine resets.




I'm kind of stuck on an RC kernel by necessity: the AW88399 subwoofer amp in

this particular model only got driver support in 7.3-rc1, which is why I

can't just fall back to the 6.12 stable kernel. So I'd rather report this

properly than silently ride it out. Apologies in advance if this should go

to bugzilla instead -- point me at the right place and I'll move it.




Hardware / software

-------------------




- Lenovo Legion R9000P 2025 (DMI product LNVNB161216, baseboard "Legion

  R9000P ADR10", BIOS RLCN29WW, 2025-08-14)

- AMD Ryzen 9 8945HX (Hawk Point-HX, 16C/32T)

- NVIDIA GeForce RTX 5060 Max-Q (GB206M, 10de:2d59, rev a1),

  nvidia-open 595.99.02 via DKMS, KDE Plasma 6 / Wayland

- Audio: AMD ACP (1022:15e2), AMD HD-Audio (1022:15e3), Realtek ALC287,

  AW88399 subwoofer amp on I2C (SSID 17aa:3928)

- WLAN: Realtek RTL8922AE 802.11be (rtw89_8922ae)

- USB: 3x AMD Raphael xHCI (1022:15b6 / 15b7 / 15b8); a Google Pixel phone

  (18d1:4ee7) is usually plugged into usb3-port1

- Kernel: Linux 7.3.0-070300rc2-generic #202609070545 SMP PREEMPT_DYNAMIC,

  built Thu Sep 10 12:34:01 UTC 2026 (Ubuntu mainline, gcc-15)

- cmdline: BOOT_IMAGE=/boot/vmlinuz-7.3.0-070300rc2-generic

  root=UUID=83395a8d-ed16-43ad-8b2b-6989f78045eb ro quiet

- Debian 13 (trixie)




What the logs look like

-----------------------




(All timestamps below are local time, UTC+08:00.)




1) FCH reset-reason decode, read at the start of the boots right after each

   crash. Both abnormal events decode identically:




   x86/amd: Previous system reset reason [0x00300800]: software wrote 0xE

            to reset control register 0xCF9

   x86/amd: Previous system reset reason [0x00300800]: ACPI power state

            transition occurred




   Every normal reboot of the same box on the same kernel decodes as:




   x86/amd: Previous system reset reason [0x00080800]: software wrote 0x6

            to reset control register 0xCF9




   So the two crashes are exactly the emergency reset path

   (emergency_restart() -> machine_emergency_restart(), which writes 0x0E).




2) There is no kernel log at all preceding either reset. The journal keeps

   getting messages (wireplumber, systemd, chrome) right up to the last

   second, then nothing. No panic, no oops, no hung task, no lockup, no MCE.

   pstore / efi_pstore has nothing from today either, which makes sense for

   a reset that isn't a panic.




3) What was happening at the time:

   - Crash #1 (session ended ~14:31, 2026-09-12): a screen recorder called

     "Cap" was running with ALSA/JACK via PipeWire; last log lines are its

     playback stats ("effective_fps=60.1").

   - Crash #2 (session ended ~15:11): a few minutes earlier the Pixel phone

     on usb3-port1 went through a bad enumeration storm:

       15:08:53 usb 3-1: device descriptor read/64, error -71

       15:09:00 usb 3-1: Cannot enable. Maybe the USB cable is bad?

       15:09:00 usb 3-1: unable to enumerate USB device

     (it finally enumerated at 15:09:12 as device #11), then about two

     minutes later the reset. Chrome was mid-playback at the same time

     (its last line is "Frame latency is negative: -0.045 ms").




4) Sysctl timeline, because it rules out the obvious: I set

   kernel.panic=10 / panic_on_oops=1 on this box at ~14:52, which is after

   crash #1 (so that one ran with kernel.panic=0 and cannot be a

   panic-timer emergency_restart) and before crash #2 (which, even with

   panic=10 active, produced no panic message while the journal was healthy

   up to the last moment).




5) Why I'm reporting this without a call stack: every reboot-path symbol

   rejects kprobe/ftrace on this kernel. register_kprobe() returns -22 for

   all of:




     emergency_restart

     machine_emergency_restart

     native_machine_emergency_restart

     machine_restart

     kernel_restart




   (a probe on panic() registers fine, so the reset path is squarely on the

   kprobe blacklist). My fallback plan is a small module that detour-patches

   emergency_restart()'s entry to log the caller, but if there's a proper,

   supported way to get the caller I'd rather use that.




What I suspect

--------------




- Both crashes happened with the GPU and the audio pipeline busy at once

  (screen recording over JACK/ALSA with compositing in one case, Chrome

  playback in the other), and the audio side is exactly the code that is

  new for this model in 7.3-rc1 (ALC287 + AW88399). The fact that the

  behaviour flipped from power-off (rc1) to warm emergency reset (rc2)

  between two RC releases is a good signal that something changed in that

  window, audio or reset-handling related.

- Not fully sure about this, but it feels like the resets happen when I'm

  playing a video that has audio (rather than silent content or plain

  static load). Both events so far fit that pattern (Cap screen recording

  and Chrome playback both had audio going), but take it with a grain of

  salt - I can't claim it's a reliable trigger.

- nvidia-open 595.99.02 prints two boot-time assertions on this SBIOS:




    NVRM: GPU0 nvAssertOkFailedNoLog: Assertion failed: Invalid data

    passed [NV_ERR_INVALID_DATA] (0x00000025) returned from

    PlatformRequestHandler failed to get target temp from SBIOS @

    platform_request_handler_ctrl.c:2174

    ... failed to get platform power mode from SBIOS @ ...:2117




  Looks benign (Lenovo doesn't implement PlatformRequest), just adding it

  for completeness.

- Not a thermal event: temps are normal and the reset-reason decode points

  to a deliberate software emergency reset, not an EC/platform trip.




Questions

---------




1. Given that the journal was still writing normally right up to the reset,

   is a "panic with a wedged console" scenario actually plausible, or should

   I assume a direct emergency_restart() caller that simply never logs?

2. Anything known between 7.3-rc1 and -rc2 that touches ACP / SoundWire /

   snd-hda-codec-realtek / AW88399, or the reboot/emergency-reset path,

   that could plausibly end in an unlogged emergency reset? The power-off ->

   warm-reset behaviour change between the two RCs feels like a regression

   window I can bisect.

3. Where is the best place to track this - LKML, bugzilla.kernel.org, or

   the ALSA or x86 lists? Who should I Cc?




Happy to help however I can: full journalctl -k dumps from the affected

boots, a serial console if I can set one up, testing patches, or running

a bisect between rc1 and rc2. And if someone can confirm a clean way to

catch the emergency_restart() caller despite the kprobe blacklist, that

would nail this in one shot.




Thanks for reading this far,

Starry



P.S. If anyone replies anywhere, please make sure to Cc me so I actually

see the answer - I'm reading the lists through a forwards-only account.