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

Bug #1759836 reported by Vinícius Milanez Couto
338
This bug affects 64 people
Affects Status Importance Assigned to Milestone
The Ubuntu Power Consumption Project
New
Undecided
Unassigned
linux
Expired
High
bluez (Debian)
New
Unknown
bluez (Ubuntu)
Fix Released
Medium
Dan Streetman
Bionic
Fix Released
Medium
Dan Streetman
Disco
Fix Released
Medium
Dan Streetman
Eoan
Fix Released
Medium
Dan Streetman
linux (Ubuntu)
Invalid
Low
Unassigned
Bionic
Invalid
Undecided
Unassigned
Disco
Invalid
Undecided
Unassigned
Eoan
Invalid
Low
Unassigned
systemd (Ubuntu)
Invalid
Undecided
Unassigned
Bionic
Invalid
Undecided
Unassigned
Disco
Invalid
Undecided
Unassigned
Eoan
Invalid
Undecided
Unassigned

Bug Description

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

Revision history for this message
In , mathieutournier (mathieutournier-linux-kernel-bugs) wrote :

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

35 comments hidden view all 113 comments
Revision history for this message
Vinícius Milanez Couto (vimcless) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in systemd (Ubuntu):
status: New → Confirmed
Revision history for this message
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!

Revision history for this message
B.H.J. Thate (botfather) wrote : Re: [Bug 1759836] Re: systemd-udevd consumes 100% of CPU

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!
>

Revision history for this message
JR (juergen-richtsfeld) wrote : Re: systemd-udevd consumes 100% of CPU

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.

Revision history for this message
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.

Revision history for this message
Gaétan QUENTIN (gaetan-quentin) wrote :

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

Revision history for this message
Gaétan QUENTIN (gaetan-quentin) wrote :

and cannot disable nvidia-persistenced.service:

systemctl disable nvidia-persistenced.service

 -> wait a loooong time
and still here

Revision history for this message
Gaétan QUENTIN (gaetan-quentin) wrote :

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

it s ok now

Revision history for this message
Andrea Bocci (fwyzard) wrote :
Revision history for this message
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
26 comments hidden view all 113 comments
Revision history for this message
In , boro (boro-linux-kernel-bugs) wrote :

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.

25 comments hidden view all 113 comments
Revision history for this message
Juha Luoma (jsluoma) wrote :

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

26 comments hidden view all 113 comments
Revision history for this message
In , lucent (lucent-linux-kernel-bugs) wrote :

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.

25 comments hidden view all 113 comments
Revision history for this message
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.

Revision history for this message
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)
description: updated
Revision history for this message
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

Revision history for this message
ach619 (ach619) wrote :

Please help this makes my laptop completely usless

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
ilia fata (likeilia) wrote :

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

Revision history for this message
Kunwardeep Singh (kunwardeep-singh) wrote :

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

Revision history for this message
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
Revision history for this message
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...

Revision history for this message
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

16 comments hidden view all 113 comments
Revision history for this message
In , f.dittmer (f.dittmer-linux-kernel-bugs) wrote :

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.

15 comments hidden view all 113 comments
Revision history for this message
Marcel Schrijvers (mschrvrs) wrote :

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

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
QuentinHartman (qhartman) wrote : Re: [Bug 1759836] Re: systemd-udevd consumes 100% of CPU

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
>

Revision history for this message
Andrea Bocci (fwyzard) wrote : Re: systemd-udevd consumes 100% of CPU

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.

Revision history for this message
Andrea Bocci (fwyzard) wrote :

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

Revision history for this message
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.

Revision history for this message
Chainick (chainick95) wrote :

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

Revision history for this message
Gaétan QUENTIN (gaetan-quentin) wrote :

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

Revision history for this message
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.

Revision history for this message
David Matějček (dmatej) wrote :

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

Revision history for this message
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.

Changed in bluez:
importance: Unknown → High
status: Unknown → Confirmed
Changed in kernel:
importance: Unknown → High
status: Unknown → Confirmed
penalvch (penalvch)
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
37 comments hidden view all 113 comments
Revision history for this message
Jeff Simpson (jeffsimpson) wrote : Re: systemd-udevd consumes 100% of CPU

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

Revision history for this message
In , jgwphd (jgwphd-linux-kernel-bugs) wrote :

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!

Revision history for this message
In , jgwphd (jgwphd-linux-kernel-bugs) wrote :

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

Revision history for this message
Bored Individual (karnemelk) wrote : Re: systemd-udevd consumes 100% of CPU

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

Revision history for this message
SB (lumumba) wrote :

