New subject: DEC Alpha EV6 (Tsunami) PCI pbus cohere. (oops, correction to text)

24 Jun 2026

NetBSD 9.2 and a lot more will now work on Alpha EV6 using a newly
discovered PCI bus cohere protocol involving a couple of SRM commands
and reboots to accomplish whenever the contents of the card cage has
been physically modified.
Here's what I've found:
The Tsunami's bus is reconciled with the PCI bus via a bitsieve, a
matrix stored in undocumented non-volatile memory somewhere on the
board, Pchip most likely.
Triggering a bus-scan with PFREFETCH_MODE enabled just spams the PCI
bus with speculative reads and never gives the cards a voice.
Nothing good is generated and that nothing good is stored in pchip.
This is familiar behavior for the past 30-ish years.
After PREFETCH has been disabled, an attempted boot of the target
operating system, NetBSD 9.2 fails in the expected way, with a Black
Screen of Death at the moment WSCONS is robbed of the framebuffer for
Xwindows. This is the only netBSD problem and it can be resolve with a
simple workaround which separates those two events by some time,
however brief ( a second would do, a tenth ).
The kernel parament 'n', passed via the boot -if n dqa0 command in the
SRM puts Netbsd in a mode convenient to us, as the framebuffer is
initialized as-such (see how nice the text is!) and has had time to
settle.  When we take the defaults and 'exit', the process completes to
an XDM login and a desktop.  I believe DEC intended this to allow NT
boots under odd circumstances and did not delete the feature, leaving
us a backdoor to boot our operating systems with the machines full
cooperation.
I believe (without testing the method with other than the video card
very thoroughly) that other cards may be positively affected by this
new-found ability to cohere the bus: Sata/Pata cards (Please God!), and
other commodity cards which otherwise would not work.
Why do SCSI cards always work no matter what?  The reason is that these
premium cards already know themselves quite well and operate at a
higher-level on the bus.  They are immune from the storm coming through
the broken bitsieve, basically establishing a fixed mode without
negotiating?
The Promise ATA133, for example, ought to work, but it is shouted-down
by the mess through the wrong sieve and craps out to pio mode 4.  I
think, and I will test, that cohering the machine after installing this
card may give me a fast and reliable (Cheap) local storage.
Why doesn't the onboard ata controller ever really work?  It is not
really on the PCI bus, but is rather sort of in-between the Tsunami and
PCI on an ISA bridge and so cannot benefit by a probe.  I believe the
drivers for NT, VMS, and TRU use specific driver tweaks to accomplish
stable performance at UDMA speeds on this commodity chip.
The alterations to fix the boot process are trivial, it isn't and never
really has been a NetBSD problem, nor OpenBSD.
Go ahead and cohere your Alpha's bus by:
Install NetBSD 9.2 with the full installation, enable XDM if you want.
It won't run X.  We knew that, but the process allows the bus to be
probed without prefetch confusing everthing.
Enter SRM.
Alphabox>>> set pci_parity off
Alphabox>>> set prefetch_mode off
Alphabox>>> init
let the boot proceed to the familiar Black Screen of Death.
Reset the machine and re-enter the SRM
Alphabox>>> set prefetch_mode on
Alphabox>>> init
The machine is permanently configured with the new bitsieve generated
by the probe we just conducted.  You will not need to modify these
again unless you makes some hardware change in the card-cage.
If you have an Ev6 in the closet, now's the time to drag it out and
reclaim its glory.  This fix allows prefetch to work the way it was
designed to, with tremendous performance benefits, and with the proper
sieve in place, strange things will no longer occur.
I have not tested as yet, but I believe that with this cohere in place
on your macine, and using a similar mechanism to allow the video card
time to settle, OpenBSD 5.9 and/or 6.0 should run, even though no one
ever saw X on them before, you can today.
Why did the oldest versions of NetBSD, OpenBSD, and Linux work in
Xwindows just fine?  I am guessing, but given that DEC had no possible
interest in helping anyone do this (Evidence all of HISTORY), these
three teams had no real choice but to slavishly emulate the boot
process in every way they could, not knowing which emulated
eccentricity was the actual key.  It worked, but no one outside of DEC
could know why.
When the Openbsd/Netbsd/freebsd teams got new members, changed tools,
rebuilt anew, at some point they forgot why the code was so strange and
obviously inefficient.  It should have been a clue, but they instead
'streamlined and optimized'-away the CAREFUL TIMING and they wiped away
another thing that I think was probably once done by Tru, NT, VMS,
OBSD, FBSD, and NBSD, all.  I think they blindly passed something to
Pchip, a key bitsieve or a special command to probe without prefetch
and then go back as we are doing manually via SRM.  Whatever the
mechanism was, it was not seen as such and removed, breaking X then.
Regression would show what worked, but it would never tell you why
without a terrific forensic effort involving long and unfettered access
to the actual, known-good vintage iron.
Best Regards,
Technoid Mutant
(Also Known as The Technoid and as Technoid6502)