Bug 1942175 - External monitor doesn't work on Lenovo P50 after upgrading to F34
Summary: External monitor doesn't work on Lenovo P50 after upgrading to F34
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mesa
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Karol Herbst
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F34FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2021-03-23 19:44 UTC by Jonas Ådahl
Modified: 2021-04-01 00:52 UTC (History)
32 users (show)

Fixed In Version: mesa-21.0.1-3.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-04-01 00:52:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
dmesg when logging in (5.30 KB, text/plain)
2021-03-23 19:44 UTC, Jonas Ådahl
no flags Details
journal -k with drm.debug=0x16 (90.64 KB, text/plain)
2021-03-24 08:43 UTC, Jonas Ådahl
no flags Details


Links
System ID Private Priority Status Summary Last Updated
freedesktop.org Gitlab drm nouveau issues 80 0 None None None 2021-03-24 09:11:28 UTC

Description Jonas Ådahl 2021-03-23 19:44:03 UTC
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.

Comment 1 Fedora Blocker Bugs Application 2021-03-23 19:55:07 UTC
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.

Comment 2 Jonas Ådahl 2021-03-24 08:43:16 UTC
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".

Comment 3 Karol Herbst 2021-03-24 18:04:13 UTC
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.

Comment 4 Karol Herbst 2021-03-24 18:05:45 UTC
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.

Comment 5 Karol Herbst 2021-03-24 18:18:46 UTC
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.

Comment 6 Jonas Ådahl 2021-03-25 07:24:31 UTC
I can confirm that mesa-21.0.1-2 fixes the issue here.

Comment 7 Adam Williamson 2021-03-27 00:58:48 UTC
Can we get that built and submitted for F34 then? Thanks!

Comment 8 Karol Herbst 2021-03-27 12:23:50 UTC
(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.

Comment 9 Fedora Update System 2021-03-29 16:32:11 UTC
FEDORA-2021-a9c73aabb7 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a9c73aabb7

Comment 10 Kalev Lember 2021-03-29 16:32:42 UTC
I went ahead and submitted the new mesa build to bodhi to get the fix out.

Comment 11 Adam Williamson 2021-03-29 16:45:18 UTC
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.

Comment 12 Karol Herbst 2021-03-29 17:05:59 UTC
(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.

Comment 13 Geoffrey Marr 2021-03-29 18:32:58 UTC
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

Comment 14 Adam Williamson 2021-03-29 23:51:09 UTC
Karol: ah, sorry, didn't realize you didn't have the privs.

Comment 15 Fedora Update System 2021-03-30 14:38:35 UTC
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.

Comment 16 Fedora Update System 2021-04-01 00:52:06 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.