Bug 18702

Can you try a 2.5.x version of xf86-video-intel?  There are some fixes for pipe underruns and 855 chips there...

I tried compiling and installing the git versions of xf86-video-intel and libdrm, but I didn't even get a usable display (it was random shapes and colors, or a bunch of purple bars). I'm sorry, but I didn't even get to capture an Xorg.log from it, either. I'll try again when I've got some more time.

Scott

Any update Scott?  Maybe your distro has updated packages now?

The stable version being used (Arch linux) is still 2.4.3 of xf86-video-intel. I'll try compiling the git version again as soon as I can. Sorry I haven't been more help!

Thanks, Scott

*** Bug 19173 has been marked as a duplicate of this bug. ***

Created attachment 21786 [details]
Xorg.0.log after installing xf86-video-intel from git

Comment on attachment 21786 [details]
Xorg.0.log after installing xf86-video-intel from git

I installed xf86-video-intel and libdrm from git. Got a working X server this time, but still got the flicker when displaying video or effects (Picasa, Youtube, Tuxpaint). I didn't see any of the buffer underrun errors in the attached log like I did before. Progress perhaps?  :)

Thanks, Scott

Well some of that debugging code was removed recently, but if the flicker looks the same it's probably the same issue.  There's patch in #18491 that might help with the video playback problem (I hope), can you give it a try?

Ok, I tried the patch . . . . it compiled and worked fine, but still no change in the post-suspend to ram behavior. In fact, the flicker actually seemed a bit worse. Just so I'm clear, it's not just video playback that causes the flicker, but anytime the graphics card is being used heavily . . . switching windows, displying slideshows, video playback, drawing programs, etc. 

Another tidbit that could?? be related -- if the computer is restarted (not shutdown and then started again, but if restart is selected), when X starts, the display is garbage and the computer is locked up. I have to power off with the power switch, and then it will start up fine. Hibernate (suspend to disk) works fine. 

Thanks,

Scott

Well, one option is to not touch the register at all on this machine:
diff --git a/src/i830_display.c b/src/i830_display.c
index 50fbc4d..ef10135 100644
--- a/src/i830_display.c
+++ b/src/i830_display.c
@@ -1137,6 +1137,8 @@ i830_update_dsparb(ScrnInfoPtr pScrn)
        fifo_entries = 127;
    else if (IS_I9XX(pI830))
        fifo_entries = 95;
