v4.2.0 + Core 2 Duo E8500: only 1 core detected

[ооо]

Hi there.
Long time user of Memtest here. Congratulations on the deal between Passmark and Chris to continue development of Memtest.

A little background so you know where I'm coming from: I used to work in a computer repair shop and ran Memtest everyday on hundreds of (mostly) custom-build computers over the years. Today I'm responsible for several dozen DELL servers in a huge school system. We have a variety of DELL servers ranging from 10+ year old models up the latest kick-ass $15.000 R720 (Memtest v4.2.0 works without visible issues here!!!).
Btw I reported an (uncritical) issue last year or so on a PowerEdge 2600 where the CPU was not detected and Chris fixed it promptly.

I'm running into an issue with Memtest v4.0a, v4.0b, v4.1 and v4.2 on my home box where the Intel E8500 ( http://en.wikipedia.org/wiki/E8500#....22_.2845_nm.29 and http://ark.intel.com/products/33911 ) on an Intel DG33TL Desktop Board is only detected with 1 core. The Intel Core 2 Duo though has 2 cores. I can attach a screenshot if needed.
Also the CPU name shows "Intel Core2 E8500 @ 3.16GHz". The actual name of the CPU, however, should be "Intel Core 2 Duo E8500".

Another issue I encountered is on an old PowerEdge 2500 which comes with a Pentium II XEON 1000 MHz, but the CPU name is not detected at all using v4.0a and v4.0b (haven't tested v4.1 nor v4.2 yet). It shows up empty. I can attach a screenshot as well if needed. I remember that Intel has 2 CPU identification tools available: one for Pentium III and earlier and the other for all other more recent CPUs (basically starting with Pentium 4), so there is a fundamental different way of how to identify these. You are probably aware of this already.

Not sure if you guys receive lots of requests to support such old hardware in these days. Probably not a big priority. I'm just reporting here and hope it gets fixed some day

Let me know if you need any more info.

Thanks.

[David (PassMark)]

Intel often give internal names to their CPUs that don't exactly match the marketing names. So the missing 'Duo' text isn't surprising.

Detecting the wrong number of cores is a bit more usual. There are definitely BIOS issues that can provoke this however. I don't think we have a E8500 in house, but we have a couple of similar machines from the same era. So we can do some testing here is you think it isn't BIOS related. (Does Windows report the correct core count?)

Having said that, we are working on a new MemTest86 V5 release. It should have new CPU ID detection code. It probably won't change the behavior for old CPUs however.

[cbrady]

If you can provide boot traces for the startup code it will help to narrow down why the core is not being detected.
Also the new CPU detection code prints the identification string that is produced by the CPUID instruction rather than trying guess from increasingly compilcated product and family codes. I am not sure what David has in mind for 5.0 but 4.* just uses the CPUID string as is.

[Michael (Passmark)]

We've test Memtest 4.2 on an E8500 here at the office. It correctly identified 2 cores and ran without any problems. As such we believe this is a motherboard or BIOS issue. (The motherboard in our system is an Asus P5K)

[ооо]

Does Windows report the correct core count?

Yep

If you can provide boot traces for the startup code it will help to narrow down why the core is not being detected.

I took 2 pictures.
The first pic shows trace 1 to 26:

The second trace 27 to 52:

We've test Memtest 4.2 on an E8500 here at the office. It correctly identified 2 cores...

Interesting. Thanks for checking this out.
It might be a BIOS issue... although an Intel CPU on an Intel desktop board with 2 dozen BIOS updates ( http://downloadmirror.intel.com/1793...easeNotes2.pdf ) makes it hard to believe that they didn't catch this issue.
I doublechecked the board/cpu compatibility ( http://processormatch.intel.com/Comp...ardname=dg33tl ) just to rule out that there is not some kind of mobo revision incompatibility, but there isn't. It remains a mystery.

[David (PassMark)]

We weren't really thinking it was a bug in the BIOS, but rather a setting that has been set wrong in BIOS.

For example the MAX CPUID VALUE LIMIT value in BIOS being enabled incorrectly. It is still strange however, as Windows should have also got the core count wrong in this case.

We'll have a look at the trace as well.

[cbrady]

I looked at the traces and the test found a valid MP table but it only had an entry for a single CPU. I have a theory about what is wrong. There are a couple types of tables that the BIOS can set up with multiprocessor data and it is assumed that the BIOS will only setup one type. It appears that the BIOS setup the MP table incorrectly (just one CPU) and then setup a valid MADT with the right information. Since Windows finds the right number of CPUs the correct information must exist somewhere, presumably in the MADT. Memtest86 does not look for the MADT if it finds a valid MP table. Perhaps a change to keep searching for an MADT would be wise if only one CPU is found in the MP table.

[Michael (Passmark)]

The change mentioned in the previous post has been implemented in the latest beta release (4.3.0 Beta). Can you give it a go and let us know if it fixes your problem.

http://www.memtest86.com/download.htm

[ооо]

We weren't really thinking it was a bug in the BIOS, but rather a setting that has been set wrong in BIOS.

For example the MAX CPUID VALUE LIMIT value in BIOS being enabled incorrectly. It is still strange however, as Windows should have also got the core count wrong in this case.

Oh I see. Thanks for clearing this up. I doublechecked and CPUID value limit is disabled (BIOS defaults), Core Multiplexing (enable both cores) is enabled.

The change mentioned in the previous post has been implemented in the latest beta release (4.3.0 Beta). Can you give it a go and let us know if it fixes your problem.

http://www.memtest86.com/download.htm

Michael, unfortunately the 4.3.0 BETA version still shows 1 CPU only.

I looked at the traces and the test found a valid MP table but it only had an entry for a single CPU. I have a theory about what is wrong. There are a couple types of tables that the BIOS can set up with multiprocessor data and it is assumed that the BIOS will only setup one type. It appears that the BIOS setup the MP table incorrectly (just one CPU) and then setup a valid MADT with the right information. Since Windows finds the right number of CPUs the correct information must exist somewhere, presumably in the MADT. Memtest86 does not look for the MADT if it finds a valid MP table. Perhaps a change to keep searching for an MADT would be wise if only one CPU is found in the MP table.

Chris, thanks for looking into this. I can attach btrace screenshots from v4.3.0 BETA if needed. I'm beginning to think that this really might be some Intel BIOS quirk. Intel uses their own BIOS alas it's not an AWARD nor AMI BIOS (not sure if this would make any difference in the way Memtest is figuring out the CPUID?).

[cbrady]

Too bad the change in 4.3.0 didn't work. Clearly the BIOS is doing something unexpected, but since Windows finds the information it has to be somewhere. The 4.3.0 traces may give us a clue.

[ооо]

The first screenshot shows trace 1 to 26, the second trace 27 to 52: