Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #64213 > unrolled thread

Bug#929943: linux-image-4.19.0-5-amd64: NFS handle leak? Suspend-to-RAM inhibition

Started byPhilipp Marek <philipp@marek.priv.at>
First post2019-06-03 21:30 +0200
Last post2019-06-16 15:50 +0200
Articles 2 — 1 participant

Back to article view | Back to linux.debian.kernel


Contents

  Bug#929943: linux-image-4.19.0-5-amd64: NFS handle leak? Suspend-to-RAM inhibition Philipp Marek <philipp@marek.priv.at> - 2019-06-03 21:30 +0200
    Bug#929943: linux-image-4.19.0-5-amd64: NFS handle leak? Suspend-to-RAM inhibition Philipp Marek <philipp@marek.priv.at> - 2019-06-16 15:50 +0200

#64213 — Bug#929943: linux-image-4.19.0-5-amd64: NFS handle leak? Suspend-to-RAM inhibition

FromPhilipp Marek <philipp@marek.priv.at>
Date2019-06-03 21:30 +0200
SubjectBug#929943: linux-image-4.19.0-5-amd64: NFS handle leak? Suspend-to-RAM inhibition
Message-ID<y50OB-6LM-1@gated-at.bofh.it>
Package: src:linux
Version: 4.19.37-3
Severity: normal

Sequence of events:

 1. Notebook is rebooted properly, used for work for some hours
 2. Notebook lid was closed, STR works as usual
 3. Notebook opened; some work; lid close, STR works
 4. Notebook was opened; NFS4 from remote machine mounted
 5. Files copied around
 6. NFS server stopped (data only temporarily shared)
 7. NFS unmounted via "umount dir/", returns immediately to shell
 7. I remember that I stopped the server already, "umount dir/ -f &"
 9. Closing the lid
 6. About half an hour later I take the notebook from my bag and see that 
    it's still running
10. I see the messages about NFS
11. I start NFS again for a clean umount - but it's not mounted any more, 
    so there's nothing to umount
12. Manual "acpitool -s" (twice) doesn't work (19:34:26)
13. I stop the NFS server again
14. Closing the lid still doesn't work
15. I start NFS again
16. At 20:00 an "at" job stops the NFS server again
17. MUCH LATER one of the backgrounded "acpitool -s" seems to work, 
    notebook gets suspended while I'm working with it
18. Something's still thinking that NFS is mounted


Here's some log data, shortened/annotated:

  16:24:14  2. PM: suspend entry (deep)
  16:24:14     PM: Syncing filesystems ... done.
  16:49:34  3. PM: suspend exit
  17:13:53  "  PM: suspend entry (deep)
  18:23:36  "  PM: Syncing filesystems ... done.
  18:23:36  4. PM: suspend exit
  18:41:39  9. PM: suspend entry (deep)
  18:43:31     PM: Syncing filesystems ...
  18:45:12 10. INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  18:47:13     INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  18:49:14     INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  18:51:14     INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  18:53:15     INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  18:55:16     INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  18:57:17     INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  18:59:18     INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  19:01:19     INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  19:03:19     INFO: task systemd-sleep:3057 blocked for more than 120 seconds.
  19:32:34 11. nfs: server rpi3 OK
  19:34:26 12. PM: suspend entry (deep)
  19:34:26     PM: suspend exit
  19:34:30     PM: suspend entry (deep)
  19:34:30     PM: suspend exit
  19:37:09 14. PM: suspend entry (deep)
  19:37:09     PM: suspend exit
  19:40:27 15. nfs: server rpi3 OK
  20:52:49 17. done.
  20:52:49     Freezing user space processes ... (elapsed 0.029 seconds) done.                                                                                   
  20:52:49 18. PM: suspend exit                                 
  20:55:33     nfs: server rpi3 not responding, timed out


I know this is not that easy to understand; still, I hope it's 
reproducible.

Thank you!


-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 root=/dev/mapper/n555--vg-root ro initrd=/install/initrd.gz quiet

** Not tainted

[toc] | [next] | [standalone]


#64269

FromPhilipp Marek <philipp@marek.priv.at>
Date2019-06-16 15:50 +0200
Message-ID<y9DHI-3bd-5@gated-at.bofh.it>
In reply to#64213
Hmmm, while there surely was something fishy about the NFS delay, I'm 
not sure whether that was the sole problem for the suspend issues.

Two more reboots later, without having NFS mounted all the time, suspend 
doesn't work all the time - I've had the notebook running
happily (and hot) 3 times in the backpack, simply closing the lid didn't 
work.


Taking it out, running "acpitool -s" did work, though --
so it might be a userspace issue (lxqt => dbus => some daemon?), or 
broken lid detection, or...

The previous 4.19.0-5-amd64 didn't have these suspend issues.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.kernel


csiph-web