Some pragmatic issues with Linux kernel mode setting on servers

July 24, 2022

Modern Linux kernels want to do kernel mode setting (KMS). One of the consequences of KMS is that the 'text' console goes through modesetting during boot. On desktops, you don't usually use a text console and KMS is necessary anyway for your graphical desktop; if modesetting is broken, you won't get far. On servers the benefits are lower and the downsides larger; with KMS enabled, modesetting must work in order for you to have any text console. Lately, I've come to feel that there are some pragmatic issues that make KMS more problematic on servers than you might think.

The first issue is that servers usually use old or eccentric graphics chipsets, ones that aren't used by desktops. Many of our servers have Matrox chipsets, while others use ASPEED chipsets (which I believe are effectively virtualized graphics which go through the system's BMC). Today, these chipsets are more or less exclusive to servers, and specific sorts of servers at that, which makes it harder to test changes to the various graphics drivers. Plus, if you want to be able to test various generations of these chipsets, you can't just keep around graphics cards; you have to keep around entire servers.

The second issue is that people running servers often don't use the latest and greatest Linux kernels; instead, my impression is that they mostly use distribution kernels and often use slow moving distributions. Certainly this is what we do (with Ubuntu LTS). This means that if a server chipset graphics driver has buggy modesetting (as seems to have happened with some Matrox chipsets), it may some time before people with servers that have that chipsets start using a kernel with the buggy driver.

These two issues combine to significantly lower the pool of people testing driver changes for server chipsets, compared to the number of people testing driver changes on desktop chipsets. This makes changes to those drivers more dangerous, and increases the chances that they'll have as yet undetected modesetting bugs when you try to use them.

On most servers, you have little need for accelerated graphics and the other things that require KMS as a base. You can almost always assume that the BIOS has left the server's graphics chipset set up in some working mode, even if it's not ideal for the LCD panel you may have attached, so the safest thing to do is to not try to change that mode and just to use it. For old fashioned BIOS boot, I believe this will leave you in a VGA text mode; with UEFI boot, this may leave you in some framebuffer mode that the kernel has to read out the details of.

(Today, you get this with the 'nomodeset' kernel parameter, although that may have other effects. Exactly what effects 'nomodeset' really has may change over time and between Linux distributions, cf.)

Written on 24 July 2022.
« The state of getting per-pool IO statistics in ZFS on Linux as of version 2.1
ZFS pool IO statistics (and vdev statistics) are based on physical disk IO »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jul 24 23:27:09 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.