Bug 989763 - After upgraing kernel to 3.10.3-300 brightness in X is set to 0
After upgraing kernel to 3.10.3-300 brightness in X is set to 0
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
i686 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-29 16:55 EDT by Artur Szymczak
Modified: 2013-09-22 16:40 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-18 16:58:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg (72.19 KB, text/plain)
2013-07-29 16:57 EDT, Artur Szymczak
no flags Details
dmidecode (9.67 KB, text/plain)
2013-07-29 16:58 EDT, Artur Szymczak
no flags Details
lspci (32.29 KB, text/plain)
2013-07-29 16:58 EDT, Artur Szymczak
no flags Details
Xorg.log (32.81 KB, text/plain)
2013-07-30 05:53 EDT, Artur Szymczak
no flags Details

  None (edit)
Description Artur Szymczak 2013-07-29 16:55:09 EDT
Description of problem:
After upgrading to 3.10.3-300.fc19 brightness in X session is reduced to 0. Text session has correct brightness. Switching back to older kernel 3.9.5-301 (this was fresh install + updates) all works fine.
I can change brightness using /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight/brightness but after reboot it backs to 0.

Version-Release number of selected component (if applicable):
# rpm -q kernel
kernel-3.9.5-301.fc19.i686
kernel-3.10.3-300.fc19.i686

How reproducible:


Steps to Reproduce:
1. update system to latest
2. reboot, and select 3.10.3-300 kernel
3. boot in to X session, or start it manually

Actual results:
brightness is set to 0 in /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight/brightness

Expected results:
Brightnesss should be different from 0 (it should inherit values from text mode).

Additional info:
I have 3 laptops with F19, and only this one has the problem: ASUS K55VJ. Problem doesn't exist on ASUS EeePc 1215N and ASUS UX21e.
So it is hardware specific problem.
Comment 1 Artur Szymczak 2013-07-29 16:57:44 EDT
Created attachment 780138 [details]
dmesg

Three last line occurs when I run lspci (three times).
Comment 2 Artur Szymczak 2013-07-29 16:58:08 EDT
Created attachment 780139 [details]
dmidecode
Comment 3 Artur Szymczak 2013-07-29 16:58:32 EDT
Created attachment 780140 [details]
lspci
Comment 4 Artur Szymczak 2013-07-30 05:53:24 EDT
Created attachment 780481 [details]
Xorg.log
Comment 5 Satish Balay 2013-07-30 12:09:19 EDT
I noticed brightness going to zero with kernel-3.10.2-301.fc19.x86_64 and also kernel-3.11.0-0.rc2.git3.2.fc20.x86_64 on a Thinkpad T420s. [with intel sandy-bridge gpu]

But I could recover from with with the brightness-increase function on the keyboard.

Now I'm with kernel-3.11.0-0.rc3.git0.1.fc20.x86_64 - and I haven't noticed this issue [so perhaps the fix is somewhere in the 3.11 rc tree..]
Comment 6 Dimitris 2013-07-30 15:52:25 EDT
I see this, but only when I hibernate the system, on an older Thinkpad X200s (Montevina, Intel graphics only).

- Laptop booted up normally with brightness to maximum.
- Laptop stays plugged in to AC throughout this sequence.
- Laptop is on docking station, through which it's connected to a second display through HDMI2 (per xrandr -q).
- I start hibernation (whether with Fn-F12 or "systemctl hibernate", same behavior).
- After the state is saved to disk and right before the machine powers off, the laptop panel is set to minimum brightness.
- Laptop panel still in minimum brightness when I power up the machine again; I have to manually increase brightness to be able to read the grub menu.

I have not been able to reproduce this with sleep; only hibernation seems to trigger it on this system.

