Sound through ALSA, a 2D game, and a stack walk that cannot panic

SDL 3 has no OSS backend and SchOS has no ALSA kernel side, so sound now
goes SDL -> alsa-lib -> alsa-plugins' OSS plugin -> /dev/dsp. That path
found two bugs underneath it:

- ac97: resetting the PCM-out box also clears the descriptor list address,
  and nothing set it again. Every stream after the first stop played a
  "list" at physical address 0 -- silence -- and ALSA resets before each
  stream. If the engine halts at the end of the queue, the run bit is set
  again.
- /dev/dsp: SETFRAGMENT, GETFMTS, GETCAPS, SETTRIGGER, GETOPTR and GETODELAY
  for the plugin's ring-and-pointer model, and poll(), writable once a whole
  fragment fits (ALSA spun at 76% CPU otherwise). speaker-test now plays in
  real time at 0% CPU, verified in a recording of QEMU's AC'97.
- /etc/asound.conf: the default device is a plug to the OSS device at 16-bit
  stereo 48 kHz, what every SchOS audio driver plays.

Also:

- getstackpcs: each frame link must go up the same stack by less than
  KSTACKSIZE. The chain ends at the syscall entry with the user's rbp,
  which lbreakouthd uses as a register (-1024); the walk dereferenced it
  under the syscall tracer and the kernel panicked inside acquire().
- fb: FBIOGET_VSCREENINFO reports nominal timings, as Linux's efifb does,
  instead of zeros, which Xorg's fbdev turned into a 0 Hz RandR mode.
- procdump (Ctrl-P) shows where runnable threads are in user space.
- World: lbreakouthd instead of lbreakout2 (its stk.c passes vsnprintf a
  size of 511 plus the prefix length, and Alpine's fortified headers trap on
  that), plus curl, alsa-lib and alsa-plugins.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S1giNvrHTrPMPw7V6x1kQ4

kernel/dev/fb.c

@@ -147,6 +147,23 @@ fbclose(struct inode *ip)
 // the largest struct here -- fb_fix_screeninfo is half the size of
 // fb_var_screeninfo, and a buffer sitting near the end of a mapping is a
 // legitimate place to put the smaller one.
+// Timings for a mode the firmware set and never described. GOP and VBE give a
+// size and a pixel format and nothing about the signal, so these are made up --
+// and made up the way Linux's efifb makes them up, which is what every program
+// that reads them was written against. They used to be zero, which is not "no
+// answer" but the answer "0 Hz": Xorg's fbdev driver built a RandR mode with a
+// dot clock of 0 from it, and SDL 3 sized a fullscreen window from that mode
+// as 1x1. Physical size stays zero; nothing reads it as a number.
+static void
+nominal_timings(struct fb_var_screeninfo *v)
+{
+  if (v->xres == 0 || v->yres == 0)
+    return;
+  v->pixclock    = 10000000 / v->xres * 1000 / v->yres;
+  v->left_margin = (v->xres / 8) & 0xf8;
+  v->hsync_len   = (v->xres / 8) & 0xf8;
+}
+
 int
 fb_ioctl(int request, addr_t arg)
 {
@@ -169,8 +186,7 @@ fb_ioctl(int request, addr_t arg)
     v->bits_per_pixel = gfx_fb_bpp();
     v->activate = FB_ACTIVATE_NOW;
     pixel_format(v, v->bits_per_pixel);
-    // height/width (physical millimetres) and every timing field stay zero:
-    // VBE does not report them and a guess would be worse than an admission.
+    nominal_timings(v);
     return 0;
   }
 
@@ -212,6 +228,7 @@ fb_ioctl(int request, addr_t arg)
     v->bits_per_pixel = gfx_fb_bpp();
     v->activate = act;
     pixel_format(v, v->bits_per_pixel);
+    nominal_timings(v);
     return 0;
   }