[arrandale] desktop is messed up with external monitors (x86_64)

[Roland Dreier]

Binary package hint: unity

(I'm not sure where in the stack this problem really is, so I'm guessing and picking on unity)

I have a Lenovo T410s laptop with Intel graphics and I use it with a dock with two 1920x1200 monitors connected. I'm running up-to-date Natty. If I boot the laptop with it already docked, everything works perfectly: the two external monitors are used and I get a nice unity desktop spanning my 3840x1200 space.

However, if I boot with the laptop undocked, log in, and then dock the laptop, it breaks pretty badly. Only one monitor is lit up, and I just get a black screen with a mouse pointer there -- no desktop background, windows, toolbars, or anything. Once it's in this state, it doesn't seem possible to recover -- if I undock the laptop again, the internal screen just stays black with a pointer.

When the laptop is in a working state, undocking it sort of works... the desktop switches to the laptop screen, but then redocking it acts just like docking as described above.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: unity 3.6.8-0ubuntu3
ProcVersionSignature: Ubuntu 2.6.38-7.39-generic 2.6.38
Uname: Linux 2.6.38-7-generic x86_64
Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,decor,mousepoll,vpswitch,regex,animation,snap,expo,move,compiztoolbox,place,gnomecompat,wall,ezoom,workarounds,staticswitcher,resize,fade,scale,session,unityshell]
CompositorRunning: compiz
DRM.card0.DP.1:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
DRM.card0.DP.2:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
DRM.card0.DP.3:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
DRM.card0.HDMI.A.1:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
DRM.card0.HDMI.A.2:
 status: connected
 enabled: enabled
 dpms: On
 modes: 1920x1200 1920x1080 1920x1080 1600x1200 1680x1050 1400x1050 1280x1024 1280x1024 1440x900 1360x768 1152x864 1280x720 1280x720 1024x768 1024x768 1024x768 832x624 800x600 800x600 800x600 800x600 720x576 720x480 640x480 640x480 640x480 640x480 720x400
 edid-base64: AP///////wA4o1BnAQEBASUUAQOAOCN46pe1qVQ4riUTUFS/74CBwIGAkECLwJUAqUCzANEAKDyAoHCwI0AwIDYAMF4hAAAaAAAA/QAyTBpSEQAKICAgICAgAAAA/ABFQTI2MVdNCiAgICAgAAAA/wAwOTEwNjY4OE5BCiAgAV4CAQQAAR0AclHQHiBuKFUAMF4hAAAeAR0AvFLQHiC4KFVAMF4hAAAejgrQiiDgLRAQPpYAMF4hAAAYjArQkCBAMSAMQFUAMF4hAAAYAjqAGHE4LUBYLEUAMF4hAAAeAjqA0HI4LUAQLEWAMF4hAAAeAAAAAAAAAAAAAAAAAAAA/A==
DRM.card0.HDMI.A.3:
 status: connected
 enabled: enabled
 dpms: On
 modes: 1920x1200 1920x1080 1920x1080 1600x1200 1680x1050 1400x1050 1280x1024 1280x1024 1440x900 1360x768 1152x864 1280x720 1280x720 1024x768 1024x768 1024x768 832x624 800x600 800x600 800x600 800x600 720x576 720x480 640x480 640x480 640x480 640x480 720x400
 edid-base64: AP///////wA4o1BnAQEBASUUAQOAOCN46pe1qVQ4riUTUFS/74CBwIGAkECLwJUAqUCzANEAKDyAoHCwI0AwIDYAMF4hAAAaAAAA/QAyTBpSEQAKICAgICAgAAAA/ABFQTI2MVdNCiAgICAgAAAA/wAwOTEwNjY5ME5BCiAgAWUCAQQAAR0AclHQHiBuKFUAMF4hAAAeAR0AvFLQHiC4KFVAMF4hAAAejgrQiiDgLRAQPpYAMF4hAAAYjArQkCBAMSAMQFUAMF4hAAAYAjqAGHE4LUBYLEUAMF4hAAAeAjqA0HI4LUAQLEWAMF4hAAAeAAAAAAAAAAAAAAAAAAAA/A==
DRM.card0.LVDS.1:
 status: connected
 enabled: enabled
 dpms: Off
 modes: 1440x900 1440x900
 edid-base64: AP///////wAwrjZAAAAAAAASAQOAHhN46uWVk1ZPkCgoUFQAAAABAQEBAQEBAQEBAQEBAQEBwSmg5FGEGjAwIDYAL74QAAAZ3iKgLFGEfjAwIDYAL74QAAAZAAAADwCVCjKVCigeCQBMo0JUAAAA/gBMVE4xNDFCVDA4MDAxAMs=
