Freeze after disconnecting AC after resuming from suspend

rktmln · 2025-07-25 17:30:32

I have been having this problem since the very beginning of using Arch Linux. I am already fed up with it, I already wrote a post on reddit and they couldn't help me there either and I hope that at least they will help me here. The main problem as I understand it is in the proprietary nvidia driver because as soon as I delete it I don't have any problems regarding suspend. I will describe in more detail what happens, I put the laptop to sleep for any period, it doesn’t matter, then I wake it up from sleep and pull out the charging cable in the first 10 seconds after waking up and it freezes immediately or, for a start, all applications start sending messages that they are not responding, the processor frequency is boosted to the maximum and then everything freezes again. I recently installed acpid and launched this daemon and after that the laptop sometimes stopped freezing the first time when I do the whole sequence of actions, but the second time it freezes with a hundred percent probability. I think that the main problem is acpi errors, but I have no idea how to fix them since everyone on the forums says to just ignore them.I have never encountered the same error as me and I don't understand what the problem is... I hope for your help, I will leave a link to the output of journalctl -b, I hope this will help, if you need anything else, please clarify here

https://github.com/rktmln/journalctl/blob/main/log.txt

seth · 2025-07-25 20:24:16

I am already fed up with it … put the laptop to sleep for any period, it doesn’t matter, then I wake it up from sleep and pull out the charging cable in the first 10 seconds after waking up

Seriously…? "Just don't do that" - seems easy enough to not trigger this.

Well… let's see

Jul 25 17:05:17 vivobook kernel: RIP: 0010:tgl_tc_phy_init+0x127/0x150 [i915]
Jul 25 17:05:17 vivobook kernel: RIP: 0033:0x7fa382e4ef6d
Jul 25 17:05:17 vivobook kernel: RIP: 0010:icl_tc_phy_connect+0x16e/0x190 [i915]
Jul 25 17:05:17 vivobook kernel: RIP: 0033:0x7fa382e4ef6d
Jul 25 17:05:17 vivobook kernel: RIP: 0010:icl_tc_phy_connect+0x16e/0x190 [i915]
Jul 25 17:05:17 vivobook kernel: RIP: 0033:0x7fa382e4ef6d
Jul 25 17:05:17 vivobook kernel: RIP: 0010:__intel_tc_port_lock+0x94/0x130 [i915]
Jul 25 17:05:17 vivobook kernel: RIP: 0033:0x7fa382e4ef6d
Jul 25 17:05:17 vivobook kernel: RIP: 0010:__intel_tc_port_lock+0x94/0x130 [i915]
Jul 25 17:05:17 vivobook kernel: RIP: 0010:__intel_tc_port_lock+0x94/0x130 [i915]
Jul 25 17:05:17 vivobook kernel: RIP: 0010:__intel_tc_port_lock+0x94/0x130 [i915]
Jul 25 17:05:30 vivobook kernel: RIP: 0010:icl_tc_phy_connect+0x16e/0x190 [i915]
Jul 25 17:05:30 vivobook kernel: RIP: 0033:0x7f1ae2c2cf4d
Jul 25 17:05:30 vivobook kernel: RIP: 0010:__intel_tc_port_lock+0x94/0x130 [i915]
Jul 25 17:05:30 vivobook kernel: RIP: 0033:0x7f1ae2c2cf4d
Jul 25 17:05:30 vivobook kernel: RIP: 0010:__intel_tc_port_lock+0x94/0x130 [i915]
Jul 25 17:05:30 vivobook kernel: RIP: 0033:0x7f1ae2c2cf4d

there're actually multiple warnings from i915 (the intel chip)

Jul 25 17:05:17 vivobook kernel: usb 1-4: device descriptor read/64, error -71
Jul 25 17:05:17 vivobook kernel: usb 1-4: New USB device found, idVendor=13ee, idProduct=0001, bcdDevice= 0.10
Jul 25 17:05:17 vivobook kernel: usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jul 25 17:05:17 vivobook kernel: usb 1-4: Product: AND 
Jul 25 17:05:17 vivobook kernel: usb 1-4: Manufacturer: MOON
Jul 25 17:05:17 vivobook kernel: usb 1-4: SerialNumber: @ɌAB

