DMESG: silent gap in boot process

ipic · Guru Joined: 29 Dec 2003 Posts: 430 Location: UK

I have upgraded my cpu from Ryzen 7 200 (8 cores) to Ryzen 9 5090X (16 cores).

On the old cpu, there was a 20 second 'silent' gap in the boot process. With the new cpu the gap has grown to around 50 seconds.

The relevant part of dmesg output is below. I can see that the initramfs has not started in this gap - since it appears in dmesg output further on.

It's not a problem, since the machine is not booted often. This post is really just to see if someone can help me understand what is happening in the silent gap.

Banana · Posted: Sat Jan 18, 2025 9:40 am Post subject:

One hint of an explanation could be in this thread here: https://forums.gentoo.org/viewtopic-t-1073986-start-0.html

Another posibility which may "help": I had something similar, but can not really remember what is was exactly. I did install https://packages.gentoo.org/packages/sys-apps/rng-tools and added it to the boot process and everything was finde after that.
_________________
Forum Guidelines

PFL - Portage file list - find which package a file or command belongs to.
My delta-labs.org snippets do expire

ipic · Guru Joined: 29 Dec 2003 Posts: 430 Location: UK

Thanks for the response, appreciated.

I *think* I can rule out random number seeding. rngd is started by the system init, which is a lot later in the process. Also, as an additional rabbit hole, I saw that the motherboard TPM entropy source was disabled.

ipic · Guru Joined: 29 Dec 2003 Posts: 430 Location: UK

Upgraded to kernel 6.13.0, and the dmesg 'silent gap' has gone back down to around the time it took on the previous cpu, as below.
I had to add configuration options DRM_SIMPLEDRM and SYSFB_SIMPLEFB to get the kernel to compile.
That, and any changes brought in by 6.13.0 itself were the only changes to my previous config.
I'm happier now - at least the boot is back to what it was :-)

I'd still like to understand what is going on in that gap though.

pingtoo · Posted: Mon Jan 20, 2025 7:17 pm Post subject:

ipic,

print out to dmesg buffer for kernel is controlled by printk kernel function which can be configured either at kernel command line level or change to /proc/sys/kernel/printk.

It is unlikely you have kernel command line setting to change printk, however it is likely you have initrd that does that.

So if you have initrd/initramfs, check the "init" script, see if it use dmesg -n 1 or sysctl -w kernel.printk=x x x x or did something direct to /proc/sys/kernel/printk

ipic · Guru Joined: 29 Dec 2003 Posts: 430 Location: UK

I may be wrong, but dracut's init process is run further down the dmesg (from the original post):

pingtoo · Posted: Mon Jan 20, 2025 7:40 pm Post subject:

Don't know. Then my guess is wrong. But in principle there is something disable printk function at that moment. You can try to enable early console print and make kernel logging at debug to see when that got disale.

pietinger · Posted: Mon Jan 20, 2025 11:45 pm Post subject:

If you suspect that it is the init-script of the initramfs that (temporarily) switches off the messages, you can (relatively) easily check this. Extract the initramfs (*) and remove the line that switches off logging - presumably:

ipic · Guru Joined: 29 Dec 2003 Posts: 430 Location: UK

I checked.
The init script has no reference to /proc/sys/kernel/printk, dmesg or sysctl.

And it is run well after the gap - which is at 2-3 seconds, init script announces itself at 27 seconds plus.

ipic · Guru Joined: 29 Dec 2003 Posts: 430 Location: UK

I changed my kernel boot command to this:

ipic · Guru Joined: 29 Dec 2003 Posts: 430 Location: UK

I worked out that one of the SSD drives I have was failing. Not enough to fail outright, but enough that the BIOS was complaining about it at boot time. Also occasional drops to 1.5 Gig/second on the sata link.

While finding that out I was experimenting with different boot parameters and loading sequences, which got me to a kernel command line that looks like this: