Bug 1982213 - 5.13+ kernels add an 80 second boot delay on one laptop
Summary: 5.13+ kernels add an 80 second boot delay on one laptop
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2021-07-14 12:50 UTC by Bruno Wolff III
Modified: 2021-07-29 14:22 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-07-29 14:22:35 UTC
Type: Bug

Attachments (Terms of Use)
3.13 boot log (461.47 KB, text/plain)
2021-07-14 13:08 UTC, Bruno Wolff III
no flags Details
3.12 boot log (671.92 KB, text/plain)
2021-07-14 13:10 UTC, Bruno Wolff III
no flags Details

Description Bruno Wolff III 2021-07-14 12:50:38 UTC
1. Please describe the problem:

2. What is the Version-Release number of the kernel:

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 :

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

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``:

6. Are you running any modules that not shipped with directly Fedora's kernel?:

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 Bruno Wolff III 2021-07-14 13:08:24 UTC
Created attachment 1801498 [details]
3.13 boot log

Comment 2 Bruno Wolff III 2021-07-14 13:10:31 UTC
Created attachment 1801500 [details]
3.12 boot log

Comment 3 Justin M. Forbes 2021-07-14 13:17:14 UTC
I assume you mean 5.13 kernels? I did look at the logs and did not see anything, but which version of dracut and which dbus is installed.  Are you sure this isn't 1976653 which is a bad interraction between newer dbus and dracut which puts a 90 second delay in the boot? There are workarounds listed in the bug. As this is a dracut issue, it would only appear on kernels where the initramfs was created with the offending version, and older kernels would continue to work as expected unless you regenerated their initramfs for some reason.

Comment 4 Bruno Wolff III 2021-07-14 13:18:22 UTC
I accidentally hit return typing in the summary which started the bug without a problem description.

Starting with 3.13 kernels (rc1 shows the issue), there is approximately an 80 second boot delay that isn't there with 3.12 or earlier kernels. I installed 3.12.12 after seeing the problem and it does not have it, so it looks like this issue is triggered by the kernel change, rather than say dracut. However the fix might end up being somewhere other than the kernel.

There is approximately a 30 second delay after printing "clocksource: Switched to clocksource tsc".
Then the following is printed "ata5: SATA link down (SStatus 0 SControl 300)
input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio2/input/input10".
Then there is approximately a 50 second delay before the boot continues with printing "ata6: SATA link down (SStatus 0 SControl 300)".

So far I have only seen this on my backup laptop.

Comment 5 Bruno Wolff III 2021-07-14 13:21:59 UTC
I also saw the issue with a 3.14rc1 kernel. I actually saw it there first as I went from a 3.11 kernel to a 3.14 because I hadn't updated my backup laptop in a while.

The log timestamps don't reflect the delay. I think this is because there are from before the root pivot and aren't written until later.

Comment 6 Bruno Wolff III 2021-07-14 13:25:00 UTC

Comment 7 Bruno Wolff III 2021-07-14 16:43:27 UTC
For some reason I wasn't even seeing the 3/5 switch. Yeah all of the comments should read 5.something instead of 3.something.

Comment 8 Bruno Wolff III 2021-07-14 20:27:42 UTC
5.13.2-300.fc34.x86_64 exhibits the same behavior.

Comment 9 Bruno Wolff III 2021-07-29 14:22:35 UTC
This is fixed in 5.14 kernels. I reinstalled a 5.13 kernel and still saw the problem, so it looks like it was triggered by a kernel change rather than systemd. Though it may be that systemd could have been involved.

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