Bug 14552

--- 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