"You are not currently using a display attached to an NVIDIA GPU" p870dm-g 4k panel

I have been having this issue ever since I installed a 4k panel in my p870dm-g. I posted about this a couple of months ago but haven't gotten a chance to follow up until now. @aarpcard has been helping me to try to resolve this problem and he contacted @Prema on my behalf.

Initially after I installed the 4k panel, my graphics cards were stuck in a low power state and weren't being detected by the Nvidia drivers. Through searching the forums and with Prema's input, and others, it seemed the issue was due to the 4k panel's device id not being listed in the bios as g-sync compatible ( or something like that). Prema sent an altered bios to flash that he said should resolve the issue. After flashing the bios, I installed the 365.10 Nvidia driver and it worked perfectly including g-sync.

The problem that I am having now is that is whenever I install a driver later than 365.10, upon restarting my computer, the new driver does not detect my video cards. Windows Device Manager shows them as having a problem, but doesn't say anything specific. If I try to open Nvidia control panel, I am met with the error: "You are not currently using a display attached to an Nvidia GPU." So far this has been the case with every single driver that I have tried since 365.10.

Here's what I have done to try to to resolve the issue so far:

- Wiped my hard drive and installed a fresh copy of Windows 10 64 bit
- Installed 378.66 onto the fresh copy of Windows (issue persisted)
- Uninstalled 378.66 using the Nvidia uninstaller and DDU
- Installed 365.10 (issue fixed as expected)
- Connected an external monitor and disabled my 4k panel
- Installed 378.66 over the existing 365.10, thinking that if the 4k panel was the source of the problem, then having an external monitor connected and the 4k panel disabled while running a driver that works might allow the newer drivers to install correctly (didn't work, same issue)

-I left my computer to sit overnight and install Windows updates. In the morning, I noticed that Windows had automatically installed 376.54. Interestingly, these drivers worked. I thought that maybe the Windows updates had fixed the problem. So I made a restore point and then installed 378.66. The issue returned. I then did a system restore back to 376.54 and now 376.54 exhibited the same problem.

I have basically tried everything I can think of and I am hoping that someone here would be able to shed some light on this. Whatever the problem is, there was something that was changed after the 365.10 driver that is preventing them from working. I don't know if it is related to the 4k panel and g-sync and the bios I flashed from Prema or if it is something else completely.

Any help/insight at all would be appreciated. Thanks in advance!

 

Have you already tried a @j95 desktop driver mod to see if it corrects your problem? If not, please do.

https://www.techinferno.com/index.p...ort-modded-inf/&do=findComment&comment=156562

Be sure to follow all of his instructions explicitly or it will not work as expected.

 

Thank you for your response.

I think I followed j95's instructions properly, but it did not fix the problem. However, strange things happened. Here is what I did:

- Reflashed Prema's latest v2 Clevo dm gtx980m g-sync vbios's
- Booted into Safe Mode and Enabled the legacy boot menu with command prompt
- Uninstalled the current Nvidia drivers with DDU and restarted
- Selected Disable Driver Signature Enforcement from the boot menu
- Downloaded the Windows 10 378.66 driver that j95 had linked in his post
- Extracted the driver and removed the folders he specified
- Downloaded the custom .inf files for Clevo Windows 10 that j95 had listed on his post
- Copyed those files into the Display.Driver folder and overwrote the existing .inf files
- Ran the setup .exe as Administrator

Here is what happened: As the driver installed Windows security popped up and asked if I trusted the installation. I selected yes and the installation continued. When it was finished I restarted the computer and tried to open Nvidia control panel. This time, it did not give the error, but it also refused to open. I opened up GPU-z and noticed that it seems that somehow the laptop 378.66 driver was installed/ remained installed for the primary graphics card and the modded .inf desktop driver was installed for the secondary graphics card.

Also strangely, the primary as shown in GPU-z and device manager is being detected as Microsoft Basic Display Adapter while the secondary is correctly labeled as a gtx980m.

I am not really sure what this means. Did DDU fail to completely uninstall the 378.66 notebook driver even though everything indicated it had?

Here are the GPU-z screenshots.

Primary gtx980m


Secondary gtx980m

 

Yeah, something is not clicking with the drivers so it thinks a card without drivers is driving the panel. Have you tried running a single card or swapping the cards over?

 

Could this maybe have anything to do with the drivers not recognizing the screen's edid as g-sync compatible?

As far as I can remember this is a aou B173ZAN01. 0 panel. I was reading on the forums that the g-sync part number for that panel is B173ZAN01.1 and that it has a different edid.

What do you guys think about trying to get that edid and flashing it to this screen?

EDIT: Seems I have that backwards. B173ZAN01.0 is the g-sync part number.

Maybe it's still worth a shot flashing the other edid though?

 

Not sure what the problem is with the one GPU. Please check the hardware ID of each GPU to be sure they are exactly the same. Driver should have installed for both GPUs. I have not seen that before. If hardware ID is exactly the same on both, the one without the driver may have a problem.

If they are the same take out the card that is not accepting the driver and put the one that is in the master MXM slot. See if the driver works and see if G-sync works.

Then put the GPU you removed in the slave MXM slot and see if it still has a problem. Don't clean up and repaste for testing . Wait until you are done testing functionality.

The one GPU could be causing your issues. You followed the instructions correctly.

 

I swapped the master and slave cards, redid j95's driver installation procedure and everything worked. I am so confused.

 

can you check if you have flashed a different vbios on the primary card?

 

The vbios are identical on both cards. It is version 84.04.88.00.C1

 

Another update:

The 378.66 driver installation worked until a Windows update forced a reinstall of the 376.54 drivers and I was back to square one.

I performed all the suggested fixes and methods listed above, until I got it working with the 365.10 drivers and Windows 10 automatic updates disabled.

 

Determined that it is not a screen or g-sync issue. I disconnected the internal monitor from the motherboard and installed the 378.66 drivers via an external non g-sync monitor. The problem still persisted.

Next, I am going to try the cards in a different laptop and see if the problem follows the cards.

It is strange that 365.10 is still is the only drivers that don't have the problem. What's different about those drivers?

 

So by testing the cards in another laptop and individually, I determined that one of them was bad.

I bought a replacement GTX 980m on ebay. I installed the card today.

With both cards installed, whichever card in the slave slot would not be detected by the drivers. It didn't matter which card was in the master slot.

I finally figured out that it was probably due to the new card not being a g-sync card and/or having a different device ID. I created a modded .inf to include the new card's device ID and now both cards were detected by the drivers - however I couldn't enable SLI.

I'm assuming I can't enable SLI because the cards have two different device ID's. The new card is 13D7 and the other is 1617.

Is there anyway to enable SLI with two cards that have different device ID's? I'm more used to dealing with AMD cards where this isn't a problem? Is there a solution other than changing the ID resistors on the mxm PCB?

 

Get a GTX 1070 LOL

 

So I'm currently helping @TechnoKitteh sort this out. We've isolated the resistors and jumpers that seem to control the hardware ID's. Changing the card from 13D7 to 1617 will require pulling a 0 ohm jumper down to ground.

I want to try to avoid having to desolder the vbios chip and flashing it. So I'm not sure on the order of operations here.

Should we set the correct device ID with the jumpers first before flashing the card to a g-sync vbios, or should be flash the card first and then fix the ID jumper?

 

Fix the resistors first. That way you can flash the vbios the normal way, without desoldering and using the programmer.

 

So before we tried anything on the new card we decided to test this on the bad GTX 980m just so there weren't any surprises.

We were able to successfully change the Device ID from 10DE 1617 0871 1558 on the bad card to 10DE 13D7 0871 1558 by changing the 0 ohm straps.

(So in other words we decided to change the bad G-SYNC card into a non G-SYNC card just to make sure the procedure worked before trying it on the good card.)

The only hang up we are having is flashing the vbios. After changing the device ID to the non-g-sync device ID, when we try to flash the non g-sync vbios with NVFLASH, we are getting a ERROR: Board ID mismatch.

We also tried putting the straps back into the g-sync configuration and got the same error. We have tried turning write protect off with NVFLASH as well as using the -6 and -f commands to force the flash - to no avail.

Any ideas on how we can force the flash?

 

Which version is this? It's -5 to ignore device id on all versions, afaik.

If it doesn't help even after changing the ids, then do an erase first (-e). That way it can no longer verify against the current vbios and it has only the device ids set by the resistors to sail by. Think later versions of nvflash have ditched the erase option, but v4.46 still has it. Should also be possible to accomplish the same thing using fpt or flashrom.

 

So we tried everything and couldn't get a flash to work with NVFLASH, so we resorted to removing the vbios chip and flashing it in a eeprom programmer and then resoldering it.

Flashing the bad g-sync card with a non-gsync vbios and changing the ID jumpers resulted in a working non-g-sync card. (the card was still bad i.e. no 3D clocks, but this is independant of this issue).

So having confirmation that the process worked on changing a g-sync card to a non g-sync card, we went about doing the same thing to the non g-sync good card @TechnoKitteh bought on ebay.

Interestingly, with the non-g-sync card, changing the ID jumpers did not change the device ID. I spent several hours trying to figure this out, and didn't make much progress. Other than the ID jumpers, the circuitry and components on the g-sync PCB and non g-sync PCB are identical.

Setting the device ID to 13D7 requires pulling a jumper to ground which had been previously pulled high (not sure on the voltage).

On the g-sync PCB, pulling this jumper high or low will result in the device ID changing from 1617 to 13D7 and vice versa.

However on the non g-sync PCB, this did nothing. I pinned out the surrounding circuitry to try to build a schematic. I eventually found another node on the same conductive path as the high side of the jumper. Connecting the jumper to this path didn't do anything.

My best guess is there was something wrong with the circuitry on the card that was preventing that node from having the correct voltage. Measuring accross the jumper to ground on the g-sync PCB resulted in 16Mohms, while on the non g-sync PCB resulted in 8Mohms - so something was different, but after several hours of analyzing the circuitry and pinning things out, I couldn't find it.

So ultimately, we ended up leaving the non g-sync card as it was, and then changing her other good g-sync 980m to a non g-sync card by changing the jumper and flashing the vbios (by desoldering and resoldering the eeprom).

So her problem is basically resolved. She has two working GTX 980m's that run in SLI because now the have the same device ID's and any driver can be installed - just at the cost of g-sync.

I might play around with the jumpers on my non g-sync GTX 970m's to see if the issue was a fluke pertaining only to that PCB or if there is indeed something else that prevents non-g-sync cards from having the g-sync device ID by only switching a jumper. (It deosn't make sense that you can go one way, but not the other - especially if the schematics, as far as I can tell, are identical.)

