Z690 Aorus Elite DDR4 Rev. 1.1 VR VOUT greyed out

I'll cut the first half to see if the second one has what it takes to be ok, if not i ll go the second half
 
well, after cutting 0-7 from x1, i shut down, booted and at login i had no gpu input, i had to force stop my pc and after that it worked. Weird, never happened something like this. I'll test it now.
 
Well, i am at the latest 1x box xF and it works just fine with just that active. Now i don't know if any single box selected in 1x row will do the trick and im too tired to test it. For now these are my findings. It's something in the 1x row.
 
Martin said:
Thanks! So with only the box for 1F checked all works OK?
Click to expand...
yes, but it also worked just fine with all 1x row checked. It worked with the 7-f half too, but i had that weird no video at windows login bug. it owrked with 4,2,1 too(as in C,D,E,F).
 
That's OK. When 1F is causing the problem then it will work with 1F checked and any other as well. Important is that now we know it's 1F as checking only that one solves the problem.
I will add this into HWiNFO so that this address will automatically be skipped.
 
  • Like
Reactions: qlf
yea, no problem. I like HWInfo and I just can't build or use a PC without having a glimpse on all those shiny rows.
PS: I only have the 1F box checked. The default 0F row is unselected on my side after the testing.
 
I tried playing with the boxes again by checking back the 0x row as it was on default plus 1F box and it did the grey out bug again, but it did not hang with 1F checked. So for me, I just can't use the first row(0x). After going back to 1F box, i had that no video at windows start as i had it when i was testing the second row with different values. I went back and started using the full 1x row to see if I will have that no video input bug at login. But using 1x, even a single value like 1F it does indeed fix the problems I had. Now i just want to see if i use the full 1x row will actually fix the no video/ blackscreen at login bug.
 
Just to explain this.. I assume there's a device at some address that when unintentionally accessed by HWiNFO causes one (or all) those issues.
When you check one box, it means HWiNFO won't access that device. So our goal is to find the minimum number of boxes that when checked no issues will happen. When any of them is unchecked again, then the issue should happen.
So if everything is OK with just 1F checked, then it's OK. Or 1F plus something else is needed, then it's our goal as well.
 
Should I just go 1F as as minimum plus 1,2,3 from right to left, until i dont have that gpu blackscreen issue at login. Btw that issue barely happens.

Btw isn't there a way to know what devices are on those addresses?
 
Unfortunately it's not possible to know what's there. I have already contacted GIGABYTE for a clarification and waiting for their response...
 
  • Like
Reactions: qlf
Martin said:
Unfortunately it's not possible to know what's there. I have already contacted GIGABYTE for a clarification and waiting for their response.
Click to expand...
The cool thing is that when using 1x, there is no greyout. All values are perfectly read with no issues. I wonder if this trick would fix the same greyout problems on my old Z390, as well as other people's similar greyout issue on the vrm sensor. Searching for a solution on my greyout problem, i have found a lot of threads with the same vrm sensor wrong or straight greyed out problems.
BTW now I'm using 1E + 1F too see if it will do the no video thing at login.
 
GIGABYTE says there are no devices no mainboard that could cause such issues. Do you maybe have RGB?
 
0 RGB. 2 fans only, cpu noctua, 14700k, 7900xt and nothing else. RAM from qvl perfectly stable. BIOS defaults, all official drivers installed.
 
So i restored to original settings, opened hwinfo in debug mode and in debug mode with all the settings on default even the first row of smbus checked, it doesn't do the greyout or the hang. Why is that????
I also attached the dbg file, maybe you can see something. I also noticed that in debug mode the app is starting slower. So something in debug mode is clearly helping with my situation. If i disable debug mode with default, it greys out and hangs.

For the time being i'll keep it defaults with debug mode on.

DBG FILE LINK: CLICK HERE (Even compressed it can't be attached)
 
Could be some timing marginality as Debug Mode is slower. I don't recommend to run with this enabled for normal use as it dumps data to disk and that file can grow pretty large over time.
 
Martin said:
Could be some timing marginality as Debug Mode is slower. I don't recommend to run with this enabled for normal use as it dumps data to disk and that file can grow pretty large over time.
Click to expand...
It seems to be replacing the dbg file every time i close the app. Well, this slower mode actually fixes every issue I have and i don't have to tweak anything. I don't even have that no video at boot problem I had with 1f checked. Is there something that I can tweak so I can disable debug mode but preserve this slow mode? Polling period doesn't seem to be changed with debug mode.
We now know that it has to do with SMBus and reading from that should maybe be slower? I'm trying to make sense of this weird behavior.

EDIT: I noticed the constant write on the disk. I'll stop using the app until we find some resolution.
 
Last edited:
You must log in or register to reply here.
Back
Top