On Sat, Aug 05, 2023 at 10:08:53PM +0200, xavie...@mailoo.org wrote:
> Hi,
>
> I run a 2G/100G virtual machine at openbsd.amsterdam freshly upgraded
> from stable to the latest snapshot and I've figured out the panic
> by the two steps detailed there:
>
> 1. The system has a root @reboot crontab entry that start a tmux
> session in the background (so always detached from a TTY during the
> whole procedure) + a /root/.tmux.conf which is some copy of my usual
> tmux confi, which appears to call a script that does `apm -b` (we have
> our quick workaround by removing it).
>
> The tmux session and the programs ran inside started just fine at the
> exception of the tmux session itself. By attaching that special
> session created @reboot, I noticed that tmux somehow fallback'd on the
> builtin's default config. (Green bottom status-bar and defaults
> keybinds). Which indeed indicated me that something went wrong.
>
> 2. It's only when I started tmux manually that the .tmux.conf calling
> `apm -b` triggerred the crash:
>
> # tmux ^M
> campfire.01:ksh* <-- my "on-top" status-bar was loaded this time
> uvm_fault(0xfffffd8078416cf0, 0x39c, 0, 2) -> e
> kernel: page fault trap, code=2
> Stopped at acpiopen+0x85: orb $0x1,0x39c(%r13)
> TID PID UID PRFLAGS PFLAGS CPU COMMAND
> *173406 19781 0 0x2 0 0 apm
> acpiopen(5300,1,2000,ffff8000ffff0b08) at acpiopen+0x85
> spec_open(ffff800021648598) at spec_open+0xe0
> VOP_OPEN(fffffd803bb6bcb0,1,fffffd80691bf550,ffff8000ffff0b08) at
> VOP_OPEN+0x4e
>
> vn_open(ffff8000216487b0,1,0) at vn_open+0x275
> doopenat(ffff8000ffff0b08,ffffff9c,f9805daef3b,0,0,ffff800021648980)
> at doopena
> t+0x1d1
> syscall(ffff8000216489f0) at syscall+0x364
> Xsyscall() at Xsyscall+0x128
> end of kernel
> end trace frame: 0x775e645c8040, count: 8
This looks like a regression introduced in the recent acpi_apm.c
extraction in which the ENXIO short circuit got lost in
acpi{open,close,ioctl}.
https://github.com/openbsd/src/commit/c75690924c3df592a3a5078fe57c951f808a8350
