RAM Detection lost occasionally

markleblatt

New Member
Hi there, I recently installed a RTX 4090 in my new system upgrading the card, and since then, occasionally the LEDs on my Corsair DDR5 RAM will stick and display one static color for RGB lighting. Coinciding with this, the sensors for temperature etc. in HWiNFO64 lose the RAM too. Looking at the logs for my RGB program, it sounded like something was interfering with the SMBus?

Everything is normal upon startup, and then at some point the monitoring for the RAM ceases.
 
Yes, some RGB control programs can't work with any other tool and cause collisions on SMBus resulting in such effects.
There's an easy way to fix this by implementing a simple synchronization technique which is already supported in other tools including HWiNFO. All such tools work together without issues.
We asked some RGB tool vendors to implement this in their software but they don't care...
 
OpenRGB has the shared SMBbus mutex implemented. Its a community project so compatibility with dd5 is not the best (yet) and not the most intuitive, but once you figure it and get it working its so refreshing to move out of iCue!
 
Indeed, I did a quick check and OpenRGB seems to be using the global SMBus mutex (GLOBAL_SMBUS_MUTEX_NAME).
However since there are issues when working together with other tools it means the interlocking isn't either implemented properly or is insufficient.
First thing is that OpenRGB needs to first try to open an existing mutex (if it's created by another tool) and if that fails, they need to create it. Moreover they might need to deal with access rights.
Another thing is that if they are accessing SMBus devices that might have multiple pages implemented, they will need to interlock the entire sequence including page switch (not just a single SMBus access) to avoid potential collisions.
 
Thanks for the replies!

I'm actually using SignalRGB as my program of choice; I'm not sure what they do with the mutex. Might be able to check once I get back from work today. This stuff is interesting.

Would the SMBus exclusions section in HWiNFO help this or is that something different?
 
I don't think the SMBus Exclusions list in HWiNFO will help here as the collision happening is of a different kind.
And BTW, almost all other tools (CPU-Z/HWMonitor, AIDA64, SIV, Argus Monitor, etc.) use the same mutex and they work together without any issues and for many years.
So I'm quite sure that if this mutex would be properly implemented in OpenRGB, we wouldn't see any such issues.
 
OpenRGB has been working flawlessly for me with HWinfo, ever since they added the mutex 4 months ago. Zero collision. Latency did go up a bit on the ram stick (1ms to 6ms when running RGB effects on them, seen in the ms field of hwinfo ) but that is to be expected since the bus gets more command over short periods. Reducing the rate of the effect improve this.

What I meant by compatibility issue with DDR5 is at the rgb control level for specific brand/models, not related to the mutex..

And yes, they have to deal with access rights. Lauching as admin is required upon 1st open for smbus devices to properly setup. Only once.
 
I meant access rights when creating the mutex. The current implementation in OpenRGB seemed insufficient to me.
DDR5 is a bit more complex, the SPD is usually accessed by multiple "pages". The PMIC too. Depends on what/how each application accesses and whether it does any writes to SMBus devices. In such case the entire operation needs to be protected/interlocked.
 
Back
Top