Bug 47059

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

Created attachment 58125 [details]
lspci

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

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

real    0m8.729s
user    0m0.000s
sys     0m0.002s

*** This bug has been marked as a duplicate of bug 29536 ***

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

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.

can you tell me the other issue?