On Sun, Apr 09, 2000 at 12:31:22PM +0200, Tobias Ernst wrote:

 > 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. 

...

 > 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?

Debian, booted via SRM+aboot, *IS* using the genuine OSF/1 PALcode, the
same that NetBSD is using.

 > 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 can.  In fact, there is no other reason to suspect anything other than
an operating system software bug.

One thing, tho, you might try changing your program to use "/dev/rsd0c"
on NetBSD, as using "/dev/sd0c" will cause NetBSD to use the buffer cache
to do I/O to the disk, which might change how the test behaves (i.e. if
a block is cached, it's not going to be read from the disk, thus you might
not see the bogus data).

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>