Sanity check: what is that? Are any external usb devices plugged in?

But

Jul 25 17:05:48 vivobook systemd[1]: Reached target Sleep.
Jul 25 17:05:48 vivobook systemd[1]: Starting NVIDIA system suspend actions...
Jul 25 17:05:48 vivobook wpa_supplicant[562]: p2p-dev-wlo1: CTRL-EVENT-DSCP-POLICY clear_all
Jul 25 17:05:48 vivobook suspend[757]: nvidia-suspend.service
Jul 25 17:05:48 vivobook logger[757]: <13>Jul 25 17:05:48 suspend: nvidia-suspend.service
Jul 25 17:05:48 vivobook wpa_supplicant[562]: p2p-dev-wlo1: CTRL-EVENT-DSCP-POLICY clear_all
Jul 25 17:05:48 vivobook wpa_supplicant[562]: nl80211: deinit ifname=p2p-dev-wlo1 disabled_11b_rates=0
Jul 25 17:05:48 vivobook wpa_supplicant[562]: wlo1: CTRL-EVENT-DSCP-POLICY clear_all
Jul 25 17:05:48 vivobook wpa_supplicant[562]: wlo1: CTRL-EVENT-DSCP-POLICY clear_all
Jul 25 17:05:48 vivobook wpa_supplicant[562]: nl80211: deinit ifname=wlo1 disabled_11b_rates=0
Jul 25 17:05:48 vivobook systemd[1]: nvidia-suspend.service: Deactivated successfully.
Jul 25 17:05:48 vivobook systemd[1]: Finished NVIDIA system suspend actions.
Jul 25 17:05:48 vivobook systemd[1]: Starting System Suspend...
Jul 25 17:05:48 vivobook systemd-sleep[776]: User sessions remain unfrozen on explicit request ($SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0).
Jul 25 17:05:48 vivobook systemd-sleep[776]: This is not recommended, and might result in unexpected behavior, particularly
Jul 25 17:05:48 vivobook systemd-sleep[776]: in suspend-then-hibernate operations or setups with encrypted home directories.
Jul 25 17:05:48 vivobook systemd-sleep[776]: Performing sleep operation 'suspend'...
Jul 25 17:05:48 vivobook kernel: PM: suspend entry (deep)
Jul 25 17:05:48 vivobook kernel: Filesystems sync: 0.012 seconds
Jul 25 17:06:11 vivobook kernel: Freezing user space processes
Jul 25 17:06:11 vivobook kernel: Freezing user space processes completed (elapsed 0.006 seconds)
Jul 25 17:06:11 vivobook kernel: OOM killer disabled.

the journal ends in the sleep.

Can you escape from the frozen system in a clean way - either by frenetically pressing ctrl+alt+del, a SHORT touch of the power button or the https://wiki.archlinux.org/title/Keyboa … el_(SysRq) ?
It would probably be helpful to see the journal on the other side of the sleep.

What most likely happens (by the symptoms) is that the charger event causes something™ to power down the nvidia GPU (battery saving) and that conflicts w/ the nvidia-suspend.service or rather nvidia-resume.service trying to restore the VRAM. Or maybe the persistence daemon.
acpid might by sheer luck just stall the process "enough" by intercepting the charger event to get you over the line.

