In early boot, when the kernel sets the mode in a mobile intel sandy bridge video adapter the brightness is set to zero. The display then becomes unreadable. If I disable KMS, the problem disappears. If I boot in text mode (no X involved) the problem persists as long as KMS is enabled. If I boot a Live CD that starts a desktop session automaticaly, I can increase the brightness using the brightness controls. The workaround is to put: echo 7 > /sys/class/backlight/acpi_video0/brightness in some initialization script. I'm using Fedora 16 with 3.1 kernel, but the problem persists with 3.2-rc4.
Created attachment 54180 [details] dmesg with debug on
drm.debug=0x4 doesn't include the details about the panel backlight, you need to use drm.debug=0xe. Can you please attach the boot dmesg with the increased verbosity?
Created attachment 54184 [details] dmesg with drm.debug=0xe You are right. In this log it's possible to see at 12.82s the point where my workaround kicks in and the brightness is set to 7. Before that, it's the normal driver operation.
Please retest with 3.4-rc1 (or the latest git snapshot if -rc1 isn't out there yet when you try to test). That contains a few backlight fixes which might help in your case here.
Ok assuming this one is fixed since the reporter hasn't responded. Gustavo, please re-open if not.
I've retested with kernel 3.4.2 (as packaged by Fedora: kernel-3.4.2-1.fc16.x86_64) and the problem is still present.
Gustavo, can you please test the drm-intel-next-queued git branch from http://cgit.freedesktop.org/~danvet/drm-intel That contains patches that are know to fix some backlight issues on snb.
Tested drm-intel-next-queued as of today and the problem is still present.
Presumably fixed with commit 6db65cbb941f9d433659bdad02b307f6d94465df Author: Takashi Iwai <tiwai@suse.de> Date: Thu Jun 21 15:30:41 2012 +0200 drm/i915: Fix eDP blank screen after S3 resume on HP desktops Which is merged into 3.5, cc stable kernels.
Tested with 3.4.9 (Fedora 3.4.9-1.fc16.x86_64), that includes this commit and the problem persists. More information: 1) This bug appears at system boot, not on S3 resume. Suspend and resume work perfectly. 2) This bug shows on a display connected on LVDS.
I have the same problem with an Ivybridge machine (HP Envy 4t Laptop). Brightness is set to 0 during kms enable upon first boot. (I select the kernel in Grub -> few moments later the screen goes dark.) Workaround is to hit Fn-F3 to brighten the display. The display appears to be working, just that brightness is 0. If there was a workaround to script brightening the display in userland, that would be acceptable as a fix for me (but this should be a kernel issue?)...
Ok I also wanted to mention that this was observed in 3.4.9-Gentoo. I'm not sure what happened to that statement when I did the initial post. The backlight turns off before init gets called. I just verified that setting a new value into /sys/class/backlight/acpi_video0/brightness works, and this is enough of a workaround for me for now (but it does get somewhat annoying when looking at the boot log trying to debug other startup issues, it's a fresh install.)
Tried Linux kernel general release 3.5.2 - problem still exists. I wish this laptop had a serial port so that I could slow the boot sequence down to see exactly when the screen goes dark, but it happens within the first 3 seconds of boot, I'm lucking if I can catch init. In my dmesg (similar to Gustavo's except the times are different) I see PWM set to 0 at 0.9s, then back to max at 1.6s, then set to 0 at 1.7s. Best I can do is assume when the PWM is set it's exactly when the event happens.
From your description it sounds more like something from userspace sets the brightness to 0 at boot, since brightness controls seem to work as advertised. Also, the intel_backlight is only a fallback in case your firmware doesn't expose anything else, userspace /should/ prefer the acpi backlight controller (or any other more specific backlight exposed by the firmware). No much idea what's going on here unfortunately ...
I tried booting without my initramfs, setting init=/bin/bash and root=/dev/sda3 (my hard drive so it can find bash). The screen still goes dark and stays dark until I fn-F3 to brighten it. This should show that it's the kernel darkening the display before init runs (unless bash does something weird...) I see both /sys/class/backlight/acpi_video0/brightness and /sys/class/backlight/intel_backlight/brightness but dmesg all reports intel_backlight. Not sure why the kernel itself is not using ACPI? Not sure how this should work...
(In reply to comment #15) > I tried booting without my initramfs, setting init=/bin/bash and root=/dev/sda3 > (my hard drive so it can find bash). The screen still goes dark and stays dark > until I fn-F3 to brighten it. This should show that it's the kernel darkening > the display before init runs (unless bash does something weird...) > > I see both /sys/class/backlight/acpi_video0/brightness and > /sys/class/backlight/intel_backlight/brightness but dmesg all reports > intel_backlight. Not sure why the kernel itself is not using ACPI? Not sure > how this should work... Please attach the output of $ cat /sys/kernel/debug/dri/0/i915_opregion | od -t x1 when the display is dark, and after you've increased the brightness using the keys.
(In reply to comment #11) > I have the same problem with an Ivybridge machine (HP Envy 4t Laptop). > Brightness is set to 0 during kms enable upon first boot. (I select the kernel > in Grub -> few moments later the screen goes dark.) > > Workaround is to hit Fn-F3 to brighten the display. The display appears to be > working, just that brightness is 0. Please also attach your dmesg with drm.debug=0xe, from boot until and including you using Fn-F3 to brighten the display. Thanks.
Created attachment 66737 [details] dmesg with drm.debug=0xe for HP Envy4t w/3rd Gen Core i5 Getting the dumps have been trickier than I thought (specifically the opregion), will try to revert back to default Gentoo setup as it sets up all directories automatically (and more importantly loads all modules...) I'd say the critical moment is why the kernel is setting PWM = 0 at around time = 1.108192. At 1.449732 it again sets it to 0, but 300ms later at 1.756318 it turns it on full blast. 50 milliseconds later, at 1.807509 it shuts it off once more. (I do not see the blinking so I don't know if this really is happening, then again a 50 ms blink with possible low pass filtering in the backlight circuitry, not sure if I can see it.) Around the time 16, that's when I had my startup script write a new value into brightness, making the screen visible again. My guess is around time 7.706841 is when my initramfs starts, there are tell tale signs after this point. Again, the order of events seems very similar to Gustavo's log.
Created attachment 66755 [details] i915_opregion while screen is dark Same machine but with kernel 3.4.9-gentoo After screen is brightened, this is the diff between the two. 19c19 < 00000310 00 00 00 80 06 00 00 80 00 00 00 80 11 80 16 8a |................| --- > 00000310 19 00 00 80 06 00 00 80 09 00 00 80 11 80 16 8a |................|
(In reply to comment #19) > Created attachment 66755 [details] > i915_opregion while screen is dark > > Same machine but with kernel 3.4.9-gentoo > > After screen is brightened, this is the diff between the two. > > 19c19 > < 00000310 00 00 00 80 06 00 00 80 00 00 00 80 11 80 16 8a > |................| > --- > > 00000310 19 00 00 80 06 00 00 80 09 00 00 80 11 80 16 8a |................| The difference is in the opregion requested backlight brightness, 0x00 vs. 0x19 out of maximum 0xff. The 0x80 at offset 0x313 indicates the value is valid. The request comes through ACPI, and kernel sets what ACPI asks. (Perhaps this also answers your question about ACPI in comment #15.) Indeed, AFAICT the below intel_panel_get_max_backlight(), intel_panel_actually_set_backlight() sequence is only possible on ACPI requests, but since we don't have debugs there, I can't be 100% sure. [ 1.807427] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882 [ 1.807430] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4882 [ 1.807507] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882 [ 1.807509] [drm:intel_panel_actually_set_backlight], set backlight PWM = 0 Why the ACPI would change its mind about the brightness it wants in less than a 1 ms, I have no idea.
New data: I think I have found something interesting: The bug is some sort of race condition. Not knowing about how to debug this I tried to make it dump the stack when setting the PWM in gpu/drm/i915/intel_panel.c With this instrumentation the backlight will turn off during initialization (seems that the code will shut off all panels) but will turn the panel backlight back on within a second, enough to start dumping the rest of the boot sequence to the display.) Unfortunately since this seems to be a race condition of sorts, the stack dumps probably isn't very useful... Hmm... still seeing if I can collect additional data as to why it's setting it back to 0.
(In reply to comment #21) > With this instrumentation the backlight will turn off during initialization > (seems that the code will shut off all panels) but will turn the panel > backlight back on within a second, enough to start dumping the rest of the boot > sequence to the display.) I'd be interested in a dmesg with drm.debug=0xe on a boot where this happens.
Created attachment 66969 [details] dmesg, after adding dump_stack based on the call traces, 1.046240 backlight off (init, lvds disable) 1.376800 backlight off (this call I don't understand) 1.711346 backlight full blast (lvds enable) 1.802276 backlight full blast (appears to be user mode setting as witnessed by the call stack which matches future calls?) 11.028084 backlight on at level 2, this I'm pretty sure is the user mode setting of the backlight in by boot scripts. Subsequent calls I think is Gnome/X11 slowly brightening the display during boot. I could understand why during init, to shut everything down once and re-enable once, the second calls to each I don't... Comparing back to the original dmesg, the 1.807509 setting should not have happened. However the instrumentation caused the code to behave different which is weird.
Again some kernel hacking newbieness here, I don't know what functions are reentrant or legal so I'm sure I'll get strange results, all part of learning... I tried adding a msleep() into intel_panel_actually_set_backlight instead of causing dumps. msleep(20) didn't appear to do anything (behavior same as before) but larger values caused bad things to happen - but msleep() of 50, 100, and 200 cause the kernel to endless loop freeze (seems msleep()ing there for a while is bad for whatever reason.) BUT... The display is ON without Fn-F3'ing and I could see the endless loop crash happening!
I have an HP Envy 3040nr and my screen backlight is set to zero upon boot. I have to set the brightness up everytime. This is present on Arch Linux (my main distribution), Ubuntu, Mint, Fedora, and Suse. I have the latest kernel 3.5.4 Here are my laptop specs: http://www.newegg.com/Product/Product.aspx?Item=N82E16834158219
(In reply to comment #25) > I have an HP Envy 3040nr and my screen backlight is set to zero upon boot. I > have to set the brightness up everytime. This is present on Arch Linux (my > main distribution), Ubuntu, Mint, Fedora, and Suse. > I have the latest kernel 3.5.4 > Here are my laptop specs: > http://www.newegg.com/Product/Product.aspx?Item=N82E16834158219 We would prefer separate bug reports unless you have the insight to be quite sure this is the same bug as reported here. It's easy to resolve extra bugs as duplicates, but it can get fairly confusing if data for two distinct bugs start to accumulate on one bug. On the new bug report, please attach dmesg with drm.debug=0xe. The newegg link says the machine has Radeon graphics - do you have that disabled? This bug is about Intel graphics. What does "upon boot" mean? Is the backlight off when you turn on the machine, or does the backlight switch off during KMS?
On my airplane flight I decided to mess with this a bit. I think msleep() is illegal this routine so I ditched this route. For kicks I tried putting in a spinloop (which is bad, as it's CPU speed dependent). When I did this: static void intel_panel_actually_set_backlight(struct drm_device *dev, u32 level) { volatile int foo; struct drm_i915_private *dev_priv = dev->dev_private; u32 tmp; DRM_DEBUG_DRIVER("set backlight PWM = %d\n", level); /* * need a 1ms or so delay. Cannot schedule a msleep here, and no usleep? */ for(foo=0;foo<555555;foo++); level = intel_panel_compute_brightness(dev, level); if (HAS_PCH_SPLIT(dev)) return intel_pch_panel_set_backlight(dev, level); the display now turns on again after being shut off during initialization. If anyone else with this issue would like to try this patch, it's definitely not clean but at least it seems to help the issue... I used the 555555 as it seems to work on my i5-3317u without killing boot times too much, may need to tweak for other CPUs, or find a cleaner solution.
A more important question is what is the delay required after? A delay here kind of suggests that your firmware is broken.
Shot in the dark: Can you please try with latest drm-intel-fixes (or upstream 3.7-rc1), specifically the following commit?commit d627b62ff8d4d36761adbcd90ff143d79c94ab22 Author: Lekensteyn <lekensteyn@gmail.com> Date: Tue Jun 26 00:36:24 2012 +0200 i915: initialize CADL in opregion
I just tried Linux mikuru 3.7.0-rc1 #1 SMP Wed Oct 17 21:49:25 MDT 2012 x86_64 Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz GenuineIntel GNU/Linux The kernel still does not turn the backlight back on and thus dark until usermode does so.
Bug still present with latest drm-intel-fixes. Based on my experience with HP laptops, I would bet on a firmware bug that needs to be worked around. When this machine boots Win7, it turns off the display briefly before de mouse cursor appears.
If this really is some firmware bug then who's the contact to HP to fix this? Apparently there are at least two, maybe three HP machines that have this issue and no other manufacturers? Or will a workaround need to be used? I accidently found a position where a delay seemed to help, so I don't know why it works... It was dumb luck that it seemed to be some sort of race condition trying to figure out how/why it ran each set_brightness and I'm sure there are other places where the delay could work... If anyone is interested in my hacky workaround patch to verify if our machines are all having the same problem, this is against 3.7-rc1 but I didn't actually test it against that, this was tested against 3.4.9 and 3.5.2 (with fuzz), however (or just manually edit the file ala above comment.) I believe the randomly selected constant 555555 will work for any Core CPU except maybe an overclocked machine (rough guess at how many loop iterations plus fuzz to get 1ms), but don't be tweaking this number just to see if it works... Assume it fails (unless you really want to play with it :) diff -ru linux-3.7-rc1-orig/drivers/gpu/drm/i915/intel_panel.c linux-3.7-rc1/drivers/gpu/drm/i915/intel_panel.c --- linux-3.7-rc1-orig/drivers/gpu/drm/i915/intel_panel.c 2012-10-14 15:41:04.000000000 -0600 +++ linux-3.7-rc1/drivers/gpu/drm/i915/intel_panel.c 2012-10-18 22:42:23.869985519 -0600 @@ -258,6 +258,8 @@ { struct drm_i915_private *dev_priv = dev->dev_private; u32 tmp; + volatile loopfoo; + for(loopfoo=0;loopfoo<555555;loopfoo++); DRM_DEBUG_DRIVER("set backlight PWM = %d\n", level); level = intel_panel_compute_brightness(dev, level);
I
I've tested with the delay of comment 32 and the display isn't dark anymore. However, strangely, when the login screen appears it sets the brightness to zero again. This time it is surely a userspace thing, but the brightness controls are a bit weird, with only 5 steps instead of 10. Might be unrelated though, because I patched drm-intel-fixes instead of 3.6. Anyway, even though random delays don't appear to the a reasonable workaround, I suppose we have found a way to identify the problem. My machine, a HP dm4-2035br, and the HP Envy 4t probably share the same problem. I know another owner of a dm4 (different model) with the same problem. Yes, it's an HP thing...
I just tested the patch against 3.7-rc1 proper and it also now exhibits the expected behavior. That is weird that the user space issue is also plaguing the machine. I suppose Gnome is saving some state that is kept in user preferences, I wonder if it will also poll the current state or use the same "brightness" setting available in the kernel regardless if it's via intel direct or ACPI if they use different values to mean the same brightness level... Hmm. (Looks like GNOME for me also has 6 levels, with level 1 being backlight off.) I suppose until we get a real patch (and it's probably HP that needs to do it?) I will have to hack my kernels with the delay so I can see bootup status (and my penguins:)) without having to turn on brightness... How *does* the firmware get used in the brightness interface anyway? ACPI DSDT firmware or something to that extent?
On Sat, Oct 27, 2012 at 4:31 AM, <bugzilla-daemon@freedesktop.org> wrote: > How *does* the firmware get used in the brightness interface anyway? ACPI > DSDT firmware or something to that extent? This is unfortunately a question that can't be answered by mere mortals. Our best guess for now is: - with some magic platform specific thing (think all the vendor/platform specific acpi modules in the kernel) - with the normal acpi backlight (maybe, if that doesn't disable it) - with the native backlight controller in the hw (but some vendoers that use this manage to wire it up the wrong way to the pwm, so we need to invert the values) - through the opregion interface (where the driver gets sent change requests, which it can deny or accept) - through SMM and special firmware-only interrupts generate when writing specific registers Plus any funny interractions of the above: E.g. write the backlight value to the native backlight controller, which generates a special SMM interrupt to the firmware, which the generates the opregion request, which the driver feeds back to the firmware, which then adjusts the backlight. Or so goes the story, but only if all the things in between work out correctly. We know that random vendor firmware checks random (acpi) tables for random things, so we try to fake them as well as possible ...
If HP does not do anything, how can we close this bug? I don't think we can "assign" this to HP here? Though I can "fix" this myself for my own kernel builds, I suspect there are many people completely baffled by this behavior in different distributions. One notable example is the GNU Parted bootable CD, which incidently is x86 and not x86_64. A Windows user tries to run it and the screen goes dark... Perhaps we can live with a delay. How would one be accepted into the kernel? What would be needed if HP does not pony up the info needed? Spinloops like what I have are surely no-go but maybe something similar somewhere would be acceptable?
Sleeps are a no-go since our boot time already takes too long - we're trying hard to shave off delays ...
Next thing I'd try is to add another call to brighten the display as a workaround, where would be an appropriate call near the end of the initialization routines to call brightness one last time before handoff to the rest of the kernel boot?
(In reply to comment #23) > Created attachment 66969 [details] > dmesg, after adding dump_stack > > based on the call traces, > > 1.046240 backlight off (init, lvds disable) > 1.376800 backlight off (this call I don't understand) > 1.711346 backlight full blast (lvds enable) > 1.802276 backlight full blast (appears to be user mode setting as witnessed > by the call stack which matches future calls?) > 11.028084 backlight on at level 2, this I'm pretty sure is the user mode > setting of the backlight in by boot scripts. > Subsequent calls I think is Gnome/X11 slowly brightening the display during > boot. > > I could understand why during init, to shut everything down once and > re-enable once, the second calls to each I don't... > > Comparing back to the original dmesg, the 1.807509 setting should not have > happened. However the instrumentation caused the code to behave different > which is weird. That second call is from the fbdev initial configuration code. It first tries to disable everything, then build a config based on what outputs have been detected. The last one at 1.802 is ACPI requesting a change through a interrupt, which could be due to userspace asking for a change through the ACPI backlight interface, or could be spontaneous. Since it happens right at the end of driver init when we init the ACPI video interface, it could be part of the firmware's ACPI video init, and not from userspace. But according to that log, the backlight PWM value should be nonzero after the driver loads... but you saw a blank screen? As for adding a "set to max brightness" at the end somewhere, we'd probably want to do it around the time we set up the fbcon for the device. Ideally right when we set the mode for fbcon, so we don't get a dim fbcon that then goes to full brightness slightly after.
(In reply to comment #40) > > But according to that log, the backlight PWM value should be nonzero after > the driver loads... but you saw a blank screen? This specific log is about a situation where a dump stack makes the problem vanish. So, yes, in this case the screen is not blank. You might be interested in the traces of comment #3 and comment #18.
Correct, in the dmesg with the traces we cannot use for debugging this issue because the back light is turned on properly with the instrumentation, which implies we are likely dealing with a race condition with unknown contestants. Likely the firmware triggering an interrupt unexpectedly after the kernel does something. However it helped me understand what the correct sequence of events. The key is how we can figure out why this is occurring in the trace in comment #3: [ 3.038356] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882 [ 3.038370] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4882 [ 3.038570] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882 [ 3.038579] [drm:intel_panel_actually_set_backlight], set backlight PWM = 0 which is the same odd behavior as this trace in comment #18 [ 1.807427] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882 [ 1.807430] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4882 [ 1.807507] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882 [ 1.807509] [drm:intel_panel_actually_set_backlight], set backlight PWM = 0 For some reason, around 170-200 microseconds after it sets the final backlight, a spurious call is made and sets the backlight to 0. I just looked at freedesktop bug #40692 trace supplied which also has this telltale signature: [ 4.397699] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882 [ 4.397705] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4882 [ 4.397783] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882 [ 4.397785] [drm:intel_panel_actually_set_backlight], set backlight PWM = 0 (just wanted to cross link these two bugs as they smell very similar, but Dan's right, we can't dupe these together just yet.)
Created attachment 71276 [details] [review] drm/i915: set the BIOS current backlight level It's a long shot, but could you try the attached patch? It's on top of drm-intel-next-queued, but might apply on Linus' master too. It just might help with the BIOS <-> driver co-operation here.
Maybe-related: https://bugzilla.kernel.org/show_bug.cgi?id=47941
poke. Any chance to test Gustavo?
The kernel.org bug appears to be on a Dell, and he mentions that his brighten/darken ACPI keys do not work so it may not be the same problem... it would be interesting if this problem also afflicted machines that weren't HPs...
(In reply to comment #46) > The kernel.org bug appears to be on a Dell, and he mentions that his > brighten/darken ACPI keys do not work so it may not be the same problem... > it would be interesting if this problem also afflicted machines that weren't > HPs... Well, the patches did not help the problem there, maybe try them for your issue?
I just tried attachment 71276 [details] [review] patch against 3.7-release and the display still goes dark upon KMS init and remains dark until brightened by Fn-F3.
I also tried that kernel.org attach-patch 88981 coupled with the patch described in the previous comment on the same 3.7 kernel, and still greeted with darkness...
Same here, the proposed patch, tested with drm-intel-next-queued does not solves the problem.
Found the problem and a solution. Apparently it is a BIOS bug where it is claimed the display uses minimum backlight at boot. More info: https://bugzilla.kernel.org/show_bug.cgi?id=21212 and https://bugzilla.kernel.org/show_bug.cgi?id=51141 The solution is to put video.use_bios_initial_backlight=0 in the kernel command line. A more definitive fix is to add this laptop to a white list of machines needing this parameter. I've made a patch to fix it and have sent it to the ACPI list: http://www.spinics.net/lists/linux-acpi/msg42467.html
Awesome. Since it's an acpi bug and not something wrong with drm/i915 I'll close this report now.
Created attachment 89242 [details] Result of acpidump Attaching acpidump as requested in linux-acpi@vger.kernel.org. Hope you don't mind. :)
Gustavo, please try linux-next branch of [1]. There are fixes for initial backlight issues, headed for 3.13. [1] http://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
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.