Corsair Link 4.9.1.23, H115i - Incorrect # of Fans & Temp Sensors

Corsair Link 4.9.1.23 has resolved some issues. Other issues I have and is a known issue is the incorrect fan count and incorrect temperature sensor count.

I can repeatedly get the fan count to be correct and then incorrect.

Steps:

1) Reboot the machine

2) Start Corsair Link (enter the admin password depending on machine configuration and user one is logged on as)

3) Corsair link displays 6 temperature sensor readings and 8 fans, with fans 5 to 8 having rpm readings between 8000 and 33000. (Fans 5 to 8 are what I refer to as ghost fans and they are magically quiet)

4) Kill Corsair Link (right click on Corsair Link icon in task bar and select exit)

5) Start SIVX64 or SIVX32 as Administrator

6) While SIV64X is running start Corsair Link up again

7) Now Corsair Link only show 3 temperature sensors and a total number of 4 fans with sensible rpm readings.

8) At this point one can kill SIVX64/32 and Corsair Link and check the processes in the Windows Task Manager to ensure that nothing is running in the background.

9) Start Corsair Link and it functions correctly (Correct number of temp sensors and fans).

10) Reboot the machine and one has to start at step 1) again to rectify the problem.

My Question is:

What is SIV64X/SIV32X doing that results in Corsair Link being able to detect the temp sensors and fans correctly, where Corsair Link has been started from scratch after SIV64X was started?

This, however does not fix the incorrect CPU core numbering.

I feel that SIV64X contains the missing link to resolve the issue at hand.

Refer to attachments posted on 11-06-2017, 09:52 AM at http://forum.corsair.com/forums/showthread.php?t=171244&page=2

SIV doesn't use the CPUID SDK to my knowledge. Again, those are issues with the CPUID SDK's reporting since, as you said, these things appear in HWMonitor as well.

 

We continue to fold in new versions with new fixes as they become available.

Actually since Corsair decided to remove the SMB Buss interlocks, it is known that if Link is run concurrently with SIV, HWINFO64, AIDA, etc. that there will be strange problems. The author of SIV has stated clearly that since this change was made, you cannot operate Link and SIV at the same time and expect things to work reliably. This was a conscious decision on Corsair's part as they have stated that removing the interlocks was necessary as they migrate to software based LED control as required for the new LL series fans. I have asked for an explanation of WHY the buss interlocks had to be removed but I never received a response. Maybe they will explain it this time.

In short, if you are using the latest version of Link, don't run SIV at the same time. You can exit one and open the other but you can't have both open at one. Same is true for HWINFO64 and AIDA64 for sure. Not sure about other monitoring programs but probably.

I believe Corsair is well aware of this. Not sure what is has to do with the CPUID SDK. Incorrect CPU Core numbering has been a problem for a long time. Also, Link can't report more than 16 cores since it is written as a 32-bit application. So it can't report all cores on an I9-7980XE or many XEON CPUs that have more than 16 cores.

Good luck!

Actually since Corsair decided to remove the SMB Buss interlocks, it is known that if Link is run concurrently with SIV, HWINFO64, AIDA, etc. that there will be strange problems. The author of SIV has stated clearly that since this change was made, you cannot operate Link and SIV at the same time and expect things to work reliably. This was a conscious decision on Corsair's part as they have stated that removing the interlocks was necessary as they migrate to software based LED control as required for the new LL series fans. I have asked for an explanation of WHY the buss interlocks had to be removed but I never received a response. Maybe they will explain it this time.

 

In short, if you are using the latest version of Link, don't run SIV at the same time. You can exit one and open the other but you can't have both open at one. Same is true for HWINFO64 and AIDA64 for sure. Not sure about other monitoring programs but probably.

 

I believe Corsair is well aware of this. Not sure what is has to do with the CPUID SDK. Incorrect CPU Core numbering has been a problem for a long time. Also, Link can't report more than 16 cores since it is written as a 32-bit application. So it can't report all cores on an I9-7980XE or many XEON CPUs that have more than 16 cores.

 

Good luck!

Please ... stop with the totally incorrect information. Corsair isn't doing anything with SMBus interlocks ... they call into the CPUID SDK to get the system-level data and it's the CPUID SDK's job to handle that. Link is written in .NET (probably C# with perhaps a touch of Managed C++ for calls into unmanaged code). You don't have direct access to the SMBus in higher-level managed platforms. Your access to this (and other low-level hardware interfaces) is going to be via calls into libraries like the CPUID SDK.