The main question however is whether the (assumed) power cut of the nvidia GPU is caused by some userspace daemon (asusd) or the firmware (uefi, you're borderline fucked)

Jul 25 17:05:47 vivobook asusd[569]: [DEBUG asusd] Doing on_prepare_for_sleep(true)

=> Try to stop asusd.

rktmln · 2025-07-26 09:42:58

For me it's not that easy to avoid because I usually leave my laptop on charge, turn it on, look at the charge and unplug it to take it somewhere with me, so for me it's a significant problem.as for i915 errors, this is an error concerning the type c port, I don't know what the problem is with it, but it seems that it is not initialized correctly and provokes these errors like display port. As for the external USB device, this is my mouse, only it is connected, why did you ask?

About what you asked me if I can get out of this freeze mode in some clean way, then no, it stops responding to any of my presses, that is, the caps lock indicator does not light up, the fn lock also stops working and the backlight adjustment button also stops working. I haven't tried SysRq yet, but it seems the result will be the same.But, after a long period, if I wait after freezing, then I am transferred to tty where it shows me that a soft lockup has occurred on all processor cores, this is the only thing I was able to get.Stopping asusd also doesn't help unfortunately, I already tried this because I thought that this was the reason but no...

and so I configured sysrq but it seems that everything freezes so much that even this key does not help. That is, it helps only in the first seconds of freezing and then the kernel simply crashes completely. Logs are not written after sleep so I do not know what to do ... You can try to output logs in real time to another PC ..

Last edited by rktmln (2025-07-26 10:07:17)

seth · 2025-07-26 14:19:50

then I am transferred to tty where it shows me that a soft lockup has occurred on all processor cores, this is the only thing I was able to get

Do you have eg. a picture of that? (If so, please link it. Don't embed huge pictures to keep everyones mousewheels cool )

If not: can you provoke this from the multi-user.target (2nd link below), ideally running "dmesg -w" while it happens (and then get images of that)?

(sleep 10; systemctl suspend) & dmesg -w

Finally, did you test the performance of s2idle? (Maybe it will fuck up as well, but return to a running system…)
https://wiki.archlinux.org/title/Power_ … end_method

rktmln · 2025-07-26 16:18:10

and so I did everything you said and I will attach a link to the video that I will post on streamable, this time I was lucky and the sysrq key worked and several lines of logs were added that were there while the laptop was sleeping.The video shows that new logs are appearing, but they look like artifacts. I think you'll be able to see something there, I hope. Also, the strangest logs started appearing at the very top of the screen, lol. You'll see for yourself in the video, I think this is a very atypical problem, but now I'm more inclined to think that it's the fault of the processor driver and that it's interfering with my gpu driver.

Here are the logs that were added at the end.
Jul 26 19:03:00 vivobook kernel: PM: suspend entry (deep)
Jul 26 19:03:00 vivobook kernel: Filesystems sync: 0.016 seconds
Jul 26 19:03:10 vivobook kernel: Freezing user space processes
Jul 26 19:03:10 vivobook kernel: Freezing user space processes completed (elapsed 0.001 seconds)
Jul 26 19:03:10 vivobook kernel: OOM killer disabled.
Jul 26 19:03:10 vivobook kernel: Freezing remaining freezable tasks
Jul 26 19:03:10 vivobook kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
Jul 26 19:03:10 vivobook kernel: ACPI: EC: interrupt blocked
Jul 26 19:03:10 vivobook kernel: ACPI: PM: Preparing to enter system sleep state S3
Jul 26 19:03:10 vivobook kernel: ACPI: EC: event blocked

https://streamable.com/p8bxml "quality is shit lol"

btw, s2idle does the same shit like deep

Last edited by rktmln (2025-07-26 16:18:30)

seth · 2025-07-26 20:37:40

I guess your camera would have produced a higher resolution still photo…

and the sysrq key worked

So you actually have the journal of that boot?
For the previous ("-1") boot:

sudo journalctl -b "-1" | curl -F 'file=@-' 0x0.st

Os is the snippet you posted the literal end (ie. nothing was actually written to disk anyway - you did the entire REISUB dance, not just "sysrq+b)?

I don't like the i915 warnings and I don't like that the i915 controlled framebuffer (notebook panel) goes wild.
=> Can you disable the IGP in the firmware (UEFI/BIOS)?

Alternatively, disable https://wiki.archlinux.org/title/NVIDIA … er_suspend (services and explicitly set the kernel parameter to "nvidia.NVreg_PreserveVideoMemoryAllocations=0") and https://wiki.archlinux.org/title/NVIDIA … ersistence (we'll just try to make the nvidia driver do less stuff around the sleep, since "because as soon as I delete it I don't have any problems regarding suspend")

rktmln · 2025-07-27 07:46:48

Hi, sorry I haven't responded yesterday. Yes, I have a log from that download but to be honest, not much has changed there, you can take a look anyway.

https://0x0.st/853J.txt

Regarding the sysrq key, I didn't have to do REISUB, I just did SysRq + B. Unfortunately, I already tried to turn off the IGPU in the BIOS, but I don't have that function.

seth · 2025-07-27 08:18:44

I didn't have to do REISUB, I just did SysRq + B

"REISU" is what allows for a clean shutdown and notably the journal to be preserved
If you can get that after a failed wakeup, we'll very likely have data on the cause.

rktmln · 2025-07-28 09:19:43

yes, finally it worked, after several reboots and tortures I finally managed to get the logs. Here is the link, thanks for telling me to do it through REISUB lol.

https://0x0.st/8552.txt

I think that the i915 is to blame for everything. I don't think it's anything else lol... it's the only one that gives such a huge number of errors.

seth · 2025-07-28 12:37:56

Not sure how much the i915 warnings there interfere, but an easy enough and obvious target should be

Jul 28 12:12:42 vivobook kernel: watchdog: BUG: soft lockup - CPU#4 stuck for 26s! [tokio-runtime-w:563]
Jul 28 12:12:42 vivobook kernel: CPU: 4 UID: 0 PID: 563 Comm: tokio-runtime-w Tainted: P        W  OE       6.15.7-arch1-1 #1 PREEMPT(full)  da38e44efe05f845d31f9b6b79f90acc327497cc
Jul 28 12:13:10 vivobook kernel: watchdog: BUG: soft lockup - CPU#4 stuck for 53s! [tokio-runtime-w:563]
Jul 28 12:13:10 vivobook kernel: CPU: 4 UID: 0 PID: 563 Comm: tokio-runtime-w Tainted: P        W  OEL      6.15.7-arch1-1 #1 PREEMPT(full)  da38e44efe05f845d31f9b6b79f90acc327497cc
Jul 28 12:13:16 vivobook kernel: CPU: 4 UID: 0 PID: 563 Comm: tokio-runtime-w Tainted: P        W  OEL      6.15.7-arch1-1 #1 PREEMPT(full)  da38e44efe05f845d31f9b6b79f90acc327497cc
Jul 28 12:13:42 vivobook kernel: watchdog: BUG: soft lockup - CPU#4 stuck for 82s! [tokio-runtime-w:563]
Jul 28 12:13:42 vivobook kernel: CPU: 4 UID: 0 PID: 563 Comm: tokio-runtime-w Tainted: P        W  OEL      6.15.7-arch1-1 #1 PREEMPT(full)  da38e44efe05f845d31f9b6b79f90acc327497cc

If only so I get to roast the "you gots to use the rust that wills it make safe" lemmings out there

rktmln · 2025-07-28 13:30:54

Haha, to be honest I'm not a big fan of rust either, but what we have is what we have. Any other ideas? What do you suggest doing next?

By the way, there was something about udev-worker on another core. Or do you think that it’s nothing important?

Last edited by rktmln (2025-07-28 13:33:29)

seth · 2025-07-28 13:51:00

I don't mind rust. Only the fanbois.

The same problem happened w/o that tokio server running?

The rip codes after the resume

Jul 28 12:12:15 vivobook kernel: RIP: 0010:icl_tc_phy_connect+0x16e/0x190 [i915]
Jul 28 12:12:15 vivobook kernel: RIP: 0010:icl_tc_phy_connect+0x16e/0x190 [i915]
Jul 28 12:12:15 vivobook kernel: RIP: 0010:__intel_tc_port_lock+0x94/0x130 [i915]
Jul 28 12:12:42 vivobook kernel: RIP: 0010:smp_call_function_many_cond+0x2c0/0x4a0
Jul 28 12:12:42 vivobook kernel: RIP: 0033:0x7f495f785deb
Jul 28 12:12:42 vivobook kernel: RIP: 0010:smp_call_function_many_cond+0x2c0/0x4a0
Jul 28 12:12:42 vivobook kernel: RIP: 0033:0x7fb33ccb58a2
Jul 28 12:13:10 vivobook kernel: RIP: 0010:smp_call_function_many_cond+0x2c0/0x4a0
Jul 28 12:13:10 vivobook kernel: RIP: 0033:0x7f495f785deb
Jul 28 12:13:10 vivobook kernel: RIP: 0010:smp_call_function_many_cond+0x2c0/0x4a0
Jul 28 12:13:10 vivobook kernel: RIP: 0033:0x7fb33ccb58a2
Jul 28 12:13:16 vivobook kernel: RIP: 0010:_nv015668rm+0x256/0xab0 [nvidia]
Jul 28 12:13:16 vivobook kernel: RIP: 0010:smp_call_function_many_cond+0x2c0/0x4a0
Jul 28 12:13:16 vivobook kernel: RIP: 0033:0x7f495f785deb
Jul 28 12:13:38 vivobook kernel: RIP: 0010:smp_call_function_many_cond+0x2c0/0x4a0
Jul 28 12:13:38 vivobook kernel: RIP: 0033:0x7fb33ccb58a2
Jul 28 12:13:42 vivobook kernel: RIP: 0010:smp_call_function_many_cond+0x2c0/0x4a0

The i915 ones are with you all the time, ignoring those there's the smp_call_function_many_cond deadlock and the nvidia one:

Jul 28 12:13:16 vivobook kernel: rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
Jul 28 12:13:16 vivobook kernel: rcu:         7-...!: (3 GPs behind) idle=638c/1/0x4000000000000000 softirq=2044/2045 fqs=180
Jul 28 12:13:16 vivobook kernel: rcu:         (detected by 3, t=60002 jiffies, g=3277, q=282 ncpus=8)
Jul 28 12:13:16 vivobook kernel: Sending NMI from CPU 3 to CPUs 7:
Jul 28 12:13:16 vivobook kernel: NMI backtrace for cpu 7
Jul 28 12:13:16 vivobook kernel: CPU: 7 UID: 0 PID: 861 Comm: kworker/7:5 Tainted: P        W  OEL      6.15.7-arch1-1 #1 PREEMPT(full)  da38e44efe05f845d31f9b6b79f90acc327497cc
Jul 28 12:13:16 vivobook kernel: Tainted: [P]=PROPRIETARY_MODULE, [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE, [L]=SOFTLOCKUP
Jul 28 12:13:16 vivobook kernel: Hardware name: ASUSTeK COMPUTER INC. VivoBook_ASUSLaptop X513EPN_K513EP/X513EPN, BIOS X513EPN.306 04/11/2023
Jul 28 12:13:16 vivobook kernel: Workqueue: kacpi_notify acpi_os_execute_deferred
Jul 28 12:13:16 vivobook kernel: RIP: 0010:_nv015668rm+0x256/0xab0 [nvidia]
Jul 28 12:13:16 vivobook kernel: Code: 00 01 00 00 00 48 89 b0 60 05 00 00 0f b6 75 1f 66 44 89 a8 50 05 00 00 40 88 b0 52 05 00 00 48 8b 75 58 44 89 a0 4c 05 00 00 <48> 89 88 68 05 00 00 40 88 b0 53 05 00 00 48 8b 45 60 89 15 3a be
Jul 28 12:13:16 vivobook kernel: RSP: 0018:ffffcee3414cbd00 EFLAGS: 00000002
Jul 28 12:13:16 vivobook kernel: RAX: ffffffffc25837f0 RBX: ffffffffc2583360 RCX: 000f421c25999700
Jul 28 12:13:16 vivobook kernel: RDX: 000000000000001f RSI: 0000000300000000 RDI: 00000000125bb500
Jul 28 12:13:16 vivobook kernel: RBP: ffff8bd48526af80 R08: 0000000000000001 R09: 0000000000000020
Jul 28 12:13:16 vivobook kernel: R10: ffff8bd48526af4c R11: 0000000000000001 R12: 0000000000000001
Jul 28 12:13:16 vivobook kernel: R13: 0000000000000000 R14: ffff8bd4859e0008 R15: 0000000000000000
Jul 28 12:13:16 vivobook kernel: FS:  0000000000000000(0000) GS:ffff8bd9688ec000(0000) knlGS:0000000000000000
Jul 28 12:13:16 vivobook kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jul 28 12:13:16 vivobook kernel: CR2: 000055b75e2e3308 CR3: 0000000579824006 CR4: 0000000000f72ef0
Jul 28 12:13:16 vivobook kernel: PKRU: 55555554
Jul 28 12:13:16 vivobook kernel: Call Trace:
Jul 28 12:13:16 vivobook kernel:  <TASK>
Jul 28 12:13:16 vivobook kernel:  _nv052874rm+0x2f/0x150 [nvidia c3d21adeec2a08385f01a2cedfe0968d6261363d]
Jul 28 12:13:16 vivobook kernel:  rm_power_source_change_event+0xf4/0x184 [nvidia c3d21adeec2a08385f01a2cedfe0968d6261363d]
Jul 28 12:13:16 vivobook kernel:  ? acpi_ut_release_mutex+0xef/0x1b0
Jul 28 12:13:16 vivobook kernel:  acpi_ev_notify_dispatch+0x4b/0x70
Jul 28 12:13:16 vivobook kernel:  acpi_os_execute_deferred+0x17/0x30
Jul 28 12:13:16 vivobook kernel:  process_one_work+0x193/0x350
Jul 28 12:13:16 vivobook kernel:  worker_thread+0x2d7/0x410
Jul 28 12:13:16 vivobook kernel:  ? __pfx_worker_thread+0x10/0x10
Jul 28 12:13:16 vivobook kernel:  kthread+0xfc/0x240
Jul 28 12:13:16 vivobook kernel:  ? __pfx_kthread+0x10/0x10
Jul 28 12:13:16 vivobook kernel:  ret_from_fork+0x34/0x50
Jul 28 12:13:16 vivobook kernel:  ? __pfx_kthread+0x10/0x10
Jul 28 12:13:16 vivobook kernel:  ret_from_fork_asm+0x1a/0x30
Jul 28 12:13:16 vivobook kernel:  </TASK>

but that is *during* the soft lockups, so it might very well be that the nvidia module runs into a pre-existing problem and makes it worse.

Do you have a journal from a wakeup w/o nvidia?

rktmln · 2025-07-29 06:59:19

Yes, this is the launch without the loaded Nvidia driver, without it everything works just fine.

to be honest i don't even know what starts that process tokio lol.

scroll a little higher because this is a session without the system hanging and at the end how I launch the graphical interface and so on, lol.

https://0x0.st/8Rum.txt

seth · 2025-07-29 07:47:47

Jul 29 09:55:06 vivobook kernel: RIP: 0010:icl_tc_phy_connect+0x16e/0x190 [i915]
Jul 29 09:55:06 vivobook kernel: RIP: 0010:__intel_tc_port_lock+0x94/0x130 [i915]
Jul 29 09:55:24 vivobook kernel: RIP: 0010:icl_tc_phy_connect+0x16e/0x190 [i915]
Jul 29 09:55:24 vivobook kernel: RIP: 0033:0x7f783a22cf4d
Jul 29 09:55:24 vivobook kernel: RIP: 0010:__intel_tc_port_lock+0x94/0x130 [i915]
Jul 29 09:55:24 vivobook kernel: RIP: 0033:0x7f783a22cf4d
Jul 29 09:55:24 vivobook kernel: RIP: 0010:__intel_tc_port_lock+0x94/0x130 [i915]
Jul 29 09:55:24 vivobook kernel: RIP: 0033:0x7f783a22cf4d

i915 shows up there as well, probably not related.
But you might try how things run on https://wiki.archlinux.org/title/Intel_ … _Xe_driver

to be honest i don't even know what starts that process tokio

ps fax

rktmln · 2025-07-29 08:21:04

All I can say about the experimental driver is that I get artifacts when loading Linux and that the system does not start to behave more stably but produces the same artifacts. Regarding the search via ps fax, I cannot find the tokio runtime process

seth · 2025-07-29 14:32:38

Artifacts aside: Have you tried how the wakeup behaves w/ i915 out of the way?

I cannot find the tokio runtime process

tokio-runtime-w from https://github.com/tokio-rs/tokio is a rust runtime thread, it might not unconditionally/permanently present.
Try from the rescue.target if you don't know what might be using that.

rktmln · 2025-07-29 18:07:57

no, except for artifacts with the new driver nothing has changed, the defect is exactly the same. As for tokio, I don't think it is the cause of the problem since it is not always running anyway and it is unlikely to have any effect, I continue to think that the problem is in a conflict with the nvidia driver, but I don't know what exactly.

seth · 2025-07-30 22:22:38

Ok, so let's see whether we can push the mountain over to the prophet…

* blacklist the nvidia modules (certainly nvidia, maybe nvidia_drm)
* Boot the system, check "lsmod | grep nvidia"
*Then run "nvidia-smi". If that fails/doesn't implicitly load the modules, explicitly load nvidia and nvidia_drm, then check nvidia-smi again.
Your display server (X11 or some wayland compositor) should™ not be listed.
* "prime-run glxgears; prime-run glxinfo -B" to make sure the GPU can still be used for offloading
* "modprobe -r nvidia_drm; modprobe -r nvidia" - this should™ work as long as no process is using them
* suspend the system and try to trigger the crash

If this works it can largely be automatized (you'll not be able to keep some game running on the nvidia GPU during the sleep, though)

rktmln · 2025-08-06 10:38:49

Hi, sorry for being gone for so long, I have health issues and had to go to hospitals, lol. So, today I checked what you told me. All I can say is that the nvidia module loads for me even if it is in modprobe blacklist, but nvidia_drm does not load successfully for me and that same defect disappeared, lol. I honestly can't understand why this is happening but for some reason it works, I don't know if it works every time but so far there have been no freezes... very strange to be honest. What do you say, what to do next? I can launch applications on my video card without this component but it seems to me that this is a super strange defect lol.Should i turn it back on and make a script to turn it off before suspend and then turn it back on or should i just leave it as it is?

haha, okay, I take my words back. At first everything worked okay, then the system comes out of sleep, tries to work for a couple of seconds, and then the applications stop responding. By the way, I can't unload the NVIDIA module before going to sleep because they tell me that it is being used by something. Honestly, this is really annoying me lol.

Last edited by rktmln (2025-08-06 10:45:17)

seth · 2025-08-06 19:43:49

the nvidia module loads for me even if it is in modprobe blacklist

If the nvidia module is also in the initramfs you'll have to regenerate that in order to apply any modprobe.conf
Passing "modprobe.blacklist=nvidia,nvidia_drm" to the kernel commandline would cover the initramfs as well.

If you can prevent the modules from loading before the display server starts, the latter should not be listed in nvidia-smi. Is it?
What processes are listed when you cannot unload the modules?

rktmln · 2025-08-07 10:52:01

blocked modules via kernel parameters, when I turn on tty all modules are loaded except nvidia_drm in nvidia-smi there is not a single process and still they do not let me disable the nvidia module, I can not unload it, something is stopping me, lol.

in short, the longer I keep the laptop in sleep mode, the greater the chance that it will freeze if I do something that causes it to freeze lol. Now I tried putting it to sleep, leaving it for a couple of seconds and then turning it on and off the charger, it works fine. The strangest defect lol.

wow, managed to learn even more lol. It turns out that when I do the same thing just in tty, everything remains normal, but as soon as I start using my window manager, the bacchanalia begins and it freezes again when I do a typical sequence of actions, but not immediately, but gradually dies.

So, I tested it several times and it doesn't hang while I'm in tty, it behaves absolutely normally. I honestly don't know what the reason is, lol...I can try using another wm and test if there is a different behavior. I'll tell you the result as soon as I do.

and so, I couldn't launch another wm but it's not that important. I launched btop and closed lid to put the laptop to sleep and then caused the defect, I did all this from tty and still it seems the hero of the occasion is i915 "maybe" pay attention to the photo. GPU 1 - Intel gpu.look at the video card consumption, lol

https://ibb.co/kkLC6PF

by the way just noticed interrupt requests from nvidia and me process, I don't know about the second but the first seems important to me and I honestly don't understand what's going on, lol

Last edited by rktmln (2025-08-07 11:34:36)

rktmln · 2025-08-07 13:17:06

In short, I'm not an expert in this, but it seems to me that there is simply a conflict between the drivers and it turns out to be a complete nightmare. Like, as for me, there is a struggle between the iGPU and dGPU for who gets control when the power profile changes.

seth · 2025-08-07 15:14:34

when I turn on tty all modules are loaded except nvidia_drm

Implies they get actively loaded by likely systemd.
Remove the modules from the MODULES array in your mkinitcpio (the hook adds explicit loads)

in nvidia-smi there is not a single process and still they do not let me disable the nvidia module

What's the output for

sudo modprobe -vr nvidia
lsmod | grep nvidia

So, I tested it several times and it doesn't hang while I'm in tty, it behaves absolutely normally.

The GPU is not in use in this context. it's what we're trying to achieve in the graphical environment.
In doubt some power management daemon or the nvidia-persistenced etc. will open/mmap the device node, forcing the module to remain loaded?

Are there btw. BIOS updates available for the system?

Arch Linux

#1 2025-07-25 17:30:32

Freeze after disconnecting AC after resuming from suspend

#2 2025-07-25 20:24:16

Re: Freeze after disconnecting AC after resuming from suspend

#3 2025-07-26 09:42:58

Re: Freeze after disconnecting AC after resuming from suspend

#4 2025-07-26 14:19:50

Re: Freeze after disconnecting AC after resuming from suspend

#5 2025-07-26 16:18:10

Re: Freeze after disconnecting AC after resuming from suspend

#6 2025-07-26 20:37:40

Re: Freeze after disconnecting AC after resuming from suspend

#7 2025-07-27 07:46:48

Re: Freeze after disconnecting AC after resuming from suspend

#8 2025-07-27 08:18:44

Re: Freeze after disconnecting AC after resuming from suspend

#9 2025-07-28 09:19:43

Re: Freeze after disconnecting AC after resuming from suspend

#10 2025-07-28 12:37:56

Re: Freeze after disconnecting AC after resuming from suspend

#11 2025-07-28 13:30:54

Re: Freeze after disconnecting AC after resuming from suspend

#12 2025-07-28 13:51:00

Re: Freeze after disconnecting AC after resuming from suspend

#13 2025-07-29 06:59:19

Re: Freeze after disconnecting AC after resuming from suspend

#14 2025-07-29 07:47:47

Re: Freeze after disconnecting AC after resuming from suspend

#15 2025-07-29 08:21:04

Re: Freeze after disconnecting AC after resuming from suspend

#16 2025-07-29 14:32:38

Re: Freeze after disconnecting AC after resuming from suspend

#17 2025-07-29 18:07:57

Re: Freeze after disconnecting AC after resuming from suspend

#18 2025-07-30 22:22:38

Re: Freeze after disconnecting AC after resuming from suspend

#19 2025-08-06 10:38:49

Re: Freeze after disconnecting AC after resuming from suspend

#20 2025-08-06 19:43:49

Re: Freeze after disconnecting AC after resuming from suspend

#21 2025-08-07 10:52:01

Re: Freeze after disconnecting AC after resuming from suspend

#22 2025-08-07 13:17:06

Re: Freeze after disconnecting AC after resuming from suspend

#23 2025-08-07 15:14:34

Re: Freeze after disconnecting AC after resuming from suspend

Board footer