Odd DisplayPort Grub2 boot issue

Hardware GPU
1

Just got myself a new 4K VA panel monitor and unfortunately could not use it on my main UEFI based rig so I had to salvage my P55 I7-860 system and load Ubuntu 18.04 on it. I knew going in that Nouveau was the number one source of headaches so I disabled it with nomodeset and nouveau.modeset=0.

Initially, I had a GTX 1060 driving the panel and all was fine. The panel woke up from sleep, showed the BIOS screens and immediately entered BIOS based Grub2 with no issues.

However, (slight tangent) I was going to test my GTX 1080 11Gbps with the new monitor on my actual UEFI rig but that did not come to pass, as Canada Post decided to not deliver ON CHRISTMAS EVE, the day my replacement CPU was supposed to arrive according to the parcel tracking. It still hasn’t shown up and Canada Post took a 3 day break while tons of parcels are backlogged due to a strike earlier in the month.

So I slapped my GTX 1080 11Gbps on the P55 i7-860 system because I had no other choice, and with DisplayPort connected, Grub2 would fail to post. The BIOS screen was fine, but as soon as it got to Grub2, it would hang.

Switched the connectors to HDMI and there were all of a sudden no more issues, but I don’t trust HDMI as much as I do DisplayPort.

Looked online and this seemed to be a common problem with no real solution other than to change GPUs… and was VERY common with 4K panels.

One comment on one of those threads wanted to point out a power rail that the monitor sends BACK to the GPU could be causing some problems. So I turned off the monitor on boot and sure enough… IT BOOTED.

This was also a common solution to those that managed to figure it out.

Also, keep in mind I set nomodeset, so Nouveau is not a factor in this issue.

My question is, is this exclusive to BIOS based systems or does it affect UEFI the same way? (I have to ask this because the Canada Post strike means I have no clue when I’m getting my CPU for testing the UEFI platform) And if it’s indeed the power rail, would a DisplayPort “condom” (a connector that only carries data, not power, to the GPU) be able to help this situation? HDMI I know carries power through the cable but it has not had ill effect unless you’re connecting a output to an output. This is the first I’ve heard of DisplayPort sending voltage back to the GPU FROM the monitor. I tested with my EDID Emulator to see if the monitor was sending back voltage over HDMI and that was not the case.

This is something I think @wendell should investigate cause the fact that this is affecting POST negatively is worrysome.

2

I think I’ve heard of this before, and the solution is to get a certified cable which conforms to the standard and does not have a wire connected through on pin 20.

See https://en.wikipedia.org/wiki/DisplayPort#DP_PWR_Pin

3

Wait. Mine is DP 1.4 certified from Club3D. So this means it’s actually non-standard?

https://www.club-3d.com/en/detail/2430/displayport_1.4_hbr3_cable_m-m_2m-6.56ft./

I’ll try with a DP cable from a old ASUS ProArt monitor to double check.

Edit: Nope. Same symptom. Might be a EDID issue instead. It’s odd that my GTX 1080 has this problem and my GTX 1060 doesn’t have this problem.

Edit 2: Tried re-enabling DDC/CI and enabling DisplayPort 1.1. (which actually did change the resolution on boot) No dice.

4

both cards have the nvidia dp firmware update?

5

None of them do, but the 1060 does not have the issue. I purchased my 1060 in September 2016, and the 1080 in December 2017.

I don’t have access to Windows at the moment, only Ubuntu 18.04.

The problemed card is the exact same one you have, Wendell, the ASUS STRIX GTX 1080 11Gbps.

I want to know if this issue persists with UEFI or is it exclusively with BIOS based systems… Only have access to a BIOS based system because CANADA POST.

I guess this is one of the first growing pains of Linux… Proprietary firmware updates still need Windows.

6

what motherboard? asus have a uefi graphics mode option to not set graphics mode from the uefi. otherwise it’ll set like 1080p or something like that which is high def.

7

I might have experienced something similar a couple of weeks ago. Using a 1440p monitor over DP and a 1080p monitor over DVI would make GRUB hang. Windows 10 would boot directly (selected as a custom boot option). I then had a look around at my UEFI settings (I have an Asrock Z170 Fatal1ty mITX board) and noticed that the CSM was still enabled, so turned it off (since all of my systems are UEFI aware) and GRUB boots up perfectly fine.

