Bug 48435 - [SNB eDP] Screen goes blank 30 seconds into boot
[SNB eDP] Screen goes blank 30 seconds into boot
Status: RESOLVED FIXED
Product: DRI
Classification: Unclassified
Component: DRM/Intel
unspecified
x86-64 (AMD64) other
: medium critical
Assigned To: Daniel Vetter
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-08 07:00 UTC by Joel
Modified: 2012-06-22 20:51 UTC (History)
6 users (show)

See Also:


Attachments
Xorg.0.log, dmesh, xrandr message (89.07 KB, text/plain)
2012-04-08 07:00 UTC, Joel
no flags Details
demesg_kernel_only (122.96 KB, text/plain)
2012-04-10 02:45 UTC, Joel
no flags Details
dmesg with drm.debug=0xe boot option (46.59 KB, text/plain)
2012-04-10 02:46 UTC, Joel
no flags Details
dmesg with i915,invert_brightness=1 boot option (47.84 KB, text/plain)
2012-04-11 02:42 UTC, Joel
no flags Details
xorg.0.log with i915.invert_brightness=1 boot option (41.00 KB, text/plain)
2012-04-11 02:44 UTC, Joel
no flags Details
entire file with boot option drm.debug=0xe (64.04 KB, text/plain)
2012-04-12 16:07 UTC, Joel
no flags Details
results of intel_reg_dumper on normal boot (11.63 KB, text/plain)
2012-04-12 16:08 UTC, Joel
no flags Details
results of intel_reg_dumper with boot option i915.modeset=0 (11.64 KB, text/plain)
2012-04-12 16:09 UTC, Joel
no flags Details
xrandr --verbose output with boot option i915.modeset=0 (1.17 KB, text/plain)
2012-04-12 16:11 UTC, Joel
no flags Details
dp link frobbing (401 bytes, patch)
2012-04-23 13:23 UTC, Daniel Vetter
no flags Details | Splinter Review
Xorg.0.log for boot with modeset (30.81 KB, text/plain)
2012-04-23 16:08 UTC, Joel
no flags Details
New Xorg.0.log from a modeset boot (40.98 KB, text/plain)
2012-04-23 16:36 UTC, Joel
no flags Details
[3.2.y] drm/i915: properly enable the blc controller on the right pipe (6.72 KB, patch)
2012-06-22 12:14 UTC, Jonathan Nieder
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Joel 2012-04-08 07:00:01 UTC
Created attachment 59646 [details]
Xorg.0.log, dmesh, xrandr message

OS:  Debian unstable
uname -r: 3.3.0-trunk-amd64
libdrm version: 2.4.33-1 (from dpkg)
Computer:  Dell Inspiron One 2320
Chipset:  Unknown

When booting the system, the screen goes blank.  I can login and startx blind.  Then I see the graphics screen only with bright light.  The screen is blinking on and off.  After an unspecified time (usually several hours) the screen turns on.  The screen is unstable. It turns off when executing xrandr or attempting to shutdown from the panel icon. When I return to the terminal (ctrl-alt-F1) I can see the text and execute any commands that do not call X.  The only way to return to X is to reboot and follow the above steps again.
Comment 1 Jonathan Nieder 2012-04-08 07:51:04 UTC
Seems like a kernel bug because the screen goes blank before X is started.

References:
 http://bugs.debian.org/660394
 http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/8363/focus=8368
Comment 2 Joel 2012-04-08 12:41:59 UTC
Chipset is Sandy Bridge
Comment 3 Daniel Vetter 2012-04-09 08:22:27 UTC
Please try the kernel from the drm-intel-next branch from

http://cgit.freedesktop.org/~danvet/drm-intel/

If that alone doesn't work, please also try the i915.i915_panel_invert_brightness=1 boot option. Also please add drm.debug=0xe to your kernel cmdline and grab the full dmesg (for the above branch).
Comment 4 Joel 2012-04-09 13:01:32 UTC
Daniel,
I do not know how to compile the kernel from this source.  I want to learn so could you provide me with a link to a how-to on using the drm-intel-next source?
Comment 5 Daniel Vetter 2012-04-09 13:15:43 UTC
If the issue is just with checking out the sources

$ git clone git://people.freedesktop.org/~danvet/drm-intel
$ git checkout -t origin/drm-intel-testing

