NetBSD Problem Report #60541

From technoid@AlphaBox.Atari8us  Wed Aug  5 17:09:30 2026
Return-Path: <technoid@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 "YR2" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 8A3221A9245
	for <gnats-bugs@gnats.NetBSD.org>; Wed,  5 Aug 2026 17:09:30 +0000 (UTC)
Message-Id: <20260805170337.7815027EFA1F@AlphaBox.Atari8us>
Date: Wed,  5 Aug 2026 12:03:37 -0500 (EST)
From: technoid@AlphaBox.Atari8us
Reply-To: technoid@AlphaBox.Atari8us
To: gnats-bugs@NetBSD.org
Subject: port-alpha: ATA stray IRQs, video fencing instability, and network buffer exhaustion under NetBSD 10.1 Multiuser
X-Send-Pr-Version: 3.95
X-From4GNATS: "technoid@AlphaBox.Atari8us via gnats" <gnats-admin@NetBSD.org>

>Number:         60541
>Category:       port-alpha
>Synopsis:       port-alpha: ATA stray IRQs, video fencing instability, and network buffer exhaustion under NetBSD 10.1 Multiuser
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-alpha-maintainer
>State:          feedback
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 05 17:10:00 +0000 2026
>Closed-Date:    
>Last-Modified:  Wed Aug 05 18:05:01 +0000 2026
>Originator:     technoid@AlphaBox.Atari8us
>Release:        NetBSD 10.1
>Organization:

>Environment:


System: NetBSD AlphaBox.Atari8us 10.1 NetBSD 10.1 (GENERIC) #0: Mon Dec 16 13:08:11 UTC 2024 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/alpha/compile/GENERIC alpha
Architecture: alpha
Machine: alpha
>Description:
Severe bus synchronization and data fencing instability observed on 
AlphaStation XP900 hardware configuration running NetBSD 10.1 GENERIC 
multiuser baseline. 

The system regularly experiences ATA controller stray IRQs and catastrophic 
video controller synchronization failures during active I/O. The primary 
onboard/workstation video subsystem fails to stabilize due to missing or 
misaligned memory-mapped I/O (MMIO) fences. It appears that the machine-
independent (MI) driver layers fail to enforce native `bus_space_barrier()` 
or `alpha_mb()` execution constraints necessary to handle the EV6's highly 
aggressive, weak memory out-of-order execution model.

Completely germane to this core architectural fencing failure is a critical 
network buffer starvation issue. When standard TCP socket buffers are 
increased at runtime or initialized at boot, the kernel immediately deadlocks 
and throws a "No buffer space available" (ENOBUFS) error, despite the 
presence of 2GB of physical system RAM. Because the unified 10.x network 
allocator lacks explicit hardware memory-ordering fences on the Alpha port, 
the EV6 processor performs out-of-order memory allocations during socket 
creation. This corrupts the kernel's internal mbuf alignment metrics, 
instantly starving the network memory pool and knocking the Intel PRO/1000 
(wm0) interface offline.

To achieve system stability and maintain continuous uptime in a multiuser 
environment, the native workstation video subsystem (Gloria, Powerstorm) had to be bypassed entirely 
by installing a simple, generic unaccelerated legacy x86 PCI VGA card to serve 
as the system console head. 

>How-To-Repeat:
BOot an AlphaStation XP900 (EV6) with a native workstation display adapter 
   (such as TGA2/PowerStorm series) into NetBSD 10.1 multiuser mode.
2. Trigger concurrent disk I/O workloads alongside console terminal output.
3. Observe a flood of ATA controller stray IRQ traps in dmesg, quickly followed 
   by console video driver register corruption, memory fence lockups, or a hard 
   kernel panic.
4. Attempt to scale up TCP network windows (e.g. net.inet.tcp.recvspace=262144) 
   and observe instant socket buffer starvation (ENOBUFS).

>Fix:
The problem appears to stem from the modernization of MI frameworks in 10.x, 
where strict Alpha-specific memory ordering barriers were dropped or omitted 
during the unified network/storage memory allocation overhauls. 

Temporary workaround requires disabling native workstation 3D/2D video hardware 
and inserting a legacy PCI VGA adapter to isolate system console initialization.

A permanent fix requires auditing the Alpha machine-dependent (MD) bus_space 
layers to ensure strict memory-ordering barriers (`alpha_mb()`) are explicitly 
enforced before and after MMIO read/write blocks on shared 32-bit PCI buses.

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->feedback
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Wed, 05 Aug 2026 18:03:22 +0000
State-Changed-Why:
feedback requested


