XRANDR operations very slow unless (phantom) HDMI1 disabled

[Soren Hansen]

Any operation that probes stuff over XRANDR is really slow. Running just "xrandr" takes slightly less than 4 seconds. A bit of experimentation reveals that adding:

Section "Monitor"
        Identifier "HDMI1"
        Option "Ignore" "True"
EndSection

...to xorg.conf fixes it. I have no HDMI ports at all, so this is not a problem.

Only HDMI1 seems to be the problem.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: xorg 1:7.6+7ubuntu7
ProcVersionSignature: Ubuntu 3.0.0-11.17-generic 3.0.4
Uname: Linux 3.0.0-11-generic x86_64
.tmp.unity.support.test.0:

ApportVersion: 1.22.1-0ubuntu2
Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,decor,resize,snap,vpswitch,gnomecompat,imgpng,grid,unitymtgrabhandles,compiztoolbox,move,regex,mousepoll,animation,place,workarounds,session,expo,wall,ezoom,fade,scale,unityshell]
CompositorRunning: None
Date: Wed Sep 21 00:10:26 2011
DistUpgraded: Log time: 2011-08-09 13:47:39.295432
DistroCodename: oneiric
DistroVariant: ubuntu
EcryptfsInUse: Yes
ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu
GraphicsCard:
 Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller])
   Subsystem: Lenovo Device [17aa:20e4]
   Subsystem: Lenovo Device [17aa:20e4]
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha amd64 (20100202)
MachineType: LENOVO 7465CTO
ProcEnviron:
 PATH=(custom, user)
 LANG=da_DK.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.0.0-11-generic root=UUID=9c822cf3-46f9-426f-9fab-13ba9053c1ef ro quiet splash vt.handoff=7
SourcePackage: xorg
UnitySupportTest: Error: command ['/usr/lib/nux/unity_support_test', '-p', '-f'] failed with exit code -11:
UpgradeStatus: Upgraded to oneiric on 2011-08-09 (42 days ago)
dmi.bios.date: 05/16/2011
dmi.bios.vendor: LENOVO
dmi.bios.version: 6DET70WW (3.20 )
dmi.board.name: 7465CTO
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:bvr6DET70WW(3.20):bd05/16/2011:svnLENOVO:pn7465CTO:pvrThinkPadX200s:rvnLENOVO:rn7465CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 7465CTO
dmi.product.version: ThinkPad X200s
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.5.94+bzr2803-0ubuntu1
version.ia32-libs: ia32-libs 20090808ubuntu20
version.libdrm2: libdrm2 2.4.26-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 7.11-0ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 7.11-0ubuntu3
version.xserver-xorg: xserver-xorg 1:7.6+7ubuntu7
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.6.0-1ubuntu13
version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.15.901-1ubuntu2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A

[Bryce Harrington (bryce)]

Kernel should probably be quirked for this laptop to not provide an HDMI1 since it doesn't exist. Adding task for kernel team.

[Bryce Harrington (bryce)]

Forwarding this slow-boot bug from Ubuntu reporter Soren Hansen:
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/855124

[Problem]
Any operation that probes stuff over XRANDR is really slow. Running just "xrandr" takes slightly less than 4 seconds. A bit of experimentation reveals that adding:

Section "Monitor"
        Identifier "HDMI1"
        Option "Ignore" "True"
EndSection

...to xorg.conf fixes it. I have no HDMI ports at all, so this is not a problem.

Only HDMI1 seems to be the problem.