This started with kernel 3.10.3-300.fc19.  I'll try to install the latest rawhide kernel and see what that does.
Comment 7 Dimitris 2013-07-30 16:38:39 EDT
Well, 3.11.0-0.rc3.git0.1.fc20 did not fix this for me...
Comment 8 Dimitris 2013-07-31 15:14:45 EDT
(In reply to Dimitris from comment #7)
> Well, 3.11.0-0.rc3.git0.1.fc20 did not fix this for me...

And for what it's worth neither did 3.10.4-300.fc19.x86_64
Comment 9 Garrett Mitchener 2013-08-02 22:50:05 EDT
Just to confirm, I'm seeing the same thing: just installed Fedora 19 on an Asus UX31A, yum update installed a new kernel, and I get the blank screen.
Comment 10 Roman Makurin 2013-08-04 15:31:36 EDT
I can confirm problem on Asus G46VW. All testing updates r installed. 
kernel-3.10.3-300.fc19.x86_64 & kernel-3.10.4-300.fc19.x86_64 are affected
Comment 11 Dimitris 2013-08-05 20:41:45 EDT
Per comment 6, my symptoms were different but after going through https://bugzilla.kernel.org/show_bug.cgi?id=51231 and https://bugzilla.kernel.org/show_bug.cgi?id=60682 I finally got my thinkpad to behave more or less correctly, so this might help others:

I can get the laptop panel brightness to behave, including across suspends and hibernations, by the following three additions to the kernel command line:

acpi_osi=Linux

I prefer this over acpi_osi="!Windows 2012" as the latter breaks (this older thinkpad's) mute key.

acpi_backlight=vendor
thinkpad_acpi.brightness_enable=0

With Intel graphics at least, this allows me to control brightness from both X and consoles, and when in X have OSD feedback.  The "grading" of the OSD bar and brightness levels themselves isn't "linear", i.e. each step down seems to subtract a certain percentage of remaining brightness, instead of a fixed "slice".  Also, the lowest brightness level turns the screen off, unlike the ACPI video driver.

Hope this helps.
Comment 12 Garrett Mitchener 2013-08-05 22:36:59 EDT
I tried acpi_osi=Linux acpi_backlight=vendor with my Asus Zenbook UX31A, and the screen was still stuck blank and black once booting was complete.  I also got error messages in dmesg about not being able to parse something:

Aug  5 22:26:11 falkor kernel: [    5.166248] ACPI Error: [IIA0] Namespace lookup failure, AE_ALREADY_EXISTS (20130328/dsfield-211)
Aug  5 22:26:11 falkor kernel: [    5.166255] ACPI Error: Method parse/execution failed [\_SB_.ATKD.WMNB] (Node ffff880118ea1fc8), AE_ALREADY_EXIS
TS (20130328/psparse-537)
Aug  5 22:26:11 falkor kernel: [    5.166343] ACPI Error: [IIA0] Namespace lookup failure, AE_ALREADY_EXISTS (20130328/dsfield-211)
Aug  5 22:26:11 falkor kernel: [    5.166346] ACPI Error: Method parse/execution failed [\_SB_.ATKD.WMNB] (Node ffff880118ea1fc8), AE_ALREADY_EXIS
TS (20130328/psparse-537)
Aug  5 22:26:11 falkor kernel: [    5.166397] ACPI: Marking method WMNB as Serialized because of AE_ALREADY_EXISTS error
Aug  5 22:26:11 falkor kernel: [    5.196638] asus-nb-wmi: probe of asus-nb-wmi failed with error -5
Aug  5 22:26:11 falkor kernel: [    5.267636] type=1305 audit(1375755971.086:4): audit_pid=487 old=0 auid=4294967295 ses=4294967295
Aug  5 22:26:11 falkor kernel: [    5.267636]  subj=system_u:system_r:auditd_t:s0 res=1


Also, the line about probe of asus-nb-wmi looks suspicious.  I see that with kernel-3.10.4 but not 3.9.5  (I think -- it's a lot of logs to go through)
Comment 13 Lars S. Jensen 2013-08-06 07:15:00 EDT
(In reply to Garrett Mitchener from comment #12)

I have the same error on an Asus Zenbook UX32VD but it works with 3.9: 
with 3.9.9-302 that works and on 3.10.4-300 that don't.

I see the problem as 2 issues:
1) Black screen 
The Black screen start after 1-3s into the kernel boot and it stays black. This also happens without "quiet".
This is the main problem. 
Can it be VT/DRM switch related?

2) Backlight off for some seconds.
The backlight goes off for 1-2s  and it look like it happens also when X/DM starts. And then it switch off after some time and i can' get it on again.
If I login to X on the black screen the backlight level goes back to the 30% level that I have configure in X(fce) and I can adjust the level with the keyboard Fn + F6/F5. it looks like the backlight works in X with xbacklight -set XX. The screen is black the hole time but the backlight is visible the edge of the screen.

This was with:  pcie_aspm=force drm.vblankoffdelay=1 i915.semaphores=1 acpi_osi='!Windows 2012'

I have blacklist nouveau because of switchable “Optimus” technology.
Have try with/out:pcie_aspm=force drm.vblankoffdelay=1 i915.semaphores=1 acpi_osi='!Windows\x202012'
Comment 14 Hal Finkel 2013-08-16 00:50:31 EDT
I also was affected by this problem, but just upgraded to kernel-3.11.0-0.rc5.git2.1.fc20.x86_64 from rawhide and, so far, it looks as though the problem has been resolved.
Comment 15 Hal Finkel 2013-08-16 11:48:03 EDT
(In reply to Hal Finkel from comment #14)
> I also was affected by this problem, but just upgraded to
> kernel-3.11.0-0.rc5.git2.1.fc20.x86_64 from rawhide and, so far, it looks as
> though the problem has been resolved.

Unfortunately, while the screen issue still seems solved, I should warn you that it seems that with this prerelease suspend support seems broken (after the machine wakes up from suspend, the wireless card no longer works, the kernel log is full of messages: alx 0000:03:00.0: invalid PHY speed/duplex: 0xffff -- and unloading the ath9k driver then crashes the kernel).
Comment 16 Lars S. Jensen 2013-08-17 06:48:53 EDT
I found the kernel bug that are related to display goes blank:
Issue: bw/lanes/clocks required for bpp=24 and then clamps it down to 18
https://bugzilla.kernel.org/show_bug.cgi?id=59841

UEFI: Boot > Launch CSM don't work in secure boot mode on my Asus Zenbook UX32VD:-(.

Workaround: Disable secure boot and enable Launch CSM
Disable: Boot > Secure Boot and enable: Boot > Launch CSM.
And it works: boot 3.10.7-200 with drm.debug=0xe:

[    1.618948] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3]
[    1.618962] [drm:intel_modeset_pipe_config], [CRTC:3]
[    1.618963] [drm:intel_modeset_pipe_config], plane bpp: 24, pipe bpp: 24, dithering: 0

I boot 3.10.7-200 with drm.debug=0xe and CSM disabled then the timing match when display goes blank:

[    1.633515] [drm:intel_modeset_stage_output_state], [CONNECTOR:12:eDP-1] to [CRTC:3]
[    1.633516] [drm:intel_modeset_stage_output_state], crtc changed, full mode switch
[    1.633517] [drm:intel_crtc_set_config], attempting to set mode from userspace
[    1.633519] [drm:drm_mode_debug_printmodeline], Modeline 13:"1920x1080" 60 138780 1920 1966 1996 2080 1080 1082 1086 1112 0x48 0xa
[    1.633522] [drm:intel_dp_compute_config], DP link computation with max lane count 2 max bw 0a pixel clock 138780KHz
[    1.633523] [drm:intel_dp_compute_config], DP link bw 06 lane count 2 clock 162000 bpp 18
[    1.633525] [drm:intel_dp_compute_config], DP link bw required 249804 available 259200
[    1.633526] [drm:intel_modeset_pipe_config], [CRTC:3]
[    1.633527] [drm:intel_modeset_pipe_config], plane bpp: 24, pipe bpp: 18, dithering: 1
Comment 17 Lars S. Jensen 2013-08-17 07:42:17 EDT
(In reply to Lars S. Jensen from comment #16)
> Disable: Boot > Secure Boot and enable: Boot > Launch CSM.
> And it works: boot 3.10.7-200 with drm.debug=0xe:

This is now OK but I still have the backlight issue 2 from comment #13 with the login manager after the backlight has been turned off: 
if I wait with the login the the lightdm switch the backlight off after some time and I can't get backlight on again in lightdm.
When I login to Xcfe the problem is gone but I may need to login on a black screen if the lightdm have turn off the backlight!
Comment 18 Garrett Mitchener 2013-09-15 17:49:39 EDT
Problem is still present in kernel 3.10.11-200...

I see the fedora logo during graphical boot, then the screen goes black.  I can then ssh into my notebook (* enable sshd, plug in an ethernet cable first), run systemctl gdm restart, and then the login screen comes up visible.
Comment 19 Josh Boyer 2013-09-18 16:45:41 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 20 Artur Szymczak 2013-09-18 16:58:03 EDT
Now I checked on 64bit (orginally was on 32bit) and it works for me.
Thank you.
Comment 21 Josh Boyer 2013-09-18 16:58:45 EDT
Thank you for letting us know.
Comment 22 Emmanuel Kowalski 2013-09-19 08:06:50 EDT
On my Zenbook 21, the latest update still has the same problem as in Comment #18.  Only kernel-3.9.* work...
Comment 23 Lars S. Jensen 2013-09-20 11:11:18 EDT
The bug for Asus Zenbook UX32VD is:

https://bugzilla.redhat.com/show_bug.cgi?id=998096

I am updated the bug with the information from  Comment #16.
Comment 24 Garrett Mitchener 2013-09-22 16:40:27 EDT
Cautiously optimistic here... I upgraded my Asus Zenbook UX31A to kernel 3.11.1-200, and I haven't seen the black screen problem.

FYI: I've disabled secure boot, but it's booting through EFI otherwise.

Note You need to log in before you can comment on or make changes to this bug.