Bug 1661417 - After update, no screen display on ASUS GL702ZC
Summary: After update, no screen display on ASUS GL702ZC
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 29
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-21 07:55 UTC by Turgut Kalfaoglu
Modified: 2019-01-31 16:44 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-29 22:07:39 UTC


Attachments (Terms of Use)
journalctl -1 output (4.18 KB, text/plain)
2018-12-21 07:55 UTC, Turgut Kalfaoglu
no flags Details
lshw output (33.44 KB, text/plain)
2018-12-21 07:55 UTC, Turgut Kalfaoglu
no flags Details
journalctl -k -b -1 output (133.28 KB, text/plain)
2018-12-28 08:47 UTC, Turgut Kalfaoglu
no flags Details
journalctl -b --no-hostname output (377.41 KB, text/plain)
2019-01-09 09:24 UTC, Turgut Kalfaoglu
no flags Details
dmesg output (92.77 KB, text/plain)
2019-01-09 14:23 UTC, Turgut Kalfaoglu
no flags Details

Description Turgut Kalfaoglu 2018-12-21 07:55:06 UTC
Created attachment 1516060 [details]
journalctl -1 output

Description of problem:

After yesterday's dnf update, the laptop's display no longer shows anything.
After selecting 4.19.9-300.fc29.x86_64 from the boot manager, nothing is displayed again. Booting the previous kernel 4.19.8-300.fc29.x86_64, works as it should.

Version-Release number of selected component (if applicable):
4.19.9-300.fc29.x86_64

How reproducible:
Every boot

Steps to Reproduce:
1. Turn on laptop,
2. Wait for it to boot the latest kernel
3. Screen turns dark, stays dark

Actual results:
Peaceful screen.

Expected results:
A screen that displays a login prompt - at least.

Additional info:

Comment 1 Turgut Kalfaoglu 2018-12-21 07:55:42 UTC
Created attachment 1516061 [details]
lshw output

Comment 2 Steve 2018-12-21 13:28:00 UTC
The attached lshw report shows:

configuration: driver=amdgpu latency=0

So you may be seeing:

Bug 1659810 - linux-firmware: amdgpu fatal error during gpu init

The fix is to update linux-firmware and then update the kernel:

bugfix update in Fedora 29 for linux-firmware 
https://bodhi.fedoraproject.org/updates/FEDORA-2018-ba224c644f

# dnf update https://kojipkgs.fedoraproject.org//packages/linux-firmware/20181219/89.git0f22c852.fc29/noarch/linux-firmware-20181219-89.git0f22c852.fc29.noarch.rpm

# dnf update kernel --enablerepo=updates-testing

