bluetoothd: keeps an otherwise idle system from residing in deeper-than-PkgC8

[thac0]

My reference system-- a suspend-to-idle laptop form factor with a panel self-refresh (PSR1) panel-- with kernel-native and desktop bundles, is not able to achieve deep idle (>=PkgC10). This is unexpected and undesired.

I started disabling bells/whistles/features in the system's firmware settings, no change. Shot in the dark a few times and disabled some kernel driver bells/whistles/features, no change. Then, on a lark, I decided to repeat my idling experiments with a bare-bones Weston session. Lo and behold, I am able to achieve deep idle (>=PkgC10). Which seems to indicate there is a "vampire" gnome process, doing just enough work to keep the system busy, causing the reference system to consume more power than it should.

So, here's the path forward:

1. Root cause the issue ("which vampiric gnome(?) process(es) are behaving sub-optimally?")
2. Isolate and reproduce
3. Submit fix(es) to, and land in, Clear Linux
4. Submit fix(es) to, and land in, Gnome (all the way upstream)

[thac0]

Note to colleagues: I'd assign this to myself if I could, so please assign to me ( @thac0 ). Thanks!

[thac0]

The universe of possibles has been reduced to the services GDM launches. I reproduce the "stuck at PkgC8 while idling" issue if I log into Weston via GDM. First thing I turned off was the accounts-daemon service, but that wasn't it. Time to play whack-a-mole.

[thac0]

Uh oh. I checked this on Arch Linux as well. Their gdm (v3.32.0) does not exhibit the same "stuck at PkgC8 while idling" issue that Clear Linux does. Will need to drill into how we package gdm (and its runtime dependencies) to see where the problem is.

[fenrus75]

this this happen also with X and not wayland?

On Tue, Jun 11, 2019 at 10:17 AM Joe Konno notifications@github.com wrote:

Uh oh. I checked this on Arch Linux as well. Their gdm (v3.32.0) does not exhibit the same "stuck at PkgC8 while idling" issue that Clear Linux does. Will need to drill into how we package gdm (and its runtime dependencies) to see where the problem is.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/clearlinux/distribution/issues/861?email_source=notifications&email_token=AAJ54FN7P2L6HVJQN5VT2I3PZ7M3JA5CNFSM4HVLHVOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXN32OQ#issuecomment-500940090, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJ54FLCLU56UTJ3FJHNJVTPZ7M3JANCNFSM4HVLHVOA .

[thac0]

Seen with both X and Wayland, @fenrus75 . GDM seems to be the common denominator, though I'm nearly certain it's not the lowest common denominator. I'll keep digging.

[thac0]

Dug deeper, and right now all eyes are on the bluetooth service. Next step is to dig into how we package the bluetooth service, which will likely have me touching NetworkManager as well.

[thac0]

If I do an apples-to-apples comparison with Arch Linux-- starting NetworkManager.service, bluetooth.service, and gdm-- I see the exact same behavior. Bluetooth will hold my reference platform at PkgC8. One possible solution is to disable Bluetooth by default in Gnome, leaving it up to the user to turn it on. Another is to mess/finesse with bluez to see if we can get it to not poll/scan/whatever as frequently. There are likely others, but I'll chew on it for a while.

[fenrus75]

we should default Bluetooth to off and let the user switch it on

On Wed, Jun 12, 2019, 11:30 Joe Konno notifications@github.com wrote:

If I do an apples-to-apples comparison with Arch Linux-- starting NetworkManager.service, bluetooth.service, and gdm-- I see the exact same behavior. Bluetooth will hold the platform at PkgC8. One possible solution is to disable Bluetooth by default in Gnome, leaving it up to the user to turn it on. Another is to mess/finesse with bluez to see if we can get it to not poll/scan/whatever as frequently. There are likely others, but I'll chew on it for a while.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/clearlinux/distribution/issues/861?email_source=notifications&email_token=AAJ54FJRFJ3FZ4HNUHUCL3TP2E6DTA5CNFSM4HVLHVOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXRMBCA#issuecomment-501399688, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJ54FJIDZ6BEEJG5ZYX2ILP2E6DTANCNFSM4HVLHVOA .

[thac0]

we should default Bluetooth to off and let the user switch it on

Agreed.

Some background: gnome-control-center ("Settings") applet monitors the bluetooth device(s)'s rfkill "soft-block" state. If you "turn off" bluetooth in gnome-control-center, you "soft-block" that bluetooth device (and when you "turn on", you un-soft-block it).

Systemd is responsible for maintaining bluetooth device(s)'s rfkill state. It is, to my mind, appropriate to soft-block bluetooth devices on "first boot" of a bare-metal/native installation. From that point forward, the user will be in full control, with systemd ensuring their bluetooth device(s) are kept in the desired state.

Two approaches to this-- soft-blocking is (slightly) more involved than writing a simple value to a sysfs node:

1. Have clr-power-tweaks install a systemd unit with ConditionFirstBoot that runs rfkill block bluetooth. And unless the user deletes /etc/machine-id, it will never be run again. Today, this is my preferred approach.
2. Introduce a "one-shot-upgrade" script into swupd. This would require some care, because the reasonable approach (to my mind) would involve a check for paired gadgets before rfkill'ing bluetooth. This approach makes me nervous.

[thac0]

The quickest fix is, "if you aren't using bluetooth devices, just turn off Bluetooth in Gnome's system settings, or issue 'sudo rfkill block bluetooth'." Proper resolution of this involves a deeper dive into BlueZ and friends. I got a bit distracted, but the delve will resume in full next week.

[thac0]

When bluez inits the controller, it "powers on" that controller. With bluetoothctl, I've tried forcibly turning off discovery, scanning, even flagging the controller as non-pairable. No difference. Once that BlueZ daemon starts running, that controller is on and platform is held at PkgC8-- unless it's rfkill'ed, of course.

Marcel mentioned the possibility of introducing more granular controls to BlueZ's main.conf as one option. I'll keep that in mind; meanwhile, I'm still exploring the codebase. I'm almost at the point where I can engage with the BlueZ community with a straight face, so I'll be doing that over the next week or so.

[thac0]

To work around BlueZ's limitations, I posted a PR to, on first boot, soft block bluetooth controllers. This will implement a "powered off by default" policy for bluetooth controllers on (!container) fresh Clear Linux installations. In the meantime, I'll continue to work on adding more granular configuration controls to BlueZ:

• https://github.com/clearlinux/clr-power-tweaks/pull/4