Building patched 4.19 kernel fails cryptically

Help
1

I run NixOS on my Surface Pro 5, which requires several kernel patches to get the touch screen and battery readings, among other things, to work properly. I apply these patches using the relevant NixOS configuration options, which amounts to overriding linux_4_19 with extraConfig and setting boot.kernelPatches. Here’s the related portions of my config, although I don’t think the problem results from this:

{ config, pkgs, options, ... }:
{
  nixpkgs = {
    overlays = [
      (self: super: {
        linux_4_19 = super.linux_4_19.override {
          extraConfig = ''
            SERIAL_DEV_BUS y
            SERIAL_DEV_CTRL_TTYPORT y
            SURFACE_SAM y
            SURFACE_SAM_SSH m
            SURFACE_SAM_SAN m
            SURFACE_SAM_VHF m
            SURFACE_SAM_DTX m
            SURFACE_SAM_SID n
            INPUT_SOC_BUTTON_ARRAY m
            INTEL_IPTS m
            INTEL_IPTS_SURFACE m
            MWLWIFI n
          '';
          # ignoreConfigErrors = true;
        };
      })
    ];
  };
  boot = {
    kernelPackages = pkgs.linuxPackages_4_19;
    kernelPatches = [
      {
        name = "surface-acpi";
        patch = ./pkgs/linux/patches/4.19/0001-surface-acpi.patch;
      }
      {
        name = "surface-suspend";
        patch = ./pkgs/linux/patches/4.19/0002-suspend.patch;
      }
      {
        name = "surface-buttons";
        patch = ./pkgs/linux/patches/4.19/0003-buttons.patch;
      }
      {
        name = "surface-cameras";
        patch = ./pkgs/linux/patches/4.19/0004-cameras.patch;
      }
      {
        name = "surface-ipts";
        patch = ./pkgs/linux/patches/4.19/0005-ipts.patch;
      }
      {
        name = "surface-hid";
        patch = ./pkgs/linux/patches/4.19/0006-hid.patch;
      }
      {
        name = "surface-sd";
        patch = ./pkgs/linux/patches/4.19/0007-sdcard-reader.patch;
      }
      {
        name = "surface-wifi";
        patch = ./pkgs/linux/patches/4.19/0008-wifi.patch;
      }
      {
        name = "surface-mwlwifi";
        patch = ./pkgs/linux/patches/4.19/0010-mwlwifi.patch;
      }
    ];
    # extraModulePackages = [ pkgs.mwlwifi ]; # not sure of diff between this and hw.fw
    kernelModules = [ "hid" "hid_sensor_hub" "hid_generic" "usbhid" "hid_multitouch" "intel_ipts" ]; # surface_acpi not in lsmod?
  };

Sorry I don’t have a GitHub repo yet, I have to figure out how to deal with secrets properly.

I’m currently on 4.19.74, which works fine, and a bunch of previous versions compiled with these options as well. The latest version is not compiling due to varying gcc errors that ask me to “Please submit a full bug report” followed by make errors (presumably caused by the gcc errors). Most recently, it was in ../drivers/net/ethernet/cisco/enic/vnic_devcmd.h, and in general, never have the gcc errors seemed tied to my patches or config in any way. This has happened for .78, .79, and .80.

How can I try to resolve this? Thanks!

1 Like
2

For those who come across this from searching the internet, I figured it would be good to provide an update. I’m up to the latest 4.19 patch (95?), and all I’ve figured out is that building the kernel seems very nondeterministic. I’ve had it succeed right after a make error in some Infiniband driver having made no changes in between builds. Not sure if this is due to the kernel build system, NixOS’s additions, or something with my machine, but I’m still managing to keep things up to date when I get the time for now. I hope to make my configs public on GitHub soon.

5.4 is the next LTS kernel, but I need to get the new reverse-engineered IPTS module working before I can upgrade to that. I might not have time for that until this summer, unfortunately.

1 Like
3

I wonder if you’re running out of memory during the build? Maybe try --cores 1 to see if you’re just ending up with too many GCC’s running at once?

4

hard to say without the actual errors. extraConfig can require several tries as enabling an option there doesn’t guarantuee it wont be overriden by some other kernel build system constraints.

5

I use -j 1 with nixos-rebuild so I can at least tell what package is failing; how do I pass in the gcc argument through nixos-rebuild?

6

Usually it’s a make: error 2 or something like that. Next time it happens I’ll post it here. I think extraConfig is working fine, because the kernel config has to successfully build before the kernel itself, and it always has. Beyond that, the failures in building the kernel are always (I think) completely unrelated to anything near the patches I’m applying.

7

-j and --cores are different. -j means --max-jobs, which is the number of derivations to build in parallel. --cores is the max number of threads to allow each derivation to use. If you set it to 0 (I forget the default), each derivation may use up to all your cores (except make-based derivations will be limited by loadavg), which may run out of memory for some builds.

8

I just started re-checking the google results for “nixos surface”.
There’s been some work done on getting this working, see the nixos mention at Installation and Setup · linux-surface/linux-surface Wiki · GitHub , and come join us at freenode/##linux-surface.

9

Just wanted to respond for posterity, in case anyone else finds this when searching for NixOS Surface info. Thanks ElvishJerricco, I wouldn’t be surprised if memory was the cause of the kernel building issue. Anyway, I ended up overhauling my configs for patching the kernel and setting up a remote builder with big-parallel, which eased the process significantly. I posted an update to nixos-hardware.