Bug 1143755 - intel[Skylake] Screen goes black during boot since kernel version 5.2.2-1.2
intel[Skylake] Screen goes black during boot since kernel version 5.2.2-1.2
Status: RESOLVED DUPLICATE of bug 1143139
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: KDE Workspace (Plasma)
Current
64bit Other
: P5 - None : Normal (vote)
: ---
Assigned To: E-Mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-08-01 06:47 UTC by Peter Luladjiev
Modified: 2019-08-05 08:21 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
hwinfo --gfx (1.00 KB, text/plain)
2019-08-01 06:48 UTC, Peter Luladjiev
Details
hwinfo --monitor (1.99 KB, text/plain)
2019-08-01 06:48 UTC, Peter Luladjiev
Details
Xorg log (68.66 KB, text/x-log)
2019-08-01 06:49 UTC, Peter Luladjiev
Details
dmesg (60.54 KB, text/plain)
2019-08-01 06:49 UTC, Peter Luladjiev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Luladjiev 2019-08-01 06:47:56 UTC
While tumbleweed is booting laptop screen turns black. 
Secondary monitor attached trough HDMI is working.
The time in which the screen will go black varies, sometimes it may go black during tumpleweed splash screen, and sometimes I can managed to login, open a browser and then will turn black.
Kernel 5.1.16-1.4 works fine. I tried with the latest version 5.2.3-1 but still the same issue.
If I disable the laptop screen from Displays dialog and enable it again the screen will turn on for few seconds and then go black.
Tried with xset -dpms but no effect. I don't have xf86-video-intel installed.
Laptop is Dell Latitude 7470 with Intel graphics 520.
Using Tumbleweed with KDE.
Comment 1 Peter Luladjiev 2019-08-01 06:48:33 UTC
Created attachment 812394 [details]
hwinfo --gfx
Comment 2 Peter Luladjiev 2019-08-01 06:48:59 UTC
Created attachment 812395 [details]
hwinfo --monitor
Comment 3 Peter Luladjiev 2019-08-01 06:49:19 UTC
Created attachment 812396 [details]
Xorg log
Comment 4 Peter Luladjiev 2019-08-01 06:49:31 UTC
Created attachment 812397 [details]
dmesg
Comment 5 Peter Luladjiev 2019-08-01 07:10:04 UTC
Additional information:
When I change the display brightness I see that the black is getting darker, so the screen is not actually turned off, something like a power saving mode? Also the problem remains even if I detach the secondary monitor and reboot. So without a secondary monitor the system is not usable.
Comment 6 Stefan Dirsch 2019-08-01 08:07:11 UTC
Thanks. You may try with

  i915.enable_dc=0 

on the boot kernel command line ...
Comment 7 Peter Luladjiev 2019-08-01 08:34:01 UTC
Like this?

λ peter [~] → cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.2.3-1-default root=/dev/mapper/system-root splash=silent resume=/dev/system/swap quiet i915.enable_dc=0

Still not working.
Comment 8 Stefan Dirsch 2019-08-01 08:54:08 UTC
Yes, thanks for giving it a try!
Comment 9 Takashi Iwai 2019-08-01 09:02:10 UTC
Does the backlight control itself work like before?

The backlight going darker at the boot time might be the systemd trying to restore the saved value.  See systemd-backlight man page.  It's saved in /var/lib/systemd/backlight/*.

And the backlight going darker during X session is done by the desktop itself.

I haven't noticed a problem on a similar machine (Latitude 7270) but with XFCE, so this might be depending on the desktop.
Comment 10 Peter Luladjiev 2019-08-01 09:29:51 UTC
"Does the backlight control itself work like before?" - Sorry I don't know what that means. 

However I've added systemd.restore_state=0 kernel parameter and now it works.