DistroRelease: Ubuntu 11.10
Package: xorg 1:7.6+7ubuntu7
ProcVersionSignature: Ubuntu 3.0.0-11.17-generic 3.0.4
Uname: Linux 3.0.0-11-generic x86_64
ApportVersion: 1.22.1-0ubuntu2
Architecture: amd64
CompositorRunning: None
Date: Wed Sep 21 00:10:26 2011
DistUpgraded: Log time: 2011-08-09 13:47:39.295432
DistroCodename: oneiric
EcryptfsInUse: Yes
ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu
GraphicsCard:
 Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller])
   Subsystem: Lenovo Device [17aa:20e4]
   Subsystem: Lenovo Device [17aa:20e4]
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha amd64 (20100202)
MachineType: LENOVO 7465CTO
ProcEnviron:
 PATH=(custom, user)
 LANG=da_DK.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.0.0-11-generic root=UUID=9c822cf3-46f9-426f-9fab-13ba9053c1ef ro quiet splash vt.handoff=7
SourcePackage: xorg
UnitySupportTest: Error: command ['/usr/lib/nux/unity_support_test', '-p', '-f'] failed with exit code -11:
UpgradeStatus: Upgraded to oneiric on 2011-08-09 (42 days ago)
dmi.bios.date: 05/16/2011
dmi.bios.vendor: LENOVO
dmi.bios.version: 6DET70WW (3.20 )
dmi.board.name: 7465CTO
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:bvr6DET70WW(3.20):bd05/16/2011:svnLENOVO:pn7465CTO:pvrThinkPadX200s:rvnLENOVO:rn7465CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 7465CTO
dmi.product.version: ThinkPad X200s
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.5.94+bzr2803-0ubuntu1
version.ia32-libs: ia32-libs 20090808ubuntu20
version.libdrm2: libdrm2 2.4.26-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 7.11-0ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 7.11-0ubuntu3
version.xserver-xorg: xserver-xorg 1:7.6+7ubuntu7
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.6.0-1ubuntu13
version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.15.901-1ubuntu2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A

[Bryce Harrington (bryce)]

Created attachment 51432
BootDmesg.txt

[Bryce Harrington (bryce)]

Created attachment 51433
XorgConf.txt

[Bryce Harrington (bryce)]

Created attachment 51434
XorgLog.txt

[Bryce Harrington (bryce)]

User reported that by disabling HDMI1 as described, it returns boot speed performance to what it was under natty.

Presumably HDMI1 could be quirked off in the kernel for this particular laptop, but is there a better solution?

[Bryce Harrington (bryce)]

Soren Hansen - I've forwarded this bug upstream to http://bugs.freedesktop.org/show_bug.cgi?id=41059 - please subscribe yourself to this bug, in case they need further information or wish you to test something. Thanks ahead of time!

[Jason Warner (jasoncwarner)]

I just tested this fix and can confirm a huge diff in perceived lagginess. I don't have an HDMI on this x220

[Timo Aaltonen (tjaalton)]

It shouldn't even load the module if the device is not supported by it. Looks like there's a genuine bug then.

Can you try first installing the machine with the safe mode, and then install a 3.1rc mainline kernel to see if it boots normally?

[Timo Aaltonen (tjaalton)]

oh bloody he**, wrong bug :)

[Chris Wilson (ickle)]

Right, let's have a look at drm.debug=0xe for starters. Though I don't think that will tell us anything more than the probe is slow. We can try the initcall_debug trick here (again requires a builtin i915.ko I think) to narrow down the offending function. The most likely suspect is that it is the EDID discovery that is slow.

[Timo Aaltonen (tjaalton)]

Could you try booting with 'drm.debug=0xe' and attach the dmesg log here (or on the upstream bug, if possible).

[Bryce Harrington (bryce)]

Easy way to set that parameter: Run 'sudo xdiagnose', then in the GUI tick the first checkbox (Graphics debugging), exit, and reboot. Then collect your dmesg and it should have the required debug info.

[Soren Hansen (soren)]

Created attachment 51505
dmesg with debug output

[Chris Wilson (ickle)]

Well, that pinpoints it entirely on the EDID probe for the HDMI port. So it would appear to be that we valiantly try to read the EDID through a sea of noise.

Just on the off-chance this helps and points us in the right direction, can you try:

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index d98cee6..1b14504 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -401,7 +401,7 @@ int intel_setup_gmbus(struct drm_device *dev)
                bus->reg0 = i | GMBUS_RATE_100KHZ;

                /* XXX force bit banging until GMBUS is fully debugged */
