Bug 22672

Additional information:

In intel_lvds_prepare(), the else if (intel_lvds->pfit_dirty) branch is taken, thus HAS_PCH_SPLIT() is false.

I think I have the same problem:

00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
	Subsystem: Dell Device 0209
	Flags: bus master, fast devsel, latency 0
	Memory at f6f00000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: <access denied>

agpgart-intel 0000:00:00.0: Intel 965GM Chipset
agpgart-intel 0000:00:00.0: detected gtt size: 524288K total, 262144K mappable
agpgart-intel 0000:00:00.0: detected 8192K stolen memory

Just reported it on LKML: http://marc.info/?l=linux-kernel&m=128950985131154&w=2

Sadly, I cannot test the commit by simply reverting it: the conflict is not
trivial enough for me.

On Friday, November 19, 2010, Larry Finger wrote:
> On 11/18/2010 05:42 PM, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a summary report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.36.  Please verify if it still should be listed and let the
> tracking team
> > know (either way).
> > 
> > 
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=22672
> > Subject             : Regression in 2.6.37-rc1 for Intel 945 Graphics
> Adapter - bisected to commit e9e331a
> > Submitter   : Larry Finger <Larry.Finger@lwfinger.net>
> > Date                : 2010-11-11 01:56 (8 days old)
> 
> This bug is not yet fixed.

I think I have the same, as well on 945GME. Still present in 2.6.37-rc3... 

and (as lid status is broken for me) I have to suspend to ram and come back to get the light back on...:)

I have the same issue usign this card

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

I get backlight back againg by closing and opening the lid.

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

Nick Bowler wrote at Bug #23122:
> I filed a very similar bug upstream before finding this one; while the
> symptoms are not identical, I bisected it to the same commit:
> 
>   https://bugs.freedesktop.org/show_bug.cgi?id=31803

References: https://bugs.freedesktop.org/show_bug.cgi?id=31803

References: http://marc.info/?l=linux-kernel&m=128944001311444&w=2

Bug is still present en 2.6.37-rc4

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

On Friday, December 03, 2010, Larry Finger wrote:
> On 12/02/2010 05:41 PM, Rafael J. Wysocki wrote:
> > The following bug entry is on the current list of known regressions
> > from 2.6.36.  Please verify if it still should be listed and let the
> tracking team
> > know (either way).
> > 
> > 
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=22672
> > Subject             : Regression in 2.6.37-rc1 for Intel 945 Graphics
> Adapter - bisected to commit e9e331a
> > Submitter   : Larry Finger <Larry.Finger@lwfinger.net>
> > Date                : 2010-11-11 01:56 (22 days old)
> 
> Still present in -rc4.

References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg02235.html

Patch: https://patchwork.kernel.org/patch/359472/
Patch: https://patchwork.kernel.org/patch/359502/

