NetBSD Problem Report #60366

From root@AlphaBox.Atari8us  Thu Jun 25 04:52:52 2026
Return-Path: <root@AlphaBox.Atari8us>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.netbsd.org", Issuer "R13" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 6B6311A923A
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 25 Jun 2026 04:52:52 +0000 (UTC)
Message-Id: <20260625044658.5F95F171E45@AlphaBox.Atari8us>
Date: Wed, 24 Jun 2026 23:46:58 -0500 (EST)
From: Technoid6502@gmail.com
Reply-To: Technoid6502@gmail.com
To: gnats-bugs@NetBSD.org
Subject: port-alpha: SRM boot -n exploit to enforce wscons delay
X-Send-Pr-Version: 3.95
X-From4GNATS: "Technoid6502@gmail.com via gnats" <gnats-admin@NetBSD.org>

>Number:         60366
>Category:       port-alpha
>Synopsis:       port-alpha: SRM boot -n exploit to enforce wscons delay
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    port-alpha-maintainer
>State:          feedback
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 25 04:55:00 +0000 2026
>Closed-Date:    
>Last-Modified:  Sun Aug 23 05:10:01 +0000 2026
>Originator:     Jeffrey S. Worley (aka Technoid Mutant)
>Release:        NetBSD 9.2
>Organization:
Atari8.us
>Environment:
System: NetBSD AlphaBox.Atari8us 9.2
Architecture: alpha
Machine: alpha
>Description:
This report documents a structural timing workaround targeting the
asynchronous video arbitration boundary between NetBSD's early kernel
display initialization and Xorg activation on native alpha platforms.

Natively, a critical race condition exists on the legacy alpha video
hardware bus: the wscons/wsdisplay subsystems initialize and attempt to
map structural display frames almost simultaneously with the rc.d
startup phase launching Xorg. On vintage Alpha video pipelines, Xorg
attempts to map PCI video registers before wscons has cleanly settled
or detached its kernel locks, causing an immediate, hard hardware
display bus lockup or total loss of video signaling.

To resolve this, we present an exploit of the SRM console firmware
environment parameters. By passing the 'boot -n' (non-interactive/
no-video initialization parameters) from the SRM firmware, we
intentionally insert a structural timing delay into the early OS boot
sequencer. This delay holds back interactive polling just long enough
to allow the wscons virtual workstation console to completely settle
its internal hardware registers. Consequently, when Xorg sweeps onto
the bus later in the sequence, the video registers are clear, and the
graphical layout initializes flawlessly.

The absolute stability, determinism, and performance durability of
this configuration are proven by the attached long-term stress
telemetry captured directly from the live environment.
>How-To-Repeat:
1. Boot a native NetBSD 9.2 alpha platform with a standard SRM boot
   string (e.g., 'boot dka0').
2. Configure the system to boot directly into a graphical Xorg
   environment via /etc/rc.conf.
3. Observe the race condition: the kernel shifts from the boot loader
   to the wscons driver, and as Xorg initializes, the hardware suffers
   a complete display bus freeze due to simultaneous register mapping
   conflicts.
>Fix:
The workaround involves exploiting the SRM 'boot -n' parameter to
introduce the required hardware-arbitration delay before the kernel
passes video control to user space. To permanently implement this
solution without risking an un-synchronized display crash on subsequent
reboots, an explicit kernel-side delay should be introduced inside the
alpha wsdisplay attachment sequence to mimic the timing window created
by 'boot -n'.

Below is the live telemetry captured from the running system after
surviving a massive, multi-day compiler stress run utilizing this
specific timing bypass:

=================== LIVE ENVIRONMENT TELEMETRY ===================
[UPTIME LOG]
11:05PM  up 5 days, 17:35, 3 users, load averages: 0.00, 0.19, 0.20

[VFS CACHE & MEMORY SUB-SYSTEM STATS]
     8192 bytes per page
        1 page color
   256571 pages managed
    93054 pages free
   110011 pages active
      262 pages inactive
        0 pages paging
     1417 pages wired
        0 zero pages
        1 reserve pagedaemon pages
        5 reserve kernel pages
     3619 boot kernel pages
    51003 kernel pool pages
     4808 anonymous pages
   103619 cached file pages
     3263 cached executable pages
      128 minimum free pages
      170 target free pages
    85523 maximum wired pages
        1 swap devices
   524287 swap pages
      516 swap pages in use
      114 swap allocations
269926107 total faults taken
282902232 traps
641966904 device interrupts
130224455 CPU context switches
 69746895 software interrupts
405114547 system calls
      114 pagein requests
       77 pageout requests
        0 pages swapped in
      603 pages swapped out
  1203700 forks total
   556581 forks blocked parent
   556581 forks shared address space with parent
        0 pagealloc zero wanted and avail
145549238 pagealloc zero wanted and not avail
        0 aborts of idle page zeroing
180738262 pagealloc desired color avail
        0 pagealloc desired color not avail