What they did do is removed the global mutex to control access to their hardware devices and are using a private, in-process SemaphoreSlim instead to ensure that Link only has one thread accessing the Link devices at a time. Since it's Corsair software accessing a device that Corsair made and that is running firmware that Corsair wrote, it is not unreasonable for them to do this. And yes, it can cause problems with third party software that is trying to read those same sensors on the Link device. Now, they've not said why they did this. Perhaps they don't want to play with others. Perhaps they were having issues with other applications grabbing their mutex and not letting Link do it's thing. Or maybe they moved all of the sensor reads to a single process and, not needing to have cross-process synchronization any longer, opted to use a lighter-weight mechanism for thread synchronization. Doesn't matter, really ... it was a named mutex that they created for themselves and never published as an integration point, making it a private API. So any one relying on that private, unpublished, undocumented API can't whine when it goes away. It wasn't published or documented for a reason.

That said, with a little bit of C# and SignalR code, it would appear to be possible to actually use the Link Service to read these sensors AND play nice with Corsair's software ecosystem. Of course, that's an unpublished API as well, so you'd do so at your own risk with the expectation that any change to link could break your integration code.

As for the 64-bit, maybe there is a technical reason for it or maybe they just never changed Visual Studio's default "AnyCPU - 32-bit preferred" assembly flag. What I do know is that, if you know a little about the .NET Framework and CLR as well as the SDK tools, you can run Link as a 64-bit app. But that won't make a difference because it's the service needs run as 64-bit and that doesn't work ... SIUSBXp (the USB Device driver) is a 32-bit DLL. That may not be available as a 32-bit component OR the 64-bit version may not work with all of their devices ... still, it appears to be a technical limitation.

Finally, I will say this ... in the past several months, Link has gotten better. It's a process, not a happening and, with the exception of some missteps with driver signing (ahem), they are definitely heading in the right direction. It's not a small code base and they need to be careful about any incremental improvements that they make so as limit breakages AND keep up with the hardware teams that are throwing new stuff at them all the time.

Please ... stop with the totally incorrect information. Corsair isn't doing anything with SMBus interlocks ... they call into the CPUID SDK to get the system-level data and it's the CPUID SDK's job to handle that. Link is written in .NET (probably C# with perhaps a touch of Managed C++ for calls into unmanaged code). You don't have direct access to the SMBus in higher-level managed platforms. Your access to this (and other low-level hardware interfaces) is going to be via calls into libraries like the CPUID SDK.

What they did do is removed the global mutex to control access to their hardware devices and are using a private, in-process SemaphoreSlim instead to ensure that Link only has one thread accessing the Link devices at a time. Since it's Corsair software accessing a device that Corsair made and that is running firmware that Corsair wrote, it is not unreasonable for them to do this. And yes, it can cause problems with third party software that is trying to read those same sensors on the Link device. Now, they've not said why they did this. Perhaps they don't want to play with others. Perhaps they were having issues with other applications grabbing their mutex and not letting Link do it's thing. Or maybe they moved all of the sensor reads to a single process and, not needing to have cross-process synchronization any longer, opted to use a lighter-weight mechanism for thread synchronization. Doesn't matter, really ... it was a named mutex that they created for themselves and never published as an integration point, making it a private API. So any one relying on that private, unpublished, undocumented API can't whine when it goes away. It wasn't published or documented for a reason.

That said, with a little bit of C# and SignalR code, it would appear to be possible to actually use the Link Service to read these sensors AND play nice with Corsair's software ecosystem. Of course, that's an unpublished API as well, so you'd do so at your own risk with the expectation that any change to link could break your integration code.

As for the 64-bit, maybe there is a technical reason for it or maybe they just never changed Visual Studio's default "AnyCPU - 32-bit preferred" assembly flag. What I do know is that, if you know a little about the .NET Framework and CLR as well as the SDK tools, you can run Link as a 64-bit app. But that won't make a difference because it's the service needs run as 64-bit and that doesn't work ... SIUSBXp (the USB Device driver) is a 32-bit DLL. That may not be available as a 32-bit component OR the 64-bit version may not work with all of their devices ... still, it appears to be a technical limitation.

Finally, I will say this ... in the past several months, Link has gotten better. It's a process, not a happening and, with the exception of some missteps with driver signing (ahem), they are definitely heading in the right direction. It's not a small code base and they need to be careful about any incremental improvements that they make so as limit breakages AND keep up with the hardware teams that are throwing new stuff at them all the time.

