Launchpad has imported 50 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=41059.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-09-20T22:41:42+00:00 Bryce Harrington wrote: 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 Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/3 ------------------------------------------------------------------------ On 2011-09-20T22:44:26+00:00 Bryce Harrington wrote: Created attachment 51432 BootDmesg.txt Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/4 ------------------------------------------------------------------------ On 2011-09-20T22:44:42+00:00 Bryce Harrington wrote: Created attachment 51433 XorgConf.txt Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/5 ------------------------------------------------------------------------ On 2011-09-20T22:45:44+00:00 Bryce Harrington wrote: Created attachment 51434 XorgLog.txt Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/6 ------------------------------------------------------------------------ On 2011-09-20T22:47:24+00:00 Bryce Harrington wrote: 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? Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/7 ------------------------------------------------------------------------ On 2011-09-21T08:39:34+00:00 Chris Wilson wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/12 ------------------------------------------------------------------------ On 2011-09-22T07:39:36+00:00 Soren Hansen wrote: Created attachment 51505 dmesg with debug output Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/16 ------------------------------------------------------------------------ On 2011-09-22T08:31:49+00:00 Chris Wilson wrote: 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); Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/17 ------------------------------------------------------------------------ On 2011-09-22T21:46:53+00:00 Eugeni Dodonov wrote: *** Bug 41061 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/18 ------------------------------------------------------------------------ On 2011-09-23T13:56:43+00:00 Hernando Torque wrote: 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? Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/19 ------------------------------------------------------------------------ On 2011-09-23T14:09:47+00:00 Chris Wilson wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/20 ------------------------------------------------------------------------ On 2011-09-23T21:58:50+00:00 Leann Ogasawara wrote: 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/ Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/21 ------------------------------------------------------------------------ On 2011-09-23T22:12:02+00:00 Soren Hansen wrote: Wow, how awesome is that? :) I'll take it for spin right away. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/23 ------------------------------------------------------------------------ On 2011-09-23T22:33:41+00:00 Soren Hansen wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/24 ------------------------------------------------------------------------ On 2011-09-26T23:45:04+00:00 Eugeni Dodonov wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/25 ------------------------------------------------------------------------ On 2011-09-27T21:24:49+00:00 Eugeni Dodonov wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/26 ------------------------------------------------------------------------ On 2011-09-27T22:12:45+00:00 Eugeni Dodonov wrote: (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. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/27 ------------------------------------------------------------------------ On 2011-09-28T03:55:33+00:00 Leann Ogasawara wrote: 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/ Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/28 ------------------------------------------------------------------------ On 2011-09-29T00:45:31+00:00 Soren Hansen wrote: Awesome! Thanks, Leann! I'll try them out right away. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/29 ------------------------------------------------------------------------ On 2011-09-29T01:22:16+00:00 Soren Hansen wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/30 ------------------------------------------------------------------------ On 2011-09-29T12:58:48+00:00 Eugeni Dodonov wrote: (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? Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/31 ------------------------------------------------------------------------ On 2011-09-29T16:48:43+00:00 Soren Hansen wrote: (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. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/32 ------------------------------------------------------------------------ On 2011-09-29T16:49:52+00:00 Soren Hansen wrote: Created attachment 51766 debug dmesg (patch from comment 14) Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/33 ------------------------------------------------------------------------ On 2011-09-29T16:50:13+00:00 Soren Hansen wrote: Created attachment 51767 debug dmesg (patch from comment 15) Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/34 ------------------------------------------------------------------------ On 2011-10-01T07:56:50+00:00 Hernando Torque wrote: 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). Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/36 ------------------------------------------------------------------------ On 2011-10-01T07:58:27+00:00 Hernando Torque wrote: Created attachment 51835 dmesg_cmt14_enabled Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/37 ------------------------------------------------------------------------ On 2011-10-01T07:59:15+00:00 Hernando Torque wrote: Created attachment 51836 dmesg_cmt15_enabled Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/38 ------------------------------------------------------------------------ On 2011-10-01T08:11:58+00:00 Hernando Torque wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/39 ------------------------------------------------------------------------ On 2011-10-01T13:54:38+00:00 Hernando Torque wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/40 ------------------------------------------------------------------------ On 2011-10-01T13:55:57+00:00 Hernando Torque wrote: Created attachment 51842 dmesg_sys2_cmt15_fail Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/41 ------------------------------------------------------------------------ On 2011-10-01T13:57:09+00:00 Hernando Torque wrote: Created attachment 51843 dmesg_sys2_cmt14_good Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/42 ------------------------------------------------------------------------ On 2011-10-06T21:00:38+00:00 Eugeni Dodonov wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/43 ------------------------------------------------------------------------ On 2011-10-06T22:45:56+00:00 Hernando Torque wrote: Just for safety: this patch shouldn't be combined with the other two, right? Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/44 ------------------------------------------------------------------------ On 2011-10-06T23:05:29+00:00 Eugeni Dodonov wrote: No, only this patch. The other patches are not necessary anymore. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/45 ------------------------------------------------------------------------ On 2011-10-06T23:15:47+00:00 Eugeni Dodonov wrote: 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 :). Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/46 ------------------------------------------------------------------------ On 2011-10-07T01:03:00+00:00 Hernando Torque wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/47 ------------------------------------------------------------------------ On 2011-10-07T01:04:27+00:00 Hernando Torque wrote: Created attachment 52065 dmesg w/ patch comment 31 Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/48 ------------------------------------------------------------------------ On 2011-10-07T01:04:57+00:00 Hernando Torque wrote: Created attachment 52066 dmesg from xrandr w/ patch comment 31 Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/49 ------------------------------------------------------------------------ On 2011-10-07T01:05:19+00:00 Hernando Torque wrote: Created attachment 52067 dmesg w/ patch comment 34 Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/50 ------------------------------------------------------------------------ On 2011-10-07T01:05:48+00:00 Hernando Torque wrote: Created attachment 52068 dmesg from xrandr w/ patch comment 34 Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/51 ------------------------------------------------------------------------ On 2011-10-07T01:48:20+00:00 Eugeni Dodonov wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/52 ------------------------------------------------------------------------ On 2011-10-07T10:17:42+00:00 Hernando Torque wrote: 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. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/53 ------------------------------------------------------------------------ On 2011-10-07T10:18:27+00:00 Hernando Torque wrote: Created attachment 52074 PC dmesg w/ patch comment 31 Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/54 ------------------------------------------------------------------------ On 2011-10-07T10:18:55+00:00 Hernando Torque wrote: Created attachment 52075 PC dmesg from xrandr w/ patch comment 31 Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/55 ------------------------------------------------------------------------ On 2011-10-07T10:19:22+00:00 Hernando Torque wrote: Created attachment 52076 PC dmesg w/ patch comment 34 Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/56 ------------------------------------------------------------------------ On 2011-10-07T10:19:41+00:00 Hernando Torque wrote: Created attachment 52077 PC dmesg from xrandr w/ patch comment 34 Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/57 ------------------------------------------------------------------------ On 2011-10-07T18:59:47+00:00 Leann Ogasawara wrote: 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/ Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/58 ------------------------------------------------------------------------ On 2011-10-10T07:23:42+00:00 Soren Hansen wrote: (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. Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/59 ------------------------------------------------------------------------ On 2011-10-18T11:04:09+00:00 Eugeni Dodonov wrote: Final patches landed into intel-gfx list, thank you all for testing and feedback! Hopefully they will reach kernel soon :). Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/60 ------------------------------------------------------------------------ On 2011-10-26T16:37:09+00:00 Seanius-e wrote: 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 Reply at: https://bugs.launchpad.net/linux/+bug/855124/comments/62 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/855124 Title: XRANDR operations very slow unless (phantom) HDMI1 disabled To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/855124/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs