systemd-udevd consumes 100% of CPU

Bug #1759836 reported by Vinícius Milanez Couto on 2018-03-29
266
This bug affects 50 people
Affects Status Importance Assigned to Milestone
The Ubuntu Power Consumption Project
Undecided
Unassigned
linux
Confirmed
High
bluez (Ubuntu)
Undecided
Unassigned
linux (Ubuntu)
Low
Unassigned
systemd (Ubuntu)
Undecided
Unassigned

Bug Description

The systemd-udevd proccess consumes 100% of a thread everytime, but i'm not noticing any difference in my computer.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: systemd 237-3ubuntu6
ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10
Uname: Linux 4.15.0-13-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.20.9-0ubuntu2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Thu Mar 29 08:52:54 2018
InstallationDate: Installed on 2018-03-05 (23 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180304)
MachineType: Dell Inc. Inspiron N5010
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-13-generic root=UUID=3c29e292-f1ae-45e1-a0ed-a82524278ce1 ro quiet splash vt.handoff=1
SourcePackage: systemd
SystemdDelta:
 [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf
 [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf

 2 overridden configuration files found.
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/25/2011
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A12
dmi.board.name: 08R0GW
dmi.board.vendor: Dell Inc.
dmi.board.version: A12
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: A12
dmi.modalias: dmi:bvnDellInc.:bvrA12:bd01/25/2011:svnDellInc.:pnInspironN5010:pvrA12:rvnDellInc.:rn08R0GW:rvrA12:cvnDellInc.:ct8:cvrA12:
dmi.product.name: Inspiron N5010
dmi.product.version: A12
dmi.sys.vendor: Dell Inc.

Created attachment 274593
dmesg

Hi,
I'm currently running ubuntu 18.04 with a 4.15 kernel and i can observe very high cpu usage to the systemd-udevd deamon.

removing the rule :
ATTR{bInterfaceClass}=="03", ATTR{bInterfaceSubClass}=="01", ATTR{bInterfaceProtocol}=="02", \
  ATTRS{bDeviceClass}=="00", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
  RUN+="hid2hci --method=dell --devpath=%p", ENV{HID2HCI_SWITCH}="1"

Solved the high CPU usage eventhough my bluetooth card is not available anymore (as not in hci mode)

It seems that the command hid2hci creates a bind/unbind loop in udev that is looping trying to set the device in hci mode. (that what udevadm monitor seems to show, looping from bind to unbind for the device)

I suspect a0085f2510e8976614ad8f766b209448b385492f introduced a regression (i have not tried to revert it yet).

Please not that there also seem to be a bug in hid2hci.c from bluez l148 :
 if (err == 0) {
  err = -1;
  errno = EALREADY;
 }
Correcting this and recompile bluez desn't solve the issue as cpu usage remains very high.

Using a 4.13 kernel result in a normal CPU usage, this seems a regression in 4.14.

Other people seems to have the same issue, here is a bug report related to this :
https://dev.solus-project.com/T5224

Thanks a lot for your support,

Mathieu Tournier

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in systemd (Ubuntu):
status: New → Confirmed
ubuntu user (ubuntu-user-123) wrote :

Do you see lines like the next one in your journal?

systemd-udevd[512]: Process 'hid2hci --method=dell --devpath=/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.2/3-1.2:1.0' failed with exit code 1.

I count more than 200 of that line per second in the journal and my Dell Inspiron (older model) registers temperatures of over 100C!

Hee ubuntu user

I don't know, i downgraded to 17.10 and am waiting for this bug to be
fixed before i upgrade to 18.04

Bart

On 30-04-18 17:56, ubuntu user wrote:
> Do you see lines like the next one in your journal?
>
> systemd-udevd[512]: Process 'hid2hci --method=dell
> --devpath=/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.2/3-1.2:1.0'
> failed with exit code 1.
>
> I count more than 200 of that line per second in the journal and my Dell
> Inspiron (older model) registers temperatures of over 100C!
>

JR (juergen-richtsfeld) wrote :

I do see those messages - it's an older Dell Latitude.
I also tried booting with the kernel shipped with 17.10 and the problem doesn't exist there.

ephillipe@gmail.com (ephillipe) wrote :

I use Dell Inspiron 1545 with Intel® Core™2 Duo CPU P8700 @ 2.53GHz × 2
If I use kernel shipped with 18.04, I get 100% cpu problem.
If I user kernel 4.14 I get Kernel Panic on system boot up.

After change Kernel to 4.13.x (shipped with ubuntu 17.10) I get my system back.

Know all is working and CPU is normal.

on official bionic , upgraded from artful:

systemd-udevd eats lot cpu , trying to repeatly modprobe nvidia indefinitly , while it is not install in this computer :

it is on a usb bootable ssd disk. i boot it on several computers, some have nvidia, some have not.

it was working fine with artfull and zesty.

i am using proprietary nvidia version 396

May 2 13:35:46 localhost kernel: [ 866.436341] nvidia-nvlink: Nvlink Core is being initialized, major device number 240
May 2 13:35:46 localhost kernel: [ 866.436566] NVRM: No NVIDIA graphics adapter found!
May 2 13:35:46 localhost kernel: [ 866.436718] nvidia-nvlink: Unregistered the Nvlink Core, major device number 240
May 2 13:35:46 localhost kernel: [ 866.506576] nvidia-nvlink: Nvlink Core is being initialized, major device number 240
May 2 13:35:46 localhost kernel: [ 866.506832] NVRM: No NVIDIA graphics adapter found!
May 2 13:35:46 localhost kernel: [ 866.506937] nvidia-nvlink: Unregistered the Nvlink Core, major device number 240
May 2 13:35:46 localhost systemd-udevd[19441]: Process '/usr/bin/nvidia-smi' failed with exit code 9.
May 2 13:35:46 localhost systemd[1]: nvidia-persistenced.service: Start request repeated too quickly.
May 2 13:35:46 localhost systemd[1]: nvidia-persistenced.service: Failed with result 'exit-code'.

and cannot disable nvidia-persistenced.service:

systemctl disable nvidia-persistenced.service

 -> wait a loooong time
and still here

i have:
 - stopped systemd-udevd
 - uninstalled nvidia-compute-utils-396
 - started systemd-udevd

it s ok now

Daniel van Vugt (vanvugt) wrote :

Is there reason to believe that bluez (the bluetoothd process) is involved here? If the problem is low-level bluetooth then the correct package to log that against is 'linux'.

Changed in bluez (Ubuntu):
status: New → Incomplete

I have the very same problem using the same distro (Ubuntu 18.04, 64-bit) on Dell Latitude E5400 laptop. Disabling BT from BIOS or removing the aforementioned rule solves the problem but leaves BT unusable.

Juha Luoma (jsluoma) wrote :

Hit this problem after updated Ubuntu 17.10 -> 18.04 on my old Dell Latitude E6400 laptop.

Bus 001 Device 009: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)
Bus 001 Device 004: ID 0a5c:0000 Broadcom Corp.

Linux zontar 4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29) x86_64 GNU/Linux

