Nvidia error GTX 1050 on Dell XPS 15 (9650) laptop

Help
1

Hey folks, I’m having the following problem with trying to run an nvidia session. This occurs during boot and never shows the greeter menu.

IMG20230707083317
IMG202307070833171920×1440 308 KB 

NVRM: installed in this system is not supported by open
NVRM: nvidia.ko because it does not include the required GPU NVRM: System Processor (GSP).
NVRM: Please see the 'Open Linux Kernel Modules' and 'GSP NVRM: Firmware' sections in the driver README, available on NVRM: the Linux graphics driver download page at
NVRM: www.nvidia.com.

My nvidia config is:

{ config, lib, pkgs, ... }:

{
  nixpkgs.config.allowUnfreePredicate = pkg:
    builtins.elem (lib.getName pkg) [
      "nvidia-x11"
    ];

  services.xserver.videoDrivers = [ "nvidia" ];

  hardware.nvidia = {
    modesetting.enable = true;
    open = true;
    nvidiaSettings = true;
    package = config.boot.kernelPackages.nvidiaPackages.stable;
  };
}
2

Have you tried the nixos-hardware module for your laptop? https://github.com/NixOS/nixos-hardware/tree/master/dell/xps/15-9560

The main module seems to use bumblebee to manage offload, may be worth updating the module to prime as well (someone already did that for the nvidia-only module), but it should work for now.

3

Oh, spotted that just now. The open driver is not exactly ready for everyday use, and I doubt it will ever be made to work with such an old card.

1 Like
4

You know, I haven’t tried this hardware module. It was working pretty well w/o that. I might see what’s in that repo and apply things I’m missing

5

Even if you don’t need it, it’s worth using and then contributing to to help others with your laptop :slight_smile:

1 Like
6

You were right, open was the issue.

That hardware module uses bumblebee (which is deprecated). Are you recommending migrating it away from that?

7

Yes, I’d suggest doing that. Afaict, the module in the nvidia folder has already migrated to it, and no longer does what it says it does in the readme (which is to enable only the nvidia gpu).

All that should need to be done is to move the common/gpu/nvidia import up to the main default.nix, removing the bumblebee config, and adding the hardware.prime.nvidia settings into the main default.nix instead.

Then give it a quick test to see if the intel driver still needs to be explicitly added, which I don’t believe it does, nor does the nvidia driver, but I don’t actually have a multi-gpu system to test these things with.

I’m not sure what to do about the nvidia folder, it doesn’t do what it advertises, and it should probably be deprecated once the main module uses prime because that’s what it in fact does. However, people probably imported it thinking it disables the intel gpu, so maybe we should make it actually do that instead?

Raising an issue about it is probably prudent, but for an initial PR I’d just make it imports = [../.] with a deprecation warning (similar to what I did with the nvidia-disable module). People who want just the nvidia driver can then come out of the woodworks and actually fix the broken module they’ve been using.

I can also just do these things and ask you to test if you like :slight_smile:

8

Let me give it a shot and I’ll shoot it by you

9

OK, some questions:

  • I don’t see the hardware.bluetooth.enable enabled by default. Shouldn’t it be? Or is that left up to the user?
  • Similarly, why wouldn’t hardware.opengl be enabled?
  • Why move the prime to the top? Shouldn’t it be in nvidia since it’s relevant only for that?
  • Other than me running this for a while, what ways can I test this config?
10

Arguable. Personally I think the profiles should set up all the hardware the device provides, but bluetooth is pointed out explicitly as “opinionated”. Take it up with upstream.

For this particular patch I’d suggest keeping it to only fixing the nvidia mess, if you want to clean up the profile so it provides a wider configuration for that laptop that’d be cool of course, but more appropriate as a separate patch.

Good question! From its description:

It is enabled by default by the corresponding modules, so you do not usually have to set it yourself, only if there is no module for your wayland compositor of choice. See services.xserver.enable and programs.sway.enable.

So seems to me like the only situation in which it won’t be enabled already is when the user wants tty-only use, or if they do something very bespoke, in which case it’s probably best left to them anyway.

I think you misunderstand the structure a bit.

The way the directory is structured, you’re supposed to import exactly one of the three modules, each providing a different GPU setup.

Right now these are the options:

  • 15-9560/default.nix (intel + nvidia GPU, using the deprecated bumblebee)
  • 15-9560/intel/default.nix (only intel GPU)
  • 15-9560/nvidia/default.nix (intel + nvidia GPU, using prime)

