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):
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.
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.
The prompt should be responsive.
> 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'
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
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:
to the kernel command line, reproduce, and then post the output of
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:
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
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.
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?
> 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
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:
And as component select "DRM/AMDgpu" please also provide hardware detaisl such as your laptop and GPU model when filing the bug.
(In reply to Hans de Goede from comment #24)
> 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:
> And as component select "DRM/AMDgpu" please also provide hardware detaisl
> such as your laptop and GPU model when filing the bug.
Thank you for your help!
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:
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).
Adding NEEDINFO to check status of the fix.