What is this??? - Actual and expected value are the same

[Roxxors]

2025-04-25 03:34:08 - [MEM ERROR - Data] Test: 7, CPU: 16, Address: 4BD574650/A2, Expected: 00000040, Actual: 00000040
2025-04-25 03:34:08 - [MEM ERROR - Data] Test: 7, CPU: 19, Address: 4C8113CA8/B2, Expected: 00000200, Actual: 00000200
2025-04-25 03:34:14 - [MEM ERROR - Data] Test: 7, CPU: 16, Address: 51D224888/A2, Expected: 01000000, Actual: 01000000

You report an error even when the actual is the same as the expected???

My faith in Memtest reliability is dropping sharply atm... Please explain...

[David (PassMark)]

Yea, that is kind of strange.

Could be that the CPU, or CPU cache, failed. (i.e. the CPU compares, for example, the value 8 with the value 8 and finds they are not the same value, somehow....).

Or the value in RAM is intermittently wrong. For example the value used for the compare step was different from the value used for the print step.

Can you Email us or post the debug log. Maybe there will be something interesting in the log.

[Roxxors]

MemTest86-20250425-032927_156723.log

Here ya go...

[David (PassMark)]

The log as 100s of errors. Most of them make some sort of sense.

Example.
2025-04-25 03:34:47 - [MEM ERROR - Data] Test: 7, CPU: 21, Address: 5F0522870/A2, Expected: 00020000, Actual: FFFDFFFF
2025-04-25 03:34:47 - [MEM ERROR - Data] Test: 7, CPU: 21, Address: 5F052286C/A2, Expected: 00010000, Actual: FFFEFFFF
2025-04-25 03:34:47 - [MEM ERROR - Data] Test: 7, CPU: 21, Address: 5F0522868/A2, Expected: 00008000, Actual: FFFF7FFF
2025-04-25 03:34:47 - [MEM ERROR - Data] Test: 7, CPU: 21, Address: 5F0522864/A2, Expected: 00004000, Actual: FFFFBFFF

But even for these examples, there are 32bits that are flipped. Which isn't typical for a RAM error. It is almost like the wrong address is being read. (i.e. an error on the address bus).

Do you have spare RAM and / or a spare CPU to try?

[Roxxors]

I wish I did. That CPU is like 800$ is the I only have 1. The spare ram I have is not CUDIMM, just standard cl30 6000 (OC to 6333) and I already tested it and it works.

I have been trying to get this system stable for over a month and keep running into all kinds of weird things like this. I'm pulling my hair out here trying to figure it out...

And yea, it usually just flips the 1st or 2ed bit. Never seen it flip the whole register... That's just weird. This whole thing is just weird...

I have been building boxes from scratch since the early 80s when I would order parts from Computer Shopper magazine and assemble them, but I have never run into anything like this before...

[Roxxors]

My hair is getting pulled out again. Is this a real error or is it not?

[David (PassMark)]

99% sure this is a real hardware error.
The cause of the error is less sure (bad CPU, address bus, RAM timings, RAM itself).

The way computers work is that data from the RAM is moved from main RAM into the CPU's cache (of which there are several levels), and then from the CPU cache to the CPU's internal "registers". Once in the registers an compare instruction is done to check if the value is the expected one.

This is the actual code of Test #7 (below).

The key line is this one,
(bad = *p) != pat

This likely compiles to something like this in x86 assembly.
mov eax, <pat>; Load a 32-bit pattern into EAX register
cmp eax, *p ; Compare EAX with the 32-bit value in memory
je equal ; Jump to 'equal' if EAX == [num_in_ram]

One of these 3 instructions fails .... somehow.




I would,
1) Check for BIOS updates. These ultra 9 systems were unstable when initially released. BIOS updates fixed most of it.
2) Under clock the RAM and try it. (i.e. run it slower). Same for the CPU.
3) Buy or borrow a new lower end CPU that fits the same socket. e.g. Intel Core Ultra 5 225F. Then sell it 2nd hand later on.

[Roxxors]

There is only a single way I can see that happening.

