SPD Checksum Errors w/ HWiNFO64 Running

[Mr. Fox]

I have a Clevo P870DM3-G that has an issue with HWiNFO64. I don't know if maybe I am doing something that causes it with a box checked in the settings that needs to be clear, or whether it is is a HWiNFO64 bug, or a laptop bug.

If I have HWiNFO64 running (which I usually do) and use Thaiphoon Burner to read from the memory modules they show SPD checksum errors. If I close HWiNFO64 and wait a couple of minutes, re-launch Thaiphoon Burner and re-read from the sticks the SPD checksum errors are gone. I am also failing TM5 testing at 3000 CL16 pretty consistently and experience memory-related instability with HWiNFO64 running. I have EC support disabled, so it's not that part of HWiNFO64. If I do not use HWiNFO64 then the SPD checksum errors go away and I regain stability.

Any thoughts or advice about what might be the problem and whether I can fix it? I've never seen this issue on any other platform before and I use HWiNFO64 on everything. I don't know how to function without it I have been using it for so long.

 

[Martin]

Access to SMBus (and SPD) requires synchronization, so if there are multiple clients trying to access SMBus at the same time, there might be a collision resulting in wrong readouts. I believe this is what happens on your system.
To prevent such situations, there are multiple mechanisms - all recent Intel chipsets feature a hardware mutex that when properly utilized avoids such collisions. Moreover, lots of software tools use a global software mutex to protect such access on an even higher level. But the requirement is that all tools make use of those mutexes and in the correct way. HWiNFO of course does use both methods, similar as other tools like AIDA64, CPU-Z/HWMonitor, SIV, etc. so you won't see such problems when running all these tools in parallel.
So I believe the problem is in Thaiphoon Burner which fails to use these mechanisms.

 

[Mr. Fox]

Access to SMBus (and SPD) requires synchronization, so if there are multiple clients trying to access SMBus at the same time, there might be a collision resulting in wrong readouts. I believe this is what happens on your system.
To prevent such situations, there are multiple mechanisms - all recent Intel chipsets feature a hardware mutex that when properly utilized avoids such collisions. Moreover, lots of software tools use a global software mutex to protect such access on an even higher level. But the requirement is that all tools make use of those mutexes and in the correct way. HWiNFO of course does use both methods, similar as other tools like AIDA64, CPU-Z/HWMonitor, SIV, etc. so you won't see such problems when running all these tools in parallel.
So I believe the problem is in Thaiphoon Burner which fails to use these mechanisms.

Thanks, Martin. I appreciate your response. This makes sense. I let Prema know and linked him to this post. He is in communication with Vitality Jungle (Thaiphoon Burner author).

The one thing I am not clear about it is once Thaiphoon Burner finds checksum errors after reading from SPD, why I get memory errors in tests with HWiNFO64 running or booting to DOS or UEFI for testing. I'm guessing they must be real errors in checksum of the SPD because they exist outside of Windows even though it seems to be triggered by HWiFO64 running in the background after Thaiphoon Burner has accessed/read from SPD.

Once the checksum errors are resolved, so are the memory errors. Now that I know the problem exists (just discovered it yesterday) I will need to do more methodical testing to better understand the behavior. I've not encountered this in the past in all the years of using HWiNFO64.

 

[Martin]

Since the SMBus software Mutex is a custom named object that has been agreed by several developers, it would be good to tell the Thaiphoon Burner author its name: "Global\Access_SMBUS.HTP.Method". This mutex needs to be held during the entire SMBus transaction, but avoid unnecessary blocking. This mutex (along with other similar) used to be publicly described somewhere in the past (TPU?), but I don't think that page is alive anymore.

I'm not sure about the other problem you're experiencing, but it might be a result of the collision during SMBus access as well. Such a collision can result in unpredictable consequences. How exactly do those errors appear, what test is reporting them ?

 

[Mr. Fox]

I will ask Prema to pass that info along to him. Thank you.

For now, it appears unchecking the box for SMBus support resolves the conflict/collision. All of the sensors I use still work and the SPD checksum errors are cleared, as well as memory tests passing without errors.

 

[Mr. Fox]

And, while it has absolutely nothing to do with HWiNFO64 I find this puzzling, too. It may be an anomaly with AIDA64 misreporting information. If what AIDA64 is reporting is accurate and it is actually programmed to the SPD that could be an issue. There is no CL38 visible elsewhere, but AIDA64 reports that is available in the SPD. Thaiphoon Burner does not show it, and as far as I know CL38 is an erroneous timing value for CAS latency. There is no way to remove the CL38 entry with Thaiphoon Burner because it does not show up at all.

 

[Martin]

The problem with CL38 reporting is probably an AIDA64 issue, I'll notify its author.

 

[Mr. Fox]

The problem with CL38 reporting is probably an AIDA64 issue, I'll notify its author.

Thanks, Martin. I also notified Tamas and linked him to this thread.

 

[Mr. Fox]

The problem with CL38 reporting is probably an AIDA64 issue, I'll notify its author.

Tamas asked me to send him an SMBus dump to look at. Here is the content in case you want to have a look to see if anything looks out of place in terms of SMB or the SPD section.

 

[Mr. Fox]

The problem with CL38 reporting is probably an AIDA64 issue, I'll notify its author.

Tamas asked me to send him an SMBus dump to look at. Here is the content in case you want to have a look to see if anything looks out of place in terms of SMB or the SPD section.

Well, as usual, Tamas came through in a timely manner and an update fixed that glitch. It's always a pleasure for me to use products like HWiNFO64 and AIDA64 and ThrottleStop when the authors are so engaged and responsive, and passionate about their work. This is really awesome. It makes an already excellent product awesome. And, sadly, it is rare to find in this day and age.

 

[Martin]

Thanks