# Suspend (S3) with Nvidia: is it possible?



## aragats (Jun 2, 2020)

FreeBSD 12.1 on ThinkStation P500 (Intel Xeon E5-1650 v3 with Nvidia Quadro K2200), suspend works:

```
# acpiconf -s3
```
Resume (by pressing power button) brings the system up without video (tried suspending from both console and X). Everything else is working.
Some time ago people here mentioned that suspend is not possible with Nvidia. Is it still true? Any work-arounds?
Thanks!


----------



## kpedersen (Jun 2, 2020)

A couple of things:

Are you able to switch to a virtual terminal (i.e ctrl-alt-F1) and back again?

Did you build the nvidia-driver port with the power management option enabled? Last time I checked, it isn't the default in the package for some reason.


----------



## aragats (Jun 2, 2020)

kpedersen said:


> Are you able to switch to a virtual terminal (i.e ctrl-alt-F1) and back again?


No, it doesn't work. Even suspending without X brings nothing back on the screen after resume.



kpedersen said:


> Did you build the nvidia-driver port with the power management option enabled?


That's a good point! I didn't enable anything explicitly. Thanks! Will try now.


----------



## aragats (Jun 2, 2020)

kpedersen said:


> Did you build the nvidia-driver port with the power management option enabled?


With that option enabled it won't even come up from suspend after pressing the power button. It stays for a while with blank screen until automatically rebooted.
Another thing to mention is that I'm using nvidia-driver-340, fresher versions don't work with that video card (Quadro K2200) unless I missed something.


----------



## shkhln (Jun 3, 2020)

aragats said:


> Another thing to mention is that I'm using nvidia-driver-340, fresher versions don't work with that video card (Quadro K2200) unless I missed something.



They should, it's listed in supported cards even. In general, legacy drivers are supposed to be used _only_ with the cards dropped from support in later driver versions, which means 340 is for Tesla GPUs and 390 is for Fermi GPUs.


----------



## kpedersen (Jun 3, 2020)

aragats said:


> With that option enabled it won't even come up from suspend after pressing the power button. It stays for a while with blank screen until automatically rebooted.



Ah darn. I was kind of hoping that was going to work. I was interested in how far you got because I have a (similar) Quadro that I was going to look at re-purposing.

I can see our cards supported in the latest driver (440.82) here: https://www.nvidia.co.uk/Download/driverResults.aspx/159388/en-uk

So it should work with the newer port. Perhaps there is something else at play? Is your PSU giving out enough juice? Extra power cable connected, etc?

I notice the Quadro *FX* (i.e Quadro FX 3800) cards need the older 340 driver. Perhaps that is where the mixup came?


----------



## aragats (Jun 4, 2020)

I tried rebuilding the latest version of the driver (440). Something is wrong, it cannot detect any output. Without any xorg.conf graphics starts only on one monitor (out of two), `xrandr` shows only "default" output with a couple of modes. With a config file created by `nvidia-xconfig` Xorg pretends it started, but shows just a block cursor in the top left corner of black screen. The meaningful lines of Xorg.0.log:
	
	



```
....
[   589.620] (II) NVIDIA(0): Creating default Display subsection in Screen section
        "Default Screen Section" for depth/fbbpp 24/32
[   589.620] (==) NVIDIA(0): Depth 24, (==) framebuffer bpp 32
[   589.620] (==) NVIDIA(0): RGB weight 888
[   589.620] (==) NVIDIA(0): Default visual is TrueColor
[   589.620] (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0)
[   589.620] (**) NVIDIA(0): Enabling 2D acceleration
[   589.620] (II) Loading sub module "glxserver_nvidia"
[   589.620] (II) LoadModule: "glxserver_nvidia"
[   589.620] (II) Loading /usr/local/lib/xorg/modules/extensions/libglxserver_nvidia.so
[   589.624] (II) Module glxserver_nvidia: vendor="NVIDIA Corporation"
[   589.624]    compiled for 1.6.99.901, module version = 1.0.0
[   589.624]    Module class: X.Org Server Extension
[   589.624] (II) NVIDIA GLX Module  440.82  Wed Apr  1 19:40:51 UTC 2020
[   589.624] (II) NVIDIA: The X server supports PRIME Render Offload.
[   590.050] (II) NVIDIA(0): NVIDIA GPU Quadro K2200 (GM107GL-A) at PCI:4:0:0 (GPU-0)
[   590.050] (--) NVIDIA(0): Memory: 4194304 kBytes
[   590.050] (--) NVIDIA(0): VideoBIOS: 82.07.79.00.1a
[   590.050] (II) NVIDIA(0): Detected PCI Express Link width: 16X
[   590.050] (II) NVIDIA(0): Validated MetaModes:
[   590.050] (II) NVIDIA(0):     "NULL"
[   590.050] (II) NVIDIA(0): Virtual screen size determined to be 640 x 480
[   590.050] (WW) NVIDIA(0): Unable to get display device for DPI computation.
[   590.050] (==) NVIDIA(0): DPI set to (75, 75); computed from built-in default
....
```
I checked the nvidia-driver-390 too, it behaves the same way, so I suspect something has changed after version 340, and I need to configure it in a special way.


----------



## kpedersen (Jun 4, 2020)

Are you adding the nvidia_load="YES" to the /boot/loader.conf?

Apparently there is now a modeset version, required on newer cards.
I believe you need one or the other. Not both.


```
#nvidia_load="YES"
#or
#nvidia-modeset_load="YES
```

This can also be done in /etc/rc.conf. Again, just the nvidia or the nvidia-modeset, not both.


