Freeze after resume

[IronRod]

I'm experiencing occasional freeze after resume from sleep. The most recent episode the lock screen appeared, I entered my password, pressed [Enter] and the screen froze; zero response. I reset the computer (reset button) and, instead of "LinxuMint..." the grub menu showed "ubunutu". I selected that, and it booted fine. (NOTE: I've seen that grub behavior once before after a previous freeze. After the successful reboot I saw a normal "LinuxMint..." entry in grub with the next boot.)

Checking the recent boot entries:

Code: Select all

$ last -x | head | tac
reboot   system boot  5.15.0-97-generi Fri Feb 23 09:30 - 13:56  (04:25)
runlevel (to lvl 5)   5.15.0-97-generi Fri Feb 23 09:30 - 13:56  (04:25)
...      tty7         :0               Fri Feb 23 09:30 - 13:55  (04:25)
shutdown system down  5.15.0-97-generi Fri Feb 23 13:56 - 07:05  (-6:50)
reboot   system boot  5.15.0-97-generi Fri Feb 23 07:05   still running
runlevel (to lvl 5)   5.15.0-97-generi Fri Feb 23 13:56 - 22:13  (08:17)
...      tty7         :0               Fri Feb 23 13:56 - crash  (08:17)
reboot   system boot  5.15.0-97-generi Fri Feb 23 22:13   still running
runlevel (to lvl 5)   5.15.0-97-generi Fri Feb 23 22:13   still running
...      tty7         :0               Fri Feb 23 22:13    gone - no logout

And at the time of the above crash entry, I find this entry in syslog:

Code: Select all

Feb 23 22:13:56 brawn pulseaudio[2199]: GetManagedObjects() failed: org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)

I know I received updates of org.freedesktop over the last couple dates; at least once today and once yesterday. But I've been seeing this freeze situation infrequently for the last week or so. Is there some debug log for `freedesktop` I can check?

[IronRod]

UPDATE: It happened again. This time, I decided to try Ctrl-Alt-F2 and this successively started getty on tty2 and I was able to login. I began looking around and found a couple things in syslog -- and then it switched back to the GUI on tty7 and I was up and running. So, it is freezing the GUI but something is happening in the background and it does wake-up if I allow it sufficient time.

The following entries from syslog may be informative; not sure. It ends the suspend, hits resume for Nvidia then a bunch of "Recovering from system lockup", followed by a coredump.

Code: Select all

Feb 24 14:21:51 brawn systemd[1]: Finished System Suspend.
Feb 24 14:21:51 brawn systemd[1]: Stopped target Sleep.
Feb 24 14:21:51 brawn systemd[1]: Reached target Suspend.
Feb 24 14:21:51 brawn systemd[1]: Starting NVIDIA system resume actions...
Feb 24 14:21:51 brawn systemd[1]: Stopped target Suspend.
Feb 24 14:21:51 brawn ModemManager[1269]: <info>  [sleep-monitor-systemd] system is resuming
Feb 24 14:21:51 brawn NetworkManager[1182]: <info>  [1708813311.2731] manager: sleep: wake requested (sleeping: yes  enabled: yes)
Feb 24 14:21:51 brawn NetworkManager[1182]: <info>  [1708813311.2731] device (eno1): state change: unmanaged -> unavailable (reason 
'managed', sys-iface-state: 'external')
Feb 24 14:21:51 brawn logger[10287]: <13>Feb 24 14:21:51 suspend: nvidia-resume.service
Feb 24 14:21:51 brawn suspend: nvidia-resume.service
Feb 24 14:21:51 brawn acpid: client 1927[0:0] has disconnected
Feb 24 14:21:51 brawn systemd[1]: nvidia-resume.service: Deactivated successfully.
Feb 24 14:21:51 brawn systemd[1]: Finished NVIDIA system resume actions.
Feb 24 14:21:51 brawn rtkit-daemon[1968]: Supervising 0 threads of 0 processes of 0 users.
Feb 24 14:21:51 brawn rtkit-daemon[1968]: Recovering from system lockup, not allowing further RT threads.
Feb 24 14:21:51 brawn rtkit-daemon[1968]: Supervising 0 threads of 0 processes of 0 users.
Feb 24 14:21:51 brawn rtkit-daemon[1968]: Recovering from system lockup, not allowing further RT threads.
Feb 24 14:21:51 brawn rtkit-daemon[1968]: Supervising 0 threads of 0 processes of 0 users.
Feb 24 14:21:51 brawn rtkit-daemon[1968]: Recovering from system lockup, not allowing further RT threads.
Feb 24 14:21:51 brawn rtkit-daemon[1968]: Supervising 0 threads of 0 processes of 0 users.
Feb 24 14:21:51 brawn rtkit-daemon[1968]: Recovering from system lockup, not allowing further RT threads.
Feb 24 14:21:51 brawn rtkit-daemon[1968]: Supervising 0 threads of 0 processes of 0 users.
Feb 24 14:21:51 brawn rtkit-daemon[1968]: Recovering from system lockup, not allowing further RT threads.
Feb 24 14:21:51 brawn kernel: [11066.013477] RTL8226B_RTL8221B 2.5Gbps PHY r8169-0-700:00: attached PHY driver (mii_bus:phy_addr=r8169-0-700:00, irq=MAC)
Feb 24 14:21:51 brawn NetworkManager[1182]: <info>  [1708813311.4997] manager: NetworkManager state is now DISCONNECTED
Feb 24 14:21:51 brawn kernel: [11066.213612] r8169 0000:07:00.0 eno1: Link is Down
Feb 24 14:21:51 brawn systemd[1]: Created slice Slice /system/systemd-coredump.
Feb 24 14:21:51 brawn systemd[1]: Started Process Core Dump (PID 10294/UID 0).
Feb 24 14:21:53 brawn systemd-coredump[10295]: Process 1927 (Xorg) of user 0 dumped core.#012#012Found module linux-vdso.so.1 with build-id: 