From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Cc: 
Subject: Re: port-alpha/60541: port-alpha: ATA stray IRQs, video fencing instability, and network buffer exhaustion under NetBSD 10.1 Multiuser
Date: Wed, 5 Aug 2026 18:02:21 +0000

 [+bcc Technoid6502@gmail.com based on similarities to PR 60366 in case
 that was the submitter's address]

 > Date: Wed,  5 Aug 2026 12:03:37 -0500 (EST)
 > From: technoid@AlphaBox.Atari8us

 Does the submitter have a real email address for replies?  If you find
 this via the mail archive or gnats web site, can you please follow up
 to gnats-bugs@NetBSD.org cc netbsd-bugs@NetBSD.org with subject line
 `Re: port-alpha/60541' with an email address we can reply to?

 I'm having a hard time understanding many things in this message and
 it's heavy on broad speculation but very light on specific evidence or
 observations.  Did you use an LLM to write this, or to assist in
 translation from your native language?  (Using an LLM to assist in
 translating from your native language is fine as long as you disclose
 it, but please don't send us LLM-generated speculation in lieu of
 writing a message you understand yourself.)

 > Severe bus synchronization and data fencing instability observed on
 > AlphaStation XP900 hardware configuration running NetBSD 10.1 GENERIC
 > multiuser baseline.

 Are you saying:

 1. This hardware worked fine in 9.x, but stopped working in 10.1?

    If so, can you bisect to find what version started having problems?

    From the symptoms I think you're describing, you can probably just
    boot newer kernels on a working 9.x userland -- we generally ensure
    older userlands work fine on newer kernels.

 2. 10.1 worked fine on this hardware in _single-user_ boot with heavy
    disk I/O and console output, but fails on this hardware in
    _multi-user_ boot with the same heavy disk I/O and console output?

 Can you provide the dmesg output on the affected hardware under the
 most recent working version you tested, and under 10.1?

 >                                                              The primary
 > onboard/workstation video subsystem fails to stabilize due to missing or
 > misaligned memory-mapped I/O (MMIO) fences.

 What is a `misaligned MMIO fence'?

 >                                             It appears that the machine-
 > independent (MI) driver layers fail to enforce native `bus_space_barrier(=
 )`
 > or `alpha_mb()` execution constraints necessary to handle the EV6's highly
 > aggressive, weak memory out-of-order execution model.

 bus_space_barrier is only relevant (on any platform) for mappings that
 either:

 (a) are mapped into kva with BUS_SPACE_MAP_LINEAR and accessed through
     normal memory operations instead of bus_space_read/write_*,
 and/or
 (b) are mapped with BUS_SPACE_MAP_PREFETCHABLE.

 Pretty much only framebuffer drivers use these.  It's possible that
 the driver for yours (tga(4)?) is missing some bus_space_barrier
 calls.

 > The problem appears to stem from the modernization of MI frameworks in 10=
 .x,
 > where strict Alpha-specific memory ordering barriers were dropped or omit=
 ted
 > during the unified network/storage memory allocation overhauls.

 What changes are you referring to?  Can you please point to specific
 commits or specific diffs between netbsd-9 and netbsd-10?

 Every bus_space_read/write_* in alpha, as far as I can tell, is issued
 with alpha_mb, and this hasn't changed in a looooong time:

 https://nxr.netbsd.org/xref/src/sys/arch/alpha/pci/pci_bwx_bus_io_chipdep.c=
 ?r=3D1.24#566
 https://nxr.netbsd.org/xref/src/sys/arch/alpha/pci/pci_bwx_bus_mem_chipdep.=
 c?r=3D1.30#536
 https://nxr.netbsd.org/xref/src/sys/arch/alpha/pci/pci_swiz_bus_io_chipdep.=
 c?r=3D1.45#640
 https://nxr.netbsd.org/xref/src/sys/arch/alpha/pci/pci_swiz_bus_mem_chipdep=
 .c?r=3D1.50#972

 Are you referring to this change to replace extent(9) by vmem(9) for
 bus space allocation?  This doesn't affect any paths that actually
 issue reads and writes to hardware registers; it only affects the
 bookkeeping logic of which subsets of bus space are in use by drivers.
 And it doesn't appear in the netbsd-10 branch at all.

 https://mail-index.netbsd.org/source-changes/2023/12/04/msg148732.html

>Unformatted:

Home	PR Database Search