I have it running ok currently on my asus laptop, currently at 4% of 16GB,
so it looks like it is a hardware problem.

CC: (none) => davidwhodgins
Resolution: (none) => WORKSFORME
Status: NEW => RESOLVED

Created attachment 12066 [details]
image of error message

https://en.wikipedia.org/wiki/Machine-check_exception

On my laptop, it completed the 1st check of all 16GB of ram with all tests in
27 minutes, with no errors detected before it started the second pass at which
time I pressed the escape key to reboot.

According to https://en.wikipedia.org/wiki/Machine-check_exception, a machine check exception indicates a hardware fault and can't be caused by software, so Dave is probably right, but I'd like to see if we can find out what's causing it.

From the screenshot I deduce that the fault is occurring when the application is probing the ACPI tables to determine how many CPU cores are available. I've uploaded a small test ISO ("memtest.iso") to the "testing" directory on the rsync server that just contains a version of PCMemTest with SMP detection disabled. Could you try that Ben, and see if it bypasses the fault.

Resolution: WORKSFORME => (none)
Status: RESOLVED => REOPENED
Assignee: bugsquad => mageia
CC: (none) => mageia

for some reason I cannot download the file

I tried mageiasync and myrsync

(In reply to ben mcmonagle from comment #5)
> for some reason I cannot download the file
> 
> I tried mageiasync and myrsync

In the preferences, did you change the Source from
rsync://isoqa@bcd.mageia.org/isos/mageia8-beta2/
to
rsync://isoqa@bcd.mageia.org/isos/testing/

I was able to download it using mageiasync. Don't forget to change the
Source back after downloading that one.

I used dorsync, which worked. But mageiasync wants an extra level of hierarchy. I've changed it now so it is in the testing/memtest directory.

Oops. Guess I looked to see what was on the server and tested mageiasync just
after it was changed.

(In reply to Martin Whitaker from comment #7)
> I used dorsync, which worked. But mageiasync wants an extra level of
> hierarchy. I've changed it now so it is in the testing/memtest directory.

thanks for the move.

ok, apart from booting straight into the memtest - ok, F1 and esc work as expected

thanks

PCMemTest is directly bootable from the BIOS, so there's no intermediate bootloader on that test ISO.

Seems likely to be an ACPI problem. Do you need to use any of noacpi/noapic/nolapic on the boot command line on that machine? If not, could you attach the output of 'journalctl -b' run as root on that machine so I can see what the Linux kernel found in the ACPI tables.

In any case, I'm adding a startup option to enable/disable the probe for additional CPU cores. I'll make it default to disabled, as that's the safe option.

(In reply to Martin Whitaker from comment #10)

> Seems likely to be an ACPI problem. Do you need to use any of
> noacpi/noapic/nolapic on the boot command line on that machine? 

no, it normally has no issues with defaults.

Created attachment 12068 [details]
journalctl -d as root output

I've added the option to enable/disable SMP by pressing F2 during the 5 second delay before the tests start running (if SMP is disabled, the ACPI probe won't be performed). I've also modified the ACPI probe code to match the order that Linux does it (and spotted and fixed a couple of bugs in the process). I've uploaded both 32-bit and 64-bit versions of the test ISO to the testing/memtest directory. Could you give them a try, Ben. Either should work for legacy boot, pick the appropriate version for UEFI boot. They work on all my machines (but then, so did the old version...).

both do work with CSM/legacy boot

machine will only boot 64 UEFI, and that tests ok too

F2 option works in both 32 & 64.

good to go?

Thanks Ben. I've pushed pcmemtest-1.4 to cauldron, so it will be fixed on installed systems and on the 8-rc ISOs when they are built.

Source RPM: (none) => pcmemtest-1.3

works mga8-rc

Resolution: (none) => FIXED
Status: REOPENED => RESOLVED