But do I need to leave it like this?
Comment 11 Takashi Iwai 2019-08-01 09:41:06 UTC
Well, systemd-backlight only tries to restore the backlight brightness to the previously saved value.  And it means that the previously saved value in /lib/var/systemd/backlight/* is wrong (or unexpected to you).

So try to remove /var/lib/systemd/backlight/* value once, and test rebooting normally.  Does it make things working?

About the backlight test: I thought you tested changing the backlight brightness by some way.  The question was just whether this worked normally like before with the new kernel.

For testing the raw backlight value, you can try to write via sysfs like:
  echo 200 > /sys/class/backlight/xxx/brightness
Comment 12 Peter Luladjiev 2019-08-01 09:45:41 UTC
(In reply to Peter Luladjiev from comment #10)
> "Does the backlight control itself work like before?" - Sorry I don't know
> what that means. 
> 
> However I've added systemd.restore_state=0 kernel parameter and now it works.
> 
> But do I need to leave it like this?

Okay never mind, went black again 20 minutes after a boot.
Comment 13 Stefan Dirsch 2019-08-01 09:45:51 UTC
Just, as an addition here. Your Laptop brightness may work as well once the desktop has been started ...
Comment 14 Takashi Iwai 2019-08-01 09:49:19 UTC
(In reply to Peter Luladjiev from comment #12)
> (In reply to Peter Luladjiev from comment #10)
> > "Does the backlight control itself work like before?" - Sorry I don't know
> > what that means. 
> > 
> > However I've added systemd.restore_state=0 kernel parameter and now it works.
> > 
> > But do I need to leave it like this?
> 
> Okay never mind, went black again 20 minutes after a boot.

It implies that the desktop environment lowers the brightness for power-saving.
I don't know what change in kernel makes the difference, though.

Check the values in /sys/class/backlight/* (both brightness and max_brightness) at the dark state on the 5.2.x kernel.  Then boot with 5.1.x, and check the values there again.  If the max_brightness differs, it might a cause of inconsistency, for example.
Comment 15 Peter Luladjiev 2019-08-01 10:56:16 UTC
(In reply to Takashi Iwai from comment #14)
> (In reply to Peter Luladjiev from comment #12)
> > (In reply to Peter Luladjiev from comment #10)
> > > "Does the backlight control itself work like before?" - Sorry I don't know
> > > what that means. 
> > > 
> > > However I've added systemd.restore_state=0 kernel parameter and now it works.
> > > 
> > > But do I need to leave it like this?
> > 
> > Okay never mind, went black again 20 minutes after a boot.
> 
> It implies that the desktop environment lowers the brightness for
> power-saving.
> I don't know what change in kernel makes the difference, though.
> 
> Check the values in /sys/class/backlight/* (both brightness and
> max_brightness) at the dark state on the 5.2.x kernel.  Then boot with
> 5.1.x, and check the values there again.  If the max_brightness differs, it
> might a cause of inconsistency, for example.

Both versions have the same brightness: 937

  λ peter [~] → cat /sys/class/backlight/intel_backlight/max_brightness
  937
  λ peter [~] → cat /sys/class/backlight/intel_backlight/brightness
  937

> So try to remove /var/lib/systemd/backlight/* value once, and test rebooting normally.  Does it make things working?

No luck with removing the files in /var/lib/systemd/backlight

> For testing the raw backlight value, you can try to write via sysfs like:
>   echo 200 > /sys/class/backlight/xxx/brightness

The only thing that happens is that the is getting darker.

> About the backlight test: I thought you tested changing the backlight brightness by some way.

Yes I changed the brightness level through Energy Saving menu and through laptop's function keys. The effect is the same like changing /sys/class/backlight/xxx/brightness value
Comment 16 Peter Luladjiev 2019-08-01 11:17:32 UTC
Update: 

I did

  xset s off
  xset s 0 0
  xset -dpms

And for now it's not going black. Will see if it stays that way.
Comment 17 Peter Luladjiev 2019-08-01 11:59:25 UTC
(In reply to Peter Luladjiev from comment #16)
> Update: 
> 
> I did
> 
>   xset s off
>   xset s 0 0
>   xset -dpms
> 
> And for now it's not going black. Will see if it stays that way.

I think this fixed the issue. 1 hour uptime and the screen remains turned on.
AFAIK these settings will be reset when I reboot, do I need to add them somewhere like .xinitrc or something?
Comment 18 Patrik Jakobsson 2019-08-01 12:36:16 UTC
Hi Peter,

Do you get the same problem when booting Tumbleweed KDE Live from a USB-stick? If not, we probably don't have a kernel regression.

Do you get any additional errors in dmesg when this problem occurs? (eg. link training issues).
Comment 19 Takashi Iwai 2019-08-01 12:41:23 UTC
And how is the exact problem?  With my freshly installed system (the very same machine), KDE turns off the screen shortly after dimming when no activity is seen, no matter which kernel.  I've tested both 5.1.x and 5.2.x.

And, if you reboot at this state, systemd will remember this exact dark state and tries to restore it at the next boot time via systemd-backlight service.  So going to this dark mode right after the boot is no bug per se, if it's the state at the previous shutdown.

The dimming and screen-off can be suppressed by adjusting the Energy Saving setup on KDE.
Comment 20 Peter Luladjiev 2019-08-01 12:59:25 UTC
(In reply to Patrik Jakobsson from comment #18)
> Hi Peter,
> 
> Do you get the same problem when booting Tumbleweed KDE Live from a
> USB-stick? If not, we probably don't have a kernel regression.
> 
> Do you get any additional errors in dmesg when this problem occurs? (eg.
> link training issues).

I'm writing from Tumbleweed KDE Live snapshot 20190730 and yes, the issue remains, laptop screen is blank. Only error in dmesg is

  [    6.997001] Couldn't get size: 0x800000000000000e
  [    6.997017] Couldn't get UEFI MokListRT

I suppose that's because I choose UEFI boot instead of Legacy when booting from USB
Comment 21 Peter Luladjiev 2019-08-01 13:04:45 UTC
(In reply to Takashi Iwai from comment #19)
> And how is the exact problem?  With my freshly installed system (the very
> same machine), KDE turns off the screen shortly after dimming when no
> activity is seen, no matter which kernel.  I've tested both 5.1.x and 5.2.x.
> 
> And, if you reboot at this state, systemd will remember this exact dark
> state and tries to restore it at the next boot time via systemd-backlight
> service.  So going to this dark mode right after the boot is no bug per se,
> if it's the state at the previous shutdown.
> 
> The dimming and screen-off can be suppressed by adjusting the Energy Saving
> setup on KDE.

As I said in the previous comment that happens on LIVE USB as well, even if there is activity. However the screen went off on Tumbleweed splash screen, I didn't even have time to see the login screen nor do any activity.

If you are correct and it uses the previous state wouldn't a kernel parameter systemd.restore_state=0 fix the problem, because I did tried it previously. Or I'm mistaken at what that parameter does.

I tried to disable dimming and screen off through Energy Saving but nothing changed.
Comment 22 Takashi Iwai 2019-08-01 13:08:37 UTC
And is it same without external monitor and docking station?
I've tested only with the laptop screen.
Comment 23 Peter Luladjiev 2019-08-01 13:13:15 UTC
(In reply to Takashi Iwai from comment #22)
> And is it same without external monitor and docking station?
> I've tested only with the laptop screen.

Yes no matter if I have attached monitor. I don't have docking station.

What else I noticed is that after the reboot the xset commands does not help keeping the screen on.
Comment 24 Peter Luladjiev 2019-08-01 13:17:18 UTC
Update:
I think xset s 0 0 helped me to keep the screen on.
Comment 25 Takashi Iwai 2019-08-01 13:21:00 UTC
Hrm, then I cannot reproduce the problem at all here.  The screen keeps on if I disable "Dim screen" and "Screen Energy Saving" on the power setup window.
(Oh there is also "Lock Screen" setup, too.)

It must be something weird in the user space side.  Reassigned to KDE people.
Comment 26 Peter Luladjiev 2019-08-01 13:27:23 UTC
(In reply to Takashi Iwai from comment #25)
> Hrm, then I cannot reproduce the problem at all here.  The screen keeps on
> if I disable "Dim screen" and "Screen Energy Saving" on the power setup
> window.
> (Oh there is also "Lock Screen" setup, too.)
> 
> It must be something weird in the user space side.  Reassigned to KDE people.

Thanks anyway.

Update: xset s 0 0 didn't helped. Screen went off after 10 minutes while I was working on it.
Comment 27 Patrik Jakobsson 2019-08-02 07:52:51 UTC
Just a couple of thoughts. Takashi, since you tested on the same model (7470) without any problems and Peter tested with KDE Live but still experienced the issue; wouldn't this suggest a hardware/firmware issue? Also, the fact that backlight is still on (and can be adjusted) when this problem occurs makes me think that it's not as simple as the screen going into power saving mode.
Comment 28 Takashi Iwai 2019-08-02 14:41:28 UTC
We've got another bug report regarding i915 driver on 5.2, and a regression wrt PSR was confirmed (bug 1143139).

Could you check whether passing i915.enable_psr=0 boot option fixes your problem?
Comment 29 Peter Luladjiev 2019-08-05 06:50:06 UTC
(In reply to Takashi Iwai from comment #28)
> We've got another bug report regarding i915 driver on 5.2, and a regression
> wrt PSR was confirmed (bug 1143139).
> 
> Could you check whether passing i915.enable_psr=0 boot option fixes your
> problem?

λ peter [~] → cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.2.3-1-default root=/dev/mapper/system-root splash=silent resume=/dev/system/swap quiet i915.enable_psr=0

No issues so far.
Comment 30 Takashi Iwai 2019-08-05 08:21:40 UTC
OK, then this is a regression by PSR2 enablement in i915 driver.
Should be addressed in the later 5.2.x stable update.

*** This bug has been marked as a duplicate of bug 1143139 ***