May 09 15:59:00 hostname upowerd[14610]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6.2/1-1.6.2:1.0
May 09 15:59:00 hostname upowerd[14610]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6.2/1-1.6.2:1.0
May 09 15:59:00 hostname upowerd[14610]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6.2/1-1.6.2:1.0
May 09 15:59:00 hostname upowerd[14610]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6.2/1-1.6.2:1.0
...repeating...

15632 root 20 0 233136 186656 2664 R 94.1% 4.7% 62:14.67 systemd-udevd
16222 root 20 0 88252 2432 1888 R 35.3% 0.1% 25:21.87 systemd-udevd

Looks like same problem affects this Dell Precision M6500 laptop.

Marcel Schrijvers (mschrvrs) wrote :

Same here, problem started after I upgraded from Ubuntu 17.10 -> 18.04 on my Dell Latitude E6500 laptop.
In Ubuntu 18.04 I used 4.15.0-20-generic, now I use 4.13.0-39-generic and now temperatures are normal again.

John Talbot (jwtalbot) wrote :

Happening here on a Dell Latitude E5500

$ top
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  380 root 20 0 110872 69188 3232 R 88.9 1.7 0:43.18 systemd-udevd
  392 root 20 0 45872 6488 5320 R 22.2 0.2 0:26.84 systemd-udevd

$ udevadm monitor
KERNEL[161.787649] bind /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2.2/8-2.2:1.0 (usb)
KERNEL[161.789029] unbind /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2.2/8-2.2:1.0 (usb)
UDEV [161.790050] unbind /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2.2/8-2.2:1.0 (usb)
KERNEL[161.799621] bind /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2.2/8-2.2:1.0 (usb)
KERNEL[161.801036] unbind /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2.2/8-2.2:1.0 (usb)
UDEV [161.802407] bind /devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2.2/8-2.2:1.0 (usb)

$ journalctl | grep -i udevd
May 09 07:25:31 Latitude-E5500-GB8FR4J systemd-udevd[367]: Process 'hid2hci --method=dell --devpath=/devices/pci0000:00/0000:00:1d.2/usb8/8-2/8-2.2/8-2.2:1.0' failed with exit code 1.

Thanks
JT

ach619 (ach619) on 2018-05-12
description: updated
ach619 (ach619) wrote :