180738262 pagealloc local cpu avail
        0 pagealloc local cpu not avail
        0 faults with no memory
        0 faults with no anons
        0 faults had to wait on pages
        0 faults found released page
    52446 faults relock (52407 ok)
 41731633 anon page faults
      114 anon retry faults
 41716676 amap copy faults
 26592673 neighbour anon page faults
337581692 neighbour object page faults
 83826703 locked pager get faults
    52332 unlocked pager get faults
 26290276 anon faults
 15308132 anon copy on write faults
 70006341 object faults
 13820323 promote copy faults
136694368 promote zero fill faults
     5779 times daemon wokeup
     5779 revolutions of the clock hand
  3191456 pages freed by daemon
  3362267 pages scanned by daemon
      603 anonymous pages scanned by daemon
  3190853 object pages scanned by daemon
    18815 pages reactivated
        0 pages found busy by daemon
      526 total pending pageouts
  3780751 pages deactivated
332960776 total name lookups
294814560 good hits
 28947718 negative hits
   427213 bad hits
        0 false hits
  8344272 miss
   427013 too long
  1668520 pass2 hits
  1804646 2passes
          cache hits (88% pos + 8% neg) system 0% per-process
          deletions 0%, falsehits 0%, toolong 0%

Device      512-blocks     Used    Avail Capacity  Priority
/dev/wd0b      8388608     8256  8380352     0%    0

[KERNEL VIDEO SUB-SYSTEM LOGS]
[     1.000000] ehci0 at pci0 dev 16 function 2: VIA Technologies VT8237 EHCI USB Controller (rev. 0x63)
[     1.000000] wm0 at pci0 dev 17 function 0: Intel i82546EB 1000BASE-T Ethernet (rev. 0x01)
[     1.000000] wm1 at pci0 dev 17 function 1: Intel i82546EB 1000BASE-T Ethernet (rev. 0x01)
[     1.000000] wskbd0 at pckbd0: console keyboard, using wsdisplay0
[ 406887.735102] wskbd1: connecting to wsdisplay0
[ 406888.176507] wskbd2: connecting to wsdisplay0
[ 406888.578848] wskbd3: connecting to wsdisplay0
[ 407059.616668] wskbd1: disconnecting from wsdisplay0
[ 407059.653710] wskbd2: disconnecting from wsdisplay0
[ 407059.674286] wskbd3: disconnecting from wsdisplay0
==================================================================

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->feedback
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Wed, 05 Aug 2026 18:11:02 +0000
State-Changed-Why:
Can you please provide

(a) output of dmesg,
(b) content of /var/log/Xorg.0.log

on working and non-working boots?  Or, if you can't get
/var/log/Xorg.0.log in a non-working boot, can you get
/var/log/Xorg.0.log.old on the _next_ boot?

> To resolve this, we present an exploit of the SRM console firmware
> environment parameters. By passing the 'boot -n' (non-interactive/
> no-video initialization parameters) from the SRM firmware, we
> intentionally insert a structural timing delay into the early OS boot
> sequencer.

How is this an `exploit'?  Where do you get the description
`non-interactive/no-video initialization parameters'?  Exactly what are
you passing where and how?  I don't have an Alpha system to test, but
according to the alpha/boot(8) man page
(https://man.NetBSD.org/alpha/boot.8), the syntax is:

     boot [-file filename] [-flags value] [device]

     Boot an operating system.  The default arguments for this command are
     taken from the SRM environment variables:

           boot_file     file name to bootstrap.
           boot_osflags  flags to pass to the secondary bootstrap program.
           bootdef_dev   default bootstrap device....
   SRM Variables
...
     boot_osflags    The flag passed to the secondary bootstrap program, and
                     the NetBSD kernel:
...
                     n     the NetBSD kernel will ask for the root file sys-
                           tem's device, the kernel core dump device, and the
                           path to init(8).

> 2. Configure the system to boot directly into a graphical Xorg
>    environment via /etc/rc.conf.

Exactly what do you mean by this?  Adding the line `xdm=YES' to
rc.conf?

If so, does creating a file /etc/rc.conf.d/xdm with the one line

	sleep 10

also have the same effect of making Xorg work?


From: "Jeffrey S. Worley" <technoid6502@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-alpha/60366 (port-alpha: SRM boot -n exploit to enforce
 wscons delay)
Date: Sun, 23 Aug 2026 01:07:15 -0400

 Passing the N parameter via SRM:

 >> boot -flags "n" dqa0

 The system will boot and ask for the root device and so forth.
 Just take the defaults and exit.  This artificial delay allows the card
 to settle.  Hardware, like the ramdacs on the card don't operate
 instantaneously, need a decent interval.

 This 'split-boot' delay only works on versions 8-9.4. =20

 Version 10 and up is completely broken for a framebuffer.

 My system presently runs 10.1 and has a cheap vga card in for console
 video (text only).  This stays within kernel and so works fine.

 The moment one introduces a framebuffer though, the system will crash
 at boot.

 I no longer have an installed 9.4.  If there is a need to test latter
 versions on alpha, I can make mine available.

>Unformatted:

Home	PR Database Search