LPAE was enabled to support native armv7l builders running in QEMU on aarch64,
but this option disables support for processors which don't support LPAE, which
are still relatively common. In particular, Beaglebones use the Cortex-A8, which
doesn't support LPAE.
Also, if you attempt to boot an LPAE kernel on a CPU that doesn't support it,
it fails before even earlycon is initialized. This makes the problem difficult
to debug without enabling CONFIG_DEBUG_LL or using a hardware debugger.
This option allows to use portions of the system RAM as block devices.
It was configured to 'y' (built-in, therefore not unloadable or
reconfigurable) and configured 16 4MB RAM disks which, to my knowledge,
currently have no purpose in NixOS.
Removing the option restores it to it's default value of 'm', which
enables it to be loaded at runtime (which is also required to be able to
change it's configuration without rebuilding the kernel).
Nixpkgs hasn't supported grsecurity kernels since 2017, so unless
anybody is manually enabling the grsecurity feature to make these
small kernel tweaks this is dead code.
This means we don't actually support any "features" in the kernel
common-config any more, but I've left the argument there because it's
conceivable we could have some again in future.
I don't think there's any reason to have a seperate kernel variant
because of this, with all the maintenance burden that imposes. Debian
and Fedora both enable all these options on their normal kernels.
Alias the Linux Xen attributes, so this change should be seemless for
people who were using the Xen kernels up to now.
All the Xen options are marked as optional anyway, so it should be
fine to try to enable them on non-x86 platforms as well.
Fixes: https://github.com/NixOS/nixpkgs/issues/115182
The parent commit forbids conflicting kernel config options.
Fix the hardened kernels by allowing options in common-config.nix to
be overridden by conflicting ones in hardened/config.nix.
I'm explicitly avoiding using a higher priority (e.g. using mkForce)
in hardened/config.nix so that the user can easily override the
options in that file.
Since 2020, Mesa requires the kcmp() system call to be available for
some of its functionality. At the moment, this system call is enabled
when CHECKPOINT_RESTORE is enabled in the Linux kernel. This option is
also enabled by default in Fedora and Debian.
This patch enables CHECKPOINT_RESTORE by default on all kernel
versions where it is not marked as EXPERT, i.e. everything after and
including 4.19.
Fixes#112082.
The kernel config parameter `DRM_AMD_DC_DCN3_0` is required to enable
the RX 6000 series GPUs, and is supported on kernels at least `5.9.12`.
Source: https://wiki.gentoo.org/wiki/AMDGPU#Installation
Starting from Linx 5.6, there is partial upstream support for the Multipath TCP
protocol. There are no downsides to enabling it afaict, since
applications need to opt-in when creating a socket.
From https://github.com/multipath-tcp/mptcp_net-next/wiki:
"[...] users of regular TCP continue to get the same type of connection and
performance unless MPTCP is requested."
As per the in-line comment, this is where distros should configure it.
Not via kernel command line parameters.
As found by looking at the implementation, while exploring the cause of
a bug on the Raspberry Pi 4, it was found that `cma=` on the command
line parameters will overwrite the values a device tree will have
configured for a given platform.
With this, the more recent 5.4 vendor kernel boots just fine on the
Raspberry Pi 4 using our common configuration.
Without this, the kernel would generate a random one for us which obviously
isn't reproducible.
`nix-build -A linux --check` succeeds now!
(Tested at different times with different kernel)
