Why is systemd-udev pegging my CPU?
I've noticed that one of the cores on a four-core laptop is pegged, and the temp is very high. I found this in top
:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
359 root 20 0 188684 147228 1552 R 99.4 5.0 111:19.91 systemd-udevd
20011 root 20 0 188320 147604 2076 S 11.0 5.0 0:00.33 systemd-udevd
11053 dotanco+ 20 0 3030036 918672 49608 S 9.6 31.2 280:40.65 firefox
3468 dotanco+ 20 0 3612776 136740 43484 S 1.7 4.6 57:02.52 plasma-desktop
20006 root 20 0 0 0 0 Z 1.0 0.0 0:00.37 systemd-udevd
Why might systemd-udev
be hammering the CPU? This is a Kubuntu 14.10 system:
$ uname -a
Linux loathe 3.16.0-44-generic #59-Ubuntu SMP Tue Jul 7 02:07:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/issue
Ubuntu 14.10 n l
EDIT: I notice that in addition to the pegged CPU, there is an additional problem. Newly connected USB devices, such as a USB mass storage device or keyboard, will show up in lsusb
but are unusable. The mass storage device is not auto mounted, and the USB keyboard does not work. I have not tried to manually mount the USB drive.
As per Bratchley's suggestion, here is the strace of the systemd-udev
process with ID 359.
systemd cpu-usage
|
show 1 more comment
I've noticed that one of the cores on a four-core laptop is pegged, and the temp is very high. I found this in top
:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
359 root 20 0 188684 147228 1552 R 99.4 5.0 111:19.91 systemd-udevd
20011 root 20 0 188320 147604 2076 S 11.0 5.0 0:00.33 systemd-udevd
11053 dotanco+ 20 0 3030036 918672 49608 S 9.6 31.2 280:40.65 firefox
3468 dotanco+ 20 0 3612776 136740 43484 S 1.7 4.6 57:02.52 plasma-desktop
20006 root 20 0 0 0 0 Z 1.0 0.0 0:00.37 systemd-udevd
Why might systemd-udev
be hammering the CPU? This is a Kubuntu 14.10 system:
$ uname -a
Linux loathe 3.16.0-44-generic #59-Ubuntu SMP Tue Jul 7 02:07:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/issue
Ubuntu 14.10 n l
EDIT: I notice that in addition to the pegged CPU, there is an additional problem. Newly connected USB devices, such as a USB mass storage device or keyboard, will show up in lsusb
but are unusable. The mass storage device is not auto mounted, and the USB keyboard does not work. I have not tried to manually mount the USB drive.
As per Bratchley's suggestion, here is the strace of the systemd-udev
process with ID 359.
systemd cpu-usage
2
You mightstrace
it usingstrace -fvvp 359
chances are it's looping continually on something. You might be able to pick out something meaningful. It's probably a bug but it still might make for a good bug report if you can collect data about it.
– Bratchley
Oct 1 '15 at 20:22
1
@Bratchley: Thank you, here is the strace. I'm googling now to learn how to read it, but any advice would be appreciated.
– dotancohen
Oct 1 '15 at 21:18
1
Well it doesn't look like it's looping.It seems to be reading in a bunch of files andmodprobe
-ing in order to get them set up. Just a bunch of random stuff really. Does it print anything to messages or to thedmesg
command?
– Bratchley
Oct 2 '15 at 15:13
1
I should have checkeddmesg
, I just reset the machine about two or three hours ago. Thank you very much for confirming that there is no looping. I tried going over the strace and though I'm not versed in reading them, I couldn't find any infinite loop which is always the first thing that I think of when CPU spikes.
– dotancohen
Oct 2 '15 at 15:19
2
Is there anything shown when you run "udevadm monitor" ?
– V13
Oct 2 '15 at 16:04
|
show 1 more comment
I've noticed that one of the cores on a four-core laptop is pegged, and the temp is very high. I found this in top
:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
359 root 20 0 188684 147228 1552 R 99.4 5.0 111:19.91 systemd-udevd
20011 root 20 0 188320 147604 2076 S 11.0 5.0 0:00.33 systemd-udevd
11053 dotanco+ 20 0 3030036 918672 49608 S 9.6 31.2 280:40.65 firefox
3468 dotanco+ 20 0 3612776 136740 43484 S 1.7 4.6 57:02.52 plasma-desktop
20006 root 20 0 0 0 0 Z 1.0 0.0 0:00.37 systemd-udevd
Why might systemd-udev
be hammering the CPU? This is a Kubuntu 14.10 system:
$ uname -a
Linux loathe 3.16.0-44-generic #59-Ubuntu SMP Tue Jul 7 02:07:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/issue
Ubuntu 14.10 n l
EDIT: I notice that in addition to the pegged CPU, there is an additional problem. Newly connected USB devices, such as a USB mass storage device or keyboard, will show up in lsusb
but are unusable. The mass storage device is not auto mounted, and the USB keyboard does not work. I have not tried to manually mount the USB drive.
As per Bratchley's suggestion, here is the strace of the systemd-udev
process with ID 359.
systemd cpu-usage
I've noticed that one of the cores on a four-core laptop is pegged, and the temp is very high. I found this in top
:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
359 root 20 0 188684 147228 1552 R 99.4 5.0 111:19.91 systemd-udevd
20011 root 20 0 188320 147604 2076 S 11.0 5.0 0:00.33 systemd-udevd
11053 dotanco+ 20 0 3030036 918672 49608 S 9.6 31.2 280:40.65 firefox
3468 dotanco+ 20 0 3612776 136740 43484 S 1.7 4.6 57:02.52 plasma-desktop
20006 root 20 0 0 0 0 Z 1.0 0.0 0:00.37 systemd-udevd
Why might systemd-udev
be hammering the CPU? This is a Kubuntu 14.10 system:
$ uname -a
Linux loathe 3.16.0-44-generic #59-Ubuntu SMP Tue Jul 7 02:07:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/issue
Ubuntu 14.10 n l
EDIT: I notice that in addition to the pegged CPU, there is an additional problem. Newly connected USB devices, such as a USB mass storage device or keyboard, will show up in lsusb
but are unusable. The mass storage device is not auto mounted, and the USB keyboard does not work. I have not tried to manually mount the USB drive.
As per Bratchley's suggestion, here is the strace of the systemd-udev
process with ID 359.
systemd cpu-usage
systemd cpu-usage
edited Oct 2 '15 at 15:17
asked Oct 1 '15 at 11:29
dotancohen
6,216195795
6,216195795
2
You mightstrace
it usingstrace -fvvp 359
chances are it's looping continually on something. You might be able to pick out something meaningful. It's probably a bug but it still might make for a good bug report if you can collect data about it.
– Bratchley
Oct 1 '15 at 20:22
1
@Bratchley: Thank you, here is the strace. I'm googling now to learn how to read it, but any advice would be appreciated.
– dotancohen
Oct 1 '15 at 21:18
1
Well it doesn't look like it's looping.It seems to be reading in a bunch of files andmodprobe
-ing in order to get them set up. Just a bunch of random stuff really. Does it print anything to messages or to thedmesg
command?
– Bratchley
Oct 2 '15 at 15:13
1
I should have checkeddmesg
, I just reset the machine about two or three hours ago. Thank you very much for confirming that there is no looping. I tried going over the strace and though I'm not versed in reading them, I couldn't find any infinite loop which is always the first thing that I think of when CPU spikes.
– dotancohen
Oct 2 '15 at 15:19
2
Is there anything shown when you run "udevadm monitor" ?
– V13
Oct 2 '15 at 16:04
|
show 1 more comment
2
You mightstrace
it usingstrace -fvvp 359
chances are it's looping continually on something. You might be able to pick out something meaningful. It's probably a bug but it still might make for a good bug report if you can collect data about it.
– Bratchley
Oct 1 '15 at 20:22
1
@Bratchley: Thank you, here is the strace. I'm googling now to learn how to read it, but any advice would be appreciated.
– dotancohen
Oct 1 '15 at 21:18
1
Well it doesn't look like it's looping.It seems to be reading in a bunch of files andmodprobe
-ing in order to get them set up. Just a bunch of random stuff really. Does it print anything to messages or to thedmesg
command?
– Bratchley
Oct 2 '15 at 15:13
1
I should have checkeddmesg
, I just reset the machine about two or three hours ago. Thank you very much for confirming that there is no looping. I tried going over the strace and though I'm not versed in reading them, I couldn't find any infinite loop which is always the first thing that I think of when CPU spikes.
– dotancohen
Oct 2 '15 at 15:19
2
Is there anything shown when you run "udevadm monitor" ?
– V13
Oct 2 '15 at 16:04
2
2
You might
strace
it using strace -fvvp 359
chances are it's looping continually on something. You might be able to pick out something meaningful. It's probably a bug but it still might make for a good bug report if you can collect data about it.– Bratchley
Oct 1 '15 at 20:22
You might
strace
it using strace -fvvp 359
chances are it's looping continually on something. You might be able to pick out something meaningful. It's probably a bug but it still might make for a good bug report if you can collect data about it.– Bratchley
Oct 1 '15 at 20:22
1
1
@Bratchley: Thank you, here is the strace. I'm googling now to learn how to read it, but any advice would be appreciated.
– dotancohen
Oct 1 '15 at 21:18
@Bratchley: Thank you, here is the strace. I'm googling now to learn how to read it, but any advice would be appreciated.
– dotancohen
Oct 1 '15 at 21:18
1
1
Well it doesn't look like it's looping.It seems to be reading in a bunch of files and
modprobe
-ing in order to get them set up. Just a bunch of random stuff really. Does it print anything to messages or to the dmesg
command?– Bratchley
Oct 2 '15 at 15:13
Well it doesn't look like it's looping.It seems to be reading in a bunch of files and
modprobe
-ing in order to get them set up. Just a bunch of random stuff really. Does it print anything to messages or to the dmesg
command?– Bratchley
Oct 2 '15 at 15:13
1
1
I should have checked
dmesg
, I just reset the machine about two or three hours ago. Thank you very much for confirming that there is no looping. I tried going over the strace and though I'm not versed in reading them, I couldn't find any infinite loop which is always the first thing that I think of when CPU spikes.– dotancohen
Oct 2 '15 at 15:19
I should have checked
dmesg
, I just reset the machine about two or three hours ago. Thank you very much for confirming that there is no looping. I tried going over the strace and though I'm not versed in reading them, I couldn't find any infinite loop which is always the first thing that I think of when CPU spikes.– dotancohen
Oct 2 '15 at 15:19
2
2
Is there anything shown when you run "udevadm monitor" ?
– V13
Oct 2 '15 at 16:04
Is there anything shown when you run "udevadm monitor" ?
– V13
Oct 2 '15 at 16:04
|
show 1 more comment
6 Answers
6
active
oldest
votes
It looks like libmtp found a device, but it's unable to disconnect it properly and it's checking for it constantly. It happens with certain devices and can be disabled by editing /lib/udev/rules.d/69-libmtp.rules
Look for a couple of lines that look like this (at the end of the file):
# Autoprobe vendor-specific, communication and PTP devices
ENV{ID_MTP_DEVICE}!="1", ENV{MTP_NO_PROBE}!="1", ENV{COLOR_MEASUREMENT_DEVICE}!="1", ENV{libsane_matched}!="yes", ATTR{bDeviceCl ass}=="00|02|06|ef|ff", PROGRAM="/usr/lib/udev/mtp-probe /sys$env{DEVPATH} $attr{busnum} $attr{devnum}", RESULT=="1", SYMLINK+="li bmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"
Comment the second line by putting a # before ENV, so that it looks like:
#ENV{ID_MTP....
Restart your computer or run sudo systemctl restart systemd-udevd
and enjoy your free CPU cycles :)
Reboot was necessary for me. I tried restarting systemd-udevd several times, but it would always peg the cpu again immediately.
– Nate Glenn
Mar 31 '17 at 7:10
add a comment |
Use udevadm monitor
to find out which driver is pooling the cpu.
add a comment |
Another cause:
- Installed nvidia driver 396
- Restart with blank screen
- Disabled nvidia in bios
System works with Intel, but after several sleep/resume I got this from
udevadm monitor
(random lines but repeating all the same indefinitely):
...
KERNEL[10072.040174] remove /module/nvidia (module)
UDEV [10072.062670] add /module/nvidia (module)
UDEV [10072.063617] add /kernel/slab/:A-0000256/cgroup/filp(40652:nvidia-persistenced.service) (cgroup)
UDEV [10072.076901] remove /module/nvidia (module)
UDEV [10072.109365] add /kernel/slab/:aA-0000192/cgroup/dentry(40652:nvidia-persistenced.service) (cgroup)
KERNEL[10072.138225] add /module/nvidia (module)
KERNEL[10072.139241] add /kernel/slab/:0012288 (slab)
KERNEL[10072.139651] remove /kernel/slab/:0012288 (slab)
...
I'm not sure but I expect this is caused by the fact that the nvidia driver is active but nvidia is disabled in BIOS.
1
I ran into the same problem. uninstalled Nvidia drivers solved the problem.
– TC Zhang
Oct 4 at 5:31
add a comment |
There is a bug in the kernel that cause systemd-udevs 100% CPU usage.
So, the work around is to reboot the system, press and hold Shift during loading Grub. Then select the older kernel listed in the bootloader list.
This work fine for me.
add a comment |
I had the same problem on Linux Mint 17.3 Rosa.
To solve it, when my PC is idle:
- I open up terminal.
- Login as SU.
- Use
top
command and see PID ofsystemd
. - Kill it.
CPU back to normal and RAM usage went low. Of course my desktop still stable. I can use my desktop normally after that operation.
I always thought that systemd is always PID 1 0pointer.de/blog/projects/systemd.html
– aventurin
Sep 27 '16 at 22:21
add a comment |
I have found this is a problem on some installs of CentOS running on Hyper-V. Turning off Integration Services in the VM settings appears to have resolved it. Specifically Time synchronization.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f233247%2fwhy-is-systemd-udev-pegging-my-cpu%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
It looks like libmtp found a device, but it's unable to disconnect it properly and it's checking for it constantly. It happens with certain devices and can be disabled by editing /lib/udev/rules.d/69-libmtp.rules
Look for a couple of lines that look like this (at the end of the file):
# Autoprobe vendor-specific, communication and PTP devices
ENV{ID_MTP_DEVICE}!="1", ENV{MTP_NO_PROBE}!="1", ENV{COLOR_MEASUREMENT_DEVICE}!="1", ENV{libsane_matched}!="yes", ATTR{bDeviceCl ass}=="00|02|06|ef|ff", PROGRAM="/usr/lib/udev/mtp-probe /sys$env{DEVPATH} $attr{busnum} $attr{devnum}", RESULT=="1", SYMLINK+="li bmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"
Comment the second line by putting a # before ENV, so that it looks like:
#ENV{ID_MTP....
Restart your computer or run sudo systemctl restart systemd-udevd
and enjoy your free CPU cycles :)
Reboot was necessary for me. I tried restarting systemd-udevd several times, but it would always peg the cpu again immediately.
– Nate Glenn
Mar 31 '17 at 7:10
add a comment |
It looks like libmtp found a device, but it's unable to disconnect it properly and it's checking for it constantly. It happens with certain devices and can be disabled by editing /lib/udev/rules.d/69-libmtp.rules
Look for a couple of lines that look like this (at the end of the file):
# Autoprobe vendor-specific, communication and PTP devices
ENV{ID_MTP_DEVICE}!="1", ENV{MTP_NO_PROBE}!="1", ENV{COLOR_MEASUREMENT_DEVICE}!="1", ENV{libsane_matched}!="yes", ATTR{bDeviceCl ass}=="00|02|06|ef|ff", PROGRAM="/usr/lib/udev/mtp-probe /sys$env{DEVPATH} $attr{busnum} $attr{devnum}", RESULT=="1", SYMLINK+="li bmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"
Comment the second line by putting a # before ENV, so that it looks like:
#ENV{ID_MTP....
Restart your computer or run sudo systemctl restart systemd-udevd
and enjoy your free CPU cycles :)
Reboot was necessary for me. I tried restarting systemd-udevd several times, but it would always peg the cpu again immediately.
– Nate Glenn
Mar 31 '17 at 7:10
add a comment |
It looks like libmtp found a device, but it's unable to disconnect it properly and it's checking for it constantly. It happens with certain devices and can be disabled by editing /lib/udev/rules.d/69-libmtp.rules
Look for a couple of lines that look like this (at the end of the file):
# Autoprobe vendor-specific, communication and PTP devices
ENV{ID_MTP_DEVICE}!="1", ENV{MTP_NO_PROBE}!="1", ENV{COLOR_MEASUREMENT_DEVICE}!="1", ENV{libsane_matched}!="yes", ATTR{bDeviceCl ass}=="00|02|06|ef|ff", PROGRAM="/usr/lib/udev/mtp-probe /sys$env{DEVPATH} $attr{busnum} $attr{devnum}", RESULT=="1", SYMLINK+="li bmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"
Comment the second line by putting a # before ENV, so that it looks like:
#ENV{ID_MTP....
Restart your computer or run sudo systemctl restart systemd-udevd
and enjoy your free CPU cycles :)
It looks like libmtp found a device, but it's unable to disconnect it properly and it's checking for it constantly. It happens with certain devices and can be disabled by editing /lib/udev/rules.d/69-libmtp.rules
Look for a couple of lines that look like this (at the end of the file):
# Autoprobe vendor-specific, communication and PTP devices
ENV{ID_MTP_DEVICE}!="1", ENV{MTP_NO_PROBE}!="1", ENV{COLOR_MEASUREMENT_DEVICE}!="1", ENV{libsane_matched}!="yes", ATTR{bDeviceCl ass}=="00|02|06|ef|ff", PROGRAM="/usr/lib/udev/mtp-probe /sys$env{DEVPATH} $attr{busnum} $attr{devnum}", RESULT=="1", SYMLINK+="li bmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"
Comment the second line by putting a # before ENV, so that it looks like:
#ENV{ID_MTP....
Restart your computer or run sudo systemctl restart systemd-udevd
and enjoy your free CPU cycles :)
answered Mar 19 '16 at 16:13
eLobato
21124
21124
Reboot was necessary for me. I tried restarting systemd-udevd several times, but it would always peg the cpu again immediately.
– Nate Glenn
Mar 31 '17 at 7:10
add a comment |
Reboot was necessary for me. I tried restarting systemd-udevd several times, but it would always peg the cpu again immediately.
– Nate Glenn
Mar 31 '17 at 7:10
Reboot was necessary for me. I tried restarting systemd-udevd several times, but it would always peg the cpu again immediately.
– Nate Glenn
Mar 31 '17 at 7:10
Reboot was necessary for me. I tried restarting systemd-udevd several times, but it would always peg the cpu again immediately.
– Nate Glenn
Mar 31 '17 at 7:10
add a comment |
Use udevadm monitor
to find out which driver is pooling the cpu.
add a comment |
Use udevadm monitor
to find out which driver is pooling the cpu.
add a comment |
Use udevadm monitor
to find out which driver is pooling the cpu.
Use udevadm monitor
to find out which driver is pooling the cpu.
edited May 7 at 14:48
Michael Mrozek♦
60.6k29187208
60.6k29187208
answered May 7 at 13:55
wayfactory
6111
6111
add a comment |
add a comment |
Another cause:
- Installed nvidia driver 396
- Restart with blank screen
- Disabled nvidia in bios
System works with Intel, but after several sleep/resume I got this from
udevadm monitor
(random lines but repeating all the same indefinitely):
...
KERNEL[10072.040174] remove /module/nvidia (module)
UDEV [10072.062670] add /module/nvidia (module)
UDEV [10072.063617] add /kernel/slab/:A-0000256/cgroup/filp(40652:nvidia-persistenced.service) (cgroup)
UDEV [10072.076901] remove /module/nvidia (module)
UDEV [10072.109365] add /kernel/slab/:aA-0000192/cgroup/dentry(40652:nvidia-persistenced.service) (cgroup)
KERNEL[10072.138225] add /module/nvidia (module)
KERNEL[10072.139241] add /kernel/slab/:0012288 (slab)
KERNEL[10072.139651] remove /kernel/slab/:0012288 (slab)
...
I'm not sure but I expect this is caused by the fact that the nvidia driver is active but nvidia is disabled in BIOS.
1
I ran into the same problem. uninstalled Nvidia drivers solved the problem.
– TC Zhang
Oct 4 at 5:31
add a comment |
Another cause:
- Installed nvidia driver 396
- Restart with blank screen
- Disabled nvidia in bios
System works with Intel, but after several sleep/resume I got this from
udevadm monitor
(random lines but repeating all the same indefinitely):
...
KERNEL[10072.040174] remove /module/nvidia (module)
UDEV [10072.062670] add /module/nvidia (module)
UDEV [10072.063617] add /kernel/slab/:A-0000256/cgroup/filp(40652:nvidia-persistenced.service) (cgroup)
UDEV [10072.076901] remove /module/nvidia (module)
UDEV [10072.109365] add /kernel/slab/:aA-0000192/cgroup/dentry(40652:nvidia-persistenced.service) (cgroup)
KERNEL[10072.138225] add /module/nvidia (module)
KERNEL[10072.139241] add /kernel/slab/:0012288 (slab)
KERNEL[10072.139651] remove /kernel/slab/:0012288 (slab)
...
I'm not sure but I expect this is caused by the fact that the nvidia driver is active but nvidia is disabled in BIOS.
1
I ran into the same problem. uninstalled Nvidia drivers solved the problem.
– TC Zhang
Oct 4 at 5:31
add a comment |
Another cause:
- Installed nvidia driver 396
- Restart with blank screen
- Disabled nvidia in bios
System works with Intel, but after several sleep/resume I got this from
udevadm monitor
(random lines but repeating all the same indefinitely):
...
KERNEL[10072.040174] remove /module/nvidia (module)
UDEV [10072.062670] add /module/nvidia (module)
UDEV [10072.063617] add /kernel/slab/:A-0000256/cgroup/filp(40652:nvidia-persistenced.service) (cgroup)
UDEV [10072.076901] remove /module/nvidia (module)
UDEV [10072.109365] add /kernel/slab/:aA-0000192/cgroup/dentry(40652:nvidia-persistenced.service) (cgroup)
KERNEL[10072.138225] add /module/nvidia (module)
KERNEL[10072.139241] add /kernel/slab/:0012288 (slab)
KERNEL[10072.139651] remove /kernel/slab/:0012288 (slab)
...
I'm not sure but I expect this is caused by the fact that the nvidia driver is active but nvidia is disabled in BIOS.
Another cause:
- Installed nvidia driver 396
- Restart with blank screen
- Disabled nvidia in bios
System works with Intel, but after several sleep/resume I got this from
udevadm monitor
(random lines but repeating all the same indefinitely):
...
KERNEL[10072.040174] remove /module/nvidia (module)
UDEV [10072.062670] add /module/nvidia (module)
UDEV [10072.063617] add /kernel/slab/:A-0000256/cgroup/filp(40652:nvidia-persistenced.service) (cgroup)
UDEV [10072.076901] remove /module/nvidia (module)
UDEV [10072.109365] add /kernel/slab/:aA-0000192/cgroup/dentry(40652:nvidia-persistenced.service) (cgroup)
KERNEL[10072.138225] add /module/nvidia (module)
KERNEL[10072.139241] add /kernel/slab/:0012288 (slab)
KERNEL[10072.139651] remove /kernel/slab/:0012288 (slab)
...
I'm not sure but I expect this is caused by the fact that the nvidia driver is active but nvidia is disabled in BIOS.
edited Dec 16 at 10:06
Thomas
3,70061225
3,70061225
answered Jun 13 at 7:42
dmatej
1313
1313
1
I ran into the same problem. uninstalled Nvidia drivers solved the problem.
– TC Zhang
Oct 4 at 5:31
add a comment |
1
I ran into the same problem. uninstalled Nvidia drivers solved the problem.
– TC Zhang
Oct 4 at 5:31
1
1
I ran into the same problem. uninstalled Nvidia drivers solved the problem.
– TC Zhang
Oct 4 at 5:31
I ran into the same problem. uninstalled Nvidia drivers solved the problem.
– TC Zhang
Oct 4 at 5:31
add a comment |
There is a bug in the kernel that cause systemd-udevs 100% CPU usage.
So, the work around is to reboot the system, press and hold Shift during loading Grub. Then select the older kernel listed in the bootloader list.
This work fine for me.
add a comment |
There is a bug in the kernel that cause systemd-udevs 100% CPU usage.
So, the work around is to reboot the system, press and hold Shift during loading Grub. Then select the older kernel listed in the bootloader list.
This work fine for me.
add a comment |
There is a bug in the kernel that cause systemd-udevs 100% CPU usage.
So, the work around is to reboot the system, press and hold Shift during loading Grub. Then select the older kernel listed in the bootloader list.
This work fine for me.
There is a bug in the kernel that cause systemd-udevs 100% CPU usage.
So, the work around is to reboot the system, press and hold Shift during loading Grub. Then select the older kernel listed in the bootloader list.
This work fine for me.
answered Aug 25 at 19:21
Yolt
111
111
add a comment |
add a comment |
I had the same problem on Linux Mint 17.3 Rosa.
To solve it, when my PC is idle:
- I open up terminal.
- Login as SU.
- Use
top
command and see PID ofsystemd
. - Kill it.
CPU back to normal and RAM usage went low. Of course my desktop still stable. I can use my desktop normally after that operation.
I always thought that systemd is always PID 1 0pointer.de/blog/projects/systemd.html
– aventurin
Sep 27 '16 at 22:21
add a comment |
I had the same problem on Linux Mint 17.3 Rosa.
To solve it, when my PC is idle:
- I open up terminal.
- Login as SU.
- Use
top
command and see PID ofsystemd
. - Kill it.
CPU back to normal and RAM usage went low. Of course my desktop still stable. I can use my desktop normally after that operation.
I always thought that systemd is always PID 1 0pointer.de/blog/projects/systemd.html
– aventurin
Sep 27 '16 at 22:21
add a comment |
I had the same problem on Linux Mint 17.3 Rosa.
To solve it, when my PC is idle:
- I open up terminal.
- Login as SU.
- Use
top
command and see PID ofsystemd
. - Kill it.
CPU back to normal and RAM usage went low. Of course my desktop still stable. I can use my desktop normally after that operation.
I had the same problem on Linux Mint 17.3 Rosa.
To solve it, when my PC is idle:
- I open up terminal.
- Login as SU.
- Use
top
command and see PID ofsystemd
. - Kill it.
CPU back to normal and RAM usage went low. Of course my desktop still stable. I can use my desktop normally after that operation.
edited Sep 27 '16 at 22:10
Tomasz
9,19352965
9,19352965
answered Sep 27 '16 at 21:50
Ryo Adi Suwito
1
1
I always thought that systemd is always PID 1 0pointer.de/blog/projects/systemd.html
– aventurin
Sep 27 '16 at 22:21
add a comment |
I always thought that systemd is always PID 1 0pointer.de/blog/projects/systemd.html
– aventurin
Sep 27 '16 at 22:21
I always thought that systemd is always PID 1 0pointer.de/blog/projects/systemd.html
– aventurin
Sep 27 '16 at 22:21
I always thought that systemd is always PID 1 0pointer.de/blog/projects/systemd.html
– aventurin
Sep 27 '16 at 22:21
add a comment |
I have found this is a problem on some installs of CentOS running on Hyper-V. Turning off Integration Services in the VM settings appears to have resolved it. Specifically Time synchronization.
add a comment |
I have found this is a problem on some installs of CentOS running on Hyper-V. Turning off Integration Services in the VM settings appears to have resolved it. Specifically Time synchronization.
add a comment |
I have found this is a problem on some installs of CentOS running on Hyper-V. Turning off Integration Services in the VM settings appears to have resolved it. Specifically Time synchronization.
I have found this is a problem on some installs of CentOS running on Hyper-V. Turning off Integration Services in the VM settings appears to have resolved it. Specifically Time synchronization.
answered Nov 2 '17 at 16:57
Yanzzee
1012
1012
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f233247%2fwhy-is-systemd-udev-pegging-my-cpu%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
You might
strace
it usingstrace -fvvp 359
chances are it's looping continually on something. You might be able to pick out something meaningful. It's probably a bug but it still might make for a good bug report if you can collect data about it.– Bratchley
Oct 1 '15 at 20:22
1
@Bratchley: Thank you, here is the strace. I'm googling now to learn how to read it, but any advice would be appreciated.
– dotancohen
Oct 1 '15 at 21:18
1
Well it doesn't look like it's looping.It seems to be reading in a bunch of files and
modprobe
-ing in order to get them set up. Just a bunch of random stuff really. Does it print anything to messages or to thedmesg
command?– Bratchley
Oct 2 '15 at 15:13
1
I should have checked
dmesg
, I just reset the machine about two or three hours ago. Thank you very much for confirming that there is no looping. I tried going over the strace and though I'm not versed in reading them, I couldn't find any infinite loop which is always the first thing that I think of when CPU spikes.– dotancohen
Oct 2 '15 at 15:19
2
Is there anything shown when you run "udevadm monitor" ?
– V13
Oct 2 '15 at 16:04