NOTE: 365.10 is some real NVIDIA voodoo. Not only was it the only driver that allowed her bad card to function, but 365.10 allowed the GTX 980m with a mismatched Device ID and vbios to work perfectly as a slave in SLI.

Put the card in the master and the computer won't post because the vbios doesn't match the Device ID, but put it in the slave slot, and install 365.10 and it will function perfectly. That driver doesn't care. It's mental.

 

The tenacity of @aarpcard and @TechnoKitteh in working to get this issue resolved is really something to behold. Kudos to both of you for seeing this through to its absolute conclusion.

 

Thanks! - I'm glad we got something figured out.

I still don't understand why NVIDIA won't allow SLI between cards with different device ID's. Is this true for the desktop world too? Won't different board manufacturers have different device ID's?

Anyhow, if anyone is intersted in messing around anymore with this (and for sake of documentation) here's a picture of which jumper needs to be switched. Unfortunately it's a bit blurry. The 0 ohm jumper location is circled in red, and i marked the jumper itself with a red line. It is currently in the 13D7 (non-g-sync) position in this picture. Shifting it to the pad to the left (in this picture) will change it to the 1617 (g-sync) position. The vbios eeprom chip is the only SSOP8 package in this image.

 

Yes, Nvidia have only ever allowed the same core with the same number of shaders for SLI on both mobile and desktop.

 

