While trying to figure out some quirky behavior with lvm2, I decided to make sure I wasn’t having a memory problem. Since I already had the openSUSE 12.2 KDE LiveCD in the drive, I decided to reboot from that and test my memory. The test resulted in errors. After trying multiple permutations of various memory sticks, I finally put in my Ultimate Boot CD Ultimate Boot CD - Download the UBCD and ran Memtest86+ V4.20 (the same as the openSUSE version) from there. 3 full passes (it takes a long time for a pass on 16 GB) with no errors.
So I went to the website Memtest86+ - Advanced Memory Diagnostic Tool and downloaded the gzipped pre-compiled bootable binary of version 4.20 of Memtest86+ from the source. After decompression, it was exactly the same size (164504 bytes) as the version on UBCD and the files compared without error.
Then I pulled the version from the openSUSE 12.2 KDE LiveCD. It wasn’t even the same size (176760 bytes) so I didn’t bother with a comparison.
After searching in this forum and seeing an old report of this issue https://forums.opensuse.org/english/get-technical-help-here/install-boot-login/478651-memtest-12-2-broken.html along with a bugzilla report https://bugzilla.novell.com/show_bug.cgi?id=773569 which claimed the the issue was resolved, I decided to check the i586 & x86_64 variants of the openSUSE 13.1 install DVDs. They also contained memory test programs which claim to be Memtest86+ V4.20, but they were also each 176760 bytes in size. Moreover none of the three files from the different openSUSE media would compare with each other and they all differ at the same location. Here’s a typical result:
> Then I pulled the version from the openSUSE 12.2 KDE LiveCD. It wasn’t
> even the same size (176760 bytes) so I didn’t bother with a comparison.
>
> After searching in this forum and seeing an old report of this issue
> http://tinyurl.com/lnbdjch along with a bugzilla report
> https://bugzilla.novell.com/show_bug.cgi?id=773569 which claimed the the
> issue was resolved,
…
> So-- DO NOT USE the memory test on any openSUSE install media until they
> REALLY fix this.
We know.
In openSUSE Bugzilla parlance, that a problem in the GM install media is fixed, means that it is
fixed on the next released version, ie, on 12.3. It does not mean that they will provide a new iso
image for 12.2.
The Bugzilla text mentions another Bugzilla (784757), that says that there is a notice on the
release notes and on the «on the “most annoying bugs” page in the wiki», both of which you should
have read. >:-)
Nothing more will be done, sorry.
On the other hand, 12.2 is obsolete.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))
> But you missed the part about also checking the i586 and x86_64 media
> for 13.1 (I hope THAT’s not obsolete already).
>
> And there’s nothing in the 13.1 Release notes (V13.1.9) or the “Most
> annoying bugs” for 13.1 about the memtest bug.
Ok, so you are saying that the 13.1 release also has that problem? A size comparison is not enough,
you have to check good memory and see if it says it is bad. Then you have to report the issue on a
new Bugzilla, not here.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))
OK, you got me there, I didn’t run the 13.1 memtest before. They both seem to run without error.
However, if what you mean by:
is that “the size doesn’t matter, because they were built from the same source and size differences are easily explainable by different compiler versions, etc.”
I would generally agree that this is true for higher level applications where the hardware is an abstraction managed by the underlying OS.
In the case of executable SW that needs to manipulate the hardware, like a device driver or a memory test utility, I couldn’t possibly disagree more.
I can’t begin to count the number of times over the past 25 years when I’ve been debugging a device driver to discover that the problem wasn’t due to bad code, but a result of overly aggressive optimization by the compiler, assembler and in a few cases, even the GNU link-loader. This is especially true when I try to build it myself (I did) and see a number of warning messages going to STDERR about a “variable is set but not used”. All too often, that’s the result of a particular bit pattern that’s supposed to be written to a control register. If that get’s removed by overly aggressive optimization, the code may still run error free, but it’s not doing what it’s supposed to do.
Couple that with the note in the README file which states that the developer has included a pre-compiled binary in with the source code in the event of build problems and I tend to be very suspicious of files which don’t compare with those provided by the developer.
You may choose to trust that the memtest code in the install media runs exactly like the code provided by the developer, I choose not to do so.