DRM.card0.VGA.1:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
Date: Tue Mar 29 10:07:56 2011
DistUpgraded: Log time: 2010-12-12 14:04:29.713775
DistroCodename: natty
DistroVariant: ubuntu
EcryptfsInUse: Yes
GraphicsCard:
 Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) (prog-if 00 [VGA controller])
   Subsystem: Lenovo Device [17aa:21c1]
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha amd64 (20101206)
InstallationMedia_: Ubuntu 11.04 "Natty Narwhal" - Alpha amd64 (20101206)
InstallationMedia__: Ubuntu 11.04 "Natty Narwhal" - Alpha amd64 (20101206)
MachineType: LENOVO 2901CTO
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-7-generic root=UUID=ab1e5491-e40c-4113-bf20-22ecb604999a ro quiet splash vt.handoff=7
ProcVersionSignature_: Ubuntu 2.6.38-7.39-generic 2.6.38
ProcVersionSignature__: Ubuntu 2.6.38-7.39-generic 2.6.38
Renderer: Unknown
SourcePackage: unity
UpgradeStatus: Upgraded to natty on 2011-03-24 (4 days ago)
dmi.bios.date: 10/27/2010
dmi.bios.vendor: LENOVO
dmi.bios.version: 6UET61WW (1.41 )
dmi.board.name: 2901CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6UET61WW(1.41):bd10/27/2010:svnLENOVO:pn2901CTO:pvrThinkPadT410s:rvnLENOVO:rn2901CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 2901CTO
dmi.product.version: ThinkPad T410s
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.4git20110322-0ubuntu5
version.libdrm2: libdrm2 2.4.23-1ubuntu5
version.libgl1-mesa-glx: libgl1-mesa-glx 7.10.1-0ubuntu3
version.xserver-xorg: xserver-xorg 1:7.6~3ubuntu11
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.0-0ubuntu4
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.14.0-4ubuntu4
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20110107+b795ca6e-0ubuntu6

[lspci]
Nux: lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02)

[Alex Launi (alexlauni)]

The issue you're describing doesn't sound related to Unity. Could you log into a Gnome 2 session and see if this issue persists?

[Roland Dreier (roland.dreier)]

Yes, I get similar issues when logging into a "classic" session and in fact when the system is at the gdm screen before logging in. So I reassigned to the intel driver, since this appears to be a generic X problem.

[Bryce Harrington (bryce)]

Actually is most likely an issue in the kernel's drm modesetting code.

[Bryce Harrington (bryce)]

I think this is probably a dupe of bug #737891.

[Bryce Harrington (bryce)]

Can you try temporarily uninstalling ia32-libs and reproducing the issue, to rule out that as a possible suspect? (We had a bug on arrandale x86_64 recently that we believe was due to an old mesa in ia32-libs, but that should be fixed now.)

[Roland Dreier (roland.dreier)]

OK, with ia32-libs uninstalled:

   $ dpkg --list|grep ia32
  rc ia32-libs 20090808ubuntu11 ia32 shared libraries for use on amd64 and ia64 systems

I get roughly the same behavior. I started with the laptop docked, and when I undocked it actually switched to the internal screen OK. Then when I redocked I got the black screen, and when undocking again I was stuck with the black screen too (only showing a pointer that still moves with the mouse).

[Bryce Harrington (bryce)]

Hrm, ok at least it rules out ia32-libs.

Next thing to look at is the GPU registers. Please install xserver-xorg-video-intel-dbg and run the tool intel_reg_dumper once when the screen is working correctly, and once with it showing the blank screen / out-of-range error, and attach both files. Comparing the register settings for them may highlight where the problem is.

[Hannes Beyer (hannesbeyer)]

I'm observing the same problem here. I also have a Lenovo T410s. When booting with the dock connected to a 19" monitor (1280x1024, DVI) both monitors turn black on ubuntu 11.04 beta 2 after login. LVDS1 stays black upon undocking but the mouse cursor is visible. The login screen is there, but here the resolution is not set properly.
When booting undocked and connecting the unit to its dock at a later timepoint, monitors also turn black.
Connecting a 1900x1080 TV via displayport to the notebook -without the dock- woked for me.
Things worked fine with ubuntu 10.10.

[Roland Dreier (roland.dreier)]

OK, I got a chance to run intel_reg_dumper when the system is in the following states:

 - docked-good.txt : in the dock with unity working properly spanning two external 1920x1080 monitors
 - docked-bad.txt: in the dock with a black screen on the left monitor and the right monitor off
 - undocked-good.txt: out of the dock with unity working properly on the internal 1440x900 LCD
 - undocked-bad.txt: out of the dock with a black screen

[Roland Dreier (roland.dreier)]

correction: I said two 1920x1080 monitors but they are really 1920x1200 monitors.

[Bryce Harrington (bryce)]

Roland, thanks for that.

Alright, here is what I think is happening. Arrandale graphics cards have a hardware limitation of a max texture buffer size of 4096x4096. What this means is that compositing will work only if the total screen width is 4096 or less. Over that, and the GPU can lock up or other weird things can occur.

My hypothesis is that when you are booting with the laptop docked, the internal laptop LVDS panel is disabled, so your total width is 1920+1920 which is <4096. However, when you boot with the laptop panel on and *then* dock, the kernel is adding the two monitors to the left or right of the laptop panel, resulting in 1920+1920+1440 which is >4096.

