[PATCH] drm/nouveau/fbcon: fix oops without fbdev emulation

[Pavel Roskin]

Hi Daniel,

I meant Linux 4.13 of course, sorry! Can you fix the description for
me please? If not, I can resend the patch with the updated
description.

Let me add some context to my patch. My laptop is Dell Precision 7510
with dual graphics (Intel and Nvidia). The dock is connected to two
monitors with DisplayPort cables. It used to be two identical Dell
P2416D monitors with 2560x1440 resolution. One of the monitors is in
the vertical position. I've been using Fedora 26 with 4.11 and 4.12
kernels for a long time with no problems. The only issue was that the
outputs would change names on reboot (e.g. DP-1-1 would become
DP-1-4). I solved it by configuring all combinations in Gnome display
settings. I also copied the resulting monitors.xml to the gdm
repository to have the correct orientation in gdm.

A few days ago, I changed one of the 24-inch monitors (the horizontal
one) with a wide Dell U3417W monitor with 3440x1440 resolution. The
monitor would come up blank on some reboots (the monitor would show
that it was not getting any signal and would go to power saving more).
So I decided to update to Fedora 27 prerelease with 4.13 kernel.
Things got even worse. The blank screen issue was not resolved, but I
also started getting messages about circular dependencies:

======================================================
WARNING: possible circular locking dependency detected
4.13.3-300.fc27.x86_64 #1 Not tainted
------------------------------------------------------
Xorg/1032 is trying to acquire lock:
(&dev->struct_mutex){+.+.+.}, at: [<ffffffffc00bddfa>]
drm_gem_object_put_unlocked+0xa/0xb0 [drm]
                                     but task is already holding lock:
  (reservation_ww_class_mutex){+.+.+.}, at: [<ffffffffc0329cc2>]
validate_init.isra.5+0x202/0x740 [nouveau]
                                     which lock already depends on the new lock.

I tried the current mainline kernel (4.14-rc1 at that time), and it
started making oopses in nouveau_fbcon_set_suspend_work(). It that
point, I wasn't using the dock. Then I realized that the 4.14-rc1
kernel wasn't showing "nouveaufb" in the log, whereas 4.13 was. The
4.14-rc1 kernel registers nouveaufb only if I use the dock.

I tracked the issue to nouveau_fbcon_accel_save_disable() trying to
dereference drm->fbcon->helper.fbdev which was NULL. Once I fixed
nouveau_fbcon_accel_save_disable(), oops started happening in
nouveau_fbcon_accel_restore(), which I fixed as well. I haven't seen
oopses in nouveau_fbcon_accel_fini(), but maybe it's just because that
code wasn't called, so I added a check there as well.

Then I read the description of commit 52dfcc5ccfbb ("drm/nouveau: fix
for disabled fbdev emulation") and decided to try Linux 4.13 with
CONFIG_DRM_FBDEV_EMULATION disabled. As expected, it was oopsing
without my patch (without the dock).

I've been running the patched Linux kernels (now 4.14-rc2) for a day
with no issues other than the blank screen. I work it around by
changing the display orientation in display properties to portrait and
back to landscape. I hope to get it fixed, but let's deal with the
oops for now.

I'm thinking of bisecting the circular dependency issue to get it
backported to Linux 4.13. That would benefit other Fedora 27 users. If
you know what patch fixed it, you would save me some time.

Pavel