Nvidia resume unreliable

Cath O'Deray · Dec 10, 2023

skunk said:
utterly obsolete driver 390

It's not obsolete.

What's a legacy driver? | NVIDIA

NVIDIA GK107GLM (Quadro K1100M)

Ported, but not the latest in the 390.xx series series:

FreeBSD Display Driver – x64 | 390.154 | FreeBSD x64 | NVIDIA

Quadro K1100M is supported.

Ported, but not the latest in the 470.xx series series:

FreeBSD Display Driver – x64 | 470.161.03 | FreeBSD x64 | NVIDIA

Quadro K1100M is not listed as supported.

According to the main legacy page:

the 470.xx driver does support Quadro K1100M.

My 2023 use of an HP ZBook 17 G2 <https://bsd-hardware.info/?computer=2ea77aa55d11&latest&d=FreeBSD> began with attempted use of x11/nvidia-driver (ignoring the fact that K1100M is not listed as supported). Incompatibility was confirmed with an on-screen message during startup.

Then, x11/nvidia-driver-470 (ignoring the mixed messages in NVIDIA-provided documentation). It does work. With vt(4).

Then, x11/nvidia-driver-390 (with K1100M listed as supported). It works, with vt, but far less smoothly in that (at least) there's a crash of plasmashell with every switch away from, then back to, Plasma at ttyv8.

So, I'm back to x11/nvidia-driver-470 with:

reliable wake from sleep.

Code:

% uname -aKU
FreeBSD mowa219-gjp4-zbook-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT #5 main-n266797-0a958aa16fed-dirty: Mon Dec  4 04:49:51 GMT 2023     grahamperrin@mowa219-gjp4-zbook-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1500005 1500005
% pkg iinfo nvidia plasma-workspace
linux-nvidia-libs-470-470.161.03
nvidia-driver-470-470.161.03
nvidia-settings-470.86_1
nvidia-xconfig-525.116.04
plasma5-plasma-workspace-5.27.9.1_2
plasma5-plasma-workspace-wallpapers-5.27.9
% sysctl kern.vty
kern.vty: vt
% grep vt /boot/loader.conf
# kern.vty="sc"
%

freezr · Dec 11, 2023

After all your insights I guess that my issues are related with the laptop lid!

I have the laptop on a stand and I use it as "2nd" monitor, while I usually use an external 24" as main monitor, I also use a USB keyboard.
It looks to me that:

if I suspend the laptop without closing the lid and then I tried to resume it, it doesn't resume;
if I suspend the laptop and then I close the lid, when I reopen the lid the laptop resumes fine.

I checked in the BIOS options and I don't have any voice to modify the lid behavior...

Cath O'Deray · Dec 11, 2023

Thanks!

freezr said:
… laptop on a stand and I use it as "2nd" monitor, while I usually use an external 24" as main monitor, …

How is the external display connected?

Does the one NVIDIA card drive both displays?

smithi · Dec 11, 2023

freezr said:
After all your insights I guess that my issues are related with the laptop lid!

I have the laptop on a stand and I use it as "2nd" monitor, while I usually use an external 24" as main monitor, I also use a USB keyboard.

Ah!

freezr said:
It looks to me that:
if I suspend the laptop without closing the lid and then I tried to resume it, it doesn't resume;

What method would you then normally use to resume, in this circumstance?

freezr said:
if I suspend the laptop and then I close the lid, when I reopen the lid the laptop resumes fine.

What says sysctl -a | grep -iw s3 ?

freezr said:
I checked in the BIOS options and I don't have any voice to modify the lid behavior...

FreeBSD ACPI pays little to no regard to BIOS settings to do with power and most things; it's mostly setup with sysctls.

If you're running with verbose logging you should find clues if it fails to resume, as above.

adding 'hw.acpi.verbose=1' to /etc/sysctl.conf may also help.

freezr · Dec 11, 2023

grahamperrin said:
Thanks!

How is the external display connected?

Does the one NVIDIA card drive both displays?

