cancel
Showing results for 
Search instead for 
Did you mean: 

X670 / X870 resource thread

Shamino
Moderator

ill use this thread to collect some new test bioses for the boards, maybe also to explain some less understood options

to disable cores ccd go here and choose ccd xx bit map down core.
each ones stand for an enabled core
best to disable from the back, ie:
110000
instead of 0011000
after selection press downcore apply changes or discard if made mistake

ocpak/octools

FAQ:
7950x not boosting pass 5.5G -> check that CStates is not disabled
Detailed Explanation on CState Boot Limiter


Test BIOSes:

Spoiler

new:
X3D OC Preset for those MB with asynch BCLK Support: (for simple slight perf boost for X3D)
97792

DOCP/EXPO Tweaked: (for simple timings tightening)
97793

strixe-e 1515 

strixe-f 1515 

strix e a 1515 

crosshair hero 1515 

crosshair gene 1515 

crosshair extreme 1515 

creator 670 1515

creator b650 1515

strix 650E I

strix 670 itx

 

 

for crosshair and strix e-e:

explanation of segment2 Loadline:

dualseg.jpg

customize a heterogenous loadline for a dual segment workload range.

example above shows loadline=L6 when current is in range of 0~40A, and Level4 when current is above 40A.

 

 

 


Adds for x3d

dynamic ccd priority switch with core flex, os / driver agnostic so win10 win11 ok

97403

97404

Algo as follows:
If condition reached and ccd0 specified, then check current mem/cache activity > threshold and hysteresis reached, if fulfilled then switch
If condition reached and ccd1 specified, then check current mem/cache activity <=threshold and hysteresis reached,, if fulfilled then switch
Default hysteresis =4

Can combine multiple algos for ccd priority so combinations are wide

works on non x3d too but of course senseless on it. detailed explanation here.

 

3,640 Views
4,710 REPLIES 4,710

To follow up on my previous post, today I checked out if the PCIe link width problem presents itself again after updating to 1807... It does indeed, almost always x1, sometimes x2, x4, and one time x8 or x16. After that, I reverted to 1710, which showed x16 on the great majority of boots, but incidentally also x8 (never below x8). 1602 appears to have the lowest "error rate". There was no clear pattern to me concerning the link width when booting after complete disconnection from power, or after a reboot.

With Linux, I investigated the PCI bus with "lspci -vvv". When the link width is below x16, that is the case for the PCI bridge, but I do not really comprehend the output... The lower bandwidth indicated by the 3dmark PCIE feature test would then be caused by a bottleneck in the bridge(?)

A diff between the output for a cold boot of firmware 1710 which ended up with x16 and a cold boot of firmware 1807 which ended up with x1, shows not many differences. Only the link width for the PCI bridge, some IRQs and I/O- vs I/O+ for the Thunderbolt interface appeared to differ... I will list the exact differences below.

Could this point to a defective I/O die which comes to light because of different firmware settings in the newer firmware versions? Or some kind of noise on the PCIe bus that for some reason is more disturbing in more recent firmware? 

Differences between lspci -vvv output for 1710 and 1807:
for ID 00:01.1 PCI bridge:
1710: LnkSta: Speed 16GT/s, Width x16
1807: LnkSta: Speed 16GT/s, Width x1
for ID 01:00.0 PCI bridge:
1710: LnkSta: Speed 16GT/s, Width x16
1807: LnkSta: Speed 16GT/s, Width x1 (downgraded)
for ID 03:00.0 GFX card in slot 1:
1710: Interrupt: pin A routed to IRQ 131
1807: pin A routed to IRQ 165
for ID 04:00.0 NVME in M2_1:
1710: Interrupt: pin A routed to IRQ 56
1807: Interrupt: pin A routed to IRQ 98
for ID 10:00.0 Thunderbolt:
1710: Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
1807: Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
for ID 6e:00.0 iGPU
1710: Interrupt: pin A routed to IRQ 149
1807: Interrupt: pin A routed to IRQ 81
for ID 6e:00.3 USB controller:
1710: Interrupt: pin D routed to IRQ 140
1807: Interrupt: pin D routed to IRQ 72
for ID 6e:00.4 USB controller:
1710: Interrupt: pin A routed to IRQ 149
1807: Interrupt: pin A routed to IRQ 81

I have no clue why the bridge would not run at full width, while the GFX card would allow that.

And interestingly: 1710 started with x8, that was x16 after waking up after being in standby mode for a few hours.

Somehow the negotiation of the link width is not working properly, the link speed is always correct (PCIE 4.0). The author of this post https://superuser.com/a/1095078 presumes that would more likely point to a configuration problem than for example a noise-related problem.

My question is: could a hardware fault: IO-die, connection between socket and CPU or between socket and slot, or a broken graphics adapter (or any hardware defect) cause these link width problems with a clearly different probability and magnitude for firmware versions 1602-1807?

GeForce66
Level 9

DId anyone already try new 2214 BIOS on their TUF models?

Yes, but "Aio pump, fan headers" it's not working perfectly with

Do not use "AIO Pump header" or your pump will run at the minimum speed be cautious. configuring for maximum or custom speed won't work. this issue occurs in bios 2204 and 2214, rollback to BIOS 2001 and headers works perfectly.

Aio pump signal only because it is powered by 4pin

Bios 2214-2204

  • Aio pump and fan headers do not work properly.
  • Dram 6600C30, 6400C28, and 2:1 7600 are impossible 
  • Using Hynix A-Die

✔️Bios 2001

  • AioPump and Fans headers works perfectly.
  • Dram 6600C30, 6400C28 are working
  • Dram 2:1 7600 hard but is possible.
  • Low Soc Voltage requirement.
  • Using Hynix A-Die

    @Shamino 

Oh, that doesn't sound too promising - thanks for your time to check it out.
Since I am using an AIO pump that I definitely need to PWM control, I will stay away for now.

F1Aussie
Level 11

I have the strix 670E-E and just went from 1609 to 1807 and it looks like the aura Stealth setting on shutdown is still broken. It won't hold the Stealth setting and the main led lighting stays on after shutdown. When you go into bios again the setting has reverted to "on". Anyone else had this issue?

There is a setting in armory crate under devices - shutdown effect that overrides bios setting.


Good to know, I will see if I can find that, cheers

Okay, just checked, was already off in AC, it would seem that that does not Override the bios setting, thanks anyway. Any idea where we can log bios issues? Not sure if there is an official thread here for that or not?

fractal-zombie
Level 10

Maybe someone know, can we disable new mitigation fix? cause sql DBs are very slow...