still no fix :(

Revision history for this message
elios (civo) wrote :

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

Revision history for this message
In , gustavo.willer (gustavo.willer-linux-kernel-bugs) wrote :

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.

Revision history for this message
In , jgwphd (jgwphd-linux-kernel-bugs) wrote :

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.

Revision history for this message
In , gustavo.willer (gustavo.willer-linux-kernel-bugs) wrote :

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

Revision history for this message
In , jgwphd (jgwphd-linux-kernel-bugs) wrote :

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!

Revision history for this message
In , gustavo.willer (gustavo.willer-linux-kernel-bugs) wrote :

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!

Revision history for this message
In , jgwphd (jgwphd-linux-kernel-bugs) wrote :

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

Revision history for this message
Mortimer (blackpenguin) wrote : Re: systemd-udevd consumes 100% of CPU

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.

Revision history for this message
August Pamplona (cosmicaug-h) wrote :

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.

Brad Figg (brad-figg)
tags: added: cscc
Revision history for this message
August Pamplona (cosmicaug-h) wrote :

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

Revision history for this message
August Pamplona (cosmicaug-h) wrote :

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

Revision history for this message
August Pamplona (cosmicaug-h) wrote :

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.

Revision history for this message
Mauro (mauromol) wrote :

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

Revision history for this message
Karl Kastner (kastner-karl) wrote :

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)
Changed in systemd (Ubuntu):
status: Confirmed → Invalid
Changed in bluez (Ubuntu):
status: Invalid → Confirmed
assignee: nobody → Dan Streetman (ddstreet)
status: Confirmed → In Progress
importance: Undecided → Medium
Changed in linux (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
Dan Streetman (ddstreet) wrote :

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

Revision history for this message
Yury Pavlov (yura9) wrote :

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)

Revision history for this message
Dan Streetman (ddstreet) wrote :

> 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>/

Revision history for this message
Jón Bjarni Bjarnason (jbbjarnason) wrote :

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"

Changed in bluez (Debian):
status: Unknown → New
Revision history for this message
Dan Streetman (ddstreet) wrote :

> 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

Revision history for this message
Jón Bjarni Bjarnason (jbbjarnason) wrote :
Download full text (4.1 KiB)

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

Read more...

Dan Streetman (ddstreet)
summary: - systemd-udevd consumes 100% of CPU
+ systemd-udevd consumes 100% of CPU due to hid2hci udev rule from bluez
Revision history for this message
Dan Streetman (ddstreet) wrote :

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

Dan Streetman (ddstreet)
Changed in systemd (Ubuntu Disco):
status: New → Invalid
Changed in systemd (Ubuntu Bionic):
status: New → Invalid
Changed in linux (Ubuntu Disco):
status: New → Invalid
Changed in linux (Ubuntu Bionic):
status: New → Invalid
Changed in bluez (Ubuntu Disco):
assignee: nobody → Dan Streetman (ddstreet)
importance: Undecided → Medium
status: New → In Progress
Changed in bluez (Ubuntu Bionic):
assignee: nobody → Dan Streetman (ddstreet)
importance: Undecided → Medium
status: New → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in bluez (Ubuntu Eoan):
status: In Progress → Fix Released
Dan Streetman (ddstreet)
description: updated
Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

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.

Changed in bluez (Ubuntu Disco):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-disco
Revision history for this message
Brian Murray (brian-murray) wrote :

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.

Changed in bluez (Ubuntu Bionic):
status: In Progress → Fix Committed
tags: added: verification-needed-bionic
Revision history for this message
Dan Streetman (ddstreet) wrote :

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

Revision history for this message
Tristan Hill (stan) wrote :

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

Dan Streetman (ddstreet)
tags: added: verification-done-disco
removed: verification-needed-disco
Revision history for this message
Dan Streetman (ddstreet) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in bluez (Ubuntu Disco):
status: Fix Committed → Fix Released
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Update Released

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.

Revision history for this message
Dan Streetman (ddstreet) wrote :

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!

You-Sheng Yang (vicamo)
tags: added: ubuntu-certified
Revision history for this message
Dan Streetman (ddstreet) wrote :

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?

Revision history for this message
David Killingsworth (davidkillingsworth) wrote :

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

Revision history for this message
Dan Streetman (ddstreet) wrote :

thank you! marking as verified for bionic :)

tags: added: verification-done verification-done-bionic
removed: verification-needed verification-needed-bionic
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in bluez (Ubuntu Bionic):
status: Fix Committed → Fix Released
Revision history for this message
In , mathieutournier (mathieutournier-linux-kernel-bugs) wrote :

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

Changed in kernel:
status: Confirmed → Expired
Displaying first 40 and last 40 comments. View all 113 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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