Bugzilla – Bug 1092246
Tumbleweed: hid2hci called from a udev rule is constantly failing leading to a busy system
Last modified: 2018-05-22 15:32:39 UTC
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Build Identifier: I am only seeing this on one Tumbleweed system. The "top" command show one "systemd-udevd" process at near 100% processor time, and another at a bit under 50% processor time. I will attach the output of "ps -ef | grep udevd". This started in March or April -- I'm not sure which Tumbleweed snapshot. The system is currently up-to-date, and the problem continues. Reproducible: Always
Created attachment 769287 [details] A transcript showing the output of "ps -ef | grep udevd"
Could you try to attach to one of the udev processes with gdb and show the backtrace ? Otherwise can you try to reproduce with the udev debug logs enabled (see /etc/udev/udev.conf) ?
Created attachment 770648 [details] debug logs I set debug loggin in "udev.conf". I am attaching the compressed output from journalctl -b | grep udev (second try -- I failed to compress on the first try, and exceeded max attachment size)
Apparently there's something broken with 'hid2hci': Process 'hid2hci --method=dell --devpath=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6/2-1.6.2/2-1.6.2:1.0' failed with exit code 1 Perhaps something goes wrong with your HW and the tool is not able to handle gracefully... Where does this tool come from ? I can't find it in the regular repos...
>Where does this tool come from ? I can't find it in the regular repos... /usr/lib/udev/hid2hci Part of the "bluez" package, version 5.49-2.1-x86_64 from vendor openSUSE I'll note that I am not seeing the same problem in Leap 15.0 (on the same computer) with "bluez" version 5.48-lp150.3.1-x86_64 Also, I am not actually using any bluetooth devices.
OK let's re-assign this issue to the Bluez package maintainer since the problem happens in the rules shipped by this package.
This might be related: https://lkml.org/lkml/2018/5/7/326
Yes, that link from lkml.org does look related. I am not able to find that file on my system, so I suppose it has to do with rules that are built into the software. For the present, I am disabling bluetooth in the BIOS, which seems to avoid the problem.