[SOLVED] Cannot login after suspend

michael8rown · 2023-02-15 14:24:04

Over the last few weeks, I've been unable to login to my laptop after suspend. When I open the lid, the only thing I see on the screen is the line:

__common_interrupt: 1.55 No irq handler for vector

I often see this same message flash briefly on the screen just before the GNOME login screen kicks in, but lately I'll get stuck at a blank screen with just that message in the top corner. The cursor does not show up, either. Sometimes, like this morning, there will be 2 or 3 lines of that same message:

__common_interrupt: 1.55 No irq handler for vector
__common_interrupt: 1.55 No irq handler for vector
__common_interrupt: 1.55 No irq handler for vector

I plan to look for more information about the common_interrupt problem later, but right now my bigger concern is how to force GNOME login to activate at times like this. Since I cannot get to a login screen, the only option I've found that works is holding down the power button until the machine powers off. I don't want to have to do that every time this happens, especially since it's been happening a lot lately. I've tried all the old standbys of Ctrl-F[0-9], ESC, Ctrl-Alt-Delete, spacebar, any-damn-key! and nothing works. All I can do is hold the power button down.

I've been running Arch on this laptop for a couple years now and have not had this issue before. I recently installed a new SATA SSD and did a clean install of Arch. I'm just giving some background in case it matters. GNOME version is 43.2. This happens in both the arch kernel and the lts kernel.

I seem to have some information in my logs, but I'm not sure if any of this matters:

Feb 14 20:28:11 arch systemd-logind[273]: Lid closed.
Feb 14 20:28:11 arch systemd-logind[273]: Suspending...
...
Feb 14 20:28:11 arch gnome-shell[1097]: g_signal_handler_disconnect: assertion 'handler_id > 0' failed
...
Feb 14 20:28:17 arch /usr/lib/gdm-x-session[1028]: (II) systemd-logind: got pause for 13:69
...
Feb 14 20:28:37 arch /usr/lib/gdm-x-session[1028]: (II) systemd-logind: got resume for 226:0
Feb 14 20:28:57 arch kernel: Freezing user space processes ... 
Feb 14 20:28:57 arch kernel: Freezing of tasks failed after 20.010 seconds (1 tasks refusing to freeze, wq_busy=0):
Feb 14 20:28:57 arch kernel: task:gsd-housekeepin state:D stack:    0 pid: 1278 ppid:  1001 flags:0x00004006
...
Feb 14 20:28:58 arch systemd-sleep[13861]: Failed to put system to sleep. System resumed again: Device or resource busy
Feb 14 20:28:58 arch gdm[287]: GLib: Source ID 108 was not found when attempting to remove it
Feb 14 20:28:58 arch kernel: PM: suspend exit
Feb 14 20:28:58 arch kernel: rfkill: input handler disabled
..
Feb 14 20:28:58 arch systemd[1]: systemd-suspend.service: Main process exited, code=exited, status=1/FAILURE
Feb 14 20:28:58 arch systemd[1]: systemd-suspend.service: Failed with result 'exit-code'.
Feb 14 20:28:58 arch systemd[1]: Failed to start System Suspend.
Feb 14 20:28:58 arch systemd[1]: Dependency failed for Suspend.
Feb 14 20:28:58 arch systemd[1]: suspend.target: Job suspend.target/start failed with result 'dependency'.
Feb 14 20:28:58 arch systemd[1]: systemd-suspend.service: Consumed 3.011s CPU time.
Feb 14 20:28:58 arch systemd[1]: Stopped target Sleep.
Feb 14 20:28:58 arch audit[1]: SERVICE_START pid=1 uid=0 auid=xxxxxxxxx ses=xxxxxxxxx msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Feb 14 20:28:58 arch systemd-logind[273]: Operation 'sleep' finished.
...
Feb 14 20:44:08 arch systemd-sleep[18707]: Entering sleep state 'suspend'...
Feb 14 20:44:08 arch kernel: PM: suspend entry (deep)
Feb 14 20:44:08 arch kernel: Filesystems sync: 0.016 seconds
Feb 14 20:44:08 arch /usr/lib/gdm-x-session[1028]: (II) AIGLX: Suspending AIGLX clients for VT switch
Feb 14 20:44:08 arch kernel: rfkill: input handler enabled
Feb 14 20:44:28 arch kernel: Freezing user space processes ... 
Feb 14 20:44:28 arch kernel: Freezing of tasks failed after 20.014 seconds (1 tasks refusing to freeze, wq_busy=0):
Feb 15 05:23:36 arch kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Feb 15 05:23:36 arch kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
Feb 15 05:23:36 arch kernel: sd 0:0:0:0: [sda] Stopping disk
Feb 15 05:23:36 arch kernel: ACPI: EC: interrupt blocked
Feb 15 05:23:36 arch kernel: ACPI: EC: interrupt unblocked
Feb 15 05:23:36 arch kernel: sd 0:0:0:0: [sda] Starting disk
...
Feb 15 05:23:36 arch kernel: OOM killer enabled.
Feb 15 05:23:36 arch kernel: Restarting tasks ... done.
...
Feb 15 05:23:36 arch systemd-logind[273]: Lid opened.
...
Feb 15 05:23:37 arch systemd[1]: Stopped target Sleep.
Feb 15 05:23:37 arch systemd[1]: Reached target Suspend.
Feb 15 05:23:37 arch systemd[1]: Stopped target Suspend.
Feb 15 05:23:37 arch systemd-logind[273]: Operation 'sleep' finished.
...
and then I hold down the power button at 
Feb 15 05:23:53

