I recently updated from the 4.9 kernel to 4.14 only to find my speakers have a constant buzzing sound. I've narrowed the problem down to the power_save parameter of the snd_hda_intel module. When enabled there is a constant buzz, but disabled (set to 0) it is silent.

I've attempted to set the value by using both a modprobe.d and a kernel parameter. The problem is, the value is being overwritten/set by something in my system.

Forcefully reloading the module (default is off) or writing 0 to /sys/module/snd_hda_intel/parameters/power_save will temporarily solve the problem, until a reboot or wake from suspend. I cannot determine what is enabling the power_save feature. I've even tried using inotifywait and lsof to find the culprit, with no results (doesn't seem to work across sleep/wake cycles).

This is a desktop PC, so no battery hence no AC vs BAT modes or anything like pm-util. I'm using a GNOME version of Manjaro, but I'm sure solutions for any platform may help. The audio is an onboard ALC887-VD chipset if that's any help.

Can anybody suggest where else I might look or what could be causing this?


I've noticed my distribution shipped with TLP (similar to pm-utils) and that on the 4.14 kernel TLP always starts up in battery mode. My PC doesn't have a battery but does have wireless peripherals. I think this may be a bug within TLP itself.

  • Gnome's power management subsystem may be doing this. Can you reproduce the problem with no user logged in? Dec 29, 2017 at 15:09
  • @Gilles, how would I test that. I use the Gnome Login Manager, so i presume booting until a login prompt will not suffice. Also, booting to the 4.9 kernel does not have this problem.
    – Twifty
    Dec 29, 2017 at 15:13
  • Boot to the login prompt, suspend, resume: do you get the buzz or not? Dec 29, 2017 at 15:16
  • @Gilles, I still get the buzz :/
    – Twifty
    Dec 29, 2017 at 15:28
  • 1
    @GAD3R The module's default value is 0, so forcefully reloading will fix the issue. The problem is that another process is setting power_save=1 after boot and resume.
    – Twifty
    Dec 30, 2017 at 1:01

2 Answers 2


Have you updated your initramfs file after changing /etc/modprobe.d/? It is possible that the sound driver modules are loaded early, and your modifications won't be available until the root filesystem is mounted - at which point it's too late as the modules have already been loaded from initramfs.

I'm not too familiar with Arch, but looks like mkinitcpio is the command you'll need for updating your initramfs file.

  • I have already tried using a kernel command line in my GRUB bootloader. Wouldn't that also set any options for modules within the initramfs?
    – Twifty
    Dec 29, 2017 at 15:09
  • The kernel only parses the boot options it has compiled-in drivers for; the rest will be transferred as environment variables to PID 1. If Arch has additional scripting that would read PID 1's environment in initramfs and use any applicable things as module parameters when loading modules, then maybe; otherwise no.
    – telcoM
    Dec 30, 2017 at 9:45

I’ve confirmed that TLP (version 1,0) is at fault here. It’s detecting the batteries of my two peripheral devices by scanning the contents of /sys/class/power_supply. Since it detects devices powered by battery and no devices powered by mains, it is incorrectly thinking the system is battery powered. The detection loop is here if anybody wants to look at this.

On kernel 4.9, my /sys/class/power_supply directory is empty, but on 4.14 it is populated with my Logitech wireless mouse and keyboard. I’m guessing many other TLP users, with wireless peripherals, may also be affected by this bug. Though, in most cases, many people may not even realize their desktop PC’s are running in battery mode.


The issue has been fixed in TLP 1.1 beta. It now ignores HID devices and the system correctly uses the AC mode.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.