kern/60735: BEEP_ONHALT fails on i386

["royce%tycho.org@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60735
>Category:       kern
>Synopsis:       BEEP_ONHALT fails on i386
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Sep 16 21:45:02 +0000 2026
>Originator:     Royce Williams
>Release:        11.0
>Organization:
>Environment:
Reproduced on multiple devices, from QEMU:
NetBSD 11.0 (QEMU_BEEPHALT) #0: Wed Sep 16 13:23:26 AKDT 2026
... and a physical device (Whistle InterJet, 486):
NetBSD test 11.0 NetBSD 11.0 (INTERJET_64M) #24: Tue Sep 15 21:57:21 AKDT 2026 
>Description:
BEEP_ONHALT seems to be designed to notify the user when halt has completed (and it's OK to shut down) -- but it looks like the components necessary to make that work on i386 have a gap, such that the beeping will never happen in practice without some adjustment.

Since many folks probably don't have a PC speaker anymore, this can be reproduced by telling QEMU to send its audio output to a file:

-audiodev wav,path=

I have a Whistle InterJet that I'm testing on and it reproduces the problem.
>How-To-Repeat:
1. Uncomment this in i386 GENERIC (NetBSD 11.0 release):

options        BEEP_ONHALT

2. On an i386-compatible system with a PC speaker, build, install, and boot.

3. Execute:

shutdown -h now

4. Expected: three beeps near/after "The operating system has halted."
   Actual:   silence

   Console shows:

sysbeep0: detached
[...]
The operating system has halted.

>Fix:
Not sure. Naively, moving the beep earlier than the device detachment would be one way, or making it so that sysbeep doesn't actually detach, or having the halt do the beeping itself directly ... but I have no idea about the trade-offs or other implications of these. In my searching it did seem like FreeBSD uses the "halt beeps on its own" approach.