Bug 1520902
Summary: | Improved Laptop Battery Life | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jan Kurik <jkurik> |
Component: | Changes Tracking | Assignee: | Hans de Goede <hdegoede> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 28 | CC: | hdegoede, jan.public, montvid |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | ChangeAcceptedF28, SystemWideChange | ||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-05-02 12:04:24 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jan Kurik
2017-12-05 12:41:37 UTC
On 2018-Feb-20, we have reached the Fedora 28 Change Checkpoint: Completion deadline (testable). At this point, all accepted changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be enabled at Change Completion deadline as well. Change tracking bug should be set to the MODIFIED state to indicate it achieved completeness. Incomplete and non testable Changes will be reported to FESCo for 2018-Feb-23 meeting. This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'. All 3 power-management improvements mentioned on the Changes page have been in the rawhide/F28 kernels for a while now, moving to MODIFIED. On 2018-Mar-08 we reached the "Change Checkpoint: 100% Code Complete Deadline" milestone for Fedora 28 release. At this point all the Changes not at least in "ON_QA" state should be brought to FESCo for review. Please update the state of this bug to "ON_QA" if it is already 100% completed. Please let me know in case you have any trouble with the implementation and the Change needs any help or review. Thanks, Jan Everything is in place, moving to ON_QA. There is a bug in fedora 28, centos 7 with echo '1' > '/sys/module/snd_hda_intel/parameters/power_save as the sound card turns off there is a click and static noise plays through the speakers annoyingly. To fix that one needs to turn power save off echo '0' > '/sys/module/snd_hda_intel/parameters/power_save. There is a better fix from openSUSE you could implement. How to disable this feature so it lasts after reboot? See here: Don't do powersave on intel sound, we get static noise https://blog.christophersmart.com/2016/05/08/automatic-power-saving-on-a-linux-laptop-with-powertop-and-systemd/comment-page-1/ The power-saving feature might cause audible click noises at each power-down/up depending on the device. Some of them might be solvable, but some are hard, I’m afraid. Some distros such as openSUSE enables the power-saving feature automatically when the power cable is unplugged. Thus, if you hear noises, suspect first the power-saving. See /sys/module/snd_hda_intel/parameters/power_save to check the current value. If it’s non-zero, the feature is turned on. https://01.org/linuxgraphics/gfx-docs/drm/sound/hd-audio/notes.html My sound card info: https://paste.gnome.org/p4whkj24b mst, There is a similar bug about Intel NUC sound issues here: https://bugzilla.kernel.org/show_bug.cgi?id=199607 Before submitting a patch upstream to disable hda power-save on your model NUC, can you first please try making sure that the "Loopback Mixing" mixer element is disabled? You can do this by running "alsamixer -c 1" or "alsamixer -c 0" but usually you want card 1 as card 0 is the HDMI audio support. Regards, Hans An easier way to do this: amixer -c1 set "Loopback Mixing" Disabled or: amixer -c0 set "Loopback Mixing" Disabled Hans, thank you for your reply, but as i provided some links above the issue with static sound with power save enabled is an old one (at least 2014-15 on various intel cards) as google can tell "intel hda static sound power save". "Loopback Mixing" is Disabled in Fedora 28 by default and the commands you provide do not fix the static sound. As I wrote before an Intel person told that openSUSE has a fix to enable power save only when a device is running on a battery. As my device is not on a battery power save on intel hda can be disabled. Can someone implement this logic in Fedora? Of course if someone can fix this static noise in intel hda driver they would be welcome. (In reply to mst from comment #9) > Hans, > > thank you for your reply, but as i provided some links above the issue with > static sound with power save enabled is an old one (at least 2014-15 on > various intel cards) as google can tell "intel hda static sound power save". > "Loopback Mixing" is Disabled in Fedora 28 by default and the commands you > provide do not fix the static sound. > > As I wrote before an Intel person told that openSUSE has a fix to enable > power save only when a device is running on a battery. As my device is not > on a battery power save on intel hda can be disabled. Can someone implement > this logic in Fedora? This is done through a bunch of bash-scripts and is not something which we want to duplicate in Fedora. Instead we are working with the upstream kernel developers to keep a blacklist of devices where the power_save option is causing problems. I'll send a patch upstream to add your model to the list. It would be nice if someone fixed this bug in the intel hda driver if possible as powersave helps the planet to use less resources. Or is this a hardware bug? (In reply to mst from comment #11) > It would be nice if someone fixed this bug in the intel hda driver if > possible as powersave helps the planet to use less resources. Or is this a > hardware bug? It is complicated, see bug 1525104 where we are trying to fix this differently for some models. Takashi Iwai, the upstream alsa / snd-hda maintainer may get back to you with similar questions to try and do a proper fix. The problem is each motherboard wires up the codec differently, so this needs to be fixed on a case by case basis, at least for those cases where we can figure out what the fix is. |