Also have Dell Inspiron N5010 systemd-udevd taking up 100% of processor System is overheating
ran strace -fvvp pid and get this info repeating endlessly
epoll_wait(10, [{EPOLLIN, {u32=445921552, u64=94798964078864}}, {EPOLLIN, {u32=445707360, u64=94798963864672}}, {EPOLLIN, {u32=445832272, u64=94798963989584}}], 11, 0) = 3
clock_gettime(CLOCK_BOOTTIME, {tv_sec=2541, tv_nsec=278071571}) = 0
epoll_wait(10, [{EPOLLIN, {u32=445921552, u64=94798964078864}}, {EPOLLIN, {u32=445707360, u64=94798963864672}}, {EPOLLIN, {u32=445832272, u64=94798963989584}}], 11, 0) = 3
clock_gettime(CLOCK_BOOTTIME, {tv_sec=2541, tv_nsec=278167641}) = 0
recvmsg(7, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="", iov_len=0}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=1790, uid=0, gid=0}}], msg_controllen=32, msg_flags=0}, MSG_DONTWAIT) = 0
recvmsg(7, {msg_namelen=0}, MSG_DONTWAIT) = -1 EAGAIN (Resource temporarily unavailable)
sendmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=1789, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base="libudev\0\376\355\312\376(\0\0\0(\0\0\0\37\1\0\0\5w\305\345\261\2Ge"..., iov_len=40}, {iov_base="ACTION=bind\0DEVPATH=/devices/pci"..., iov_len=287}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, 0) = 327
epoll_wait(10, [{EPOLLIN, {u32=445921552, u64=94798964078864}}, {EPOLLIN, {u32=445707360, u64=94798963864672}}, {EPOLLIN, {u32=445832272, u64=94798963989584}}], 11, 0) = 3
clock_gettime(CLOCK_BOOTTIME, {tv_sec=2541, tv_nsec=284128363}) = 0
recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=0x000001}, msg_namelen=128->12, msg_iov=[{iov_base="unbind@/devices/pci0000:00/0000:"..., iov_len=8192}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=0, uid=0, gid=0}}], msg_controllen=32, msg_flags=0}, 0) = 264
getrandom("\x5c\x05\xb7\x00\xc9\x0e\x92\x24\x64\x4b\x1d\xbe\x21\xad\x25\xab", 16, GRND_NONBLOCK) = 16
getrandom("\xa2\x4a\x63\x92\x35\xf3\x63\x78\x5d\xec\x7b\x25\xfe\xe4\xfe\xd5", 16, GRND_NONBLOCK) = 16
getrandom("\xed\xfb\x0a\x18\x24\xe4\x07\xdb\xc1\x9e\x4e\xfe\xf5\xcc\xb6\xb3", 16, GRND_NONBLOCK) = 16
getrandom("\x98\x96\xbe\xbe\x06\x4b\xe3\x26\xe0\xeb\xb2\xc6\xcc\x17\x3c\x7f", 16, GRND_NONBLOCK) = 16
getrandom("\x3a\x5a\x82\x79\xfb\xb7\x32\x02\x58\x05\xdb\x2a\x81\x7a\x16\x50", 16, GRND_NONBLOCK) = 16
getrandom("\xb0\xde\x65\xbb\x40\x2e\x1c\x35\x11\xad\x32\x9c\x19\x18\xc7\x33", 16, GRND_NONBLOCK) = 16

ach619 (ach619) wrote :

Please help this makes my laptop completely usless

Wedge009 (wedge009) wrote :

Adding some information in case it's useful.

Old - but still useful - Intel Core 2 laptop with discrete Mobility Radeon GPU. I had nvidia packages installed for development purposes years ago, but don't really use them any more. After the upgrade from 17.10 to 18.04 (only performed 2018-05-12, several days after official release), I noticed single-threaded 100% CPU usage from systemd-udevd, with modprobe starting and exiting over and over again. I saw lots of messages complaining about NVIDIA hardware not being found in dmesg output. After uninstalling the nvidia packages and rebooting, the high CPU usage seemed to go away.

So at least on my system, it seems there was a conflict between having nvidia drivers present with no NVIDIA hardware available.

QuentinHartman (qhartman) wrote :

I noticed this problem because my wireles KB/Mouse combo became nearly unusable after upgrading from 17.10 to 18.04. I'm seeing the high CPU consumption as reported above and the dell HID messages as reported above. Also, if I unplug the transceiver for my KB/Mouse it stops working until I reboot.

My machine is a Dell XPS 15 9560. So, also a Dell, but a very new one.

Downgrading to kernel 4.13 has alleviated the symptoms.

ilia fata (likeilia) wrote :

I have a Dell Inspiron N5010 laptop and this bug affected my system.
hope to fix the bug soon.

I am using Dell Inspiron 15R (N5010) and this bug affects my system as described above. Waiting for the fix.

Marcel Schrijvers (mschrvrs) wrote :

Forget last time to add some details about the problem with the new kernel 4.15.0-20-generic versus 4.13.0-39-generic.

Kernel 4.15.0-20-generic
dell_smm-virtual-0
Adapter: Virtual device
Processor Fan: 4214 RPM
CPU: +70.0°C
SODIMM: +57.0°C
Other: +54.0°C

