[Bug 81382] New: Text console blanking does not go away

* [Bug 81382] New: Text console blanking does not go away
@ 2014-07-15 11:25 bugzilla-daemon
  2014-07-15 12:29 ` [Bug 81382] " bugzilla-daemon
                   ` (44 more replies)
  0 siblings, 45 replies; 46+ messages in thread
From: bugzilla-daemon @ 2014-07-15 11:25 UTC (permalink / raw)
  To: dri-devel

[-- Attachment #1.1: Type: text/plain, Size: 4375 bytes --]

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 5809 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply	[flat|nested] 46+ messages in thread