Looking at your monitors.xml, the first section shows HDMI2 and HDMI3 arranged side-by-side, and LVDS1 is also present and not disabled but not set to any particular position, so it is unclear how the kernel would position it in this case; perhaps it is adding it at +3840+0 which would fit with my hypothesis.

There are a few things you could test which might prove my hypothesis wrong:

a. This behavior should occur only with Unity/Compiz. If you boot Classic Desktop (No Effects), the system freeze should be unreproducible. (However, see below)

b. If in gnome-display-properties you arrange your LVDS to be positioned *below* your two main monitors, it should work in unity. Note you may need to delete your monitors.xml before making these settings.

c. If you disable your LVDS before docking (either using the GUI, or via 'xrandr --output LVDS1 --off') and then docking, the system shouldn't freeze. (I don't know if the external monitors will fire up in this case, but at least it won't trigger the freeze bug).

These may also give you some idea on working around the issue.

If those tests turn out correct, then this issue is basically a sub-case of bug #555641. However, I think that there could be some work done in gnome-display-properties to check max texture size before enabling configurations like this, if compiz is running.

Now, one other caveat. It appears that there is a separate unrelated bug that is common to Arrandale, that certain RANDR operations can sometimes result in a monitor being improperly blanked. So, that may add some confusion to your testing. But the way to tell these bugs apart is that your original bug results in a system lockup (a black screen with a mouse pointer, and no way to recover), whereas with this latter blanking bug, you won't see a mouse cursor and the monitor will appear to be not getting any signal. Possibly you may be able to work around this blanking issue via this command:

xset dpms force on

Anyway, sorry for the lengthy dissertation, but hopefully with this information you can help me nail down this bug. I have some thoughts on what steps to take to get resolution to this issue (and the blanking one) but let's see if you can prove my hypothesis before we get into all that.

[Roland Dreier (roland.dreier)]

Bruce, thanks for all the info. I will do some more testing today.

One clarification though: when I get in the black screen + mouse pointer situation, my machine is not hung. In fact the mouse pointer is still responsive, I can log in via network, etc. It just that I lose the X root background, WM stuff, etc.

Also I believe I did see similar problems with classic, although I need to double check the "no effects" part. I definitely have seen it from the GDM screen.

[Roland Dreier (roland.dreier)]

Bryce, first off, sorry for mistyping your name ;)

I did a bit more testing, and I tried the classic/no effects login again. If I start undocked and dock, I do get the black screen/responsive mouse pointer. However, if I log in with classic/no effects *and* do "xrandr --output LVDS1 --off" and then dock, one monitor lights up with a real desktop (ie it seems to work). The second monitor was off, but I was able to get it to light back up by going to a text console and back to X. (I guess this is the second conflating bug you mentioned).

I tried a standard unity login and did the "xrandr --output LVDS1 --off" and I still ended up with a black but on monitor.

[Bryce Harrington (bryce)]

Hi Roland, thanks for the quick response.

Regarding your clarification, yes despite how it may seem, "blank screen with moving mouse cursor and X not responding to input, but network login works" is the prototypical set of symptoms that go with a GPU hang. The kernel itself is ok, which is why you can ssh in; the mouse cursor is handled far enough outside the core of X that it is often unaffected by lockups (not always though). Often when you have a GPU lockup, there will be an error message in your 'dmesg' output. The file /sys/kernel/debug/dri/0/i915_error_state often displays error codes when the GPU is locked up. In fact, if you could reproduce the bug with the classic/no-effects case and attach both of those here, it might give us some more clue what's going wrong. Or, at least, it gives me plenty of info to take upstream.