acpitz-virtual-0
Adapter: Virtual device
temp1: +70.5°C (crit = +107.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0: +67.0°C (high = +105.0°C, crit = +105.0°C)
Core 1: +72.0°C (high = +105.0°C, crit = +105.0°C)

Kernel 4.13.0-39-generic
dell_smm-virtual-0
Adapter: Virtual device
Processor Fan: 2774 RPM
CPU: +40.0°C
SODIMM: +44.0°C
Other: +44.0°C

acpitz-virtual-0
Adapter: Virtual device
temp1: +40.5°C (crit = +107.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0: +41.0°C (high = +105.0°C, crit = +105.0°C)
Core 1: +43.0°C (high = +105.0°C, crit = +105.0°C)

Changed in bluez (Ubuntu):
status: Incomplete → Invalid
Lumar (lmspamkill) wrote :
Download full text (5.3 KiB)

The bug is present on my system.
It was temporarily solved with workaround from https://dev.solus-project.com/T5224, but I don't use Bluetooth and so don't know if it is now working.

* Infos from uname
Linux 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:15:38 UTC 2018 i686 i686 i686 GNU/Linux
Ubuntu 4.15.0-20.21-generic 4.15.17

* From dmidecode
System Information
 Manufacturer: Dell Inc.
 Product Name: Vostro 3700
 Version: A10

Base Board Information
 Manufacturer: Dell Inc.
 Product Name: 07VWR8
 Version: A10
 Features:
  Board is a hosting board
  Board is replaceable
 Type: Motherboard

OEM Strings
 String 1: Dell System
 String 2: 5[0003]
 String 3: 13[PP41L]

BIOS Information
 Vendor: Dell Inc.
 Version: A10
 Release Date: 10/25/2010
 Address: 0xF0000
 Runtime Size: 64 kB
 ROM Size: 2048 kB
 Characteristics:
  MCA is supported
  PCI is supported
  BIOS is upgradeable
  BIOS shadowing is allowed
  ESCD support is available
  Boot from CD is supported
  Selectable boot is supported
  BIOS ROM is socketed
  EDD is supported
  5.25"/1.2 MB floppy services are supported (int 13h)
  3.5"/720 kB floppy services are supported (int 13h)
  3.5"/2.88 MB floppy services are supported (int 13h)
  Print screen service is supported (int 5h)
  8042 keyboard services are supported (int 9h)
  Serial services are supported (int 14h)
  Printer services are supported (int 17h)
  CGA/mono video services are supported (int 10h)
  ACPI is supported
  USB legacy is supported
  ATAPI Zip drive boot is supported
  BIOS boot specification is supported
  Targeted content distribution is supported
 BIOS Revision: 1.254
 Firmware Revision: 1.254

* From /sys/kernel/debug/usb/devices
T: Bus=01 Lev=03 Prnt=03 Port=02 Cnt=03 Dev#= 7 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=413c ProdID=8160 Rev= 1.73
S: Manufacturer=Dell Computer Corp
S: Product=Dell Wireless 365 Bluetooth Module
C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 32 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 32 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 64 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 64 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 64 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 64 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=84(I) Atr=...

Read more...

Vivek Agrawal (vickymnit) wrote :

I also faced the same issue and thanks to the Lumar's comment, workaround mentioned in the link worked for me too:
https://dev.solus-project.com/T5224

I observed the high cpu usage after upgrading from udev-233 to udev-236/udev-238 on Gentoo Linux. Downgrading back to udev-233 lets me use newer kernels (currently running 4.15.18) without any problems.
Using DELL Latitude E6400 from 2009, with same Broadcom Bluetooth module as mentioned above.

Marcel Schrijvers (mschrvrs) wrote :

Just upgraded from kernel 4.15.0-20-generic => 4.15.0-22-generic - still the same problem....

Rick Harris (rickfharris) wrote :

It's a known kernel bug that Dell bluetooth is broken in kernels >=4.14, so sticking with the old kernel that works for now.

Kernel bluetooth bug causes bluez 97-hid2hci.rules udev rule to fail.
systemd-udevd has always consumed 100% whenever a udev rule fails (could be argued that's also a bug but at least you become immediately aware there's a problem).

Possibly no coincidence that the break was introduced at the same time kernel tree commits were made to btusb.c wrt. Dell 'features' being addded.

Marcel Schrijvers (mschrvrs) wrote :

Interesting read. If they are adding Dell 'features' then maybe also my built in webcam will one day work again as that also doesn't work.

Jesse McNichol (mcnichol) wrote :

Similar problem for me. Dell E6530, Ubuntu 18.04

Downgraded to 4.13 headers as suggested above, disabled bluetooth in BIOS as suggested by others. Neither workaround helped. Computer still producing excess heat and systemd-udevd climbs to nearly 100% CPU usage gradually from startup.

QuentinHartman (qhartman) wrote :

You need to actually downgrade your running kernel to 4.13. Just
downgrading the headers isn't enough.

QH

On Sat, May 26, 2018 at 1:22 PM, Jesse McNichol <email address hidden>
wrote:

> Similar problem for me. Dell E6530, Ubuntu 18.04
>
> Downgraded to 4.13 headers as suggested above, disabled bluetooth in
> BIOS as suggested by others. Neither workaround helped. Computer still
> producing excess heat and systemd-udevd climbs to nearly 100% CPU usage
> gradually from startup.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1759836
>
> Title:
> systemd-udevd consumes 100% of CPU
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/bluez/+bug/1759836/+subscriptions
>

Andrea Bocci (fwyzard) wrote :

FYI: running with the 4.17-rc6 release candidate of the new kernel from https://wiki.ubuntu.com/Kernel/MainlineBuilds seems to have fixed the issue for me.

Andrea Bocci (fwyzard) wrote :

And it seems to be fixed also in the current stable kernel, 4.16.11 .

JR (juergen-richtsfeld) wrote :

I tried it with mainline 4.16.12 and 4.17-rc7 on the Dell Latitude and the problem still exists.

Chainick (chainick95) wrote :

Removing the bluez package solves the problem for me. After that bluetooth does not work, of course.

on bionic, stopping udevd and starting it again correct the problem:

sudo systemctl stop systemd-udevd systemd-udevd-control.socket systemd-udevd-kernel.socket
sudo systemctl start systemd-udevd systemd-udevd-control.socket systemd-udevd-kernel.socket

gveiga Ubuntu (gveiga-ubuntu) wrote :

Same problem with an old Dell Inspiron 1545 recently upgraded to Ubuntu 18.04 (4.15.0-22-generic). After disabling Bluetooth in the Bios and removing package Bluez, system is usable again.

David Matějček (dmatej) wrote :

I had this problem with NVidia after I disabled nvidia card in BIOS.

As per https://patchwork.kernel.org/patch/10384111/ editing 97-hid2hci.rules as follows works around the new uevents added to the kernel in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1455cf8dbfd06aa7651dcfccbadb7a093944ca65

-ACTION=="remove", GOTO="hid2hci_end"
+ACTION!="add", GOTO="hid2hci_end"

Bluetooth now works with kernels above and below 4.14.

Rick Harris (rickfharris) wrote :

As per https://patchwork.kernel.org/patch/10384111/ message from Bluez mailing list, editing 97-hid2hci.rules as follows works around the new uevents added to the kernel in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1455cf8dbfd06aa7651dcfccbadb7a093944ca65

-ACTION=="remove", GOTO="hid2hci_end"
+ACTION!="add", GOTO="hid2hci_end"

Bluetooth now works with kernels above and below 4.14.

Scratch that last comment, on further testing found I was booted into incorrect kernel :/

Editing of 97-hid2hci.rules is not a solution.

Only surefire way of getting bluetooth back and working with kernels >=4.14, was to revert the bogus kernel commit that added the bind/unbind uevents.

Created attachment 276537
revert-bind_unbind-uevents.patch

Changed in bluez:
importance: Unknown → High
status: Unknown → Confirmed
Changed in kernel:
importance: Unknown → High
status: Unknown → Confirmed
Daniel Angio (daoangio) wrote :

I had the same problem with 2 Dell of the year 2008

I have a same problem too. My system is too slow and so overheated.

My machine:
Ubuntu 18.04
Vostro 3500
Intel Core i5 540m
NVidia GT-310m

Please, help me!

Svip (svippy) wrote :

I am having a similar problem after upgrading to 18.04 on a Dell Precision M4600, with the following specs:

- Intel Core i7 2640M
- NVidia Quadro 2000M

I have disabled Bluetooth entirely, because I don't need it. But the NVidia loading/unloading (add/remove) in udev keeps persisting. I can disable this by removing the nvidia-rules (71-nvidia-rules) from the rules.d-directory, but that also disables the module entirely, and I need the nvidia module, I just wish it would not unload.

This issue seems to be about Bluetooth, although plenty of mentions of NVidia, should I create a separate one for the nvidia driver issue?

August Pamplona (cosmicaug-h) wrote :

The issue also showed up with on my laptop. I was running Mint 19 (still on the BETA) which is based on Bionic Beaver, kernel is 4.15.0-24-generic x86_64 bits with Cinnamon 3.8.6. I did try booting with 4.15.0-22 and it made no difference (which, after reading the comments here, I see is as expected)

The laptop is a Latitude E6400. It's one with the nVidia graphics. I don't remember what the Bluetooth adapter is (it's something I added, not necessarily something that would have come from Dell).

Bored Individual (karnemelk) wrote :

Got the same problem on a Dell E6400 Laptop.

Systemd-udevd climbs to 100% cpu usage in minutes, making it verify difficult and horrible to install, if one can manage to find the patience, only to find out that this problem persists after the installation.

I could install after:

systemctl disable systemd-udevd.service
systemctl disable systemd-udevd-control.socket
systemctl disable systemd-udevd-kernel.socket
systemctl stop systemd-udevd.service
systemctl stop systemd-udevd-control.socket
systemctl stop systemd-udevd-kernel.socket
then kill -9 any systemd-udevd process that remained active

After this the installation went fine and fast.

Disabling bluetooth in the bios did not work for me.
Disabling wireless in the bios works to some extend, systemd-udevd takes around ~50% cpu instead of 100%

Downgrade to 4.13 kernel worked like a charm, no problems after that.

I had some problems switching to the nvidia driver, so i had to stick with nouveau (which works great)

Mikhail (micvvv) wrote :

gaetan-quentin's workaround helped me for now:

systemctl stop systemd-udevd
sudo apt remove *nvidia-compute-utils*
systemctl start systemd-udevd

(Lenovo P51)

Mikhail (micvvv) wrote :

After some time CPU load grew to 100% again.

Have found another workaround which is working so far (disabling nvidia rules for udev):

sudo mv /lib/udev/rules.d/71-nvidia.rules /lib/udev/rules.d/71-nvidia.save

(and then restart).

Vinícius Milanez Couto, in order to allow additional upstream mainline kernel developers to examine the issue, at your earliest convenience, could you please test the latest mainline kernel? Please keep in mind the following:
1) The one to test is in a folder at the very top of the page (not the daily folder).
2) The release names are irrelevant.
3) The folder time stamps aren't indicative of when the kernel actually was released upstream.
4) Install instructions are available at https://wiki.ubuntu.com/Kernel/MainlineBuilds .