Reading the readme, the intention appears to have been:

  • 15-9560/default.nix (intel + nvidia GPU, using prime)
  • 15-9560/intel/default.nix (only intel GPU)
  • 15-9560/nvidia/default.nix (only nvidia GPU)

So, in an ideal world, the prime config should be at the top, some intel GPU config should be in intel/default.nix, as well as an import of the nvidia disable module, and some (very different, without prime) nvidia GPU config should be in nvidia/default.nix, as well as some blacklisting of the intel GPU driver.

In practice, we cannot do this, because someone else - just like you - interpreted the nvidia folder as “here goes nvidia config” and updated it to provide prime, and now people have clearly started using it as the module that contains the intel + nvidia config, contrary to what the documentation and in fact in-code comments say.

Some will have done so unknowingly, and believe that the nvidia GPU has been turned off. Some will have done so knowingly, and would be confused if suddenly the nvidia+intel config turned into a just-nvidia config.

For this reason, I believe it would be best to deprecate the nvidia folder, so that those who are using it realize that there has been a huge mistake and that their config might not be doing what they think it is.

Once people who thought they were using an nvidia-only system realize the mistake, they can create a new folder with a less confusing name for their nvidia-only config.

As an aside, I think this is all horrible, people shouldn’t be providing multiple different modules that all do the same thing except for different GPUs being turned on/off. It’s awful for code ergonomics, confusing for new and old users alike, and results in these awkward misunderstandings where whole modules suddenly behave differently.

This appears to unfortunately have been cargo culted all over the repository though. I think if we really wanted to fix this, we should introduce a new option that allows flipping on/off specific GPUs. This could likely be provided at the common level, and save each specific profile the effort of writing 4+ modules just for en-/disabling specific GPUs (the “please don’t give me any GPUs at all” module is missing here).

I’ll probably see about introducing such an option separately. For now, it would be cool to fix the trainwreck around this laptop since someone who actually owns one has their eyes on it :slight_smile:

Since this is about testing configurations for specific hardware, there’s not much else you can do.

Since this is nvidia config, ideally you would confirm that none of these break (and confirm they worked on bumblebee, if they don’t at least it’s not a regression):

  • Starting an xorg WM/DE, running firefox and watching some video through it, ideally confirming hardware acceleration words
  • Starting a wayland WM/DE, and doing the same
  • Running some game through proton under both graphical sessions

This would be a lot of effort though. I don’t think these modules see enough maintenance that such strict testing is expected or required.

Make the change, raise the PR, ping people who have previously contributed to it in your PR, and then run it on your machine for a while to check for any fires. That will likely be enough.

12

OK, need some noob help:

I’m initializing nvidia only, but the i915 driver is loading. If I go into nix repl, I can see:

nix-repl> outputs.nixosConfigurations.xps15.config.boot.kernelParams
[ "nohibernate" "loglevel=4" ]
nix-repl> outputs.nixosConfigurations.xps15.config.boot.blacklistedKernelModules
[ "usblp" "nouveau" "nvidiafb" ]

However, in my branch of the nixos-hardware, I am calling:

  imports = [
    ../../../../common/gpu/nvidia
    ../../../../common/gpu/intel/disable.nix
    ../xps-common.nix
  ];

which should be setting (via nixos-hardware/common/gpu/intel/disable.nix):

  boot.blacklistedKernelModules = lib.mkDefault [ "i915" ];
  boot.kernelParams = lib.mkDefault [ "i915.modeset=0" ];

In my configuration.nix -> hardware-configuration.nix, there is this:

  boot.kernelModules = [ ];

Does this reset things?

I’m initializing like this:

      nixosConfigurations = {
        xps15 = nixpkgs-unstable.lib.nixosSystem {
          specialArgs = { inherit inputs outputs self; }; # Pass flake inputs to our config
          system = "x86_64-linux";
          modules = [
            # > Our main nixos configuration file <
            ./hosts/xps15/configuration.nix
            nixos-hardware-test.outputs.nixosModules.dell-xps-15-9560-nvidia
            home-manager.nixosModules.home-manager
            {
              home-manager = {
                extraSpecialArgs = { inherit inputs outputs; };
                users = {
                  mcrowe = import ./home-manager;
                };
              };
            }
          ];
        };
      };
    };