I've got a bunch of desktop clients, that seem to be hanging periodically since updating kernel from 3.10.0-327 to 3.10.0-514 (10.2, 21.1 and 21.2)
The only 'hard' evidence I get is occasionally I see events logged locally:
May 19 09:55:10 desktop-132 acpid: 1 client rule loaded
May 19 09:55:20 desktop-132 kernel: lockd: server nfserver not responding, still trying
May 19 09:55:23 desktop-132 kernel: lockd: server nfserver OK
May 19 09:55:23 desktop-132 gnome-session: (gnome-settings-daemon:3367): GLib-GIO-WARNING **: gdbusobjectmanagerclient.c:1586: Processing InterfaceRemoved signal for path /org/gnome/Mutter/IdleMonitor/Device6 but no object proxy exists
May 19 09:55:23 desktop-132 gnome-session: (gnome-settings-daemon:3367): GLib-GIO-WARNING **: gdbusobjectmanagerclient.c:1586: Processing InterfaceRemoved signal for path /org/gnome/Mutter/IdleMonitor/Device7 but no object proxy exists
May 19 09:55:23 desktop-132 gnome-session: (gnome-settings-daemon:3367): GLib-GIO-WARNING **: gdbusobjectmanagerclient.c:1586: Processing InterfaceRemoved signal for path /org/gnome/Mutter/IdleMonitor/Device8 but no object proxy exists
May 19 09:55:23 desktop-132 gnome-session: (gnome-settings-daemon:3367): GLib-GIO-WARNING **: gdbusobjectmanagerclient.c:1586: Processing InterfaceRemoved signal for path /org/gnome/Mutter/IdleMonitor/Device9 but no object proxy exists
May 19 09:55:23 desktop-132 gnome-session: (gnome-settings-daemon:3367): GLib-GIO-WARNING **: gdbusobjectmanagerclient.c:1586: Processing InterfaceRemoved signal for path /org/gnome/Mutter/IdleMonitor/Device10 but no object proxy exists
May 19 09:55:23 desktop-132 gnome-session: Window manager warning: last_user_time (946497320) is greater than comparison timestamp (946495968). This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW. Trying to work around...
May 19 09:55:23 desktop-132 gnome-session: Window manager warning: 0x2000007 (user@d) appears to be one of the offending windows with a timestamp of 946497320. Working around...
I am pretty sure that this problem is only being encountered on this kernel version - only stuff that's been updated is showing it, and downgrading to 3.10.0-327 again makes the problem go away.
Of course, that's not a help, because we're updating because of security fixes.
The problem still seems to be present on the current kernel version released just a couple of days ago.
But I'm at something of a loss - I've got nothing being logged, just 'lockups' that I'm trying to track. So I've not even got the basics I need to start filing a bug report.
