On 3/20/26 16:40, John Paul Adrian Glaubitz wrote:
On Fri, 2026-03-20 at 15:12 -0400, Dennis Clarke wrote:
I downloaded the debian-5010-alpha-CD-1.iso from here :
https://cdimage.debian.org/mirror/cdimage/archive/5.0.10/alpha/iso-cd/
Things did not go so well :
Looks pretty normal to me.
(...)
...
FWIW, you have a non-BWX CPU [1], so the very latest ISO images from Debian
Ports
won't work at the moment.
Adrian
[1] https://en.wikipedia.org/wiki/DEC_Alpha#Model_history
Actually all of Linux is now pushed off the table. Due to the decision
to remove support for these old DEC Alpha processors. With good reasons.
See :
https://lore.kernel.org/lkml/[email protected]/T/#m48242a03ae584715edb4274247b2fbcd3d104ef3
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036158
Also some thoughts from Linus are posted below.[1]
It runs OpenBSD just fine and I have seen no reason to think the OpenBSD
kernel folks have any issues with the strange Total Store Order byte
access problem. Either that or no one cares about the overhead needed.
So until I have a newer unit on hand I will just be happy with OpenBSD.
--
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
greybeard and suspenders installed
[1] with regards to dropping the EV5 and early DEC Alpha processors
I have some bad news for you: the old alpha CPU's not only screwed up
the byte/word design, they _also_ screwed up the
load-locked/store-conditional.
You'd think that LL/SC would be done at a cacheline level, like any
sane person would do.
But no.
The 21064 actually did atomicity with an external pin on the bus, the
same way people used to do before caches even existed.
Yes, it has an internal L1 D$, but it is a write-through cache, and
clearly things like cache coherency weren't designed for. In fact,
LL/SC is even documented to not work in the external L2 cache
("Bcache" - don't ask me why the odd naming).
So LL/SC on the 21064 literally works on external memory.
Quoting the reference manual:
"A.6 Load Locked and Store Conditional
The 21064 provides the ability to perform locked memory accesses through
the LDxL (Load_Locked) and STxC (Store_Conditional) cycle command pair.
The LDxL command forces the 21064 to bypass the Bcache and request data
directly from the external memory interface. The memory interface
logic must
set a special interlock flag as it returns the data, and may
optionally keep the
locked address"
End result: a LL/SC pair is very very slow. It was incredibly slow
even for the time. I had benchmarks, I can't recall them, but I'd like
to say "hundreds of cycles". Maybe thousands.
So actual reliable byte operations are not realistically possible on
the early alpha CPU's. You can do them with LL/SC, sure, but
performance would be so horrendously bad that it would be just sad.
The 21064A had some "fast lock" mode which allows the data from the
LDQ_L to come from the Bcache. So it still isn't exactly fast, and it
still didn't work at CPU core speeds, but at least it worked with the
external cache.
Compilers will generate the sequence that DEC specified, which isn't
thread-safe.
In fact, it's worse than "not thread safe". It's not even safe on UP
with interrupts, or even signals in user space.
It's one of those "technically valid POSIX", since there's
"sig_atomic_t" and if you do any concurrent signal stuff you're
supposed to only use that type. But it's another of those "Yeah, you'd
better make sure your structure members are either 'int' or bigger, or
never accessed from signals or interrupts, or they might clobber
nearby values".
Linus
