Bug 1759289

Summary: 5.3 introduced additional 6 seconds delay in early boot stage
Product: [Fedora] Fedora Reporter: Mirek Svoboda <goodmirek>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 31CC: 3bcg4zh9, airlied, bskeggs, goodmirek, hdegoede, ichavero, ih11sssm, itamar, jarodwilson, jeremy, jglisse, johannespfrang, john.j5live, jonathan, josef, kernel-maint, linville, masami256, mchehab, mjg59, pasik, steved
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-30 01:31:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
dmesg.txt, kernel 5.3.2 none

Description Mirek Svoboda 2019-10-07 18:44:32 UTC 
Created attachment 1623308 [details]
dmesg.txt, kernel 5.3.2

1. Please describe the problem:
While testing kernel 5.3.2 on HP 850 G4 with encrypted root disk (LUKS), I have observed that getting a LUKS password prompt takes 6 seconds longer, compared to 5.2.17. Kernel 5.3.1 shows the same behavior. I have found by chance that the boot time of kernel 5.3 is the same as of the kernel 5.2 if I disable builtin LAN ethernet port.
Boot time until LUKS password prompt of 5.2: 5.9 seconds 
Boot time until LUKS password prompt of 5.3 (eth enabled): 11.9 seconds

2. What is the Version-Release number of the kernel:
5.3.2-300.fc31.x86_64

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :
As far as I know it appeared with 5.3, for sure with 5.3.1. I did not test 5.3.0.
Last time it booted without the additional delay in 5.2.17, I did not test later 5.2 kernels.

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:
Yes, the issue is 100% reproducible.
Start machine, measure the time from pressing enter in grub menu till LUKS password prompt appears.
I have measured it multiple times.

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:
Kernel 5.4.0-0.rc1.git1.1.fc32 shows the LUKS password prompt in 7.5 seconds, the time is not affected by the ethernet LAN state. So it is possible to say that the issue does not occur with the latest rawhide kernel, although the latest rawhide kernel prolongs the overall boot time by 1.6 seconds, compared to  5.2.17.

6. Are you running any modules that not shipped with directly Fedora's kernel?:
Not before LUKS container is opened. After switching root to LUKS device, I load VirtualBox modules, but these are not present in /boot kernels.

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.
Comment 1 Mirek Svoboda 2019-10-10 08:49:56 UTC 
Only known recovery from the freeze is a hard reset. This is not a temporary freeze, but system hang up.
Comment 2 Mirek Svoboda 2019-10-10 08:58:37 UTC 
Please disr(In reply to Mirek Svoboda from comment #1)
> Only known recovery from the freeze is a hard reset. This is not a temporary
> freeze, but system hang up.

Please disregard this comment, it should have been for a different bug.
Comment 3 Justin M. Forbes 2020-03-03 16:30:35 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 31 kernel bugs.

Fedora 31 has now been rebased to 5.5.7-200.fc31.  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 have moved on to Fedora 32, and are still experiencing this issue, please change the version to Fedora 32.

If you experience different issues, please open a new bug report for those.
Comment 4 Mirek Svoboda 2020-03-03 16:34:35 UTC 
(In reply to Justin M. Forbes from comment #3)
> *********** 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 31 kernel bugs.
> 
> Fedora 31 has now been rebased to 5.5.7-200.fc31.  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 have moved on to Fedora 32, and are still experiencing this issue,
> please change the version to Fedora 32.
> 
> If you experience different issues, please open a new bug report for those.

I am currently running 5.5.7-200.fc31.x86_64 and the issue is still present.
Comment 5 Mirek Svoboda 2020-04-30 01:31:16 UTC 
The issue does not happen with kernel 5.5.13.
Comment 6 Laverne Hubbard 2021-07-17 07:36:06 UTC Comment hidden (spam)
Comment 7 Demarcusteed 2021-08-02 07:35:47 UTC Comment hidden (spam)