Regarding the second conflating bug (which I suspect might be a DPMS bug in the kernel's arrandale code), I've a PPA you could try to see if it at least improves that situation:

  https://launchpad.net/~bryce/+archive/elderberry

[Roland Dreier (roland.dreier)]

I added that ppa and updated, and did a bit more testing. It seemed to work a bit better, though not in the way I would have expected.

classic/no-effects: I started undocked, and actually got docking once to work perfectly (both monitors lit up, desktop displayed on both). However when I undocked and re-docked again, my right monitor didn't light up (although I got my desktop on the left monitor). I was not able to get the right monitor to turn on again, after trying "xset dpms force on" , the gnome monitor GUI, going to tty1 and back, etc. This situation was stable after a couple more undock/redock cycles. I never got into the black screen/moving mouse pointer situation. The kernel log never showed any intel graphics related stuff (just USB devices appearing/disappearing and other docking related stuff). And i915_error_state stayed "no error state collected".

unity: Again I actually got docking to work once; however the second time I docked, I got the black screen/moving mouse pointer and right monitor stuck with no signal. However neither the kernel log nor the error_state file showed anything.

[Roland Dreier (roland.dreier)]

I just noticed something while looking at my Xorg.0.log after a couple of dock/undock cycles leading to the black screen. I'm attaching the full log, but what I noticed was:

boot up undocked:
[ 5.897] (II) intel(0): Allocated new frame buffer 1472x900 stride 6144, tiled
matches a 1440x900 panel

dock:
[ 370.652] (II) intel(0): Allocated new frame buffer 3840x1200 stride 15360, tiled
makes sense, I now have 2x1920x1200 monitors

undock:
[ 414.405] (II) intel(0): Allocated new frame buffer 1472x900 stride 6144, tiled
back to the 1440x900 panel

dock again:
[ 434.873] (II) intel(0): Allocated new frame buffer 1920x1200 stride 7680, tiled
now it only allocates a buffer for one monitor -- which probably explains why the second monitor never lights up

I'm not sure what layer of the stack is responsible for figuring out what buffer to allocate etc but this does seem like the first real clue I've seen to where the problem lies.

[Bryce Harrington (bryce)]

Hi Roland, that's a good eye. It is the kernel modesetting portion of the stack which allocates framebuffers, and that does tend to indicate where in the core logic things may be going awry.

Since you're results with the elderberry PPA sound mixed, it's sounding to me like it would not be worth pursuing getting that change into natty. Do you agree, or do you see some value to it?

[Roland Dreier (roland.dreier)]

I don't think the elderberry stuff is related to my issue -- I see a monitor stuck with no signal because (if I understood correctly) KMS got confused and forgot about it. Probably fixing KMS would fix my problems.

Is there some i915 tracing I could turn on to figure out what is confusing the kernel driver?
I guess I'll try a 2.6.39-rc upstream kernel to see if that makes any difference.

[Bryce Harrington (bryce)]

On Thu, Apr 21, 2011 at 12:27:20AM -0000, Roland Dreier wrote:
> I don't think the elderberry stuff is related to my issue -- I see a
> monitor stuck with no signal because (if I understood correctly) KMS got
> confused and forgot about it. Probably fixing KMS would fix my
> problems.
>
> Is there some i915 tracing I could turn on to figure out what is confusing the kernel driver?
> I guess I'll try a 2.6.39-rc upstream kernel to see if that makes any difference.

Yes, the xdiagnose utility allows switching on drm debug messages (the
first checkbox). You might also experiment with disabling vesafb but
I'm doubtful that would do anything in this case.

In addition to testing the .39-rc kernel, you can test Intel's
experimental tree which we package for Ubuntu now for testers:

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next-proposed/

[Roland Dreier (roland.dreier)]

With linux-image-2.6.39-999-generic_2.6.39-999.201104201108_amd64.deb docking/undocking seems to work pretty well. There is a bit of a delay in switching, but even through a few cycles with unity running, I was able to switch successfully between the internal LCD and the two external monitors.

I captured some kernel logs, and when I get a chance I'll do the same for the stock natty kernel so we can compare.

[Bryce Harrington (bryce)]

I have duped bugs #750259, #734756, and #747205 here.

Bug #737891 also exhibits this same issue but also conflates it with another issue where creating a screen >4096 wide exceeds the max texture width (as per the linked upstream bug), so I'm going to let that bug focus on that particular issue (which really is more of a gnome configuration tool issue).

[Bryce Harrington (bryce)]

On lp #747205 we discovered by creating a new user account, that having certain RANDR operations present in monitors.xml would trigger it, presumably because gnome-settings-daemon would pick up those configuration settings and try applying them, triggering an underlying bug in RANDR. Perhaps fiddling with the primary monitor setting did it?

734756 collected register dumps on the issue, and experimented with some dpms forcing from the userspace side. My elderberry PPA was found to have some positive effects, but didn't fix it sufficiently completely to warrant pursuing that to work around the kernel issue. drm-intel-next-proposed did not boot on this reporter's hardware.

Video and photos are available on bug #750259. We also examined gpu error states and found this bug is not a gpu lockup issue (as 747205 suggested). The drm-intel-next-proposed kernel from around 4/21 was found to fix it.

Bug #737891 includes reports of this issue, among other problems. Maverick was re-tested via livecd and the issue was not reproduced (maybe for the same reasons as creating a new account in bug 747205 did not reproduce? Reporters also found that deleting monitors.xml has an ameliorative effect.) Fiddling with which monitor was listed as primary in monitors.xml appeared also to resolve things for at least one person.

[Bryce Harrington (bryce)]

Bug #761236 is the broken-out portion of bug #737891 which is this specific issue. On that report, it was found that kernel 2.6.39-0.4~20110419 resolved it, but the elderberry PPA with the -intel workaround did not.

[Bryce Harrington (bryce)]

That should capture all the background on the various instances of this bug that I've been working with people on. Basically, there are some variations in symptoms but all of the reports are particular to Arrandale, occur in relationship with setting up external screens (perhaps something relating to primary monitor settings), and appear to be fixed in the latest kernel.

The next step for this bug is that we need to narrow down what patch in the upstream kernel provides the fix. The best way to achieve this is via doing a git bisection search. Unfortunately none of us Ubuntu-X guys have Arrandale hardware, so if this bug is going to get fixed in natty we need a volunteer to do this. It is a bit technical but well documented in a paint-by-numbers fashion at https://wiki.ubuntu.com/Kernel/KernelBisection.

[Bryce Harrington (bryce)]

An alternative thing to investigate: There is another bug particular to Sandybridge, with roughly similar symptoms to this one, which has already been git bisected and found a candidate patch. The flagged patch with the fix appears to also affect Arrandale, so I have a hunch it *might* also solve this bug. But that's just a wild guess. Please install and boot this kernel to see if the issue can be reproduced; if not, then this bug may be a dupe of bug #761065:

http://people.canonical.com/~acelan/bugs/lp753189/

[Greg Wilkins (gregw-wiltel)]

I was having a very similar issue with a thinkpad X201 (see https://bugs.launchpad.net/bugs/771344 - which is now duped here)

However, booting with the monitors plugged in made no difference - I would go to the black screen regardless when I logged in an existing account.

However, a freshly created account was able to display two monitors and worked OK with monitor connects and disconnects.

I removed all the compiz files from the existing account and then logged in with a classic no affects session. This gave me black screens, but I was able to hit fn-f7 and my screens cycled through various combinations. Some of these were all black, but some worked, including both screens full resolution (not mirrored) and just external monitor.

I was then able to log out and back in with a classic with effects session, and this now works! However, if I fn-f7 too much, then eventually I end up in the black screens with only X cursor situation and have to restart X to get out of it.

[Unkraut (unkraut2)]

Dear Bruce!

I tried your kernel and experienced exactly the same problems as with the stock ubuntu kernel.
Could anyone please confirm this?

[Unkraut (unkraut2)]

Switch back to kernel 2.6.35-28 from maverick solved most issues for me. I can recomend this as a workaround.

[Hannes Beyer (hannesbeyer)]

I installed kernel 2.6.36-020636.201010210905_amd64 what also wokrd for me. I can conveniently switch between internal and external monitors. Docking/Undocking and weaking up from suspend works which is a pain with the 38er kernel.

[Ed Swierk (eswierk)]

I installed kernel 2.6.39-994.201104200727 from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next-proposed/. This solves the blank screen issue when an external monitor is connected (ThinkPad T410s with Natty).

[Sebastián García Rojas (sebagr)]

I've just installed linux-headers-2.6.39-020639rc4 and this fixed the problem for me!

[Peter L. Hansen (peter-r12)]

I installed kernel 2.6.39 and it too fixed the problem on my ThinkPad T410 such i can use it with my docks again, with different configurations.

But the machine has been significantly slower and it has introduced crashes. Is this because of the PPA software? Debug mode or something the like?

[Martin Pool (mbp)]

Is it worth updating the title to clarify this bug also apparently covers cases where just a single monitor doesn't work (as some of the bugs duped to this complain.)

[Bryce Harrington (bryce)]

[I've marked this bug for inclusion in our oneiric bug queue. While technically this bug has not been re-confirmed against oneiric, I feel it is worth continued development attention. We will need to ask that it be re-confirmed once oneiric is further along, perhaps once we get closer to alpha.]

[Ruairi (ruhann)]

I installed 2.6.29 from the PPA, this fixed the problem in ubuntu classic. In the unity desktop with 2.6.39 I can have choose one monitor only, with two monitors I have issues where the workspace is not the same size as the screen.?field.comment=On a Lenovo Thinkpad Edge, installing 2.6.39 from the Kernel PPA also fixes the problem in ubuntu classic. In the unity desktop with 2.6.39 I can have choose one monitor only, with two monitors I have issues where the workspace is not the same size as the screen. (See attachments). A workaround can be made by setting up the screens in classic mode and the logging out and logging into the unity desktop (see last attachment)?field.comment=On a Lenovo Thinkpad Edge, installing 2.6.39 from the Kernel PPA also fixes the problem in ubuntu classic. In the unity desktop with 2.6.39 I can have choose one monitor only, with two monitors I have issues where the workspace is not the same size as the screen. (See attachments). A workaround can be made by setting up the screens in classic mode and the logging out and logging into the unity desktop (see last attachment)

[Yoni Tsafir (yonix85+launchpad)]

Had a similar bug on my ThinkPad x201.

Installing 2.6.39 kernel as suggested solved the frequent crashes, but certain areas of the screen still remained unusable.
Finally, the workaround I found for this was to delete ~/.config/monitors.xml

[Martin Pool (mbp)]

> xrandr --output DP1 --set audio off

looks good:

I plugged my laptop into the dock, and it came up at the medium
resolution it was running at earlier in the day. I ran that command,
and the screen blanked briefly, I guess while the dp link was
reestablished. I then used the displays panel to switch up to full
resolution and it worked.

So, 1/1. But, this has always been a bit intermittent, so more
testing might be needed.

[Martin Pool (mbp)]

Hitting Fn-F7 a few more times, I still have the blank screen problem,
and turning dp audio off again does not fix it.

[Martin Pool (mbp)]

I've tried, as a bit of a shot in the dark, cutting out one bit of code that seems to try to enable the audio pipe, and this does not seem to be enough to make it reliable when the display is configured automatically.

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index db3b461..007c68b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -867,10 +867,14 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct drm_display_mode *mode,
                break;
        }
        if (intel_dp->has_audio) {
- DRM_DEBUG_DRIVER("Enabling DP audio on pipe %c\n",
- pipe_name(intel_crtc->pipe));
- intel_dp->DP |= DP_AUDIO_OUTPUT_ENABLE;
- intel_write_eld(encoder, adjusted_mode);
+ if (1) {
+ DRM_DEBUG_DRIVER("DP audio forced off!\n");
+ } else {
+ DRM_DEBUG_DRIVER("Enabling DP audio on pipe %c\n",
+ pipe_name(intel_crtc->pipe));
+ intel_dp->DP |= DP_AUDIO_OUTPUT_ENABLE;
+ intel_write_eld(encoder, adjusted_mode);
+ }
        }
        memset(intel_dp->link_configuration, 0, DP_LINK_CONFIGURATION_SIZE);
        intel_dp->link_configuration[0] = intel_dp->link_bw;

[Martin Pool (mbp)]

I tried the current tip of drm-intel-next-fixes (44306ab302687b519a31aa498b954c1e26f95a6b) and it has the same problem.

[Martin Pool (mbp)]

It seems like if I force audio off at the same time I add the external screen, through xrandr, it does work reliably(?) so far. Using the monitor control panel or fn-f7 apparently puts audio back to the 'auto' setting, which does induce a problem

I tried running

for i in `seq 30` ;do; echo i && xrandr --output DP1 --off && sleep 15 && xrandr --output DP1 --mode 2560x1600 --above LVDS1 --set audio off && sleep 15 || break;done

and this got through 14 iterations successfully.

Now I wonder if I can identify what the problem is with audio or provide a way to force it off. This screen does have an option for speakers to be connected, but I'm not using it. I don't know if it picks up audio across dp.

[Martin Pool (mbp)]

Running

xrandr --output DP1 --mode 2560x1600 --above LVDS1 --set audio on

when it's previously working does immediately make the monitor black out, and using '--set audio off' does not bring it back, nor does soft power cycling the monitor or unplugging/replugging it.

I can see some reports of people complaining about dp/audio problems under windows with the U3011, but it's hard to tell how much they indicate a real hardware/firmware problem vs windows driver problems or something else.

http://en.community.dell.com/support-forums/laptop/f/3517/p/19370516/19844480.aspx

> It seems that the Nvidia based implementation at least with Displayport "++" out will only support an audio signal being passed over displayport to an external monitor that is no high resolution than 1080HD, or 1920x1080.

So I wonder if there is some way for Linux to know not to try this, preferably without needing special user configuration:

 * don't do audio above a certain resolution?
 * ... on specific hardware models?
 * don't do DP audio at all by default?

[Martin Pool (mbp)]

I tried a couple of variations on that patch to try to force dp audio off, with no success. If someone gives me a patch or an idea on where to start I'm happy to try it.

[Martin Pool (mbp)]

Just to be clear: forcing audio off every time the external display is configured, by using "xrandr ... --set audio off", does make it work reliably every time so far.

What I tested previously, and what did not work to turn it off just once and then use the system's normal configuration method (eg fn-f7), I guess because that is effectively configuring the monitor with auto audio.

So it does seem that the problem is related to audio; in my particular situation being able to force it off all the time would at least hide the problem. I don't care about sending audio to my monitor, but I suppose others do, so a patch that just turns it off across the board probably wouldn't be accepted.

I guess the next thing to work out is:

 * audio actually can't work on this channel with this resolution (not enough bandwidth?)
 * there's a bug in this monitor to do with audio at high resolution?
 * there's some other bug in the kernel about dp audio?
 * ...?

[Martin Pool (mbp)]

The problem i describe in <https://bugs.freedesktop.org/show_bug.cgi?id=45211#c16>, coming up with only a restricted set of resolutions available, seems connected to booting in 'recovery' mode and then proceeding to a normal desktop.

Leaving that aside, with the one patch from <https://git.kernel.org/?p=linux/kernel/git/keithp/linux.git;a=commitdiff;h=c898261c0dad617f0f1080bedc02d507a2fcfb92> applied to the Ubuntu Precise kernel it looks like things are working ok.

[Martin Pool (mbp)]

Now that I know not to use recovery mode (which might be a separate less important bug), <http://people.canonical.com/~ogasawara/fdo44881/amd64/cmt3/> does work for me.

[Martin Pool (mbp)]

And <https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745112/+attachment/2725463/+files/2012-02-09-intel-dp-oneiric.diff> looks like it works as a (not quite trivial) backport of the fix to 3.0.17.

[Martin Pool (mbp)]

the current tip of drm-intel-fixes does seem to have this fixed (but drm-intel-next-fixes does not)

[Martin Pool (mbp)]

so perhaps the fix for https://bugs.freedesktop.org/show_bug.cgi?id=44881
c898261c0dad617f0f1080bedc02d507a2fcfb92

will also fix this...

[Martin Pool (mbp)]

Ogasawara's build http://people.canonical.com/~ogasawara/fdo44881/amd64/cmt3/ from bug 44881 is only partly working for me: the external monitor does come up, but only at 1600x1200 and xrandr shows
                                                         mbp@joy% xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 480, current 1600 x 1200, maximum 1600 x 1200
default connected 1600x1200+0+0 0mm x 0mm
   1600x1200 0.0*
   1280x1024 0.0
   1024x768 0.0
   800x600 0.0
   640x480 0.0

[Martin Pool (mbp)]

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/2012-01-05-precise/linux-image-3.2.0-997-generic_3.2.0-997.201201050433_amd64.deb
does seem to work correctly.

I'm going to try what I think is the right patch applied to the precise kernel.

[Martin Pool (mbp)]

I built Ubuntu-3.2.0-15.24
from git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git plus
https://git.kernel.org/?p=linux/kernel/git/keithp/linux.git;a=commitdiff;h=c898261c0dad617f0f1080bedc02d507a2fcfb92
and that does seem to fix the problem, hooray. Maybe that one fix can be cherrypicked into the Ubuntu kernel?

The binary is in http://sourcefrog.net/tmp/1m/linux-image-3.2.5-drm-mbp4+_3.2.5-drm-mbp4-mbp0_amd64.deb

(I think the wonky version number is just due to mixing make-kpkg and a debian-style tree?)

I'm going to see if it will work on Oneiric too, and perhaps also do a clean build of it.

[Martin Pool (mbp)]

Here's an attempted backport of that patch to the oneiric kernel; not tested yet.

[Martin Pool (mbp)]

on precise, <http://people.canonical.com/~ogasawara/fdo44881/amd64/cmt3/> does seem to be working correctly

on oneiric's kernel, <https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745112/+attachment/2725463/+files/2012-02-09-intel-dp-oneiric.diff> seems to fix it, and there is a binary from that in <http://sourcefrog.net/tmp/1m/linux-image-3.0.17-oneiric-mbp5+_3.0.17-oneiric-mbp5-mbp0_amd64.deb>

[Daniel-ffwll (daniel-ffwll)]

If drm-intel-fixes works flawless, but just backporting the patch does not yet work so great, we likely miss a few of the recent dp fixes in -stable trees.

Closing this, please reopen if it shows up again or file a new bug reporter if you still have other issues left.

[Leann Ogasawara (leannogasawara)]

Hi Martin,

Thanks for all the extra testing and feedback. I'd been looking at bug 912387 (fdo bug 44881) in parallel. The patch to fix bug 912387 appears to provide a fix for the issue you are seeing here. I've therefore cherry-pick'ed the patch in question from the drm-intel-fixes branch into Precise prior to the patch officially hitting the mainline kernel. So this issue should be resolved in Precise after the next upload (which I intend to do before the end of the week).

I see that the patch has also been CC'd to upstream stable. Once the patch does land in mainline, it'll then propagate through to the upstream stable releases. This means that it should land in Oneiric automatically through our normal SRU process and not require any further action on our part. Thanks.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 3.2.0-16.25

---------------
linux (3.2.0-16.25) precise; urgency=low

  [ Andy Whitcroft ]

  * d-i -- include the Hyper-V drivers in the virtio udeb
    - LP: #917135

  [ Felix Fietkau ]

  * (pre-stable): ath9k_hw: fix a RTS/CTS timeout regression
    - LP: #925602

  [ Keith Packard ]

  * SAUCE: drm/i915: Force explicit bpp selection for
    intel_dp_link_required
    - LP: #745112, #912387, #917330

  [ Leann Ogasawara ]

  * Fix typo in generic-pae description
    - LP: #928448
  * Rebase to v3.2.6

  [ Upstream Kernel Changes ]

  * procfs: parse mount options
    - CVE-2011-4917
  * procfs: add hidepid= and gid= mount options
    - CVE-2011-4917
  * proc: fix null pointer deref in proc_pid_permission()
    - CVE-2011-4917
  * xhci: Remove warnings about MSI and MSI-X capabilities.
    - LP: #929656
  * xhci: Remove scary warnings about transfer issues.
    - LP: #929656
  * x86, mce, therm_throt: Don't report power limit and package level
    thermal throttle events in mcelog
    - LP: #930288
  * rebase to v3.2.6
    - LP: #924320
    - LP: #918254
 -- Leann Ogasawara <email address hidden> Mon, 13 Feb 2012 13:00:08 -0800

[Martin Pool (mbp)]

Thanks, Leann.

I have just tried 3.2.0-16.25 and it's not completely working, the external monitor is still black at high resolutions. I'll investigate some more.

[Martin Pool (mbp)]

One apparently regression in 3.2.0-16.25 (maybe unconnected to this change?) is that fn-f7 does not seem to have any effect. It was working on the previous kernel I tried, both the Ubuntu ones and my own builds.

Turning on the external screen with xrandr does work:

xrandr --output DP1 --mode 2560x1600 --set audio off --above LVDS1

Using the displays control panel, the first time I tried, the monitor showed an error about the signal being wrong. I've just tried again and it has worked. So, I'm not sure. Also, after using the monitors control panel, Fn-F7 is working again. (So, perhaps the bug is in userspace?) I'll see if I can get a better description of what the problem is.

[Martin Pool (mbp)]

This is definitely improved but not fixed. Most of the time the external monitor comes up ok, but sometimes when I switch a running session on to the external monitor it stays irretrievably blank. Here's a kernel log with debugging on of those transitions.

I have not yet worked out the pattern or a reliable reproduction.

[Martin Pool (mbp)]

Current status in Precise seems to be:

 - works reliably with ` xrandr --output DP1 --mode 2560x1600 --set audio off`
 - fairly reliably **does not** work if I set the external monitor direct to 2560x1600 from the monitors control panel, I'm guessing because that does auto audio and gets it wrong.

[Martin Pool (mbp)]

Using the current kernel from Precise, which is supposed to have the latest patches, my external monitor works if audio is forced off using xrandr, but fails if audio is left in auto mode. So, reopening.

[Timo Aaltonen (tjaalton)]

On Sat, 10 Mar 2012, Martin Pool wrote:

> Using the current kernel from Precise, which is supposed to have the
> latest patches, my external monitor works if audio is forced off using
> xrandr, but fails if audio is left in auto mode. So, reopening.

please follow up on the upstream bug as well

[Martin Pool (mbp)]

That comment was on the upstream bug, Launchpad just forwarded it to you ;)

[Martin Pool (mbp)]

On Ubuntu's current kernel (3.2.0-20-generic #32-Ubuntu SMP Thu Mar 22 02:22:46 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux), the behaviour is:

 * after booting, the machine comes up ok to the lightdm screen, and after logging in it restores the previous configuration correctly, ie external monitor at full resolution and internal screen off
 * if I log out, both screens go black and stay black

[Jesse Barnes (jbarnes-virtuousgeek)]

Two things may be going on here:
  1) we're setting the DP audio enable bit too early I think; we should only set it when we go to a normal link mode
  2) there may not be enough bw for audio at 25x16 with the clock configuration we use, we may need to reduce the audio config somehow

