Bug 47059 - xrandr is blocking X completely
Summary: xrandr is blocking X completely
Status: CLOSED DUPLICATE of bug 29536
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Daniel Vetter
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-07 08:24 UTC by mikopp
Modified: 2017-07-24 23:02 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg (41.75 KB, application/octet-stream)
2012-03-07 08:24 UTC, mikopp
no flags Details
xorg log (47.99 KB, text/plain)
2012-03-07 08:26 UTC, mikopp
no flags Details
lspci (6.70 KB, application/octet-stream)
2012-03-07 08:27 UTC, mikopp
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description mikopp 2012-03-07 08:24:48 UTC
Created attachment 58123 [details]
dmesg

when I execute xrandr with no options it blocks X until it is done. meaning nothing gets painted, my mouse does not move, keyboard is not reacting. This currently takes 4 seconds. When I use xrandr to activate my dual screen it blocks several times and overall takes 15 seconds until it has settled down again.

This seems to be related to bug 41059, but the mentioned patch, while speeding up the switching, does not remedy the problrm

Linux mkopp 3.1.10-gentoo-r1 #4 SMP Wed Mar 7 17:06:13 CET 2012 i686 Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz GenuineIntel GNU/Linux
Comment 1 mikopp 2012-03-07 08:26:51 UTC
Created attachment 58124 [details]
xorg log

Module intel: vendor="X.Org Foundation"
[    22.606]    compiled for 1.11.2, module version = 2.18.0
[    22.606]    Module class: X.Org Video Driver
Comment 2 mikopp 2012-03-07 08:27:10 UTC
Created attachment 58125 [details]
lspci
Comment 3 mikopp 2012-03-07 08:30:09 UTC
oh, forgot to mention, I have HDMI1 and DP2 and use them both in a dual screen setup

xrandr --output DP2 --auto --primary --output HDMI1 --auto --pos 1920x176

Screen 0: minimum 320 x 200, current 3200 x 1200, maximum 8192 x 8192
eDP1 connected (normal left inverted right x axis y axis)
   1366x768       60.2 +
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 connected 1280x1024+1920+176 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0*+   75.0  
   1152x864       75.0  
   1024x768       75.1     60.0  
   800x600        75.0     60.3  
   640x480        75.0     60.0  
   720x400        70.1  
DP2 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 320mm
   1920x1200      60.0*+
   1600x1200      60.0  
   1280x1024      75.0     60.0  
   1152x864       75.0  
   1024x768       75.1     60.0  
   800x600        75.0     60.3  
   640x480        75.0     60.0  
   720x400        70.1
Comment 4 mikopp 2012-03-07 08:58:02 UTC
time xrandr --output DP2 --auto --primary --output HDMI1 --auto --pos 1920x176

real    0m8.729s
user    0m0.000s
sys     0m0.002s
Comment 5 Chris Wilson 2012-03-07 10:04:48 UTC

*** This bug has been marked as a duplicate of bug 29536 ***
Comment 6 mikopp 2012-03-07 10:28:00 UTC
Chris,

I am not sure this is the same bug as the one you are pointing too. Just to make sure this is why:

1) I didn't have this issue in the 2.6 series of the kernel and I had 2.6.35,36,39 all running fine. I only had this since I upgraded to 3.1.
2) I don't have a stall every ten seconds, but only if something is requesting the EDID information (at least that is what it looks like from xorg.log)
3) I have this when running xrandr, after xrandr is done and KDE is still layouting the screen and when wine is starting programs, where I see that it is checking EDID as well for whatever reason
4) as long as nothing is checking EDID every thing is running fine

That being said, if it is the same issue then your "patch" must have been regressed out of the kernel in the 3.1 series... I'l try your patch lets see
Comment 7 Chris Wilson 2012-03-07 10:33:46 UTC
The essence of the problem that probing holds onto the config mutex which is also then acquired by the cursor updates (as well as other cases where we take the struct mutex) is the root cause of the stalls you observe. We've dreamt about fixing that for ages.

You may have a further issue which has recently exacerbated the issue for you, however we already are tracking that as well.
Comment 8 mikopp 2012-03-07 10:45:06 UTC
can you tell me the other issue?


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.