- bus->force_bit = intel_gpio_create(dev_priv, i);
+ //bus->force_bit = intel_gpio_create(dev_priv, i);
        }

        intel_i2c_reset(dev_priv->dev);

[Eugeni Dodonov (eugeni)]

*** Bug 41061 has been marked as a duplicate of this bug. ***

[Hernando Torque (htorque)]

I'm the original reporter of the dupe. The patch actually worsen the time by a bit. From only my LVDS1 activated, I successively un-ignored the other outputs via xorg.conf and checked the time `xrandr` needed to finish (mean over 10 runs):

* Ubuntu kernel (3.0.0-11.18) and 3.1-rc7 w/o patch (using the Ubuntu config):

LVDS1 5 ms (connected)
+ VGA1 6 ms (disconnected)
+ DP3 120 ms (not present)
+ DP2 240 ms (not present)
+ DP1 360 ms (disconnected)
+ HDMI3 380 ms (not present)
+ HDMI2 400 ms (not present)
+ HDMI1 2000 ms (not present)

* 3.1-rc7 patched (using the Ubuntu config):

LVDS1 5 ms (connected)
+ VGA1 6 ms (disconnected)
+ DP3 120 ms (not present)
+ DP2 240 ms (not present)
+ DP1 360 ms (disconnected)
+ HDMI3 380 ms (not present)
+ HDMI2 590 ms (not present)
+ HDMI1 2200 ms (not present)

Besides: are 120 ms for the (disconnected and non-existent) DisplayPort ports okay?

[Chris Wilson (ickle)]

Well that rules out the possibility that the hardware GMBUS handles the failure more graceful.

To determine if VGA is connected we first check a hotplug status bit in a register. So determining if it is disconnected is quick and easy.

For everything else, we more or less, probe for an EDID and check that EDID corresponds with the limitations of the link. (There are many machines out there that share a single DDC bus between multiple devices, and so the EDID you receive might be for a different encoder.)

Next step is to dive into the specs and see if there is a method for quickly determining unconnected status that we've overlooked all these years...

Besides which the timeout for the HDMI is inexplicably long.

[Leann Ogasawara (leannogasawara)]

For anyone else interested (ie Soren), I've built an Ubuntu test kernel with the patch from comment #7 applied. It's available at the following location:

http://people.canonical.com/~ogasawara/fdo41059/

[Leann Ogasawara (leannogasawara)]

Just adding a note here that I've build a test kernel with the patch noted in comment #7 of the upstream bug report. It's available at the following location:

http://people.canonical.com/~ogasawara/fdo41059/

[Soren Hansen (soren)]

Wow, how awesome is that? :) I'll take it for spin right away.

[Soren Hansen (soren)]

It certainly made a difference.

If I don't disable any of the outputs, xrandr takes nearly 4 seconds without the patch, and around 0.6 with the patch.

If I disable HDMI1, xrandr runtime gets down to 0.125 seconds or thereabouts.

[Eugeni Dodonov (eugeni)]

Created attachment 51643
Patch to ignore non-existent i2c buses

Could you please try with this patch?

It should allow kernel to ignore non-existent i2c communication lines.

On my machine, the xrandr probing with this patch went from 4s to 0.366s.