will do the trick. For compiling a kernel from sources, please consult your distro's resources for howtos.
Comment 6 Jonathan Nieder 2012-04-09 14:46:57 UTC
Once you have a version to build checked out,

 cp /boot/config-$(uname -r) .config; # current configuration
 make localmodconfig; # optional: minimize configuration
 make deb-pkg; # optionally with -j<num> for parallel build

produces a Debian package out of it.
Comment 7 Joel 2012-04-10 02:44:17 UTC
Booting the drm-intel-next kernel did not change the results. Adding the boot option i915.i915_panel_invert_brightness=1 produced a good boot with video turned on, however, the resolution is not optimum. I am attaching the dmesg files you requested.
Comment 8 Joel 2012-04-10 02:45:43 UTC
Created attachment 59713 [details]
demesg_kernel_only
Comment 9 Joel 2012-04-10 02:46:55 UTC
Created attachment 59714 [details]
dmesg with drm.debug=0xe boot option
Comment 10 Chris Wilson 2012-04-10 02:49:53 UTC
i915_panel_invert_brightness is the new nomodeset ;-)
Comment 11 Daniel Vetter 2012-04-10 03:13:30 UTC
Oops, I've been wrong with the module option, it is i915.invert_brightness=1. The one you've used doesn't exist, which prevents the i915 module from loading. Notice the "i915: Unknown parameter `i915_panel_invert_brightness'" in dmesg.

Can you please test again with the fixed cmdline option?
Comment 12 Joel 2012-04-10 06:16:05 UTC
That explains why the screen resolution is the same as when I use the boot option i915.modeset=0.

I'll try the i915.invert_brightness=1 boot option this afternoon when I get home.  Thanks
Comment 13 Joel 2012-04-11 02:42:50 UTC
Created attachment 59792 [details]
dmesg with i915,invert_brightness=1 boot option
Comment 14 Joel 2012-04-11 02:44:28 UTC
Created attachment 59793 [details]
xorg.0.log with i915.invert_brightness=1 boot option
Comment 15 Joel 2012-04-11 02:49:44 UTC
I cold booted the drm-intel-next kernel with the i915.invert_brightness=1 boot option.  The framebuffer started but the screen went blank before the boot sequence finished. I logged in and sarted X in the blind.  After about a minute the video turned on. The screen had horizontal bands of trash flashing at random locations on the screen.  After about a minute the screen went blank and stayed off.  I have attached the dmesg log and the xorg.0.log from this boot.
Comment 16 Daniel Vetter 2012-04-11 03:06:53 UTC
Can you also attach full dmesg with drm.debug=0xe (from drm-intel-next) and xrandr --verbose (for that you need to be in an X session), please?

