If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

---------------
Please run this Beta on as many platform as possible and post a quick report (with a screenshot if possible), if you find any error or if all goes well.

Some tips about failsafe modes at startup :

- F1 : Enter global fail safe, with basic features only
- F2 : Toggle SMP. Will try to activate SMP on systems where SMP is disabled by default (Xeon, Opteron & Engineering Sample CPU) or will disable SMP on all other platforms.
- F3 : Hidden mode. Will use old MP Table instead of modern ACPI MADT Table for SMP initialization.

I've tried the beta on a MBP8,2 (early 2011) with 16GB of RAM. It seems to "hang". It only gets as far as the detection of the memory modules and then just sits there. Cannot exit or enter config.
I've tried pressing F1-F3 -- no improvement. Please see attached screenshot.

It seems Apple doesn't follow the established standards, one more time. The memory map is not filled correctly and Memtest86+ just try to access reserved memory marked as usable. I wrote an email to Apple dev support some months ago and their answer was "Apple computers are not PC compatible". Built with PC compatible components, but especially modded for not being "PC Compatible". It's a shame, but I don't know how to solve this issue : Apple doesn't publish the required technical informations. :-/

It seems Apple doesn't follow the established standards, one more time. The memory map is not filled correctly and Memtest86+ just try to access reserved memory marked as usable. I wrote an email to Apple dev support some months ago and their answer was "Apple computers are not PC compatible". Built with PC compatible components, but especially modded for not being "PC Compatible". It's a shame, but I don't know how to solve this issue : Apple doesn't publish the required technical informations. :-/

Sad but true. Unfortunately apples BIOS implementation is pretty poor, though it's only there for legacy compatibility for things like bootcamp. Have you considered making memtest work from EFI? BIOS won't be around much longer. I've tried running memtest from grub-efi, but it doesn't work because it uses 16bit mode. Is it possible to make it use the 32bit boot protocol?

The issue is not 16 or 32 bits boot protocol, the main issue is the numerous BIOS calls required to do the memory initialization. EFI is a nice idea, but the first time I heard "EFI will replace BIOS in the upcoming months !!!" was in 2002 at an Intel Developer's forum. 10 years after, UEFI replaced EFI but BIOS is still present in 99% of PC Motherboard. It's an hard task to build an EFI-readyMemtest86+, with massive code rewrite, and that version will not be compatible with legacy BIOS. I will not consider supporting two forks at the same time, so when Memtest86+ will switch to EFI, the BIOS version will be discontinued. When BIOS will be not be available in standard PC components, I'll start working on en EFI revision.

3 hours with no Crash (nearly one single Pass for 64GB ).
But: two single fails at 60GB (Test3) and 61GB (Test6). So I tried to isolate the corresponding DIMM.
The expected failing DIMM was used in a slot where I expect to see 8GB - 16GB range. So I adjusted the Tested Range from 10GB to 14 GB (expceted error at 12GB and 13GB ).
I somehow saw, that test3 was done VERY fast and I did not get any fail. So I wanted to go back to test all Memory. Hitting "0" to enable the new addressrange caused a direct reboot.
I know, that other configuration settings are broken (e. g. test or core selection), but this is not mentioned for the Address range setting.

Restarting in Safe mode and checking the behavior for Test3 showed the following:
- Test 1 runs fast, but one sees some pattern changes.
- Test 2, Test3, Test4 are just a single blink and next test executed is Test 5.
- Afterwards the testflow seems fine.

I would not expect that Tests 2,3,4 are that fast.
So If Test3 would not be executed it would be strange to get the fail on test3 when al 8 DIMMs are plugged in. Not sure how to interprete this obervation.

Best regards

Hermann

System:
MSI X79A-GD65 (8D) with a Intel i7 3930K, 64G RAM (BIOS 1.8 (beta)) (Sorry typed Gigabyte in the old message, but it is a MSI)

- Some tests are bypassed in SMP mode
- There is a bug with test numbers displayed in beta 1
- "All memory" in Address mode is broken. To be more precise, every option that require a test restart is broken and will reboot the PC.

About single fails, I would be really interested to see a screenshot.

PS : I think the final revision of Mt86+ 5.00 will have SMP disabled by default in all case.

The issue is not 16 or 32 bits boot protocol, the main issue is the numerous BIOS calls required to do the memory initialization. EFI is a nice idea, but the first time I heard "EFI will replace BIOS in the upcoming months !!!" was in 2002 at an Intel Developer's forum. 10 years after, UEFI replaced EFI but BIOS is still present in 99% of PC Motherboard. It's an hard task to build an EFI-readyMemtest86+, with massive code rewrite, and that version will not be compatible with legacy BIOS. I will not consider supporting two forks at the same time, so when Memtest86+ will switch to EFI, the BIOS version will be discontinued. When BIOS will be not be available in standard PC components, I'll start working on en EFI revision.

I understand that. Please see here: https://www.gnu.org/software/grub/ma...e/linux16.html
Seeing as Apple's BIOS implementations is so buggy, I was hoping that by using 32bit boot protocol I would at least be able to call it from grub-efi. That might give it a better chance of getting correct addresses for access.
Can we expect a code drop soon? Perhaps someone else would like to work on the EFI port...

I was using the .bin from grub.
I used unetbin to put the ISO on a USB but all I get is the unetbin (grub?) screen that says "default" but that doesn't run.
The time just resets so it probably isn't a bootable image.
I will try a cd later.

Test percentage counter seems to be a little bugged during Test #1: It already reaches 100% when address test is in progress on CPU #5 (out of 8 SMT cores total) somewhere between 10G and 20G in address range.

I have tried 5.00b1 on two different motherboards of the same model. Both of them will run without error for several passes, then experience an error in test 5. The error only seems to occur during test 5. Motherboard is an Asus M5A97, which has UEFI. Memory is Kingston ECC DDR3-1600. I am attaching 2 screenshots for your reference. Notice that the speed detection is inconsistent; one shows "741 MHz (DDR3-1482) - BCLK: 92" and the other shows "802 MHz (DDR3-1605) - BCLK: 100".

Can you tell me if I'm hitting a bug in the beta, or if I probably do have bad memory? I was able to run Memtest86+ 4.20 many, many times (over 20 runs) without any errors.

I have tried 5.00b1 on two different motherboards of the same model. Both of them will run without error for several passes, then experience an error in test 5. The error only seems to occur during test 5. Motherboard is an Asus M5A97, which has UEFI. Memory is Kingston ECC DDR3-1600. I am attaching 2 screenshots for your reference. Notice that the speed detection is inconsistent; one shows "741 MHz (DDR3-1482) - BCLK: 92" and the other shows "802 MHz (DDR3-1605) - BCLK: 100".

Can you tell me if I'm hitting a bug in the beta, or if I probably do have bad memory? I was able to run Memtest86+ 4.20 many, many times (over 20 runs) without any errors.

The error in test#5 at 0x13CF0 & 0x13CF8 is a bug in the code. It will be solved in the next beta. Did you get an error at another address ? It will help to get a screenshot.

I believe it was at 0x274f0 and 0x274f8, but I am not certain. I just started another run to see if I can duplicate the error. I will provide a screenshot as soon as possible. Thank you for looking into this.