Sometimes the power button option gets logged, too:

Feb 13 05:45:42 arch systemd-logind[401]: Power key pressed short.

But not always.

I have all my journals so if you want any other information from them, just tell me what to look for.

Thanks in advance for any help you can offer!

Last edited by michael8rown (2023-02-17 22:03:09)

V1del · 2023-02-15 15:05:47

Check whether you can "safely" reboot with REISUB when the crash happens (pause 2-3 secs between each keypress): https://wiki.archlinux.org/title/Keyboa … el_(SysRq)

If you could - and for that matter even if you couldn't - post the full journal for the boot having the issue

sudo journalctl -b-1

michael8rown · 2023-02-15 15:50:18

Thanks. I have created a file /etc/sysctl.d/99-sysctl.conf with the line

kernel.sysrq = 1

Running

sudo sysctl --system

I see

 * Applying /etc/sysctl.d/99-sysctl.conf ...
kernel.sysrq = 1

at the bottom. So I presume that means it's enabled now. I do not have a key on my keyboard that says "SysRq", but I do have a PrtSc key. I just tested it by holding down Alt+PrtSc+b which rebooted my system. So I presume that means it works. The next time this issue happens, I will try to work through the various magic key combinations. and I will post the journal as you've recommended.

If you'd like to see the journal from when I hard-shutdown the system this morning, let me know.

seth · 2023-02-15 16:38:16

I've tried all the old standbys of Ctrl-F[0-9], ESC, Ctrl-Alt-Delete, spacebar, any-damn-key! and nothing works

ctr+alt+F[0-9] and if that doesn't work the kernel or at least the graphics stack stalled.

I seem to have some information in my logs, but I'm not sure if any of this matters:

Please post your complete system journal for the boot: eg.

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

for the previous one.
The stuff behind the ellipsis is probably relevant in some capacity.

I recently installed a new SATA SSD and did a clean install of Arch.

NVMe?
https://wiki.archlinux.org/title/Solid_ … nd_support

Edit: Ok, I didn't F5 this for faaaaar to long

Last edited by seth (2023-02-15 16:39:16)

michael8rown · 2023-02-15 17:05:50

seth wrote:

ctr+alt+F[0-9] and if that doesn't work the kernel or at least the graphics stack stalled.

I do see some

task:gsd-housekeepin state:D stack:

messages that only just started on Feb 10. (This fresh install occurred on Jan 28.)

Please post your complete system journal for the boot: eg.
sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st
for the previous one.
The stuff behind the ellipsis is probably relevant in some capacity.

Journal from Feb 13-15, at the end of which the most recent freeze occurred: http://0x0.st/HrYf.txt
Journal from this morning after I held down the power button: http://0x0.st/HrY9.txt

NVMe?

No, it's a SAMSUNG 870 EVO SATA III SSD.

seth · 2023-02-15 17:19:30