+   else if (IS_845G(pI830))
+       return;
    else if (IS_MOBILE(pI830)) {
        fifo_entries = 255;
    } else {

If that's not enough, we may actually need to write FW_BLC on your machine.  Btw, does choosing a lower refresh rate or resolution make the flicker go away or become less severe?

(In reply to comment #10)
> Well, one option is to not touch the register at all on this machine:
> diff --git a/src/i830_display.c b/src/i830_display.c
> index 50fbc4d..ef10135 100644
> --- a/src/i830_display.c
> +++ b/src/i830_display.c
> @@ -1137,6 +1137,8 @@ i830_update_dsparb(ScrnInfoPtr pScrn)
>         fifo_entries = 127;
>     else if (IS_I9XX(pI830))
>         fifo_entries = 95;
> +   else if (IS_845G(pI830))
> +       return;
>     else if (IS_MOBILE(pI830)) {
>         fifo_entries = 255;
>     } else {
> 
> If that's not enough, we may actually need to write FW_BLC on your machine. 
> Btw, does choosing a lower refresh rate or resolution make the flicker go away
> or become less severe?
> 

I have the same problem (I reported the duplicate Bug #19173).  I tried this change on the Intel driver in Ubuntu Intrepid, but it seemed to have no effect.

As for refresh rates, it's hard to tell whether 1280x1024x75 versus 1280x1024x60 makes much of a difference, but I do know that screen resolution has a profound impact on the frequency of the horizontal jerks.  It looks like 1280x1024 is flickering about ten times as much as 1024x768.  640x480 has virtually no flickering.

Also, I noticed that the flickering occurs in greater intensity when there's a lot of memory I/O going on (even when it has nothing to do with X).  For instance, running make &> /dev/null on the intel driver source resulted in substantial flicker, as did the background task update-apt-xapian-index.  I think intensive 2D rendering causes the problem more acutely, but glxgears does not.

Running a simple for (;;); loop in C doesn't cause flicker, but this:

for (;;)
  malloc(4096);

and this:

void *buf = malloc(1048576*500); //this malloc succeeded
memset(buf, 0, 1048576*500);

result in substantial flickering.

I'm using a Pentium 4 CPU, but I noticed the flicker back when I was using a Celeron.

Sorry for the interruption.  Hopefully my input was helpful :)

Ok, here's another one.  We've never bothered to program this register since we really don't have the correct values to use yet, but this may help.  It sets the value such that the GPU will fetch memory for the display very aggressively, increasing power consumption and potentially decreasing CPU performance, but hopefully preventing the flicker you see.

diff --git a/src/i830_display.c b/src/i830_display.c
index 50fbc4d..56584a9 100644
--- a/src/i830_display.c
+++ b/src/i830_display.c
@@ -1172,6 +1172,17 @@ i830_update_dsparb(ScrnInfoPtr pScrn)
              (planea_entries << DSPARB_AEND_SHIFT));
    else
        OUTREG(DSPARB, planea_entries << DSPARB_AEND_SHIFT);
+
+   /*
+    * Some 845 machines appear to have the FIFO watermark set too
+    * conservatively by default.
+    */
+   if (IS_I845G(pI830)) {
+       u32 fw_blc = INREG(FWATER_BLC);
+
+       fw_blc = (fw_blc & 0xffffffc0) | 1;
+       OUTREG(FWATER_BLC, fw_blc);
+   }
 }

 /**

Tried the patch from comment #12, with no noticeable improvement. The normal driver and all the git and patched drivers work fine normally (no flicker, full screen Youtube videos work normally). It's just after a resume from suspend to RAM that the flicker is a problem, and full screen video stutters frequently, like the CPU is working too hard.

Thanks!
Scott

Hm, your machine is really acting like the DSPARB value is wrong after resume, but the xf86-video-intel driver should be restoring that at resume time (as should the kernel), which is why I thought it might be the FW_BLC register instead, but it doesn't seem to be that either.  Can you attach register dumps from before and after your suspend/resume cycle both from the console and from X?  The intel_reg_dumper tool is part of the xf86-video-intel package, in the src/reg_dumper directory.  So:
  from X before suspend
  from console before suspend (so just change to VT one after capturing the above)
  from console after resume
  from X after resume (so just change to the X VT after capturing the dump from the console)

Thanks.  Depending on what we find I may need to add a few more regs and ask for more dumps...

Created attachment 22162 [details]
Log of intel_reg_dumper tool before and after suspend to RAM

Sorry about the delay. I put the four cases that you requested in the one log attached. X - before and after suspend and console - before and after suspend.

Thanks,

Scott

Created attachment 22325 [details] [review]
add fifo watermark to debug output

Sorry to ask again, but can you apply this patch (only the i830_debug.c part really matters) and capture another dump before and after suspend/resume (just from X is fine)?  I added the FIFO watermark regs so I can see if they're changing.

Sorry it took so long. Tried today with the xf86-video-intel-git and got the following error during compile:


 i830_memory.lo i830_memory.c
i830_memory.c: In function ‘i830_allocator_init’:
i830_memory.c:539: error: ‘I915_SETPARAM_NUM_USED_FENCES’ undeclared (first use in this function)
i830_memory.c:539: error: (Each undeclared identifier is reported only once
i830_memory.c:539: error: for each function it appears in.)
make[4]: *** [i830_memory.lo] Error 1

Thanks!
Scott

Created attachment 24377 [details] [review]
save/restore fifo regs at suspend/resume time

Care to give this a try?  There's also a patch in 18651 that reprograms the FIFO regs so might also work.

(In reply to comment #18)
> Created an attachment (id=24377) [details]
> save/restore fifo regs at suspend/resume time
> 
> Care to give this a try?  There's also a patch in 18651 that reprograms the
> FIFO regs so might also work.
> 

Ok, you got me on this one.....is this a patch for the xf86-video-intel driver or something else? I can't find any of the files to patch in the git source for the driver!

Sorry -- it's probably obvious :)


Scott

That last patch is against the kernel.  Probably best to grab anholt's drm-intel-2.6.29 branch from git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git.

Have you had a chance to try that patch Scott?

No, I haven't had a chance to try this yet. I haven't compiled a kernel in a long time....I'll have to find the time to sit down and figure it out on arch with the kernel & patch that you've requested. Sorry! 

Scott

Ok Jesse, I downloaded the git source from the link you gave, and tried to apply your patch -- hopefully I did it correctly! Got the following errors:

scottandchrystie@family-room:~/src/drm-intel$ patch -p1 < ../intel-drm.patch 
patching file arch/x86/mm/pat.c
Hunk #1 succeeded at 364 (offset -1 lines).
Hunk #2 FAILED at 643.
Hunk #3 succeeded at 705 with fuzz 1 (offset -44 lines).
Hunk #4 FAILED at 720.
Hunk #5 succeeded at 744 with fuzz 1 (offset -70 lines).
Hunk #6 FAILED at 757.
Hunk #7 FAILED at 772.
4 out of 7 hunks FAILED -- saving rejects to file arch/x86/mm/pat.c.rej
patching file arch/x86/pci/i386.c
Hunk #1 FAILED at 319.
1 out of 1 hunk FAILED -- saving rejects to file arch/x86/pci/i386.c.rej
patching file drivers/gpu/drm/drm_gem.c
Hunk #1 FAILED at 537.
1 out of 1 hunk FAILED -- saving rejects to file drivers/gpu/drm/drm_gem.c.rej
patching file drivers/gpu/drm/i915/i915_drv.h
Hunk #1 succeeded at 199 (offset 2 lines).
patching file drivers/gpu/drm/i915/i915_gem.c
Hunk #1 succeeded at 1133 (offset 568 lines).
Hunk #2 succeeded at 1172 with fuzz 2 (offset 568 lines).
patching file drivers/gpu/drm/i915/i915_suspend.c
patching file include/linux/mm.h
Hunk #2 succeeded at 128 (offset 1 line).
Hunk #3 FAILED at 157.
1 out of 3 hunks FAILED -- saving rejects to file include/linux/mm.h.rej
patching file mm/memory.c
Hunk #1 FAILED at 1665.
Hunk #2 FAILED at 1680.
2 out of 2 hunks FAILED -- saving rejects to file mm/memory.c.rej
scottandchrystie@family-room:~/src/drm-intel$ 


Thanks,
Scott

Created attachment 25427 [details] [review]
Save/restore FIFO regs (correct pat

Sorry that last patch had a bunch of extra junk in it that was causing the failures you saw.  This one should apply better.

Ok Jesse, 
  I managed to compile and install the kernel with the patch you provided. It's a 2.6.30 branch. Unfortunately, I'm still getting the screen 'shaking' after a resume from suspend to ram (same intensity as before). The only errors I can find so far are:

May  6 05:32:41 family-room kernel: [  617.324988] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 1
May  6 05:32:52 family-room kernel: [  628.780560] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 1

and

(EE) intel(0): Failed to set tiling on front buffer: Invalid argument
(EE) intel(0): Failed to set tiling on back buffer: Invalid argument
(EE) intel(0): Failed to set tiling on depth buffer: Invalid argument

The version of the video-intel driver is 2:2.6.3-0ubuntu9.

Thanks!
Scott

Created attachment 27064 [details] [review]
set FIFO watermarks at DPMS & mode set time

If you're willing to try a recent kernel, you could apply this patch and see if it helps...  You'll need to enable kernel mode setting:
https://wiki.ubuntu.com/X/KernelModeSetting
has some info on that.

Marking as a dupe of the main FIFO programming bug.

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