You read the memory (and the expected is the same as the actual in memory) and copy it to the CPU register and do the CMP and it fails.
You write the expected and actual from the memory (which match) to the logfile and display it on the screen (not what is actually in the CPU registers).

QUESTION: What was the actual contents of the registers? Is there a way for you to read that and display it?

If the contents of the registers compared don't match the actual/expected in the memory, we just pinpointed the problem. The data is getting corrupted moving from the memory to the CPU register...

[David (PassMark)]

I don't have the exact assembly code available, as Memtest86 runs in UEFI land and there is no operating system and thus no good debugger.
So very hard to be sure of exact x86 machine code without a fair amount of work.
I'm leaning towards a bad CPU however (intermittent data corruption in cache memory or registers).

[Roxxors]

I don't think it's an actual "physically" broken CPU or I would be seeing errors in the OS. This machine ran all night, I run SWTOR since this morning on monitor1, IE on monitor2 with a dozen tabs open (one is this site), monitor3 has my Outlook email and Discord open, and monitor4 has another IE open to Youtube playing music videos all day. No errors, locks or anything.

I'm thinking that Memtest stresses it more than normal operation and heats CPU/Ram up more under testing than is does under normal operation. I am also thinking that it is a setting or two in the BIOS that I need to find and change to stabilize the CPU. It could also be that the MEFW needs another update.

That stuff you can't help with. I need to figure that out, but I think we have it more narrowed down then when we started.

I will try to keep you updated on what I find out from here on out.

Thanks!

[David (PassMark)]

You could also give the BurnInTest trial a go. it might help reproduce the problem, if it was load related.
(it also contains a RAM test, using different code than MemTest86)

In the absence of really high end diagnostics gear, you are probably at the point where swapping out hardware is required.

[Roxxors]

I did some more testing and found this...

Now. I was able to get the system stable. It passes Memtest all 4 passes, but I have a question or two...

Number one is that I think the main stat is the Memory (line, 5th one down) <amount> and the speed. I also assume that the higher that speed is, the better.

Number two... Is 34.+ be fast, you have seen way more of these screens then I have. I think it is but have nothing to compare it to.

Number three, what is up with the reported CPU speed? I am pretty sure that I am running way faster than 781 MHZ...

[David (PassMark)]

What did you do to get the machine stable ?

Yes, higher GB/sec is better than lower. 34GB/sec is OK.
(we've seen results as high as 60GB/sec, but that was with RAM / huge cache on board with the CPU die, like with the Ryzen 9 7950X3D, so maybe not a fair comparison)

I am pretty sure that I am running way faster than 781 MHZ

That was the measured speed. But CPU clocks speeds ramp up and down from one millisecond to the next.
We try and report the max clock, but it can be hard to force the CPU into it's highest clock speed state.

[Roxxors]

To get it stable I bumped the BCLK from 100 to 126 and enabled BCLK aware voltage then set the memory controller voltage manually from 1.1 to 1.5v after bumping the SOC from 100 to 106.

It's kinda like playing Whack a Mole.

If I increase A and B, system locks.
If I decrease A and B, system is slow.
If I increase A and drop B down, system runs at speed X.
If I increase B and drop A down, system runs at speed Y.
So I just see which combination is faster and more stable over all.

Thing is that it's just not settings A and B, there are like 50 different settings or more and an almost millions of combinations and finding the fastest and most stable one is gonna take time...

I may just die of old age first...

[David (PassMark)]

Good to get confirmation that it was in fact a hardware issue (or at least a hardware configuration issue).

1.5V seems pretty high. VDD is normally 1.1V, so this is a 36% increase. Wonder if it will kill the RAM over time.

Thing is that it's just not settings A and B, there are like 50 different settings or more and an almost millions of combinations and finding the fastest and most stable one is gonna take time...

Correct. Which is why I never ever go down this path. Really need very high end oscilloscope, protocol analyzer and 10 years of electrical engineering experience to get it right. Which is why it is the vendors job to set all this correctly in firmware and in the SPD data.

The RAM either works at it (factory) XMP settings, or if it doesn't, it is faulty (or motherboard is faulty) and should be returned.