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.