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 .
smithi said:
Working suspend/resume is still comparatively rare
Click to expand...
No, it is not.

Just make sure you avoid the most common resume blockers:
1. vt console breaks resume for nvidia (you must use sc console)
2. make sure vesa.ko is not loaded (if necessary, build kernel without options VESA)
3. stop running virtualbox VMs before suspending
4. avoid using dysfunctional DE menu sleep functions, instead directly call acpiconf -s 3
 
How can I trace the next resume failure?

I am pretty sure if I left the computer in suspend for entire night the day after it won't resume!
 
skunk said:
No, it is not.

Just make sure you avoid the most common resume blockers:
1. vt console breaks resume for nvidia (you must use sc console)
2. make sure vesa.ko is not loaded (if necessary, build kernel without options VESA)
3. stop running virtualbox VMs before suspending
4. avoid using dysfunctional DE menu sleep functions, instead directly call acpiconf -s 3
Click to expand...

How can I understand if I am using VT or a SC? ?‍♂️

At least VESA module is not running:
Code: 
kldstat | grep vesa
>
 
Try adding vbe_max_resolution="1080p" to /boot/loader.conf, my desktop computer cannot resume with NVIDIA driver, and TTY access is broken too, but with that setting, everything works fine, suspend resume too. vt console doesnot work with NVIDIA cards. See it helps.
 
freezr

syscons(4), often referred to as sc, is the legacy console driver. The type of console that someone (not you) might see after boot, before appearance of a login manager or a desktop environment. Its manual page:
The word NVIDIA, sometimes written as Nvidia or nvidia, has multiple meanings, especially when written lowercase without context. Confusion is commonplace.

Reference​

The text below is slightly adapted from a past revision of a graphics page in the FreeBSD wiki (removed, not by me). To avoid issues with quoting in XenForo, I'll use two lines to indicate the end of the quote. Adaptation:
  • the two commands at the end are slightly improved, to allow for the many situations in which misunderstandings have occurred.
Quote

Five drivers are ported and packaged:
The number of available ports, and the related links, will vary.

NVIDIA-provided pages:
  • list supported products (users can learn which driver to choose)
  • offer downloads for source code (not package-oriented).
Most users will prefer a package.

For versions prior to 358.09:

sysrc -f /etc/rc.conf kld_list-=nvidia-modeset && sysrc kld_list+=nvidia

For superior versions:

sysrc -f /etc/rc.conf kld_list-=nvidia && sysrc kld_list+=nvidia-modeset


freezr at the NVIDIA page for 535.104.05, you will find your (NVIDIA) GeForce GTX 970M listed as supported.

freezr said:
…

Code: 
% pkg iinfo nvidia
nvidia-driver-535.104.05_1
nvidia-settings-470.86_1
nvidia-xconfig-525.116.04

…
Click to expand...

grahamperrin said:
I do use vt(4) with NVIDIA. Without breakage.

I can't find relevant information in the FreeBSD Handbook.
Click to expand...

Found, elsewhere. From Newcons - FreeBSD Wiki:

vt(4) is the virtual terminal console driver implementation (also known as the "Newcons" project) which replaces syscons(4), …
Click to expand...

Most relevant:
  • syscons does not have kernel modesetting integration.

From the DESCRIPTION of the manual page for vt(4):

… Integration with KMS (Kernel Mode Setting) video drivers for switching between the X Window System and virtual terminals. …
Click to expand...

freezr in your case:
  • the nvidia-modeset kernel module is correct
  • vt(4) is correct
  • the nvidia kernel module would be inappropriate
  • syscons(4) would be inappropriate.
freezr said:
How can I understand if I am using VT or a SC? ?‍♂️
Click to expand...

If you have done nothing to attempt use of syscons(4) in lieu of vt(4): FreeBSD will use vt.


Caution

Improper use of sc can cause boot failure, with single user mode unusable.
 
x11/nvidia-driver-390

In #freebsd-bugs in IRC I wrote:

x11/nvidia-driver-390 might be slightly outdated, <https://www.nvidia.com/Download/driverResults.aspx/196217/en-us/> has no release highlight.
Click to expand...

I do not imagine any change affecting sleep/wake.


x11/nvidia-driver-470

x11/nvidia-driver-470 is outdated by <https://www.nvidia.com/Download/driverResults.aspx/215843/en-us/>, I doubt that danfe@ will need a report
Click to expand...

I use x11/nvidia-driver-470. I do not imagine any change affecting sleep/wake.


x11/nvidia-driver

275569 – x11/nvidia-driver, x11/linux-nvidia-libs: update to 535.146.02

bugs.freebsd.org bugs.freebsd.org

This will benefit opening poster freezr, although I do not imagine any change affecting sleep/wake.

freezr said:
nvidia-driver-535.104.05_1
Click to expand...

275569 is broadened by ashafer to include the distinfo update for:
The related meta port:

273311 – graphics/nvidia-drm-kmod (meta port): improve the COMMENT line of the Makefile, and the package description

bugs.freebsd.org bugs.freebsd.org
 
freezr said:
smithi

