Suspend (S3) with Nvidia: is it possible?

FreeBSD 12.1 on ThinkStation P500 (Intel Xeon E5-1650 v3 with Nvidia Quadro K2200), suspend works:
Code:
# 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!
 
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.
 
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.
 
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.
 
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?
 
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:
Code:
....
[   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.
 
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.

Code:
#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.

Code:
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
 
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.
 
Try sysctl hw.nvidia.registry.ResmanDebugLevel=0, then start X, then dmesg. Double check that you actually have nvidia-modeset.ko loaded wih kldstat.
 
Here is what I get with the latest (440) driver:
Code:
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:
Code:
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!
 
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.
 
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.
 
Back
Top