Hide Forgot
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:
Created attachment 1516061 [details] lshw output
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
(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
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.
(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
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.
Created attachment 1517184 [details] journalctl -k -b -1 output journalctl -k -b -1 output
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]
(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).
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
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
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!
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).
(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
(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
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.
I'm sorry -- a day later it started happening again. I don't understand it. It's back to dark screen at login..
(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?
(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, ...
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
(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
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 ~]$
(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
BTW, selinux appears to be disabled: Dec 28 09:17:10 tklaptop.kalfaoglu.net kernel: SELinux: Disabled at runtime.
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.
Created attachment 1519379 [details] journalctl -b --no-hostname output
> 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.
Created attachment 1519512 [details] dmesg output
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
(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.
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
(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.
> The xorg-x11-drv-amdgpu package probably needs to be installed: > # dnf install xorg-x11-drv-amdgpu Many thanks.. I just installed it.. rebooting.
Same result - installing amdgpu did not help.
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.
(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
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.)
*********** 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.
The recent kernel DID stop this problem from happening.. thank you.. The issue is solved.
(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.)