Description of problem: I installed Fedora 26 in a new computer with a AMD Polaris11 video card and set up full disk encryption, so every time I boot up I get prompted for the password. Sometimes it works fine, but sometimes it's ridiculously slow. A second or more may pass since I press a key until it's registered in the screen. The slowness affects only the graphical prompt. If I switch to text mode with the Esc key I can type it just fine there. After the system has booted I don't notice any strange performance difference regardless of whether the prompt was fast or slow. Version-Release number of selected component (if applicable): plymouth-core-libs: 0.9.3 xorg-x11-drv-amdgpu: 1.3.0 How reproducible: 50/50 Probably not exactly, but it happens quite often. Steps to Reproduce: 1. Boot the computer (with a new AMD card and full disk encryption). 2. Type the password. Actual results: The prompt is very laggy and dots appear very slowly... You may have to wait half a minute for it if it's a bit long. Expected results: The prompt should be responsive. Additional info: > lspci |grep VGA 04:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 41) af:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 460] (rev cf)
I've just switched to amdgpu from radeon on a Radeon 390X (GCN 1.1) and am seeing something similar. I haven't tried waiting to see if dots appear eventually, but every time with 3-4 boots, the dots were not displayed. Hitting Esc. immediately switches between text and graphical modes. This doesn't affect the actual input of the password - typing it blindly in graphical mode and hitting Enter immediately continues bootup (immediate disk activity then successful boot). This is with kernel 4.15.3-300.fc27 with the following boot params added: amdgpu.cik_support=1 radeon.cik_support=0 amdgpu.dc=1 (First two are to force the amdgpu driver; last one is to enable HDMI/DisplayPort audio, which is otherwise disabled for pre-Vega hardware with the current Fedora 4.15 config).
Correction: 390X is GCN 1.2
Argh, no it's not, sorry for the spam.
This also affects the graphical version of DNF upgrade-on-reboot (at least with dnf system-upgrade reboot - I don't use "reboot to upgrade packages" normally). In the case of dnf system-upgrade reboot, after blindly entering the encryption password, the empty graphical password box remains shown, while the upgrade is taking place "behind" it (verifiable by switching to text mode with Esc).
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still a problem on 28. Someone please bump the version, because I can't.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Still present as of today. Can someone change the title to "Plymouth doesn't echo LUKS keypresses or show boot progress with amdgpu+LUKS" (or something like that)? That's the current behaviour, unless Alicia you're still seeing the "slow echo" variant?
This was accepted as a PrioritizedBug. https://meetbot.fedoraproject.org/fedora-meeting/2018-10-10/fedora_prioritized_bugs_and_issues.2018-10-10-15.02.log.html#l-56
I've acquired an RX570 and installed Fedora 29 with LUKS encryption. Everything's working totally fine. So there's more to this than "Plymouth doesn't echo LUKS keypresses or show boot progress with amdgpu+LUKS" because I have both amdgpu and LUKS and it's echoing keypresses with no problem.
so can anyone who's seeing this please add: plymouth.debug=stream:/dev/kmsg to the kernel command line, reproduce, and then post the output of journalctl -b after boot up?
I can reproduce the problem, but I'm using an nvidia gpu. Sometimes there is the plymouth LUKS password screen and sometimes there isn't. In this case typing in the password blindly works. When there is the password screen key presses or the boot progress aren't shown as well. As soon as I disable PSR the problem is gone.
Created attachment 1507979 [details] output of "journalctl -b" with "plymouth.debug=stream:/dev/kmsg" boot parameters
Which driver are you using, nouveau or the binary blob?
(In reply to Stephen from comment #14) > Which driver are you using, nouveau or the binary blob? I'm using the nouveau driver.
Hmm, I've the feeling that this is not a plymouth problem. If disabling PSR fixes it then this definitely is NOT a plymouth problem. I've a version of plymouth with some fixes which may help here: https://fedorapeople.org/~jwrdegoede/plymouth/ Note the main feature here is a new improved plymouth theme, but this does also contain a bunch of drm/kms handling fixes which might help. To give this a try download all rpm files from the above URL except the .src.rpm and -devel files and then from a directory with all those files in it, run: sudo rpm -Uvh plymouth*.rpm Then run: sudo plymouth-set-default-theme -R bgrt This will select the new theme and rebuild the initrd for the currently running kernel. Please let me know if this helps or not, if you are still having problems, please attach /run/plymouth.log from a boot with the new plymouth. p.s. If you want to switch back to the old theme, do: "sudo plymouth-set-default-theme -R charge"
One more remark for people who have both working and non working boots, it would be get to get a copy of /run/plymouth.log from boot types of boots (with clear marking which is which).
Presumably PSR == panel self-refresh from the eDP standard? I'm seeing this issue on a desktop with amdgpu over standard DP, so there is no PSR to disable (also I'm not sure if amdgpu even supports PSR). Hans, in my case it's consistently broken.
(In reply to fednuc from comment #18) > Presumably PSR == panel self-refresh from the eDP standard? Yes. > I'm seeing this issue on a desktop with amdgpu over standard DP, so there is > no PSR to disable (also I'm not sure if amdgpu even supports PSR). > > Hans, in my case it's consistently broken. Ok, please give the test plymouth version I linked to a try, no promises. Also if things still do not work, please attach a copy of the /run/plymouth.log file the test version writes out here.
The box in question is still on F28 for now so I'm not sure if they'll install but I'll give it a shot; otherwise I'll update here when I've moved it across to F29 and tested.
(In reply to Hans de Goede from comment #16) > Hmm, I've the feeling that this is not a plymouth problem. If disabling PSR > fixes it then this definitely is NOT a plymouth problem. Still tried your version of plymouth, but same situation: -with PSR enabled key-presses aren't shown -without PSR everything works as expected This problem appeared with kernel version 4.18.X.
Created attachment 1516058 [details] /run/plymouth.log - new improved plymouth theme - everything working
Created attachment 1516059 [details] /run/plymouth.log - new improved plymouth theme - PSR ENABLED
Sebastian, I think the PSR triggered problem is a kernel driver issue. Plymouth re-uses a single framebuffer, calling drmModeDirtyFB() on each update, I think that the driver does not properly recognize / tracks that a call to drmModeDirtyFB() means the panel needs to be taken out of self-refresh as there is new contents in the framebuffer. It is probably best if you file a bug with the upstream amdgpu developers for this, feel free to copy and paste my theory about the cause of this. To file a bug for this, go here: https://bugs.freedesktop.org/enter_bug.cgi?product=DRI And as component select "DRM/AMDgpu" please also provide hardware detaisl such as your laptop and GPU model when filing the bug. Regards, Hans
(In reply to Hans de Goede from comment #24) > Sebastian, > > I think the PSR triggered problem is a kernel driver issue. Plymouth re-uses > a single framebuffer, calling drmModeDirtyFB() on each update, I think that > the driver does not properly recognize / tracks that a call to > drmModeDirtyFB() means the panel needs to be taken out of self-refresh as > there is new contents in the framebuffer. > > It is probably best if you file a bug with the upstream amdgpu developers > for this, feel free to copy and paste my theory about the cause of this. > > To file a bug for this, go here: > > https://bugs.freedesktop.org/enter_bug.cgi?product=DRI > > And as component select "DRM/AMDgpu" please also provide hardware detaisl > such as your laptop and GPU model when filing the bug. > > Regards, > > Hans Thank you for your help! https://bugs.freedesktop.org/show_bug.cgi?id=109282
Hi, I've just built a new test build of plymouth which may help with some of the diskunlock screen issues seen on AMD GPUs (but not with the PSR issue): To give this a try download all rpm files from: https://fedorapeople.org/~jwrdegoede/plymouth/ except the .src.rpm and -devel files and then from a directory with all those files in it, run: sudo rpm -Uvh plymouth*.rpm This version also includes a new theme which will be the default for Fedora 30, to test the new plymouth you need to regenerate your initrd, to do this (and also select the new theme) run: sudo plymouth-set-default-theme -R bgrt Note this updates the initrd for your currently running kernel, so if you've installed a kernel update since your last reboot, you may need to run this a second time after rebooting (check "uname -r" output before and after reboot). Please give this a test run and let me know if it helps (or not). Regards, Hans
Adding NEEDINFO to check status of the fix.
Unfortunately, it has been a long time since I stopped getting graphical output from plymouth at all. Using Esc I can toggle between plain text mode and a text-based colorful mode, neither of which have the delay problem, but they don't use non-text-based graphics either, so I can't really tell.
I've just upgraded from Fedora 29 to Fedora 30 and I now experiencing the same issue. Similarly, I have an MSI R9 390 GPU and I am using the following kernel parameters:- radeon.cik_support=0 amdgpu.dc=1 amdgpu.cik_support=1 I have rebooted a couple of times since upgrading to Fedora 30 and each time there is no feedback when typing the LUKS passphrase but the keyboard input is accepted and, if typed correctly, the boot process will continute as expected once the return key is pressed. Additionally I am using the "spinfinity" plymouth theme and the usual progress bar also not displayed (I revert to the default theme run some more tests)
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This is still happening, re-opening. Also changing the component, since this clearly is a kernel modesetting driver issue, not a plymouth issue.
*** Bug 1705729 has been marked as a duplicate of this bug. ***
*** Bug 1718569 has been marked as a duplicate of this bug. ***
*** Bug 1605409 has been marked as a duplicate of this bug. ***
*** Bug 1629387 has been marked as a duplicate of this bug. ***
What really needs to happen here is that someone opens a bug with the upstream amdgpu developers so that they can fix this. To file a bug for this, go here: https://bugs.freedesktop.org/enter_bug.cgi?product=DRI And as component select "DRM/AMDgpu" please also provide hardware detaisl such as your laptop and GPU model when filing the bug. Once you've filed a bug, please report back here with a link to the bug.
Removing from the Prioritized Bugs list as it needs to be handled upstream.
Not a single affected user willing to file an upstream bug report...?
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
Hans, you're sure xorg-x11-drv-amd is the right component? An orphaned package? Anyway, since nobody has reported this upstream, and it's assigned to no maintainer, I'm going to close this. If anybody is still experiencing this issue, please report the bug upstream as requested by Hans and post a link here.
(In reply to Michael Catanzaro from comment #42) > Hans, you're sure xorg-x11-drv-amd is the right component? An orphaned package? It is normal for drm/kms kernel bugs to be assigned to the matching userspace component to make it easier to get a list of say intel kms/drv bugs, or amd bugs. I did not know the -amd variant was orphaned, I was expecting that the -amd variant contained the amdgpu driver, but I guess it contained some older driver. I've changed this to xorg-x11-drv-ati now. Also some communication before just closing this, especially since it has many dups as many users are affected by this would have been nice. This bug is even listed on https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues ... Recently I've gotten access to one of the affected AMD cards and I can reproduce this problem, so I am re-opening this. I've looking into this on my TODO list, but it likely is going to still be a couple of weeks minimum before I get around to this. I still believe that it is an kernel amdgpu driver problem and it would still be useful if one of the reporters can file an upstream bug for this against the kernel amdgpu driver in the mean time...
*** Bug 1744952 has been marked as a duplicate of this bug. ***
I've been working on debugging this this weekend and it turns out that at least for people who are passing kernel commandline options to use the amdgpu driver on cards which by default use the radeon driver, this is a plymouth issue after all. When this is done the radeon driver briefly registers a /dev/dri/card0 device and then unregisters it again, followed by amdgpu registering it a second time. This causes plymouth to see (when they are played back on init) udev add + remove + add events for /dev/dri/card0 and this was triggering a bug in plymouth, see: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59 for more details and the fix. The kernels weird behavior here is undesirable, so I've also submitted a kernel patch upstream which makes the radeon driver check the kernel commandline options before registering /dev/dri/card0. I'm preparing an updated plymouth package with the fix from: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59 added, please test. Note I'm going to disable auto karma based pushing to stable to avoid nasty surprises. I expect the fix to not cause trouble elsewhere but you never know.
FEDORA-2019-3f95b8911d has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-3f95b8911d
plymouth-0.9.4-9.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-aadaa1a995
Still the same problem/behaviour on F30 with 0.9.4-9 unfortunately (kernel 5.2.11-200). Also still the same problem once GDM is reached - the GDM interface doesn't appear, the blank LUKS Plymouth prompt remains. Previously I was switching to a different VT and restarting GDM from therre, but I found that just switching to a different VT and back causes GDM to appear. I'm guessing this would have worked with the previous Plymouth version too, but didn't test. I'm also guessing that this is probably a side-effect of this Plymouth issue? Thanks for all the work tracking this down/fixing it.
(In reply to fednuc from comment #48) > Still the same problem/behaviour on F30 with 0.9.4-9 unfortunately (kernel > 5.2.11-200). > > Also still the same problem once GDM is reached - the GDM interface doesn't > appear, the blank LUKS Plymouth prompt remains. Previously I was switching > to a different VT and restarting GDM from therre, but I found that just > switching to a different VT and back causes GDM to appear. I'm guessing this > would have worked with the previous Plymouth version too, but didn't test. > I'm also guessing that this is probably a side-effect of this Plymouth issue? > > Thanks for all the work tracking this down/fixing it. Thank you for the quick feedback. The symptoms you are describing exactly match what I saw, including gdm not showing + a VT switch away + back fixing gdm. I guess you did not re-generate your initrd after installing the new plymouth? This is my bad I should have added some testing instructions about this. Please run: uname -r and write down the printed kernel version and then to regenerate your initrd do: sudo dracut -f And then reboot, then after rebooting things should work, if they still do not work run "uname -r" again. If the output does not match with the previous run, try "sudo dracut -f" + rebooting one more time.
OK that fixed it, nice one :) All seems to be working perfectly now! Is that manual step (or a kernel upgrade?) the only way for the fix to be picked up for other users with the same problem? Thanks again!
(In reply to fednuc from comment #50) > OK that fixed it, nice one :) All seems to be working perfectly now! That is good to hear. I'm still waiting for feedback from other users, but I hope that we can finally put this issue to rest now. > Is that manual step (or a kernel upgrade?) the only way for the fix to be picked up for other users with the same problem? Yes, I'm afraid so. We deliberately do not re-generate the initrd(s) on plymouth updates, so that a bad plymouth update cannot render the system unbootable (users will always have older kernels with an old initrd around as fallback). But we release kernel updates quite regularly, so users who regularly apply updates should get a new initrd soon enough anyways.
plymouth-0.9.4-9.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-3f95b8911d
plymouth-0.9.4-9.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
plymouth-0.9.4-9.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.