Feb 14 20:28:37 arch kernel: Freezing of tasks failed after 20.006 seconds (1 tasks refusing to freeze, wq_busy=0):
Feb 14 20:28:37 arch kernel: task:gsd-housekeepin state:D stack:    0 pid: 1278 ppid:  1001 flags:0x00004006
Feb 14 20:28:37 arch kernel: Call Trace:
Feb 14 20:28:37 arch kernel:  <TASK>
Feb 14 20:28:37 arch kernel:  __schedule+0x37f/0x1540
Feb 14 20:28:37 arch kernel:  schedule+0x5b/0xe0
Feb 14 20:28:37 arch kernel:  request_wait_answer+0xd9/0x2a0 [fuse 9b963ee0dd5b8b2634e8af34d8af7e9a34d36749]
Feb 14 20:28:37 arch kernel:  ? finish_wait+0x90/0x90
Feb 14 20:28:37 arch kernel:  fuse_simple_request+0x191/0x2f0 [fuse 9b963ee0dd5b8b2634e8af34d8af7e9a34d36749]
Feb 14 20:28:37 arch kernel:  fuse_statfs+0xeb/0x150 [fuse 9b963ee0dd5b8b2634e8af34d8af7e9a34d36749]
Feb 14 20:28:37 arch kernel:  statfs_by_dentry+0x67/0x90
Feb 14 20:28:37 arch kernel:  user_statfs+0x67/0xd0
Feb 14 20:28:37 arch kernel:  __do_sys_statfs+0x35/0x70
Feb 14 20:28:37 arch kernel:  do_syscall_64+0x5b/0x80
Feb 14 20:28:37 arch kernel:  ? exit_to_user_mode_prepare+0x12b/0x170
Feb 14 20:28:37 arch kernel:  ? syscall_exit_to_user_mode+0x23/0x50
Feb 14 20:28:37 arch kernel:  ? do_syscall_64+0x67/0x80
Feb 14 20:28:37 arch kernel:  ? syscall_exit_to_user_mode+0x23/0x50
Feb 14 20:28:37 arch kernel:  ? do_syscall_64+0x67/0x80
Feb 14 20:28:37 arch kernel:  ? syscall_exit_to_user_mode+0x23/0x50
Feb 14 20:28:37 arch kernel:  ? do_syscall_64+0x67/0x80
Feb 14 20:28:37 arch kernel:  entry_SYSCALL_64_after_hwframe+0x61/0xcb
Feb 14 20:28:37 arch kernel: RIP: 0033:0x7fc8f66df27b
Feb 14 20:28:37 arch kernel: RSP: 002b:00007ffdb025f178 EFLAGS: 00000246 ORIG_RAX: 0000000000000089
Feb 14 20:28:37 arch kernel: RAX: ffffffffffffffda RBX: 000055efb6da8f48 RCX: 00007fc8f66df27b
Feb 14 20:28:37 arch kernel: RDX: 000055eae8207f4a RSI: 00007ffdb025f180 RDI: 000055efb6db1210
Feb 14 20:28:37 arch kernel: RBP: 00007ffdb025f180 R08: 000055efb6d8af00 R09: 0000000000000000
Feb 14 20:28:37 arch kernel: R10: 00007fc8f675b560 R11: 0000000000000246 R12: 000055efb6da8f40
Feb 14 20:28:37 arch kernel: R13: 000055efb6db11e0 R14: 000055efb6db1210 R15: 00007ffdb025f2d8
Feb 14 20:28:37 arch kernel:  </TASK>
Feb 14 20:28:37 arch kernel:

Some fuse mount doesn't respond.

mount

But that might be due to the gsd-housekeeping process, https://gitlab.gnome.org/GNOME/gnome-se … ote_994079

michael8rown · 2023-02-15 17:33:49

I think that might be related to an fstab entry I've added recently to connect to a drive on my home network at startup. I can get rid of that and just mount it the old fashioned way when I actually need to access that drive, but could that be preventing login after suspend?

seth · 2023-02-15 17:57:14

It's hard to guess the wider impact of stalled IO, but it can theoretically block a lot of things that desire to access that mount.
You'll figure after removing the mount.
What fuse implementation is this btw?

michael8rown · 2023-02-15 18:31:04

What fuse implementation is this btw?

I've got

fuse2 2.9.9-4
fuse3 3.13.1-1
fuse-common 3.13.1-1

installed.

fusermount -V
fusermount version: 2.9.9

The call being made in fstab is

 ... fuse.sshfs x-systemd.automount,_netdev,user,idmap=user,transform_symlinks,allow_other,default_permissions ... 0 0

But I've removed that fstab entry for now to see if things improve.

EDIT:

I also have sshfs installed.

$ sshfs -v
SSHFS version 3.7.3
FUSE library version 3.13.0
user FUSE kernel interface 7.38
fusermount3 version: 3.13.0

Last edited by michael8rown (2023-02-15 18:35:26)

michael8rown · 2023-02-17 22:02:43

I believe this issue has been resolved. I removed the fstab entry for fuse.sshfs mount and reverted to mounting that volume on demand instead. Since then, I haven't had any lockups, and no more Call Trace: messages in the journal either. I'm not sure exactly how that caused my problem, but as seth said: "It's hard to guess the wider impact of stalled IO".

Thanks again for your help!

Arch Linux

#1 2023-02-15 14:24:04

[SOLVED] Cannot login after suspend

#2 2023-02-15 15:05:47

Re: [SOLVED] Cannot login after suspend

#3 2023-02-15 15:50:18

Re: [SOLVED] Cannot login after suspend

#4 2023-02-15 16:38:16

Re: [SOLVED] Cannot login after suspend

#5 2023-02-15 17:05:50

Re: [SOLVED] Cannot login after suspend

#6 2023-02-15 17:19:30

Re: [SOLVED] Cannot login after suspend

#7 2023-02-15 17:33:49

Re: [SOLVED] Cannot login after suspend

#8 2023-02-15 17:57:14

Re: [SOLVED] Cannot login after suspend

#9 2023-02-15 18:31:04

Re: [SOLVED] Cannot login after suspend

#10 2023-02-17 22:02:43

Re: [SOLVED] Cannot login after suspend

Board footer