Hallo!

Does anyone know the details of the differencies on who NetBSD/Alpha
handles Disk I/O versus how Linux/Alpha does it?

I have written a simple program that does what the Linux "badblocks -w"
does: It opens a device like /dev/sda on Linux or /dev/sd0c on NetBSD
and writes the same byte value to that device until it is full. Then it
reads the device again and tests if it still sees the same byte value.

On my Multia/UDB running Linux, this test shows no problem if I use
0x00, 0x55 or 0xAA as byte value. It fails when I use 0xFF as byte
value, yielding to the average about 10 bytes per Gigabye that have
mystically changed their values. But on each run, those bytes are at
different locations and also their number is different. 

This happens no matter if I use a notebook IDE or an external SCSI
disk, and the same disks connected to an Intel PC don't show this
symptom. I have already equipped the Muttia with a really powerful fan;
and have tried both Redhat 5.2 booted via ARC+Milo, and Debian Potato
booted via SRM+aboot.

Now the really queer thing is that if I use NetBSD 1.4.2, the problem
does NOT show up (!). I have tested countless times, of course.

So I don't think it is a hardware failure any more. I can also exclude
a programming error, as I originally came to write this program because
the Linux badblocks utilitiy showed bad blocks, but others each time I
ran it.

So what is the difference? Perhaps the PAL-Code? Which leads me to the
question: Does Linux, booted via SRM+aboot, use the DEC SRM firmware
palcode like NetBSD does, or does it still use it's own Palcode like it
does when using ARC+Milo?

I still cannot believe Alphalinux has such a blatant bug!? Perhaps
Linux uses some part of my hardware which is faulty that NetBSD does
not use?

I have asked a friend who has also has a Multia to do this check, but
he could not reproduce my problem. On the other hand, he only had a 100
MB partition available and only tested 3 times.

As the real problem is not with NetBSD, but with Linux, perhaps you'd
rather answer via private mail and not to the list. I'll post the
solution to the list, should I ever find it.

Viele Gr=FC=DFe,
Tobias