https://bugs.freedesktop.org/show_bug.cgi?id=81382
Priority: medium Bug ID: 81382 Assignee: dri-devel@lists.freedesktop.org Summary: Text console blanking does not go away Severity: normal Classification: Unclassified OS: All Reporter: vda.linux@googlemail.com Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI
Created attachment 102847 --> https://bugs.freedesktop.org/attachment.cgi?id=102847&action=edit dmesg
I log in as root on a text virtual console. After about 10 minutes screen blanks.
Surprisingly, pressing a key does *not* unblank the screen!
Machine is still alive (I can ssh into it), and typed keys even reach the console: I can type e.g. "ls -lR /usr" and I see disk indicator blinking, ls process is visible in the ps in ssh session, etc.
This does not happen in X.
This is observed on Lenovo T60, on RHEL7 kernel and also on recent upstream kernel 3.15.5.
Investigation had revealed that VT unblanking code, after all the hard work it done to turn display back on, calls ATOM_LCD_BLOFF (backlight off, numeric value 2) function.
Digging further, I discovered that fb_blank(blank=0) almost at its end calls fb_notifier_call_chain(FB_EVENT_BLANK). Which calls backlight.c::fb_notifier_callback(), which tries to set brightness via radeon_atom_backlight_update_status(), which does atombios_set_backlight_level(radeon_atom_bl_level()), but radeon_atom_bl_level() is zero (it's an uint8_t, brightness level). So it's essentially atombios_set_backlight_level(0) and it switches backlight off.
In drivers/gpu/drm/radeon/*, bd->props.brightness, surprisingly, is only set in radeon_atom_backlight_init() and radeon_legacy_backlight_init(), all other locations are only reading it. So, if this init code sets it to 0, then VT unblanking code will use this zero value as brightness to restore, causing this bug.
And indeed, that's what happens on the machine exhibiting this bug:
[ 2.301563] radeon_atom_get_backlight_level_from_reg: RADEON_BIOS_2_SCRATCH [ 2.301633] radeon_atom_get_backlight_level_from_reg: bios_2_scratch:00000000 [ 2.301704] radeon_atom_backlight_init: bd->props.brightness=0 [ 2.301780] radeon_atom_backlight_update_status: atombios_set_back
The full dmesg of the RHEL7 boot with many debug printks added is attached. (Sorry, I started debugging it on RHEL7, I believe mainline does not differ significantly). It shows the following: After "setterm -blank 1 && sleep 60", VT blanking triggers at ~362 seconds, and at ~370 seconds VT is trying to unblank because of keyboard activity. The bug is evident here:
[ 370.852058] fb_blank: fb_notifier_call_chain(FB_EVENT_BLANK)... [ 370.852061] fbcon_event_notify: case FB_EVENT_BLANK: fbcon_fb_blanked(blank:0) [ 370.852063] fbcon_fb_blanked: do_unblank_screen(0) [ 370.852064] do_unblank_screen: entered on cpu 0 [ 370.852066] do_unblank_screen: !console_blanked on cpu 0 [ 370.852068] backlight: drivers/video/backlight/backlight.c:fb_notifier_callback: backlight_update_status() [ 370.852071] radeon_atom_backlight_update_status: atombios_set_backlight_level() [ 370.852072] radeon_atom_bl_level: level = bd->props.brightness:0 [ 370.852074] atombios_set_backlight_level(level:0) [ 370.852077] atombios_set_backlight_level: atom_execute_table(ATOM_LCD_BLOFF) ^^^^^^^^^^^^^^^^^^^^ THIS TURNS OFF DISPLAY ^^^^^^^^^^^^^^^^^ [ 370.852083] atom_execute_table_locked(index:23,*params:ffff8802) returns 0 [ 370.852085] backlight: drivers/video/backlight/backlight.c:fb_notifier_callback: backlight_update_status() [ 370.852940] fb_blank returns 0 [ 370.852942] fbcon_blank: update_screen()... [ 370.862313] do_unblank_screen: done on cpu 0
Note: PCI error seen during blanking is not causing this bug. It happens on first blanking (including Xserver screen blankings, which do not exhibit this bug), and never repeats. Google says it's a known issue on Radeon, comes from PCIe lanes reconfiguration.
I am unsure how to proceed from here. Maybe init code needs fixing to properly read backlight brightness on this hardware? I think radeon people are more qualified to take it from here. I'm willing to test patches.
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #1 from Denys Vlasenko vda.linux@googlemail.com --- Created attachment 102852 --> https://bugs.freedesktop.org/attachment.cgi?id=102852&action=edit Debugging messages patch
https://bugs.freedesktop.org/show_bug.cgi?id=81382
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |david.heidelberger@ixit.cz
--- Comment #2 from Alex Deucher agd5f@yahoo.com --- *** Bug 70207 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #3 from Alex Deucher agd5f@yahoo.com --- Created attachment 102856 --> https://bugs.freedesktop.org/attachment.cgi?id=102856&action=edit set the default backlight level to something reasonable
Does this patch help?
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #4 from Denys Vlasenko vda.linux@googlemail.com --- (In reply to comment #3)
Created attachment 102856 [details] [review] set the default backlight level to something reasonable
Does this patch help?
Yes, it does.
Maybe add a comment there why this check is necessary?
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #5 from Alex Deucher agd5f@yahoo.com --- Will do.
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #6 from David Heidelberger (okias) david.heidelberger@ixit.cz --- Work perfectly on Toshiba A210-15j!
Tested-by: David Heidelberger david.heidelberger@ixit.cz
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #7 from David Heidelberger (okias) david.heidelberger@ixit.cz --- Ok, this fix work, but cause another problem (tested with 3.15.5+patch and 3.16.1).
When display goes off, backlight goes off. When display goes on, backlight is set to MAX. When display goes off again, backligh remains MAX. After pressing key, LCD works, backlight stay at MAX level. When display goes off, backlight is still MAX.
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #8 from Daniel Kirsten daniel-kirsten-72@excite.com --- The above patch causes a problem on my Amilo Xi 2550 (RadeonHD 2600).
The behaviour for kernel-3.14.8-100.fc19 (without patch):
The value of /sys/class/backlight/radeon_bl0/brightness is 0. Whenever I write something (0-255) to /sys/class/backlight/radeon_bl0/brightness, the backlight is turned off, and I am not able to turn on the backlight again. However, I can still shutdown the system (Ctr+Alt+Fx, login as root, and give a shutdown command.
I can control the backlight by writing values 0-7 to /sys/class/backlight/acpi_video0/brightness.
The behaviour for kernel-3.14.17-100.fc19 (with patch):
The backlight is turned off during the boot up process, when the kernel switches into graphics mode. I commented out the lines 233-234 in drivers/gpu/drm/radeon/atombios_encoders.c, and then, the problem disappeared, i.e., the backlight stays on when the kernel switches into graphics mode.
Best regards, Daniel
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #9 from Denys Vlasenko vda.linux@googlemail.com --- (In reply to comment #7)
Ok, this fix work, but cause another problem (tested with 3.15.5+patch and 3.16.1).
When display goes off, backlight goes off. When display goes on, backlight is set to MAX. When display goes off again, backligh remains MAX. After pressing key, LCD works, backlight stay at MAX level. When display goes off, backlight is still MAX.
I would say it means that merely treating backlight value of 0 as MAX is not the best idea.
Maybe we need an additional bool variable "failed to read initial BL value, don't ever try to set it", set it if initial read of BL value is 0, and if it is set, never try to change BL level?
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #10 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #7)
Ok, this fix work, but cause another problem (tested with 3.15.5+patch and 3.16.1).
When display goes off, backlight goes off. When display goes on, backlight is set to MAX. When display goes off again, backligh remains MAX. After pressing key, LCD works, backlight stay at MAX level. When display goes off, backlight is still MAX.
Does the backlight respond correctly when adjusted via the sysfs blacklight interface?
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #11 from Patrick ps_mail@freenet.de --- I've got the same notebook as Daniel Kirsten, so I've searched for changes in the kernel code, which caused the dark screen. From that point, I've found the patch from Alex Deucher and this bug report.
If I change /sys/class/backlight/radeon_bl0/brightness or /sys/class/backlight/acpi_video0 the display stayes dark.
@Alex is this what you wanted to know? If not, please let me know, how I could help you to debug this problem!
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #12 from Daniel Kirsten daniel-kirsten-72@excite.com --- (In reply to comment #11)
I've got the same notebook as Daniel Kirsten,
They sold different Amilo Xi 2550, there are even some Amilo Xi 2550 with an Nvidia graphic card.
If I change /sys/class/backlight/radeon_bl0/brightness or /sys/class/backlight/acpi_video0 the display stayes dark.
I can control brightness by writing 0-7 into /sys/class/backlight/acpi_video0/brightness
You should comment out lines 233-234 in drivers/gpu/drm/radeon/atombios_encoders.c, i.e.,
/* if (bd->props.brightness == 0) 234 bd->props.brightness = RADEON_MAX_BL_LEVEL; */
then it works.
Daniel
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #13 from Patrick ps_mail@freenet.de --- (In reply to comment #12)
Hi Daniel,
correct, before that patch, the display was controllable through /sys/class/backlight/acpi_video0/brightness.
After that patch, the display is always dark.
The only change which was done by Alex, was adding the lines, which you commeted out. (If I understood the code correct, the other two lines, which were removed, are obsolete and not needed).
So if you removed that two lines, then you've got the same code as before and our Amilo (with ATI card) is working fine, but Denys problem will appear again...
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #14 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #11)
If I change /sys/class/backlight/radeon_bl0/brightness or /sys/class/backlight/acpi_video0 the display stayes dark.
@Alex is this what you wanted to know? If not, please let me know, how I could help you to debug this problem!
Without the patch from this bug report applied (e.g., when your display is working), which, if any, of the blacklight interfaces work? It seems like perhaps your laptop claims to have a GPU controlled backlight, but really uses an external backlight control. Can you attach a copy of your vbios? TO get a copy of your vbios:
(as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/<pci bus id> echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #15 from Patrick ps_mail@freenet.de --- Created attachment 106353 --> https://bugs.freedesktop.org/attachment.cgi?id=106353&action=edit lspci output for amilo
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #16 from Patrick ps_mail@freenet.de --- Created attachment 106354 --> https://bugs.freedesktop.org/attachment.cgi?id=106354&action=edit from Amilo
https://bugs.freedesktop.org/show_bug.cgi?id=81382
Patrick ps_mail@freenet.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #106354|from Amilo |vbios from Amilo description| |
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #17 from Patrick ps_mail@freenet.de --- (In reply to comment #14)
This could be true. I can control it via /sys/class/backlight/acpi_video0/brightness. If I change /sys/class/backlight/radeon_bl0/brightness then the display is nearly black and cannot be restored.
After reboot the following values are set: acpi_video0 = 7 radeon_bl0 = 0
I've attached a lspci -vvv to " lspci output for amilo" and the vbios to "vbios from Amilo"
https://bugs.freedesktop.org/show_bug.cgi?id=81382
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #106354|text/plain |application/octet-stream mime type| |
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #18 from Alex Deucher agd5f@yahoo.com --- Can you attach the lspci -vnn output for your GPU?
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #19 from Patrick ps_mail@freenet.de --- Created attachment 106410 --> https://bugs.freedesktop.org/attachment.cgi?id=106410&action=edit lspci -vnn for Amilo
sure, here it is
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #20 from Alex Deucher agd5f@yahoo.com --- Created attachment 106441 --> https://bugs.freedesktop.org/attachment.cgi?id=106441&action=edit patch 1/2
Do the attached patches help? The first patch adds a backlight module parameter to disable the gpu backlight device for testing. The second adds a quirk for the Amilo laptop.
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #21 from Alex Deucher agd5f@yahoo.com --- Created attachment 106442 --> https://bugs.freedesktop.org/attachment.cgi?id=106442&action=edit patch 2/2
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #22 from Patrick ps_mail@freenet.de --- Thanks for the patch, but I'm on vacation till 26th September, so long I cannot test it.
@Daniel As you've got the same problem, could you test the patches?
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #23 from Daniel Kirsten daniel-kirsten-72@excite.com --- I can test the patches from 2014-09-17 on my amilo.
Can I apply them to the current fedora kernel code 3.14.18-100?
Should I apply both patches or test each patch separately?
Daniel
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #24 from Alex Deucher agd5f@yahoo.com --- Apply them both together.
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #25 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #24)
Apply them both together.
Well, assuming your laptop has the same pci ids as Patrick. If not, just append radeon.backlight=0 to the kernel command line in grub and attach your lspci -vnn output.
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #26 from Daniel Kirsten daniel-kirsten-72@excite.com --- (In reply to comment #25)
The pci-id of the VGA Controller is 01:00.0 for my Amilo.
However, I cannot apply the patches to the 3.14.18-100.fc19 kernel:
patch --dry-run -p1 < ~/software/0001-drm-radeon-add-a-module-parameter-for-backlight-cont.patch checking file drivers/gpu/drm/radeon/radeon.h Hunk #1 FAILED at 106. 1 out of 1 hunk FAILED checking file drivers/gpu/drm/radeon/radeon_drv.c Hunk #1 FAILED at 181. Hunk #2 succeeded at 237 with fuzz 2 (offset -26 lines). 1 out of 2 hunks FAILED checking file drivers/gpu/drm/radeon/radeon_encoders.c Exit 1
patch --dry-run -p1 < ~/software/0002-drm-radeon-add-a-backlight-quirk-for-Amilo-Xi-2550.patch checking file drivers/gpu/drm/radeon/radeon_encoders.c Hunk #1 FAILED at 173. 1 out of 1 hunk FAILED Exit 1
Which kernel should I use to test the patches?
Daniel
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #27 from Alex Deucher agd5f@yahoo.com --- They are written against 3.17.
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #28 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #26)
(In reply to comment #25)
The pci-id of the VGA Controller is 01:00.0 for my Amilo.
That's the bus id. I need the output of lspci -vnn
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #29 from Daniel Kirsten daniel-kirsten-72@excite.com --- I tested the patches from 2014-09-17 against 3.17-rc5.
When I applied both patches, the backlight was not turned off, when the kernel switched into graphics mode. The kernel worked very well.
Without the patches, the backlight was turned off, when the kernel switched into graphics mode.
Daniel
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #30 from Daniel Kirsten daniel-kirsten-72@excite.com --- Created attachment 106554 --> https://bugs.freedesktop.org/attachment.cgi?id=106554&action=edit lspci -vnn for Daniel's amilo
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #31 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #30)
Created attachment 106554 [details] lspci -vnn for Daniel's amilo
You have the same configuration as Patrick.
(In reply to comment #29)
I tested the patches from 2014-09-17 against 3.17-rc5.
When I applied both patches, the backlight was not turned off, when the kernel switched into graphics mode. The kernel worked very well.
Great. I'll make sure the patches get upstream. Thanks for testing.
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #32 from Patrick ps_mail@freenet.de --- I've just tested the patches on my notebook, too. Also here, the problem is fixed, with the patches you provided.
Do you already know, in which upstream versions, the fix will be published? 3.17? Or in an 3.16.x already?
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #33 from Dieter Nützel Dieter@nuetzel-hh.de --- They are in Linus 3.17 tree:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0...
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #34 from Christophe Migliorini mig+freedesktop@chene.vingt-et-un-cinq.fr --- Hi, it took me quite some time to get here, but hopefully you can still solve my problem. I'm running a 2006 Intel iMac (Core Duo) under Unbuntu 12.04LTS server, which sits on my desk and almost never log to the console, which would normally go blank a few minutes after boot.
There is strong evidence that this patch found its way to my "stock" kernel back in september 2014, and since then my iMac exhibits the following behaviour after boot: - whenever the console blanking activates, backlight goes to MAX (with my LCD screen going all strange and overheating — even causing fans to blow) - only way out is to echo 0 > /sys/class/backlight/radeon_bl0/brightness — which I 'crontabbed' but is not exactly satisfactory. - any other value causes the backlight to go all the way up and overheat.
I did try to "echo 1 > /sys/class/backlight/acpi_video0/brightness" today, and that caused the iMac to reboot.
I have not experimented anything else, but would be happy to help.
uname is "Linux xxx 3.13.0-49-generic #81~precise1-Ubuntu SMP Wed Mar 25 16:32:40 UTC 2015 i686 i686 i386 GNU/Linux"
https://bugs.freedesktop.org/show_bug.cgi?id=81382
Christophe Migliorini mig+freedesktop@chene.vingt-et-un-cinq.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mig+freedesktop@chene.vingt | |-et-un-cinq.fr
--- Comment #35 from Christophe Migliorini mig+freedesktop@chene.vingt-et-un-cinq.fr --- Created attachment 115253 --> https://bugs.freedesktop.org/attachment.cgi?id=115253&action=edit lspci -vnn for Christophe's iMac
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #36 from Alex Deucher alexdeucher@gmail.com --- Should be fixed in this patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b7...
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #37 from Christophe Migliorini mig+freedesktop@chene.vingt-et-un-cinq.fr --- Apparently only "set the default backlight level to something reasonable" patch was applied to 3.13, so I don't have the "radeon_encoder_add_backlight" function, thus this won't work at all.
Would you suggest I first apply the patch published here on 2014-09-17?
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #38 from Christophe Migliorini mig+freedesktop@chene.vingt-et-un-cinq.fr --- Well, I did, '2014-09-17 15:38 UTC' and '2014-09-17 15:39 UTC' patches apply ok and it works. Sorry for the inconvenience. (perhaps one should consider pushing these two upstream instead of the fist one?)...
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #39 from Alex Deucher alexdeucher@gmail.com --- (In reply to Christophe Migliorini from comment #38)
Well, I did, '2014-09-17 15:38 UTC' and '2014-09-17 15:39 UTC' patches apply ok and it works. Sorry for the inconvenience. (perhaps one should consider pushing these two upstream instead of the fist one?)...
Those patches are upstream as well.
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #40 from Alex Deucher alexdeucher@gmail.com --- (In reply to Alex Deucher from comment #39)
(In reply to Christophe Migliorini from comment #38)
Well, I did, '2014-09-17 15:38 UTC' and '2014-09-17 15:39 UTC' patches apply ok and it works. Sorry for the inconvenience. (perhaps one should consider pushing these two upstream instead of the fist one?)...
Those patches are upstream as well.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bc... http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8a...
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #41 from Christophe Migliorini mig+freedesktop@chene.vingt-et-un-cinq.fr --- Good. Hopefully into 12.04LTS before it's no longer supported :-).
https://bugs.freedesktop.org/show_bug.cgi?id=81382
--- Comment #42 from David Heidelberg (okias) david@ixit.cz --- Maybe this bug can be closed?
https://bugs.freedesktop.org/show_bug.cgi?id=81382
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org