```
kld_list="nvidia nvidia-modeset"
```

If I recall from a couple of years ago, it the /boot/loader.conf way would work for me but not the /etc/rc.conf or vice versa


----------



## aragats (Jun 4, 2020)

Currently I have in /boot/loader.conf only:
	
	



```
nvidia-modeset_load="YES"
```


----------



## shkhln (Jun 4, 2020)

aragats said:


> Without any xorg.conf graphics starts only on one monitor (out of two)



That's not relevant.



aragats said:


> With a config file created by `nvidia-xconfig` Xorg pretends it started, but shows just a block cursor in the top left corner of black screen.



Can you please disconnect the second display? (Before loading the driver, of course.) Also try switching tty's from and back to X.


----------



## aragats (Jun 5, 2020)

shkhln said:


> Can you please disconnect the second display?


Nothing changed...

I was wrong stating it works without xorg.conf: Xorg just loads VESA driver, that's why it looks working, my bad.
So both 440 and 390 don't work for me, however, Xorg doesn't report any error, it thinks everything is okay, but the screen is black with block cursor in the top left corner.


----------



## shkhln (Jun 5, 2020)

Try `sysctl hw.nvidia.registry.ResmanDebugLevel=0`, then start X, then `dmesg`. Double check that you actually have nvidia-modeset.ko loaded wih `kldstat`.


----------



## aragats (Jun 8, 2020)

Here is what I get with the latest (440) driver:
	
	



```
NVRM: GPU 0000:04:00.0: RmInitAdapter
NVRM: GPU 0000:04:00.0: RmSetupRegisters for 0x10de:0x13ba
NVRM: GPU 0000:04:00.0: pci config info:
NVRM: GPU 0000:04:00.0:    registers look  like: 0xfa000000 0x1000000NVRM: GPU 0000:04:00.0:    fb        looks like: 0xe0000000 0x10000000NVRM: GPU 0000:04:00.0: Successfully mapped framebuffer and registers
NVRM: GPU 0000:04:00.0: final mappings:
NVRM: GPU 0000:04:00.0:     regs: 0xfa000000 0x1000000 0x0xfffff800fa000000
NVRM: nv_acpi_dsm_method: failed to evaluate _DSM method!
NVRM: nv_acpi_dsm_method: failed to evaluate _DSM method!
NVRM: nv_acpi_dsm_method: failed to evaluate _DSM method!
NVRM: nv_acpi_dsm_method: failed to evaluate _DSM method!
NVRM: nv_acpi_dsm_method: failed to evaluate _DSM method!
NVRM: nv_acpi_dsm_method: failed to evaluate _DSM method!
NVRM: nv_acpi_dsm_method: failed to evaluate _DSM method!
NVRM: nv_acpi_dsm_method: failed to evaluate _DSM method!
NVRM: GPU 0000:04:00.0: RM reports GPU is primary VGA
NVRM: GPU 0000:04:00.0:  is primary VGA
NVRM: nv_acpi_dod_method: failed to evaluate _DOD method!
NVRM: PBI is not supported for GPU 0000:04:00.0
NVRM: GPU 0000:04:00.0: RmInitAdapter succeeded!
```
No much difference with the working version 340:
	
	



```
NVRM: RmInitAdapter: 0000:04:00.0
NVRM: RmSetupRegisters for 0x10de:0x13ba
NVRM: pci config info:
NVRM:   registers look  like: 0xfa000000 0x1000000NVRM:   fb        looks like: 0xe0000000 0x10000000NVRM: Successfully mapped framebuffer and registers
NVRM: final mappings:
NVRM:    regs: 0xfa000000 0x1000000 0x0xfffff800fa000000
NVRM: nv_acpi_dsm_method: failed to evaluate _DSM method!
NVRM: nv_acpi_dsm_method: failed to evaluate _DSM method!
NVRM: nv_acpi_dsm_method: failed to evaluate _DSM method!
NVRM: nv_acpi_dsm_method: failed to evaluate _DSM method!
NVRM: nv_acpi_dsm_method: failed to evaluate _DSM method!
NVRM: nv_acpi_dsm_method: failed to evaluate _DSM method!
NVRM: nv_acpi_dsm_method: failed to evaluate _DSM method!
NVRM: nv_acpi_dsm_method: failed to evaluate _DSM method!
NVRM: RM reports 0000:04:00 is primary VGA
NVRM: 0000:04:00.0 is primary VGA: 1
NVRM: nv_acpi_dod_method: failed to evaluate _DOD method!
NVRM: RmInitAdapter succeeded!
```


----------



## shkhln (Jun 9, 2020)

I'm still waiting for the confirmation that nvidia-modeset.ko is loaded.


----------



## aragats (Jun 15, 2020)

I'm sorry for the late reply: this computer is always busy, I cannot reboot it frequently...

shkhln , you're right, nvidia-modeset.ko wasn't loaded, only nvidia.ko, although it was in /boot/loader.conf, now the latest driver is working, thank you for the hint!

However, this doesn't solve the original issue with S3 suspend, still doesn't work, it doesn't come up when resumed: black screen for several minutes, then reboots in normal way.


----------



## shkhln (Jun 16, 2020)

aragats said:


> However, this doesn't solve the original issue with S3 suspend, still doesn't work, it doesn't come up when resumed: black screen for several minutes, then reboots in normal way.



Well, that sucks. I know, from reading the bug tracker issues such as PR 237050, that this functionality works at least for some people. Unfortunately, I have no idea how to debug it.


----------