If testing on your main install would be inconvenient, one may:
1) Install Ubuntu to a different partition and then test this there.
2) Backup, or clone the primary install.

If the latest kernel did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to the issue. Once you've tested the mainline kernel, please comment on which kernel version specifically you tested. If this issue is not reproducible in the mainline kernel, please add the following tags by clicking on the yellow circle with a black pencil icon, next to the word Tags, located at the bottom of the Bug Description:
kernel-fixed-upstream
kernel-fixed-upstream-X.Y-rcZ

Where X, and Y are the first two numbers of the kernel version, and Z is the release candidate number if it exists.

If the issue is reproducible with the mainline kernel, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-X.Y-rcZ

Please note, an error to install the kernel does not fit the criteria of kernel-bug-exists-upstream.

Also, you don't need to apport-collect further unless specifically requested to do so.

It is most helpful that after testing of the latest mainline kernel is complete, you mark this report Status Confirmed.

Lastly, to keep this issue relevant to upstream, please continue to test the latest mainline kernel as it becomes available.

Thank you for your help.

affects: bluez → linux (Ubuntu)
Changed in linux (Ubuntu):
importance: High → Undecided
status: Confirmed → New
importance: Undecided → Low
status: New → Incomplete
tags: added: bios-outdated-a15 regression-potential
August Pamplona (cosmicaug-h) wrote :