Resume did not survived the overnight.
This morning when I woke up the computer all the LED on, including the keyboard, no screen, no sign of any disk activity. Before to wake up the laptop I plugged in the power supply.
Click to expand...

Hang on ... do you mean that while suspended overnight, the power supply had not been connected? If so, are you sure it didn't just run down battery?

freezr said:
It looks like after a couple hours it goes in deep sleep and then it is unable to resume.
Well I don't know actually... ?
Click to expand...

Unless there's an actual hardware fault, such as RAM refresh failing while suspended, I'm not aware of any way it could go into 'deeper' sleep.

OTOH, I've never had Nvidia graphics, so I can't say that mightn't affect things.

Generally speaking, once it finishes suspending, you can wake it up any time between immediately and as long as there's still power, with no expected difference.

Graham seems all over your particular hardware; I'd tend to listen to him before some of the wilder theories floating around.

The fact remains that some combinations of hardware and system software including BIOS, graphic cards and drivers lend themselves to reliable suspend / resume, possibly needing sysctl tweaks even then.
 
freezr said:
How can I understand if I am using VT or a SC? ?‍♂️
Click to expand...

sysctl kern.vty will be 'vt' or 'sc'

If 'vt', sysctl kern.vt lists all options. sysctl -d kern.vt for descriptions.

Hmm, what's your
sysctl kern.vt.suspendswitch ?

freezr said:
At least VESA module is not running:
Code: 
kldstat | grep vesa
>
Click to expand...

Try with kldstat -v | grep vesa to check if it's built into kernel rather than deliberately loaded. Not likely your problem, though, as it's in GENERIC.
 
grahamperrin said:
That's generally untrue.
Click to expand...
I haven't followed the development since I conversated with Ed Maste about that topic almost two years ago.
Possibly there has been some progress since.

grahamperrin said:
For versions prior to 358.09:
[...]
  • the nvidia-modeset kernel module is correct
  • vt(4) is correct


Improper use of sc can cause boot failure, with single user mode unusable.
Click to expand...
1. Versions prior to 390 are broken and dysfunctional anyway due to xorg ABI changes.
2. so the nvidia-modeset is the recommended method for all remaining working proprietary drivers
3. vt is correct for UEFI computers, as sc does not support graphic console without extra configuration

If you experience the "colored blocks phenomenon" when switching from xorg to console, this is caused by vt being buggy.
No idea whether this already got fixed, maybe this issue no longer exists by now.
Anyway if you have the "colored blocks phenomenon", you can fix the issue by using sc instead vt console.

smithi said:
Try with kldstat -v | grep vesa to check if it's built into kernel rather than deliberately loaded. Not likely your problem, though, as it's in GENERIC.
Click to expand...
One result of my discussion with Ed Maste was that vesa.ko no longer is part of GENERIC. Not sure though from which release/patchlevel on it has been taken away from GENERIC.
 
smithi said:
Try with kldstat -v | grep vesa to check if it's built into kernel rather than deliberately loaded. Not likely your problem, though, as it's in GENERIC.
Click to expand...
skunk said:
One result of my discussion with Ed Maste was that vesa.ko no longer is part of GENERIC. Not sure though from which release/patchlevel on it has been taken away from GENERIC.
Click to expand...

Fair call; that was from a 12.4 system. At least OP may know about kldstat -v now ...
 
Thanks,

skunk said:
Versions prior to 390
Click to expand...

<https://forums.freebsd.org/posts/632795> above specifies the nvidia module for versions prior to 358.09.

github.com

x11/nvidia-driver: reword the pkg-message to reflect modern reality · freebsd/freebsd-ports@a09185f

Try to reduce readers' confusion by specifying exactly which nVidia kernel module users should be loading these days. PR: 269626
github.com github.com

Background:

269626 – FreeBSD Handbook: NVIDIA: corrections

bugs.freebsd.org bugs.freebsd.org

269626 puts 358.09 in context.

Also:

github.com

Nvidia fixes by shkhln · Pull Request #114 · freebsd/freebsd-doc

304, 340, 390 are out of support: https://nvidia.custhelp.com/app/answers/detail/a_id/3142/~/support-timeframes-for-unix-legacy-gpu-releases. In addition to that 304 and 340 are also completely bro...
github.com github.com

Amongst the closures that were associated with my resignation:

github.com

The X Window System: … NVIDIA: corrections, update by grahamperrin · Pull Request #122 · freebsd/freebsd-doc

kld_list is to load modules, not drivers. rc.conf(5) Updated URLs taken from https://wiki.freebsd.org/Graphics#NVIDIA_graphics.
github.com github.com
 
skunk said:
… If you experience the "colored blocks phenomenon" when switching from xorg to console, this is caused by vt being buggy.

No idea whether this already got fixed, maybe this issue no longer exists by now. …
Click to expand...

Anyone: was there a report in Bugzilla? A report number will help to end uncertainties.

I did encounter the symptom years ago (with PC-BSD, if I recall correctly), not encountered by me in recent years.

github.com

History for sys/dev/vt - freebsd/freebsd-src

