Suspending issues on Fedora 44, Thinkpad laptop and NVIDIA GPU

Hello all,

I am facing issues with my ThinkPad laptop. After screen lock activates, it sleeps after some minutes and then doesn’t come back. I tried several different things and even though I have different behaviors, none of them make the suspend feature work as expected. Right now the laptop suspends, but I need to press Alt + F3 to get to TTY and then Alt + F2 to return to the screen lock window. Other than that, the laptop works as expected.

I am using Fedora 44 default with GNOME on a fresh install. I use a Dell monitor connected via USB-C. I’ve tried KDE, open source NVIDIA driver and many different options, but the issue persisted. The issue happens, at least in the initial setup using the open source driver, only when the external monitor has a refresh rate of 99.98 Hz. When it is configured with 49.99 Hz, the suspend feature works fine, but the system gets so laggy that it becomes unusable. I don’t know what to do. I’ve already spent several days on this without success. The system below is not in the default configuration because I have already tried many different things without success that I don’t even remember what I have changed. I keep the laptop LCD disabled in the settings and configured the BIOS to boot to the external monitor. Could someone help me?

CPU: Intel(R) Core™ i7-10850H CPU @ 2.70GHz
GPU: NVIDIA Corporation TU117GLM [Quadro T1000 Mobile]

Display Server Protocol: Wayland
Nvidia version: 595.84
Linux kernel version: 7.0.12-201.fc44.x86_64

$ cat /sys/power/mem_sleep
s2idle [deep]
$
$ systemctl status nvidia-suspend nvidia-hibernate nvidia-resume
○ nvidia-suspend.service
     Loaded: masked (Reason: Unit nvidia-suspend.service is masked.)
     Active: inactive (dead)

○ nvidia-hibernate.service
     Loaded: masked (Reason: Unit nvidia-hibernate.service is masked.)
     Active: inactive (dead)

○ nvidia-resume.service
     Loaded: masked (Reason: Unit nvidia-resume.service is masked.)
     Active: inactive (dead)
$
$ cat /proc/driver/nvidia/params 
ResmanDebugLevel: 4294967295
RmLogonRC: 1
ModifyDeviceFiles: 1
DeviceFileUID: 0
DeviceFileGID: 0
DeviceFileMode: 438
InitializeSystemMemoryAllocations: 1
UsePageAttributeTable: 4294967295
EnableMSI: 1
EnablePCIeGen3: 0
MemoryPoolSize: 0
KMallocHeapMaxSize: 0
VMallocHeapMaxSize: 0
IgnoreMMIOCheck: 0
EnableStreamMemOPs: 0
EnableUserNUMAManagement: 1
NvLinkDisable: 0
RmProfilingAdminOnly: 1
PreserveVideoMemoryAllocations: 1
UseKernelSuspendNotifiers: 0
EnableS0ixPowerManagement: 0
S0ixPowerManagementVideoMemoryThreshold: 256
DynamicPowerManagement: 3
DynamicPowerManagementVideoMemoryThreshold: 200
TegraGpuPgMask: 4294967295
RegisterPCIDriver: 1
EnablePCIERelaxedOrderingMode: 0
EnableResizableBar: 0
EnableGpuFirmware: 0
EnableGpuFirmwareLogs: 2
RmNvlinkBandwidthLinkCount: 0
EnableDbgBreakpoint: 0
OpenRmEnableUnsupportedGpus: 1
DmaRemapPeerMmio: 1
ImexChannelCount: 2048
CreateImexChannel0: 0
EnableSystemMemoryPools: 529
CoherentGPUMemoryMode: ""
RegistryDwords: ""
RegistryDwordsPerDevice: ""
RmMsg: ""
GpuBlacklist: ""
TemporaryFilePath: "/var/tmp/"
ExcludedGpus: ""
$
$ cat /etc/modprobe.d/nvidia.conf 
#options nvidia NVreg_EnableS0ixPowerManagement=1
#options nvidia NVreg_PreserveVideoMemoryAllocations=1
#options nvidia NVreg_TemporaryFilePath=/var/tmp/
#options nvidia NVreg_EnableGpuFirmware=0
$

