This is really useful work. I'm already seeing ~20% battery improvement with Fedora 27 + 4.14.0-0.rc8.git3.1.fc28.x86_64 on an HP Spectre, and so far no regressions. I get better battery life with this combination than running Windows 10 with all the HP specific drivers for this model. Some tips on how regressions might manifest and what information to include in a good bug report would be useful. e.g. on an Intel NUC when I run powertop --auto-tune, and walk away (it's a server so it might be days) and come back the keyboard won't work. I've never done any troubleshooting other than just disable the powertop systemd unit, I'm vaguely suspicious of usb autosuspend and it not waking up when keys are pressed.

Am 14.11.2017 um 12:22 schrieb Gerd Hoffmann: >> This is really useful work. I'm already seeing ~20% battery >> improvement with Fedora 27 + 4.14.0-0.rc8.git3.1.fc28.x86_64 on an HP >> Spectre, and so far no regressions. I get better battery life with >> this combination than running Windows 10 with all the HP specific >> drivers for this model. >> >> Some tips on how regressions might manifest and what information to >> include in a good bug report would be useful. e.g. on an Intel NUC >> when I run powertop --auto-tune, and walk away (it's a server so it >> might be days) and come back the keyboard won't work. I've never done >> any troubleshooting other than just disable the powertop systemd unit, >> I'm vaguely suspicious of usb autosuspend and it not waking up when >> keys are pressed. > > autosuspend has a high chance to be the root cause for this one.  Yes, > its very messy, mostly due to bad hardware similar is happening on my homemachine with the mouse for years now, i just need to switch to a VT instead the graphical login/desktop and every few seconds the kernel pretends that the device got disconnected and connected again spitting dmesg and the current VT full so that it becomes practically unuseable

Auto suspend can be a real problem when it is keyboards and mice. I know there was a huge uproar with logitech unified receiver users when powertop would change the receiver to autosuspend and the keyboard/mouse became unresponsive for a couple of key presses. To be honest, I think this particular change may do much more harm than good.

I find it ironic that this misbehaving hardware is Intel's USB stuff, in their NUC, and powertop is an Intel managed project. I'd guess the powertop folks would already know better than to apply autosuspend to Intel USB hardware.

On Mon, Nov 13, 2017 at 10:16 AM, Chris Murphy <lists(a)colorremedies.com&gt; wrote: > On Mon, Nov 13, 2017 at 8:40 AM, Hans de Goede <hdegoede(a)redhat.com&gt; wrote: >> Hi all, >> >> As mentioned before I'm working on trying to improve the OOTB >> power-consumption of Fedora Workstation on laptops >> (I need to create an F28 feature page for this). >> >> On many laptops the btusb device is the only USB device not >> having USB autosuspend enabled, this causes not only the btusb >> device but also the USB controller to stay awake, together using >> aprox. 0.4W of power. Modern ultrabooks idle around 6W >> (at 50% screen brightness), 3.5W for Apollo Lake devices. >> 0.4W is a significant chunk of this (7 / 11%). >> >> So I would like to enable btusb autosuspend by default, to >> make this possible I've submitted the following kernel >> patch upstream which has just been merged (queued for 4.16): >> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.... >> >> If it is ok with the Fedora kernel team I would like to add >> this as a patch to the Fedora kernels for now and set >> the new BT_HCIBTUSB_AUTOSUSPEND option to y. This is not >> without a risk of regressions, so this is something for >> rawhide/F28 only. > > > This is really useful work. I'm already seeing ~20% battery > improvement with Fedora 27 + 4.14.0-0.rc8.git3.1.fc28.x86_64 on an HP > Spectre, and so far no regressions. I get better battery life with > this combination than running Windows 10 with all the HP specific > drivers for this model. > > Some tips on how regressions might manifest and what information to > include in a good bug report would be useful. e.g. on an Intel NUC > when I run powertop --auto-tune, and walk away (it's a server so it > might be days) and come back the keyboard won't work. I've never done > any troubleshooting other than just disable the powertop systemd unit, > I'm vaguely suspicious of usb autosuspend and it not waking up when > keys are pressed. > Auto suspend can be a real problem when it is keyboards and mice. I know there was a huge uproar with logitech unified receiver users when powertop would change the receiver to autosuspend and the keyboard/mouse became unresponsive for a couple of key presses. To be honest, I think this particular change may do much more harm than good.

On 11/13/2017 07:40 AM, Hans de Goede wrote: > Hi all, > > As mentioned before I'm working on trying to improve the OOTB > power-consumption of Fedora Workstation on laptops > (I need to create an F28 feature page for this). > > On many laptops the btusb device is the only USB device not > having USB autosuspend enabled, this causes not only the btusb > device but also the USB controller to stay awake, together using > aprox. 0.4W of power. Modern ultrabooks idle around 6W > (at 50% screen brightness), 3.5W for Apollo Lake devices. > 0.4W is a significant chunk of this (7 / 11%). > > So I would like to enable btusb autosuspend by default, to > make this possible I've submitted the following kernel > patch upstream which has just been merged (queued for 4.16): > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.... > > If it is ok with the Fedora kernel team I would like to add > this as a patch to the Fedora kernels for now and set > the new BT_HCIBTUSB_AUTOSUSPEND option to y. This is not > without a risk of regressions, so this is something for > rawhide/F28 only. > > Regards, > > Hans I'm concerned about this mostly because it goes through the USB stack. USB hardware seems to be particularly bad at hardware power management based on the archives of linux-usb. I don't have a good alternative though so I'm okay with it going in as long as we are prepared for a possible influx of bug reports. Or maybe I'll be wrong and all hardware will just magically work correctly.