Intersil ISL 69269 sensors blanking out

[Aptos]

I just got a Gigabyte z590 Aorus Master and 10900k and have been in the process of overclocking, but sometimes under heavy load the Intersil ISL 69269 sensors stop reporting (VR VOUT, POUT, COUT, etc.). When I eventually reboot, the BIOS resets itself after a ~5x reboot loop (although it kindly reloads all my settings).

Can something like this be caused by HWiNFO? Or do I have a faulty ISL 69269 VRM Controller?

 

[Martin]

No, that doesn't mean the VRM is faulty. I think this is rather due to the high system load when HWiNFO is unable to reliably talk to the VRM because it's blocked by other tasks in the system.

 

[Aptos]

No, that doesn't mean the VRM is faulty. I think this is rather due to the high system load when HWiNFO is unable to reliably talk to the VRM because it's blocked by other tasks in the system.

Thanks for the response!

The sensors don't come back after stopping prime95 and restarting HWiNFO. Are there any other things I should try to reset the sensor reporting while Windows is running? Or is the only way to let the BIOS recover itself on reboot?

 

[Martin]

Hmm, that's strange when restarting HWiNFO doesn't help and such a reboot loop is required. That might indicate something wrong happened there, but I'm not sure what exactly.

 

[Aptos]

After playing with this some more, it's definitely related to however HWiNFO is querying the Intersil ISL69269's sensors. I've never had an issue w/o HWiNFO open. I've got the z590 Master and was hitting the BIOS reset reboot loop issue on the F3 bios, but now that I'm on the F5a BIOS it seems to recover better, but HWiNFO still seems to mess up the ISL69269 sensors somehow.

Is there anything I could do to help debug this issue? I've enabled debug mode and looked at the logs after a repro, but there didn't seem to be anything particularly useful in there for this situation: just the sensors start reading 0.

 

[Martin]

Are you perhaps running some other monitoring tools along with HWiNFO? That could cause a conflict when accessing the ISL.
I'd also need to see the Debug File when the issue happens.
You could try to rule the issue out by disabling monitoring of the ISL sensor.

 

[Aptos]

Sometimes I am (e.g. OCCT and CPU-z) but it regularly happens when I'm not running anything else as well (assuming there's not some background application doing so w/o my knowledge). I don't understand how disabling monitoring the ISL sensor would help since those are the only sensor values that are going blank/crashing and those are the ones I want to see, but maybe I don't understand something. I expect it would run just fine if I did that, but I wouldn't see the sensors I care about.

The quickest way to reproduce is to use a heavy load like p95 small ffts or similar 170+ Amp load on my 10900k, however, it will reproduce while playing games as well, it just takes longer.

Here's two DBG files: one is just a quick launch while the sensors were already not reporting, the other is a zipped (cuz it was too big) DBG file from a run where the sensors crashed mid-run.

 

[Martin]

I analyzed those dumps and can see what happens there. It's not an issue of just the ISL PWM, but the entire SMBus becomes stuck after some time and from that point any device connected there becomes inaccessible.
Unfortunately I don't know why that happens, what is the reason resulting in such state.

 

[Aptos]

Is it possible to find out what SMBus addresses are associated with the ISL 69269 VR VOUT, IOUT, and POUT sensors? I'm wondering if disabling all other addresses except those would help.

 

[Aptos]

This doesn't seem right... lol

 

[Martin]

Usually the SMBus Host Controller indeed doesn't require any drivers.
On your system the ISL should be at SMBus address 0x60.

 

[Aptos]

0x60 was the right address, but disabling everything but that didn't help. I grabbed the latest INF from Intel, which did update to oem41.inf (from oem6.inf), but it didn't help either.

 

[Martin]

Then I suspect there's something else in the system running that might access the SMBus and cause a collision.

 

[Aptos]

I don't know what it could be since I'm very careful about letting anything run in the background or as a service. Looking through my running processes and services I don't see anything that sounds like it would interfere. One other interesting note is that when I updated from the F3 bios to the F5a bios (for the z590 aorus master) it recovers from this SMBus lockup much better: I just have to restart now. Before, it would reboot loop and sometimes reset the BIOS (like a clear CMOS) when this SMBus lockup would happen.

Is there any way to check what processes might be accessing the SMBus?

 

[Martin]

I'm afraid there's no way how to know what process is using the SMBus.