Re: port-alpha/60541: port-alpha: ATA stray IRQs, video fencing instability, and network buffer exhaustion under NetBSD 10.1 Multiuser

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR port-alpha/60541; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
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@localhost 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@localhost cc netbsd-bugs%NetBSD.org@localhost 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