To enable it, please also add the following line into /etc/modprobe.conf (or /etc/modprobe.d/i2c_algo_bit.conf file (creating it when necessary):

options i2c_algo_bit bit_test=1

Also, if it works (or if it does not works) for you, please paste the result of 'dmesg' with the patch applied.

[Eugeni Dodonov (eugeni)]

Created attachment 51687
Patch to detect stuck bits directly in i915 driver

This patch avoids going through i2c_algo_bit to do the bus testing and performs the testing directly in the i915 driver.

It tests only for the bits which are stuck as high, which seems to be the case if this issue.

Please test with both patches (this and the previous one), and report if they fix the issue for you. At least on my machine, I haven't experienced delays in xrandr and video output detection with any of those patches anymore.

[Eugeni Dodonov (eugeni)]

(In reply to comment #15)
> Please test with both patches (this and the previous one)

Err.. clarifying, I meant "please test each of those patches". They do similar thing, but in two different ways, let's find out which one works better for this specific case.

[Leann Ogasawara (leannogasawara)]

Hi Soren,

I've built Ubuntu test kernels for each of the patches mentioned in comment 14 and comment 15. They are available at the following locations. Please test and let Eugeni know your results. Thanks.

http://people.canonical.com/~ogasawara/fdo41059/comment14/

http://people.canonical.com/~ogasawara/fdo41059/comment15/

[Soren Hansen (soren)]

Awesome! Thanks, Leann!

I'll try them out right away.

[Soren Hansen (soren)]

These are the timings for running xrandr with hdmi1 enabled and disabled for the patches from comment 14 and 15:

comment14/with-hdmi1-disabled:real 0m0.115s
comment14/with-hdmi1-enabled:real 0m0.646s
comment15/with-hdmi1-disabled:real 0m0.040s
comment15/with-hdmi1-enabled:real 0m0.041s

So the one from comment15 is clearly the winner. Switching feels instant.

[Eugeni Dodonov (eugeni)]

(In reply to comment #19)
> These are the timings for running xrandr with hdmi1 enabled and disabled for
> the patches from comment 14 and 15:
>
> comment14/with-hdmi1-disabled:real 0m0.115s
> comment14/with-hdmi1-enabled:real 0m0.646s
> comment15/with-hdmi1-disabled:real 0m0.040s
> comment15/with-hdmi1-enabled:real 0m0.041s
>
> So the one from comment15 is clearly the winner. Switching feels instant.

Great to know that it works! :)

Could you also post the dmesg output with both of those patches please?

[Soren Hansen (soren)]

(In reply to comment #20)
> (In reply to comment #19)
> > So the one from comment15 is clearly the winner. Switching feels instant.
> Great to know that it works! :)
> Could you also post the dmesg output with both of those patches please?

Of course, sorry.

[Soren Hansen (soren)]

Created attachment 51766
debug dmesg (patch from comment 14)

[Soren Hansen (soren)]

Created attachment 51767
debug dmesg (patch from comment 15)

[Leann Ogasawara (leannogasawara)]

Moving milestone to oneiric-updates as we're currently in Final Freeze and this is still under investigation. We can likely consider this for SRU once a fix is determined (see upstream bug).

[Hernando Torque (htorque)]

Sorry for the late answer. I also tested with Leann's kernels (thanks for providing them!) and got different (but not too bad) results:

Ubuntu kernel 3.0.0-12.19
* HDMI1 enabled: 1400 ms
* HDMI1 ignored: 800 ms

Ubuntu kernel 3.0.0-12.20~fdo41059cmt14 + bit_test=1
* HDMI1 enabled: 150 ms
* HDMI1 ignored: 150 ms

Ubuntu kernel 3.0.0-12.20~fdo41059cmt15
* HDMI1 enabled: 150 ms
* HDMI1 ignored: 150 ms

So both cases are equally better than the original one (I have no idea why those numbers changed so much from Ubuntu's kernel 3.0.0-12.18 to 3.0.0-12.19).

[Hernando Torque (htorque)]

Created attachment 51835
dmesg_cmt14_enabled

[Hernando Torque (htorque)]

Created attachment 51836
dmesg_cmt15_enabled

[Hernando Torque (htorque)]

Re-tested with DisplayPort ports DP1-3 ignored (so only LVDS1, VGA1 and HDMI1-3 enabled) and got decent results for both patches:

Ubuntu kernel 3.0.0-12.20~fdo41059cmt14 + bit_test=1, DP1-3 ignored
* HDMI1 enabled: 6 ms
* HDMI1 ignored: 4 ms

Ubuntu kernel 3.0.0-12.20~fdo41059cmt15, DP1-3 ignored
* HDMI1 enabled: 6 ms
* HDMI1 ignored: 6 ms

I wanted to test this with a second system (Z68 based with an Intel HD Graphics 3000), but xrandr shows HDMI1 being in use (monitor is connected via DVI), so I got no idea what to do there.

[Hernando Torque (htorque)]

The patch from comment 15 is causing trouble on my second system (monitor connected via DVI, shown as HDMI1 by xrandr): the monitor loses the signal early in the boot process.

Times with the patch in comment 14 didn't change (170 ms for VGA1, HDMI1-3, and ignored DP1-3).

Attaching both dmesg logs.

[Hernando Torque (htorque)]

Created attachment 51842
dmesg_sys2_cmt15_fail

[Hernando Torque (htorque)]

Created attachment 51843
dmesg_sys2_cmt14_good

[Eugeni Dodonov (eugeni)]

Created attachment 52057
Give up on DDC detection when i2c tells us

Ok, so we got mixed results with the previous patches, and after some investigation I finally found out why they don't work.

What happens with some of the hot-pluggable connectors is that while they are not ready, the bits stay "stuck" (and the patches were detecting that correctly). As soon as they are, they are no longer stuck - but it is too late now, because previous patches already marked them as ignored.

So by checking all the events I am getting, I can consistently detect whether the connection is not there earlier - it is being indicated by the -ENXIO error code being returned by the i2c_transfer call. In this case, I modified drm_do_probe_ddc_edid to return earlier and avoid having try repeatable to talk over those pins.

With this patch, each time a display detection is being performed (for example, by running xrandr), the kernel should list the pins that are being ignored into the dmesg output, so please attach it with the testing results.

[Hernando Torque (htorque)]

Just for safety: this patch shouldn't be combined with the other two, right?

[Eugeni Dodonov (eugeni)]

No, only this patch. The other patches are not necessary anymore.

[Eugeni Dodonov (eugeni)]

Created attachment 52062
Another way to do the check if bus is alive

Besides the previous patch, if you could test this one as well, it would be great!

It does a similar thing to the previous patch, but only affects i915 driver, while the previous one also modifies the edid detection for other drm drivers (nouveau, radeon, ...).

This patch adds a check for i2c connectivity prior to getting the edid data. It could be slightly faster than the previous one in case the connection is not there (e.g., it could greatly reduce the delay with xrandr with phantom outputs), and potentially a bit slower when the bus is present (e.g., it could increment by some ms the xrandr time for valid outputs).

As with the previous patch, this one should be tested on its own.

Sorry for all those patches, I am trying to figure out a way to fix it properly, once and for all :).

[Hernando Torque (htorque)]

Again both patches are equally fast (but slower than the previous ones):

Ubuntu kernel 3.0.0-12.19:
- HDMI1 enabled: 840 ms (690 ms with DP1-3 ignored)
- HDMI1 ignored: 200 ms ( 50 ms with DP1-3 ignored)

With patch from comment 31 (abort early/drm):
- HDMI1 enabled: 290 ms (140 ms with DP1-3 ignored)
- HDMI1 ignored: 160 ms ( 15 ms with DP1-3 ignored)

With patch from comment 34 (valid bus/i915):
- HDMI1 enabled: 290 ms (140 ms with DP1-3 ignored)
- HDMI1 ignored: 160 ms ( 15 ms with DP1-3 ignored)

Will test the second system with active HDMI1 (really DVI) tomorrow.

[Hernando Torque (htorque)]

Created attachment 52065
dmesg w/ patch comment 31

[Hernando Torque (htorque)]

Created attachment 52066
dmesg from xrandr w/ patch comment 31

[Hernando Torque (htorque)]

Created attachment 52067
dmesg w/ patch comment 34

[Hernando Torque (htorque)]

Created attachment 52068
dmesg from xrandr w/ patch comment 34

[Eugeni Dodonov (eugeni)]

Great, thanks a lot for the testing and the feedback!

The patches are a bit slower than the previous one because they attempt to improve performance while still detecting all the possible output consistently all the time. For some outputs (such as hdmi), it turned out that it is impossible to say whether they are present or not without at least one ddc query - so it should take some ms. But with those patches, we can detect if an output is not really there, so we do not keep retrying until the final timeout and give up faster.

[Hernando Torque (htorque)]

Here are the results for the second system:

Ubuntu kernel 3.0.0-12.19:
- All: 315 ms (175 ms with DP1-3 ignored)
- Only HDMI1: 130 ms

With patch from comment 31 (abort early/drm):
- All: 280 ms (140 ms with DP1-3 ignored)
- Only HDMI1: 130 ms

With patch from comment 34 (valid bus/i915):
- All: 280 ms (140 ms with DP1-3 ignored)
- Only HDMI1: 130 ms

I obviously couldn't test with HDMI1 ignored, so that's all outputs vs. only HDMI1. Both patches were equally fast again.

[Hernando Torque (htorque)]

Created attachment 52074
PC dmesg w/ patch comment 31

[Hernando Torque (htorque)]

Created attachment 52075
PC dmesg from xrandr w/ patch comment 31

[Hernando Torque (htorque)]

Created attachment 52076
PC dmesg w/ patch comment 34

[Hernando Torque (htorque)]

Created attachment 52077
PC dmesg from xrandr w/ patch comment 34

[Leann Ogasawara (leannogasawara)]

Hi Soren,

In case you are interested in testing the patches from comments #31 and #34, I've built an Ubuntu test kernel for each patch and placed them at the following locations. Thanks.

http://people.canonical.com/~ogasawara/fdo41059/comment31/

http://people.canonical.com/~ogasawara/fdo41059/comment34/

[Soren Hansen (soren)]

(In reply to comment #46)
> In case you are interested in testing the patches from comments #31 and #34,
> I've built an Ubuntu test kernel for each patch and placed them at the
> following locations. Thanks.
>
> http://people.canonical.com/~ogasawara/fdo41059/comment31/
>
> http://people.canonical.com/~ogasawara/fdo41059/comment34/

Lovely, thanks!

comment31

With HDMI1 disabled, xrandr takes 0.086s on average to complete.
With HDMI1 enabled, xrandr takes 0.185s on average to complete.

comment34

With HDMI1 disabled, xrandr takes 0.085s on average to complete.
With HDMI1 enabled, xrandr takes 0.184s on average to complete.

[Eugeni Dodonov (eugeni)]

Final patches landed into intel-gfx list, thank you all for testing and feedback!

Hopefully they will reach kernel soon :).

[Daniel van Vugt (vanvugt)]

See also bug 859389 where I have an incorrectly named "HDMI1" output, on a machine with no HDMI ports.

The difference is, I am using "HDMI1". It's actually a Display Port with a DVI adapter.

[Seanius-e (seanius-e)]

Hi, after getting hinted to this from the kind folks in #debian-x, I'd like to report that this does also affect radeon systems as well. I have a radeon HD5770, and somewhere around 3.0ish I started seeing this behavior too.

I'd like to confirm that the non-intel-specific patch also helps on my system, though the problem is still clearly there. Instead of a dozen (or more) 2-second stutter/hangs as the system comes up, it's a dozen half second hangs, or feels something roughly like that. But to add some objective measures, here's some "time xrandr" outputs from the different combinations of patch/xorg config:

without patch, no xorg.conf "Ignore":, 3.210
with patch, no xorg.conf "Ignore": 1.060
with patch, with xorg.conf "Ignore": 0.120
without patch, with xorg.conf "Ignore": 0.117

I'd say the last two are statistically equivalent, but there is still an obvious problem even with the patch, though it seems to be much less of one.

This is running master as of this morning, using the radeon HD5770 card connected over HDMI. The following is the "Ignore" config referenced above:

Section "Monitor"
        Identifier "DisplayPort-0"
        Option "Ignore" "True"
EndSection
Section "Monitor"
        Identifier "DVI-0"
        Option "Ignore" "True"
EndSection
Section "Monitor"
        Identifier "DVI-1"
        Option "Ignore" "True"
EndSection

[Bryce Harrington (bryce)]

Patches to fix this issue are available on the upstream bug. The final proposed patches on intel-gfx@ are in this thread:

  http://lists.freedesktop.org/archives/intel-gfx/2011-October/012504.html

Pre-built kernels are here:

  http://people.canonical.com/~ogasawara/fdo41059/comment31/
  http://people.canonical.com/~ogasawara/fdo41059/comment34/

The next step is to get this on the kernel team's todo list to incorporate the precise kernel, and do the sru for oneiric.

[Bryce Harrington (bryce)]

Closing the X driver task since this really requires changes in kernel drm.

[Bryce Harrington (bryce)]

Btw, the upstream discussion indicates that the patch has been tested on intel but maybe needs wider testing to ensure it doesn't cause erroneous behavior on radeon and nouveau drm drivers. Thus, it would be reasonable for kernel team to block on seeing these patches appear in the upstream kernel tree, but will leave that to their discretion.

[Bryce Harrington (bryce)]

Jason Warner has hardware that reproduces this bug (see #884348).

It does not look like there's much else to be done on the X side, so I'm closing out the last X task. I think it's just a matter of waiting on this to work its way through kernel team processes.

[Chris Wilson (ickle)]

In airlied/drm-next:

commit 9292f37e1f5c79400254dca46f83313488093825
Author: Eugeni Dodonov <email address hidden>
Date: Thu Jan 5 09:34:28 2012 -0200

    drm: give up on edid retries when i2c bus is not responding

    This allows to avoid talking to a non-responding bus repeatedly until we
    finally timeout after 15 attempts. We can do this by catching the -ENXIO
    error, provided by i2c_algo_bit:bit_doAddress call.

    Within the bit_doAddress we already try 3 times to get the edid data, so
    if the routine tells us that bus is not responding, it is mostly pointless
    to keep re-trying those attempts over and over again until we reach final
    number of retries.

    This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059
    and improve overall edid detection timing by 10-30% in most cases, and by
    a much larger margin in case of phantom outputs (up to 30x in one worst
    case).

    Timing results for i915-powered machines for 'time xrandr' command:
    Machine 1: from 0.840s to 0.290s
    Machine 2: from 0.315s to 0.280s
    Machine 3: from +/- 4s to 0.184s

    Timing results for HD5770 with 'time xrandr' command:
    Machine 4: from 3.210s to 1.060s

    Reviewed-by: Chris Wilson <email address hidden>
    Reviewed-by: Keith Packard <email address hidden>
    Tested-by: Sean Finney <email address hidden>
    Tested-by: Soren Hansen <email address hidden>
    Tested-by: Hernando Torque <email address hidden>
    Tested-by: Mike Lothian <email address hidden>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059
    Signed-off-by: Eugeni Dodonov <email address hidden>
    Signed-off-by: Dave Airlie <email address hidden>

Please test and report if this does not resolve the problem for you. In some instances we may need to teach the application to use RRGetScreenResourcesCurrent rather than RRGetScreenResources.

[Bryce Harrington (bryce)]

Ubuntu build of drm-next kernel is here for anyone wishing to test:

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

[Bryce Harrington (bryce)]

Allegedly the patches have now hit the drm-next kernel, Ubuntu builds of which are here:

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

It would be helpful if someone able to repro this problem could install that kernel and verify that the issue is gone there.

[Scott Talbert (swt-techie)]

For me, under kernel 3.0.0-16-generic, running xrandr takes ~1.4 seconds and it appears to stall my system while running. With 3.3.0-996-generic #201202170408 from the drm-next area above, running xrandr takes ~170ms and doesn't cause my system to stall (at least noticeably). So for me, it appears the problems are gone or at least are greatly reduced.

[Leann Ogasawara (leannogasawara)]

Hi,

I have built an Precise 12.04 Ubuntu test kernel with the patch noted in comment #69 applied. Could you please test and let me know your results. Thanks in advance.

http://people.canonical.com/~ogasawara/lp855124/amd64/

[Leann Ogasawara (leannogasawara)]

I'd really like to get this fix applied before Beta-2 for Precise. If I could just get test confirmation with the kernel from comment #71, that would be great. Thanks.

[Scott Talbert (swt-techie)]

On Fri, 2 Mar 2012, Leann Ogasawara wrote:

> I'd really like to get this fix applied before Beta-2 for Precise. If I
> could just get test confirmation with the kernel from comment #71, that
> would be great. Thanks.

Leann,

I'll try to test it this weekend.

[Scott Talbert (swt-techie)]

Leann, the kernel mentioned in comment #71 seems to perform about the same as the drm-next one. xrandr operations take about 170ms on my hardware. So it would seem you have successfully applied the patch. :)

[Leann Ogasawara (leannogasawara)]

Thanks for testing and the feedback. I've gone ahead and applied the patch to our ubuntu-precise kernel git repo. The fix should be available in the next upload we do. Thanks.

[Mikopp (mikopp)]

I checked the patch from comment 15 against 3.1.1. While xrandr is faster switching my screen it still takes a long time (3.8 seconds) to read out the current information.
What is worse during switching or asking the information X is blocking! meaning not even the mouse is moving. This also happens when other applications ask for display information (e.g. wine seems to do that a lot).

I reported a separate issue for this bug 47059

[Mikopp (mikopp)]

oh, forgot to mention, I have HDMI1 and DP2 and use them both in a dual screen setup

[Launchpad Janitor (janitor)]

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

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

  [ Andy Whitcroft ]

  * [Config] restore build-% shortcut
  * SAUCE: ata_piix: defer disks to the Hyper-V drivers by default
    - LP: #929545, #942316

  [ Eugeni Dodonov ]

  * SAUCE: drm: give up on edid retries when i2c bus is not responding
    - LP: #855124

  [ Seth Forshee ]

  * SAUCE: (drop after 3.3) platform/x86: Add driver for Apple gmux device
    - LP: #925544

  [ Upstream Kernel Changes ]

  * bsg: fix sysfs link remove warning
    - LP: #946928
  * regset: Prevent null pointer reference on readonly regsets
    - LP: #949905
    - CVE-2012-1097
  * regset: Return -EFAULT, not -EIO, on host-side memory fault
    - LP: #949905
    - CVE-2012-1097

  [ Wu Fengguang ]

  * SAUCE: (drop after 3.4) ALSA: hda - add id for Atom Cedar Trail HDMI
    codec
 -- Leann Ogasawara <email address hidden> Fri, 09 Mar 2012 07:56:11 -0800

[Mikopp (mikopp)]

is this related or a duplicate of bug 29536?

[sean finney (seanius)]

Sorry for the delay in follow-up:

Yes, the patch when cherry-picked into a recentish mainline kernel shows noticable improvement. Subjectively, it still feels a little "chunky" when starting up (I think the login manager and gnome 3 both seem to issue a large number of xrandr requests), but night and day compared to the previous succession of stalls.

w.r.t. bug 29536? I can't say whether it's a dupe or not. i specifically wasn't getting the periodic stalls every 10-30s. But perhaps the other reporter had something that was doing xrandr requests with that frequency whereas for me it was only during log-in.

[Eugeni Dodonov (eugeni)]

Patch has landed in the 3.4-rc1 kernel, so closing this bug. Thank you all for all the testing and feedback!

[dino99 (9d9)]

kernel fix

[Adam Conrad (adconrad)]

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.