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 Chipset is Sandy Bridge 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). 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? 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. 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. 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. Created attachment 59713 [details]
demesg_kernel_only
Created attachment 59714 [details]
dmesg with drm.debug=0xe boot option
i915_panel_invert_brightness is the new nomodeset ;-) 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? 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 Created attachment 59792 [details]
dmesg with i915,invert_brightness=1 boot option
Created attachment 59793 [details]
xorg.0.log with i915.invert_brightness=1 boot option
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. 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). 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. (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. Created attachment 59880 [details]
entire file with boot option drm.debug=0xe
Created attachment 59881 [details]
results of intel_reg_dumper on normal boot
Created attachment 59882 [details]
results of intel_reg_dumper with boot option i915.modeset=0
Created attachment 59883 [details]
xrandr --verbose output with boot option i915.modeset=0
(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. 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'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 Created attachment 60496 [details] [review] dp link frobbing Shot in the dark, please try this patch. (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. Created attachment 60499 [details]
Xorg.0.log for boot with modeset
Disregard modeset_Xorg.0.log file and comment #27. Errors were made. OK, here is the correct Xorg.0.log from a modeset boot. Still there are no edid files that have any content. Created attachment 60500 [details]
New Xorg.0.log from a modeset boot
Applied patch dp_link_frobbing. I still get the same behavior. Do you need any logs? > --- 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?
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. 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? $ 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. (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 I reinstalled build essential. That was the problem. 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. 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. (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. Another patch to try (on top of 3.4-rc): https://bugzilla.kernel.org/attachment.cgi?id=73335 (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. (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. 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. Daniel, this kernel branch solved the backlight issues. Thanks for all your hard work. I am marking this bug resolved. (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? I didn't log in. (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. 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. 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. 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. 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. (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 (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. (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. (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. (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. (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 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. 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.
|
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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.