... completely wrong :eek:... you are new here? :D:

What they did do is removed the global mutex to control access to their hardware devices and are using a private, in-process SemaphoreSlim instead to ensure that Link only has one thread accessing the Link devices at a time.

You are correct - they removed the Global\CorsairLinkReadWriteGuardMutex. I apologize for misspeaking. It's clear from your post that you are more knowledgeable about the inner workings of Link and the environment it operates in. Thanks for sharing your insights.

Contrary to what I read above, SIVnnX (nn = 32 or 64, makes no difference on a 64bit platform) works perfectly well. Intel's Extreme Tuning Utility and SIVnnX report fans and temperature sensors correctly. I find no problem running SIVnnX concurrently with Corsair Link.

Starting SIVnnX first ensures that Corsair Link detects the correct number of fans and temperature sensors.

Without SIVnnX being started first, Corsair Link does not function correctly.

After Corsair Link is started you can terminate SivnnX and Corsair Link then continues to function correctly.

Unfortunately I have to shut down my machine and when I restart I repeat the work around from scratch. This is a pity as the product seems quite good. It is only the link software that let's the side down. I want to buy additional components but just cannot justify spending anything until it all works as intended to without requiring a work around. An example I need a device like commander pro to control several fans.

Does this not provide any clues or are we at the situation where most developers sometimes get to when one is desperately trying to resolve an issue and you can't see the wood for the trees.

What is SIVnnX doing right that Corsair Link is not doing at all?

I am just as eager, as I am sure all at Corsair are, to get Corsair Link to function as intended. Mentioning Intel Extreme Tuning Utility is just to illustrate that it works perfectly OK. SIVnnX as far as I understand, is a utility used to check the system and comes from Corsair. Correct me if I am wrong. It also functions OK. Why I mentioned the steps I tried is also to show that somehow running SIVnnX has a positive outcome on the way Corsair Link works.

My aim is to remove all fans from the main board headers, install Corsair Commander Pro and drive all fans through that where I am hoping to have better control over cooling.

Corsair Link 4.9.1.23 has resolved some issues. Other issues I have and is a known issue is the incorrect fan count and incorrect temperature sensor count.

 

I can repeatedly get the fan count to be correct and then incorrect.

 

Steps:

1) Reboot the machine

2) Start Corsair Link (enter the admin password depending on machine configuration and user one is logged on as)

3) Corsair link displays 6 temperature sensor readings and 8 fans, with fans 5 to 8 having rpm readings between 8000 and 33000. (Fans 5 to 8 are what I refer to as ghost fans and they are magically quiet)

4) Kill Corsair Link (right click on Corsair Link icon in task bar and select exit)

5) Start SIVX64 or SIVX32 as Administrator

6) While SIV64X is running start Corsair Link up again

7) Now Corsair Link only show 3 temperature sensors and a total number of 4 fans with sensible rpm readings.

8) At this point one can kill SIVX64/32 and Corsair Link and check the processes in the Windows Task Manager to ensure that nothing is running in the background.

9) Start Corsair Link and it functions correctly (Correct number of temp sensors and fans).

10) Reboot the machine and one has to start at step 1) again to rectify the problem.

 

My Question is:

What is SIV64X/SIV32X doing that results in Corsair Link being able to detect the temp sensors and fans correctly, where Corsair Link has been started from scratch after SIV64X was started?

This, however does not fix the incorrect CPU core numbering.

 

I feel that SIV64X contains the missing link to resolve the issue at hand.

 

Refer to attachments posted on 11-06-2017, 09:52 AM at http://forum.corsair.com/forums/showthread.php?t=171244&page=2

Contrary to what I read above, SIVnnX (nn = 32 or 64, makes no difference on a 64bit platform) works perfectly well. Intel's Extreme Tuning Utility and SIVnnX report fans and temperature sensors correctly. I find no problem running SIVnnX concurrently with Corsair Link.

 

Starting SIVnnX first ensures that Corsair Link detects the correct number of fans and temperature sensors.

 

Without SIVnnX being started first, Corsair Link does not function correctly.

 

After Corsair Link is started you can terminate SivnnX and Corsair Link then continues to function correctly.

 

Unfortunately I have to shut down my machine and when I restart I repeat the work around from scratch. This is a pity as the product seems quite good. It is only the link software that let's the side down. I want to buy additional components but just cannot justify spending anything until it all works as intended to without requiring a work around. An example I need a device like commander pro to control several fans.

 

