Squall Leonhart

I've put this towards a vanguard user to try and get a repro and then forward onto AMD, theres clearly an issue with a driver mutex or kernel memory corruption when the two software are paired that needs to be investigated from there end.

Your BSOD is caused by a defective CPU or cosmic waves, contact Intel for a replacement.

Sensor and GPU Sensor info latency is massive, report the issue to nvidia, I'll notify ManuelG of this thread and to be on the watch for the feedback. https://forms.gle/kJ9Bqcaicvjb82SdA You might also go further and perform the following Use nsight to analyze your system for causes of hitching and stutters https://developer.nvidia.com/blog/using-nsight-systems-for-fixing-stutters-in-games/ Then follow on with these if it doesn't display a trigger or theres evidence the issue is in the nvidia driver. Performance reports require the user to submit a gpuview or

These are listed as not supported on Processors that support either or both in some cases, meanwhile HWInfo64 is logging the time the processor is in the C6 state just fine.

hi Fiery, I'm not on the affected platform but i can confirm that there are still users experiencing this in the wild. See the users thread here on guru3D https://forums.guru3d.com/threads/3700x-5700xt-crashs-everyday.436494/#post-5883244 Perhaps you might work with AMD to develop a safer API for their card interfaces?

By allowing the administrator account to set a persistent Start = 0x2 from within the Aida64 options, and change the task schedule to include the user account in the name of the Run at Startup task so multiple admins or users can choose to start it or not.

I see, well that would have to be a placeholder name, because the product is the Turing version of the Tesla T10 as shown running here

Why In the change notes do you have the T10-8 identified as a Geforce RTX, when this nomenclature is a Tesla part.? TU102 T10 Generation 8 Tesla board.

No, that didn't seem to work. I found why though, devices on the ASUSTOR driver are treated as a Raid device, so RAID Smart needs to be enabled.

Easy, here you go. The drive is currently on the ASUS UASP driver, but Smart was also missing on the mass storage driver, regardless both could pass through smart to Crystaldisk, and I can also see the data in HD Tune, SSD-Z, etc. diskctrldump.txt raiddump.txt smartdump.txt I also have a cable based on the ASM1351 on order so i can get trim working on this ssd, so i'll likely be back with dumps for that too after it arrives lol.

Hey Feiry, i grabbed a UASP sata 3 adapter cable produced by startech it uses the ASMedia - ASM1153E https://www.startech.com/au/HDD/Adapters/USB-3-SATA-adapter-cable-with-UASP~USB3S2SAT3CB Aida64 is unable to pull smart data from the drive attached, but CrystalDiskInfo has no such problem. Need a dump to add support? if so which ones.

Fiery, the feature this user wanted is possible. The drive itself can report what SATA mode it is in, but not all do so and seems more likely when the Drive is Sata Rev3 / 6Gb with some exceptions being ODD's The utility SSD-Z implements it. Attached to Intel ICH10 sata Attached to Marvel SATA 6G Attached to JMI E-Sata

Interestingly enough, the fields are now visible, seems that this information is not presented by hotplugged drives?

This is resolved by 417.71+

Something strange with AIDA64's support of this. It seems aida64 lacks the active udma field on some drives declaring them to be running in MWDMA 0 or 2, meanwhile HDD Scan and HD Tune both agree that the current active mode is UDMA6 for those drives, and buffered read tests come back as expected.

yeah, there was an issue from 397.65 to 411.63.

what driver have you got installed?

this might be fixed in 411.63

Aida64 is just a victim to nvidia's unstable NVAPI code at the present time.

it doesn't point directly at anything. otherwise it would be FAULTING_PROCESS: Nvidia has made no mention of whether they have reproduced the issue with the reproduction steps so far. There is no announcement. You should read all posts within a thread before assuming something. There will not be a fix for this bsod coming from Fiery's side.

Spectre patch reduces this benchmark.

the spectre patch is not responsible for the util issue here, the effect of the patch halves performance of fpu vp8.

Try disabling screen power management.

It's not really Fiery's fault, but there some new information Re the cause It was a bit premature to mark this thread fixed just because an issue with 1803 was found and worked around, some of us are not even on Win10.