Suspend/resume causes panic | NetBSD 10.1/9.4 | ThinkPad X31

KYLikesBSD

Hello everyone

I am new to NetBSD, and I am installing it on a crusty old IBM ThinkPad X31. With the help of NetBSD manual and various forum posts, I got a fair amount of functionality to work (most importantly, the audio).

However, I have run into a suspend/resume issue that I am unable to resolve, and have given up after trying for a couple of days. I found very little information regarding the ThinkPad X31, especially when it comes to running alternative operating systems.

I am hoping someone here might have insight or prior experience that could help.

The setup:

IBM ThinkPad X31 with a Pentium M 1.6GHz and 1GB RAM
- Barebones Windows XP SP3 installation with no drivers, replaced with NetBSD 10.1 and then 9.4
- BIOS v2.11 updated to v1.08
- EC v1.03 updated to v3.02

Both NetBSD 10.1 and 9.4 boot cleanly. apm and apm -v report the correct battery and AC adapter state, and the system is otherwise stable during normal use.

What does not work is suspend. Closing the lid does not trigger a suspend, and attempting to suspend manually from the shell results in a kernel panic.

For both NetBSD 10.1 and 9.4, I verified that /dev/apm and /dev/apmctl exist (via MAKEDEV apm), and that apmd starts without errors. Power states are visible via apm -v. However, both apm -z and forcing sleep via sysctl -w hw.acpi.sleep.state=3 immediately panic the kernel. I tested this both on AC power and with the battery installed, before and after the firmware updates. I also checked the BIOS for any sleep- or power-related settings, but nothing obvious stood out.

When manually forcing ACPI S3, no reliable log is preserved. The following was crudely captured from a photo of the screen:

# 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 node
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
срu0: Begin traceback...
vpanic(c0fc378f,db1a0c70,db1a8d38,c011d8cc,c0fc378f,db1a8d44,db1a8d44,1,db1a72c8,210046) at netbsd:vpanic+0x12d
snprintf(c0fc378f,db1a0d44,db1a8d44,1,db1a72c0,210046,da681de1,8,c1244d48,c05ce664) at netbsd:snprintf
trap_tss() at netbsd :trap tss
--- trap via task gate ---
netbsd :cpu_info_primary:
срu0: End traceback...
dumping to dev 0,1 offset 8
dump area unavailable
rebooting...

My main questions are:

Is NetBSD ACPI S3 resume known to fail on X31 specifically? If yes, what config knobs or kernel flags helped?
Are there ACPI quirks or patches known for this hardware?
Has anyone successfully suspended & resumed X31 on NetBSD? If yes,
1. Which NetBSD version?
2. Was a custom kernel configuration required, and what did that look like?
3. Were any DSDT overrides or ACPI quirks involved?

As a next step, I am considering testing suspend/resume using a Linux live USB to confirm whether resume works at all on this machine outside NetBSD. Ultimately, I am trying to determine whether this is a NetBSD bug or configuration issue, or simply a firmware limitation of the X31.

Thanks in advance for any guidance, and please let me know if I should provide additional information.

533k3R

Hi, welcome!

The lid issue should be a easy fix "man acpilid".

You could try building with different apm specs (1.0, 1.1, instead of 1.2); "man 4 apm" a.k.a apm(4).
Might work.

KYLikesBSD

533k3R I understand APM is currently enabled via emulation on ACPI. So to try out a different version of APM (using `options APM_V10_ONLY), APM would have to be enabled in place of ACPI.

So, I spent most of my Sunday trying to understand the process of configuring a custom kernel. However, I get an error when I run config APMONLY. APMONLY is a copy of GENERIC where I have uncommented the line apm0 at mainbus0:

APMONLY:275: 'apm' cannot attach to 'mainbus'.

I could not find much information around this error, or perhaps I have exhausted today’s quota of comprehension. 😃

So, ending the day by dropping an update here.

Also, before going the custom kernel route, I tried disabling ACPI via userconfig during boot (disable acpi and enable apm). But I end up with a state where apm -S/zzz gives a “device not configured” error. I ran apmd after executing sh MAKDEV apm in /dev, but the “device not configured” error persists.

533k3R

KYLikesBSD I understand APM is currently enabled via emulation on ACPI.

That was kinda my take.

You could make a acpidump, and upload it somewhere, for a PR. Before doing that, I'd test the memory.