Public bug reported:
Hi, I have this weird bug in mutter (44.2-0ubuntu1) which seems to
correlate with uptime - if I kill mutter the problem seems to go away
for a few days, although killing mutter is very inconvenient because all
applications are also killed even with session persistence.
Upon strace analysis it can be seen that when the pauses are happening
there is a specific trace involving GEM operations happening immediately
after a ~1 second epoll expires.
During this state the entire UI is paused - video does not update, mouse
cursor does not move, keypresses have no response. However, input
events are "queued" so that when the pause ends, the mouse instantly
warps across the screen, and if a key was down at the time the pause
began, the key is repeated hundreds of times since it seems that the
key-up event is only processed when the "pause" ends.
The system is up to date 23.04 and mutter is using the Intel HD 530
integrated graphics. I do not believe this issue happened before 23.04
was released, although it has been intermittent and persistent since
that time.
Attached a strace with timestamps which provides an example of a multi-
second pause. Using grep -A1 epoll_wait you can see the instances of
the GEM operations during the pause. Eventually at around 09:40:57
local time in the trace the "pause" ended.
Example of an instance of the GEM operation trace after a ~1 second
epoll timeout:
[pid 686436] 09:40:54.750468 poll([{fd=3, events=POLLOUT}], 1, 5) = 1 ([{fd=3,
revents=POLLOUT}])
[pid 686436] 09:40:54.750719 epoll_wait(8, [], 256, 671) = 0
[pid 686436] 09:40:55.422886 ioctl(11, DRM_IOCTL_SYNCOBJ_DESTROY,
0x7ffce0975140) = 0
[pid 686436] 09:40:55.423213 ioctl(11, DRM_IOCTL_I915_GEM_EXECBUFFER2,
0x7ffce09751d0) = 0
[pid 686436] 09:40:55.423525 ioctl(11, DRM_IOCTL_I915_GEM_MADVISE,
0x7ffce0975098) = 0
[pid 686436] 09:40:55.423642 ioctl(11, DRM_IOCTL_SYNCOBJ_WAIT, 0x7ffce0974ef0)
= 0
[pid 686436] 09:40:55.423876 ioctl(11, DRM_IOCTL_I915_GEM_MADVISE,
0x7ffce0974fec) = 0
[pid 686436] 09:40:55.423971 ioctl(11, DRM_IOCTL_SYNCOBJ_CREATE,
0x7ffce0975100) = 0
[pid 686436] 09:40:55.424218 writev(45,
[{iov_base="#\221\360s\0\0\0\0\2\0\0\0\204\v \4\3\0\200\3s\213\0\0\243\v
\4\244\v \4", iov_len=32}], 1) = 32
[pid 686436] 09:40:55.424471 writev(45,
[{iov_base="#\221\360s\2\0\0\0\1\0\0\2\204\v
\4\3\0\200\3r\213\0\0\376S\340\252\37\2\0\0\311uf\0\0\0\0\0", iov_len=40}], 1)
= 40
[pid 686436] 09:40:55.424810 poll([{fd=3, events=POLLOUT}], 1, 5) = 1 ([{fd=3,
revents=POLLOUT}])
[pid 686436] 09:40:55.425150 epoll_wait(8, [], 256, 0) = 0
These pauses are often 10-15 seconds in length but can also be much
longer. I have observed it happening even with the screen locked
(screen lock unresponsive until pause ends).
FD 8 in the trace is anon_inode:[eventpoll] and FD 11 is
/dev/dri/renderD129, the Intel HD 530 DRI device.
Kernel is 6.2.0-24-generic from the distribution.
** Affects: mutter (Ubuntu)
Importance: Undecided
Status: New
** Attachment added: "strace.txt"
https://bugs.launchpad.net/bugs/2025662/+attachment/5683579/+files/strace.txt
** Description changed:
Hi, I have this weird bug in mutter which seems to correlate with uptime
- if I kill mutter the problem seems to go away for a few days, although
killing mutter is very inconvenient because all applications are also
killed even with session persistence.
Upon strace analysis it can be seen that when the pauses are happening
there is a specific trace involving GEM operations happening immediately
- after a 1 second epoll expires.
+ after a ~1 second epoll expires.
During this state the entire UI is paused - video does not update, mouse
cursor does not move, keypresses have no response. However, input
events are "queued" so that when the pause ends, the mouse instantly
warps across the screen, and if a key was down at the time the pause
began, the key is repeated hundreds of times since it seems that the
key-up event is only processed when the "pause" ends.
The system is up to date 23.04 and mutter is using the Intel HD 530
integrated graphics. I do not believe this issue happened before 23.04
was released, although it has been intermittent and persistent since
that time.
Attached a strace with timestamps which provides an example of a multi-
second pause. Using grep -A1 epoll_wait you can see the instances of
the GEM operations during the pause. Eventually at around 09:40:57
local time in the trace the "pause" ended.
- Example of an instance of the GEM operation trace after a 1 second epoll
- timeout:
+ Example of an instance of the GEM operation trace after a ~1 second
+ epoll timeout:
[pid 686436] 09:40:54.750468 poll([{fd=3, events=POLLOUT}], 1, 5) = 1
([{fd=3, revents=POLLOUT}])
[pid 686436] 09:40:54.750719 epoll_wait(8, [], 256, 671) = 0
[pid 686436] 09:40:55.422886 ioctl(11, DRM_IOCTL_SYNCOBJ_DESTROY,
0x7ffce0975140) = 0
[pid 686436] 09:40:55.423213 ioctl(11, DRM_IOCTL_I915_GEM_EXECBUFFER2,
0x7ffce09751d0) = 0
[pid 686436] 09:40:55.423525 ioctl(11, DRM_IOCTL_I915_GEM_MADVISE,
0x7ffce0975098) = 0
[pid 686436] 09:40:55.423642 ioctl(11, DRM_IOCTL_SYNCOBJ_WAIT,
0x7ffce0974ef0) = 0
[pid 686436] 09:40:55.423876 ioctl(11, DRM_IOCTL_I915_GEM_MADVISE,
0x7ffce0974fec) = 0
[pid 686436] 09:40:55.423971 ioctl(11, DRM_IOCTL_SYNCOBJ_CREATE,
0x7ffce0975100) = 0
[pid 686436] 09:40:55.424218 writev(45,
[{iov_base="#\221\360s\0\0\0\0\2\0\0\0\204\v \4\3\0\200\3s\213\0\0\243\v
\4\244\v \4", iov_len=32}], 1) = 32
[pid 686436] 09:40:55.424471 writev(45,
[{iov_base="#\221\360s\2\0\0\0\1\0\0\2\204\v
\4\3\0\200\3r\213\0\0\376S\340\252\37\2\0\0\311uf\0\0\0\0\0", iov_len=40}], 1)
= 40
[pid 686436] 09:40:55.424810 poll([{fd=3, events=POLLOUT}], 1, 5) = 1
([{fd=3, revents=POLLOUT}])
[pid 686436] 09:40:55.425150 epoll_wait(8, [], 256, 0) = 0
These pauses are often 10-15 seconds in length but can also be much
longer. I have observed it happening even with the screen locked
(screen lock unresponsive until pause ends).
FD 8 in the trace is anon_inode:[eventpoll] and FD 11 is
/dev/dri/renderD129, the Intel HD 530 DRI device.
** Description changed:
- Hi, I have this weird bug in mutter which seems to correlate with uptime
- - if I kill mutter the problem seems to go away for a few days, although
- killing mutter is very inconvenient because all applications are also
- killed even with session persistence.
+ Hi, I have this weird bug in mutter (44.2-0ubuntu1) which seems to
+ correlate with uptime - if I kill mutter the problem seems to go away
+ for a few days, although killing mutter is very inconvenient because all
+ applications are also killed even with session persistence.
Upon strace analysis it can be seen that when the pauses are happening
there is a specific trace involving GEM operations happening immediately
after a ~1 second epoll expires.
During this state the entire UI is paused - video does not update, mouse
cursor does not move, keypresses have no response. However, input
events are "queued" so that when the pause ends, the mouse instantly
warps across the screen, and if a key was down at the time the pause
began, the key is repeated hundreds of times since it seems that the
key-up event is only processed when the "pause" ends.
The system is up to date 23.04 and mutter is using the Intel HD 530
integrated graphics. I do not believe this issue happened before 23.04
was released, although it has been intermittent and persistent since
that time.
Attached a strace with timestamps which provides an example of a multi-
second pause. Using grep -A1 epoll_wait you can see the instances of
the GEM operations during the pause. Eventually at around 09:40:57
local time in the trace the "pause" ended.
Example of an instance of the GEM operation trace after a ~1 second
epoll timeout:
[pid 686436] 09:40:54.750468 poll([{fd=3, events=POLLOUT}], 1, 5) = 1
([{fd=3, revents=POLLOUT}])
[pid 686436] 09:40:54.750719 epoll_wait(8, [], 256, 671) = 0
[pid 686436] 09:40:55.422886 ioctl(11, DRM_IOCTL_SYNCOBJ_DESTROY,
0x7ffce0975140) = 0
[pid 686436] 09:40:55.423213 ioctl(11, DRM_IOCTL_I915_GEM_EXECBUFFER2,
0x7ffce09751d0) = 0
[pid 686436] 09:40:55.423525 ioctl(11, DRM_IOCTL_I915_GEM_MADVISE,
0x7ffce0975098) = 0
[pid 686436] 09:40:55.423642 ioctl(11, DRM_IOCTL_SYNCOBJ_WAIT,
0x7ffce0974ef0) = 0
[pid 686436] 09:40:55.423876 ioctl(11, DRM_IOCTL_I915_GEM_MADVISE,
0x7ffce0974fec) = 0
[pid 686436] 09:40:55.423971 ioctl(11, DRM_IOCTL_SYNCOBJ_CREATE,
0x7ffce0975100) = 0
[pid 686436] 09:40:55.424218 writev(45,
[{iov_base="#\221\360s\0\0\0\0\2\0\0\0\204\v \4\3\0\200\3s\213\0\0\243\v
\4\244\v \4", iov_len=32}], 1) = 32
[pid 686436] 09:40:55.424471 writev(45,
[{iov_base="#\221\360s\2\0\0\0\1\0\0\2\204\v
\4\3\0\200\3r\213\0\0\376S\340\252\37\2\0\0\311uf\0\0\0\0\0", iov_len=40}], 1)
= 40
[pid 686436] 09:40:55.424810 poll([{fd=3, events=POLLOUT}], 1, 5) = 1
([{fd=3, revents=POLLOUT}])
[pid 686436] 09:40:55.425150 epoll_wait(8, [], 256, 0) = 0
These pauses are often 10-15 seconds in length but can also be much
longer. I have observed it happening even with the screen locked
(screen lock unresponsive until pause ends).
FD 8 in the trace is anon_inode:[eventpoll] and FD 11 is
/dev/dri/renderD129, the Intel HD 530 DRI device.
+
+ Kernel is 6.2.0-24-generic from the distribution.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to mutter in Ubuntu.
https://bugs.launchpad.net/bugs/2025662
Title:
mutter pauses for multiple seconds at random times
Status in mutter package in Ubuntu:
New
Bug description:
Hi, I have this weird bug in mutter (44.2-0ubuntu1) which seems to
correlate with uptime - if I kill mutter the problem seems to go away
for a few days, although killing mutter is very inconvenient because
all applications are also killed even with session persistence.
Upon strace analysis it can be seen that when the pauses are happening
there is a specific trace involving GEM operations happening
immediately after a ~1 second epoll expires.
During this state the entire UI is paused - video does not update,
mouse cursor does not move, keypresses have no response. However,
input events are "queued" so that when the pause ends, the mouse
instantly warps across the screen, and if a key was down at the time
the pause began, the key is repeated hundreds of times since it seems
that the key-up event is only processed when the "pause" ends.
The system is up to date 23.04 and mutter is using the Intel HD 530
integrated graphics. I do not believe this issue happened before
23.04 was released, although it has been intermittent and persistent
since that time.
Attached a strace with timestamps which provides an example of a
multi-second pause. Using grep -A1 epoll_wait you can see the
instances of the GEM operations during the pause. Eventually at
around 09:40:57 local time in the trace the "pause" ended.
Example of an instance of the GEM operation trace after a ~1 second
epoll timeout:
[pid 686436] 09:40:54.750468 poll([{fd=3, events=POLLOUT}], 1, 5) = 1
([{fd=3, revents=POLLOUT}])
[pid 686436] 09:40:54.750719 epoll_wait(8, [], 256, 671) = 0
[pid 686436] 09:40:55.422886 ioctl(11, DRM_IOCTL_SYNCOBJ_DESTROY,
0x7ffce0975140) = 0
[pid 686436] 09:40:55.423213 ioctl(11, DRM_IOCTL_I915_GEM_EXECBUFFER2,
0x7ffce09751d0) = 0
[pid 686436] 09:40:55.423525 ioctl(11, DRM_IOCTL_I915_GEM_MADVISE,
0x7ffce0975098) = 0
[pid 686436] 09:40:55.423642 ioctl(11, DRM_IOCTL_SYNCOBJ_WAIT,
0x7ffce0974ef0) = 0
[pid 686436] 09:40:55.423876 ioctl(11, DRM_IOCTL_I915_GEM_MADVISE,
0x7ffce0974fec) = 0
[pid 686436] 09:40:55.423971 ioctl(11, DRM_IOCTL_SYNCOBJ_CREATE,
0x7ffce0975100) = 0
[pid 686436] 09:40:55.424218 writev(45,
[{iov_base="#\221\360s\0\0\0\0\2\0\0\0\204\v \4\3\0\200\3s\213\0\0\243\v
\4\244\v \4", iov_len=32}], 1) = 32
[pid 686436] 09:40:55.424471 writev(45,
[{iov_base="#\221\360s\2\0\0\0\1\0\0\2\204\v
\4\3\0\200\3r\213\0\0\376S\340\252\37\2\0\0\311uf\0\0\0\0\0", iov_len=40}], 1)
= 40
[pid 686436] 09:40:55.424810 poll([{fd=3, events=POLLOUT}], 1, 5) = 1
([{fd=3, revents=POLLOUT}])
[pid 686436] 09:40:55.425150 epoll_wait(8, [], 256, 0) = 0
These pauses are often 10-15 seconds in length but can also be much
longer. I have observed it happening even with the screen locked
(screen lock unresponsive until pause ends).
FD 8 in the trace is anon_inode:[eventpoll] and FD 11 is
/dev/dri/renderD129, the Intel HD 530 DRI device.
Kernel is 6.2.0-24-generic from the distribution.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2025662/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
