Re: Possible IDE corruption bug?

["Jeffrey S. Worley" <technoid6502%gmail.com@localhost>]

The onboard ata driver is broken on NetBSD 11.  It is moribund on 10.1
and below.  It is unfenced, Alpha requires memory barriers for ordered
IO, the coder did not get that memo.

I boot my Alpha from the onboard ATA controller just to get kernel into
memory, then pivot to an SI3124 SATA controller.  It runs a
100meg@sec!, and is bulletproof.

If you need to keep the onboard ata controller as your primary disk,
use NetBSD 9.2.  That is the latest version on which the ATA controller
is useable for such and the last version with which I have succeeded in
running a local X session.

You can sure email me directly.  Also you can check "Technoid Mutant"'s
DMESG post at https://dmesgd.nycbug.org/dmesgd?do=view&id=9246

That list is my XP900 (ev6@466mhz).

My SATA solution way outperforms any SCSI solution available, is cheap
as dirt, uses commonly available modern ssd's...  It is not bootable.

What you can do is compile your kernel to DISABLE the IDE controller,
at least the Primary.  The SRM doesn't know BSD is ignorant of the
controller and will dutifully bootstrap the kernel in from it, kernel
will look for the first available controller and drive, find the
Sil3124 and assign it sd0 and continue the boot as though it had
actually loaded the kernel from there.  It is a split-boot, like a
netboot but faster and entirely local.  To get kernel in, I use a cheap
sata ssd with pata adapter.  The problem with the controller is
entirely in the BSD's, and so it doesn't really matter what you use,
even a physical cd.

OpenBSD is no better.  The driver is shared code and is horrible.  When
you get a 3124 controller in, you'll see how drivers make all the
difference.  The combination of a properly fenced driver and a well-
implemented busmaster really shines on this machine.

I would recommend the PCIx version of the controller, not knowing which
alpha you have...

The only other options are scsi.  I've installed a U320 scsi card and a
Bluescsi Ultra-Wide, getting a good 18meg@sec, but that compares not at
all to the Sil3124's 124meg@sec... I've gotten 40meg@sec with a real
fast-wide scsi drive, but that's for linear reads.  In a race, the
physical disk has you in the straights but gets clobbered in the
curves.  SSD has zero latency and disk's is comparatively glacial, so
even there the scsi emulator wins.

NEC USB is useable on Alpha, and the Intel Dual 100tx card is golden.

You can message me personally on facebook (I'm my own name), or in
email or here.  I'll be glad to help.

best,

jeff

On Mon, 2026-10-26 at 19:39 -0500, John Goerzen wrote:
> Hi folks,
> 
> I have an AlphaPC 164LX (600MHz 21164a, 256MB RAM).
> 
> This machine ran Linux many years ago, and I'm now repurposing it for
> NetBSD.
> 
> I downloaded the NetBSD 11.0 alpha ISO.  I successfully booted from
> it
> (boot dqb0 at SRM).  I partitioned the drive, selected "Full
> installation without X11", but I got the attached screen.
> 
> I went through, and HTTP installation from cdn.netbsd.org (via my
> Tulip
> NIC) was fine.  However, I didn't trust an un-authenticated download,
> so
> I tried it again.
> 
> Same thing.
> 
> This time, I opened a shell in the installer environment.  There were
> no
> I/O errors in dmesg.  I could mount the CD fine (I made a directory
> at
> /mnt3) and tried pointing the installer at that.  Same thing again!
> 
> I mounted the ISO on my file server and started a HTTP server over
> it,
> and pointed the installer at that.  It worked fine.
> 
> I verified the SHA512SUM of the downloaded ISO.  It matches.
> 
> So on my installed system, I again mounted the CD and sent into
> /cdrom/alpha/binary/sets and ran sha512 -c SHA512.
> 
> Now -- almost all of them are failing!
> 
> I tried copying xetc.tgz to my home directory.  I can scp the same
> file
> from another box into there from another box.  The scp'd file is
> fine,
> the copied one retains the bad hash from the CD.
> 
> I can compare them thusly:
> 
> alpha$ cmp -l xetc-real.tgz xetc.tgz
>   7953   0  10
>  10209 102 112
>  18607 100 101
>  25689 302 312
>  34102  33  37
> 
> In case there was a problem with the burn, I mounted the same CD on a
> Linux system and ran sha512sum -c SHA512.  All verify properly.  So
> it's
> not a bad burn.
> 
> Both the CD drive and the HDD are IDE devices, connected to the
> motherboard IDE.  I see this at boot:
> 
> [     4.110851] wd0 at atabus0 drive 0
> [     4.111829] wd0: <IBM-DTLA-305040>
> [     4.111829] wd0: drive supports 16-sector PIO transfers, LBA
> addressing
> [     4.112805] wd0: 39266 MB, 79780 cyl, 16 head, 63 sec, 512
> bytes/sect x 80418240 sectors
> [     4.114757] wd0: 32-bit data port
> [     4.114757] wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA
> mode 5 (Ultra/100)
> [     4.115733] wd0(cmdide0:0:0): using PIO mode 4, DMA mode 2 (using
> DMA)
> [     4.115733] atapibus0 at atabus1: 2 targets
> [     4.122570] cd0 at atapibus0 drive 0: <TOSHIBA CD-ROM XM-6302B, ,
> 1012> cdrom removable
> [     4.124524] cd0: 32-bit data port
> [     4.124524] cd0: drive supports PIO mode 4, DMA mode 2
> [     4.125499] cd0(cmdide0:1:0): using PIO mode 4, DMA mode 2 (using
> DMA)
> 
> This has the smell to me of a kernel bug. 
> 
> I don't really care about the CD now that it's installed, but I'm
> concerned about the implications.
> 
> Ideas?
> 
> Thanks,
> 
> John