The second monitor is connected through a Displayport and I manage both monitors with the NVDIA card, actually my laptop doesn't have an integrated Intel GPU.

freezr · Dec 12, 2023

smithi said:
Ah!

What method would you then normally use to resume, in this circumstance?

If the lid was closed then opening the lid resums the laptop, otherwise pressing the power button.

What says sysctl -a | grep -iw s3 ?

It says:

Code:

sysctl -a | grep -iw s3
hw.acpi.suspend_state: S3
hw.acpi.sleep_button_state: S3
hw.acpi.supported_sleep_state: S3 S4 S5

FreeBSD ACPI pays little to no regard to BIOS settings to do with power and most things; it's mostly setup with sysctls.
If you're running with verbose logging you should find clues if it fails to resume, as above.
adding 'hw.acpi.verbose=1' to /etc/sysctl.conf may also help.

Done!

smithi · Dec 12, 2023

freezr said:
If the lid was closed then opening the lid resums the laptop, otherwise pressing the power button.

Ok, that's usual with this setup.

freezr said:

Ok.

freezr said:
Done!

Now you just need to make it fail ... note that the lines in messages file after 'suspend at' and upto the following 'resumed at' have timestamps of the suspend time, although resume is (perhaps days) later, because suspend reporting is saved until resuming - don't be confused, just search for 'suspend|resume' in less().

freezr · Dec 12, 2023

smithi

So yesterday I suspended the laptop with acpiconf -s 3, left the lid opened, left it unplugged overnight; and this morning resumed without a problem pressing the power button.

As I wrote in the opening, this is totally unpredictable!

freezr · Jan 2, 2024

It looks like my laptop can be resumed by suspension only opening the lid, if I suspend it, close the lid and open it again it resumes fine, if I try to resume by pressing the power button the resume fails and screen holds off, afterwards closing and opening the lid is useless.

I guess it is just the way the bios works...

smithi · Jan 2, 2024

freezr said:
It looks like my laptop can be resumed by suspension only opening the lid, if I suspend it, close the lid and open it again it resumes fine,

At least you have a consistent way to suspend and resume!

Does just closing your lid also suspend it? That usually requires setting sysctl hw.acpi.lid_switch_state=S3

I don't use that, just the sleep button (Fn-F4 on Thinkpads) or acpiconf -s3 in scripts, but some like just closing the lid.

freezr said:
if I try to resume by pressing the power button the resume fails and screen holds off, afterwards closing and opening the lid is useless.

I can just 'dab' the power button - not press it for long - but pressing the Fn key (or opening the lid) resumes.

freezr said:
I guess it is just the way the bios works...

More likely the ACPICA code, but let's not go there ;-)

freezr · Jan 2, 2024

smithi said:
Does just closing your lid also suspend it? That usually requires setting sysctl hw.acpi.lid_switch_state=S3

No, it doesn't. I set up XFCE to lock the screen if I close the lid, and to suspend if the laptop is inactive more than two hours.

More likely the ACPICA code, but let's not go there ;-)

Better not!

T-Aoki · Jan 3, 2024

grahamperrin said:
It's not obsolete.

What's a legacy driver? | NVIDIA

NVIDIA GK107GLM (Quadro K1100M)
Ported, but not the latest in the 390.xx series series:

FreeBSD Display Driver – x64 | 390.154 | FreeBSD x64 | NVIDIA

Quadro K1100M is supported.

Ported, but not the latest in the 470.xx series series:

FreeBSD Display Driver – x64 | 470.161.03 | FreeBSD x64 | NVIDIA

Quadro K1100M is not listed as supported.

According to the main legacy page:

the 470.xx driver does support Quadro K1100M.

My 2023 use of an HP ZBook 17 G2 <https://bsd-hardware.info/?computer=2ea77aa55d11&latest&d=FreeBSD> began with attempted use of x11/nvidia-driver (ignoring the fact that K1100M is not listed as supported). Incompatibility was confirmed with an on-screen message during startup.

Then, x11/nvidia-driver-470 (ignoring the mixed messages in NVIDIA-provided documentation). It does work. With vt(4).

