Bug 437701

The above was true also for memtest included on 20080329 images.
Running on my hardware memtest binaries from x86_64 and i386 images
(no idea what is the real difference but files are definitely not the same)
produces right away around 70 thousands errors and terminates with
an "Unexpected Interrupt  Type: Divide".

Morever if replaced with binaries from www.memtest.org (an unpacked
http://www.memtest.org/download/2.01/memtest86+-2.01.bin.gz
will do just fine) memtest-2.01 runs without any issues.  These
executables are still different.  Not the same compiler?

I just tried memtest (v2.01) from the F9beta DVD, it fails after in the first
20 seconds on all machine that I have tried it on.  I grabbed memtest v2.01
from the web, burnt a CD and it runs without problem.

Sounds like the gcc-4.3 might be miscompiling.

http://people.redhat.com/wtogami/temp/memtest86+-2.01-2.fc8.i386.rpm
Could you please test this one, which is the same version, built using F8's
compiler?

> http://people.redhat.com/wtogami/temp/memtest86+-2.01-2.fc8.i386.rpm

I let this one to run through one full pass on the same hardware
as previously used for comment #1.  No issues were reported.

That memtest binary is still different from any other one I collected
so far. :-)

That version (memtest86+-2.01-2) works fine, thanks.

(In reply to comment #3)
> Sounds like the gcc-4.3 might be miscompiling.
> 
> http://people.redhat.com/wtogami/temp/memtest86+-2.01-2.fc8.i386.rpm
> Could you please test this one, which is the same version, built using F8's
> compiler?

Yes, this version works fine.  No errors through a full test.

Reassigning to gcc.  If they are unable to fix this before Fedora9 then we'll
use one of the alternative compilers to build this for release.

That's premature.  It is far more likely a bug in the package rather than GCC,
so before reassigning to GCC you need to prove the bug is in GCC rather than the
package, or at least cut it down to a small self-contained testcase.
Try building it with different options (e.g. replace -O2 with -O2
-fno-strict-aliasing, or -O0), if one of these work, do a binary search between
the -O2 and other option .o files to see which compilation unit is problematic,
then try to narrow it down to a particular routine, gather what argument it is
being called with and create self-contained testcase where main prepares
whatever necessary, calls that routine with the right arguments and stub any
functions the problematic function calls.
The fact that it happens to work with gcc 4.1 and doesn't with 4.3 is not a
proof there is a compiler bug, it more probably is a package bug, which just
didn't show up with the older gcc (think of e.g. aliasing violation, using
uninitialized memory, etc.).

I can reproduce the problem using qemu, which makes testing the
problem _much_ easier.  Because of an apparent floppy emulation bug
in qemu I had to use the cdrom iso image:

    qemu -cdrom mt201.iso

Let me know if you need help find the bug.

Pat
---

Warren, are you going to get to the things Jakub suggested before the final
freeze?  It would be nice to have a working memtest and avoid the bugspam for F9...

http://koji.fedoraproject.org/packages/memtest86+/2.01/3.fc9/
Please test this build.

Works okay.

(In reply to comment #11)
> http://koji.fedoraproject.org/packages/memtest86+/2.01/3.fc9/
> Please test this build.
> 
Works fine.

memtest86+-2.01-3.fc9 binaries, both i386 and x86_64, are working AFAICT.

Works okay with the Rawhide 20080404 snapshot.  Thank you.

I noticed on my ThinkPad T61 that I was getting tons of errors from the memtest.
 Eventually, memtest walked all over some video memory or perhaps other mmio
regions and corrupted the display, hung the computer, etc.  I'll give the above
build a try.