Also, can you please install intel-gpu-tools v1.2 and attach the full output of intel_reg_dumper, once when booting with nomodeset, once when booting with the broken setup (not special boot options required, but for the nomodeset preferrably run X with the native resolution of your display, if possible).
Comment 17 Joel 2012-04-12 05:04:27 UTC
I have cloned the files at git://anongit.freedesktop.org/xorg/app/intel-gpu-tools.
Is it necessary to checkout?  If so what is the object?  When I use git -t checkout origin/intel-gpu-tools I get an error. I must be doing something wrong.
Comment 18 Jonathan Nieder 2012-04-12 06:15:10 UTC
(In reply to comment #17)
> I have cloned the files at
> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools.
> Is it necessary to checkout?  If so what is the object?  When I use git -t
> checkout origin/intel-gpu-tools I get an error.

Thanks.

Here's how to list remote-tracking branches available for checkout: http://jk.gs/user-manual.html#examining-remote-branches
In this example, 'master' (checked out by default) looks like the right
one.

Using the intel-gpu-tools package from Debian sid might be simpler, though. It's new enough.
Comment 19 Joel 2012-04-12 16:07:36 UTC
Created attachment 59880 [details]
entire file with boot option drm.debug=0xe
Comment 20 Joel 2012-04-12 16:08:36 UTC
Created attachment 59881 [details]
results of intel_reg_dumper on normal boot
Comment 21 Joel 2012-04-12 16:09:41 UTC
Created attachment 59882 [details]
results of intel_reg_dumper with boot option i915.modeset=0
Comment 22 Joel 2012-04-12 16:11:16 UTC
Created attachment 59883 [details]
xrandr --verbose output with boot option i915.modeset=0
Comment 23 Joel 2012-04-12 16:13:10 UTC
(In reply to comment #16)
> Can you also attach full dmesg with drm.debug=0xe (from drm-intel-next) and
> xrandr --verbose (for that you need to be in an X session), please?
> 

I am attaching the entire dmesg file from /var/log/.  While in an X session, I ran xrandr --verbose.  The result was "Can't open display".  I ran xrandr --verbose again while booted with nomodeset.

> Also, can you please install intel-gpu-tools v1.2 and attach the full output of
> intel_reg_dumper, once when booting with nomodeset, once when booting with the
> broken setup (not special boot options required, but for the nomodeset
> preferrably run X with the native resolution of your display, if possible).

When I am running in nomodeset I am not in the native resolution and when I am in an X session under a normal boot, I cannot get an output from xrandr.
Comment 24 Daniel Vetter 2012-04-23 13:18:37 UTC
2 more things to attach please:
- Xorg log for the modeset case (I have no idea why xrandr fails for you).
- in sysfs we have edid files, for your output it's likes /sys/class/drm/card-0-DP-1 (or maybe eDP-1). Please grab a edid files which are not empty.
Comment 25 Daniel Vetter 2012-04-23 13:20:01 UTC
I've looked at the register dumps and dmesg, eDP output at 1920x1080, only 2 things stick out:
- we pick slightly different pll values
- kms picks -hsync, bios +hsync
Comment 26 Daniel Vetter 2012-04-23 13:23:53 UTC
Created attachment 60496 [details] [review]
dp link frobbing

Shot in the dark, please try this patch.
Comment 27 Joel 2012-04-23 16:07:00 UTC
(In reply to comment #24)
> 2 more things to attach please:
> - Xorg log for the modeset case (I have no idea why xrandr fails for you).
> - in sysfs we have edid files, for your output it's likes
> /sys/class/drm/card-0-DP-1 (or maybe eDP-1). Please grab a edid files which are
> not empty.

I have attached the Xorg.0.log which was generated from a modeset boot.

There are no directories /sys/class/drm/card-0-DP-1 or eDP-1.  So no edid files.
Comment 28 Joel 2012-04-23 16:08:10 UTC
Created attachment 60499 [details]
Xorg.0.log for boot with modeset
Comment 29 Joel 2012-04-23 16:24:44 UTC
Disregard modeset_Xorg.0.log file and comment #27.  Errors were made.
Comment 30 Joel 2012-04-23 16:34:58 UTC
OK, here is the correct Xorg.0.log from a modeset boot.
Still there are no edid files that have any content.
Comment 31 Joel 2012-04-23 16:36:00 UTC
Created attachment 60500 [details]
New Xorg.0.log from a modeset boot
Comment 32 Joel 2012-04-23 18:17:41 UTC
Applied patch dp_link_frobbing. I still get the same behavior.  Do you need any logs?
Comment 33 Daniel Vetter 2012-04-24 01:40:38 UTC
> --- Comment #32 from Joel <jheaton5@linuxmail.org> 2012-04-23 18:17:41 PDT ---
> Applied patch dp_link_frobbing. I still get the same behavior.  Do you need any
> logs?

Nope. Also, please double-check that there's no edid file anywhere in
/sys/class/drm - if that's the case there's something strange going on
with your distro.

Also, I have no idea why xrandr doesn't work on X with modeset, it really
should. btw, do you have a second screen to make all the logfile grabbing
easier without the backlight on?
Comment 34 Joel 2012-04-24 02:18:11 UTC
I am logged in to the object computer from a remote computer on the network through ssh.  That's how I am able to get the log files and run any tests.  Xrandr kills X and the backlight when I run it in modeset.
Comment 35 Joel 2012-04-26 04:35:02 UTC
I deleted the drm-intel kernel and tried to grab the git file again. to see if I had some problem with the kernel.  I can't checkout the drm-intel-testing commit again.  Which commit should I use?
Comment 36 Daniel Vetter 2012-04-26 04:38:51 UTC
$ git clone git://people.freedesktop.org/~danvet/drm-intel
$ cd drm-intel
$ git checkout origin/drm-intel-testing

should work. If not, please paste the error message you get into the bug report.
Comment 37 Joel 2012-04-26 20:12:15 UTC
(In reply to comment #36)
> $ git clone git://people.freedesktop.org/~danvet/drm-intel
> $ cd drm-intel
> $ git checkout origin/drm-intel-testing
> 
> should work. If not, please paste the error message you get into the bug
> report.

I got the version checked out but got error when trying to make loocalmodconfig

jheaton5@debian:~/drm-intel$ git checkout origin/drm-intel-testing
Note: checking out 'origin/drm-intel-testing'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at f6e066e... Merge remote-tracking branch 'danvet/drm-intel-fixes' into drm-intel-testing
jheaton5@debian:~/drm-intel$ cp /boot/config-$(uname -r) .config;
jheaton5@debian:~/drm-intel$ make localmodconfig;
  HOSTCC  scripts/basic/fixdep
scripts/basic/fixdep.c:106:23: fatal error: sys/types.h: No such file or directory
compilation terminated.
make[1]: *** [scripts/basic/fixdep] Error 1
make: *** [scripts_basic] Error 2
Comment 38 Joel 2012-04-29 13:47:15 UTC
I reinstalled build essential.  That was the problem.
Comment 39 Joel 2012-04-29 14:29:54 UTC
I have recompiled and booted into the drm-intel kernel.  I deleted the previous build and rebuilt from a new clone.  I did that because Daniel thought there might be something wrong with my system since there were no edid files.

With the new kernel, there are several edid files in /sys/class/drm/* but they all are emtpy.
Comment 40 Joel 2012-05-15 07:27:49 UTC
I just tried drm-intel image 3.4.0-rc5 with no joy.  I thought I'd provide an updated description of the behavior I am seeing.
I have used 3.3.0-trunk, 3.4.0-rc4 and now 3.4.0-rc5.

In 3.3.0-trunk when I startx, I get a black screen but the background image if visible by shining a bright light on the screen.  The image is blinking on/off @ 1 sec. cycles. After an inconsistent interval (5 min to 5 hrs) the backlight comes on and the video stabilizes.  From that point forward I have a useable system.  To do my daily d-u, I go to tty1 (<ctrl><alt>F1) and shutdown x with <ctrl>C.  The backlight remains on.  I complete the d-u and then startx.  The system does not immediately come back on, but enters the same pattern as above. It eventually comes on.

In 3.4.0-rc4 & 3.4.0-4c5, the behavior is identical to 3.3.0-trunk until we get to the blinking background screen.  At that point the system never recovers.

Obviously, something changed between 3.3 and 3.4 that stops the backlight and X from eventually turning on.

I hope this helps.
Comment 41 Joel 2012-05-16 16:56:52 UTC
(In reply to comment #36)
> $ git clone git://people.freedesktop.org/~danvet/drm-intel
> $ cd drm-intel
> $ git checkout origin/drm-intel-testing
> 
> should work. If not, please paste the error message you get into the bug
> report.

I just tried drm-intel image 3.4.0-rc5 with no joy.  I thought I'd provide an
updated description of the behavior I am seeing.
I have used 3.3.0-trunk, 3.4.0-rc4 and now 3.4.0-rc5.

In 3.3.0-trunk when I startx, I get a black screen but the background image if
visible by shining a bright light on the screen.  The image is blinking on/off
@ 1 sec. cycles. After an inconsistent interval (5 min to 5 hrs) the backlight
comes on and the video stabilizes.  From that point forward I have a useable
system.  To do my daily d-u, I go to tty1 (<ctrl><alt>F1) and shutdown x with
<ctrl>C.  The backlight remains on.  I complete the d-u and then startx.  The
system does not immediately come back on, but enters the same pattern as above.
It eventually comes on.

In 3.4.0-rc4 & 3.4.0-4c5, the behavior is identical to 3.3.0-trunk until we get
to the blinking background screen.  At that point the system never recovers.

Obviously, something changed between 3.3 and 3.4 that stops the backlight and X
from eventually turning on.

I hope this helps.
Comment 42 Daniel Vetter 2012-05-19 14:22:45 UTC
Another patch to try (on top of 3.4-rc):

https://bugzilla.kernel.org/attachment.cgi?id=73335
Comment 43 Joel 2012-05-20 06:25:24 UTC
(In reply to comment #42)
> Another patch to try (on top of 3.4-rc):
> 
> https://bugzilla.kernel.org/attachment.cgi?id=73335

I applied the patch.  There is no change in behavior.
Comment 44 Joel 2012-05-20 06:55:25 UTC
(In reply to comment #43)
> (In reply to comment #42)
> > Another patch to try (on top of 3.4-rc):
> > 
> > https://bugzilla.kernel.org/attachment.cgi?id=73335
> 
> I applied the patch.  There is no change in behavior.

After about 30 minutes the screen turned on.  There were horizontal bands of static of random heights and random locations on the screen. The screen turned off after about 10 seconds.
Comment 45 Daniel Vetter 2012-06-20 01:27:47 UTC
Please try the latest drm-intel-next-queued git branch from

http://cgit.freedesktop.org/~danvet/drm-intel

That contains backlight fixes that are known to fix at least one other snb machine.
Comment 46 Joel 2012-06-21 20:23:21 UTC
Daniel, this kernel branch solved the backlight issues.  Thanks for all your hard work.  I am marking this bug resolved.
Comment 47 Jonathan Nieder 2012-06-22 08:17:15 UTC
(In reply to comment #46)
> Daniel, this kernel branch solved the backlight issues.  Thanks for all your
> hard work.

Nice.

Do you know which commit has the fix? Is it marked for backporting to stable?
Comment 48 Joel 2012-06-22 09:17:22 UTC
I didn't log in.
Comment 49 Jonathan Nieder 2012-06-22 09:25:13 UTC
(In reply to comment #48)
> I didn't log in.

Context: Joel mentioned that he couldn't reply through the bugtracker and
I asked why.

When this fix is in mainline, please let me know (through this bug,
through cc: stable@, or some other way) so we can make sure older kernels
get it, too.  Thanks for your hard work.
Comment 50 Daniel Vetter 2012-06-22 10:35:02 UTC
My bet is on the reworked backlight code, specifically:

commit 24ded204429fa0f5501d37c63ee35c555c0b75ee
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Jun 5 12:14:54 2012 +0200

    drm/i915: properly enable the blc controller on the right pipe

This is merged into drm-intel-next and will land in 3.6. No cc: stable, too risky imo.
Comment 51 Jonathan Nieder 2012-06-22 12:14:00 UTC
Created attachment 63360 [details] [review]
[3.2.y] drm/i915: properly enable the blc controller on the right pipe

Daniel Vetter wrote:

> My bet is on the reworked backlight code, specifically:
>
> commit 24ded204429fa0f5501d37c63ee35c555c0b75ee
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Tue Jun 5 12:14:54 2012 +0200
>
>     drm/i915: properly enable the blc controller on the right pipe
>
> This is merged into drm-intel-next and will land in 3.6. No cc: stable, too
> risky imo.

Thanks!  I can understand that.

3.2.y still has at least three years of life ahead, so I would like to
find a way to fix this there.  Perhaps we can give this some testing in
Debian wheezy before a more targeted fix is found for upstream.

Untested backport attached.  Joel, can you try this against the
linux-3.2.y branch from
<git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git>?

If you have any questions, please don't hesitate to ask.
Comment 52 Joel 2012-06-22 17:25:42 UTC
I compiled stable/linux-3.2.y with the patch 63360.  It doesn't work. The backlight goes off during the boot sequence.  I can login and startx in the blind and I see the background screen flashing on and off with no backlight.  Same behavior as before.
Comment 53 Joel 2012-06-22 17:54:12 UTC
I have been over my steps again and I don't think the patch applied properly.  I applied it before I made the deb package of the 3.2.y kernel.  I will make the kernel and apply the patch in that order, like I should have done the first time.  Sorry your having to rely on an amature. I'll let you know when I'm done.
Comment 54 Jonathan Nieder 2012-06-22 18:27:49 UTC
(In reply to comment #53)
> I have been over my steps again and I don't think the patch applied properly. 
> I applied it before I made the deb package of the 3.2.y kernel.  I will make
> the kernel and apply the patch in that order, like I should have done the first
> time.

Do you mean the opposite? :)

Here are steps I use to test, for concreteness.

1. get the kernel history, if you don't already have it:

  git clone \
    git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

2. get point releases:

  cd linux
  git remote add stable \
    git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
  git fetch stable

3. apply patch, test:

  git checkout stable/linux-3.2.y
  git am -3sc /path/to/the/patch
  cp /boot/config-$(uname -r) .config; # current configuration
  scripts/config --disable DEBUG_INFO
  make localmodconfig; # optional: minimize configuration
  make deb-pkg; # optionally with -j<num> for parallel build
  dpkg -i ../<name of package>; # as root
  reboot
Comment 55 Joel 2012-06-22 18:38:06 UTC
(In reply to comment #54)
> (In reply to comment #53)
> > I have been over my steps again and I don't think the patch applied properly. 
> > I applied it before I made the deb package of the 3.2.y kernel.  I will make
> > the kernel and apply the patch in that order, like I should have done the first
> > time.
> 
> Do you mean the opposite? :)
> 
> Here are steps I use to test, for concreteness.
> 
> 1. get the kernel history, if you don't already have it:
> 
>   git clone \
>     git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 
> 2. get point releases:
> 
>   cd linux
>   git remote add stable \
>     git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>   git fetch stable
> 
> 3. apply patch, test:
> 
>   git checkout stable/linux-3.2.y
>   git am -3sc /path/to/the/patch
>   cp /boot/config-$(uname -r) .config; # current configuration
>   scripts/config --disable DEBUG_INFO
>   make localmodconfig; # optional: minimize configuration
>   make deb-pkg; # optionally with -j<num> for parallel build
>   dpkg -i ../<name of package>; # as root
>   reboot

Thanks for the steps.  I used a different method that I got from you at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660394#31

Let me try again using the method you have outlined above.
Comment 56 Jonathan Nieder 2012-06-22 18:48:26 UTC
(In reply to comment #55)
> Thanks for the steps.  I used a different method that I got from you at
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660394#31

I see. :)  The instructions at that URL use a more advanced technique:
testing with and without the patch and comparing the results.
Comment 57 Jonathan Nieder 2012-06-22 18:51:27 UTC
(In reply to comment #56)
>            The instructions at that URL use a more advanced technique:
> testing with and without the patch and comparing the results.

Also, to start, take care to clear away any patches you already have
applied.  "git reset --hard" should do the trick.  Sorry for the fuss -
I guess I should include that in the list of instructions.
Comment 58 Joel 2012-06-22 19:33:35 UTC
(In reply to comment #57)
> (In reply to comment #56)
> >            The instructions at that URL use a more advanced technique:
> > testing with and without the patch and comparing the results.
> 
> Also, to start, take care to clear away any patches you already have
> applied.  "git reset --hard" should do the trick.  Sorry for the fuss -
> I guess I should include that in the list of instructions.

I compiled using your instruction in #54. The result is the same as before.  I didn't get your suggestion about clearing previous patches beforehand. I'll do it again.
Comment 59 Jonathan Nieder 2012-06-22 19:38:58 UTC
(In reply to comment #58)
> I compiled using your instruction in #54. The result is the same as before.  I
> didn't get your suggestion about clearing previous patches beforehand. I'll do
> it again.

Unless you got a message about the patch not applying, I think it's more
likely that you did everything right and my backport just didn't fix it.

For reference, here are the patched sha1sums:

$ lsdiff --strip=1 /path/to/patch | xargs sha1sum
a647bd15f36fa8307d169e1a589ebdaf49cfa9cb  drivers/gpu/drm/i915/i915_reg.h
394d8bb8dfe816aef7830797b2df32fdf8fe640a  drivers/gpu/drm/i915/intel_drv.h
0580add4a5e1e0f5e83e8fa54e8ebf39cc4b9a1f  drivers/gpu/drm/i915/intel_lvds.c
f70e49f1e9f25b37e6171bd12ce50b60afa1d0ec  drivers/gpu/drm/i915/intel_panel.c
Comment 60 Joel 2012-06-22 20:24:01 UTC
I followed your instructions exactly.  I entered git reset --hard just before applying the patch.  Still did not fix the back light issue in 3.2.
Comment 61 Jonathan Nieder 2012-06-22 20:51:33 UTC
Findings so far:

Chipset: Sandybridge Desktop (GT1).

bad = backlight turns off during boot.
(There are more nuances such as blinking later, but for concreteness
I'm focusing on the backlight state before X is started.)

* Debian 3.2.6-1: bad
* pristine v3.2.7: bad
* v3.2.7 + 7885d2052bd9 ("drm/i915: mask transcoder select bits before
  setting them on LVDS"): bad
* Debian 3.3-1~experimental.1: bad
* drm-intel-testing 2012-04-09 ("3.4.0-rc1+"): bad
* same with i915.invert_brightness=1: bad
* drm-intel-testing 2012-04-26 or so ("3.4.0-rc5+"): bad
* ?? + 17038de5f165 ("drm/i915/dp: Flush any outstanding work to turn
  the VDD off") + 6cb49835da04 ("drm/i915: enable vdd when switching
  off the eDP panel"): bad
* drm-intel-testing 2012-06-21: good!
* v3.2.21 + backported 24ded204429f ("drm/i915: properly enable the
  blc controller on the right pipe"): bad

The bug log also includes some register dumps and other details.