yeah, its weird. There are bios causes for the display driver not being initialized at startup that I'm aware of, i know know of them affecting the MPG gaming though, but i know the 1.0.0.4B bios has issues with the 10bit tag support delaying device starts and boots. does it occur with fast startup turned off or ErP enabled in the bios?
I've got dpc peaks of 487 microseconds for nvlddmkm.sys (NVidia Windows Kernel Mode Driver), they're relatively rare peaks, but it was never as high as this before, something's changed. (Highest ntoskrnl.exe was only 80 microseconds for me).
@Astyanax no fast boot or ErP turned on. just noticed only happens on cold boot, not reboot. i can pretty much exclude bios, as i was using it since release without trouble. ill probably try 450, if not, clean install.
No, you actually cannot. Shutdown and start boot is Hiberboot (Fast startup) In Reboot there is no kernel state stored, and this is exactly the instance that Tomahawk boards fail to start the card for several moments. The bios is part of the restoration from S3 and S4, certain registers have to be "played back" exactly to return the system to working order. This shows that Is you misunderstanding what was asked. Fast Startup is a Windows kernel feature introduced in 8.x and requires all aspects of the system to have a correct ACPI implementation and configuration, it is toggled in the Windows Power Settings. Fast Boot is an aspect of UEFI that skips as many tests as possible You will have to fill out https://forms.gle/kJ9Bqcaicvjb82SdA with your full details, and don't forget to note you have the x570 Aorus Ultra, because just googling brings up the z390 rendition, any bios settings, driver versions of secondary devices and bios versions for card (use gpu-z) and mobo.
thanks for help. seems that GB has a problem with some bios versions not clearing cmos thru normal means (button/jumper/battery removal), and keeps settings even if bios is updated/flashed. at least for my board, F10 was first release with that problem, and after flashing F11 again (incl backup bios), loading defaults, then qflash-ing F11 and loading defaults then my settings, it now seems to work and in device manager its actually back to initially installed gpu/moni etc, and doesnt show same behavior on cold boot.
aha!, glad to hear! Gigabyte has historically been the worst with ACPI compliance, they once told a customer to install windows because they don't support linux -_-' Nvidia also had a handful of drivers that code 43'd Pascal and maxwell parts because they removed a particular Gigabyte specific hack when removing Fermi compatibility from the drivers. This isn't Gigabyte specific, I've seen quite a few cases of Ryzen platform issues as a result of not totally purging the cmos, AMD is playing dangerously with their additions and removals and changing variable names whilst leaving the setting reading code untouched in quite a few cases. I'll be fair here though, Intel has had this issue a couple of times too, one case involved a IGP that was disabled in the bios but still presented to the device manager in an unstartable error state, The bios was setting on var name as disabled in the nvram but still loading the original var which was enabled. doh.
just amazed about the level of "crap" they do without blinking. did realize i have to use CSM mode, or bios goes into lower res, then with it turned on.