V5 beta feedback - problems

[Bandit]

new beta feedback

We put out a new beta release today that should address some of the issues.
Here is a list of issues you raised and current state,

Issue #2: Main ram benchmark is reporting bigger numbers compared to V4
Looks like this was a bug. It should be corrected in the new beta.

No correction/difference on my machines.

Issue #3: Missing second XMP profile.
As best we can see in the log the second profile is disabled in the RAM itself. Needs independent checking with another utility (see above).

Now memtest reports the ram on the test screen as ECC (it is not)

Issue #4: Progress bar behaviour
We have changed this in the new release.

THANK-YOU!!! MUCH preferred.

Issue #5: False positives text
This was some text we added back in V4. On a very small number of machines, multi-threading would give false positives. For the moment we'll leave the text in place. But if we don't see it on any UEFI machines we can eventually remove it.

It did give errors on my machine, but is it a BIOS problem or an actual ram problem?
Usually the reported ram errors would not occur when using only 1 CPU, unless I was overclocking beyond limits.

Issue #6: Lockups / freezes when switching tests
Looks like this is a firmware issue as best we can see. The lockup occurs inside a firmware call to force a CPU switch to a new CPU. If this theory is correct, you would never see a lockup when running on an individual CPU without rotation or threading.
We are going to put in a bit more debugging code anyway, so there should be a bit more detail in future debug logs for us to look at.

OK, running the new beta right now so will let you know.

Issue #7: CPU clock speed not reporting correct value when overclocking
MemTest86 was originally coded in the days before CPUs had 'turbo' mode and unclocking power saving modes. So the code is a bit ignorant as to these features. For example we only report a single clock speed, but we really should be reporting a base clock speed and a turbo clock speed, as either or both might be overclocked. Correctly detecting both these clock speeds across all CPU types is tricky. Doubly so, when you don't have an operating system, but do have buggy firmware to deal with. Anyway, we'll see if it is possible to include both clock speeds.

I like how the CPU core temp is now showing. Thanks. I was going to suggest it.
I see you have removed v4.2, and v4.1 options.
And it seems like this new V5 beta sure is a lot larger in size (200Mb?).

Issues - it used to be that when exiting Memtest V5, it would then automatically go to V4. Now it does not. Often, but not always, it actually just exits (black screen for ~1sec) then immediately goes to the Info screen of Memtest v5.
Now it seems I have to use the boot option on the BIOS boot screen.
And on that issue - my BIOS with 256Mb USB key shows 3 possible boot options:
- just the key (must be legacy mode) which boots into v4.3
- UEFI '1' which goes into v5
- UEFI '2' which seems to give a slightly different v5 screen

[keith]

Thanks for that. We'll have a look at the issues and address them in the next release. If you can send the log file for the new release to our e-mail it would be helpful as well, thanks.

[jesselin68]

Could you please tell me How to put the USB flash drive back to normal after I created a Memtest86 Beta5 UEFI USB flash drive by ImageUSB?
I have tried "Diskpart" and "HPUSBFW". but NO luck.
please help!
Any suggestion will be appreciated
Jesse

[keith]

Could you please tell me How to put the USB flash drive back to normal after I created a Memtest86 Beta5 UEFI USB flash drive by ImageUSB?
I have tried "Diskpart" and "HPUSBFW". but NO luck.
please help!
Any suggestion will be appreciated
Jesse

diskpart should be able to restore your USB drive back to its original partition structure

1. First select the USB disk. Be sure to select the correct one.

list disk

select disk <disk number>

2. Remove all partition/volume formatting on USB disk

clean

3. Create a partition

create partition primary

4. Format the partition to desired file system (eg. fat32, ntfs)