Comment 3 Steve 2018-12-21 14:20:35 UTC
(In reply to Steve from comment #2)

> ... and then update the kernel: ...

Or rebuild the initramfs:

# dracut --kver 4.19.9-300.fc29.x86_64 --force

Comment 4 Turgut Kalfaoglu 2018-12-28 06:24:11 UTC
Thank you -- before I could do the changes you suggested, several updates arrived and I am now at:
 4.19.10-300.fc29.x86_64 

Now the issue is slightly different:  When I turn on the laptop, after GRUB, there is no display.
I have to tap the power button to put the machine to sleep and re-tap it to get back the login screen.

So,
1. Turn it on, 
2. wait or select the latest kernel from grub menu
3. nothing on display
4. tap power button
5. machine suspends itself
6. tap power button
7. login screen appears, 
8. and all works normally from there on.

Comment 5 Steve 2018-12-28 07:45:24 UTC
(In reply to Turgut Kalfaoglu from comment #4)
> Thank you -- before I could do the changes you suggested, several updates
> arrived and I am now at:
>  4.19.10-300.fc29.x86_64 
> 
> Now the issue is slightly different:  When I turn on the laptop, after GRUB,
> there is no display.
> I have to tap the power button to put the machine to sleep and re-tap it to
> get back the login screen.
> 
> So,
> 1. Turn it on, 
> 2. wait or select the latest kernel from grub menu
> 3. nothing on display
> 4. tap power button
> 5. machine suspends itself
> 6. tap power button
> 7. login screen appears, 
> 8. and all works normally from there on.

See if you can get some boot messages by either:

1. Tapping the ESC key after selecting the kernel in grub and initiating a boot. (You may need to tap ESC several times.)

or by

2. Removing "rhgb quiet" from the kernel command-line from grub (press "e", scroll to the "linux" line, remove "rhgb quiet" -- use the arrow and backspace keys).

You can check whether you are seeing Bug 1659810 by running:

$ journalctl -b -g 'firmware'

NB: The log file you attached is missing a lot of information, including the kernel command-line.

That could happen if you were not an administrative user when you ran "journalctl". Check that you are in group "wheel":

$ groups
joeuser wheel

Comment 6 Turgut Kalfaoglu 2018-12-28 08:45:57 UTC
Thank you for your response.

$ journalctl -b -g 'firmware'

-- Logs begin at Tue 2018-12-11 12:41:03 +03, end at Fri 2018-12-28 11:40:41 +03. --
Dec 28 14:38:11 tklaptop.kalfaoglu.net kernel: ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
Dec 28 14:38:11 tklaptop.kalfaoglu.net kernel: acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-3f] only partially covers this bridge
Dec 28 14:38:11 tklaptop.kalfaoglu.net kernel: [drm] Found UVD firmware Version: 1.130 Family ID: 16
Dec 28 14:38:11 tklaptop.kalfaoglu.net kernel: [drm] Found VCE firmware Version: 53.26 Binary ID: 3
Dec 28 11:38:13 tklaptop.kalfaoglu.net kernel: r8822be: Using firmware rtlwifi/rtl8822befw.bin
Dec 28 11:38:22 tklaptop.kalfaoglu.net NetworkManager[1219]: <info>  [1545986302.7589] manager[0x55fcc55a80c0]: monitoring kernel firmware directory '/lib/firmware'.
Dec 28 11:38:39 tklaptop.kalfaoglu.net systemd[1]: Startup finished in 8.946s (firmware) + 3.599s (loader) + 3.563s (kernel) + 1.423s (initrd) + 26.532s (userspace) = 44.065>
Dec 28 11:39:44 tklaptop.kalfaoglu.net systemd[1]: Starting Firmware update daemon...
Dec 28 11:39:44 tklaptop.kalfaoglu.net systemd[1]: Started Firmware update daemon.

$ groups
turgut wheel dialout lock vboxusers

My current kernel line simply has:
GRUB_CMDLINE_LINUX="pti=off"
I removed the "rhgb quiet" and did see a boot log that flashed before it plunged into darkness.

I'll attach a new journalctl -k -b -1  obtained as root.

Comment 7 Turgut Kalfaoglu 2018-12-28 08:47:04 UTC
Created attachment 1517184 [details]
journalctl -k -b -1 output

journalctl -k -b -1 output

Comment 8 Steve 2018-12-28 08:53:18 UTC
For the record, the attached lshw output shows that you have an AMD Ellesmere GPU. Based on Googling, that is the codename for Polaris 10:

           *-display
                description: VGA compatible controller
                product: Ellesmere [Radeon RX 470/480/570/570X/580/580X/590]
                vendor: Advanced Micro Devices, Inc. [AMD/ATI]

Comment 9 Steve 2018-12-28 09:02:18 UTC
(In reply to Steve from comment #8)
> For the record, the attached lshw output shows that you have an AMD
> Ellesmere GPU. Based on Googling, that is the codename for Polaris 10:
> 
>            *-display
>                 description: VGA compatible controller
>                 product: Ellesmere [Radeon RX 470/480/570/570X/580/580X/590]
>                 vendor: Advanced Micro Devices, Inc. [AMD/ATI]

Confirmed:

$ egrep 'smpboot: CPU0:|modesetting' journalctl-2.log 
Dec 28 12:17:08 tklaptop.kalfaoglu.net kernel: smpboot: CPU0: AMD Ryzen 7 1700 Eight-Core Processor (family: 0x17, model: 0x1, stepping: 0x1)
Dec 28 12:17:09 tklaptop.kalfaoglu.net kernel: [drm] amdgpu kernel modesetting enabled.
Dec 28 12:17:09 tklaptop.kalfaoglu.net kernel: [drm] initializing kernel modesetting (POLARIS10 0x1002:0x67DF 0x1043:0x1A60 0xC1).

Comment 10 Steve 2018-12-28 09:12:25 UTC
Could you temporarily disable non-Fedora kernel modules, so we are only debugging Fedora software:

$ grep taint journalctl-2.log 
Dec 28 09:17:18 tklaptop.kalfaoglu.net kernel: vboxdrv: loading out-of-tree module taints kernel.
Dec 28 09:17:18 tklaptop.kalfaoglu.net kernel: vboxdrv: module verification failed: signature and/or required key missing - tainting kernel

Comment 11 Steve 2018-12-28 09:38:31 UTC
Your log* shows this bug:

Bug_108260 - [Regression?] [powerplay] Failed to retrieve minimum clocks. 4.19-rc6+ 
https://bugs.freedesktop.org/show_bug.cgi?id=108260

I don't know if the fix is in kernel-4.19.12-301.fc29, but it has been pushed to testing:

bugfix update in Fedora 29 for kernel and kernel-headers 
https://bodhi.fedoraproject.org/updates/FEDORA-2018-64a4d60839

# dnf update --enablerepo=updates-testing kernel

* Log snippet:

$ grep powerplay journalctl-2.log 
Dec 28 12:17:09 tklaptop.kalfaoglu.net kernel: [drm] add ip block number 3 <powerplay>
Dec 28 12:17:09 tklaptop.kalfaoglu.net kernel: amdgpu: [powerplay] Failed to retrieve minimum clocks.
Dec 28 12:17:09 tklaptop.kalfaoglu.net kernel: amdgpu: [powerplay] Error in phm_get_clock_info

Comment 12 Turgut Kalfaoglu 2019-01-02 04:43:39 UTC
Thank you so much for your help..
I am now at 4.19.10-300, I am unable to find a newer kernel, 
# dnf update --enablerepo=updates-testing kernel
returns nothing.

I'm downloading the https://bodhi.fedoraproject.org/updates/FEDORA-2018-64a4d60839
and will update this report when it's complete..

Happy holidays!

Comment 13 Turgut Kalfaoglu 2019-01-02 04:58:23 UTC
I'm sorry but the same issue continues at 301 as well. 

When the machine is turned on, the screen is not totally black btw; it's dark grey (the backlighting is on), there is just nothing on the screen. After a tap the power button to turn it off, the backlighting is turned off. One more tap and the screen turns back on, this time with writing on it (the login screen).

Comment 14 Steve 2019-01-03 00:53:00 UTC
(In reply to Turgut Kalfaoglu from comment #13)
> I'm sorry but the same issue continues at 301 as well. 
> 
> When the machine is turned on, the screen is not totally black btw; it's
> dark grey (the backlighting is on), there is just nothing on the screen.
> After a tap the power button to turn it off, the backlighting is turned off.
> One more tap and the screen turns back on, this time with writing on it (the
> login screen).

Thanks for your followup reports. There is yet another kernel (4.19.13) available:

bugfix update in Fedora 29 for kernel and kernel-headers
https://bodhi.fedoraproject.org/updates/FEDORA-2019-23ea681504

Try adding the "--refresh" option:

# dnf update kernel --enablerepo=updates-testing --refresh

Comment 15 Steve 2019-01-03 01:00:20 UTC
(In reply to Turgut Kalfaoglu from comment #6)
...
> My current kernel line simply has:
> GRUB_CMDLINE_LINUX="pti=off"
...

BTW, "pti=off" is a non-standard option, so I would suggest removing it before testing further kernels.

From the documentation, it sounds like that option makes your system less secure:

"Disabling this feature removes hardening, ..."

The kernel’s command-line parameters
https://www.kernel.org/doc/html/v4.19/admin-guide/kernel-parameters.html

Comment 16 Turgut Kalfaoglu 2019-01-03 03:57:57 UTC
Thank you very much for your feedback. After yesterday's DNF UPDATE, the machine now boots correctly, with display and all. Thank you all very much for your assistance.

Comment 17 Turgut Kalfaoglu 2019-01-03 21:27:15 UTC
I'm sorry -- a day later it started happening again. I don't understand it. It's back to dark screen at login..

Comment 18 Steve 2019-01-03 23:12:15 UTC
(In reply to Turgut Kalfaoglu from comment #17)
> I'm sorry -- a day later it started happening again. I don't understand it.
> It's back to dark screen at login..

Thanks for reporting that. Did you do a poweroff or a reboot in between?

Comment 19 Steve 2019-01-03 23:31:34 UTC
(In reply to Steve from comment #18)
> (In reply to Turgut Kalfaoglu from comment #17)
> > I'm sorry -- a day later it started happening again. I don't understand it.
> > It's back to dark screen at login..
> 
> Thanks for reporting that. Did you do a poweroff or a reboot in between?

From your log file, it looks like you might dual boot with Windows. Is that so? And, if so, did you boot into Windows in between?

Log file snippet:

Dec 28 09:17:10 ... systemd[1]: RTC configured in localtime, ...

Comment 20 Turgut Kalfaoglu 2019-01-04 07:55:23 UTC
Yes, I sometimes do -- when I need to play my only game, World of Warcraft.
This morning, I turned the laptop on; let it sit, no display. Then it went into screensaver and when I hit a key, I was able to see the screen saver turn off and the login screen appeared.

I shut the machine down, re-powered, but the same problem, nothing on display.

Perhaps then dual booting to windows enables me to bypass the problem once in a while. 
IMHO, This is looking more and more like a display driver issue; not resetting/powering on the card when it's first loaded..
-t

Comment 21 Steve 2019-01-04 13:39:12 UTC
(In reply to Turgut Kalfaoglu from comment #20)
> Yes, I sometimes do -- when I need to play my only game, World of Warcraft.
> This morning, I turned the laptop on; let it sit, no display. Then it went
> into screensaver and when I hit a key, I was able to see the screen saver
> turn off and the login screen appeared.

Thanks for reporting that. Could you post the output from these:

$ pgrep -ia 'xorg|wayland'
$ env | grep -i desktop

> I shut the machine down, re-powered, but the same problem, nothing on
> display.
> 
> Perhaps then dual booting to windows enables me to bypass the problem once
> in a while. 
> IMHO, This is looking more and more like a display driver issue; not
> resetting/powering on the card when it's first loaded..
> -t

OK. I suggest updating the bug summary to say some like this:

amdgpu (POLARIS10): usually boots to black login screen with kernel 4.19.13

Comment 22 Turgut Kalfaoglu 2019-01-05 04:21:43 UTC
Thank you very much; here it goes:
[turgut@tklaptop ~]$ pgrep -ia 'xorg|wayland'
8026 /usr/libexec/gdm-wayland-session /usr/bin/gnome-session
8186 /usr/bin/Xwayland :0 -rootless -terminate -accessx -core -listen 4 -listen 5 -displayfd 6
[turgut@tklaptop ~]$ env | grep -i desktop
DESKTOP_SESSION=gnome
XDG_SESSION_DESKTOP=gnome
XDG_CURRENT_DESKTOP=GNOME
[turgut@tklaptop ~]$

Comment 23 Steve 2019-01-05 06:58:57 UTC
(In reply to Turgut Kalfaoglu from comment #22)
> Thank you very much; here it goes:
> [turgut@tklaptop ~]$ pgrep -ia 'xorg|wayland'
> 8026 /usr/libexec/gdm-wayland-session /usr/bin/gnome-session
> 8186 /usr/bin/Xwayland :0 -rootless -terminate -accessx -core -listen 4
> -listen 5 -displayfd 6
> [turgut@tklaptop ~]$ env | grep -i desktop
> DESKTOP_SESSION=gnome
> XDG_SESSION_DESKTOP=gnome
> XDG_CURRENT_DESKTOP=GNOME
> [turgut@tklaptop ~]$

Thanks. That means you are running Gnome3 with Wayland. See if the behavior changes when you run "GNOME on Xorg", which is the third option on the GDM login screen when you click on the gear icon. There is a screenshot here:

How to debug Wayland problems
https://fedoraproject.org/wiki/How_to_debug_Wayland_problems

Reboot at least once, so that the log file reflects the change. It should have "gdm-x-session" entries.

Please attach the output from:

$ journalctl -b --no-hostname > journalctl-3.log

Comment 24 Steve 2019-01-05 07:06:47 UTC
BTW, selinux appears to be disabled:

Dec 28 09:17:10 tklaptop.kalfaoglu.net kernel: SELinux:  Disabled at runtime.

Comment 25 Steve 2019-01-05 07:49:53 UTC
Here is another possible workaround:

1. Wait until the login screen should be displayed.
2. Press ctrl-alt-f2 to switch to a console.
3. Press ctrl-alt-f1 to switch back to the login screen.

Tested with gdm in a VM and on bare metal.

Comment 26 Turgut Kalfaoglu 2019-01-09 09:24:03 UTC
Created attachment 1519379 [details]
journalctl -b --no-hostname  output

Comment 27 Turgut Kalfaoglu 2019-01-09 09:27:51 UTC
> See if the behavior changes when you run "GNOME on Xorg", which is the third option on the GDM login screen when you click on the gear icon.

I just logged out, selected GNOME on Xorg from the gearbox, logged back in.
Then selected RESTART, and the machine restarted, back to darkness.
My problem occurs before I can login - I get no login prompt.
After GRUB2 selection and the [OK] blurbs flashing, there is nothing on display..
...Until I hit the power button to suspend the machine and hit power button again to wake it up.. Then I get the login prompt.

I attached the output of
journalctl -b --no-hostname > journalctl-3.log

The below does not work either; it was the first thing I tried:
>1. Wait until the login screen should be displayed.
(login screen is NOT displayed)
>2. Press ctrl-alt-f2 to switch to a console.
>3. Press ctrl-alt-f1 to switch back to the login screen.

Comment 28 Turgut Kalfaoglu 2019-01-09 14:23:40 UTC
Created attachment 1519512 [details]
dmesg output

Comment 29 Steve 2019-01-09 16:25:09 UTC
Thanks for your report and attachments. This is a definite problem, although it may not help with this bug:

$ grep '(EE).*amdgpu' journalctl-3.log 
Jan 09 12:21:10 /usr/libexec/gdm-x-session[8028]: (EE) Failed to load module "amdgpu" (module does not exist, 0)

The xorg-x11-drv-amdgpu package probably needs to be installed:

# dnf install xorg-x11-drv-amdgpu

Comment 30 Steve 2019-01-09 16:41:39 UTC
(In reply to Turgut Kalfaoglu from comment #27)
> > See if the behavior changes when you run "GNOME on Xorg", which is the third option on the GDM login screen when you click on the gear icon.
> 
> I just logged out, selected GNOME on Xorg from the gearbox, logged back in.
> Then selected RESTART, and the machine restarted, back to darkness.
> My problem occurs before I can login - I get no login prompt.
> After GRUB2 selection and the [OK] blurbs flashing, there is nothing on
> display..
> ...Until I hit the power button to suspend the machine and hit power button
> again to wake it up.. Then I get the login prompt.
...

See if you can do a "blind" login:

1. Wait until the GDM login screen should be displayed.
2. Press Enter.
3. Type your password.
4. Press Enter.

Tip: Do a practice run with a working kernel so that you can repeat the login steps when the screen is black.

Comment 31 Turgut Kalfaoglu 2019-01-10 15:35:20 UTC
I just tried the "blind" login. I was able to login - but it did not turn on the screen.

After logging in, I hit the power button to suspend, then again to unsuspend, THEN I could see something..
-t

Comment 32 Hans de Goede 2019-01-10 15:44:06 UTC
(In reply to Turgut Kalfaoglu from comment #31)
> I just tried the "blind" login. I was able to login - but it did not turn on
> the screen.
> 
> After logging in, I hit the power button to suspend, then again to
> unsuspend, THEN I could see something..

Hmm, this might be a problem with your initrd not having the necessary firmware for the amdgpu driver.

We have had some similar bugs, if you installed the latest updates you should have the right firmware now, but you may need to regenerate your initrd, try doing:

sudo dracut -f /boot/initramfs-$(uname -r).img $(uname -r)

With the kernel which works after blind login + suspend/resume and then try rebooting into that kernel again.

Comment 33 Turgut Kalfaoglu 2019-01-10 18:41:37 UTC
> The xorg-x11-drv-amdgpu package probably needs to be installed:
> # dnf install xorg-x11-drv-amdgpu

Many thanks.. I just installed it.. rebooting.

Comment 34 Turgut Kalfaoglu 2019-01-10 18:44:37 UTC
Same result - installing amdgpu did not help.

Comment 35 Turgut Kalfaoglu 2019-01-10 18:45:25 UTC
If no one else is having this problem amongst the GL702ZC users, perhaps I just need to reinstall Fedora 29. 
I'm sure it will correct itself.

Comment 36 Steve 2019-01-10 19:13:09 UTC
(In reply to Turgut Kalfaoglu from comment #35)
> If no one else is having this problem amongst the GL702ZC users, perhaps I
> just need to reinstall Fedora 29. 
> I'm sure it will correct itself.

Actually, there are two reports in which the LUKS passphrase screen is black on an AMD system. However, there are no logs attached, so what you are doing is very helpful.

Bug 1661807 - Kernel 4.19.10 or later, LUKS password prompt is not visible on boot
(Bug 1661807, Comment 4 confirms that the system has AMD graphics.)

Bug 1663496 - Laptop screen on Lenovo Ideapad Y700-15ACZ (AMD) does not work in 4.19* kernels

Comment 37 Steve 2019-01-10 19:34:46 UTC
If doing what Hans suggests (Comment 32) doesn't change the behavior, I suggest updating the bug summary to say something like this:

amdgpu (POLARIS10): usually boots to black login screen with kernel 4.19.13

(In reply to Turgut Kalfaoglu from comment #27)
...
> After GRUB2 selection and the [OK] blurbs flashing, there is nothing on display.
...

Could you check whether the boot messages change to a smaller font before the screen goes black?
(If you aren't sure what I mean, boot with a working kernel and watch for the boot messages changing to a smaller font.)

Comment 38 Justin M. Forbes 2019-01-29 16:14:17 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are 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 29 kernel bugs.

Fedora 29 has now been rebased to 4.20.5-200.fc29.  Please test this kernel update (or newer) 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 39 Turgut Kalfaoglu 2019-01-29 22:07:39 UTC
The recent kernel DID stop this problem from happening.. thank you.. The issue is solved.

Comment 40 Steve 2019-01-31 16:44:47 UTC
(In reply to Turgut Kalfaoglu from comment #39)
> The recent kernel DID stop this problem from happening.. thank you.. The
> issue is solved.

Thanks for your report. 

Resolution: --- → NOTABUG
Status: NEW → CLOSED
Last Closed: 2019-01-29 22:07:39

In this case, the bug "Resolution" would be "CURRENTRELEASE":
https://bugzilla.redhat.com/page.cgi?id=fields.html#resolution
(No need to change -- that's FYI.)


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