I'm very happy to test or debug things here, if someone gives me a pointer where to start.

Please attach xrandr --verbose output. Also please boot with drm.debug=0xe attached to your kernel cmdline, try to set a low working resolution and then a high non-working resolution and attach the entire dmesg. Please ensure that the attached dmesg is complete, if stuff at the beginning is missing you need to increase the log buffer with log_buf_len=2M or even larger.

Also please provide the output of lspci -nn for you gpu.

Hi, here is the requested information:

 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745112/+attachment/2700631/+files/x201-lspci.txt

 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745112/+attachment/2700632/+files/x201-dell30-xrandr.txt

 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/745112/+attachment/2700641/+files/x201-kernel.txt

Chris Wilson also reports occasional (really occasionl) transcoder failures on his x201 at the same resolution.

Turning of audio might help, can you please try this:

xrandr --output DP1 --set audio off

> 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.

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

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

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.

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?

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;

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.

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?
 * ...?

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

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

will also fix this...

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

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.

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.

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.

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.

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.

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).

Is this still an issue on 3.6-rc kernels?

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

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, <bugzilla-daemon@freedesktop.org> wrote:

>  Chris Wilson <chris@chris-wilson.co.uk> 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 <chris@chris-wilson.co.uk> *
>
> 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.
>
>

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