Nvidia resume unreliable

Have you found suspend from terminal more reliable?

  • Yes, not a problem! 👍

    Votes: 0 0.0%

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

    Votes: 1 20.0%

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

    Votes: 4 80.0%
  • Total voters
    5
  • Poll closed .
skunk said:
utterly obsolete driver 390
Click to expand...

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"
%
 
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:
  1. if I suspend the laptop without closing the lid and then I tried to resume it, it doesn't resume;
  2. 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... ?‍♂️
 
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.
Click to expand...

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;
Click to expand...

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.
Click to expand...

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... ?‍♂️
Click to expand...

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.
 
smithi said:
Ah!
Click to expand...

?

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

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

What says sysctl -a | grep -iw s3 ?
Click to expand...

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.
Click to expand...

Done! ?
 
freezr said:
If the lid was closed then opening the lid resums the laptop, otherwise pressing the power button.
Click to expand...

Ok, that's usual with this setup.

freezr said:
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
Click to expand...

Ok.

freezr said:
Done! ?
Click to expand...

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().
 
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! ?‍?
 
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... ?
 
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,
Click to expand...

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.
Click to expand...

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... ?
Click to expand...

More likely the ACPICA code, but let's not go there ;-)
 
smithi said:
Does just closing your lid also suspend it? That usually requires setting sysctl hw.acpi.lid_switch_state=S3
Click to expand...

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 ;-)
Click to expand...

Better not! ?
 
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"
%
Click to expand...
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
 
You must log in or register to reply here.
Back
Top