Re: Possible IDE corruption bug?

[Jason Thorpe <thorpej%me.com@localhost>]

> On Oct 27, 2026, at 2:24 PM, Jeffrey S. Worley <technoid6502%gmail.com@localhost> wrote:
> 
> I do know that the driver for onboard ata on webbrick and slate works
> more and more reliably as you regress the OS release versions.  At
> version 8 is it almost useable.  With 10 it is nearly unuseable and
> with 11 it is completely unuseable.
> 
> The driver hasn't changed, but structural changes in the operating
> system alter its timing, exacerbating race conditions which existed
> prior but with more benign symptoms.

But that has absolutely *nothing* to do with “fencing” or “barriers” as you asserted in your previous message.  That’s because the Alpha implementation of the bus_space(9) interface inserts the barriers on every PIO access, and has done for decades (plural).

<snip>
static inline uint8_t
__C(CHIP,_io_read_1)(void *v, bus_space_handle_t ioh, bus_size_t off)
{
        register bus_space_handle_t tmpioh;
        register uint32_t *port, val;
        register uint8_t rval;
        register int offset;

        alpha_mb();          <===== OH HEY!

        tmpioh = ioh + off;              offset = tmpioh & 3;
        port = (uint32_t *)((tmpioh << CHIP_ADDR_SHIFT) |
            (0 << CHIP_SIZE_SHIFT));
        val = *port;          rval = ((val) >> (8 * offset)) & 0xff;

        return rval;
}
.
.
.
static inline void
__C(CHIP,_io_write_1)(void *v, bus_space_handle_t ioh,
    bus_size_t off, uint8_t val)
{
        register bus_space_handle_t tmpioh;
        register uint32_t *port, nval;
        register int offset;

        tmpioh = ioh + off;
        offset = tmpioh & 3;
        nval = val << (8 * offset);
        port = (uint32_t *)((tmpioh << CHIP_ADDR_SHIFT) |
            (0 << CHIP_SIZE_SHIFT));
        *port = nval;
        alpha_mb();          <===== OH HEY!
}
</snip>

> The worlds fastest single-chip processor has been running PIO mode 4
> with errors as below, for decades.
> 
> Over the course of time NetBSD has slowly foreclosed the onboard ATA
> controllers, driving users to SCSI or nothing.

That’s a strange thing to say.  I’m using the on-board ATA on my DS10L.  It works just fine.

    https://dmesgd.nycbug.org/dmesgd?do=view&id=8858

> Other machines, TSO machines like Sparc and Intel work fine with this
> chip.  
> 
> The fellow asked for help and I have been down his road before.  I can
> save him four years of forensic detective work.
> 
> The Driver is broken and has been since day one.

Which specific controller driver are you referring to?  Different Alpha models had different controllers each of which had different sets of errata that applied to them.  My DS10L has an Acer Labs controller revision that has a specific problem with certain DMA modes, for example.

> This is not normal, and has existed through decades of reports from us
> about it, and the above is a modern representation of the results of
> that relationship.

Can you point to specific bug reports in the NetBSD bug database?

-- thorpej