systemd-udev is frequently handling events on an idle phone

Bug #1221859 reported by Colin Ian King
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
touch-preview-images
Fix Released
Undecided
Unassigned

Bug Description

On a Samsung Galaxy Nexus I observed that systemd-udev is handling events (from /devices/platform/omapfb ?) quite frequently even on an idle phone. I see on average epoll_wait() being called once every 4-8 seconds to handle these.

epoll_wait(11, {{EPOLLIN, {u32=7, u64=7}}}, 8, -1) = 1
clock_gettime(CLOCK_MONOTONIC, {14518, 144413196}) = 0
stat64("/etc/udev/rules.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/run/udev/rules.d", 0xbe9db540) = -1 ENOENT (No such file or directory)
stat64("/lib/udev/rules.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fstat64(10, {st_mode=S_IFREG|0444, st_size=5658459, ...}) = 0
stat64("/etc/modprobe.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/lib/modprobe.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/lib/modules/3.0.0-3-maguro/modules.dep.bin", {st_mode=S_IFREG|0644, st_size=25755, ...}) = 0
stat64("/lib/modules/3.0.0-3-maguro/modules.alias.bin", {st_mode=S_IFREG|0644, st_size=8363, ...}) = 0
stat64("/lib/modules/3.0.0-3-maguro/modules.symbols.bin", {st_mode=S_IFREG|0644, st_size=14023, ...}) = 0
stat64("/lib/modules/3.0.0-3-maguro/modules.builtin.bin", {st_mode=S_IFREG|0644, st_size=12735, ...}) = 0
clock_gettime(CLOCK_MONOTONIC, {14518, 159977159}) = 0
read(7, "\5\0\0\0\0\0\0\0\200\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 128) = 128
epoll_wait(11, {{EPOLLIN, {u32=4, u64=4}}}, 8, -1) = 1
clock_gettime(CLOCK_MONOTONIC, {14535, 253147325}) = 0
stat64("/etc/udev/rules.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/run/udev/rules.d", 0xbe9db540) = -1 ENOENT (No such file or directory)
stat64("/lib/udev/rules.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
fstat64(10, {st_mode=S_IFREG|0444, st_size=5658459, ...}) = 0
stat64("/etc/modprobe.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/lib/modprobe.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64("/lib/modules/3.0.0-3-maguro/modules.dep.bin", {st_mode=S_IFREG|0644, st_size=25755, ...}) = 0
stat64("/lib/modules/3.0.0-3-maguro/modules.alias.bin", {st_mode=S_IFREG|0644, st_size=8363, ...}) = 0
stat64("/lib/modules/3.0.0-3-maguro/modules.symbols.bin", {st_mode=S_IFREG|0644, st_size=14023, ...}) = 0
stat64("/lib/modules/3.0.0-3-maguro/modules.builtin.bin", {st_mode=S_IFREG|0644, st_size=12735, ...}) = 0
clock_gettime(CLOCK_MONOTONIC, {14535, 260898790}) = 0
recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000001}, msg_iov(1)=[{"change@/devices/platform/omapfb\0"..., 8192}], msg_controllen=24, {cmsg_len=24, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS{pid=0, uid=0, gid=0}}, msg_flags=0}, 0) = 170
clock_gettime(CLOCK_MONOTONIC, {14535, 262150011}) = 0
_llseek(5, 0, [8], SEEK_CUR) = 0
write(5, "\335\f\0\0\0\0\0\0\30\0/devices/platform/omap"..., 34) = 34
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC|SOCK_NONBLOCK, 15) = 12
bind(12, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
getsockname(12, {sa_family=AF_NETLINK, pid=541, groups=00000000}, [12]) = 0
setsockopt(12, SOL_SOCKET, SO_PASSCRED, [1], 4) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x400b5068) = 4896
close(12) = 0
clock_gettime(CLOCK_MONOTONIC, {14535, 266971788}) = 0
epoll_wait(11, {{EPOLLIN, {u32=8, u64=8}}}, 8, 3000) = 1
clock_gettime(CLOCK_MONOTONIC, {14535, 270206651}) = 0
recv(8, " \23\0\0\0\0\0\0", 8, MSG_DONTWAIT) = 8
close(5) = 0
munmap(0x40054000, 4096) = 0
open("/run/udev/queue.tmp", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE|O_CLOEXEC, 0666) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x400d5000
write(5, "\335\f\0\0\0\0\0\0", 8) = 8
rename("/run/udev/queue.tmp", "/run/udev/queue.bin") = 0
recv(8, 0xbe9db828, 8, MSG_DONTWAIT) = -1 EAGAIN (Resource temporarily unavailable)

I see the same activity but very frequently if I touch the touch screen. Is that expected behaviour?

description: updated
tags: added: mobile-power-consumption
Changed in touch-preview-images:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.