Systemd filling up syslog with bluetooth resets

triantares · October 16, 2019, 6:11am

On my machine there seems to be a problem with systemd resetting USB bluetooth all the time. It looks to be connected to laptop-mode-settings and has only become apparant this last week.
Using "systemctl disable bluetooth" doesn't help in any way. Anybody got any pointers as my log files are getting biiiig.

Here's the output of :tail -f /var/log/syslog":

Oct 16 07:56:37 localhost URfkill[808]: killswitch state: KILLSWITCH_STATE_UNBLOCKED new_state: KILLSWITCH_STATE_UNBLOCKED``
Oct 16 07:56:37 localhost URfkill[808]: Setting device 16 (BLUETOOTH) to unblock``
Oct 16 07:56:37 localhost kernel: [  178.867099] usb 2-7: New USB device found, idVendor=8087, idProduct=07dc, bcdDevice= 0.01``
Oct 16 07:56:37 localhost kernel: [  178.867101] usb 2-7: New USB device strings: Mfr=0, Product=0, SerialNumber=0``
Oct 16 07:56:37 localhost kernel: [  178.870059] usb 2-7: USB disconnect, device number 18``
Oct 16 07:56:37 localhost URfkill[808]: device_changed_cb: tpacpi_bluetooth_sw``
Oct 16 07:56:37 localhost URfkill[808]: killswitch state: KILLSWITCH_STATE_UNBLOCKED new_state: KILLSWITCH_STATE_SOFT_BLOCKED``
Oct 16 07:56:37 localhost URfkill[808]: device_changed_cb: hci0``
Oct 16 07:56:37 localhost URfkill[808]: killswitch state: KILLSWITCH_STATE_SOFT_BLOCKED new_state: KILLSWITCH_STATE_SOFT_BLOCKED``
Oct 16 07:56:37 localhost URfkill[808]: device_changed_cb: hci0``
Oct 16 07:56:37 localhost URfkill[808]: killswitch state: KILLSWITCH_STATE_SOFT_BLOCKED new_state: KILLSWITCH_STATE_SOFT_BLOCKED``
Oct 16 07:56:39 localhost kernel: [  180.875207] Bluetooth: hci0: command 0x0c03 tx timeout

The output is continous and slowly but surelyy drives up CPU usage.
Here's what "top" says:

18939 root      20   0   23240   3836   2232 R 100.0   0.0   9:44.34 systemd-udevd                                                                                                                                        
14966 root      20   0   23240   3844   2240 R  46.7   0.0   5:13.77 systemd-udevd                                                                                                                                                
29955 root      20   0    2544   1280    956 S   5.0   0.0   0:00.15 laptop_mode

Edit (LupusE): Improve readability with 'Preformatted text' Instead of 'Blockquote'.

triantares · October 16, 2019, 6:26am

Doing "systemctl stop bluetooth.service" and after that "systemctl disable bluetooth.service"
gives the following output:

sudo systemctl disable bluetooth.service Synchronizing state of bluetooth.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install disable bluetooth insserv: warning: current start runlevel(s) (empty) of scriptbluetooth' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script bluetooth' overrides LSB defaults (0 1 6). insserv: warning: current start runlevel(s) (empty) of scriptbluetooth' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script bluetooth' overrides LSB defaults (0 1 6). ~ ❯❯❯

UPDATE

Starting and stopping udevd with:
sudo systemctl start systemd-udevd systemd-udevd-kernel.socket systemd-udevd-control.socket

Seems to solve this CPU hogging but I don't know what's causing it ...... I suspect waking up from suspend scripts.

Update the update

Connecting the charger is what causes this.
Unplugging makes all activity go away including the bluetooth activation.
This looks like a wrong setting in cpu-freq (it also resembles a bug I encountered in kernel 4.0.19-05) ... it could be because I used E2x to manipulate power-settings can anybody see if they have the same issues?

Thanatermesis · October 16, 2019, 7:44am

Syslogs filling up (few) sometimes happens with drivers that prints too much

Try to disable the daemon laptop-mode to see if is the one (that controls Bluetooth hooks) that makes all this printing

triantares · October 16, 2019, 8:31am

Yeah, well syslog is the slightest problem. The CPU hogging and subsequent overheating is.

As said it only happens if the charger is connected.
running the afore mentioned systemctl commands brings the CPU down to 3%.

rbrick49 · October 16, 2019, 1:51pm

so you guys a using laptops

triantares · October 16, 2019, 5:32pm

Well certainly me ...... when my desktop broke down I never repaired it but replaced it with laptops that had screen or other defects.

Thanatermesis · October 17, 2019, 2:58pm

"only if the charger is connected" this sounds to me that there can be only a possible reason: some kind of daemon that "detects AC" is triggering something, and thus, it can be probably laptop-mode daemon

So try to disable it to see if this is the cause of the issue, if so, maybe the bluetooth settings for laptop-mode should be disabled, if not, there should be another daemon that "does something" with bluetooth when AC

triantares · October 17, 2019, 4:21pm

Hmm, turning off bluetooth and acm97 (I don't need them, they're both disabled) by unchecking them in the "laptop-mode configuration tool" seems to keep everything quite for now.
Although there is a pop-up that some settings couldn't be saved.....very unclear but it looks to have done something and CONTROL_Bluetooth is set to 0.
Rechecking ac97 indeed resets it its value to 1 despite the pop-up..

Laptop-mode is quite the syslog filler at any rate.

Thanatermesis · October 17, 2019, 8:59pm

As I'm reading in the /etc/laptop-mode/ confs, AC97 has no relation with AC VS battery switching

So is blueotooth the feature that should be disabled in order to not have this issue?

triantares · October 18, 2019, 2:30am

yes, it is. AC97 is the sound module ..... at first I thought it was my built-in modem. Only disabling bluetooth is enough to keep systemd calm.

Thanatermesis · October 18, 2019, 10:25pm

ok, fixed package with bluetooth (management) disabled by default