On my HP Envy 17, with ATI Radeon HD 5850, using kernels >= 2.6.34, every boot time the screen brightness goes to 0 when the acpi is enabled. The only way to fix it is setting acpi=off. After many tests, this bug seems to me not dependent of any kind of graphics modules activated on the kernel, in fact it appears always. This bug affects also all distribution kernels, like Ubuntu, Fedora, Gentoo, etc..
(In reply to comment #0) > On my HP Envy 17, with ATI Radeon HD 5850, using kernels >= 2.6.34, every > boot > time the screen brightness goes to 0 when the acpi is enabled. > so the system is still working well at this time, right? can you change the backlight via hotkeys? please remote login, and 1. attach the acpidump of this laptop. 2. attach the output of "grep . /sys/class/backlight/*/*"
Thanks for reply! Yes, the system is still working well. The backlight hotkeys work, on Gentoo they increment correctly, using this clear .config file: http://pappy-mcfae.pastebin.com/F9enuzP1 However on Ubuntu it goes always to 0 before increment. Another important point is that if I'm using KDE or Gnome Desktop the power manager can change the brightness using the power profiles. In attached you have acpidump and grep, note that my video is video0, and I'm under kde with performance profile (100% brightness).
Created attachment 35442 [details] acpidump
Created attachment 35452 [details] grep . /sys/class/backlight/*/*
(In reply to comment #4) please attach the output of "grep . /sys/class/backlight/*/device/*" as well.
Created attachment 35722 [details] grep . /sys/class/backlight/*/device/*
(In reply to comment #0) > On my HP Envy 17, with ATI Radeon HD 5850, using kernels >= 2.6.34, every > boot > time the screen brightness goes to 0 when the acpi is enabled. > so this is a 2.6.34 regression, right? does the problem exist in 2.6.33? IMO, this is a BIOS problem which set initial _BQC value to minimum. But as you said, this is a regression, so I need to find out which commit exposes this problem.
(In reply to comment #7) > so this is a 2.6.34 regression, right? > does the problem exist in 2.6.33? Not really, sorry. I bought my Envy in August, so I only tested it with ubuntu 2.6.32, gentoo 2.6.34-r6, 2.6.34-r11, 2.6.34-r12, 2.6.35-r1. For all these kernels I'm observing this issue. So I don't think that it's a regression. Here you have a "blog" where someone shows this issue, called in this case black console, for another envy model, HP envy 14, with similar ATI drive: http://www.andreas-demmer.de/2010/07/18/testbericht-linux-auf-dem-hp-envy-14 Please let me know if you need more information.
Another precision: All attachments are from Ubuntu 10.10 with kernel 2.6.35-22-generic, using HP Bios F13. I'm posting the dmesg, there is nothing strange (like _BQC wanings). I don't know if it's usefull for you or maybe it's correlated: at 60s I get "bios memory corruption in low memory". I can remove this warning setting CONFIG_X86_RESERVE_LOW_64K=n. So probably it's only a bios bug. > [ 62.516112] WARNING: at > /build/buildd/linux-2.6.35/arch/x86/kernel/check.c:134 > check_for_bios_corruption+0xe5/0xf0() > [ 62.516118] Hardware name: HP ENVY 17 Notebook PC > [ 62.516122] Memory corruption detected in low memory
Created attachment 35902 [details] dmesg with ubuntu kernel 2.6.35-22-generic
Created attachment 35972 [details] patch: do not trust BIOS initial backlight please apply this patch, set CONFIG_ACPI_VIDEO=y. rebuild the kernel and boot with video.use_bios_initial_backlight=0. please attach the output of "grep . /sys/module/video/parameters/*" if the problem still exists.
Thank you very much for your patch, I'll try it this weekend. Looking to your code it seems a good workaround. I would like to ask your opinion about the origin of this bug. If you think that it's a BIOS bug I will report it to hp. Are you sure that it's not a kernel new BIOS models incompatibility? (i.e. new BIOS commands/function/controls...) Thank you again, and in the next days I'll let you know if it solves the issue.
Created attachment 36072 [details] custom DSDT If the patch works, we only know that BIOS exports minimum backlight values to OS. To find the root cause why BIOS behaves in this way, please: 1. build a 2.6.36 kernel with this custom DSDT. 2. reboot with boot option "acpi.aml_debug_output=1" 3. you should get a dimming screen after system boot now, and save the dmesg 4. attach the dmesg output
BTW: to apply a custom DSDT, you need to follow step 5,6 and 7 at http://www.lesswatts.org/projects/acpi/overridingDSDT.php
(In reply to comment #11) > patch: do not trust BIOS initial backlight I just finished the test with gentoo kernel 2.6.34-r12, your patch works perfectly, the backlight is now preserved. Thanks very much!
Created attachment 36302 [details] dmesg from custom DSDT on gentoo kernel 2.6.36 Here you have the dmesg from gentoo kernel 2.6.36 using the custom DSDT table. With this kernel I have two strange points to highlight: 1. with this kernel, considered unstable by gentoo, the backlight does not change during the boot. (I don't need to apply your patch) 2. the backlight buttons do not work anymore with this kernel!!! Well, for me both points are correlated, I'm not sure about the actual quality of this gentoo kernel, maybe you can suggest me another one.
please attach the output of "lspci -vvxxx".
Created attachment 36622 [details] custom DSDT please try this DSDT instead.
Created attachment 36712 [details] lscpi -vvxxx
Created attachment 36722 [details] dmesg from custom DSDT on gentoo kernel 2.6.36 Here you have the new output. Now backlight buttons work, and the blacklight issue returned.
I don't know if here is the good place, maybe is correlated to the bios, but the suspend to raw doesn't work on this machine.
Patch in comment #11 has been shipped in acpi test tree. (In reply to comment #21) > I don't know if here is the good place, maybe is correlated to the bios, but > the suspend to raw doesn't work on this machine. I guess you mean suspend to ram, right? please file a new bug report about this issue.
Thanks for reply. Could you please confirm me if this issue is from my BIOs model or from kernel linux ACPI? Thanks.
shipped in 2.6.38-rc1: commit 99fd1895ef603f1a0fa9af478c96c637a7b4529d Author: Zhang Rui <rui.zhang@intel.com> Date: Mon Dec 6 15:04:27 2010 +0800 ACPI video: introduce module parameter video.use_bios_initial_backlight Introduce module parameter video.use_bios_initial_backlight. Some BIOSes claim they use the minimum backlight at boot, and this may bring dimming screen after boot. https://bugzilla.kernel.org/show_bug.cgi?id=21212 use video.use_bios_initl_backlight=0 to use the maximum backlight level after boot. Signed-off-by: Zhang Rui <rui.zhang@intel.com>