EDIT: forgot to mention, GPU is an nVidia GTX 1060 6GB

8

What I currently run is pre-UEFI. The EVGA P55 Micro. Normally I run a X79S-UP5-WIFI, but that’s not available to me right now due to broken CPUs for it.

Through the HDMI, the BIOS sets the resolution to the GPU as 1280x1024 and it boots fine on the STRIX 1080. On the 1060 though, no modifications were needed and it upscaled 640x480 from the BIOS to full 4K over DisplayPort and went through all the BIOS screens to BIOS grub just fine.

9

That points to a incompatibility with BIOS based systems, but then my 1060 does this just fine on a BIOS based system… Only my 1080 is having issues with BIOS based systems.

If what you’re saying is true, Trying to boot MBR Windows 7 on my UEFI system would mean the same result. I installed UEFI though for all my other OSes.

10

I STILL don’t have my replacement CPU for my UEFI system because the unions are still picketing preventing any mail delivery… I got my 4K display before the CPU capable of driving it with a GTX 1080.

Goddamn Canada Post related unions.

11

Just noticed something with the HDMI ports on my STRIX GTX 1080 11Gbps. According to Cinnamon/GNOME, The topmost (rightmost) HDMI port is Port 2 for HDMI numbering according to the Nvidia driver, but it’s Port 1 for HDMI audio according to the HD Audio drivers in Linux.

It’s vice versa for the 2nd HDMI port, where the NV driver detects it as port 1, but the HD Audio driver detects it as port 2.

There’s some funkyness going on with the HD Audio port mapping on this card. Whether that relates to this issue I have no idea, but I wanted to point that out.

I had no problems with cards using the default display output set (3x DP, 1x HDMI and 1x DVI) using the DP-0 (DisplayPort out #1) on the top/right of the card. (The GTX 1060 I had from EVGA worked fine) DP-0 doesn’t exist on the STRIX in the same way, so I’m wondering if it’s a port mapping issue.

12

Canada Post has lost my CPU.

I’m now stuck on a BIOS based system with Ubuntu and will not be able to test anything else.

In order to avoid shipping with Canada Post, I have to ship to Blaine, Washington and I have border issues, so I’m unable to cross alone to setup a receiving shipping address there cause guards there have stereotyped me as “Look at that Asian, he’s commin to steal err jerbs!”

FML.

13

Okay, back up and running with a 4960X instead of a E5-1660 V2 and I can confirm GRUB and Clover for OSX using UEFI has no more issues over DisplayPort. This was limited to the BIOS P55 system and it’s handling of GRUB.

Legacy Boot on UEFI also works. It’s just an oddity with BIOS GRUB on BIOS systems.

14

Brief bump:

Turns out this issue is apparent AFTER flashing the DisplayPort patch for 1.3 and 1.4 on Pascal GPUs. If the patch isn’t applied, BIOS based systems have no problems here, but after flashing the DisplayPort fix, this breaks BIOS Grub to be non-functional. UEFI Grub of course isn’t affected.

I did the flash after TianoCore didn’t show anything upon VM boot on my recently acquired GTX 1080 Ti, and it was fixed after flashing the DisplayPort patch, but it breaks BIOS Grub if you ever put the card on a BIOS based system rather than a UEFI one.

15

I also observe a problem with nvidia card and GRUB2 in BIOS. Please see here:
devtalk_nvidia_com/default/topic/1066548/linux/upon-boot-up-only-30-hz-on-4k-display-connected-via-dp/2

It is a Quadro K420 with firmware: 80.07.f0.00.04.

@FurryJackman: You related the DP patch with the GRUB2/BIOS problem. Is is worth downgrading the vbios. To which one?

16

The patch permanently patches your VBIOS to enable DP 1.4. You need to find a unpatched VBIOS from before the utility was released.

But the better thing is for the GRUB maintainers to fix the issue since it’s only GRUB that has this issue if you boot using a BIOS only motherboard.

17

Yes, I did file a bug, but nobody seems to care. Do you know where I find the previous vbios?

18

Jesus. Looks like this is another problem that will never be solved.

For Quadros, Techpowerup is NOT the place to get BIOSes because that’s mostly for consumer cards.

This could be the end of the road for you, because there is no solution.