Then, x11/nvidia-driver-390 (with K1100M listed as supported). It works, with vt, but far less smoothly in that (at least) there's a crash of plasmashell with every switch away from, then back to, Plasma at ttyv8.

So, I'm back to x11/nvidia-driver-470 with:

reliable wake from sleep.

Code:

% uname -aKU FreeBSD mowa219-gjp4-zbook-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT #5 main-n266797-0a958aa16fed-dirty: Mon Dec 4 04:49:51 GMT 2023 grahamperrin@mowa219-gjp4-zbook-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1500005 1500005 % pkg iinfo nvidia plasma-workspace linux-nvidia-libs-470-470.161.03 nvidia-driver-470-470.161.03 nvidia-settings-470.86_1 nvidia-xconfig-525.116.04 plasma5-plasma-workspace-5.27.9.1_2 plasma5-plasma-workspace-wallpapers-5.27.9 % sysctl kern.vty kern.vty: vt % grep vt /boot/loader.conf # kern.vty="sc" %

Just FYI:
x11/nvidia-driver, which is the master port of x11/nvidia-driver-470 and all other legacy drivers, has the mechanism to override version to support legacy drivers (and can abuse for testing beta and new feature drivers).

By searching nvidia driver page, latest driver for Quadro (notebook) K1100M seems to be 390.157.

Yes, official pkg repo does have supported (in-tree) versions only, but you can try (not assured to build/install fine, though), for example, 390.157, by building it yourself.

I have lines below to ease testing not-yet-in-tree production (sometimes new feature or beta) driver in /etc/make.conf. this also works for x11/linux-nvidia-libs, too. Currently I'm testing 545.29.06.
As non-in-tree versions don't listed in distinfo, NO_CHECKSUM= YES is required.

Beware! You must use configuration below for x11/nvidia-driver and/or x11/linux-nvidia-libs, NOT LEGACY DRIVER DIRECTORY EVEN IF YOU ARE ATTEMPTING TO BUILD LEGACY ONES.
And if you want to use it with graphics/nvidia-drm-*-kmod, YOU CANNOT USE THIS WITHOUT ASSISTANCE BY Austin Shafer, the maintainer of them.
If you are using graphics/nvidia-drm-*-kmod, it must be in sync with x11/nvidia-driver* and distfiles of graphics/nvidia-drm-*-kmod is created by the maintainer himself. Or maybe you could create it by yourself with the procedure Austin discloses at his github repo.

NVIDIA_OVERRIDE_VERSION= 545.29.06

.if ${.CURDIR:M/usr/ports/x11/nvidia-driver} && defined (NVIDIA_OVERRIDE_VERSION)
  DISTVERSION=    ${NVIDIA_OVERRIDE_VERSION}
  NO_CHECKSUM=    YES
.endif

.if ${.CURDIR:M/usr/ports/x11/linux-nvidia-libs} && defined (NVIDIA_OVERRIDE_VERSION)
  DISTVERSION=    ${NVIDIA_OVERRIDE_VERSION}
  NO_CHECKSUM=    YES
.endif

Nvidia resume unreliable

Have you found suspend from terminal more reliable?

Yes, not a problem! 👍

No it isn't, no resume after suspend! 👎

Regardless if it does work or not, I've never suspended! 🫵

Cath O'Deray

NVIDIA GK107GLM (Quadro K1100M)

freezr

Cath O'Deray

smithi

freezr

freezr

smithi

freezr

freezr

smithi

freezr

T-Aoki

NVIDIA GK107GLM (Quadro K1100M)

Nvidia resume unreliable

Have you found suspend from terminal more reliable?

Yes, not a problem! 👍

No it isn't, no resume after suspend! 👎

Regardless if it does work or not, I've never suspended! 🫵

NVIDIA GK107GLM (Quadro K1100M)​

NVIDIA GK107GLM (Quadro K1100M)​

NVIDIA GK107GLM (Quadro K1100M)

NVIDIA GK107GLM (Quadro K1100M)