Nope, getting rid of '/lib/udev/rules.d/71-nvidia.rules' does nothing.

It's a Mint 19 (Tara) with Cinnamon installation that I sometimes use on a Dell E6400 which used to work well with it before with earlier kernels.

August Pamplona (cosmicaug-h) wrote :

But the directions mentioned elsewhere from https://dev.solus-project.com/T5224 do work even thought they appear to break Bluetooth (even with the updated instructions workaround mentioned in that thread).

I use ubuntu 18.04 with 4.15 kernel
I have hit the same problem, but with synaptics touchpad.

I have bisected 4.13-4.14 and the problem was in commit 1455cf8dbfd06aa7651dcfccbadb7a093944ca65 (as in the attached patch)

I am unable to use USB bus because udev is bogged down with these bind/unbind events

```
UDEV [496.168312] bind /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.2/2-1.4.2:1.0 (usb)
KERNEL[496.175932] bind /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.2/2-1.4.2:1.0 (usb)
KERNEL[496.176947] unbind /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.2/2-1.4.2:1.0 (usb)
UDEV [496.177602] unbind /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.2/2-1.4.2:1.0 (usb)
KERNEL[496.185259] bind /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.2/2-1.4.2:1.0 (usb)
KERNEL[496.185479] unbind /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.2/2-1.4.2:1.0 (usb)
UDEV [496.186342] bind /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.2/2-1.4.2:1.0 (usb)
KERNEL[496.196813] bind /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.2/2-1.4.2:1.0 (usb)
KERNEL[496.197103] unbind /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.2/2-1.4.2:1.0 (usb)
UDEV [496.197501] unbind /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.2/2-1.4.2:1.0 (usb)
KERNEL[496.207283] bind /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4.2/2-1.4.2:1.0 (usb)
```

```
> cat /sys/bus/usb/devices/2-1.4/2-1.4.2/id*
8162
413c
```

