Subject: Re: disk i/o linux vs netbsd
To: UUCP <email@example.com>
From: Jason R Thorpe <firstname.lastname@example.org>
Date: 04/17/2000 08:11:47
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 <email@example.com>