systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez

[Vinícius Milanez Couto]

[impact]

on specific Dell systems, with a specific usb bluetooth device built-in, the udev rule 'hid2hci' provided by the 'bluez' package causes an endless loop of uevents resulting from 'bind' or 'unbind' kernel uevents. These new events were added to the kernel after the 'hid2hci' udev rule was written.

[test case]

the specific Dell system is required to be able to reproduce this, or at least the specific usb bluetooth hardware included in that system.

Reproducing this is reportedly easy, for example comment 75 indicates it happens on every boot.

When this happens, any process monitor (e.g. ps, top, etc) will show the 'udevd' process using 100% of a cpu, and 'udevadm monitor' should show repeated 'bind' and 'unbind' events as mentioned in comment 39.

[regression potential]

as this alters what kernel uevents the 'hid2hci' udev rule processes, regressions would involve the affected usb bluetooth device failing to be set up, or otherwise not processing the uevents correctly.

[other info]

this is not fixed yet upstream, as of my last check, but has been submitted upstream as mentioned in comment 95.

original 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.

[mathieutournier (mathieutournier-linux-kernel-bugs)]

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)]

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

[ubuntu user (ubuntu-user-123)]

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!

[B.H.J. Thate (botfather)]

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)]

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.

[[e-mail] (ephillipe)]

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.

[Gaétan QUENTIN (gaetan-quentin)]

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'.

[Gaétan QUENTIN (gaetan-quentin)]

and cannot disable nvidia-persistenced.service:

systemctl disable nvidia-persistenced.service

 -> wait a loooong time
and still here

[Gaétan QUENTIN (gaetan-quentin)]

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

it s ok now

[Andrea Bocci (fwyzard)]

Also reported on Solus [https://dev.solus-project.com/T5224], Manjaro [https://forum.manjaro.org/t/high-cpu-usage-on-kernel-4-14-and-4-15-from-systemd-udevd-which-seems-to-be-the-synaptic-touchpad-driver/35972] and Gentoo (on the Manjaro page).

[Daniel van Vugt (vanvugt)]

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'.

[boro (boro-linux-kernel-bugs)]

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)]

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

[lucent (lucent-linux-kernel-bugs)]

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)]

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)]

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)]

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)]

Please help this makes my laptop completely usless

[Wedge009 (wedge009)]

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)]

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)]

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

[Kunwardeep Singh (kunwardeep-singh)]

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

[Marcel Schrijvers (mschrvrs)]

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)

[Lumar (lmspamkill)]

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=...

[Vivek Agrawal (vickymnit)]

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

[f.dittmer (f.dittmer-linux-kernel-bugs)]

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)]

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

[Rick Harris (rickfharris)]

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)]

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)]

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)]

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)]

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)]

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

[JR (juergen-richtsfeld)]

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

[Chainick (chainick95)]

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

[Gaétan QUENTIN (gaetan-quentin)]

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)]

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)]

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

[rickfharris (rickfharris-linux-kernel-bugs)]

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)]

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.

[rickfharris (rickfharris-linux-kernel-bugs)]

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.

[rickfharris (rickfharris-linux-kernel-bugs)]

Created attachment 276537
revert-bind_unbind-uevents.patch

[DOA (daoangio)]

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

[Emerson Novais Oliveira (emerson-novais)]

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)]

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)]

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)]

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)]

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)]

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).

[penalvch (penalvch)]

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.

[August Pamplona (cosmicaug-h)]

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)]

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).