Does this not provide any clues or are we at the situation where most developers sometimes get to when one is desperately trying to resolve an issue and you can't see the wood for the trees.

 

What is SIVnnX doing right that Corsair Link is not doing at all?

HUh. I have never heard that running SIV first and then opening Link would cause Link work correctly, or differently at all. My understanding is that since Corsair "broke the mutex", running SIV and Link concurrently was a no-no. Yet you are saying that running SIV, then Link, then closing SIV, results in Link reporting fans and temps correctly, which it does not do if you do not run SIV first before you open Link. I have no idea why that would be happening. I know who would know but he is not available for comment.

SIVnnX as far as I understand, is a utility used to check the system and comes from Corsair. Correct me if I am wrong. It also functions OK. Why I mentioned the steps I tried is also to show that somehow running SIVnnX has a positive outcome on the way Corsair Link works.

Are we talking about the same SIV? This SIV?

http://rh-software.com/

 

With respect to the hard work done by other software vendors, our priority is always going to be making sure our software and products work and work well.

This forum is meant just for that purpose. To raise awareness of issues experienced outside at the consumer coal face as it were. I do accept that with limited resources it will take time to resolve. The difficulty is identifying the root cause and directing enough resources to resolve these issues.

I have been through many software development and conversion projects where one tests the code till you are blue in the face and when it is placed into production all hell breaks loose.

Recently participated in an upgrade to Maximo software running on IBM AIX Power8 severs connecting to Oracle 12cR1 databases at a National Utility company and all stress tests provided us with a false sense of achievement in terms of performance. Post Go-Live the performance was dismal and totally unexpected, so yes I understand the immense pressure all at Corsair may be faced with.

SIV is absolutely, 100% NOT from Corsair.

No, but it can be very useful for diagnosing problems. I still don't get how in TevleGnirheg's case, opening SIV before Link somehow results in Link reading fan speeds and temperature data that it otherwise doesn't. Perhaps something gets initialized or SIV doing a sensor poll starts or changes something. Maybe it's specific to his system. It's above my level of understanding but hey - if it works, it works...

HUh. I have never heard that running SIV first and then opening Link would cause Link work correctly, or differently at all. My understanding is that since Corsair "broke the mutex", running SIV and Link concurrently was a no-no. Yet you are saying that running SIV, then Link, then closing SIV, results in Link reporting fans and temps correctly, which it does not do if you do not run SIV first before you open Link. I have no idea why that would be happening. I know who would know but he is not available for comment.

Without the mutex in place to synchronize cross-process access to the Corsair hardware devices, there is a possibility that both applications could attempt to access the hardware at the same time. When that happens, one of the applications will hang or fail to get a reading. It's a timing issue and happens randomly. It's also entirely possible that some users may never see it at all. Or the applications could handle the hang gracefully and, even though there is a hang, the user isn't aware of it happening ... the missed reading is just dropped/ignored. I frequently run Link and HWInfo at the same time and there are times when HWInfo will show a "blank" reading for my H100iV2 when this happens ... and then it goes away when it gets the next reading. From my perspective, I'm aware of this, I understand why it happens and, personally, it's not a big deal to me. Others, however, have felt differently.

No, but it can be very useful for diagnosing problems. I still don't get how in TevleGnirheg's case, opening SIV before Link somehow results in Link reading fan speeds and temperature data that it otherwise doesn't. Perhaps something gets initialized or SIV doing a sensor poll starts or changes something. Maybe it's specific to his system. It's above my level of understanding but hey - if it works, it works...

There is certainly something that SIV is initializing that Link (or, more accurately, the CPUID SDK) isn't initializing. And, apparently, once it's initialized, CPUID SDK does pick it up. The challenge is that every motherboard handles things like temperature readings and fan control differently; there's no standard API for this. And while the usual bus interface for these sensors and controllers is (from what I understand) I2C, that's far from a standard - each device will have their own, unique I2C commands and the responses are also unique and distinct per device. Since we don't know what motherboard TevleGnirheg has, however, we can't compare notes or experiences.

In my own system, the PSU (AX860i) dongle (plugged on to a Commander Pro) for some reason stops communicating, especially after the computer is brought out of sleep. This happens in Corsair Link AND SIV. However, SIV does have a choice to restart the service. Once restarted, I can close SIV and open Corsair Link (or SIV), which now shows the PSU. Or I can restart my PC.....

Before I had the Commander Pro, I had the PSU daisy chained through the H100i and never had a issue. I cannot daisy chain through the H100i and then into the Commander Pro however. I have to use the dongle.