| 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 [details]
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.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
