Hello, PopOS is on 460.73 nvidia driver version, seems that they are waiting until completely safe update. Anyone with this distro might not have any problem.
@amrits you mentioned that the issue is being worked on more than a week ago. Do you have any more information at this point? This is a severe regression that made its way into several major distributions, so it would be good to know if there will be a fix anytime soon.
I agree that this is a severe regression and that it needs to be fixed asap.
However, I think that the ones who shall take immediate action here are the maintainers of the distributions, since they are supposed to be the “shock absorbers” in these cases.
ESPECIALLY when the issue was already known from the previews in the testing branches: it has been unfortunate, if not irresponsible, that despite all the red flags that were raised they nevertheless made these drivers available to stable branches.
I would first blame Canonical, Manjaro, Arch & the others rather than push nvidia for a solution.
Nvidia may or may not be cooperative with the OSS community, but they are debugging something that is likely to be assembly language, and not high-level language… doesn’t look like to be trivial.
Yeah absolute madness to assume that a stable driver release from Nvidia does not contain severe regressions /irony_off . Always these fanboys that jump in to protect the reputation of their beloved company… I don’t care who to blame, I would just like to see better communication from the only party here that has insight into the code. On such a severe bug I would expect that they pull back the buggy drivers, instead I’m still offered 460.84 on the driver download page.
On such a severe bug I would expect that they pull back the buggy drivers, instead I’m still offered 460.84 on the driver download page.
Please, separation of concerns:
- not all users are affected: why should nvidia remove the possibility to download the drivers for everybody?
- package maintainers knew about the issue since the time the drivers landed into the testing branches, they were told not to promote them to stable, and they did that nevertheless.
Now, who is doing the worst communication here?
Always these fanboys that jump in to protect the reputation of their beloved company
How can nvidia be the beloved company of a Linux user?!
I ended up going through a full rollback process with the help of this article…
After initially re-configuring my default to 5.8.0-53 I eventually binned 5.8.0-55 entirely. I’ll run the upgrade again once this is all resolved and the newer drivers are being shipped with that upgrade else I’ll be stuffed again and won’t be able to get anywhere to fix anything.
This is running with the 460.73 NVidia drivers - all is well
I’d recommend for anyone on Ubuntu 20.04 to get ahold of 5.8.0-53 if you don’t have it already and try that out - If it’s all good, bin off the newer kernel until Canonical and / or NVidia have resolved this mess (which could take a while).
Same issue here. 1080Ti. Kernel 5.11.22-2-MANJARO #1 SMP PREEMPT. Dual 4k monitors on DP.
Reverting to 460.67 drivers has resolved it for now but this is extremely frustrating. This is the second time nvidia drivers have caused my PC to be unusable. You guys really need to improve your QA processes.
NO. We should pay THEM to do THEIR QA testing. Check your entitlement SMH!
If you’re using 473 then you’re not having the issue in this thread.
I assume you’re replying to the comment above yours, that’s what they’re referring to, the community doesn’t have it’s own QA testing, only nvidia.
Sorry > Brain melt - 460.73 works for me - Anything above that bricks the OS (main reply updated).
Currently working via an older kernel with a hold on 460.73 to stop upgrading. For some reason 473 keeps ringing around my head. Been staring at version numbers far too long…
I was being sarcastic about having to do QA for Nvidia while paying them.
Same issue here. When comparing two different Xorg log files (one from a successful boot with driver 390, another with a faulty boot with driver 460.80), I noticed the latter one stops just right before it starts listing monitors, which makes sense since I have a monitor plugged in via DisplayPort.
My solution, as others have pointed, was to use the nvidia-driver-460-server offered by Ubuntu, which is version 460.73.
I hope they fix this soon. Any fresh install of Ubuntu’s 20.04 to 21.04 are guaranteed to black screen on the first boot for DP users. I know because I did two myself.
OS: Ubuntu 20.04.02
GPU: GTX 1050Ti
Monitor 1: AW2518HF, 240Hz via DisplayPort, 1920x1080
Monitor 2: T24B350, 60Hz via HDMI, 1920x1080
Same issue on 460.80 and 460.84
OS: openSUSE Leap 15.3
GPU: GTX 1080
Monitor: Dell U3818DW, DP 3840x1600 24bit
Two months for such serious problem. It’s a shame… Just imagine this problem was for Windows - they would fix it in 24 hours…
I agree : nvidia driver is currently broken for most owners using DP connection and using a rolling distro (which are increasingly popular). Considering it’s a recent change, I am very surprised that it takes 2+ months to rollback the culprit change.
My 1080ti is long overdue for a change, but I am seriously considering switching to AMD : last gen is decent, and their linux support is much better.
Not just rolling distros but LTS distros like Ubuntu 20.04.
@aplattner you mentioned that this is tracked internally as bug no. 3302807. Is there any progress that you can share?
Same problem here, using Manjaro kernel 5.10.42-1-MANJARO and Drivers above 460.73
Also running 3 monitors on DP : 2 HP 27xq 2560x1440 and a Dell U2414H à 1920x1080
Only the Dell is working “alone” on DP, plug one or two HP monitors (with or without the DELL) crash the system
We all are loosing time to figure out the problem !
The lastest drivers working is 460.73
I ended up testing my display with ubuntu’s nvidia-driver-460-server and my second monitor remained disabled whereas it is enabled when I use NVIDIA proprietary driver v460.73 (installed manually) - same xorg.conf each time. So no DP problem here as my main display was enabled and connected to DP, but at least not the same behaviour as the non-server driver