AX1200i - Corsair link spamming event log with load of driver

Hi,

Despite my recent bad experience, I brought an AX1200i as a replacement for my blown PSU and have been fine with it so far.

However, today I have reinstalled Windows 7 and now I have a strange problem in the link software.

Previously, before the reinstall, all the rails were reading roughly correct. I was able to enable OCP for everything, setting the trip points to 20A. Readings were not exactly stable (they seem to jump around a bit and read 0 often which doesn't seem possible) but they were usable enough, and the main thing was that I could enable multi-rail mode with low OCP trip points.

(I am running beta 2.0.16)

Now, after the reinstall of Windows, I have one rail miles out. As you can see here: http://i38.photobucket.com/albums/e119/bit_monkey/CorsairLink.jpg

PCIe 2 reads 21 amps or more with the system idling. Not only that, but if I try to enable OCP, even leaving the default setting of 40 amps, the system immediately powers off.

I swapped my PCIe cables around, since at first I feared a possible hardware problem and wondered if the reading could be correct, but it is certainly spurious - even with the PCIe cables swapped around to different GPUs, it is still PCIe 2 that shows a high reading.

I tried going back to 2.0.15 - I uninstalled corsair link, manually deleted remaining files in c:\program files (x86)\corsair, and uninstalled the corsair USB dongle in device manager, ticking the box to remove the drivers so it would revert to seeing "Flexpower USB-SMBus bridge" instead of the correct name that shows up once the driver is installed.

I then rebooted, and installed 2.0.15, and rebooted again.

The result was an even higher reading for PCIe 2 of over 40 amps - probably this was the case somehow "behind the scenes" with 2.0.16 which is why OCP is tripping.

Here's a screenshot of the over 40A reading: http://i38.photobucket.com/albums/e119/bit_monkey/CorsairLink2.jpg

As you can see, total system power usage is reported at 200w, which is realistic for idling, but PCIe 2 shows 46 amps (550 watts) alone!

In either case, if I load the system up running kombustor, I see current draw change on the other PCIe rails that have loads on them, but the PCIe 2 reading stays the same. It does sometimes seem to vary by less than an amp, staying in the 21.x amp range.

I'd like to get this sorted as soon as possible, as the main reason I brought the AX1200i was to have OCP enabled in multi-rail mode, so as to have better protection against the kind of failure that happened to my previous PSU.

Other than reinstalling as described (more than once), I've also powered the system off and left it for a while with the PSU turned off to see if that reset anything, but to no avail.

Happy to provide any logs necessary etc. to troubleshoot this. I guess it's possible my USB dongle has gone wrong, but it seems rather coincidental that it's happened when I reinstalled the OS.

Oh, and while we're talking about OCP and the AX1200i, is it possible to implement OCP on the periph rails as well as the PCIe? If so, I'd like to request that in a future version please.

PS. I am just about to go and try a different cable on that output, just to make sure I don't have a faulty cable, but I would have expected a more dramatic outcome if it was shorting to the tune of 250 watts. I'll follow up in a minute with the result of changing the cable.

OK, follow up as promised.

Changing the cable made no difference.

So I switched the load that was on PCIe2 to a different output, now PCIe 2 has nothing connected, and is still reporting 21.7 amps of load.

I am hopeful that there's not an internal short in the PSU, since the GPU that PCIe2 was connected to is working fine, and total system load is reported correctly as I stated before.

EDIT - THE POST BELOW IS LEFT HERE FOR COMPLETENESS, BUT THE PROBLEM HAS COME BACK. PLEASE SEE THE FOLLOWING POST(S)

OK, so the wierdness continues.

So I could have OCP on everything again, while I waited to hear back, I swapped everything around so that I'd have PCIe 2 unused.

While I was recabling, I shut down and actually unplugged the mains cable from the PSU this time. I then spent about 10 or 15 minutes cabling, then turned the system back on.

This time, I have a normal (0) reading on PCIe 2.

I have no idea what I did to fix it. As I said in my last post, I'd already tried with nothing plugged into pcie2 and that hadn't fixed it.

When I shut down and tried resetting the PSU before, I just turned off the switch on the back. I never unplugged the mains cable. I would have thought that switch was before any electronics in the PSU and was equivalent to pulling the plug, or is that not the case?

Perhaps it was just how long I left it without power this time, and that somehow reset it fully. I know stuff can hold odd and corrupt values for a fair while after power is removed, and it was probably only a couple of minutes I shut down for during the previous attempt to get it to reset, perhaps the longer downtime fixed it???

I will obviously report if there is any reoccurance, but I'll leave this post here in case anyone else ever has the same problem - a prolonged period with no power to the PSU from the wall is probably worth a try if it happens to anyone else.

The problem is back.

All of a sudden, after about half an hour without a problem, the PC powered off. It rebooted, I tried logging in to windows, and as soon as I went to log in, it went again, presumably as Sierra2 started.

I pulled the plug again, let it sit without power for a couple of minutes, then started it and managed to get into windows for long enough to disable OCP on PCIe2. The wierd readings on PCIe2 (along with the reasonable reading for total power draw) are there again. As mentioned previously, nothing is plugged in to that output.

I'm not sure now whether to trust the total power draw, or whether there may be an internal short in the PSU. It's not running hot or anything, and is in fanless mode at about 38 degrees in a 20 degree room. If PCIe2 really was drawing 40 amps as it's reporting now, that would be nearly 500 watts on it's own - add in the system itself, and I'd expect the PSU to be hot and the fan to be on.

In any case, I'm obviously a bit concerned. I think it might be best to RMA this. Can someone please help me out getting an advanced RMA sorted so I don't end up without a PSU again. I'm just about to PM Ram Guy to draw his attention to this thread, and put in an RMA on the website.

Boris, Corsair is closed till Monday. Hence the lack of response. I'm sure he'll see this on Monday at some point..c

Yeah, I figured as much, just putting it down here while it's all fresh in my mind so hopefully it can help troubleshoot any other similar problems.

I expect this is just a corsair link failure, but obviously I'm a bit gun-shy after recent events.

Boris the only way to get an advanced RMA is to actually call CS on the phone. They are the only ones who can arrange that.

You can find the number on the main website page at the bottom under contatct

Ok, replacement arrived and fitted.

On first start, I immediately opened Corsair link and the rail was reporting 18.4a, then about 30 seconds later, it went to 0 and has stayed there.

I hope this is just that when the link software starts, it takes a little while to update with the latest reading from the PSU, and what I saw was maybe a cached reading from the other one.

I'll continue to monitor and post/email again if it reoccurs, but it looks hopeful.

If it continues I would suggest we uninstall the Links software and restart the system and try installing it again.

Also did you use the new Link that came with the New PSU? Or did we just send you a new Link module?

Yes, new link module and new PSU installed.

It seems fine so far, I'm still going to keep a close eye on it for a few days, but I think the initial high reading with the new PSU must have been a cached value from the old PSU/link module, it only showed up for a few seconds after the first boot with the new hardware and it has since stayed correctly reading 0.

While trying to debug a problem I'm having, I just noticed that I have thousands of events in the system log for Corsair link loading a driver. They are at a rate of one a second or thereabouts. Here's the contents (they are all identical)

A service was installed in the system.

Service Name: WinRing0_1_2_0

Service File Name: C:\Program Files (x86)\Corsair\CorsairLink 2\WinRing0x64.sys

Service Type: kernel mode driver

Start Type: demand start

Service Account:

Another thread now found where other users are reporting the same problem. http://forum.corsair.com/v3/showthread.php?t=111067

I'll continue this there.

Can you call our customer service by phone? If its not easy for you to do that please post the RMA# this was on.

Hi RAM GUY,

I did call C/S today, early during your business day. I spoke to Sandra and was promised the shipping labels would be sent today.

Now it is past closing time there, and still no labels.

I'd appreciate if you would chase it for me.

RMA 1281311

thanks

Hi RAM GUY,

I don't think the OP ever fixed this - he actually posted the following in the other thread:

About the problem that WinRing0x64 is trashing my System Event log has been norrowed down to how SierraService.exe is handling this inner kernel ring sensor.

 

If I start RealTemGT that use the same inner kernel ring sensor there will only one entry in the System event log about it has been started on demand. If I start RealTempGT when SierraService is running the entrys stop's comming every 3-4 sec from WinRing0x64 and as soon I exit RealTempGT the enterys are comming again.

 

It seems to me that SierraService is restarting the WinRing0x64 every 3-4 sec and that's way all thoose entries are there. I think you should talk to the software team that I think it's better to start this inner kernel ring sensor once when the service wrapper SierraService starts and not restarting it every 3-4 seconds.

 

I hope this will be changed in a futurerelease of this software that has been much better since I started to use the Corsair Link in the beging of this year.

That was his last post about the problem in that thread. So he wasn't saying it was fixed, but just posting an update on something he'd noticed about RealTemp inhibiting the constant reloads of WinRing0x64.sys by the Sierra2 service.

I can report that I see the same effect from running RealTempGT - the constant reloads of WinRing0x64.sys (and therefore the log spam) stop. I presume the reason for this is that once the WinRing0x64.sys driver is loaded by RealTemp once, it stays loaded and both RealTempGT and Corsair Link are able to use it.