Bug 596844

Might be related (from Linus 2.6 git tree):

commit 8d06a1e1e9c69244f08beb7d17146483f9dcd120
Author: Robert Hooker <sarvatt@ubuntu.com>
Date:   Fri Mar 19 15:13:27 2010 -0400

    drm/i915: Disable FBC on 915GM and 945GM.
    
    It is causing hangs after a suspend/resume cycle with the default
    powersave=1 module option on these chipsets since 2.6.32-rc.

Seife, could you please try without powersave option with 2.6.34-rc5, which includes the mentioned patch above? Just update to current kernel from obs://Kernel:Head.

Seife? ping! :-)

seife@susi:~> uname -a
Linux susi 2.6.34-rc5-6-desktop #1 SMP PREEMPT 2010-04-22 21:18:20 +0200 x86_64 x86_64 x86_64 GNU/Linux
seife@susi:~> rpm -q kernel-desktop
kernel-desktop-2.6.34-6.1.x86_64

still the same problem. This is from FACTORY, not from Kernel:Head, but should be new enough, I guess.

Argh. I mixed up GM45 with 945GM. :-( Yes, that should already be the right kernel you've tested ...

IIRC Coolo saw the same issue on his machine. Disabling FBC on GM45 would be the right approach I believe.

Created attachment 357165 [details]
drm-i915-disable-fbc-on-gm45-and-965gm.diff

Seife, could apply the following patch, which disables FBC on GM45 and 965GGM?

Yes, seems to help:

susi:~ # cat /sys/module/i915/parameters/powersave 
1

no flickering anymore.
(I know I'm using the recompiled module, because I miscompiled it first, so it did not load ;)

I have the same model, so I assume mine is fixed too then :)

Thanks a lot, Seife. And now we need to convince Greg to add that patch to our kernel. Honestly I have no idea how to achieve that. :-(

Greg, if you don't know the history of FBC support for mobile GPUs in the intel
driver. Upstream it has often been disabled, reenabled, again disabled for various GPUs. In the end the best result we've seen were with having it disabled for all GPUs, which we then usually did for the final product as patch for xf86-video-intel. Now it's in kernel and we can't do that any longer.

Also a problem on X60.

Stefan, is that patch upstream?  If not, care to push it there?  I can't just
disable something like that for our kernel without upstream also taking it.

(In reply to comment #11)
> Stefan, is that patch upstream? 

Of course it is not.

> If not, care to push it there?  

No, it won't be accepted, since Intel developers are going to claim that it
works for them.

> I can't just disable something like that for our kernel without upstream also 
> taking it.

Great. So our user base needs to suffer from upstream decisions, since we're
not interested in adjusting the upstream kernel to our user's needs. Makes perfectly sense.

(In reply to comment #12)
> (In reply to comment #11)
> > Stefan, is that patch upstream? 
> 
> Of course it is not.
> 
> > If not, care to push it there?  
> 
> No, it won't be accepted, since Intel developers are going to claim that it
> works for them.

But if it does, then perhaps something else is wrong on this hardware?

> > I can't just disable something like that for our kernel without upstream also 
> > taking it.
> 
> Great. So our user base needs to suffer from upstream decisions, since we're
> not interested in adjusting the upstream kernel to our user's needs. Makes
> perfectly sense.

We are not interested in taking patches to our kernel that are not going to
be accepted upstream as we would be responsible for maintaining them for the next 10+ years.

Again, try submitting this upstream (or the original problem), I'm sure they will
work with you to resolve the issue.

(In reply to comment #13)
> > > If not, care to push it there?  
> > No, it won't be accepted, since Intel developers are going to claim that it
> > works for them.
> But if it does, then perhaps something else is wrong on this hardware?

Drivers for graphics hardware are in an abominable state, still. Which is related to the fact that there is no single more complex system in a computer than the GPU. And intel especially did an excellent job in the past with changing functionality on a very subtle level.

The driver is known to have races. A number of them. They are not fixed yet because it's unknown *where* they are.

> > Great. So our user base needs to suffer from upstream decisions, since we're
> > not interested in adjusting the upstream kernel to our user's needs. Makes
> > perfectly sense.
> 
> We are not interested in taking patches to our kernel that are not going to
> be accepted upstream as we would be responsible for maintaining them for the
> next 10+ years.

Let me be blunt:
You're suggesting that we're taking the blame for something that doesn't work, but do not disable it even though we know it doesn't work?!?

I know we want to use only upstream supported stuff in our kernel. I didn't know that we also want to absolutely keep broken stuff for the sake of it.

Sigh.

> Again, try submitting this upstream (or the original problem), I'm sure they
> will
> work with you to resolve the issue.

Yes, and it will take several months, with additional issues popping up. At least longer than we have time. Not because upstream developers are idiots, but because debugging these issues takes enormous time and *exactly* the same hardware.

Ok guys. I'll create a KMP package to solve it for me ;-)

Maybe a "fb_compression=0" module parameter would actually be acceptable upstream?
There is already "powersave=0" but I guess that is an even bigger hammer for that pesky little screw, isn't it?

(In reply to comment #14)
> (In reply to comment #13)
> > > Great. So our user base needs to suffer from upstream decisions, since we're
> > > not interested in adjusting the upstream kernel to our user's needs. Makes
> > > perfectly sense.
> > 
> > We are not interested in taking patches to our kernel that are not going to
> > be accepted upstream as we would be responsible for maintaining them for the
> > next 10+ years.
> 
> Let me be blunt:
> You're suggesting that we're taking the blame for something that doesn't work,
> but do not disable it even though we know it doesn't work?!?

If we disable it, what else will break?

> I know we want to use only upstream supported stuff in our kernel. I didn't
> know that we also want to absolutely keep broken stuff for the sake of it.

How can we reliably delete a big chunk of code, and expect other machines to
also work properly?

> Sigh.
> 
> > Again, try submitting this upstream (or the original problem), I'm sure they
> > will
> > work with you to resolve the issue.
> 
> Yes, and it will take several months, with additional issues popping up. At
> least longer than we have time. Not because upstream developers are idiots, but
> because debugging these issues takes enormous time and *exactly* the same
> hardware.

I understand, it's nothing new with kernel development.

Again, work with upstream, we aren't going to take patches that are not submitted
there, and at least trying to work through.  That does not scale in any way, and
is madness (we have learned from prior mistakes in this area.)

(In reply to comment #15)
> Ok guys. I'll create a KMP package to solve it for me ;-)
> 
> Maybe a "fb_compression=0" module parameter would actually be acceptable
> upstream?

Yes, that might work out.

> There is already "powersave=0" but I guess that is an even bigger hammer for
> that pesky little screw, isn't it?

Yes, we want powersaving to work :)

(In reply to comment #17)
> (In reply to comment #15)
> > Maybe a "fb_compression=0" module parameter would actually be acceptable
> > upstream?
> Yes, that might work out.

I doubt it, but it would be great.

> > There is already "powersave=0" but I guess that is an even bigger hammer for
> > that pesky little screw, isn't it?
> Yes, we want powersaving to work :)

I assume that it does much more than fbc. But I'm not sure.

Just to add my 2ct from a user perspective: Intel video chips are common on laptops, and especially laptop users need powersave. Actually I bought a laptop with Intel video only because it works fine with Linux.

Not providing a workaround will render 11.3 completely useless for a lot of users.

How can I help?

JFTR: there's a KMP now in home:seife:testing called "i915-nofbc-kmp" with Stefan's patch, until upstream Xorg/Kernel gets their act together.

Yesterday I installed the 2.6.34-rc6 KOTD to test if it is fixed there.

To make sure I keep a bootable system, I installed Kernel-default from FACTORY before (I had kernel desktop). I found out that The problem does not happen in kernel-default from FACTORY (kernel-default-2.6.34-6.2.x86_64). It also does not happen with kernel-desktop from KOTD (kernel-desktop-2.6.34-rc6.28.2.x86_64).
Just to make sure, I additionally installed kernel-desktop from FACTORY and noticed that it also no longer happens there, even without the patched module.

So the problem seems to be gone in FACTORY and for sure in KOTD kernels.

I'm not sure which change fixed it for FACTORY, maybe I still had a too old kernel in comment #4.

Anyway => Worksforme now. Can anyone reproduce this? Just remove that i915.powersave=0 from your boot options and reboot to test... ;)

I have rc5 from factory and can still reproduce it. make sure you have huge uni colour windows open - any background gradient will be a work around for me (not using full screen will do)

There have been various drm/i915 patches between 2.6.34-rc5 and -rc6, which might have improve the situation.

  drm/i915: fix non-Ironlake 965 class crashes
  drm/i915: use PIPE_CONTROL instruction on Ironlake and Sandy Bridge
  drm/i915: cleanup FBC buffers at unload time
  drm/i915: fix tiling limits for i915 class hw v2
  drm/i915: set DIDL using the ACPI video output device _ADR method return.
  drm/i915: Fix 82854 PCI ID, and treat it like other 85X
  drm/i915: Attempt to fix watermark setup on 85x (v2)

I assume it's this one:

  drm/i915: cleanup FBC buffers at unload time

FYI, RC1 fixed it for me.

(In reply to comment #25)
> FYI, RC1 fixed it for me.

Anybody else, who can confirm that?

Also:

I believe it would be worth a try to update to latest Mesa, libdrm and 
xorg-x11-driver-video packages from obs://X11:XOrg.

I have not seen that issue for quite some time (since 2010-06-05), only maybe one or two short flickers after switching from AC to Battery, but not reproducible, so I am definitely not the right one for needinfo here.

coolo?

Or will, he has seen that issue on X60 according to comment #10.

it's gone for me as well.

Will?

I can't reproduce this with GM either.

So everybody is happy now. :-)