How Intel's Clear Linux Team Cut The Kernel Boot Time From 3 Seconds To 300 ms

[skeevy420]

Yeah I noticed this too on servers that provide a LCD panel for boot status codes (Fujitsu), it shows a ton of different codes that I never saw on a normal PC through a POST card. (this is also available on high end "gaming" or overclocking motherboards, they use a 2-digit segment display soldered on the board)

I don't know what they mean though.

I got lucky and found the meanings to the codes of my system digging through Dell's documentation. I should probably print that one of these days.

[starshipeleven]

The lights on the front of mine output in code during the POST and it isn't until that is over that the GPU fires up. Mine does ECC checks, HDD checks, RAID checks, dual CPU checks, etc. Tweak one thing hardware wise and it'll know and start nagging me.

Yeah I noticed this too on servers that provide a LCD panel for boot status codes (Fujitsu), it shows a ton of different codes that I never saw on a normal PC through a POST card. (this is also available on high end "gaming" or overclocking motherboards, they use a 2-digit segment display soldered on the board)

I don't know what they mean though.

[skeevy420]

Also doing a more extensive POST (power on self test) sequence for diagnostic reasons is another possibility.

That's what it is.

The lights on the front of mine output in code during the POST and it isn't until that is over that the GPU fires up. Mine does ECC checks, HDD checks, RAID checks, dual CPU checks, etc. Tweak one thing hardware wise and it'll know and start nagging me.

[starshipeleven]

Is there any reason why does it take so long?

There is no official explanation so "the firmware is shit" could very well be the real reason. I suspect RAM controller training (calibration and such). Servers that take ages to boot (Dell, Fujitsu) have been less picky with ECC RAM in my experience.
Also doing a more extensive POST (power on self test) sequence for diagnostic reasons is another possibility.

Supermicro boot is faster but is a bit more bitchy with RAM, and it WILL NOT BOOT if you are not using ECC ram or if it does not like the ECC RAM you install, not printing shit on screen nor giving any other indication of what went wrong.

Note that I'm not counting the time needed for RAID cards to power up and enumerate drives, do scans and whatever, as that's not part of the server's UEFI. But in practice you also have that to add on top of the UEFI boot times in most servers.

[skeevy420]

nope, just 1 disk. apparently a full minute is common for servers. the server right below it (a Super Micro with twice as many CPUs and a lot more RAM) only takes 20 seconds, though, so there doesn't seem to be any reason for it to take so long other than Dell's UEFI firmware being shit.

Their BIOS is shit too

See above

[skeevy420]

Is there any reason why does it take so long?

Too many disks to spin up maybe?

I have a Dell T5500 Workstation and it takes around 10 seconds before the GPU outputs anything and another 20 seconds from there before Grub loads up.

Simply put: Enterprise grade Dell equipment is slow to boot due to having assloads of POSTs.

I'm specifically saying workstation because there's also a Dell T5500 laptop and it's a piece of crap.

[polarathene]

Anyway the problem with the ultra fast boot mode is that if a kernel update won't boot, I'm stuck. Happened few times. I can't switch to some other boot entry since the keyboard won't work.

Mine will disable the feature if it boots unsuccessfully 3 times iirc. Don't have to pop out the CMOS battery, personally easier to just detach the OS disk(s) by unplugging the SATA cables. I think it might prevent USB stick(or other storage) from being bootable option though, if not then having that as a higher priority when plugged in could work for recovery.

Really though, it's barely an important time savings as I rarely reboot(Once every few months usually), so I just don't see much point in it myself.

Can someone provides a list of modules that should be run in parallel to speed up boot? amdgpu?
driver_async_probe=[list]

It'd be nice to know how to query that in CLI. I see the description for using module.async_probe as an alternative way to load, but none of the modules I have loaded appear to have this as a parameter.

All the ones in the kernel that support async afaik are listed here:

https://github.com/torvalds/linux/search?q=PROBE_PREFER_ASYNCHRONOUS&unscoped_q=PROBE_PREFER_ASYNCHRONOUS

Based on probe_type enum docs: https://01.org/linuxgraphics/gfx-doc...l#c.probe_type

I have tried scanning (I guess only loaded modules?) for the param like this:
grep sync /sys/module/*/parameters/*

But only got "scan:async" as a result for scsi_mod.

[hotaru]

Is there any reason why does it take so long?

Too many disks to spin up maybe?

nope, just 1 disk. apparently a full minute is common for servers. the server right below it (a Super Micro with twice as many CPUs and a lot more RAM) only takes 20 seconds, though, so there doesn't seem to be any reason for it to take so long other than Dell's UEFI firmware being shit.

[tildearrow]

That's a rack server. A full minute for UEFI in a server is common.

Is there any reason why does it take so long?

Too many disks to spin up maybe?

[starshipeleven]

The problem is that by doing this they'll be dropping compatibility with e.g. BIOS. Yes, BIOS still requires 16-bit mode at the beginning and I'm pretty sure even UEFI does too (but initializes a 64-bit environment fairly quickly).

I hope this is why they are dropping CSM ("legacy boot" or "BIOS boot" mode in UEFI) in a few years. So once the system simply can't boot BIOS OS anymore they can drop some of that old crap modes in the hardware.