Announcement

Collapse
No announcement yet.

The data string order in "Test12 random number sequence, 128-bit" result log

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • The data string order in "Test12 random number sequence, 128-bit" result log

    Hi,~
    I want to confirm the order of data string reported in test log:
    Is the data string of 128 bit in test 12 swaped by half?

    I have a DIMM which has a bad single bit.

    Here is the test log of my DIMM with MemTest86 V8.2 Pro:
    Code:
    1998-01-01 15:08:53 - =============================================
    1998-01-01 15:08:53 - MemTest86 V8.2 Pro Build: 1000 (64-bit)
    1998-01-01 15:08:53 - =============================================
    ....
    1998-01-01 15:09:14 - [MEM ERROR - Data] Test: 1, CPU: 0, Address: 2512997E8, Expected: 00000002512997E8, Actual: 00000002512995E8
    1998-01-01 15:37:28 - [MEM ERROR - Data] Test: 12, CPU: 10, Address: 2512997E0, Expected: F626029852ECEB432455C7E2B6A5EB43, Actual: F626029852ECEB432455C7E2B6A5E943
    1998-01-01 15:38:32 - [MEM ERROR - Data] Test: 13, CPU: 0, Address: 2512997E8, Expected: 19A69BDD, Actual: 19A699DD
    1998-01-01 15:37:41 - [MEM WARNING] Test: 13, CPU: 0, Address: 2512997E8, Expected: B21A8381, Actual: B21A8181

    from the test 1 and test 13, I can see the mismatch byte locating in physical address 2512997E9,
    but for test 12, it shows the error byte locating at address 2512997E1.

    Code:
    Address: 2512997E8:  00000002512997E8 XOR 00000002512995E8 ==> 0000000000000200
    Address: 2512997E0:  F626029852ECEB432455C7E2B6A5EB43  XOR F626029852ECEB432455C7E2B6A5E943  ==> 00000000000000000000000000000200
    Address: 2512997E8:  19A69BDD  XOR 19A699DD  ==> 00000200
    Address: 2512997E8:  B21A8381   XOR B21A8181  ==> 00000200
    IF I swap the low and high half data string of test 12, I can get a correct result:
    Code:
    Address: 2512997E0:  2455C7E2B6A5EB43F626029852ECEB43  XOR 2455C7E2B6A5E943F626029852ECEB43  ==> 00000000000002000000000000000000
    Thank you!

  • #2
    Yes, you are correct, thanks for letting us know.

    Due to a bug with handling endianness, the expected/actual values displayed in the logs/reports may be swapped in 64-bit increments.

    We will fix this for the next public release.

    Comment

    Working...
    X