```
> lsusb -d 413c:8162
Bus 002 Device 006: ID 413c:8162 Dell Computer Corp. Integrated Touchpad [Synaptics]
```

I also observed in my Dell laptop similar to Szymon that it relates to Touchpad.

My workarounds-
Soon after booting, stopping and starting systed-udev eliminates all bind and unbind problems and response drastically improves. I used the following commands in sequence-

sudo systemctl stop systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

sudo systemctl start systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

My understanding-
Before all hardware is discovered properly, bind/unbind start executing when no procedures are available and does not get reinitialized. After stopping and starting, it gets all the procedures in place. Probably, it is booting sequence problem.

SB (lumumba) wrote :

why is this still not fixed, it is quite a showstopper on dell systems

I've found that just sticking with kernel 4.13 has been working fine for
me. It works around this problem and for my use case hasn't had any
downsides.

On Sun, Sep 23, 2018 at 2:15 PM SB <email address hidden> wrote:

> why is this still not fixed, it is quite a showstopper on dell systems
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1759836
>
> Title:
> systemd-udevd consumes 100% of CPU
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kernel/+bug/1759836/+subscriptions
>

Bored Individual (karnemelk) wrote :

Still present in 4.19rc6, lets hope it gets fixed before 5.0.
If you guys want me to test things. Let me know.

(In reply to Y S Gupta from comment #8)

Same here. I used the commands from Szymon to find out what was going on and got the Synaptics Touchpad, too.

The workaround by Y S Gupta works like a charm. Put it in a startup script and everything is ok. THANK YOU!

QuentinHartman (qhartman) wrote :

Found this lkml thread for other issues related to this change. It seems the effort to run it down fizzled. What would be the best way to tie this to that to hopefully raise visibility / priority?

https://lkml.org/lkml/2018/4/6/221

QuentinHartman (qhartman) wrote :

and here is the commit that adds these events that are causing us such issues on the Dell hardware: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1455cf8dbfd06aa7651dcfccbadb7a093944ca65

Giovanni Panozzo (giox069) wrote :

I have the same problem on my old Dell Latitude E6400. Workaround at post #55 fixes the problem until next reboot.

Bored Individual (karnemelk) wrote :

Is this launchpad thing even working, how long does it take to fix a bug around here ?

This is untested but should work, let me know.
Execute the following commands, it will create a file called bugfix-1759836.service.
Copies it to /etc/systemd/system and enables it.

---
cat <<EOF>bugfix-1759836.service
[Unit]
Description=Fix for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1759836

[Service]
Type=oneshot
ExecStart=/bin/bash -c "services='systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket';systemctl stop $services;systemctl start $services"

[Install]
WantedBy=multi-user.target
EOF

sudo cp bugfix-1759836.service /etc/systemd/system
sudo systemctl enable bugfix-1759836.service
---
Then manually reboot.

Let me know if this works for you.

Richie Ward (richies) wrote :

Reproduced on Dell Inspiron 13z / 1370. I can work around it by turning off Bluetooth in BIOS.

Richie Ward (richies) wrote :

sudo systemctl stop systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

sudo systemctl start systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

Running this on startup seems to fix it.

Bored Individual (karnemelk) wrote :

Forgot the quotes around 'EOF', tested and it works for me.
Make sure you check if the service is enabled

Run the following commands:
---
cat<<'EOF'>bugfix-1759836.service
[Unit]
Description=Fix for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1759836

[Service]
Type=oneshot
ExecStart=/bin/bash -c "services='systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket';systemctl stop $services;systemctl start $services"

[Install]
WantedBy=multi-user.target
EOF

sudo cp bugfix-1759836.service /etc/systemd/system
sudo systemctl enable bugfix-1759836.service

systemctl status bugfix-1759836.service
---
It should display something like:
  Loaded: loaded (/etc/systemd/system/bugfix-1759836.service; enabled; vendor preset: enabled)

After a reboot again run:
systemctl status bugfix-1759836.service

Hopefully they get this fixed soon.

Kai-Heng Feng (kaihengfeng) wrote :

Sounds like a kernel bug instead? Please boot with kernel parameter `usbcore.dyndbg=+p` and attach dmesg.

Bored Individual (karnemelk) wrote :

Installed latest v4.19.1 with the added kernel parameter

Kai-Heng Feng (kaihengfeng) wrote :

Can you try comment out this section helps:
ATTR{bInterfaceClass}=="03", ATTR{bInterfaceSubClass}=="01", ATTR{bInterfaceProtocol}=="02", \
  ATTRS{bDeviceClass}=="00", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
  RUN+="hid2hci --method=dell --devpath=%p", ENV{HID2HCI_SWITCH}="1"

and this section:
ATTR{bDeviceClass}=="e0", ATTR{bDeviceSubClass}=="01", ATTR{bDeviceProtocol}=="01", ATTR{idVendor}=="413c", \
  ENV{REMOVE_CMD}="/sbin/udevadm trigger --action=change --subsystem-match=usb --property-match=HID2HCI_SWITCH=1"

Florian Dittmer (fd81) wrote :

Had the same problem on Dell Latitude E6400 laptop using Gentoo Linux with udev versions newer than udev-233. Disabling Bluetooth in BIOS solved the issue, however, I need bluetooth. Researching the web resulted in this page:

https://askubuntu.com/questions/1028883/ubuntu-18-04-systemd-udevd-uses-high-cpu-conflict-with-wifi

Following the instructions mentioned by one user in the comments helped me to solve the cpu load issue with udev-239 and kernel 4.18.17, while Bluetooth still works.

Run the following command:

/lib/systemd/systemd-udevd -D

This should print garbage in endless loop containing ".../97-hid2hci.rules:"

If so, edit /lib/udev/rules.d/97-hid2hci.rules

and add

ACTION=="add",

in front of line mentioned by above command.

In my case, I had to change the following lines in 97-hid2hci.rules from:

ATTR{bInterfaceClass}=="03", ATTR{bInterfaceSubClass}=="01", ATTR{bInterfaceProtocol}=="02", \
  ATTRS{bDeviceClass}=="00", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
  RUN+="hid2hci --method=dell --devpath=%p", ENV{HID2HCI_SWITCH}="1"

to:

ACTION=="add", ATTR{bInterfaceClass}=="03", ATTR{bInterfaceSubClass}=="01", ATTR{bInterfaceProtocol}=="02", \
  ATTRS{bDeviceClass}=="00", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
  RUN+="hid2hci --method=dell --devpath=%p", ENV{HID2HCI_SWITCH}="1"

And this fixed the issue (after reboot).

Best regards
Florian

i started this thread the day ubuntu 18 was released, I've tried the work
around. It solved my problem, so I want to thank the original solution
contributor (...forgot which email it was. Read it and implemented it a
while ago). but I also thank you Florian for the clear, concise, well
articulated, up to date description of the work around. Specifically the
line numbers and code diff. much appreciated.

Kai-Heng Feng (kaihengfeng) wrote :

Florian,
So it works in udev-232 but not udev-233? Sounds like a regression.

Command from Y S Gupta fixed to high cpu load for me.
As this is just a workaround. I suppose this bug should remain open.
Thanks for this, i can now reuse my bluetooth card.

Jeff Simpson (jeffsimpson) wrote :

I can confirm that the solution Florian posted (modifying /lib/udev/rules.d/97-hid2hci.rules) works for me as well.

Dell Latitude E6500, Kubuntu 18.04 with hwe kernel (4.18.0-13-generic), udev/systemd version 237-3ubuntu10.9, bluez version 5.48-0ubuntu3.1

When I boot up every day without exception, my machine starts up with one of the CPU cores running at 100%. I see lots of posts on other forums (Unbuntu etc) going back over a year or more blaming touchpads or nvidia or WiFi. Some even say they can't use their thumb drive if it isn't plugged in when they boot. The problem also mimics a defective thumb drive where you plug it in and Ubuntu doesn't see it (because systemd-udevd doesn't have the cycles to process the newly plugged in USB device). Losing one core makes my machine slower but not too noticeably so. I do see much longer boot times and sometime it will hang entirely during boot. I assume a single core or dual core machine will be drastically slowed down or even unusable. When I search I find other non-ubuntu os's complaining about similar problems.

