Created attachment 56609 [details] dmesg log Hi, I'm having a problem using a Dell U3011 monitor with my 2011 macbook air. The laptop has an Intel Core i7 CPU (I7-2677M), with HD 3000 graphics. There are some more specs at this URL: http://www.everymac.com/systems/apple/macbook-air/stats/macbook-air-core-i7-1.8-13-mid-2011-specs.html I'm using these versions: - Ubuntu 12.04 - ubuntu kernel version 3.2.0-12-generic - xorg version 7.6+7ubuntu7 - xserver version 1.11.3-0ubuntu9 The monitor uses a 2560x1600 resolution, and I'm connecting it using DisplayPort. The very first time I connected the monitor to the laptop, it worked fine. However, after rebooting, it is now completely unable to show anything on the display. When I reboot into windows or OS X it works fine. My problem seems somewhat similar to these two other bug reports: http://en.community.dell.com/support-forums/peripherals/f/3529/t/19369819.aspx https://lkml.org/lkml/2012/1/21/149 My problem seems more similar to the first case, in that it worked the first time and then not again, however I have not been able to get it working by doing a factory reset like the person in the forum post was able to do. The second person describes it working on occasion, however for me it seems like no matter how many power cyclings and factory resets I do it doesn't seem to work. All I get is a black screen every time I connect it. I've attached some log files including the dmesg log with "drm.debug=0x06" added to the kernel command line. When I created the logfiles I started by booting the laptop without the display, then I connected the dell display, then I disconnected it, so there's also references to the laptop's internal display in there as well. In the dmesg log, the relevant parts seems to start at around time 28, and end somewhere around time 31. This message seems like it might be important: [ 31.398253] [drm:intel_cpt_verify_modeset] *ERROR* mode set failed: pipe 0 stuck That's the error I get when I don't have "drm.debug=0x06" set. If there's anything else I can provide let me know!
Created attachment 56610 [details] xorg log file
I've learned some more information about the problem that might be useful. I tried connecting over SSH while the laptop was connected to the monitor and ran xrandr: shane@lap:~$ export DISPLAY=:0 shane@lap:~$ xrandr Screen 0: minimum 320 x 200, current 2560 x 1600, maximum 8192 x 8192 eDP1 connected (normal left inverted right x axis y axis) 1440x900 60.0 + VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) DP1 connected 2560x1600+0+0 (normal left inverted right x axis y axis) 641mm x 401mm 2560x1600 60.0*+ 1920x1440 60.0 1920x1200 59.9 1920x1080 50.0 60.0 24.0 25.0 30.0 1600x1200 60.0 1280x1024 75.0 60.0 1280x800 59.8 1152x864 75.0 1280x720 50.0 60.0 1440x576 25.0 1024x768 75.1 60.0 1440x480 30.0 800x600 75.0 60.3 720x576 50.0 720x480 59.9 640x480 75.0 60.0 59.9 720x400 70.1 HDMI2 disconnected (normal left inverted right x axis y axis) HDMI3 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) So the driver definitely thinks it's in 2560x1600. I used xrandr to try 1600x1200, 1920x1080, 1920x1200, 1920x1440 and they all worked. I then switched it back to 2560x1600 and it broke again, however instead of just being a blank screen, the monitor showed a message saying "incorrect mode, change to 2560x1600 60 Hz". The message flashed on and off on the screen at a rate of a about once a second. The flashing didn't seem natural, as it made it hard to read the text.. maybe the driver was still trying to do something? I then disconnected the monitor, reconnected it, changed it to resolution 1920x1440 using xrandr and then back to 2560x1600, and this time it worked! So it looks like it does occasionally work.
Can you try whether force-disabling audio helps for you? When setting the mode with xrandr, just add --set audio off
Hmm.. the problem seems to have changed now since I last tried it. The monitor still fails to work when I plug it in and it's set to a mode for the first time. When I connect over SSH and run xrandr it still shows it in 2560x1600 mode even though the screen is blank. But now, if I use xrandr to change it to 1920x1440 and then back to 2560x1600 it seems to reliably work. In fact I've tried repeatedly various combinations of restarting the monitor, restarting the computer, etc. and I've been unable to replicate the behaviour from before. Now it seems that I can reliably 100% of the time fix the problem by logging in over SSH, changing the resolution to 1920x1440 and changing it back. I'm not sure what could have happened to explain the change, though I did install some ubuntu updates the other day. Those ubuntu updates actually introduced a separate bug in which on the login screen the password entry field is a lot skinner than it needs to be to have the text fit inside. I believe I did get an update to the X server... while the Xorg.0.log file still says it's using x server version 1.11.3-0ubuntu9, the "xserver-xorg" package now shows 7.6-10ubuntu1 instead of 7.6+7ubuntu7. Perhaps this update changes things in some way? In any case, I can still reliably reproduce the problem by connecting the monitor and letting it set the mode automatically without using xrandr. Oh, additionally I am testing now using the kernel in the drm-intel-testing branch at git://people.freedesktop.org/~danvet/drm-intel, as suggested by jbarnes in an email. However I was also using this before, when xrandr was still failing to set the mode correctly. What about using another setting for "drm.debug" on the kernel command line? Is there something I can set it to which would give you more helpful information about the mode setting? Is there a way to find out what the monitor is telling the computer about it's modes (EDID information?) and then find out what the computer is trying to do that's incorrect?
Well, we seem to have a few dp at high resolutions issues, where the screen fails to lock onto the signal we send. Unfortunately no idea yet what it could be or any patches to try :(
Hopefully this helps: commit c4867936474183332db4c19791a65fdad6474fd5 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Apr 10 10:42:36 2012 +0200 drm/i915: properly compute dp dithering for user-created modes We've only computed whether we need to fall back to 6bpc due to dp link bandwidth constrains in mode_valid, but not mode_fixup. Under various circumstances X likes to create new modes which then lack proper 6bpc flags (if required), resulting in mode_fixup failures and ultimately black screens. Chris Wilson pointed out that we still get things wrong for bpp > 24, but that should be fixed in another patch (and it'll be easier because this patch consolidates the logic). The likely culprit for this regression is commit 3d794f87238f74d80e78a7611c7fbde8a54c85c2 Author: Keith Packard <keithp@keithp.com> Date: Wed Jan 25 08:16:25 2012 -0800 drm/i915: Force explicit bpp selection for intel_dp_link_required v2: Fix indentation and tune down the too bold claim that this should fix the world. Both noticed by Chris Wilson. v3: Try to really git add things. Reported-and-tested-by: Brice Goglin <Brice.Goglin@ens-lyon.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48170 Cc: stable@kernel.org Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> in linus/master, please test.
I can confirm that this works fine on my T420 at least... but we may still have issues (see bug #45211). Shane, can you confirm with the drm-intel-next-queued or drm-intel-fixes branch?
This may be a dupe of 45801 but hopefully it's fixed. Shane, please re-open if not or check out the other bug for ideas.
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.