Trials and tribulations installing a 1070 in a M6800

Managed to track down that the source of the random crashes is a BSOD with VIDEO_TDR_FAILURE in nvlddmkm.sys, similar to what @Aaron44126 has seen with his P5000.

 

So, it's not just me... Though, I've never experienced a BSOD while gaming (on the laptop display with Optimus). It only has occurred when I have a display connected directly to the NVIDIA GPU. (This is the case when I am docked and working, and normally in this case the NVIDIA GPU is only under an extremely light load, regular desktop applications.) Is that the case for you, either external display or Optimus off?

I'd feel better if this could be figured out and solved properly. However, none of the hints that I have found online have been of any use. You can increase the TDR timeout in the registry, but all that has done for me is increase the length of time that I experience a short freeze before the system crashes.

[Edit]
Were you not seeing the actual BSOD? In my case the BSOD appears on the laptop display (connected to Intel GPU); the NVIDIA-connected display retains the image that appeared before the crash until the system reboots. Wondering if you only have an NVIDIA-connected display, the BSOD might be "invisible" and only show in the crash dump log?

 

I think you are correct. When I was running with Optimus disabled, the screen would simply freeze until it eventually rebooted. Once I got Optimus running and had it enabled, then I would see the BSOD with the error message.

I've only seen the error while gaming, and it's usually within the first few minutes.

 

There's a bit more technical info about that error here: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x116---video-tdr-error

 

Yes, basically Windows detects that the display driver is hung up, gives it a period of time to get unstuck, and then BSODs if it does not. Question is, why is the NVIDIA driver specifically getting stuck in this case?
When you had Optimus enabled, did you have any external displays connected when you got this BSOD, or were you running with the laptop display alone?

I'm capable of opening a stack trace from the memory dump to poke around, but not capable enough to understand what I am looking at.

 

Just laptop display alone. I'll do some more testing with external displays.

 

Ok, just looking for commonalities...
I've only ever gotten this error with an external display connected, never with the laptop alone (and I've done a fair amount of gaming with the laptop display alone).

 

I game with my M6800 as well but never got BSOD thus far. I haven't tried connecting an external display to it docked or not. Did you see the same thing when undocked and with an external display connected directly to your M6700?

Does your dock come with USB3 ports or is it the dock with just USB2 ports?

 

I never use an external display undocked. I could try it but I have no idea how long it would take to reproduce the BSOD. I've had cases where it goes 2 or 3 weeks before it occurs.
Pretty sure my dock has USB3 ports but I don't think that it would matter, the dock in this case (unlike the newer Thunderbolt docks) doesn't do any processing, it's just a port replicator, so, exposing ports that are already present on the motherboard but only exposed through the dock connector.

I've been trying to come up with theories as to why this BSOD might be happening with these Pascal cards while previous cards were totally stable. The idea that my card is physicially defective seems less likely now that @JEAMN has reported BSOD's with the same error message.

We know that this card draws more power than other cards. I'm wondering if something power-related could be going on that sometimes causes the card to basically lock up. That would be why the image basically freezes on-screen until the system is rebooted, and the NVIDIA display driver basically stalls (causing Windows to BSOD with the video time out detection error). Maybe it is not total power draw (we already know that the system can be stable under a full GPU load), but sudden changes in power draw, or maybe sudden changes in power draw while the CPU is already really busy? Maybe it is just more likely to happen with the 1070 and its higher clock speed?

This would explain @JEAMN's BSOD while gaming more than it explains mine. I've only ever gotten it with a display connected to the NVIDIA GPU while doing light office work. Now, while the NVIDIA GPU is actually driving the desktop, I suppose that there is a chance that it decides to kick into the maximum performance state temporarily for whatever reason, and that could be when this happens? Unfortunately this would be difficult to check since the BSOD is so infrequent.

I've done tens of hours of gaming on this card (single-display with Optimus) and never had a crash. However, none of the games that I've been playing have really been pushing this card to the limit. In the last coule of months I've played StarCraft II on and off and also played through A Hat in Time, and when frustrated that both of these games had moments of below 60 FPS on my new card, I dug in and found that both of them seem to be performance-limited on the CPU side. So, maybe I haven't been trying hard enough to get a BSOD with a single display on Optimus. I'll try to find some time this soon to run some extended stress tests.

@JEAMN, what games are you trying that cause the crash?
Then there's the fact that you are here reporting that you have never had a BSOD. Are any of your games graphically intensive enough to be pushing the P5000 to near-max load?

I'm wondering if underclocking and/or undervolting the GPU so that it's power draw stays within or closer to the expected limits might be the solution to this problem... It might not take much since it already seems to be sort of hard to trigger this BSOD.

[Edit]
I think that I am going to try forcing the NVIDIA GPU to sit in the P8/idle state while docked and see if that keeps the BSOD away. (I don't game while docked, that is just for working.) I believe that NVIDIA Inspector's command-line options allow for this and I can probably script it to happen automatically when a certain device is connected or disconnected.

 

Working down the path of limiting the GPU speed and power usage to see if that has any impact on this BSOD.

I had used NVIDIA Inspector to force a specific P-state before and I still had my commands lying around.

Force P8 (idle state):
nvidiaInspector.exe -forcepstate:0,8

Set back to auto state selection:
nvidiaInspector.exe -forcepstate:0,16

These commands seemed to have no effect on my P5000, after attempting to force P8 then it would still hop up to P0 if I launched any graphics app. I Googled and found many other users complaining that forcing P-state with NVIDIA Inspector just plain doesn't work anymore with Windows 10. Then I found this gem post, turns out that all you have to do is swap the .NET version from 4.0 to 4.5 in the config file and then it starts working fine in Windows 10. (This worked for me.)

Normally when my card is sitting idle at the desktop, then it will go to P8 and the GPU core will sit at 139 MHz. With the card "locked" in P8, the GPU core stays a bit higher at 608 MHz. However, it does not budge if I fire up a graphics app. NVIDIA Inspector options to change the clock speed of the GPU core don't seem to work, it always resets back to the original value if I try to change anything.

I played around with nvidia-smi which has some interesting options but both the system-wide "lock the speed" or "power limit" options are reported as unsupported on this GPU. You are able to set a "recommended" core speed with the command nvidia-smi -ac, I tested this by setting it to the minimum level nvidia-smi -ac 405,139. It did go above 139 MHz but it did not go above the 700 MHz range on my quick/light test. This might be a way to lower the clock speed "a little" in order to reduce the power draw to acceptable levels.

ANYWAY. I will run with the system locked in P8 with NVIDIA Inspector while I am docked and hooked up to my external screen via DVI, and see if that solves the BSOD issue. If it does then maybe we have something to go off of for a less extreme solution.