[sobik.szymon (sobik.szymon-linux-kernel-bugs)]

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]
```

[ysg (ysg-linux-kernel-bugs)]

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)]

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

[QuentinHartman (qhartman)]

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)]

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

[brunofcosouza (brunofcosouza-linux-kernel-bugs)]

(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)]

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)]

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)]

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

[Bored Individual (karnemelk)]

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)]

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

[Richie Ward (richies)]

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)]

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)]

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

[Bored Individual (karnemelk)]

Installed latest v4.19.1 with the added kernel parameter

[Kai-Heng Feng (kaihengfeng)]

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)]

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

[ach619 (ach619)]

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)]

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

[mathieutournier (mathieutournier-linux-kernel-bugs)]

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)]

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

[jgwphd (jgwphd-linux-kernel-bugs)]

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!

[jgwphd (jgwphd-linux-kernel-bugs)]

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)]

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)]

still no fix :(

[elios (civo)]

I'am not even able to install ubuntu 18.04 because of this, it keeps printing the error message and it's stuck.

[gustavo.willer (gustavo.willer-linux-kernel-bugs)]

I have the same problem, that John related.

I have dell n5010, with SSD. Run F30 and suffer to connect bluedio t4.

If I Uninstall the package bluez-hid2hci, the problem of boot cpu with systemd-udevd dissappear. But at same time, I lost the connection of bluetooth device.

[jgwphd (jgwphd-linux-kernel-bugs)]

An update: The problem I reported in January went away on its own after a few weeks of having the problem every single day when I booted each morning. I was installing Ubuntu software updates when they became available during that time. There is something going on during boot that causes this problem.

"my speculation" is that I suspect a timing issue with the way things are initialized during boot up that leads to the problem. Some strange timing issue is occurring which causes systemd-udevd to fall into an infinite loop (continuously looking for something or to be notified about an action completion) and drive one of the processor cores to 100%. When a new kernel was installed or something was done to change initialization activity during boot the problem went away because the timing problem that created it was changed. I believe that some kind of race condition may be at the root of the problem.

From my earlier search on the problem symptoms, it seems that when systemd-udevd isn't working correctly you can get numerous confusing symptoms that mysteriously go away when the something changes timing conditions during boot. Since the problem is in the kernel then it effects other systems besides Ubuntu.

[gustavo.willer (gustavo.willer-linux-kernel-bugs)]

I fix the problem with this approach:

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1759836/comments/70

from "Florian Dittmer (fd81)"

"
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).
"

from

[jgwphd (jgwphd-linux-kernel-bugs)]

These nerd-level suggestions all work but the root cause (the real problem) is not solved and will pop up again. How is the non-nerd supposed to do this? ...would you want your neighbor editing your system files???? Someone needs to fix this permanently!

[gustavo.willer (gustavo.willer-linux-kernel-bugs)]

I agree with you, its not the best solution. This bug impact many users! At next release of this softwares this bug has to be fixed.

But I lost many days to fix this problem, and I'm sharing this 'hard approach' at forums I had visited before. So other people do not waste so much time!

[jgwphd (jgwphd-linux-kernel-bugs)]

This problem has been around for a long time and a lot of people have struggled with it. You can find examples such as the following on quite a few help sites, for example

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

[Mortimer (blackpenguin)]

This is a problem for non-dell computers also.

18.04.2

kernel:
4.18.0-21

This link is down:
https://dev.solus-project.com/T5224

Was the workaround mentioned there different than the ones here?

-

Is there a bluetooth file that people can easily remove with Synaptic so we don't have to tell them to go edit code? Part of the problem with that is it will ask them to remove the network manager though and they won't be able to get on the internet if they ok it.

[August Pamplona (cosmicaug-h)]

Mortimer, it's still available at the Google cache:
https://webcache.googleusercontent.com/search?https://webcache.googleusercontent.com/search?q=cache:Ulh1YXwMuK8J:https://dev.getsol.us/T5224

It appears that the fix there addresses the same file and the same line in that file. However, the lines are simply being deleted there & it breaks Bluetooth so I wouldn't go that route (though at the time I did due to not knowing any better).

They are also placing it at a different location, /etc/udev/rules.d/, and I don't know the significance of that.

And to address what others are saying, yes, hand editing a system file (and one, at that, which is headed by the comment line "# do not edit this file, it will be overwritten on update") is not an optimal solution.

[August Pamplona (cosmicaug-h)]

OK, so this is annoying.

The background behind the report I made on 2018-07-03 (message #47) is that I have had a Mint install on a desktop computer (fairly old hardware) and that at some point I started to switch over to the Dell Latitude E6400 laptop that I mentioned (just swap the hard drive, an ssd). This just worked. This is something that didn't use to just work with Linux many years ago and I was pleased that it now does.

At some point, it developed this high cpu use issue (I believe this happened upon the switch to Mint 19 but earlier is possible since my noticing this would depend on how often I tried using the hard drive with the Mint install in the Dell laptop which at this point may not have been that often).

I applied one fix mentioned here & the issue went away (although it broke Bluetooth). I forgot about it for a while.

At some point, I created a full separate install on a USB flash drive just to have an install to play with because I needed something Ubuntu based (Mint being close enough for my purposes) —though I did choose to go with Mate instead of Cinnamon (which is what I have on my main install). Of course, I had the same issue again. I went back to this thread to refresh my memory about fixing the issue and noticed the slightly better fix for the issue mentioned in message #70. The fix worked and I was glad to find that Bluetooth works.

So now came the time when I decided I will be using my main install from my desktop in my laptop again for a period of time and I am surprised to find that when it boots I am greeted with a message advising me that it's "Running in software rendering mode" and that I should expect high cpu use. Then I notice that I'm again having high cpu use even for running in rendering mode (from ~45%-100% —and maybe going closer to 100% over time?).

Investigating this leads me,... right back to here. The issue with the '/97-hid2hci.rules' is gone (having also applied the fis from message #70 on this install) but now I seem to have the same issue as what Gaétan QUENTIN writes about on this thread on message #7 on the date of 2018-05-02.

I attempted the fix from #9 and it did not work. I then attempted the fix from #50 and it got rid of the repeating Nvidia messages mentioned in #7 when executing 'sudo /lib/systemd/systemd-udevd -D'. However, the message "Running in software rendering mode" and cpu use may have gone down slightly but is still extremely high. I don't know how to get rid of this. My inclination was to go to the Driver manager to try to enable the recommended nvidia-340 binary driver but my only allowed choice is 'Continue using a manually installed driver' (the other options, the NVIDIA binary driver and the Nouveau driver are greyed out and not selectable).

Keep in mind that I did not have the issue with previous Mint versions and keep in mind that, after applying the fix described in message #70, a different install of the same Mint version number on the exact same hardware does not have this problem (however, the difference could be that this other install is using Mate).

[August Pamplona (cosmicaug-h)]

'However, the message "Running in software rendering mode" and cpu use may have gone down slightly but is still extremely high.' should have been written as 'However, the message "Running in software rendering mode" remains and cpu use may have gone down slightly but is still extremely high.'.

[August Pamplona (cosmicaug-h)]

Ignore my previous two posts.

It's fixed. I uninstalled & reinstalled Nvidia driver related things (which didn't really want to happen).

I don't know why it happened nor why it produced symptoms related to one of the posts here (maybe just an unrelated coincidence?) nor why it happened when I moved the hard drive to the Dell laptop.

[Mauro (mauromol)]

Same problem here with Debian 10, Dell Inspiron 13 1370.
Workaround by Florian works for me too.

[Karl Kastner (kastner-karl)]

Lenovo T510 with 4.18.0-25 is also effected, this strangely almost freezes the GUI, despite that systemd-udevd only occupies one core

[Dan Streetman (ddstreet)]

As many have commented, this is almost certainly a bug in the bluez udev rule 'hid2hci', that is caused by the introduction of 'bind' and 'unbind' uevents.

Can anyone who can reproduce this bug test with the bluez package from this ppa:
https://launchpad.net/~ddstreet/+archive/ubuntu/lp1759836

[Yury Pavlov (yura9)]

Great! Thank you, Dan, that is a fix for me.

My config:
Dell Studio 1558
Ubuntu MATE 18.04.3 LTS, Linux 5.0.0-25-generic x86_64
lsusb (partial):
Bus 001 Device 007: ID 413c:8160 Dell Computer Corp. Wireless 365 Bluetooth
Bus 001 Device 006: ID 413c:8162 Dell Computer Corp. Integrated Touchpad [Synaptics]
Bus 001 Device 005: ID 413c:8161 Dell Computer Corp. Integrated Keyboard
Bus 001 Device 003: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)

[Dan Streetman (ddstreet)]

> that is a fix for me

excellent, thanks. The patch there is the same idea as from comment 70, to only process the hid2hci rules on 'add' action events. It's the same as was proposed upstream:
https://lore.kernel.org/patchwork/patch/902126/#1138115

The only thing needed now before merging this fix is for upstream to accept the patch, I sent an email to poke the mailing list.

https://lore.kernel.org/linux<email address hidden>/

[Jón Bjarni Bjarnason (jbbjarnason)]

Hi

I tried your fix Dan and it seems not to work. I am running on popOs 19.04 (Dell latitude E6530 i7)

kernel vers: Linux 5.0.0-25-generic x86_64

$ sudo apt-cache policy bluez
bluez:
  Installed: 5.50-0ubuntu2+bug1759836v20190827b1~disco

from top:
488 root 20 0 66264 51564 3208 R 100.0 0.4 18:10.64 systemd-udevd

I previously disabled the bluetooth in the bios.

This is my .rules file (after the update):

# do not edit this file, it will be overwritten on update

ACTION!="add", GOTO="hid2hci_end"
SUBSYSTEM!="usb*", GOTO="hid2hci_end"

# Variety of Dell Bluetooth devices - match on a mouse device that is
# self powered and where a HID report needs to be sent to switch modes
# Known supported devices: 413c:8154, 413c:8158, 413c:8162
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"

# Logitech devices
KERNEL=="hiddev*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[345abce]|c71[3bc]", \
  RUN+="hid2hci --method=logitech-hid --devpath=%p"
# Logitech, Inc. diNovo Edge Keyboard
KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c7[01]4", \
  RUN+="hid2hci --method=logitech-hid --devpath=%p"

ENV{DEVTYPE}!="usb_device", GOTO="hid2hci_end"

# When a Dell device recovers from S3, the mouse child needs to be repoked
# Unfortunately the only event seen is the BT device disappearing, so the mouse
# device needs to be chased down on the USB bus.
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"

# CSR devices
ATTR{idVendor}=="0a12|0458|05ac", ATTR{idProduct}=="1000", RUN+="hid2hci --method=csr --devpath=%p"

LABEL="hid2hci_end"

[Dan Streetman (ddstreet)]

> I tried your fix Dan and it seems not to work.

hmm, can you run this cmd and capture a bit of output to paste here? it probably will generate a lot of output that repeats, so just pasting a short bit of it should be enough:

$ sudo udevadm monitor

[Jón Bjarni Bjarnason (jbbjarnason)]

Sorry for the late reply. Here comes the output:
KERNEL[90619.640204] remove /module/nvidia (module)
UDEV [90619.659490] add /kernel/slab/:0012288 (slab)
KERNEL[90619.696504] add /module/nvidia (module)
KERNEL[90619.697757] add /kernel/slab/:0012288 (slab)
KERNEL[90619.697792] add /bus/pci/drivers/nvidia-nvswitch (drivers)
KERNEL[90619.698144] remove /bus/pci/drivers/nvidia-nvswitch (drivers)
UDEV [90619.734780] add /bus/pci/drivers/nvidia-nvswitch (drivers)
KERNEL[90619.760125] remove /kernel/slab/:0012288 (slab)
KERNEL[90619.780134] remove /module/nvidia (module)
UDEV [90619.799634] add /module/nvidia (module)
UDEV [90619.863581] remove /module/nvidia (module)
UDEV [90619.914399] remove /bus/pci/drivers/nvidia-nvswitch (drivers)
UDEV [90619.980993] remove /kernel/slab/:0012288 (slab)
KERNEL[90619.987727] add /kernel/slab/:A-0000256/cgroup/filp(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.987765] add /kernel/slab/dentry/cgroup/dentry(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.987787] add /kernel/slab/inode_cache/cgroup/inode_cache(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.987807] add /kernel/slab/:A-0000128/cgroup/pid(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.987827] add /kernel/slab/sock_inode_cache/cgroup/sock_inode_cache(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.987846] add /kernel/slab/:A-0001024/cgroup/UNIX(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.987873] add /kernel/slab/skbuff_head_cache/cgroup/skbuff_head_cache(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.987893] add /kernel/slab/kmalloc-512/cgroup/kmalloc-512(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.987918] add /kernel/slab/:A-0000192/cgroup/cred_jar(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.987938] add /kernel/slab/mm_struct/cgroup/mm_struct(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.987956] add /kernel/slab/:A-0000208/cgroup/vm_area_struct(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.988007] add /kernel/slab/:A-0000064/cgroup/anon_vma_chain(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.988029] add /kernel/slab/anon_vma/cgroup/anon_vma(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.988058] add /kernel/slab/kmalloc-192/cgroup/kmalloc-192(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.988076] add /kernel/slab/kmalloc-1k/cgroup/kmalloc-1k(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.988094] add /kernel/slab/task_struct/cgroup/task_struct(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.988113] add /kernel/slab/:A-0000080/cgroup/task_delay_info(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.988128] add /kernel/slab/:A-0000704/cgroup/files_cache(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.988144] add /kernel/slab/sighand_cache/cgroup/sighand_cache(351529:nvidia-persistenced.service) (cgroup)
KERNEL[90619.988159] add /kernel/slab/:A-0001088/cgroup/signal_cache(351529:nvidia-persistenced.service) (...

[Dan Streetman (ddstreet)]

> Sorry for the late reply. Here comes the output:
> KERNEL[90619.640204] remove /module/nvidia (module)
> KERNEL[90619.696504] add /module/nvidia (module)

ok, your problem is that something is constantly adding and removing the nvidia module (and, doing other related device processing). That has nothing to do with this bug's problem, which is ONLY for udev looping due to rules in the bluez package's hid2hci rules file. I updated the bug subject to clarify that (scanning back through all the comments, I think most if not all of the discussion focuses on this specific package and rule).

You do seem to be having some other problem, which probably is with the nvidia-persistenced.service, provided by the nvidia-compute-utils-NNN package (with NNN being a number). Check:

$ dpkg -l | grep nvidia

to see the specific package name/version on your system. I don't really know what the problem is there, but you could try removing the package (if you don't need it), or searching for and/or opening a new bug for the problem.

[Launchpad Janitor (janitor)]

This bug was fixed in the package bluez - 5.50-0ubuntu4

---------------
bluez (5.50-0ubuntu4) eoan; urgency=medium

  * d/p/lp1759836.patch: avoid endless udev events from new bind uevents
    (LP: #1759836)

 -- Dan Streetman <email address hidden> Tue, 10 Sep 2019 17:22:37 -0400

[Brian Murray (brian-murray)]

Hello Vinícius, or anyone else affected,

Accepted bluez into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/bluez/5.50-0ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

Hello Vinícius, or anyone else affected,

Accepted bluez into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/bluez/5.48-0ubuntu3.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Dan Streetman (ddstreet)]

@yura9, @mauromol, or anyone experiencing this, if you are running Bionic or Disco, can you please test with the 'bluez' package currently in -proposed? See the previous 2 comments for instructions how.

This bug does need someone affected by this bug (i.e. with the affected hardware) to verify it before it's released.

[Tristan Hill (stan)]

Works for me with 5.50-0ubuntu2.1 on an old dell.

[Dan Streetman (ddstreet)]

@stan thanks for testing on Disco.

if anyone can please test the package on Bionic, that would be appreciated, this fix won't be released until someone affected by this problem tests the proposed fix and verifies it fixes it.

[Launchpad Janitor (janitor)]

This bug was fixed in the package bluez - 5.50-0ubuntu2.1

---------------
bluez (5.50-0ubuntu2.1) disco; urgency=medium

  * d/p/lp1759836.patch: avoid endless udev events from new bind uevents
    (LP: #1759836)

 -- Dan Streetman <email address hidden> Tue, 10 Sep 2019 17:24:43 -0400

[Łukasz Zemczak (sil2100)]

The verification of the Stable Release Update for bluez has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Dan Streetman (ddstreet)]

there's a lot of people subscribed to this bug, and presumably interested in seeing it fixed on Bionic; can any of you please test with the package from bionic-proposed and report the results? Until you do, it's unlikely this fix will be released into bionic-updates.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.

Or you can directly download the proposed debs from this (amd64) build page:
https://launchpad.net/ubuntu/+source/bluez/5.48-0ubuntu3.2/+build/17810460

please someone test on Bionic!

[Dan Streetman (ddstreet)]

nobody who has been affected by this bug is able to test on Bionic?

@stan are you able to test using Bionic by any chance?

[David Killingsworth (davidkillingsworth)]

Dan,

I can confirm that after enabling proposed for bionic and then issuing the command which installs bluez/5.48-0ubuntu3.2

$ sudo apt-get install bluez/bionic-proposed

The issue has been fixed for me.

I have a Dell Latitude E5400.

Thanks,
David

[Dan Streetman (ddstreet)]

thank you! marking as verified for bionic :)

[Launchpad Janitor (janitor)]

This bug was fixed in the package bluez - 5.48-0ubuntu3.2

---------------
bluez (5.48-0ubuntu3.2) bionic; urgency=medium

  * d/p/lp1759836.patch: avoid endless udev events from new bind uevents
    (LP: #1759836)

 -- Dan Streetman <email address hidden> Tue, 10 Sep 2019 17:25:22 -0400

[mathieutournier (mathieutournier-linux-kernel-bugs)]

Finnally solved !
5.15 kernel and ubuntu 22.04 upgrade solved totally the issue for me.
I can enable my integrated Dell BT card again :)