Paulo, do you have a DP monitor you can test with to confirm?

I just confirmed that 25x16 works fine on my ILK laptop with drm-intel-next-queued, but I don't have any audio in my config.

Martin, it would be good if you could re-test with drm-intel-next-queued too, just to rule out recent fixes (there have been a number that might affect this).

[Timo Aaltonen (tjaalton)]

Martin: here's a kernel build with that branch:

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-experimental/current/

(d-i-e mapped to d-i-n-q)

[Daniel-ffwll (daniel-ffwll)]

Is this still an issue on 3.6-rc kernels?

[Timo Aaltonen (tjaalton)]

Please test with 3.6-rc kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/

[Chris Wilson (ickle)]

Timeout. Please do reopen if you can still reproduce the issue and help us diagnose the problem, thanks.

[Martin Pool (mbp)]

I have tried this screen and machine with 3.6 and so far it seems to be
working.

Martin
On Oct 22, 2012 1:30 AM, <email address hidden> wrote:

> Chris Wilson <email address hidden> changed bug 45211<https://bugs.freedesktop.org/show_bug.cgi?id=45211>
> What Removed Added Status NEEDINFO RESOLVED Resolution --- INVALID
>
> *Comment # 24 <https://bugs.freedesktop.org/show_bug.cgi?id=45211#c24>on bug
> 45211 <https://bugs.freedesktop.org/show_bug.cgi?id=45211> from Chris
> Wilson <email address hidden> *
>
> Timeout. Please do reopen if you can still reproduce the issue and help us
> diagnose the problem, thanks.
>
> ------------------------------
> You are receiving this mail because:
>
> - You reported the bug.
>
>

[Daniel-ffwll (daniel-ffwll)]

Marking as fixed then, pls reopen if it blows up again, and thanks for submitting the status update.

[psny18 (psny18)]

I'm not sure if I'm in the right place, but on my T61 + docking station I have an issue with desktop files/folders not being displayed correctly. With either VGA or DVI, everything works great but the files/folders in the Desktop/ folder are not constrained to the viewable area. They remain on the laptop monitor (can be dragged to the external monitor) but they are off the screen. "Organize Desktop by Name" has the same result.

So, it seems that the area allocated to icons is bigger than the actual display.

[psny18 (psny18)]

sorry, forgot my details
12.04 LTS x86_64 with 3.2.0-34-generic

[Timo Aaltonen (tjaalton)]

closing as wontfix for precise, it'll get in a point release anyway and the fixing commit is very hard to identify