The full output is here: https://termbin.com/119z

dmesg highlights these entries in red:

Code: Select all

[11070.518507] [drm:nv_drm_master_set [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000900] Failed to grab modeset ownership
[11187.393817] CIFS: VFS: \\media has not responded in 180 seconds. Reconnecting...
[11194.561675] CIFS: VFS: \\media has not responded in 180 seconds. Reconnecting...
[11196.064783] [drm:nv_drm_master_set [nvidia_drm]] *ERROR* [nvidia-drm] [GPU ID 0x00000900] Failed to grab modeset ownership

Maybe I should try an earlier Nvidia driver? Although, I read Nvidia has a new driver coming out. (NOTE: I am having to use the Nvidia driver instead of nouveau because the Android emulator will not run in hardware mode without using the Nvidia driver.)

[IronRod]

UPDATE: It happened again this morning. Note that it doesn't freeze immediately. The system awakens and brings up the login prompt. The mouse works, everything seems operational. Then I enter my password and press enter -- then it freezes. This time, given what I saw last time, I just waited for a minute or so but it still didn't unfreeze. So I hit Ctrl-Alt-F2 and saw a lot of what appeared to be syslog messages and this one at the bottom of the screen:

Code: Select all

CIFS: VFS: \\media has not responded in 180 seconds. Reconnecting...

Just as I was going to hit Ctrl-Alt-F7 (but before I did), the system unfroze and displayed the GUI.

Given that message -- which I also saw in the last syslog -- I'm thinking this issue may be related to having a lot of devices mounted at boot. (But the system didn't used to do this and I have not changed the number of devices being mounted. So there must be some recent update that led to this.) Searching around, I found this page viewtopic.php?t=190961 which is a little different than my issue but sounds similar.

I looked at /etc/fstab and noticed that it looks dramatically different than when I last looked at it and added the mounts for the above drives. Currently, it looks like this:

Code: Select all

# <file system> <mount point> <type> <options> <dump> <pass>

