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.
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 : Class}= ="03", ATTR{bInterface SubClass} =="01", ATTR{bInterface Protocol} =="02", \ bDeviceClass} =="00", ATTRS{idVendor} =="413c" , ATTRS{bmAttribu tes}==" e0", \ SWITCH} ="1"
ATTR{bInterface
ATTRS{
RUN+="hid2hci --method=dell --devpath=%p", ENV{HID2HCI_
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 a0085f2510e8976 614ad8f766b2094 48b385492f 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 : /dev.solus- project. com/T5224
https:/
Thanks a lot for your support,
Mathieu Tournier