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

[+bcc [email protected] 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: [email protected]

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 [email protected] cc [email protected] 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 omitted
> 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=1.24#566
https://nxr.netbsd.org/xref/src/sys/arch/alpha/pci/pci_bwx_bus_mem_chipdep.c?r=1.30#536
https://nxr.netbsd.org/xref/src/sys/arch/alpha/pci/pci_swiz_bus_io_chipdep.c?r=1.45#640
https://nxr.netbsd.org/xref/src/sys/arch/alpha/pci/pci_swiz_bus_mem_chipdep.c?r=1.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