I have 18.10 running on my Dell studio XPS with an AMD® Phenom(tm) ii x4 945 processor × 4 and AMD® Juniper graphics. It's a quad-core 64 bit machine. I have wireless mouse and keyboard for Logitech. I have a pretty vanilla set-up. I DO NOT have a touchpad or nvidia or WiFi!

I can verify that the problem can be managed by stopping and starting systemd-udevd. I used the following commands, suggested in this bug report, in sequence in the terminal which corrects the problem until I boot again.

sudo systemctl stop systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

sudo systemctl start systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

Also the problem will "sometimes" re-appear by plugging in a thumb drive!

This is a serious kernel problem and can manifest its presence in a number of ways depending on your hardware configuration.

This is a very very very annoying problem will someone PLEASE fix it soon! ...did I mention that this is a serious problem impacting many people!

BTW, add to my previous comment an additional symptom: sometimes my system will "appear to hang" entirely during boot (but it will power down normally by briefly touching the power off button when it "looks like" it is stuck).

Bored Individual (karnemelk) wrote :

I too can confirm that the solution Florian posted (modifying /lib/udev/rules.d/97-hid2hci.rules) works.

Dell Latitude E6400, Ubuntu-Mate 18.04LTS with generic kernel (Linux 4.15.0-43-generic), udev/systemd version 237-3ubuntu10.11, bluez version 5.48-0ubuntu3.1

SB (lumumba) wrote :

still no fix :(

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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