Created attachment 1765702 [details] dmesg when logging in 1. Please describe the problem: I just upgraded my Lenovo P50, which has two GPUs. One Intel GPU connected the laptop panel; one Nvidia GPU connected to the HDMI port. After upgrading to F34, (going from 5.9 to 5.11), the external monitor fails to turn on. The issue happens both with the regular GNOME session, as well as the GNOME (X11) session. When using the Wayland session, gnome-shell, mutter fails to set the mode. The call to drmModeSetCrtc() fails with "Device or resource busy". When using Xorg, xrandr reports the external monitor as connected, but attempting to enable it via xrandr, the xrandr command (xrandr --output DP-2-1 --auto) fails with an error similar to that of gnome-shell (failed to set crtc). 2. What is the Version-Release number of the kernel: I have tried kernel-5.12.0-0.rc4.175.fc35.x86_64 and kernel-5.11.7-200.fc33.x86_64. 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : I upgraded from kernel-5.9.12-200.fc33.x86_64 to kernel-5.11.7-200.fc33.x86_64 today, and today is when it started to happen. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Boot. During the startup spinner, the external monitor is active. Once reaching GDM, it turns off. Logging into the regular session or the X11 session makes no difference. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: 6. Are you running any modules that not shipped with directly Fedora's kernel?: 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag.
Proposed as a Blocker for 34-final by Fedora user jadahl using the blocker tracking app because: The issue makes external monitors not work with Lenovo P50.
Created attachment 1765845 [details] journal -k with drm.debug=0x16 Attaching `journal -kf > log` with `0x16` placed in the drm.debug param, then starting plain mutter which call to `drmModeSetCrtc()` fail with "Failed to set mode 1920x1080_60.00 on CRTC 50: Device or resource busy".
Sooo.. turns out this is a problem with zink. If the display offloading GPU doesn't support OpenGL for whatever reason (like Nvidia Ampere GPUs with nouveau atm) we get two OpenGL contexts for each GPU, just that the intel one gets an iris context and the nouveau one gets a zink on anv context. And this prevents mutter to detect that the second GPU can't do acceleration as it used to get llvmpipe on mesa builds with zink disabled.
fyi: this is not a P50 specific issue, Jonas just hit it because nouveau.noaccel=1 was added to the kernel which effectively disables acceleration and behaves for this case the same as for GPUs with KMS but without OpenGL support.
so, discussed this upstream and the proposal is to disable zink for mesa at least for 21.0 in fedora and other solutions within mesa will follow as well later on.
I can confirm that mesa-21.0.1-2 fixes the issue here.
Can we get that built and submitted for F34 then? Thanks!
(In reply to Adam Williamson from comment #7) > Can we get that built and submitted for F34 then? Thanks! dave already merged it into the f34 branch.
FEDORA-2021-a9c73aabb7 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a9c73aabb7
I went ahead and submitted the new mesa build to bodhi to get the fix out.
thanks, Kalev. Karol, "merged" is not the same as "built and submitted as an update" - this is a Final blocker, we needed to get the fix actually built and submitted and off the blocker list ASAP, it's no fun doing it at the last minute.
(In reply to Adam Williamson from comment #11) > thanks, Kalev. Karol, "merged" is not the same as "built and submitted as an > update" - this is a Final blocker, we needed to get the fix actually built > and submitted and off the blocker list ASAP, it's no fun doing it at the > last minute. sure, but I don't have access rights myself, so I always have to find proxies and I assumed Dave already took care of it.. oh well.. I am working on getting the proper rights in order to handle that more quickly in the future. Sorry for the delays.
Discussed during the 2021-03-29 blocker review meeting: [0] The decision to delay the classification of this as a blocker bug was made as we are waiting on the reporter to report status with a new mesa build here. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-03-29/f34-blocker-review.2021-03-29-16.00.txt
Karol: ah, sorry, didn't realize you didn't have the privs.
FEDORA-2021-a9c73aabb7 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a9c73aabb7` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a9c73aabb7 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-a9c73aabb7 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.