kern/59901: ThinkPad X31: kernel panic during suspend on NetBSD 9.4

["ky.netbsd.pr%pobox.com@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         59901
>Category:       kern
>Synopsis:       ThinkPad X31: kernel panic during suspend on NetBSD 9.4
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 09 14:30:00 +0000 2026
>Originator:     KY
>Release:        NetBSD 9.4 GENERIC
>Organization:
>Environment:
NetBSD 9.4 NetBSD 9.4 (GENERIC) #0: Sat Apr 20 13:32:22 UTC 2024 mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/i386/compile/GENERIC i386
>Description:
I am running NetBSD 9.4 on an IBM ThinkPad X31.

The system fails to suspend using ACPI. On a vanilla installation with the stock GENERIC kernel, attempting to suspend results in a kernel panic followed by an automatic reboot.

The failure can be triggered using any of the following commands:

    sysctl -w hw.acpi.sleep.state=3
    zzz
    apm -z

On the stock GENERIC kernel, I was able to capture the following console output from a video recording taken immediately before the automatic reboot:

    # sysctl -w hw.acpi.sleep.state=3
    acpi0: entering state S3
    Flushing disk caches: 4 4 4 4 4 done
    fatal protection fault in supervisor mode
    trap type 4 code 0 eip 0xc0136497 cs 0x8 eflags 0x210046 cr2 0xda681de1 ilevel 0x8 esp 0xc1244d40
    curlwp 0xc2b69440 pid 422 lid 1 lowest kstack 0xdb1a72c0
    panic: trap
    cpu0: Begin traceback...
    vpanic(...) at netbsd:vpanic+0x12d
    snprintf(...) at netbsd:snprintf
    trap_tss() at netbsd:trap_tss
    --- trap via task gate ---
    netbsd:cpu_info_primary:
    cpu0: End traceback...
    dumping to dev 0,1 offset 8
    dump area unavailable
    rebooting...

I could not figure out how to persist the crash dumps, so further post-mortem analysis was not possible.

To investigate further, I built a custom DEBUG kernel (based on GENERIC) with the intent of debugging the panic, not to change ACPI or APM behaviour. When triggering suspend under the DEBUG kernel, the system panics and drops into DDB instead of rebooting.

The following output is observed when entering the debugger:

    acpi0: entering state S3
    Flushing disk caches: 5 done
    fatal protection fault in supervisor mode
    trap type 4 code 0 eip 0xc0136507 cs 0x8 eflags 0x10046 cr2 0xb7390880 ilevel 0x8 esp 0xc1259d40
    curlwp 0xc2c699c0 pid 73 lid 1 lowest kstack 0xdb28a2c0
    kernel: supervisor trap protection fault, code=8
    Stopped in pid 73.1 (sysctl) at netbsd:acpi_nd_sleep_prepare+0x37: rdmsr
    db{0}>

At this point, the keyboard appears to be non-functional, preventing further interaction with the debugger.

An additional observation is that the ThinkPad "moon" sleep indicator LED turns on immediately before the panic occurs.

Other investigation performed:
- Attempted to disable ACPI and enable APM using boot -c ("disable acpi", "enable apm"), but APM did not attach.
- Attempted to build a kernel (APMONLY, based off GENERIC) with only APM enabled by uncommenting "apm0 at mainbus" and "options APM_V10_ONLY", but running "config APMONLY" failed with the error "apm cannot attach to mainbus".
- An overnight memory test using GoldMemory completed 11 passes with 0 errors.

The failure is reproducible, and the system is otherwise stable under NetBSD 9.4.

For reference:
- dmesg output: https://pastebin.com/f7S5v3Ze
- acpidump -td output: https://pastebin.com/JqhbQRf9

>How-To-Repeat:
1. Boot NetBSD 9.4 on an IBM ThinkPad X31.
2. As root, run: "sysctl -w hw.acpi.sleep.state=3" or "apm -z" or "zzz".
3. Observe that the system hangs or panics instead of entering S3 sleep.
>Fix:
Unknown.