Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Bill Bogstad wrote: > ...boot both CDs and run the CD integrity check > that is typically available on Ubuntu CDs I had the same thought, but hadn't gotten around to trying it. I've since booted the 12.10 CD on the hardware in questions, as well as on another machine, and ran the integrity test, which passed in both places. (I didn't bother testing the 12.04 CD, as it worked.) I'm assuming it tests the full CD, including the memtest86+ executable. Lets see... % cat boot/grub/loopback.cfg [...] menuentry "Test memory" { linux16 /install/mt86plus } % fgrep mt86plus md5sum.txt 1cc6be61a3c1605eeaf4b635e782c6bb ./install/mt86plus So it does appear to be included. > You could try doing a checksum (md5sum perhaps?) of > the memtest86 binary from both CDs to see if they differ. Yes. For good measure, lets compare the sha256 of the two versions: % sha256sum install/mt86plus 954a63241537f15373889f5d17f84a0b8385b0c218e5034b238655a96744a81e install/mt86plus % sha256sum install/mt86plus 13f714c5d4b870a4e4cd65089ed65ce1c8f2f4bb277f7dce73f36ca465404ec0 install/mt86plus So they are in fact different binaries, despite both showing the same version number in the UI. (The 12.04 md5 hash, as you'd expect, is also different: % fgrep mt86plus md5sum.txt e8ddd2897e15d799a2420c8ccae23faa ./install/mt86plus ) So it would seem the version on the 12.10 disk is either intentionally altered in some way, or was corrupted before the md5 was generated. The answer is actually pretty easy to find...a quick search for "memtest" on Launchpad turns up: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/1071209 Nizamov Shawkat wrote: Trying to check the memory at newly bought notebook I found a bug in the memtest86+ version 4.20 in ubuntu 12.10, in ubuntu 12.04 it is ok. The bug is reported at least in Fedora and Opensuse. It is assumed that the bug is caused by the gcc-4.7. It is easily reproducible - select the test #7 in memtest or just wait till it - starting from the 129Mb it will report a lot of errors. --- Duwe (duwe) wrote: The bug is triggered by a different register allocation. gcc-4.6 uses ebp for the volatile ulong *start (remember, -fomit-frame-pointer), where gcc-4.7 prefers ecx. ECX is, AFAIK "caller-save" by the ABI calling convention; and the asm inline calls rand(), which it does not declare. Rand() is free to clobber ecx. --- Corax2-05 (corax2-05) wrote: I bought a new RAM and a new board because of this damn bug. --- Lynara Le'dominae (lynarasys) wrote: Bought two new sticks of RAM... --- Dan Cundiff (pmotch) wrote: I tried many different combinations and encountered the error each time...I even went and bought new ram... I tried memtest+ from an older 12.04 DVD I had around and there wasn't an error. Shook my fist in the air very rapidly. --- ofb (cottlestonpie) wrote: This really needs to be on the 12.10 Release Notes by now. We've got a Red Hat report of it as early as March. --- 2012-12-06 This bug was fixed in the package memtest86+ - 4.20-1.1ubuntu3 I guess I'm lucky that it only cost me some time. Fun. (The 12.10 release notes: https://wiki.ubuntu.com/QuantalQuetzal/ReleaseNotes/UbuntuDesktop still don't mention this.) Rich Pieri wrote: > 32-bit version vs. 64-bit version? Is there such a thing as a 64-bit version of memtest86+? Jerry Natowitz wrote: > I'm actually partial to the "old" memtest86: http://www.memtest86.com/ > The 4.0 version will run most tests multi-threaded on multi-CPU/core > systems. So that's the non-plus version? I got the impression that it was no longer maintained, though I guess that doesn't matter, if it was actively developed back when the hardware being tested was produced. The memtest86+ site suggests that the code is pretty intimately linked to the chipset, and that they've gone to some lengths to minimize the impact of caching. It gives the impression that the plus version should generally be superior. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |