Bug 1982213

Summary: 5.13+ kernels add an 80 second boot delay on one laptop
Product: [Fedora] Fedora Reporter: Bruno Wolff III <bruno>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: acaringi, adscvr, airlied, alciregi, bruno, bskeggs, hdegoede, jarodwilson, jeremy, jforbes, jglisse, jonathan, josef, kernel-maint, lgoncalv, linville, masami256, mchehab, ptalbert, steved
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-07-29 14:22:35 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
3.13 boot log
none
3.12 boot log none

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
dracut-055-3.fc35.x86_64
dbus-1.12.20-3.fc34.x86_64

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.