Created attachment 12775 [details]
Log with mode debug and framebuffer compression enabled

In case it helps, here is the diff between the logs of an enabled compression and a disabled one:

@@ -976,7 +977,7 @@
 (II) intel(0): X context handle = 0x1
 (II) intel(0): [drm] installed DRM signal handler
 (==) intel(0): VideoRam: 262144 KB
-(**) intel(0): Framebuffer compression enabled
+(**) intel(0): Framebuffer compression disabled
 (**) intel(0): Tiling enabled
 (II) intel(0): Attempting memory allocation with tiled buffers.
 (II) intel(0): Success.
@@ -1026,14 +1027,10 @@
 (II) intel(0): xf86BindGARTMemory: bind key 4 at 0x07000000 (pgoffset 28672)
 (II) intel(0): Fixed memory allocation layout:
 (II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB)
-(II) intel(0): 0x00020000-0x0061ffff: compressed frame buffer (6144 kB, 0x000000007f820000 physical
+(II) intel(0): 0x00020000-0x00029fff: HW cursors (40 kB, 0x000000007f820000 physical
 )
-(II) intel(0): 0x00620000-0x00620fff: compressed ll buffer (4 kB, 0x000000007fe20000 physical
-)
-(II) intel(0): 0x00621000-0x0062afff: HW cursors (40 kB, 0x000000007fe21000 physical
-)
-(II) intel(0): 0x0062b000-0x00632fff: logical 3D context (32 kB)
-(II) intel(0): 0x00633000-0x00633fff: overlay registers (4 kB, 0x000000007fe33000 physical
+(II) intel(0): 0x0002a000-0x00031fff: logical 3D context (32 kB)
+(II) intel(0): 0x00032000-0x00032fff: overlay registers (4 kB, 0x000000007f832000 physical
 )
 (II) intel(0): 0x007bf000:            end of stolen memory
 (II) intel(0): 0x01000000-0x01ffffff: front buffer (16384 kB) X tiled
@@ -1049,14 +1046,9 @@
 (II) intel(0): SDVO: R:                         (Success)
 (II) intel(0): SDVO: W: 05 00 00                   (SDVO_CMD_SET_ACTIVE_OUTPUTS)
 (II) intel(0): SDVO: R:                         (Success)
-(II) intel(0): fbc disabled on plane a
-(II) intel(0): fbc disabled on plane a
-(II) intel(0): fbc disabled on plane a
 (II) intel(0): Mode for pipe A:
 (II) intel(0): Modeline "1600x1200"x60.0  162.00  1600 1664 1856 2160  1200 1201 1204 1250 +hsync +vsync (75.0 kHz)
 chosen: dotclock 161828 vco 1618285 ((m 118, m1 20, m2 6), n 5, (p 10, p1 1, p2 10))
-(II) intel(0): fbc enabled on plane a
-(WW) intel(0): fbc already enabled on plane a, not enabling on plane a
 (II) intel(0): Mode for pipe B:
 (II) intel(0): Modeline "1440x900"x60.0   95.44  1440 1504 1536 1744  900 903 906 912 -hsync -vsync (54.7 kHz)
 chosen: dotclock 95142 vco 2664000 ((m 111, m1 18, m2 9), n 2, (p 28, p1 4, p2 7))
@@ -1102,9 +1094,9 @@
 (II) intel(0):          DSPATILEOFF: 0x00000000
 (II) intel(0):            PIPEACONF: 0x80000000 (enabled, single-wide)
 (II) intel(0):             PIPEASRC: 0x063f04af (1600, 1200)
-(II) intel(0):         FBC_CFB_BASE: 0x7f820000
-(II) intel(0):          FBC_LL_BASE: 0x7fe20006
-(II) intel(0):          FBC_CONTROL: 0xc3e847e0
+(II) intel(0):         FBC_CFB_BASE: 0x00000000
+(II) intel(0):          FBC_LL_BASE: 0x00000000
+(II) intel(0):          FBC_CONTROL: 0x00000000
 (II) intel(0):          FBC_COMMAND: 0x00000000
 (II) intel(0):           FBC_STATUS: 0x20000000
 (II) intel(0):         FBC_CONTROL2: 0x00000000
@@ -1353,4 +1345,3 @@
 (II) Configured Mouse: ps2EnableDataReporting: succeeded
 Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!
 Could not init font path element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list!
-(WW) intel(0): fbc already enabled on plane a, not enabling on plane a

Created attachment 13041 [details]
Program y offset of framebuffer for FBC

Hm, I wonder if in your configuration we need to program the Y offset of the framebuffer.  Not doing this is a bug regardless, but maybe this'll help your situation.

It seems like this patch did the trick. The image on external VGA is now stable when compression is enabled.

Sorry for the earlier message, I had only tested with a VGA display (and I usually turn off the LVDS when I do), so all seemed fine. But now I also tested with the LVDS (and no VGA) and the situation is in fact no better. With the patch, it is the LVDS display that stutters when compression is enabled. Please do not apply.

Just to confirm, you're seeing flickering on both the VGA and LVDS outputs, even when only one of them is enabled?

Also, can you time the flickering?  I wonder if it occurs every ~15s... if so that would almost surely be the FBC re-compress event.

Does the flickering stop after a short time and the display return to normal?  Or once corrupt does it stay corrupt?

Let me summarize what I experience when compression is enabled:

- without the patch, no VGA display: the LVDS output is fine

- without the patch, LVDS is off and a VGA display is connected: the VGA output flickers several times per minute, but only for a split second; the display is fine otherwise; my initial thought was that there was a glitch in the hardware that occurred while the framebuffer is being compressed, so this behavior is compatible with your "FBC re-compress event" hypothesis

- with the patch, LVDS is off and a VGA display is connected: the VGA output is fine (but perhaps I did not experiment for long enough, see below)

- with the patch, no VGA display: the LVDS flickers similarly to the VGA way above, but it happens rarely: only three times while using the computer for one hour

So there is a noticeable improvement with the patch for the VGA output, since there is no longer a flicker every few seconds. But it broke something with respect to the LVDS.

Here is another event that just occurred with the LVDS and framebuffer compression. Since it never occurred before, it may be related to the patch too. The display suddenly got blank. Switching VT worked fine and I could read and use the text consoles (pure text consoles, no fb, if that matters). Restarting the X server did not help, the display was blank again once in graphical mode. I had to reboot the laptop in order to get back a visible X.

Since then, I have been working with and without framebuffer compression. So I can now confirm that the display going blank is caused by patch+fbc. I can also confirm that VGA display does not suffer from the issues the patch introduced for LVDS display. As a consequence, while it fixed VGA display, the patch severely broke LVDS display. Perhaps some other graphic register should have been written along the one in the patch?

Bugzilla Upgrade Mass Bug Change

NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO.

  - benjsc
    fd.o Wrangler

Just pushed some FBC stuff that will hopefully fix this.  Care to retest?

This is still as bad as before. However, it seemed to work at first: When I installed the new driver, I didn't reboot the computer, I just restarted X, and the LVDS display was fine. Or at least I think it was.

So I have made a log diff between the possibly-stable display (-) and the certainly-unstable display (+), both with the new driver and the framebuffer compression. It may give you a clue with what goes wrong with the hardware, in case all these ARxx values are relevant.

@@ -20,7 +20,7 @@
 Markers: (--) probed, (**) from config file, (==) default setting,
 	(++) from command line, (!!) notice, (II) informational,
 	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
-(==) Log file: "/var/log/Xorg.0.log", Time: Thu Feb  7 20:52:02 2008
+(==) Log file: "/var/log/Xorg.0.log", Time: Fri Feb  8 09:15:24 2008
 (==) Using config file: "/etc/X11/xorg.conf"
 (==) ServerLayout "Default Layout"
 (**) |-->Screen "Default Screen" (0)
@@ -442,7 +442,7 @@
 (II) intel(0):      PFIT_PGM_RATIOS: 0x00000000
 (II) intel(0):      PORT_HOTPLUG_EN: 0x00000020
 (II) intel(0):    PORT_HOTPLUG_STAT: 0x00000400
-(II) intel(0):             DSPACNTR: 0x59000000 (disabled, pipe B)
+(II) intel(0):             DSPACNTR: 0x00000000 (disabled, pipe A)
 (II) intel(0):           DSPASTRIDE: 0x00000000 (0 bytes)
 (II) intel(0):              DSPAPOS: 0x00000000 (0, 0)
 (II) intel(0):             DSPASIZE: 0x00000000 (1, 1)
@@ -539,7 +539,7 @@
 (II) intel(0):                 SR06: 0x00
 (II) intel(0):                 SR07: 0x00
 (II) intel(0):                  MSR: 0x67
-(II) intel(0):                  ARX: 0x30
+(II) intel(0):                  ARX: 0x33
 (II) intel(0):                 AR00: 0x00
 (II) intel(0):                 AR01: 0x01
 (II) intel(0):                 AR02: 0x02
@@ -556,7 +556,7 @@
 (II) intel(0):                 AR0d: 0x0d
 (II) intel(0):                 AR0e: 0x0e
 (II) intel(0):                 AR0f: 0x0f
-(II) intel(0):                 AR10: 0x20
+(II) intel(0):                 AR10: 0x0c
 (II) intel(0):                 AR11: 0x00
 (II) intel(0):                 AR12: 0x0f
 (II) intel(0):                 AR13: 0x08
@@ -807,6 +807,9 @@
 (WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to 0xd0000009
 (WW) intel(0): PP_STATUS before: on, ready, sequencing idle
 (WW) intel(0): PP_STATUS after: on, ready, sequencing on
+(WW) intel(0): Register 0x70180 (DSPACNTR) changed from 0x00000000 to 0x58000000
+(WW) intel(0): DSPACNTR before: disabled, 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.
 (II) resource ranges after preInit:
@@ -847,14 +850,19 @@
 (II) intel(0): Kernel reported 488960 total, 1 used
 (II) intel(0): I830CheckAvailableMemory: 1955836 kB available
 drmOpenDevice: node name is /dev/dri/card0
-drmOpenDevice: open result is 8, (OK)
+drmOpenDevice: open result is -1, (No such device or address)
+drmOpenDevice: open result is -1, (No such device or address)
+drmOpenDevice: Open failed
 drmOpenDevice: node name is /dev/dri/card0
-drmOpenDevice: open result is 8, (OK)
+drmOpenDevice: open result is -1, (No such device or address)
+drmOpenDevice: open result is -1, (No such device or address)
+drmOpenDevice: Open failed
 drmOpenByBusid: Searching for BusID pci:0000:00:02.0
 drmOpenDevice: node name is /dev/dri/card0
 drmOpenDevice: open result is 8, (OK)
 drmOpenByBusid: drmOpenMinor returns 8
 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
+(II) [drm] loaded kernel module for "i915" driver.
 (II) [drm] DRM interface version 1.3
 (II) [drm] DRM open master succeeded.
 (II) intel(0): [drm] Using the DRM lock SAREA also for drawables.
@@ -1092,10 +1100,10 @@
 (II) intel(0):                 AR0d: 0x0d
 (II) intel(0):                 AR0e: 0x0e
 (II) intel(0):                 AR0f: 0x0f
-(II) intel(0):                 AR10: 0x20
+(II) intel(0):                 AR10: 0x00
 (II) intel(0):                 AR11: 0x00
 (II) intel(0):                 AR12: 0x0f
-(II) intel(0):                 AR13: 0x08
+(II) intel(0):                 AR13: 0x00
 (II) intel(0):                 AR14: 0x00
 (II) intel(0):                 CR00: 0x5f
 (II) intel(0):                 CR01: 0x4f

Guillaume, can you please attach the full X log (with modedebug enabled) from running with the latest git tip?  It has some register dumps I'd like to look at...

Created attachment 14225 [details]
Log for 2.2.90+ with fb compression enabled

Here is the log. In case it is the register you are interested in (since it is the only new one, as far as I can tell), the CACHE_MODE_0 value is 0x00006820.

Created attachment 14431 [details] [review]
Adjust FBC memory interface behavior

I wonder if this patch makes any difference at all?  It just changes the way FBC blocks memory traffic, hopefully making things a little better.

I would be happy to post that I didn't experience any stutter with the patch. But I have the feeling that I did not experiment anything actually. In my logs, except for the second dump (the one after the start of X), all the FBC registers are about 0. I would have expected only half of the dumps to be 0 (for VT) and the other ones to be non-zero (for X). Could it be that X fails to restore the framebuffer compression when I switch back from VT to X? How can I be sure that compression is enabled at a given time?

I don't know yet about LVDS display, since I need more testing. But I can already tell that the bug is back for VGA displays. It seems to occur less quickly than before, since I need to let the computer idle for 30 seconds / 1 minute before it happens.

As a matter of fact, I am no longer sure the bug really disappeared after your first patch, since I have yet to understand when framebuffer compression is enabled. For instance, this time, X started with framebuffer compression disabled (perhaps because I had enabled both LVDS and VGA?), but the screensaver restored it later on when it kicked out.

Yeah, it should automatically get disabled if you have more than one pipe running.  If only one pipe is active (like if the VGA has been shut off by DPMS but LVDS is still active) then it should turn back on.

So are you running with both LVDS and VGA enabled?  If you don't see the problem in that configuration, that's good.  If you see it only after one display has been disabled, then we still have a problem...

I almost never run X with both displays at once, so I cannot tell for sure if it works or not. But I guess it does, especially since you just confirmed that framebuffer compression is disabled when both pipes are active.

Since it does not seem clear, I will try to describe more precisely my setting. I have an external screen connected to my laptop, so at the start of X, both pipes (A is VGA, B is LVDS) are enabled and framebuffer compression is disabled. Then I disable LVDS (with xrandr). As far as I can tell from the logs, both pipes still seem to be enabled (is that a bug or my misunderstanding?). Later on, DPMS kicks in and powers off the VGA display. Then, when the VGA display is brought back, only the VGA pipe is enabled and framebuffer compression starts. And the stutter starts too.

Thanks for clearing things up, the scenario you describe makes sensee, though when you use 'xrandr' to turn off a display, the corresponding pipe should also get disabled.

Created attachment 14483 [details] [review]
Don't touch 965 FBC regs on !965

I'm running out of possibilities here.  Can you give this patch a try?  It won't touch registers it shouldn't on pre-965 chips.  If those regs exist but have different layouts on previous generations, writing them could be harmful.

No, it doesn't help, the LVDS display is stable, but the VGA display is not. Since your first patch of touching the FENCE_OFF register seemed to help (as far as I remember), I will later experiment with writing to it, but not writing to CONTROL2 as per your latest patch suggestion.

As a side remark, I have found a way to forcefully enable or disable compression, so testing should now be a lot easier (but I don't have time right now). To disable framebuffer compression, enable the other pipe a few seconds. To enable back compression, switch to VT.

Once again I thought it was working, but then I noticed that pipe B (LVDS) was connected to plane B, so framebuffer compression was not enabled. (This probably explains comment #15.)

Is there a way to manually connect pipe B to plane A, so that I can actually test the patches?

Hm, the pipe/plane swap should occur at startup... can you attach logs from when the swap seems to be failing?

Created attachment 15290 [details]
LVDS is on pipe B which is connected to plane B

I have attached my current log, which has pipe B connected to plane B. Framebuffer compression is disabled in my configuration, but it should not be relevant to the choice of planes (?).

Actually, it is.  Normally pipe a maps to plane a and pipe b to plane b.  However, on pre-965 chips, framebuffer compression only works on plane a and LVDS only works on pipe b, so we have to switch the pipe/plane mappings when framebuffer compression is enabled.  So if you change your config to enable framebuffer compression, you should see a message saying that the mappings were changed to support it.

But I'm starting to think this problem may be only partially related to fbc...

Created attachment 15328 [details]
LVDS is on pipe B, which is connected to plane B, when frmabuffer compression is enabled

Just to be sure my memory wasn't playing tricks on me, I enabled back framebuffer compression. So I can now confirm it does not change the mapping: LVDS is still connected to the non-compressed plane.

Ok, thanks Guillame, according to your log, fbc isn't getting enabled on plane A after things come up because the pipe/plane mappings weren't actually swapped, maybe due to an old DRM?

In your old logs, we were enabling FBC on the VGA pipe, since it was sitting on plane A, but we were also running pipe B/plane B for the LVDS, which is what I thought was causing the flicker.

So can you try updating your DRM so that the pipes & planes will get swapped (you should see "adjusting pipe->plane mappings" in your log) to see if the problem still occurs?  It may be that the patch to disable FBC if two pipes were active fixed the problem...

This might be a DUP of 13326 too

The version of the linux kernel on the laptop is 2.6.24, so the DRM code should not be that old (?). Anyway, I will try to get and install a newer version.

In the meantime, please notice that, in the logs from 2008-02-08, the planes are correctly swapped: "Display plane A is now enabled and connected to pipe B." So there was a time when planes were correctly setup.

I have read the comments of bug #13326 and this does indeed look quite similar. While I have not experienced all the described symptoms (e.g. my VGA display never spuriously blanked), I wouldn't be surprised if this was the same underlying issue.

Yeah, somehow the log from 2/8 shows that the adjustment occurred, but the most recent log doesn't.  And since you didn't have a VGA display connected, FBC was disabled on plane a...

It looks like 2.6.24 didn't have the swapped pipe/plane vblank fixes, so that would explain why the driver isn't adjusting them in your more recent logs.

I haven't had a chance to replace the DRM module from my kernel yet, but I would like to clear a potential misunderstanding (?) from comment 28: The disabling of FBC when two pipes are active does not fix the issue. Indeed, when LVDS is off and VGA is on (remember that the VGA pipe is currently on plane A), the image still stutters. As a consequence, unless the most recent DRM ensures that the VGA pipe is never on plane A (even when it is the only active pipe), the bug will still occur.

Pretty sure this is a DUP

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