10-04-2022 06:30 AM - last edited a month ago by Silent_Scone
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:
new:
X3D OC Preset for those MB with asynch BCLK Support: (for simple slight perf boost for X3D)
DOCP/EXPO Tweaked: (for simple timings tightening)
strixe-e 1515
for crosshair and strix e-e:
explanation of segment2 Loadline:
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
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.
06-20-2023 11:29 AM
Have you fixed your issue ?
06-20-2023 03:09 PM
I'm on stock RAM since yesterday (was running EXPO II before) as this seemed to be the easiest route to follow (still with MCR enabled, lol). Can't tell for sure as it used to happen no more than once every week or so. Will need to wait another week and see if it comes back or not. Will report back for sure!
06-26-2023 07:03 AM - edited 06-26-2023 07:09 AM
@DDavid33 here's some update from today:
After almost getting ready to think the issue was resolved with stock RAM settings (MCR still on) I had the same issue today but this time I was a little more patient and tested something 🙂
So...first cold boot today: no issues
Turned PC off 2 hours later, then came back another 2 hours later -> missing Marvel AQtion 10Gbit Network Adapter from Device Manager
These are the steps (in order) that I did after that:
- full shutdown, waiting 10 seconds, then power on -> network still missing
- to be sure, I again powered off and booted -> network still missing
- this time I rebooted instead of power off / power on -> network came back !!!!
Decided to check windows event logs, found these (besides a lot of other trash):
(in order from old to new)
The process C:\Windows\System32\RuntimeBroker.exe (CZR-PC) has initiated the power off of computer CZR-PC on behalf of user CZR-PC\cezar for the following reason: Other (Unplanned)
Reason Code: 0x0
Shutdown Type: power off
Along with:
The system is entering sleep.
Sleep Reason: Application API
No idea why Windows thinks I'm using sleep function when powering off, not to mention it's completely disabled everywhere.
I also updated Marvell drivers from 3.1.7 to 3.1.8 and disabled "Energy-Efficient Ethernet" as some had issues with it.
Will wait another week and update to 1510 bios and see if that fixes or breaks anything 🙂 (I'm on 1415 right now) At this point, I'm not even sure if it's a hardware or software problem. Last thing to test is MCR disabled but I'm almost sure that won't make a difference. Either way, I'm trying NOT to make too many changes at the same time hoping I can pinpoint the exact problem causing this.
06-26-2023 07:23 AM
Based on your feedback I'm not sure it's MCR related.
Did you power off by using PC button ? Check advanced power settings, your windows may be set to hibernate when power button is pressed.
If your windows goes sleep while you clicked the shutdown in start menu, your windows should be reinstalled.
Runtimebroker can also become a pain, google "RuntimeBroker.exe has initiated the power off" and enjoy 😉
06-26-2023 07:32 AM - edited 06-26-2023 07:38 AM
Never used the button. Only windows menu.
Hibernation is also disabled, even hybrid sleep from power plan.
The pain that a Windows reinstall would bring ... omg 🙂
P.S: Windows only reports going to sleep. But it's not. Else it would power back on from keyboard etc.
I do really hope it's related to Fast Startup as others pointed out. The thing is I never get a BSOD or random shutdown/reboot/anything else. It's just the lan thing (and only on the 10gbit one) + the event logs.
Thanks for your feedback!
06-26-2023 07:34 AM - edited 06-26-2023 07:35 AM
When your windows goes to sleep when you tell it to shutdown... That's no good !
06-26-2023 07:42 AM
Fast startup to me is a glorified remarketed hybernation so I leave it disabled 🙂 does wonders especially for cold boot.
06-26-2023 08:32 AM
Unfortunately fast startup has caused many issues mainly due to misunderstanding and people not knowing what it actually does. In short:
So when shutting down, your Windows is not actually shutting down. If you got a crashed service (ie driver or service) after "shutdown" and subsequent power-on you will find this system service still being in crashed mode.
So it's never a good idea to shut down your PC and then power it on again and assume it's actually been restarted. I almost daily have support calls and I ask them to reboot their computer first and most people keep responding "oh, but I shut it down yesterday and turned it on today, so I just restarted it". In fact you didn't.
To prove it open your task manager and go to the CPU performance graph. It will also show a value called "Up time". If you run your PC for 8 hours on day 1 and then shut down and power it on next day and run it for another 4 hours your up time will read 12 hours.
In order to perform proper reboot start up your windows and select "Restart" from the power button in the Windows start menu. This will also reset the "up time" as you get a proper restart.
If you also want a proper shutdown and restart on normal shutdown you should disable fast startup.
So in your case the issue with your NIC might be related to a crashing driver improperly re-initializing after hibernation. To rule this out you might disable fast startup and repeat your test (cold-boot). If it does not occur after disabled fast startup (check your up time to be reset on power-on) you might rather face a simple software/driver issue rather than mainboard hardware initialization issue.
However I can confirm another issue reported occasionally in regards to storage: I am running AM5 platform in some small and home seerver configurations and found from time to time my storage disappearing. Sometimes M.2 NVMe drives just fail and disappear and in one case I lost all my SATA drives at once. After a reboot they typically re-appear but nevertheless the system will cause issues dropping drives from software RAID or causing systems to crash (if all disks disappear). Not sure what's causing it but at least I am running 3 of those systems with ASUS B650-PLUS mainboards and all of them suffer from occasional drive disappearance.
Currently running Linux (Kernlel 6.3 on one and Kernel 6.2 on others). There is no pattern yet. One system now running for 60 days without any issue and another one lost all SATA drives yesterday with an uptime of 15 days.
Newer BIOS might fix it. I did not see the system with BIOS 1616 crash yet but it's just been 8 days up yet since it crashed and therefore got latest upgrades too. So I need more data to make an educated guess but random NVMe inaccessibility seems to be an issue.
Also I found that one system clearly logged iommu related issues right before failing:
Jun 12 21:00:37 master kernel: amd_iommu_report_page_fault: 538 callbacks suppressed
Jun 12 21:00:37 master kernel: ahci 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0014 address=0x385e0000 flags=0x0020]
Jun 12 21:00:37 master kernel: ahci 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0014 address=0x385e0100 flags=0x0020]
Jun 12 21:00:37 master kernel: ahci 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0014 address=0x385e0180 flags=0x0020]
Jun 12 21:00:37 master kernel: ahci 0000:09:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0014 address=0x385e0200 flags=0x0020]
Meanwhile I went away with software-IOMMU using iommu=soft kernel command line. Hoping to work around the problem as I found some people online reporting IOMMU issues triggered by NVMe trim on AMD systems resolved by iommu=soft.
As said I don't have enough data on it yet and will try to update also the other systems (they are remote unfortunately) with latest BIOS revisions.
06-26-2023 08:42 AM - edited 06-26-2023 08:43 AM
Nice shot, I totally forgot about this fast startup trash, at my discharge I never shutdown my computer 😛
06-26-2023 08:55 AM
You might at least anyway restart it once per month as installing Windows Updates will force a reboot. So your uptime is reset to 0 once per month.
Fast startup as such is not such a bad thing actually. I am leaving it enabled on purpose but I take care all my drivers are not causing such issues and if I still run into an issue I will just first perform a "real reboot" before complaining. Most modern systems do run just fine without re-initializing everything every day. But people should be aware about it so if someone is telling me he just did a restart I need to ask if probably just referring to "just turned on my machine" and not actual fresh boot.