(In reply to comment #12)
> References:
> http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg02235.html
> 
> Patch: https://patchwork.kernel.org/patch/359472/
> Patch: https://patchwork.kernel.org/patch/359502/

My tree has both these patches (they are in Linus' tree since 1st december).
They don't fix the issue on my laptop (Dell XPS M1330).

They do not fix my problem either. The bug report is reopened.

My Dell D430 has similar issues. It does not matter in which mode kde puts the screen: standby, suspend or power off. In all cases the back light stays on (i have never seen it off). When the screen is 'unblanked' it returns in the lowest possible brightness level, and with dis-functional brightness keys (separate key's on the keyboard to change the brightness). Closing and reopening the lid restores the brightness to maximum level and restores the function of the brightness keys. I have bisected the problem to the same commit as above. I rebuild linus's tree every day, and the bug is still there.

There is a corresponding userspace driver fix on the xf86-video-intel master branch at git://anongit.freedesktop.org/xorg/driver/xf86-video-intel which comes with those two patches. 

commit 33c08882c0d551afb28baef643279901dcc65fa9
Author: Keith Packard <keithp@keithp.com>
Date:   Wed Nov 17 16:37:53 2010 +0800

    Mark outputs as DPMSModeOn and restore backlight at mode set
    
    The kernel always turns monitors on when doing mode setting, and so no
    further DPMS action is required. Note this in the mode setting code by
    marking the updated DPMS mode and restoring any saved backlight level.
    
    Signed-off-by: Keith Packard <keithp@keithp.com>
    Reviewed-by: Eric Anholt <eric@anholt.net>

It is still a problem in 2.6.37-rc5.

Still broken in 2.6.37-rc6

Unfortunately, yes it is still broken in -rc6.

On Sunday, December 19, 2010, Larry Finger wrote:
> On 12/19/2010 06:34 AM, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a summary report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.36.  Please verify if it still should be listed and let the
> tracking team
> > know (either way).
> > 
> > 
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=22672
> > Subject             : Regression in 2.6.37-rc1 for Intel 945 Graphics
> Adapter - bisected to commit e9e331a
> > Submitter   : Larry Finger <Larry.Finger@lwfinger.net>
> > Date                : 2010-11-11 01:56 (39 days old)
> 
> The problem is still present in 2.6.37-rc6.

Merry Christmas everybody.

As of today this is still present in current master.

Still broken in -rc8.

http://marc.info/?t=129358572400001&r=1&w=4

Broken for me too in rc8

The back light of my Dell D430 now is turned of when the screen blanks. I don't know at which rc this feature became active. The screen still recovers in the lowest possible brightness level, and with dis-functional brightness keys.

On Thursday, December 30, 2010, Larry Finger wrote:
> On 12/29/2010 05:06 PM, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a summary report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.36.  Please verify if it still should be listed and let the
> tracking team
> > know (either way).
> > 
> > 
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=22672
> > Subject             : Regression in 2.6.37-rc1 for Intel 945 Graphics
> Adapter - bisected to commit e9e331a
> > Submitter   : Larry Finger <Larry.Finger@lwfinger.net>
> > Date                : 2010-11-11 01:56 (49 days old)
> 
> Neither 2.6.37-rc8 nor the patches listed above fix my system.

Ignore-Patch: https://patchwork.kernel.org/patch/359472/
Ignore-Patch: https://patchwork.kernel.org/patch/359502/

Still broken in the master tree after Linus merged all the reverted i915 commits
(by Chris Wilson, 3643e0e87c13c670a).

Still broken for me on 2.6.37-rc8-git1 (2010-12-31).

HW: Dell vostro 1400,

00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)

Bug is still present in 2.6.37 mainline for me.

Got the same problem on my Samsung NP-X120 laptop with GM45 chipset on mainline 2.6.37. 

xf86-video-intel 2.13
xorg-server 1.9.2

The problem is also present on mainline 2.6.37 with the following:

xf86-video-intel 2.13.903
xorg-server 1.9.2.902

Beginning with mainline 2.6.37 my screen goes permanently blank when the i915 driver loads and switches the video mode to 48x170.  Everything else works.  Logs report no problems, nothing different than when I run 2.6.36 (my previous version).

Linux version 2.6.37 (russell@randytool.net) (gcc version 4.5.1 (GCC) ) #1 SMP Thu  Jan 6 18:23:51 MST 2011

VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
        Subsystem: Acer Incorporated [ALI] Device 0212

i915

in an emachines E725 laptop.

Created attachment 43132 [details]
Fix backlight_level accounting.

I think I've more or less figured out what's wrong, or at least a fix for it. The real problem could be that there's way too much unnecessary backlight setting going on, but this patch tries to make that more harmless.

The problem is that intel_lvds_disable() is called too often, or at least more than once for each intel_lvds_enable() call (it looks like it's called twice for each enable call). This should be harmless, but because the current backlight level is stored unconditionally, the real value gets overwritten by zero.

I suspect this regression was caused by a change that introduced the extra intel_lvds_disable() call. If someone wants to look into that, they probably have to look around drm/i915/intel_display.c:intel_crtc_dpms() and drm/drm_crtc_helper.c:drm_helper_connector_dpms().

The patch is against 2.6.37 and also fixes intel_lvds_prepare() and intel_lvds_commit() to behave more sensibly.

Signed-of-by: Indan Zupancic <indan@nul.nu>

I have found a workaround for my Acer Aspire 5732Z:
echo '/usr/sbin/setpci -s 00:02.0 F4.B=00' >> /etc/rc.local

(In reply to comment #33)
> Created an attachment (id=43132) [details]
> Fix backlight_level accounting.
> 
...

The patch fixes the problem on my Dell D430.

-- 
Hans

It does not fix the original problem noted for this bug.

When my system blanks the screen completely - a two step process, the only way to get it back is to close the cover. Mouse and keyboard activity does nothing.

/sbin/setpci -s 00:02.0 F4.B=00 works for me; I put it at the end of rc.modules

Created attachment 43242 [details]
Check for (pfit_control & PFIT_ENABLE) instead of pfit_control only.

(In reply to comment #36)
> It does not fix the original problem noted for this bug.

Did you try both my path, and the setpci thing?

> When my system blanks the screen completely - a two step process, the only
> way
> to get it back is to close the cover. Mouse and keyboard activity does
> nothing.

If you tilt the laptop and look very closely, can you see stuff on the screen? I could, the screen turned on but the backlight stayed off. It would be interesting to know if nothing at all happens or if it's just the backlight.

Also, does the brightness level always get restored correctly or is it sometimes set to the highest setting, or too dim?

To get more info, you could run with drm.debug=0x02 or so, and try to spot anything weird happening. (Maybe you want the kms one, debug=0x04. For an explanation you have to read drmP.h.) Your kernel buffer will be flooded (maybe boot with log_buf_len=1M), so compare dmesg just before and after running:

"xset dpms force off; sleep 1; xset dpms force on"

And then close and open the lid to see what happened. Then compare what resume does to what dpms does. (I'd start with grepping for "lvds".)

> In intel_lvds_prepare(), the else if (intel_lvds->pfit_dirty) branch is
> taken,
> thus HAS_PCH_SPLIT() is false.

That pfit_dirty is set seems relevant. I'm not sure what it means though. What is your monitor's native screen resolution and what resolution are you using?

Looking at the code, I can see two potential problems, attached a patch that tries to fix them. Even if this doesn't fix anything, I still wonder if this patch shouldn't be applied anyway.

Before you waste a lot of time doing other stuff, I'd try this patch (on top of the previous one).

Applying the 2 patches fixes my system. The setpci business is not needed.

I'm going to assume that fixing the problem makes the answers to the above questions irrelevant. If not, let me know and I will supply that information.

Thanks for keeping on this problem.

For the record, the kernel that I tested is no longer vanilla 2.6.37, but is tracking the .37 => .38 merge. The git describe command lists it as v2.6.37-3737-g0c21e3a. I don't think there have been any i915 changes in the updates.

Confirming fix.
These two patches restore correct LVDS behavior on my Samsung NP-X120 laptop with mainline 2.6.37.

The two patches fix my 'xset dpms force standby; sleep 1; xset dpms force on' problem as well.

Created attachment 43272 [details]
Count backlight enable/disable

It is indeed possible for intel_lvds_disable to be called more often than intel_lvds_enable, due to some fun interactions in drm_kms_helper. It shouldn't but it does.

So we have to track the backlight enable/disable more carefully.

The panel fitting patch looks like it will break switching between non-native resolutions. It should reduce to:


diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds
index 3538e6b..40e1e87 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -371,6 +371,8 @@ static bool intel_lvds_mode_fixup(struct drm_encoder *encode
        }
 
 out:
+       if ((pfit_control & PFIT_ENABLE) == 0)
+               pfit_control = 0;
        if (pfit_control != intel_lvds->pfit_control ||
            pfit_pgm_ratios != intel_lvds->pfit_pgm_ratios) {
                intel_lvds->pfit_control = pfit_control;

Color me "confused". What combination of patches should be tested?

As the report is that both patches are required, the question becomes just what is wrong with the current method of disabling the pfit. The docs say that the requirement is that the panel must be off ((PP_STATUS & PP_ON) == 0) before the pfit can be modified. So from that perspective it looks like the code should not be causing harm. So I am interested in just what values we are programming into pfit_control in lvds_disable() that causes the panel to die.

I have retested with the 1st patch only and it works just fine. So it looks that the second one is not necessary for the proper 
xset dpms force standby; sleep 1; xset dpms force on

usecase

Dell XPS M1330 (GM965/GL960). The 1st patch fixed backlight after panel suspend here also. The 2nd doesn't seem to change anything.

If I max out the backlight, than close and open the lid, the brightness goes one step dimmer; IOW I have to press the button exactly once to restore the brightness to maximum.

To answer my own question from Comment #43, only the 3rd patch was needed to fix my box.

With that patch and today's pull from Linux-2.6.git, the screen is restored from full blanking by mouse or keyboard action. The brightness is restored to the value it was before blanking. Everything looks good here.

Chris' patch (Count backlight enable/disable) fixes both backlight after
suspend issue and that "1 step dimmer after lid close/open" I reported in #46.

Tested with vanilla 2.6.37

I had similar problem on my Toshiba R700 laptop with i5 processor. Details of the graphic adapter are:

00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
	Subsystem: Toshiba America Info Systems Device 0007
	Flags: bus master, fast devsel, latency 0, IRQ 40
	Memory at d0000000 (64-bit, non-prefetchable) [size=4M]
	Memory at c0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 3050 [size=8]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 2
	Capabilities: [a4] PCI Advanced Features
	Kernel driver in use: i915

I have tested Cris' patch and it doesn't fix this problem.

(In reply to comment #49)
> I had similar problem on my Toshiba R700 laptop with i5 processor. Details of
> the graphic adapter are:

Similar, but definitely not the same. Is it an eDP display perchance?
This bug is only on gen3/gen4 (i915-i965 gpus).

The patch from comment 42 on top of .37 fixes the problem as well.

(In reply to comment #50)
> Similar, but definitely not the same. Is it an eDP display perchance?

To be honest, I don't know that. How can I check if it is eDP (embedded Display Port, as far as I understood this acronym) ?

xrandr or Xorg.log

(In reply to comment #53)
> xrandr or Xorg.log

xrandr shows that LVDS1 output is connected and there are also additional not connected outputs like: VGA1, DP1, DP2, HDMI1 and HDMI2

(In reply to comment #54)
> (In reply to comment #53)
> > xrandr or Xorg.log
> 
> xrandr shows that LVDS1 output is connected and there are also additional not
> connected outputs like: VGA1, DP1, DP2, HDMI1 and HDMI2

Ok, if drm-intel-staging also fails, can you please file a new bug report with drm.debug=0xe dmesg, Xorg.log, xrandr --verbose and intel_reg_dumper (before i915.ko loads and afterwards)?

(In reply to comment #55)
> Ok, if drm-intel-staging also fails, can you please file a new bug report
> with
> drm.debug=0xe dmesg, Xorg.log, xrandr --verbose and intel_reg_dumper (before
> i915.ko loads and afterwards)?

Where can I find drm-intel-staging?

http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git

(In reply to comment #42)
> Created an attachment (id=43272) [details]
> Count backlight enable/disable

Hi Chris,

I tried that patch, instead of the "return 0;" thing from Indan's first attempt.
Applied with one shifted hunk on vanilla 2.6.37.

I can CONFIRM that it FIXES the backlight dimming issues I've seen on my Dell laptop.

Thanks!

Patrick

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

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

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

Ok, this particular patch is upstream, though we still have a broken backlight in combination mode and ACPI issues.

(In reply to comment #15)
> My Dell D430 has similar issues. It does not matter in which mode kde puts
> the
> screen: standby, suspend or power off. In all cases the back light stays on
> (i
> have never seen it off). When the screen is 'unblanked' it returns in the
> lowest possible brightness level, and with dis-functional brightness keys
> (separate key's on the keyboard to change the brightness). Closing and
> reopening the lid restores the brightness to maximum level and restores the
> function of the brightness keys. I have bisected the problem to the same
> commit
> as above. I rebuild linus's tree every day, and the bug is still there.

I had similar backlight problems on my Dell D430 and kernel 2.6.36.2. After suspend the brightness keys would fail and the backlight was in a very low state, making the screen hard to read.

I solved it however not by patching the kernel but by adding the following boot option to my /etc/lilo.conf (or grub if you prefer) :

append="video.allow_duplicates=1"

This seems to fix the problem completely and now the backlight is fine
after a restore. Also, now there are 2 lines in dmesg after a restore :

 video LNXVIDEO:00: Restoring backlight state
 video LNXVIDEO:01: Restoring backlight state

while without the boot option there would be only 1 line in dmesg :

 video LNXVIDEO:00: Restoring backlight state

FYI: the option was suggested by the kernel itself :

Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work.

regards,
Kees Lemmens.

Hi,

False alarm : problem is NOT solved with video.allow_duplicates=1. But the problem can be easily avoided in anaoter way : the backlight is ONLY frozen in a low state if a do a suspend and then CLOSE THE LID WHILE IT IS SUSPENDING !

If I first suspend to ram and only close the lid when the system is suspended the backlight is fine after a restore. 

Probably the acpi action for closing the lid and the action for suspend are biting each other if the coincide ?

regards,
Kees Lemmens.

Hi,

False alarm : problem is NOT solved with video.allow_duplicates=1. But the problem can be easily avoided in anaoter way : the backlight is ONLY frozen in a low state if a do a suspend and then CLOSE THE LID WHILE IT IS SUSPENDING !

If I first suspend to ram and only close the lid when the system is suspended the backlight is fine after a restore. 

Probably the acpi action for closing the lid and the action for suspend are biting each other if the coincide ?

regards,
Kees Lemmens.

Kees, this particular problem is fixed upstream already. It was a bug in the 
code, perhaps revealed because of different behaviour than before, but still 
a bug. You can try to work around the bug, but that doesn't solve it.

The reason lid closing makes a difference is because when you close the lid
the screen gets blanked before you suspend and you hit this particular bug. 
If you don't close the lid you have normal suspend resume, which apparently 
works for you.

This particular bug is about screen blanking, not backlight problems after 
suspend.

Will this fix be applied to 2.6.37.1 or do I have to wait for 2.6.38?

It seems fixed to me on 2.6.38-rc2-1. Thanks!

I'm trying 2.6.38-rc2 atm and for me it's nearly fixed: "xset dpms force off; sleep 1; xset dpms force on" brings back the backlight half-decent, but the good thing is I can restore the brightness to full again using the HW keys on my laptop.

Martin, does the same happen after a suspend? Perhaps you're hitting bug 23472: If so, you could try either my "fix_combination_mode" or "remove_is_backlight_combination_mode" patch (perhaps after some modifications for rc1, patch is against 37). Please report at bug 23472 instead of here if it makes any difference.

This patch does not work if the backlight level is set at a maximum.
agpgart-intel 0000:00:00.0: Intel GM45 Chipset
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09)