So does that mean that ALL GTX 980 (desktop) cards for example, have the same device ID regardless of board manufacturer? If that's the case, what's the sense in changing that practice for mobile cards?

Purely hypothetical, I wonder if you changed the device ID on a GTX 970m to that of a GTX 980m and flashed it with a GTX 980m vbios - if you could SLI the two? Might have a problem if more than 6gb of VRAM was accessed, but other than that it sounds like it could/should work. . .

 

The chip and enabled units must be identical, it's done more on that level for desktop cards than board ID.

 

Out of interest what was the reason for desoldering the vbios chip prior to programming?

Didn't have sop8 adapter cable?
Bus prevented/interfered with in-place programming?


Frame pacing would be a big issue with different spec cards. It would lumber along like a V-twin in AFR

 

Yeah. we didn't have an adapter cable. I tried making one by soldering leads to the chip while it was in circuit, but the programmer refused to flash it once connected.

 

Haven't posted in a while, but I figured I should update this thread because the information on the fix is incomplete. . . didn't realize it was incomplete until the problem resurfaced.

It turns out the 0 ohm jumper for selecting the device ID of the GPU does not operate exactly like a toggle switch.

It almost seems like the signal from the jumper triggers a JK flip-flop or something similar.

We discovered that when you would initiate a soft restart of the laptop, the device ID would switch back to the original device ID of the MXM board regardless of which position the jumper was in. (This does not happen on hard restarts.) Switching the jumper to the opposite position when this occured would toggle the device ID. Jumper high does not = one device ID and Jumper low does not = the other device ID. Switching the jumper toggles between the two.

So in other words, there are two ways to change the device ID - by toggling the jumper on the MXM board AND by initiating a soft restart of the computer, however the soft restart will only revert the GPU device ID back to the original device ID of the MXM board.

Obviously this is annoying.

What we did to mitigate this issue was install two DIP switches externally on the laptop and wire them to each MXM board. We also modded the registry to remove the requirement to soft restart on new driver installations.

This way, if you ever accidentally do a soft restart, all you have to do is flip the DIP switches and the device ID of the GPU's will be switched back to the correct device ID preventing you from having to switch a soldered jumper.

I've also done this mod on my non-Gsync GTX 970m's in SLI to change them over to G-sync cards.