Bug 1490490 - Plymouth doesn't echo LUKS keypresses or show boot progress with amdgpu+LUKS
Summary: Plymouth doesn't echo LUKS keypresses or show boot progress with amdgpu+LUKS
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-amd
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Orphan Owner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
: 1605409 1629387 1705729 1718569 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-11 18:12 UTC by Alicia Boya García
Modified: 2019-06-20 16:17 UTC (History)
14 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2019-05-29 00:10:06 UTC


Attachments (Terms of Use)
output of "journalctl -b" with "plymouth.debug=stream:/dev/kmsg" boot parameters (280.65 KB, text/plain)
2018-11-22 14:25 UTC, Sebastian
no flags Details
/run/plymouth.log - new improved plymouth theme - everything working (44.90 KB, text/plain)
2018-12-21 06:51 UTC, Sebastian
no flags Details
/run/plymouth.log - new improved plymouth theme - PSR ENABLED (44.92 KB, text/plain)
2018-12-21 06:51 UTC, Sebastian
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1629387 None CLOSED Plymouth completely prevents boot with 4.18 + AMDGPU + LUKS 2019-06-24 08:36 UTC

Internal Trackers: 1629387

Description Alicia Boya García 2017-09-11 18:12:25 UTC
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)

Comment 1 fednuc 2018-02-16 20:37:42 UTC
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).

Comment 2 fednuc 2018-02-16 20:38:46 UTC
Correction: 390X is GCN 1.2

Comment 3 fednuc 2018-02-16 20:42:31 UTC
Argh, no it's not, sorry for the spam.

Comment 4 fednuc 2018-04-04 19:00:18 UTC
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).

Comment 5 Fedora End Of Life 2018-05-03 07:53:38 UTC
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.

Comment 6 fednuc 2018-05-13 11:07:49 UTC
Still a problem on 28. Someone please bump the version, because I can't.

Comment 7 Fedora End Of Life 2018-05-29 12:16:15 UTC
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.

Comment 8 fednuc 2018-10-02 18:08:58 UTC
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?

Comment 10 Michael Catanzaro 2018-11-01 15:25:59 UTC
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.

Comment 11 Ray Strode [halfline] 2018-11-07 16:17:30 UTC
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?

Comment 12 Sebastian 2018-11-22 14:22:14 UTC
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.

Comment 13 Sebastian 2018-11-22 14:25 UTC
Created attachment 1507979 [details]
output of "journalctl -b" with "plymouth.debug=stream:/dev/kmsg" boot parameters

Comment 14 fednuc 2018-11-22 15:02:38 UTC
Which driver are you using, nouveau or the binary blob?

Comment 15 Sebastian 2018-11-27 12:30:11 UTC
(In reply to Stephen from comment #14)
> Which driver are you using, nouveau or the binary blob?

I'm using the nouveau driver.

Comment 16 Hans de Goede 2018-12-19 16:30:50 UTC
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"

Comment 17 Hans de Goede 2018-12-19 16:33:44 UTC
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).

Comment 18 fednuc 2018-12-19 16:40:01 UTC
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.

Comment 19 Hans de Goede 2018-12-19 16:43:27 UTC
(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.

Comment 20 fednuc 2018-12-19 16:46:32 UTC
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.

Comment 21 Sebastian 2018-12-21 06:48:07 UTC
(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.

Comment 22 Sebastian 2018-12-21 06:51 UTC
Created attachment 1516058 [details]
/run/plymouth.log - new improved plymouth theme - everything working

Comment 23 Sebastian 2018-12-21 06:51 UTC
Created attachment 1516059 [details]
/run/plymouth.log - new improved plymouth theme - PSR ENABLED

Comment 24 Hans de Goede 2019-01-10 11:01:46 UTC
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

Comment 25 Sebastian 2019-01-10 13:46:15 UTC
(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

Comment 26 Hans de Goede 2019-01-21 15:56:28 UTC
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

Comment 27 Ben Cotton 2019-03-27 16:33:17 UTC
Adding NEEDINFO to check status of the fix.

Comment 28 Alicia Boya García 2019-04-24 20:37:49 UTC
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.

Comment 29 Shecks 2019-04-30 22:34:55 UTC
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)

Comment 30 Ben Cotton 2019-05-02 19:23:22 UTC
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.

Comment 31 Ben Cotton 2019-05-29 00:10:06 UTC
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.

Comment 32 Hans de Goede 2019-06-12 08:26:38 UTC
This is still happening, re-opening.

Also changing the component, since this clearly is a kernel modesetting driver issue, not a plymouth issue.

Comment 33 Hans de Goede 2019-06-12 08:35:59 UTC
*** Bug 1705729 has been marked as a duplicate of this bug. ***

Comment 34 Hans de Goede 2019-06-12 08:36:02 UTC
*** Bug 1718569 has been marked as a duplicate of this bug. ***

Comment 35 Hans de Goede 2019-06-12 08:41:51 UTC
*** Bug 1605409 has been marked as a duplicate of this bug. ***

Comment 36 Hans de Goede 2019-06-12 08:44:25 UTC
*** Bug 1629387 has been marked as a duplicate of this bug. ***

Comment 37 Hans de Goede 2019-06-12 09:11:39 UTC
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.

Comment 38 Ben Cotton 2019-06-20 16:17:59 UTC
Removing from the Prioritized Bugs list as it needs to be handled upstream.


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