V5 beta feedback - problems

[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).

[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]

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)]

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]

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.

[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.

[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]

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.

[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

[David (PassMark)]

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 #1: CPU mode effects the bandwidth benchmark
We don't think this is possible. Any variation in measurements is more likely just random variations.

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.

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).

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

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.

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.

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.

[David (PassMark)]

Some other things I've noticed in v4.3 - when running a test, it doesn't respond to keyboard

There are a bunch of problems with USB keyboards in V4.x.
A USB keyboard working depends on the BIOS correctly emulating old PS/2 style keyboards. Not all BIOSs do this, or it properly. New Macs don't do it all all for example. So you'll never be able to run DOS on a new Mac.

The problem should disappear in V5 as USB is directly supported. No emulation is required anymore.

choosing a different CPU test mode (single core vs parallel vs etc) causes a little ram speed change

It shouldn't make any change. Might be just random fluctuations.

Changing CPU multiplier all the way from 35 stock to 50 overclock actually does not change the ram speed much at all

Doesn't surprise me greatly. The CPU should already be a lot faster than main RAM. For example, in Windows, if I run a RAM benchmark, then the CPU ticks over at just 10% load. So by overclocking the CPU you won't be gaining much in RAM speeds.

We'll have a look at the log for some of the other issues.

[Bandit]

updates

XMP specifies 2 profiles: Enthusiast (lower performance) and Extreme (higher performance). In your case, the 2000MHz and PC3-16000 comes from the Enthusiast profile. It might be that the 2133MHz and PC3-17000 values comes from the Extreme profile but isn't displayed because MemTest86 seems to think it is disabled. You can confirm if this is the case by running CPU-Z or our own RAMMon utility.(http://www.passmark.com/products/rammon.htm)

The mobo only has a choice of Profile1, which is the Extreme.
There is no OS on the system yet, so I would have to wait to try either utility.

Some other things I've noticed in v4.3 - when running a test, it doesn't respond to keyboard (MS 4000 USB) such as when hitting 'c' or 'ESC' unless it's on the very 1st test.

The text on the top is the brand string reported by the CPU, and will not change regardless of the actual clock speed. The clock speed on the left side, however, is measured by MemTest86 itself so it is interesting that it does not match your overclocked speed. We will need to investigate further into this.

Yes, I should have been more specific in my wording and not rounded off the 3492MHz.
I do note that, interestingly, the ram speed also does not increase/change with CPU clock speed change.

But choosing a different CPU test mode (single core vs parallel vs etc) causes a little ram speed change. Even v4.3 shows a change between CPU modes.
The ram speed measuring must have changed also, since v4.3 shows 29395MBs and V5 shows 42372MBs for the same BIOS settings. That's quite a bit of difference.
(note these are for the system ram, not CPU L1/L2/L3 cache)

Changing CPU multiplier all the way from 35 stock to 50 overclock actually does not change the ram speed much at all. Although they vary slightly each time a few MHz, they always stay around L1=136840, L2=94300, L3=71565, main=44000; v4.3 reports L1=99300, L2=53150, L3=35500, main=29364.

Seems that there may be issues with your motherboard's UEFI firmware implementation of multiprocessor services, as your log indicates that it freezes right after switching CPUs. You can try updating the firmware, but I doubt that the mobo vendor would have a fix for an issue like this. Can you try running in single CPU mode on any processor other than the first? Please e-mail the log file to help[atpassmarkdotcom]

Could be a firmware bug. I am using the latest F15 official BIOS. Not the first bug in the firmware I discovered. There was also the problem in F15betas where if an XMP profile was enabled AND anything other than the default 64Mb of onboard ram used for the iGPU, the system would not POST. This is fixed in the official non-beta F15 BIOS version, already 2 months old but which they are too lazy to post, and the issue did not exist in the F14 version.

I tried at least 2 passes on every other of the 8 CPU's in single CPU mode and no problems. I have emailed the log file.
I also discovered something else: I ran a full 1 pass test in parallel CPU mode. It completed fine with no error results. So, then I tried to run it again right away, and THAT's when Memtest froze and would not continue. So it seems like it's an issue with starting another round of tests even when a full pass had been completed.

BTW, what is the issue with false positives in parallel CPU mode?

The behaviour of the PASS progress bar was changed so that it is based on the number of tests currently completed (as opposed to the total number of tests to perform). This was so that any percentage less than 100% indicates test failure(s) as opposed to tests that have yet to be completed.

I vote strongly for retaining the 'old v4 PASS progress bar behaviour. Memtest is in use by millions of users who are used to the existing behaviour. Changing it confuses people, who will look at it and think that v5 has some super fast testing process and it is already done when in reality it is only done test 1. It could also be interpreted incorrectly as the existing test ongoing is 100% completed, when it is not yet.
If you were to change it so that it said FAILS: or ERRORS: then the bar did not progress unless there were errors, that would make sense. Or add a line that said FAILS: or ERRORS: , but kept the existing PASS: completion progress I think would be best. Memtest needs to retain the quick at-a-glance overall progress bar behaviour that everyone knows. Don't make the mistake like MS did with removing the START orb in Win8 and are now taking flak and having to bring it back. Otherwise you will also be answering 10 billion forum posts either about "why was it changed" or "it's not working correctly" or "insert question here".

[keith]

It doesn't seem like memtest is getting correct ram info.
Ram I have in there is 2133Mhz PC3-17000:

http://www.patriotmemory.com/product...roupid=232&id= 1326&type=1

http://www.patriotmemory.com/product...G213C1QKRD.pdf

but memtest says it is 2000 and PC3-16000.

XMP specifies 2 profiles: Enthusiast (lower performance) and Extreme (higher performance). In your case, the 2000MHz and PC3-16000 comes from the Enthusiast profile. It might be that the 2133MHz and PC3-17000 values comes from the Extreme profile but isn't displayed because MemTest86 seems to think it is disabled. You can confirm if this is the case by running CPU-Z or our own RAMMon utility.(http://www.passmark.com/products/rammon.htm)

Now in this test I had also overclocked the CPU to 4.2GHz (stock is 3.5 with turbo to 3.9,, but we all know 3770K is good for 4.2 easily), but I note that Memtest still reports it as 3500MHz and the ram speed does not increase. I *know* it's at 4200 because the BIOS reports it as such as do other utils. Memory is just the default XMP profile.

The text on the top is the brand string reported by the CPU, and will not change regardless of the actual clock speed. The clock speed on the left side, however, is measured by MemTest86 itself so it is interesting that it does not match your overclocked speed. We will need to investigate further into this.

Using anything other than the default 1 CPU (which stays on CPU core 1 on my system) causes hangs at some point, so using Round Robin or Parallel will cause Memtest to hang, sometimes it will run for some time, but it never makes it thru a whole 1 pass, usually hanging on test 9, sometimes before.

Seems that there may be issues with your motherboard's UEFI firmware implementation of multiprocessor services, as your log indicates that it freezes right after switching CPUs. You can try updating the firmware, but I doubt that the mobo vendor would have a fix for an issue like this. Can you try running in single CPU mode on any processor other than the first? Please e-mail the log file to help[atpassmarkdotcom]

The PASS progress 'bar' immediately shows 100% after the first test, even though it is just finished the first test.
You can see from the pic that the actual number indicator still shows 0 for passes completed, which is correct.

The behaviour of the PASS progress bar was changed so that it is based on the number of tests currently completed (as opposed to the total number of tests to perform). This was so that any percentage less than 100% indicates test failure(s) as opposed to tests that have yet to be completed.

[Bandit]

test 9 wait time

The log get appended to.
You can E-mail us any additional logs (or updated log).

For Test #9 how long did you wait? There is a long pause in this test to see if the bits 'fade'.

Yes, there are many long pauses, and I waited for several hours.
But the spinning \|/-_ cycling indicator under the CPU number bank was frozen also, and when just using the 1 CPU 0 it still 'spins' while the bits are fading. Also, there is a countdown timer showing how long the fade test is delapsing (if that's not real word then I invent it now) and that is frozen also. Obviously a static pic won't show that, but if I were to video it, it'd look the same as a static pic since memtest was frozen.

Anything else I can help debug?

[David (PassMark)]

The log get appended to.
You can E-mail us any additional logs (or updated log).

For Test #9 how long did you wait? There is a long pause in this test to see if the bits 'fade'.