The FreeBSD src tree publish-only repository. Experimenting with 'simple' pull requests.... - History for sys/dev/vt - freebsd/freebsd-src
github.com github.com

<https://cgit.freebsd.org/src/log/sys/dev/vt>
 
grahamperrin said:
<https://forums.freebsd.org/posts/632795> above specifies the nvidia module for versions prior to 358.09.

github.com

x11/nvidia-driver: reword the pkg-message to reflect modern reality · freebsd/freebsd-ports@a09185f

Try to reduce readers' confusion by specifying exactly which nVidia kernel module users should be loading these days. PR: 269626
github.com github.com

Background:

269626 – FreeBSD Handbook: NVIDIA: corrections

bugs.freebsd.org bugs.freebsd.org
Click to expand...
Thanks.
I'll try soon with a 340 graphics card whether IgnoreABI works.
With 304, this does not work.
 
smithi

Hang on ... do you mean that while suspended overnight, the power supply had not been connected? If so, are you sure it didn't just run down battery?
Click to expand...

Because the mouse attached was still glowing, when I resumed I plugged the power supply before.

grahamperrin

I believe I manually added vt as console as it written in the handbook somewhere.

Code: 
at /boot/loader.conf
aesni_load="YES"
geom_eli_load="YES"
security.bsd.allow_destructive_dtrace=0
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
cryptodev_load="YES"
zfs_load="YES"

# Custom
kern.vty=vt
cuse_load="YES"
#geom_md_load="YES"
cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"

# Sound
mixer_enable="YES"

and…

Code: 
sysctl -d kern.vt
kern.vt: vt(9) parameters
kern.vt.splash_cpu_duration: Hide logos after (seconds)
kern.vt.splash_cpu_style: Draw logo style (0 = Alternate beastie, 1 = Beastie, 2 = Orb)
kern.vt.splash_ncpu: Override number of logos displayed (0 = do not override)
kern.vt.splash_cpu: Show logo CPUs during boot
kern.vt.kbd_panic: Enable request to panic.  See kbdmap(5) to configure.
kern.vt.kbd_debug: Enable key combination to enter debugger.  See kbdmap(5) to configure (typically Ctrl-Alt-Esc).
kern.vt.kbd_reboot: Enable reboot keyboard combination.  See kbdmap(5) to configure (typically Ctrl-Alt-Delete).
kern.vt.kbd_poweroff: Enable Power Off keyboard combination.  See kbdmap(5) to configure.
kern.vt.kbd_halt: Enable halt keyboard combination.  See kbdmap(5) to configure.
kern.vt.suspendswitch: Switch to VT0 before suspend
kern.vt.deadtimer: Time to wait busy process in VT_PROCESS mode
kern.vt.debug: vt(9) debug level
kern.vt.enable_bell: Enable bell
kern.vt.enable_altgr: Enable AltGr key (Do not assume R.Alt as Alt)
 
freezr said:
With zzz two in a row without issues... ?‍♂️
Click to expand...

Ok, to see if zzz (which runs acpiconf -s3) does anything different from using your WM | DE functions:

When booting, enable the verbose boot option - or add boot_verbose="YES" to /boot/loader.conf to always boot verbosely. This adds a fair bit of extra logging to /var/log/messages, handy while debugging.

Then suspend and resume a time or two. Search messages for 'suspend|resume' in less (ono), and save the segment/s.

Repeat using other method/s. Compare. Any differences?

If you do get any failures to resume, chances are you'll get some helpful clues in the messages file about it.

sysctl kern.vt.suspendswitch= ?
 
I'll get someone from NVIDIA to comment, if they can.

We seem to have significant contraditions.

angry_vincent please note, from <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216050#c22> (2023-10-24, the most recent comment):

Updated my graphics card so I can use nvidia-driver-470. Still fails to load due to the assumption everything were syscons. …
Click to expand...

I used nvidia-driver-470 with vt until a few hours ago.

I'm now testing nvidia-driver-390 with vt (boot environment n266797-0a958aa16fed-d).

I'll probably revert to nvidia-driver-470 with vt (n266797-0a958aa16fed-c) later today.

Code: 
% sysctl kern.vty
kern.vty: vt
% pkg iinfo nvidia
linux-nvidia-libs-470-470.161.03
nvidia-driver-390-390.154_1
nvidia-settings-470.86_1
nvidia-xconfig-525.116.04
% bectl list -c creation | tail -n 2
n266797-0a958aa16fed-c -      -          44.9M 2023-12-09 13:47
n266797-0a958aa16fed-d NR     /          571G  2023-12-10 06:25
%
 
freezr said:
With zzz two in a row without issues... ?‍♂️
Click to expand...
Actually my reason for recommending the manual zzz method over the DE menu is that years ago I browsed the KDE sources to find out what KDE did when suspending/resuming. I found that it did some strange actions instead of a clean call of acpiconf. So the easiest fix/workaround was just to not use the start menu for sending the computer to sleep.

grahamperrin
Don't bother with that PR. It regards only the utterly obsolete driver 390. There have been many, many changes in 470 and again many many changes in 535.
 
You must log in or register to reply here.
Back
Top