Both nvidia-suspend.service and nvidia-resume.service are masked so those services never are able to operate. The GPU does not properly suspend and is unable to recover on wake-up

Thanks, but it doesn’t change anything if they are enabled. The issue has just happened with the following configuration:

$ systemctl status nvidia-resume
○ nvidia-resume.service - NVIDIA system resume actions
Loaded: loaded (/usr/lib/systemd/system/nvidia-resume.service; enabled; preset: disabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: inactive (dead)
$ systemctl status nvidia-suspend
○ nvidia-suspend.service - NVIDIA system suspend actions
Loaded: loaded (/usr/lib/systemd/system/nvidia-suspend.service; enabled; preset: disabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: inactive (dead)
$

What I see that is strange is the presets for those services.
Mine shows

$ systemctl status nvidia-suspend nvidia-resume
○ nvidia-suspend.service - NVIDIA system suspend actions
     Loaded: loaded (/usr/lib/systemd/system/nvidia-suspend.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: inactive (dead)

○ nvidia-resume.service - NVIDIA system resume actions
     Loaded: loaded (/usr/lib/systemd/system/nvidia-resume.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: inactive (dead)

While they should not be active at any time except when actually suspending or resuming, mine are preset as enabled and yours are preset as disabled.

I wonder if you may need to actually remove all the nvidia packages then reinstall.
sudo dnf remove \*nvidia\* --exclude=nvidia-gpu-firmware
then
sudo dnf install akmod-nvidia xorg-x11-drv-nvidia-cuda

A simple reinstall may not replace all the files that are contained in the package while a removal and new install will do that.

The services do not become masked as they were earlier without user action.

Thanks again. I will test that now, but before doing so, I wanted to explain what happened today. I was out for the whole day, and when I returned, the system resumed fine when I moved the mouse, but the primary display had automatically switched back to the laptop LCD. Even before enabling nvidia-resume and nvidia-suspend, resuming worked automatically from time to time.

I disabled the laptop LCD as I don’t need it, and I noticed the external monitor’s refresh rate got stuck at 49.98 Hz. I cannot change it higher unless I reboot the system. That specific issue had been happening during the last few days before I settled down with the configuration that I posted initially here, and I believe it also happened when I used the open-source driver. I don’t know if this is the result of enabling nvidia-resume and nvidia-suspend, but it hadn’t happened over the last three or four days.

EDIT: I tried to do what you suggested, but it seems there are no Nvidia packages installed. I installed the driver by downloading the package from the Nvidia website. This was the last attempt to get resuming working fine after battling with the open-source driver, without good results so far.

$ sudo dnf remove \*nvidia\* --exclude=nvidia-gpu-firmware
Argument '*nvidia*' matches only excluded packages.

Nothing to do.
$

Not to discount those other insights provided, but my machine has suffered the same thing after updating to Plasma 6.7. That does not appear to be the primary culprit since there were other packages along with Plasma in there, and you are on GNOME experiencing the same problem. It may be related to a powerdevil update. That is just a hunch, and I am still learning.

Setup:
For some reference to hardware, my machine is using an AMD CPU with integrated graphics. A dedicated GPU is not in use.

Issue Details:
My machine will seem like it kicks back “on” from sleeping (fans start to spin and so on), but the display never comes back up and everything is completely unresponsive. The physical ports still receive power, but no data can transfer through them it seems (from any of the ports). The keyboard does not light up for caps lock during this issue either. This is simply not a layer 1 problem. Yes, unplugging and plugging peripherals back in was attempted various times.
Edit: To add, the machine never goes back into “sleep” mode once it is stuck in this limbo.

Resolution/Future Prevention:
The only thing that works to resolve this for me is holding the power button down until power is cut, and that is not ideal. I ended up changing some KDE settings around to stop the machine from sleeping completely, but the screen is still allowed to turn off. This has fixed my problem, and I actually like it better this way. It does use more power compared to allowing the machine to sleep though.

For GNOME:
I do not use GNOME, but if there are power settings to prevent sleep - try those. If you do not have those (because GNOME) maybe try a .conf file in systemd to manually set sleep behaviors, but I will defer that advice to someone with more GNOME (and linux) experience on that topic. I did not go that route to have pretested it for you with a validated outcome. Therefore, I cannot in good conscience recommend anything specific, but I did see some topics here that outline the process of the directory needed and the .conf file contents in systemd for this exact problem - although the reason for this problem in those cases appeared to be related to the kernel version.

Good luck!

That would be expected when the nvidia drivers are not installed from rpmfusion.
Installing drivers directly from nvidia often may cause issues.

The common suggestion is to completely remove those drivers the same way they were installed, then install the drivers from the rpmfusion repo

Hi, Jeff. In fact, I installed the proprietary driver because I was having the same issues with the open-source one. I had spent a good amount of time trying to understand and solve it, and installing the proprietary driver was a last resort that, unfortunately, didn’t change much. I will try it again and report the results here. Thanks!

Thanks, Msplinter. I’ll do more experiments to see if I can get it to work as expected, but if I can’t, there’s not much that I can do other than disabling the suspend feature altogether.

Okay, I think I found the culprit. The Dell monitor has a setting called “USB-C Prioritization” that was set to “High Resolution”. When I changed it to “High Data Speed”, the problem seemed to go away.

I did three tests and was able to reliably reproduce the issue when the setting was on “High Resolution”, whereas the problem never occurred during the tests with “High Data Speed”. Note that when I change this setting, both the internal and external monitors go completely blank and I am forced to reboot, so all tests were performed after a fresh boot.

I’ll continue using the laptop, and if the problem doesn’t return, I’ll mark this post as the solution. Thank you, everyone!

so it seems that this is not a suspend issue after all.

Does this also happen with a monitor connected to the HDMI port?
Usually, displays connected to a USB-C port are driven by the iGPU in a hybrid graphic setup. You could also see if changing the UEFI setting to discrete GPU’ has any effect.

This setting is/was important for older systems that support DP1.2 only like the iGPU on the

i.e DP1.2 systems would not be able to configure 4k USB-C displays @ 60Hz

Essentially, It disables USB3 in order to configure the 4 available lanes for DP data.

This should not be an issue with systems that support DP1.4

Now I know that the laptop itself suspends and resumes fine, but the external monitor does not, at least with my current configuration. I only noticed this after running extensive tests. For example, after resuming, I can blindly log in while both the internal and external monitors are still completely black, and I can verify that the laptop is active on my local network.

When I try to wake the laptop by moving the mouse or pressing a key and the monitors fail to activate, switching to a TTY via Alt + F3 somehow forces the internal display to wake up, which in turn triggers the external monitor to turn on. I then press Alt + F2 to return to the graphical desktop environment. When I get back, I am already logged in because I authenticated blindly using the fingerprint scanner. This confirms the laptop wakes up fine. It is just the displays that fail to catch the signal. It appears the external monitor simply isn’t receiving the command to wake up.

Yes, it does. Based on the basic tests I ran, I couldn’t get it to work properly over HDMI either.

I have already tried that. I tested every variation of the GPU settings in the UEFI, but none of them made a difference.

Unfortunately, the problem is still occurring. Changing the monitor’s built-in settings felt like progress at first because I was able to successfully suspend and resume several times in a row, but eventually, the problem returned. I am not entirely sure what triggers it, but if the system stays suspended long enough, the external monitor does activate when I move the mouse (this doesn’t happen when the USB-C Prioritization is set to “High Resolution”), however, the screen just displays random letters and completely freezes. I am forced to reboot to get the system back.

There’s also this message that I hadn’t seen before:

I cannot afford to spend any more time troubleshooting this right now, so I have disabled system suspension entirely. I will probably start tinkering with it again in a few days.

I think I’ve taken this as far as I can, so I’ll leave this final update here for anyone else facing the same issue.

After tinkering with the system and running several experiments, I now know the issue isn’t directly related to suspending or resuming, as it happens even when the laptop doesn’t suspend at all. I have disabled all automatic suspend features in the settings.

The issue fundamentally comes down to the external monitor failing to activate after entering standby mode. I had to use Alt + F3 and Alt + F2 to get back to the graphical interface twice during two days of uptime, but at least the system doesn’t crash and I can get my work done.

In case anyone is interested, I noticed every time I need to manually activate the external monitor, the exact same errors appear on journalctl:

$ journalctl -r
Jun 29 13:46:40 weyl gnome-shell[142996]: Errors from xkbcomp are not fatal to the X server
Jun 29 13:46:40 weyl gnome-shell[142996]: >                   Using 0, ignoring 0
Jun 29 13:46:40 weyl gnome-shell[142996]: > Warning:          Virtual modifier ScrollLock multiply defined
Jun 29 13:46:40 weyl gnome-shell[142996]: >                   Using 0, ignoring 0
Jun 29 13:46:40 weyl gnome-shell[142996]: > Warning:          Virtual modifier Hyper multiply defined
Jun 29 13:46:40 weyl gnome-shell[142996]: >                   X11 cannot support keycodes above 255.
Jun 29 13:46:40 weyl gnome-shell[142996]: > Warning:          Unsupported maximum keycode 709, clipping.
Jun 29 13:46:40 weyl gnome-shell[142996]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Jun 29 13:46:39 weyl gsd-media-keys[3696]: Unable to get default sink
Jun 29 13:46:39 weyl xdg-desktop-portal-gnome[4017]: Monitor 'Built-in display' has no configuration which is-current!
Jun 29 13:46:39 weyl xdg-desktop-portal-gnome[4017]: Monitor 'Built-in display' has no configuration which is-current!
Jun 29 13:46:39 weyl uresourced[1753]: Setting resources on user@1000.service (MemoryMin: 262144000, MemoryLow: 0, CPUWeight: 500, IOWeight: 500)
Jun 29 13:46:39 weyl uresourced[1753]: Setting resources on user-1000.slice (MemoryMin: 262144000, MemoryLow: 0, CPUWeight: 500, IOWeight: 500)
Jun 29 13:46:39 weyl uresourced[1753]: Setting resources on user.slice (MemoryMin: 262144000, MemoryLow: 0, CPUWeight: -, IOWeight: -)
Jun 29 13:46:39 weyl kernel: rfkill: input handler disabled
Jun 29 13:46:39 weyl gdm[1715]: GLib: Source ID 165 was not found when attempting to remove it
Jun 29 13:46:36 weyl uresourced[1753]: Setting resources on user.slice (MemoryMin: 0, MemoryLow: 0, CPUWeight: -, IOWeight: -)
Jun 29 13:46:36 weyl uresourced[1753]: Setting resources on user@1000.service (MemoryMin: 0, MemoryLow: 0, CPUWeight: 100, IOWeight: 100)
Jun 29 13:46:36 weyl uresourced[1753]: Setting resources on user-1000.slice (MemoryMin: 0, MemoryLow: 0, CPUWeight: 100, IOWeight: 100)
Jun 29 13:46:36 weyl gnome-shell[3550]: Object MetaInputDeviceNative (0x7f2c943b2bd0), has been already disposed — impossible to get any property from it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
                                        == Stack trace for context 0x55e3dd4fba60 ==
                                        #0   55e3dd5cc478 i   resource:///org/gnome/shell/ui/keyboard.js:1059 (38c168c85560 @ 3)
                                        #1   55e3dd5cc3e8 i   resource:///org/gnome/shell/ui/init.js:20 (349f8a58d8d0 @ 48)
Jun 29 13:46:36 weyl gsd-media-keys[3696]: Unable to get default source
Jun 29 13:46:36 weyl gsd-media-keys[3696]: Unable to get default sink
Jun 29 13:46:36 weyl kernel: rfkill: input handler enabled
Jun 29 13:46:35 weyl gsd-media-keys[3696]: Unable to get default sink

Thank you to everyone who helped me!

This seems to imply you may be using X11 desktop which has been totally removed from most fedora products and may not be properly supported.

Have you tried using the wayland DE instead to see if there may be a difference in behavior with the graphics?

Please show us the output of inxi -Fzxx which should show the entire hardware and driver info so we may have a better idea of the hardware involved. It will also include the monitor info which is important since this seems the area of concern.

I’ve noticed this, but it’s crazy because it’s using Wayland. It’s a default Fedora 44 installation. I don’t customize anything regarding the desktop environment.

$ echo $XDG_SESSION_TYPE 
wayland
$
$ inxi -Fzxx
System:
  Kernel: 7.0.12-201.fc44.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 16.1.1
  Desktop: GNOME v: 50.2 tk: GTK v: 3.24.52 wm: gnome-shell dm: GDM
    Distro: Fedora Linux 44 (Workstation Edition)
Machine:
  Type: Laptop System: LENOVO product: 20ST0075BR v: ThinkPad P15 Gen 1
    serial: <superuser required> Chassis: type: 10 serial: <superuser required>
  Mobo: LENOVO model: 20ST0075BR v: SDK0J40697 WIN
    serial: <superuser required> part-nu: LENOVO_MT_20ST_BU_Think_FM_ThinkPad
    P15 Gen 1 Firmware: UEFI vendor: LENOVO v: N30ET62W (1.98 )
    date: 03/24/2026
Battery:
  ID-1: BAT0 charge: 82.4 Wh (100%) condition: 82.4/94 Wh (87.7%) volts: 12.76
    min: 11.52 model: Celxpert 5B10W13959 serial: <filter> charging:
    status: full control: start: 0% end: 100% cycles: 51
CPU:
  Info: 6-core model: Intel Core i7-10850H bits: 64 type: MT MCP
    arch: Comet Lake rev: 2 cache: L1: 384 KiB L2: 1.5 MiB L3: 12 MiB
  Speed (MHz): avg: 4958 min/max: 800/5100 cores: 1: 4958 2: 4958 3: 4958
    4: 4958 5: 4958 6: 4958 7: 4958 8: 4958 9: 4958 10: 4958 11: 4958 12: 4958
    bogomips: 64797
  Flags-basic: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: NVIDIA TU117GLM [Quadro T1000 Mobile] vendor: Lenovo
    driver: nvidia v: 610.43.02 arch: Turing pcie: speed: 5 GT/s lanes: 1 ports:
    active: DP-2 off: eDP-1 empty: DP-1,DP-3,HDMI-A-1 bus-ID: 01:00.0
    chip-ID: 10de:1fb9
  Device-2: Chicony Integrated Camera driver: uvcvideo type: USB rev: 2.0
    speed: 480 Mb/s lanes: 1 bus-ID: 1-8:7 chip-ID: 04f2:b725
  Device-3: Dell Webcam WB7022 driver: hid-sensor-hub,usbhid,uvcvideo
    type: USB rev: 3.2 speed: 5 Gb/s lanes: 1 bus-ID: 2-1.1:4 chip-ID: 413c:c015
  Display: wayland server: Xwayland v: 24.1.12 compositor: gnome-shell
    driver: gpu: nvidia,nvidia-nvswitch display-ID: 0
  Monitor-1: DP-2 model: Dell S3423DWC res: 3440x1440 dpi: 110
    diag: 864mm (34")
  Monitor-2: eDP-1 model: BOE Display 0x086e res: 1920x1080 dpi: 142
    diag: 395mm (15.5")
  API: OpenGL v: 4.6.0 vendor: nvidia v: 610.43.02 glx-v: 1.4
    direct-render: yes renderer: Quadro T1000/PCIe/SSE2 display-ID: :0.0
  API: EGL Message: EGL data requires eglinfo. Check --recommends.
  Info: Tools: api: glxinfo gpu: nvidia-settings,nvidia-smi x11: xdriinfo,
    xdpyinfo, xprop, xrandr
Audio:
  Device-1: Intel 400 Series Family HD Audio vendor: Lenovo
    driver: snd_hda_intel v: kernel bus-ID: 00:1f.3 chip-ID: 8086:06c8
  Device-2: NVIDIA vendor: Lenovo driver: snd_hda_intel v: kernel pcie:
    speed: 8 GT/s lanes: 1 bus-ID: 01:00.1 chip-ID: 10de:10fa
  API: ALSA v: k7.0.12-201.fc44.x86_64 status: kernel-api
  Server-1: PipeWire v: 1.6.7 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
    4: pw-jack type: plugin
Network:
  Device-1: Intel 400 Series Family CNVi Wi-Fi driver: iwlwifi v: kernel
    bus-ID: 00:14.3 chip-ID: 8086:06f0
  IF: wlp0s20f3 state: up mac: <filter>
  Device-2: Intel 400 Series Family GbE vendor: Lenovo driver: e1000e
    v: kernel port: N/A bus-ID: 00:1f.6 chip-ID: 8086:0d4c
  IF: enp0s31f6 state: down mac: <filter>
  IF-ID-1: vmnet0 state: unknown speed: N/A duplex: N/A mac: <filter>
Drives:
  Local Storage: total: 1.51 TiB used: 119.31 GiB (7.7%)
  ID-1: /dev/nvme0n1 vendor: Samsung model: MZVLB1T0HBLR-000L7
    size: 953.87 GiB speed: 31.6 Gb/s lanes: 4 serial: <filter> temp: 37.9 C
  ID-2: /dev/nvme1n1 vendor: Intel model: SSDPEKNW512G8 size: 476.94 GiB
    speed: 31.6 Gb/s lanes: 4 serial: <filter> temp: 27.9 C
  ID-3: /dev/sda vendor: SanDisk model: USB 3.2Gen1 size: 114.61 GiB
    type: USB rev: 2.1 spd: 480 Mb/s lanes: 1 serial: <filter>
Partition:
  ID-1: / size: 951.27 GiB used: 24.48 GiB (2.6%) fs: btrfs dev: /dev/dm-0
    mapped: luks-538c31f1-ea9e-4737-99dd-6c7b97244905
  ID-2: /boot size: 1.9 GiB used: 1.06 GiB (55.6%) fs: ext4
    dev: /dev/nvme0n1p2
  ID-3: /boot/efi size: 598.8 MiB used: 20 MiB (3.3%) fs: vfat
    dev: /dev/nvme0n1p1
  ID-4: /home size: 951.27 GiB used: 24.48 GiB (2.6%) fs: btrfs
    dev: /dev/dm-0 mapped: luks-538c31f1-ea9e-4737-99dd-6c7b97244905
Swap:
  ID-1: swap-1 type: zram size: 8 GiB used: 3.19 GiB (39.9%) priority: 100
    dev: /dev/zram0
Sensors:
  Src: /sys System Temperatures: cpu: 52.0 C pch: 46.0 C mobo: N/A
  Fan Speeds (rpm): fan-1: 1962 fan-2: 1668
  Power: 12v: N/A 5v: 5 3.3v: N/A vbat: N/A
Info:
  Memory: total: 16 GiB note: est. available: 15.31 GiB
    used: 12.27 GiB (80.1%)
  Processes: 475 Power: uptime: 2d 21h 28m wakeups: 0 Init: systemd v: 259
    default: graphical
  Packages: pm: rpm pkgs: N/A note: see --rpm Compilers: gcc: 16.1.1
    Shell: Bash v: 5.3.9 running-in: ptyxis-agent inxi: 3.3.40

This looks odd. So far for fedora the latest driver available from rpmfusion is the 595.80 release.

Where did you get that 610.43.02 driver from? Directly from nvidia or elsewhere?
A search on nvidia only shows the latest released version for windows to be the 596.72 driver (equivalent to the 595.84 for linux).

Drivers for nvidia that are obtained from other sources than rpmfusion repos often have issues that are identified, fixed, and tested by rpmfusion before release.

The latest released version from the rpmfusion repo is 595.80 version and seems to work very well (and is one of the listed versions for that T1000M on the nvidia site.)

I suggest you remove the currently installed nvidia driver then install the latest available driver from the rpmfusion-nonfree-updates repo as shown here.

You may need to enable that repo as shown here before installing it.

Ah, yeah. I forgot to say that before, I am sorry. I found it on the Nvidia website while reading everything that I could about the problem. It’s a “New Feature Branch” version.

I could do what you suggested, as I mentioned in a reply a few days ago, but I initially used the RPM Fusion driver and the issue also existed with it. I also installed KDE and changed many settings, but nothing worked, so I reinstalled the system and installed the stable proprietary driver. Since the issue continued and I found that newest version, I decided to try it.

I can do what you suggested, but since I have already used it on this laptop, I believe the chances of the problem not happening with it are very small.

I am continuing to use that version of the driver because I honestly think the system got much better regarding performance after installing it and, as I stated a few messages ago, I can at least do my work using this configuration now.