Created attachment 117104 [details] dmesg output from start to connecting the two monitors, then disconnecting the VGA monitor I am using a Lenovo W520 on Fedora 22. What I'd like to be able to do is close the laptop's display and use two external monitors. I know that Optimus is troublesome in Linux, so I have disabled it, and am using discrete graphics only (Nvidia Quadro 1000M, 108GLM). When I plug in the first of the two external monitors via the Displayport (converted to HDMI), everything works fine; I am able to use the laptop's internal display and the external monitor. When I plug in a second display via the VGA port, all of the screens go blank for a time, and then only the Displayport-connected monitor comes up. It is usable for about 10 seconds, and then the internal display shows some boot up messages, and the displayport-connected monitor shows the desktop, but I cannot type anything. About every three seconds, all screens blank out, and then the process repeats. My next step is to then disconnect the VGA monitor, and after about 10 seconds, it puts me back at the Gnome desktop login. From there I was able to log back in and get the dmesg output (attached). Looking at the dmesg output, there is a segfault in libmutter. Perhaps this is what is causing the problem. I don't know.
xorg-x11-drv-nouveau-1.0.11-2.fc22.x86_64 is what I have installed
While "going crazy" is rarely the right thing to do, I'd like to point out that a GF108 only has 2 CRTC's and thus can only ever power 2 different screens at a time. (There might be a way to drive 2 identical screens at once from a single CRTC, not sure.) I suspect a negative interactions with gnome which might get confused about such a restriction.
(In reply to Ilia Mirkin from comment #2) > While "going crazy" is rarely the right thing to do, I'd like to point out > that a GF108 only has 2 CRTC's and thus can only ever power 2 different > screens at a time. (There might be a way to drive 2 identical screens at > once from a single CRTC, not sure.) Yeah, I realize that. Just as a reference point, two external monitors works fine with Windows 7, even with just the Nvidia chip enabled (discrete graphics). With Optimus enabled, I can actually drive all three monitors simultaneously. > > I suspect a negative interactions with gnome which might get confused about > such a restriction. Maybe so. Thanks for your input :)
I bet it works if you first disable one of the screens before plugging a third one in.
(In reply to Ilia Mirkin from comment #4) > I bet it works if you first disable one of the screens before plugging a > third one in. I had tried that experiment before, but I just now tried it again. Same bad result. Here are the steps I took. 1) Boot laptop with no external monitors connected. 2) Attach Displayport-connected monitor. All is well. 3) Disable internal monitor. All is still well... now using only the external monitor. 4) Plug in VGA monitor. 5) Nothing happens. 6) I bring up the Gnome Displays setting (not clicking anything yet), then the system starts with its display resetting (or whatever it's doing), and becomes unresponsive to keyboard input. 7) The only way to get back to a usable system is to disconnect the VGA display, which after 5-10 seconds gets me back to the Gnome login, and after logging in I was able to capture the dmesg output (will attach).
Created attachment 117105 [details] Similar as first log, but this time I disable the laptop's display before adding the second monitor
In both of these log files is a line like the following: 48.693955] nouveau E[ PDISP][0000:01:00.0] INVALID_STATE [UNK05] chid 0 mthd 0x0080 data 0x00000000 Followed by a dump of what appears to be internal Nouveau driver state: [ 48.693960] nouveau E[ PDISP][0000:01:00.0] Core: [ 48.693966] nouveau E[ PDISP][0000:01:00.0] 0x0084: 0x019e02e2 -> 0x00000000 [ 48.693972] nouveau E[ PDISP][0000:01:00.0] 0x0088: 0xf0000000 [ 48.693973] nouveau E[ PDISP][0000:01:00.0] Core - DAC 0: [ 48.693978] nouveau E[ PDISP][0000:01:00.0] 0x0400: 0x00000000 [ 48.693984] nouveau E[ PDISP][0000:01:00.0] 0x0404: 0x00000000 [ 48.693989] nouveau E[ PDISP][0000:01:00.0] 0x0420: 0x00010000 [ 48.693990] nouveau E[ PDISP][0000:01:00.0] Core - DAC 1: [ 48.693995] nouveau E[ PDISP][0000:01:00.0] 0x0480: 0x00000000 Is this normal behavior?
Apologies for jumping in on another bug report, however this sounds exactly like the problem I've been struggling with for years on my Lenovo T420s: https://bugs.freedesktop.org/show_bug.cgi?id=56615 I see the same symptoms in that the kernel "hangs" with an external DisplayPort connected in discrete mode when trying to use the internal LVDS with the external monitor. It seems the message I get in the kernel log is similar too: nouveau E[ PDISP][0000:01:00.0] chid 1 mthd 0x0080 data 0x00000000 0x00005080 0x0000000
(In reply to Mark Cave-Ayland from comment #8) > Apologies for jumping in on another bug report, however this sounds exactly > like the problem I've been struggling with for years on my Lenovo T420s: > > https://bugs.freedesktop.org/show_bug.cgi?id=56615 > > I see the same symptoms in that the kernel "hangs" with an external > DisplayPort connected in discrete mode when trying to use the internal LVDS > with the external monitor. It seems the message I get in the kernel log is > similar too: > > nouveau E[ PDISP][0000:01:00.0] chid 1 mthd 0x0080 data 0x00000000 > 0x00005080 0x0000000 Yeah, it does seem similar. However, in my case, a single external monitor along with the internal LVDS works fine.
A few people who have had these PDISP errors were due to gnome toggling cursor state when a CRTC had not been enabled, and nouveau not properly protecting against it. There was a (lost) patch that fixed it, unfortunately I don't remember where the place was. Ben should be able to come up with that patch fairly easily. However for the user in question, while the PDISP error dumps went away, the underlying problems remained. Just a thought. [As an aside, Corey, with reverse-prime you should also be able to get all 3 screens up... see http://nouveau.freedesktop.org/wiki/Optimus/ . Of course nothing is perfect, this also introduces tons of problem for some people. But not others.]
Created attachment 117123 [details] [review] potential fix for issue Yeah, in both those logs it's definitely the "something is turning on the cursor without a mode set" issue. Completely untested patch attached.
(In reply to Ilia Mirkin from comment #10) > [As an aside, Corey, with reverse-prime you should also be able to get all 3 > screens up... see http://nouveau.freedesktop.org/wiki/Optimus/ . Of course > nothing is perfect, this also introduces tons of problem for some people. > But not others.] My thought was if I cannot get this "simpler" mode to work without any fancy stuff happening, I stand little chance of getting the Optimus stuff working. That said, thanks for the suggestion :) Tonight I will see if I can use just the integrated video (i915, I guess) for both external displays.
(In reply to Ben Skeggs from comment #11) > Created attachment 117123 [details] [review] [review] > potential fix for issue > > Yeah, in both those logs it's definitely the "something is turning on the > cursor without a mode set" issue. > > Completely untested patch attached. Ok, I will see if I can build the code with this patch. Thanks :)
(In reply to Corey Ashford from comment #12) ... > Tonight I will see if I can use just the integrated video (i915, I guess) > for both external displays. I tried using just the integrated driver, and it seems to only know about the LVDS display. So that's out.
(In reply to Corey Ashford from comment #13) > (In reply to Ben Skeggs from comment #11) > > Created attachment 117123 [details] [review] [review] [review] > > potential fix for issue > > > > Yeah, in both those logs it's definitely the "something is turning on the > > cursor without a mode set" issue. > > > > Completely untested patch attached. > > Ok, I will see if I can build the code with this patch. Thanks :) Well, I was able to apply the patch to the kernel and build it, but after I installed the new kernel, and rebooted, I wasn't able to get past the luks disk decryption. So I don't know what I did wrong, but in any case that kernel will not boot. I'm sure it's not related to the patch; it's that I don't know how to correctly build the kernel.
Ben - thanks for the patch! I managed to find a few minutes to test the patch at comment #11 today and unfortunately it didn't fix the issue for me. I'll post the updated information back over at bug #56615 so it's all in one place.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/201.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.