UUID=fa53fe16-5f6b-462a-a7c4-4417ee1c3202	/	ext4	noatime,errors=remount-ro	0	1
UUID=ECAB-629B	/boot/efi	vfat	umask=0077	0	1
/swapfile	none	swap	sw	0	0
UUID="56A098E57084D8CB"	/media/rod/Storage	ntfs	defaults,noatime	0	0
UUID="72BAC31E0EB2B6AF"	/media/rod/Development	ntfs	defaults,noatime	0	0
UUID="7ED3A86316B4A75E"	/media/rod/Videos	ntfs	defaults,noatime	0	0
UUID="70F545626369B03E"	/media/rod/Games	ntfs	defaults,noatime	0	0
UUID="7A0D8B350486CE16"	/media/rod/Temp	ntfs	defaults,noatime	0	0
//media/Music	/media/rod/Media-Music	cifs	vers=3.0,uid=rod,credentials=/home/rod/.samba_cred,_netdev	0	0
//media/Videos	/media/rod/Media-Videos	cifs	vers=3.0,uid=rod,credentials=/home/rod/.samba_cred,_netdev	0	0
//media/Pictures	/media/rod/Media-Pictures	cifs	vers=3.0,uid=rod,credentials=/home/rod/.samba_cred,_netdev	0	0
//media/Xfer	/media/rod/Media-Xfer	cifs	vers=3.0,uid=rod,credentials=/home/rod/.samba_cred,_netdev	0	0

But checking through my Timeshift snapshots, it was previously like this:

Code: Select all

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/nvme0n1p5 during installation
UUID=fa53fe16-5f6b-462a-a7c4-4417ee1c3202 /               ext4    noatime,errors=remount-ro 0       1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=ECAB-629B  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw              0       0

# NTFS drives on the system
UUID="56A098E57084D8CB" /media/rod/Storage ntfs defaults,noatime 0 0
UUID="72BAC31E0EB2B6AF" /media/rod/Development ntfs defaults,noatime 0 0
UUID="7ED3A86316B4A75E" /media/rod/Videos ntfs defaults,noatime 0 0
UUID="70F545626369B03E" /media/rod/Games ntfs defaults,noatime 0 0
UUID="7A0D8B350486CE16" /media/rod/Temp ntfs defaults,noatime 0 0

# Windows shares on the network
//media/Music /media/rod/Media-Music cifs vers=3.0,uid=rod,credentials=/home/rod/.samba_cred,_netdev 0 0
//media/Videos /media/rod/Media-Videos cifs vers=3.0,uid=rod,credentials=/home/rod/.samba_cred,_netdev 0 0
//media/Pictures /media/rod/Media-Pictures cifs vers=3.0,uid=rod,credentials=/home/rod/.samba_cred,_netdev 0 0
//media/Xfer /media/rod/Media-Xfer cifs vers=3.0,uid=rod,credentials=/home/rod/.samba_cred,_netdev 0 0

So, something definitely changed this since that snapshot. But later snapshots from more than a week back also show this "new" formatted /etc/fstab and I did not experience this freezing issue until the last few days.

[IronRod]

UPDATE: I took another TimeShift snapshot then I retrieved the old fstab from a previous snapshot and pasted its content into my existing fstab. I have not had the freeze since doing this. Still no idea what changed the contents of my fstab, especially since it replaced all blanks (which were previously spaces) with tabs.

I will keep monitoring. NOTE: Clearly, no one is looking at this but me. But it is a place to record what I've experienced and it may be helpful to someone in the future. Maybe I should have put this in another forum...

[SMG]

I will keep monitoring. NOTE: Clearly, no one is looking at this but me. But it is a place to record what I've experienced and it may be helpful to someone in the future. Maybe I should have put this in another forum...

No, you put it in the correct forum. I have been following, but have not had a chance until now to spend enough time with it to be able to post. You did a good job investigating and perhaps your documentation will help others in the future.

[IronRod]

You did a good job investigating and perhaps your documentation will help others in the future.

Thx. Since restoring /etc/fstab, it has not happened again and the file has not been changed again. Any guesses as to what would have changed it in that way? Just really weird.

[SMG]

Any guesses as to what would have changed it in that way? Just really weird.

I do not normally work with issues which might change fstab so I do not have any ideas.

Maybe someone else will have some ideas.

[SMG]

Since restoring /etc/fstab, it has not happened again and the file has not been changed again. Any guesses as to what would have changed it in that way?

You might want to follow along this topic What edited my "fstab"? for possible ideas.

[IronRod]

You might want to follow along this topic What edited my "fstab"? for possible ideas.

Thank you for referring that thread. In my case, I always edit fstab manually using an editor (micro) from a terminal. I've never intentionally edited it any other way but I can see how some tool I may've used could have altered the file. Going forward, I'll be more cognizant of how steps I might be taking in some disk-related tool could be affecting fstab and monitor it for changes.