format fs=fat32 quick[COLOR=#333333][FONT=Arial]
[/FONT][/COLOR]

5. Assign the partition to a drive letter

assign[COLOR=#333333][FONT=Arial]
[/FONT][/COLOR]

You should be able to access the drive in Windows.

[Bandit]

update

Thanks for that. We'll have a look at the issues and address them in the next release. If you can send the log file for the new release to our e-mail it would be helpful as well, thanks.

''

log files emailed

USB drive still not recognized (in WInXPProx32SP3+)
FYI: In Linux reader it now shows 2 FAT16 Volumes on it

Suggestions:
- when saving test result logs, and ram spd info and system info logs, put the date/time not only in the log but into the filename and/or ad a 'v1' 'v2' 'v3' just before file extension so that previous logs do not get overwritten - like when it asks "Would you like to save a report to a file (Memtest86-TestReport.txt)? ((y)es)>"

- please number the beta so we know which is the most recent version e.g. V5beta1 V5beta2 both in the filename/archive, or at least in a readme.txt in the archive

Issues:
Freezes immediately when trying sequential CPU.
No longer freezing in parallel CPU mode.
Although actual CPU speed is not showing, main ram speed drops about 8000MHz when going from XMP profile to 1600MHz, so it is picking up some of the 'overclocking' now.
When using the e'X'it, the first time it always just restarts it in v5 mode. usually, but not always, after the 2nd e'X'it, it will go to v4.
v4.3.1 - when choosing parallel CPUs - it won't actually show using parallel CPUs, instead going to round-robin default.

In addition to this testing, what I'm actually trying to figure for my ram situation is if I have faulty ram. I've never had trouble with running any XMP ram at it's XMP profile (with or without CPU overclocking), but when running memtest in parallel CPU mode it gets ram errors, but not so in only single CPU modes (whether by round-robin, single, or sequential). I'm thinking parallel would more accurately reflect real world use.

[David (PassMark)]

USB drive still not recognized (in WInXPProx32SP3+)

We need to use GPT partitioning for UEFI. But Windows XP 32bit never supported GPT. Strangely enough XP 64bit does support it. So this might just have to be a restriction in V5. You need XP64bit, Vista, Win7 or 8, or Linux to read the drive. XP and 32bit have to die eventually. Hopefully there aren't too many people running new UEFI systems with 32bit XP.

system info logs, put the date/time

Yes, we'll start time stamping the file names.

please number the beta

Yes, in fact we had already done this for the next beta release (Beta 3, next week some time)

Freezes immediately when trying sequential CPU

Looks like the same issue as before with buggy UEFI BIOS getting locked up on a CPU switch. We don't know how widespread the problem is, so we might default to running on a single CPU for the moment.

When using the e'X'it, the first time it always just restarts

We have made some changes to the exit behavior in Beta 3.

in parallel CPU mode it gets ram errors

What are the details of the errors? Or can you post a screen shot.

[Bandit]

We need to use GPT partitioning for UEFI. But Windows XP 32bit never supported GPT. Strangely enough XP 64bit does support it. So this might just have to be a restriction in V5. You need XP64bit, Vista, Win7 or 8, or Linux to read the drive. XP and 32bit have to die eventually. Hopefully there aren't too many people running new UEFI systems with 32bit XP.

Sure, just trying to give updated feedback.
(Although I do still have a Win 3.1 and a Win98SE client Very 'senior' senior citizens who just play solitaire and minesweeper and think they are 'programming' or 'on the internet')

Looks like the same issue as before with buggy UEFI BIOS getting locked up on a CPU switch. We don't know how widespread the problem is, so we might default to running on a single CPU for the moment.

Sure, just trying to give updated feedback and help solve the problem (you can't have every motherboard/ram'BIOS combo there to test can you?)

What are the details of the errors? Or can you post a screen shot.

In addition to this testing, what I'm actually trying to figure for my ram situation is if I have faulty ram. I've never had trouble with running any XMP ram at it's XMP profile (with or without CPU overclocking), but when running memtest in parallel CPU mode it gets ram errors, but not so in only single CPU modes (whether by round-robin, single, or sequential). I'm thinking parallel would more accurately reflect real world use.

OK, I'm emailing a bunch of pics as well as log files, ram tests, etc from the last days.
I would appreciate you ram errors, or not, advice.

You'll also be able to see in a screenshot that in MemtestV5beta2 it thinks the ram is ECC (it isn't although it would be nice if it is or was secretly so and Patriot just didn't list it).

Doesn't seem to matter if I overclock the CPU or not, although if I start getting crazy like at 5GHz then I would expect errors, but mostly I've been at stock 3.5GHz since I've been trying to determine if the ram errors are actual ram errors or errors in Memtest, or related to parallel CPU mode. Or is it all just this BIOS having issues.

Although I'll usually do a modest overclock if available, I *ALWAYS* want max stability before installing/using an OS.

An 'oddity' I've noticed is the speed of completion of of passes. It varies even when on the same sessions.

[David (PassMark)]

Our thought is that these single bit errors you have seen are probably real hardware errors.

We should have a new beta out to test either today or tomorrow.

[Bandit]

ram errors

Our thought is that these single bit errors you have seen are probably real hardware errors.

Thanks for your input.
I am finding it hard to determine if there is really a hardware ram error, or is it beta Memtest, or a faulty BIOS, or the CPU settings, or the BIOS settings, or the motherboard. Hence my questions, and focus on Memtest beta testing, as Memtest has always been a reliable testing determinant before.

If the errors were always the same, and the same memory location, and occured on the same test, etc, then I'd be convinced it is a ram fault, but it doesn't seem to consistent. Sometimes after a reboot and continuing the Memtest identically, the errors disappear, or new ones appear instead, or v4.3.2 shows some that v5 didn't, or vice versa.

Generally, me thinks the XMP profile should work fine at it's profile speed as that's what it's rated at. I don't think I should have to tinker with ram speed - but for a test I tried dropping the multiplier to 20 (to get the 'Enthusiast' PC16000-2000MHz that Emetest picks up but the motherboard profile does not) and got no errors, but I also did not run Memtest as many passes.

I generally avoid overvoltage, choosing whatever overclock I can get without raising voltage, but even so the XMP 2133MHz profile is supposed to be at the 'stock' 1.5V ram voltage. I wonder if I should try upping ram or some CPU voltage.

Your thoughts on above?
Or suggestions?

We should have a new beta out to test either today or tomorrow.

I'll look for it (don't yet see it - at least as the beta numbering system that was going to be implemented).