[cctalk] Re: DEC Alpha EV6 (Tsunami) PCI pbus cohere. (oops, correction to text)

X DOES RUN, just fine.  There's a little glitch with Xorg's keyboard matrix that drops the w an r key at times..  It covers all attached keyboard and all keyboard attached after the fact.  A restart of X cures the fault for a time. After you have finished the suggested cohere protocol, X will run.  All you need do is provide the required delay via passing the '-if n' parameter to the kernel at boot time or by whatever other method you devise.  It wouldn't be hard, but the machine is busy right now compiling.... I'm sorry that the text could be construed to read that 'X won't run' On Wed, 2026-06-24 at 04:03 -0400, Jeffrey S. Worley wrote: > 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)