Actually each X application hangs after trying to start xrandr once. I bisected the intel driver and figured out that it was the following commit. commit abf4b0cafa038e97bd7a6e5ba107b822117b9ccc Author: Jesse Barnes <jbarnes@hobbes.virtuousgeek.org> Date: Tue Feb 5 13:30:51 2008 -0800 Only enable FBC if one pipe is active Some chips can't support FBC if multiple pipes are active. So if more than one pipe is on or we're going from one->two pipes enabled, make sure FBC is disabled. Intended to fix 13418, 13326, 13152. The driver hangs in a while loop in Program received signal SIGINT, Interrupt. [...] i830_disable_fb_compression_8xx (crtc=0x207a6a0) at i830_display.c:622 622 while (INREG(FBC_STATUS) & FBC_STAT_COMPRESSING) This happens on a 965 G1 machine. This looks like a blocker to me.
--- Xorg.0.log.broken 2008-02-18 19:48:15.000000000 +0100 +++ Xorg.0.log 2008-02-18 19:48:47.000000000 +0100 @@ -624,8 +624,8 @@ (II) Loading sub module "ramdac" (II) LoadModule: "ramdac"(II) Module "ramdac" already built-in (II) intel(0): Comparing regs from server start up to After PreInit -(WW) intel(0): Register 0x70180 (DSPACNTR) changed from 0x58000400 to 0x58000000 -(WW) intel(0): DSPACNTR before: disabled, pipe A +(WW) intel(0): Register 0x70180 (DSPACNTR) changed from 0xd8000400 to 0x58000000 +(WW) intel(0): DSPACNTR before: enabled, pipe A (WW) intel(0): DSPACNTR after: disabled, pipe A (==) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. @@ -751,6 +751,8 @@ (II) intel(0): 0x03a6c000-0x045e7fff: depth buffer (11760 kB) Y tiled (II) intel(0): 0x045e8000-0x065e7fff: classic textures (32768 kB) (II) intel(0): 0x10000000: end of aperture +(WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled +(WW) intel(0): Existing errors found in hardware state. (II) intel(0): Output configuration: (II) intel(0): Pipe A is on (II) intel(0): Display plane A is now enabled and connected to pipe A.
Created attachment 14396 [details] xorg.conf
Created attachment 14397 [details] Xorg.0.log.broken
Created attachment 14398 [details] Xorg.0.log.works
We can not reproduce this bug. How did you produce this bug? can you give detail steps?
Steps for reproduction on a Intel 965G (desktop!) machine: - build and install X.Org 7.3 - build and install xorg-server 1.4.0.90 - build and install xf86-video-intel 2.2.0.90 - start Xorg - start xrandr on top of Xorg In case you still can't reproduce it, you might imagine that such kind of while loops might run infinite /* Wait for compressing bit to clear */ while (INREG(FBC_STATUS) & FBC_STAT_COMPRESSING) ; /* nothing */ ... when the compression bit never gets cleared. Onboard graphics device ID is 2982 (G35), which is handled as IS_I965G in the driver.
A later commit should have prevented that code from running on chips not supporting FBC, are you running with the patch from the "Only disable FBC if registers are available" commit?
I thought I did, but the patch was not yet in 2.2.0.90, so I need to double check this. commit d59eaa8b1e6eeb9775c9d21c7a5fd28f25b2bc3a Author: Jesse Barnes <jbarnes@hobbes.virtuousgeek.org> Date: Wed Feb 6 09:35:43 2008 -0800 Only disable FBC if registers are available The call to disable FBC should only occur if the FBC feature is actually present or we may end up hanging on a read from a non-existent register. diff --git a/src/i830_display.c b/src/i830_display.c index 585b0e7..3fe7cda 100644 --- a/src/i830_display.c +++ b/src/i830_display.c @@ -722,7 +722,8 @@ i830_use_fb_compression(xf86CrtcPtr crtc) /* Here we disable it to catch one->two pipe enabled configs */ if (count > 1) { - i830_disable_fb_compression(crtc); + if (i830_fb_compression_supported(pI830)) + i830_disable_fb_compression(crtc); return FALSE; }
Yeah, I put together that fix right after releasing .90, please double check your tree.
Indeed commit d59eaa8b1e6eeb9775c9d21c7a5fd28f25b2bc3a fixes the issue for me. Unfortunately some commit later broke the driver on the hardware again so the machine now freezes here: (**) intel(0): Depth 24, (--) framebuffer bpp 32 (==) intel(0): RGB weight 888 (==) intel(0): Default visual is TrueColor (II) intel(0): Integrated Graphics Chipset: Intel(R) G35 (--) intel(0): Chipset: "G35" (--) intel(0): Linear framebuffer at 0x80000000 (--) intel(0): IO registers at addr 0x90300000 This is with commit 293120bfc40a5b828567551954d8312639e73578.
Ok. The issue is that with commit 293120bfc40a5b828567551954d8312639e73578 the logout from a xdm/kdm/gdm Xsession freezes the machine, if DisplayManager._0.terminateServer: true is set in /etc/X11/xdm/xdm-config, i.e. a new Xserver is started after each Xsession. This issue does not occur with commit d59eaa8b1e6eeb9775c9d21c7a5fd28f25b2bc3a. So the initial issue seems to be fixed.
Stefan, can you open a new issue for the hang and assign it to Zhenyu (zhenyu.z.wang@intel.com)? That's his commit... Thanks, Jesse
(In reply to comment #12) > Stefan, can you open a new issue for the hang and assign it to Zhenyu > (zhenyu.z.wang@intel.com)? That's his commit... done. Bug #14591
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.