* 100.0% power usage of Device Audio codec (HDA) on wake
@ 2012-11-16 14:23 Tomas Pospisek
2012-11-16 16:04 ` Takashi Iwai
0 siblings, 1 reply; 15+ messages in thread
From: Tomas Pospisek @ 2012-11-16 14:23 UTC (permalink / raw)
To: Alsa-devel
Hello,
The kernel of the upcoming Debian release and some
recent kernels of Ubuntu seem to be suffering from HDA
running at full force upon wakeup and producing
a lot of heat (keeping the fan spinning loudly).
The bug tracking can be found here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560
is there anything known about this problem? What the root of
the problem is? How to solve it? Are there patches? Are there
kernels that have fixed the problem? Are there workarounds?
The problem seems to be impacting quite a few users.
*t
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: 100.0% power usage of Device Audio codec (HDA) on wake 2012-11-16 14:23 100.0% power usage of Device Audio codec (HDA) on wake Tomas Pospisek @ 2012-11-16 16:04 ` Takashi Iwai 2012-11-17 0:48 ` Tomas Pospisek 0 siblings, 1 reply; 15+ messages in thread From: Takashi Iwai @ 2012-11-16 16:04 UTC (permalink / raw) To: Tomas Pospisek; +Cc: Alsa-devel At Fri, 16 Nov 2012 15:23:06 +0100, Tomas Pospisek wrote: > > Hello, > > The kernel of the upcoming Debian release and some > recent kernels of Ubuntu seem to be suffering from HDA > running at full force upon wakeup and producing > a lot of heat (keeping the fan spinning loudly). What do you mean "wakeup"? Which kernel are you using? Which codec and HD-audio controller chips? Please elaborate a bit more instead of a bug track URL. This will save lots of time for other people. If it's really a CPU usage, try to run perf and check what is spinning around. thanks, Takashi > > The bug tracking can be found here: > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560 > > is there anything known about this problem? What the root of > the problem is? How to solve it? Are there patches? Are there > kernels that have fixed the problem? Are there workarounds? > > The problem seems to be impacting quite a few users. > *t > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 100.0% power usage of Device Audio codec (HDA) on wake 2012-11-16 16:04 ` Takashi Iwai @ 2012-11-17 0:48 ` Tomas Pospisek 2012-11-17 1:17 ` Tomas Pospisek 2012-11-17 10:53 ` Takashi Iwai 0 siblings, 2 replies; 15+ messages in thread From: Tomas Pospisek @ 2012-11-17 0:48 UTC (permalink / raw) To: Takashi Iwai; +Cc: Alsa-devel Hello, On Fri, 16 Nov 2012 17:04:03 +0100, Takashi Iwai <tiwai@suse.de> wrote: > At Fri, 16 Nov 2012 15:23:06 +0100, Tomas Pospisek wrote: >> >> The kernel of the upcoming Debian release and some >> recent kernels of Ubuntu seem to be suffering from HDA >> running at full force upon wakeup and producing >> a lot of heat (keeping the fan spinning loudly). > > What do you mean "wakeup"? Waking up from suspend to RAM. > Which kernel are you using? 3.2.0-4-amd64 from Debian wheezy: http://packages.debian.org/wheezy/linux-image-3.2.0-4-amd64 > Which codec and HD-audio controller chips? Wrt codec - I don't know. Before suspending I am not playing any sound. And the system (say the desktop system or the bell in a terminal) isn't producing any sound either. Powertop says "Audio codec hwC0D0: IDT". Other People in the launchpad bugtracker seem to be reporting either "hwC0D0: IDT", "hwC0D0: Conexant" or "hwC0D1: Conexant". https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560 Here's the chip: Audio: 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05) > Please elaborate a bit more instead of a bug track URL. This will save lots of time for other people. Powertop v2.0 shows: in the Overview tab: Usage Events/s Category Description 100.0% Device Audio codec hwC0D0: IDT in Tunable tab: Good Runtime PM for PCI Device Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller Top shows: top - 01:12:28 up 4 days, 4:10, 3 users, load average: 0.04, 0.14, 0.21 Tasks: 181 total, 2 running, 179 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.2 us, 0.3 sy, 0.0 ni, 99.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 4007896 total, 3773420 used, 234476 free, 266220 buffers KiB Swap: 8280060 total, 272 used, 8279788 free, 2096072 cached If I start alsamixer and press "F5" (nothing else!), the previous number in powertop will go down to: Usage Events/s Category Description 0.0% Audio codec hwC0D0: IDT after about 5 seconds. I have tried also tried the following workaround: echo 1 | sudo tee /sys/module/snd_hda_intel/parameters/power_save echo Y | sudo tee /sys/module/snd_hda_intel/parameters/power_save_controller mentioned in Ubuntu's Launchpad: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560/comments/37 but that had no visible impact. The bug is a regression, since I did not have the problem under the previous Ubuntu Precise installation. However I *think* I was running a non-standard kernel there (my HD crashed, so I can't verify this assertion). > If it's really a CPU usage, try to run perf and check what is spinning > around. I ran "perf top", but I can't find anything interesting there: Events: 8K cycles 15.69% libxul.so [.] 0x9c31ae 12.49% libmozjs.so.10d [.] 0xd4f72 7.38% [kernel] [k] intel_idle 3.15% powertop [.] 0x283ae 2.40% Xorg (deleted) [.] 0xc3894 2.26% libc-2.13.so [.] 0x786ea 1.41% libQtCore.so.4.8.2 [.] 0xbc8fb ... Thanks, *t >> The bug tracking can be found here: >> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560 >> >> is there anything known about this problem? What the root of >> the problem is? How to solve it? Are there patches? Are there >> kernels that have fixed the problem? Are there workarounds? >> >> The problem seems to be impacting quite a few users. >> *t >> _______________________________________________ >> Alsa-devel mailing list >> Alsa-devel@alsa-project.org >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 100.0% power usage of Device Audio codec (HDA) on wake 2012-11-17 0:48 ` Tomas Pospisek @ 2012-11-17 1:17 ` Tomas Pospisek 2012-11-17 10:53 ` Takashi Iwai 1 sibling, 0 replies; 15+ messages in thread From: Tomas Pospisek @ 2012-11-17 1:17 UTC (permalink / raw) To: Takashi Iwai; +Cc: Alsa-devel On Sat, 17 Nov 2012 01:48:47 +0100, Tomas Pospisek wrote: > On Fri, 16 Nov 2012, Takashi Iwai wrote: >> Which codec and HD-audio controller chips? [...] > > Powertop says "Audio codec hwC0D0: IDT". Other People in the launchpad > bugtracker seem to be reporting either "hwC0D0: IDT", "hwC0D0: Conexant" or > "hwC0D1: Conexant". > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560 > > Here's the chip: > > Audio: > 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset > Family High Definition Audio Controller (rev 05) People in this other bug thread seem to have other "codecs" and setups as well: 1. k: Ubuntu linux-image-3.0.0-12-generic 3.0.0-12.20 d: ? c: ? u: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560 2. k: ? d: ? c: hwC0D1: LSI, hwC0D0: Analog Devices u: https://bugs.launchpad.net/ubuntu/+source/powertop/+bug/536631/comments/3 3. k: ? d: ? c: hwC0D1: LSI u: https://bugs.launchpad.net/ubuntu/+source/powertop/+bug/536631/comments/4 4. k: d: c: hwC0D1: LSI u: https://bugs.launchpad.net/ubuntu/+source/powertop/+bug/536631/comments/5 5. k: ? d: ? c: hwC0D3: auto (Intel) u: https://bugs.launchpad.net/ubuntu/+source/powertop/+bug/536631/comments/6 6. k: ? d: ? c: hwC0D0: SigmaTel u: https://bugs.launchpad.net/ubuntu/+source/powertop/+bug/536631/comments/7 7. k: linux-image-3.0.0-12-generic 3.0.0-12.20, 3.1.0-* d: Intel [HDA Intel], device 0: CONEXANT Analog [CONEXANT Analog] c: hwC0D0: Conexant u: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560 8. k: ? d: ? c: hwC0D0: IDT u: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560/comments/34 9. k: 3.2.0-26-generic #41-Ubuntu d: Device: 6 Series/C200 Series Chipset Family High Definition Audio Controller [1c20] c: ? u: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560/comments/43 10. k: ? d: PCI Device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller, PCI Device: Advanced Micro Devices [AMD] nee ATI RV635 HDMI Audio [Radeon HD 3600 Series] c: ? u: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560/comments/44 11. k: linux-image-3.2.0-4-amd64 d: 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05) c: Audio codec hwC0D0: IDT u: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560/comments/45 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 100.0% power usage of Device Audio codec (HDA) on wake 2012-11-17 0:48 ` Tomas Pospisek 2012-11-17 1:17 ` Tomas Pospisek @ 2012-11-17 10:53 ` Takashi Iwai 2012-11-20 6:54 ` Tomas Pospisek 1 sibling, 1 reply; 15+ messages in thread From: Takashi Iwai @ 2012-11-17 10:53 UTC (permalink / raw) To: Tomas Pospisek; +Cc: Alsa-devel, David Henningsson At Sat, 17 Nov 2012 01:48:47 +0100, Tomas Pospisek wrote: > > Hello, > > On Fri, 16 Nov 2012 17:04:03 +0100, Takashi Iwai <tiwai@suse.de> wrote: > > At Fri, 16 Nov 2012 15:23:06 +0100, Tomas Pospisek wrote: > >> > >> The kernel of the upcoming Debian release and some > >> recent kernels of Ubuntu seem to be suffering from HDA > >> running at full force upon wakeup and producing > >> a lot of heat (keeping the fan spinning loudly). > > > > What do you mean "wakeup"? > > Waking up from suspend to RAM. And does the same issue occur on hibernation, too? Basically both S2RAM and S2DISK use the same suspend/resume path regarding the sound driver, so the behavior should be consistent in both cases. > > Which kernel are you using? > > 3.2.0-4-amd64 from Debian wheezy: > http://packages.debian.org/wheezy/linux-image-3.2.0-4-amd64 OK, could you check the latest Linus tree (at least 3.7-rc5) whether the problem is still present? If it is, please keep using it for the further testing instead of 3.2.0. 3.2.0 is way too old to debug primarily. Also, try the latest alsa-lib from git tree, too. I thought David provides some packages built from the latest repo? > > Which codec and HD-audio controller chips? > > Wrt codec - I don't know. Before suspending I am not playing any sound. Well, I meant the audio codec chip, not the codec format :) But in the text below, you showed a conexant codec. Also, it's important to know what h/w vendor and model are. I guess it's a Lenovo machine? > And the > system (say the desktop system or the bell in a terminal) isn't producing > any sound either. OK. > Powertop says "Audio codec hwC0D0: IDT". Other People in the launchpad > bugtracker seem to be reporting either "hwC0D0: IDT", "hwC0D0: Conexant" or > "hwC0D1: Conexant". > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560 > > Here's the chip: > > Audio: > 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset > Family High Definition Audio Controller (rev 05) > > > Please elaborate a bit more instead of a bug track URL. This will save > lots of time for other people. > > Powertop v2.0 shows: > in the Overview tab: > Usage Events/s Category Description > 100.0% Device Audio codec hwC0D0: > IDT The usage in powertop doesn't mean what actually consuming the power in 100%. It's a completely different statistics from the CPU usage. It shows that the sound driver hasn't gone into the power-saving mode, a sort of partial suspend of the device. It can happen by various reasons: e.g. when your system doesn't set up the power_save option properly, or your mixer setup blocks it. First off, check the value in /sys/module/snd_hda_intel/parameters/power_save. If it shows 0, it means the power-saving feature is turned off. If it's a positive value, it means the power-saving may be turned on after the specified seconds after closing all usages of sound devices. Then check "fuser /dev/snd/pcm*" (run as root). If this shows something, the PCM device is still being used, so the power-saving can't be activated. If nothing is using the PCM device, but still no power-saving is activated, check the mixer setup. Check "amixer -c0 contents", and see whether any element with "Playback Switch" string is turned on. If anything else than "Speaker", "Headphone", "Master" (or sometimes "Front" or "Surround", too) is turned on, this is likely an analog loopback control, which constantly blocks the power-saving feature. Turn them off. If nothing still helps, give alsa-info.sh output at this state. > in Tunable tab: > Good Runtime PM for PCI Device Intel Corporation 6 Series/C200 > Series Chipset Family High Definition Audio Controller > > Top shows: > top - 01:12:28 up 4 days, 4:10, 3 users, load average: 0.04, 0.14, 0.21 > Tasks: 181 total, 2 running, 179 sleeping, 0 stopped, 0 zombie > %Cpu(s): 0.2 us, 0.3 sy, 0.0 ni, 99.5 id, 0.0 wa, 0.0 hi, 0.0 si, > 0.0 st > KiB Mem: 4007896 total, 3773420 used, 234476 free, 266220 buffers > KiB Swap: 8280060 total, 272 used, 8279788 free, 2096072 cached > > If I start alsamixer and press "F5" (nothing else!), the previous number > in powertop will go down to: > > Usage Events/s Category Description > 0.0% Audio codec hwC0D0: IDT > > after about 5 seconds. Again, this doesn't mean that your machine is consuming too much power. But please check the behavior at first with the latest 3.7-rc5 kernel. > I have tried also tried the following workaround: > > echo 1 | sudo tee /sys/module/snd_hda_intel/parameters/power_save > echo Y | sudo tee > /sys/module/snd_hda_intel/parameters/power_save_controller > > mentioned in Ubuntu's Launchpad: > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560/comments/37 > > but that had no visible impact. In the earlier kernel before 3.7, setting the power_save option alone doesn't trigger the power-saving mode. It's activated after the first use of the device. But this was improved in 3.7 kernel so that the power-saving is kicked off immediately. Takashi > The bug is a regression, since I did not have the problem under the > previous Ubuntu > Precise installation. However I *think* I was running a non-standard > kernel there (my HD crashed, so I can't verify this assertion). > > > If it's really a CPU usage, try to run perf and check what is spinning > > around. > > I ran "perf top", but I can't find anything interesting there: > > Events: 8K cycles > > 15.69% libxul.so [.] 0x9c31ae > 12.49% libmozjs.so.10d [.] 0xd4f72 > 7.38% [kernel] [k] intel_idle > 3.15% powertop [.] 0x283ae > 2.40% Xorg (deleted) [.] 0xc3894 > 2.26% libc-2.13.so [.] 0x786ea > 1.41% libQtCore.so.4.8.2 [.] 0xbc8fb > ... > > Thanks, > *t > > >> The bug tracking can be found here: > >> > >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560 > >> > >> is there anything known about this problem? What the root of > >> the problem is? How to solve it? Are there patches? Are there > >> kernels that have fixed the problem? Are there workarounds? > >> > >> The problem seems to be impacting quite a few users. > >> *t > >> _______________________________________________ > >> Alsa-devel mailing list > >> Alsa-devel@alsa-project.org > >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > >> > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 100.0% power usage of Device Audio codec (HDA) on wake 2012-11-17 10:53 ` Takashi Iwai @ 2012-11-20 6:54 ` Tomas Pospisek 2012-11-20 7:16 ` Takashi Iwai 2012-11-20 8:07 ` David Henningsson 0 siblings, 2 replies; 15+ messages in thread From: Tomas Pospisek @ 2012-11-20 6:54 UTC (permalink / raw) To: Takashi Iwai; +Cc: Alsa-devel, David Henningsson On Sat, 17 Nov 2012 11:53:49 +0100, Takashi Iwai wrote: > At Sat, 17 Nov 2012 01:48:47 +0100, Tomas Pospisek wrote: > >> On Fri, 16 Nov 2012 17:04:03 +0100, Takashi Iwai wrote: >> > At Fri, 16 Nov 2012 15:23:06 +0100, Tomas Pospisek wrote: >> >> >> >> The kernel of the upcoming Debian release and some >> >> recent kernels of Ubuntu seem to be suffering from HDA >> >> running at full force upon wakeup and producing >> >> a lot of heat (keeping the fan spinning loudly). >> > >> > What do you mean "wakeup"? >> >> Waking up from suspend to RAM. > > And does the same issue occur on hibernation, too? > Basically both S2RAM and S2DISK use the same suspend/resume path > regarding the sound driver, so the behavior should be consistent in > both cases. s2disk doesn't work here / isn't configured properly so I can't tell ad hoc. >> > Which kernel are you using? >> >> 3.2.0-4-amd64 from Debian wheezy: >> http://packages.debian.org/wheezy/linux-image-3.2.0-4-amd64 > > OK, could you check the latest Linus tree (at least 3.7-rc5) whether > the problem is still present? If it is, please keep using it for the > further testing instead of 3.2.0. 3.2.0 is way too old to debug > primarily. I'm running 3.7.0-rc6 now, with configuration from the "original" Debian kernel, make oldconfig and all choices to default. > Also, try the latest alsa-lib from git tree, too. I thought David > provides some packages built from the latest repo? I've found this repository by David: https://launchpad.net/~diwic/+archive/dkms however it seems to be deprecated and points to this: https://code.launchpad.net/~ubuntu-audio-dev/+archive/alsa-dailyvvv which however only contains "dkms-hda" packages. I'm not sure what those packages contain, or rather whether they contain the latest alsa and utils. It seems that they "only" contain an out of tree hda build, but I'm not sure. I'll try to compile latest alsa "the Debian way" and see if that changes anything. >> > Which codec and HD-audio controller chips? >> >> Wrt codec - I don't know. Before suspending I am not playing any sound. > > Well, I meant the audio codec chip, not the codec format :) > But in the text below, you showed a conexant codec. > > Also, it's important to know what h/w vendor and model are. > I guess it's a Lenovo machine? It's not Conexant. It's: 100.0% Device Audio codec hwC0D0: IDT 100.0% Device Audio codec hwC0D3: Intel Note that with Debian's 3.2.0-4-amd64 kernel only the IDT codec would show up on the top of powertop's list. Now there's the Intel codec as well. >> And the >> system (say the desktop system or the bell in a terminal) isn't producing >> any sound either. > > OK. > >> Powertop says "Audio codec hwC0D0: IDT". Other People in the launchpad >> bugtracker seem to be reporting either "hwC0D0: IDT", "hwC0D0: Conexant" >> or >> "hwC0D1: Conexant". >> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560 >> >> Here's the chip: >> >> Audio: >> 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset >> Family High Definition Audio Controller (rev 05) >> >> > Please elaborate a bit more instead of a bug track URL. This will >> > save lots of time for other people. >> >> Powertop v2.0 shows: >> in the Overview tab: >> Usage Events/s Category Description >> 100.0% Device Audio codec >> hwC0D0: >> IDT > > The usage in powertop doesn't mean what actually consuming the power > in 100%. It's a completely different statistics from the CPU usage. > > It shows that the sound driver hasn't gone into the power-saving > mode, a sort of partial suspend of the device. It can happen by > various reasons: e.g. when your system doesn't set up the power_save > option properly, or your mixer setup blocks it. > > First off, check the value in > /sys/module/snd_hda_intel/parameters/power_save. If it shows 0, it > means the power-saving feature is turned off. If it's a positive > value, it means the power-saving may be turned on after the specified > seconds after closing all usages of sound devices. Upon boot the value is 0. I can set it to 1 and it stays 1 while running, however if I suspend to ram and resume, the value gets reset to 0 again. > Then check "fuser /dev/snd/pcm*" (run as root). If this shows > something, the PCM device is still being used, so the power-saving > can't be activated. It doesn't show anything. > If nothing is using the PCM device, but still no power-saving is > activated, check the mixer setup. Check "amixer -c0 contents", and > see whether any element with "Playback Switch" string is turned on. > If anything else than "Speaker", "Headphone", "Master" (or sometimes > "Front" or "Surround", too) is turned on, this is likely an analog > loopback control, which constantly blocks the power-saving feature. > Turn them off. Here's all instances of "Playback Switch": numid=13,iface=MIXER,name='Master Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=2,iface=MIXER,name='Front Playback Switch' ; type=BOOLEAN,access=rw------,values=2 : values=on,on numid=4,iface=MIXER,name='Surround Playback Switch' ; type=BOOLEAN,access=rw------,values=2 : values=on,on numid=25,iface=MIXER,name='IEC958 Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=6,iface=MIXER,name='Beep Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=off > If nothing still helps, give alsa-info.sh output at this state. http://www.alsa-project.org/db/?f=54ea874f43f12c1572aff3ee3113dc4b0ad0b398 Thanks, *t >> in Tunable tab: >> Good Runtime PM for PCI Device Intel Corporation 6 >> Series/C200 >> Series Chipset Family High Definition Audio Controller >> >> Top shows: >> top - 01:12:28 up 4 days, 4:10, 3 users, load average: 0.04, 0.14, >> 0.21 >> Tasks: 181 total, 2 running, 179 sleeping, 0 stopped, 0 zombie >> %Cpu(s): 0.2 us, 0.3 sy, 0.0 ni, 99.5 id, 0.0 wa, 0.0 hi, 0.0 si, >> 0.0 st >> KiB Mem: 4007896 total, 3773420 used, 234476 free, 266220 buffers >> KiB Swap: 8280060 total, 272 used, 8279788 free, 2096072 cached >> >> If I start alsamixer and press "F5" (nothing else!), the previous number >> in powertop will go down to: >> >> Usage Events/s Category Description >> 0.0% Audio codec hwC0D0: IDT >> >> after about 5 seconds. > > Again, this doesn't mean that your machine is consuming too much > power. But please check the behavior at first with the latest 3.7-rc5 > kernel. > >> I have tried also tried the following workaround: >> >> echo 1 | sudo tee /sys/module/snd_hda_intel/parameters/power_save >> echo Y | sudo tee >> /sys/module/snd_hda_intel/parameters/power_save_controller >> >> mentioned in Ubuntu's Launchpad: >> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560/comments/37 >> >> but that had no visible impact. > > In the earlier kernel before 3.7, setting the power_save option alone > doesn't trigger the power-saving mode. It's activated after the first > use of the device. But this was improved in 3.7 kernel so that the > power-saving is kicked off immediately. > > > Takashi > >> The bug is a regression, since I did not have the problem under the >> previous Ubuntu >> Precise installation. However I *think* I was running a non-standard >> kernel there (my HD crashed, so I can't verify this assertion). >> >> > If it's really a CPU usage, try to run perf and check what is spinning >> > around. >> >> I ran "perf top", but I can't find anything interesting there: >> >> Events: 8K cycles >> >> 15.69% libxul.so [.] 0x9c31ae >> 12.49% libmozjs.so.10d [.] 0xd4f72 >> 7.38% [kernel] [k] intel_idle >> 3.15% powertop [.] 0x283ae >> 2.40% Xorg (deleted) [.] 0xc3894 >> 2.26% libc-2.13.so [.] 0x786ea >> 1.41% libQtCore.so.4.8.2 [.] 0xbc8fb >> ... >> >> Thanks, >> *t >> >> >> The bug tracking can be found here: >> >> >> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560 >> >> >> >> is there anything known about this problem? What the root of >> >> the problem is? How to solve it? Are there patches? Are there >> >> kernels that have fixed the problem? Are there workarounds? >> >> >> >> The problem seems to be impacting quite a few users. >> >> *t >> >> _______________________________________________ >> >> Alsa-devel mailing list >> >> Alsa-devel@alsa-project.org >> >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >> >> >> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 100.0% power usage of Device Audio codec (HDA) on wake 2012-11-20 6:54 ` Tomas Pospisek @ 2012-11-20 7:16 ` Takashi Iwai 2012-11-21 15:12 ` Tomas Pospisek 2012-11-20 8:07 ` David Henningsson 1 sibling, 1 reply; 15+ messages in thread From: Takashi Iwai @ 2012-11-20 7:16 UTC (permalink / raw) To: Tomas Pospisek; +Cc: Alsa-devel, David Henningsson At Tue, 20 Nov 2012 07:54:10 +0100, Tomas Pospisek wrote: > > On Sat, 17 Nov 2012 11:53:49 +0100, Takashi Iwai wrote: > > At Sat, 17 Nov 2012 01:48:47 +0100, Tomas Pospisek wrote: > > > >> On Fri, 16 Nov 2012 17:04:03 +0100, Takashi Iwai wrote: > >> > At Fri, 16 Nov 2012 15:23:06 +0100, Tomas Pospisek wrote: > >> >> > >> >> The kernel of the upcoming Debian release and some > >> >> recent kernels of Ubuntu seem to be suffering from HDA > >> >> running at full force upon wakeup and producing > >> >> a lot of heat (keeping the fan spinning loudly). > >> > > >> > What do you mean "wakeup"? > >> > >> Waking up from suspend to RAM. > > > > And does the same issue occur on hibernation, too? > > Basically both S2RAM and S2DISK use the same suspend/resume path > > regarding the sound driver, so the behavior should be consistent in > > both cases. > > s2disk doesn't work here / isn't configured properly so I can't tell > ad hoc. > > >> > Which kernel are you using? > >> > >> 3.2.0-4-amd64 from Debian wheezy: > >> http://packages.debian.org/wheezy/linux-image-3.2.0-4-amd64 > > > > OK, could you check the latest Linus tree (at least 3.7-rc5) whether > > the problem is still present? If it is, please keep using it for the > > further testing instead of 3.2.0. 3.2.0 is way too old to debug > > primarily. > > I'm running 3.7.0-rc6 now, with configuration from the "original" Debian > kernel, make oldconfig and all choices to default. > > > Also, try the latest alsa-lib from git tree, too. I thought David > > provides some packages built from the latest repo? > > I've found this repository by David: > > https://launchpad.net/~diwic/+archive/dkms > > however it seems to be deprecated and points to this: > > https://code.launchpad.net/~ubuntu-audio-dev/+archive/alsa-dailyvvv > > which however only contains "dkms-hda" packages. I'm not sure what > those packages contain, or rather whether they contain the latest alsa > and utils. It seems that they "only" contain an out of tree hda > build, but I'm not sure. > > I'll try to compile latest alsa "the Debian way" and see if that changes > anything. > > >> > Which codec and HD-audio controller chips? > >> > >> Wrt codec - I don't know. Before suspending I am not playing any sound. > > > > Well, I meant the audio codec chip, not the codec format :) > > But in the text below, you showed a conexant codec. > > > > Also, it's important to know what h/w vendor and model are. > > I guess it's a Lenovo machine? > > It's not Conexant. It's: > > 100.0% Device Audio codec hwC0D0: > IDT > 100.0% Device Audio codec hwC0D3: > Intel > > Note that with Debian's 3.2.0-4-amd64 kernel only the IDT codec would show > up > on the top of powertop's list. Now there's the Intel codec as well. OK, I've read a different line for other people's machine, then. (BTW, you can just check /proc/asound/card0/codec#0 and codec#3 files for more detailed information about the codec. powertop gives only digests.) > >> And the > >> system (say the desktop system or the bell in a terminal) isn't > producing > >> any sound either. > > > > OK. > > > >> Powertop says "Audio codec hwC0D0: IDT". Other People in the launchpad > >> bugtracker seem to be reporting either "hwC0D0: IDT", "hwC0D0: > Conexant" > >> or > >> "hwC0D1: Conexant". > >> > >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560 > >> > >> Here's the chip: > >> > >> Audio: > >> 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset > >> Family High Definition Audio Controller (rev 05) > >> > >> > Please elaborate a bit more instead of a bug track URL. This will > >> > save lots of time for other people. > >> > >> Powertop v2.0 shows: > >> in the Overview tab: > >> Usage Events/s Category Description > >> 100.0% Device Audio codec > >> hwC0D0: > >> IDT > > > > The usage in powertop doesn't mean what actually consuming the power > > in 100%. It's a completely different statistics from the CPU usage. > > > > It shows that the sound driver hasn't gone into the power-saving > > mode, a sort of partial suspend of the device. It can happen by > > various reasons: e.g. when your system doesn't set up the power_save > > option properly, or your mixer setup blocks it. > > > > First off, check the value in > > /sys/module/snd_hda_intel/parameters/power_save. If it shows 0, it > > means the power-saving feature is turned off. If it's a positive > > value, it means the power-saving may be turned on after the specified > > seconds after closing all usages of sound devices. > > Upon boot the value is 0. I can set it to 1 and it stays 1 while running, > however if I suspend to ram and resume, the value gets reset to 0 again. This is the system setup issue. It has nothing to do with the driver itself. So, what is the *real* problem with it? Did you measure any real power consumption with it? If the usages is turned off after playing something, it is the feature in your kernel version. As mentioned, power_save option itself didn't trigger the power-save mode but it's activated only after closing a device. This was improved with 3.7, so check with the 3.7 kernel. thanks, Takashi ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 100.0% power usage of Device Audio codec (HDA) on wake 2012-11-20 7:16 ` Takashi Iwai @ 2012-11-21 15:12 ` Tomas Pospisek 0 siblings, 0 replies; 15+ messages in thread From: Tomas Pospisek @ 2012-11-21 15:12 UTC (permalink / raw) To: Takashi Iwai; +Cc: Alsa-devel, David Henningsson On Tue, 20 Nov 2012 08:16:49 +0100, Takashi Iwai wrote: > At Tue, 20 Nov 2012 07:54:10 +0100, Tomas Pospisek wrote: >> >> On Sat, 17 Nov 2012 11:53:49 +0100, Takashi Iwai wrote: >> > At Sat, 17 Nov 2012 01:48:47 +0100, Tomas Pospisek wrote: >> > >> >> On Fri, 16 Nov 2012 17:04:03 +0100, Takashi Iwai wrote: >> >> > At Fri, 16 Nov 2012 15:23:06 +0100, Tomas Pospisek wrote: >> >> >> >> >> >> The kernel of the upcoming Debian release and some >> >> >> recent kernels of Ubuntu seem to be suffering from HDA >> >> >> running at full force upon wakeup and producing >> >> >> a lot of heat (keeping the fan spinning loudly). >> >> > >> >> > What do you mean "wakeup"? >> >> >> >> Waking up from suspend to RAM. >> > >> > And does the same issue occur on hibernation, too? >> > Basically both S2RAM and S2DISK use the same suspend/resume path >> > regarding the sound driver, so the behavior should be consistent in >> > both cases. >> >> s2disk doesn't work here / isn't configured properly so I can't tell >> ad hoc. >> >> >> > Which kernel are you using? >> >> >> >> 3.2.0-4-amd64 from Debian wheezy: >> >> http://packages.debian.org/wheezy/linux-image-3.2.0-4-amd64 >> > >> > OK, could you check the latest Linus tree (at least 3.7-rc5) whether >> > the problem is still present? If it is, please keep using it for the >> > further testing instead of 3.2.0. 3.2.0 is way too old to debug >> > primarily. >> >> I'm running 3.7.0-rc6 now, with configuration from the "original" Debian >> kernel, make oldconfig and all choices to default. >> >> > Also, try the latest alsa-lib from git tree, too. I thought David >> > provides some packages built from the latest repo? Since changing the kernel from 3.2.0-4-amd64 to upsteam 3.7.0-rc6 fixed the excessive heat production, I'm concluding that the problem is not with alsa-lib. >> >> > Which codec and HD-audio controller chips? >> >> >> >> Wrt codec - I don't know. Before suspending I am not playing any >> >> sound. >> > >> > Well, I meant the audio codec chip, not the codec format :) >> > But in the text below, you showed a conexant codec. >> > >> > Also, it's important to know what h/w vendor and model are. >> > I guess it's a Lenovo machine? >> >> It's not Conexant. It's: >> >> 100.0% Device Audio codec hwC0D0: IDT >> 100.0% Device Audio codec hwC0D3: Intel >> >> Note that with Debian's 3.2.0-4-amd64 kernel only the IDT codec would >> show up on the top of powertop's list. Now there's the Intel codec as well. > > OK, I've read a different line for other people's machine, then. > > (BTW, you can just check /proc/asound/card0/codec#0 and codec#3 files > for more detailed information about the codec. powertop gives only > digests.) Thanks, it's giving me much more information that I can make sense of :-) >> >> And the >> >> system (say the desktop system or the bell in a terminal) isn't >> producing >> >> any sound either. >> > >> > OK. >> > >> >> Powertop says "Audio codec hwC0D0: IDT". Other People in the launchpad >> >> bugtracker seem to be reporting either "hwC0D0: IDT", "hwC0D0: >> Conexant" >> >> or >> >> "hwC0D1: Conexant". >> >> >> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560 >> >> >> >> Here's the chip: >> >> >> >> Audio: >> >> 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset >> >> Family High Definition Audio Controller (rev 05) >> >> >> >> > Please elaborate a bit more instead of a bug track URL. This will >> >> > save lots of time for other people. >> >> >> >> Powertop v2.0 shows: >> >> in the Overview tab: >> >> Usage Events/s Category Description >> >> 100.0% Device Audio codec hwC0D0: IDT >> > >> > The usage in powertop doesn't mean what actually consuming the power >> > in 100%. It's a completely different statistics from the CPU usage. >> > >> > It shows that the sound driver hasn't gone into the power-saving >> > mode, a sort of partial suspend of the device. It can happen by >> > various reasons: e.g. when your system doesn't set up the power_save >> > option properly, or your mixer setup blocks it. >> > >> > First off, check the value in >> > /sys/module/snd_hda_intel/parameters/power_save. If it shows 0, it >> > means the power-saving feature is turned off. If it's a positive >> > value, it means the power-saving may be turned on after the specified >> > seconds after closing all usages of sound devices. >> >> Upon boot the value is 0. I can set it to 1 and it stays 1 while running, >> however if I suspend to ram and resume, the value gets reset to 0 again. > > This is the system setup issue. It has nothing to do with the driver > itself. > > So, what is the *real* problem with it? Did you measure any real > power consumption with it? I don't know what is causing the excessive heat. I just know that when the laptop wakes from suspend to ram under the 3.2.0-4-amd64 kernel it starts blowing hot air immediately. I start powertop and see "100% Audio codec hwC0D0: IDT" on top of the "Overview" list. I start alsamixer, press F5, I hear a slight "click" (as in speakers were dis/connected), "hwC0D0: IDT" drops to 0% and after a minute or so the laptop stops ventilating. The trail that lead me to this conclusion So my conclusion was that probably the production of heat and the audio system were connected. My conclusion might very well be wrong. The trail that lead me to this conclusion passed through this comment here: https://bugs.launchpad.net/ubuntu/+source/powertop/+bug/536631/comments/13 That person had to "mess with alsamixer settings" specifically with "Mic feedthrough to Main". It's noteworthy that for most people: https://bugs.launchpad.net/ubuntu/+source/powertop/+bug/536631 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560 setting triggering the relevant system config parameters as in: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560/comments/37 that is setting /sys/module/snd_hda_intel/parameters/power_save{_controller} resolved the problem. Not for me however. > If the usages is turned off after playing something, it is the feature > in your kernel version. As mentioned, power_save option itself didn't > trigger the power-save mode but it's activated only after closing a > device. This was improved with 3.7, so check with the 3.7 kernel. As I wrote, I _am_ using 3.7-rc6, and if I: echo 1 > /sys/module/snd_hda_intel/parameters/power_save it will stay 1, but after wake from suspend to RAM it will be 0 again. *t ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 100.0% power usage of Device Audio codec (HDA) on wake 2012-11-20 6:54 ` Tomas Pospisek 2012-11-20 7:16 ` Takashi Iwai @ 2012-11-20 8:07 ` David Henningsson 2012-11-20 8:32 ` Takashi Iwai 2012-11-21 14:44 ` Tomas Pospisek 1 sibling, 2 replies; 15+ messages in thread From: David Henningsson @ 2012-11-20 8:07 UTC (permalink / raw) To: Tomas Pospisek; +Cc: Takashi Iwai, Alsa-devel On 11/20/2012 07:54 AM, Tomas Pospisek wrote: > On Sat, 17 Nov 2012 11:53:49 +0100, Takashi Iwai wrote: >> At Sat, 17 Nov 2012 01:48:47 +0100, Tomas Pospisek wrote: >> >>> On Fri, 16 Nov 2012 17:04:03 +0100, Takashi Iwai wrote: >>>> At Fri, 16 Nov 2012 15:23:06 +0100, Tomas Pospisek wrote: >>>>> >>>>> The kernel of the upcoming Debian release and some >>>>> recent kernels of Ubuntu seem to be suffering from HDA >>>>> running at full force upon wakeup and producing >>>>> a lot of heat (keeping the fan spinning loudly). >>>> >>>> What do you mean "wakeup"? >>> >>> Waking up from suspend to RAM. >> >> And does the same issue occur on hibernation, too? >> Basically both S2RAM and S2DISK use the same suspend/resume path >> regarding the sound driver, so the behavior should be consistent in >> both cases. > > s2disk doesn't work here / isn't configured properly so I can't tell > ad hoc. > >>>> Which kernel are you using? >>> >>> 3.2.0-4-amd64 from Debian wheezy: >>> http://packages.debian.org/wheezy/linux-image-3.2.0-4-amd64 >> >> OK, could you check the latest Linus tree (at least 3.7-rc5) whether >> the problem is still present? If it is, please keep using it for the >> further testing instead of 3.2.0. 3.2.0 is way too old to debug >> primarily. > > I'm running 3.7.0-rc6 now, with configuration from the "original" Debian > kernel, make oldconfig and all choices to default. The Ubuntu kernel team does mainline builds - https://wiki.ubuntu.com/Kernel/MainlineBuilds - which provide the latest upstream kernels. >> Also, try the latest alsa-lib from git tree, too. I thought David >> provides some packages built from the latest repo? > > I've found this repository by David: > > https://launchpad.net/~diwic/+archive/dkms > > however it seems to be deprecated and points to this: > > https://code.launchpad.net/~ubuntu-audio-dev/+archive/alsa-dailyvvv > > which however only contains "dkms-hda" packages. I'm not sure what > those packages contain, or rather whether they contain the latest alsa > and utils. It seems that they "only" contain an out of tree hda > build, but I'm not sure. > > I'll try to compile latest alsa "the Debian way" and see if that changes > anything. The thing I currently compile and maintain are DKMS packages for the HDA driver. We're never daily built alsa-lib, and the full sound tree builds have been discontinued since almost everyone used the DKMS packages (or the full mainline kernel). See https://wiki.ubuntu.com/Audio/UpgradingAlsa/DKMS for how to install them. I haven't followed this thread in total, and I hadn't seen the bug report before it was reported here, but I find it a little strange that a headphone amp, even at full power, would give out so much heat that your fan would spin up (I mean, this doesn't happen when you normally listen to music through headphones, right?). I could be wrong, but AFAIK, a codec chip just doesn't cause that much heat in /any/ situation. So it's probably something else? It does put another question - from where does powertop get its values, and do we have to do anything on our side to make sure / aid them being correct? -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 100.0% power usage of Device Audio codec (HDA) on wake 2012-11-20 8:07 ` David Henningsson @ 2012-11-20 8:32 ` Takashi Iwai 2012-11-20 8:56 ` David Henningsson 2012-11-21 14:44 ` Tomas Pospisek 1 sibling, 1 reply; 15+ messages in thread From: Takashi Iwai @ 2012-11-20 8:32 UTC (permalink / raw) To: David Henningsson; +Cc: Alsa-devel, Tomas Pospisek At Tue, 20 Nov 2012 09:07:21 +0100, David Henningsson wrote: > > It does put another question - from where does powertop get its values, > and do we have to do anything on our side to make sure / aid them being > correct? powertop checks /sys/class/sound/hwC*D*/power_{off|on}_acct files. They contain the time (in ms) how long the codec is in the power-save mode. Takashi ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 100.0% power usage of Device Audio codec (HDA) on wake 2012-11-20 8:32 ` Takashi Iwai @ 2012-11-20 8:56 ` David Henningsson 2012-11-20 9:01 ` Takashi Iwai 0 siblings, 1 reply; 15+ messages in thread From: David Henningsson @ 2012-11-20 8:56 UTC (permalink / raw) To: Takashi Iwai; +Cc: Alsa-devel, Tomas Pospisek On 11/20/2012 09:32 AM, Takashi Iwai wrote: > At Tue, 20 Nov 2012 09:07:21 +0100, > David Henningsson wrote: >> >> It does put another question - from where does powertop get its values, >> and do we have to do anything on our side to make sure / aid them being >> correct? > > powertop checks /sys/class/sound/hwC*D*/power_{off|on}_acct files. > They contain the time (in ms) how long the codec is in the power-save > mode. Thanks. But I have also recently seen a computer where powertop showed a Watt number, essentially saying that the codec consumed 1.4 Watts or so (I don't remember the exact number). Have you seen that too? -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 100.0% power usage of Device Audio codec (HDA) on wake 2012-11-20 8:56 ` David Henningsson @ 2012-11-20 9:01 ` Takashi Iwai 2012-11-21 14:15 ` Tomas Pospisek 0 siblings, 1 reply; 15+ messages in thread From: Takashi Iwai @ 2012-11-20 9:01 UTC (permalink / raw) To: David Henningsson; +Cc: Alsa-devel, Tomas Pospisek At Tue, 20 Nov 2012 09:56:19 +0100, David Henningsson wrote: > > On 11/20/2012 09:32 AM, Takashi Iwai wrote: > > At Tue, 20 Nov 2012 09:07:21 +0100, > > David Henningsson wrote: > >> > >> It does put another question - from where does powertop get its values, > >> and do we have to do anything on our side to make sure / aid them being > >> correct? > > > > powertop checks /sys/class/sound/hwC*D*/power_{off|on}_acct files. > > They contain the time (in ms) how long the codec is in the power-save > > mode. > > Thanks. But I have also recently seen a computer where powertop showed a > Watt number, essentially saying that the codec consumed 1.4 Watts or so > (I don't remember the exact number). Have you seen that too? When 1.4W is constantly consumed even without PCM, it's a bit too high. But with PCM playback, about 1W usage can be measured normally, I guess. Takashi ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 100.0% power usage of Device Audio codec (HDA) on wake 2012-11-20 9:01 ` Takashi Iwai @ 2012-11-21 14:15 ` Tomas Pospisek 2012-11-21 14:26 ` Takashi Iwai 0 siblings, 1 reply; 15+ messages in thread From: Tomas Pospisek @ 2012-11-21 14:15 UTC (permalink / raw) To: Takashi Iwai; +Cc: Alsa-devel, David Henningsson On Tue, 20 Nov 2012 10:01:18 +0100, Takashi Iwai <tiwai@suse.de> wrote: > At Tue, 20 Nov 2012 09:56:19 +0100, > David Henningsson wrote: >> >> On 11/20/2012 09:32 AM, Takashi Iwai wrote: >> > At Tue, 20 Nov 2012 09:07:21 +0100, >> > David Henningsson wrote: >> >> >> >> It does put another question - from where does powertop get its >> >> values, >> >> and do we have to do anything on our side to make sure / aid them >> >> being >> >> correct? >> > >> > powertop checks /sys/class/sound/hwC*D*/power_{off|on}_acct files. >> > They contain the time (in ms) how long the codec is in the power-save >> > mode. >> >> Thanks. But I have also recently seen a computer where powertop showed a >> Watt number, essentially saying that the codec consumed 1.4 Watts or so >> (I don't remember the exact number). Have you seen that too? > > When 1.4W is constantly consumed even without PCM, it's a bit too > high. But with PCM playback, about 1W usage can be measured normally, > I guess. man powertop says: --calibrate runs powertop in calibration mode. When running on battery, powertop can track power consumption as well as system activity. When there are enough measurements, powertop can start to report power estimates. One can get more accurate estimates by using this option to enable a calibration cycle. This will cycle through various display levesl and USB device activities and workloads. So that's what powertop does I think: it estimates. *t ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 100.0% power usage of Device Audio codec (HDA) on wake 2012-11-21 14:15 ` Tomas Pospisek @ 2012-11-21 14:26 ` Takashi Iwai 0 siblings, 0 replies; 15+ messages in thread From: Takashi Iwai @ 2012-11-21 14:26 UTC (permalink / raw) To: Tomas Pospisek; +Cc: Alsa-devel, David Henningsson At Wed, 21 Nov 2012 15:15:09 +0100, Tomas Pospisek wrote: > > On Tue, 20 Nov 2012 10:01:18 +0100, Takashi Iwai <tiwai@suse.de> wrote: > > At Tue, 20 Nov 2012 09:56:19 +0100, > > David Henningsson wrote: > >> > >> On 11/20/2012 09:32 AM, Takashi Iwai wrote: > >> > At Tue, 20 Nov 2012 09:07:21 +0100, > >> > David Henningsson wrote: > >> >> > >> >> It does put another question - from where does powertop get its > >> >> values, > >> >> and do we have to do anything on our side to make sure / aid them > >> >> being > >> >> correct? > >> > > >> > powertop checks /sys/class/sound/hwC*D*/power_{off|on}_acct files. > >> > They contain the time (in ms) how long the codec is in the power-save > >> > mode. > >> > >> Thanks. But I have also recently seen a computer where powertop showed > a > >> Watt number, essentially saying that the codec consumed 1.4 Watts or so > > >> (I don't remember the exact number). Have you seen that too? > > > > When 1.4W is constantly consumed even without PCM, it's a bit too > > high. But with PCM playback, about 1W usage can be measured normally, > > I guess. > > man powertop says: > > --calibrate runs powertop in calibration mode. When running on battery, > powertop can track power consumption as well as system > activity. When there are enough measurements, powertop > can start to report power estimates. One can get more > accurate estimates by using this option to enable a > calibration cycle. This will cycle through various display > levesl and USB device activities and workloads. > > So that's what powertop does I think: it estimates. But 100% things from hwC0D0 has nothing to do with the real power usage. It's just the time of HD-audio power-saving mode on and off. Takashi ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: 100.0% power usage of Device Audio codec (HDA) on wake 2012-11-20 8:07 ` David Henningsson 2012-11-20 8:32 ` Takashi Iwai @ 2012-11-21 14:44 ` Tomas Pospisek 1 sibling, 0 replies; 15+ messages in thread From: Tomas Pospisek @ 2012-11-21 14:44 UTC (permalink / raw) To: David Henningsson; +Cc: Takashi Iwai, Alsa-devel On Tue, 20 Nov 2012 09:07:21 +0100, David Henningsson <david.henningsson@canonical.com> wrote: > On 11/20/2012 07:54 AM, Tomas Pospisek wrote: >> On Sat, 17 Nov 2012 11:53:49 +0100, Takashi Iwai wrote: >>> At Sat, 17 Nov 2012 01:48:47 +0100, Tomas Pospisek wrote: >>> >>>> On Fri, 16 Nov 2012 17:04:03 +0100, Takashi Iwai wrote: >>>>> At Fri, 16 Nov 2012 15:23:06 +0100, Tomas Pospisek wrote: >>>>>> >>>>>> The kernel of the upcoming Debian release and some >>>>>> recent kernels of Ubuntu seem to be suffering from HDA >>>>>> running at full force upon wakeup and producing >>>>>> a lot of heat (keeping the fan spinning loudly). >>>>> >>>>> What do you mean "wakeup"? >>>> >>>> Waking up from suspend to RAM. >>> >>> And does the same issue occur on hibernation, too? >>> Basically both S2RAM and S2DISK use the same suspend/resume path >>> regarding the sound driver, so the behavior should be consistent in >>> both cases. >> >> s2disk doesn't work here / isn't configured properly so I can't tell >> ad hoc. >> >>>>> Which kernel are you using? >>>> >>>> 3.2.0-4-amd64 from Debian wheezy: >>>> http://packages.debian.org/wheezy/linux-image-3.2.0-4-amd64 >>> >>> OK, could you check the latest Linus tree (at least 3.7-rc5) whether >>> the problem is still present? If it is, please keep using it for the >>> further testing instead of 3.2.0. 3.2.0 is way too old to debug >>> primarily. >> >> I'm running 3.7.0-rc6 now, with configuration from the "original" Debian >> kernel, make oldconfig and all choices to default. > > The Ubuntu kernel team does mainline builds - > https://wiki.ubuntu.com/Kernel/MainlineBuilds - which provide the latest > upstream kernels. > >>> Also, try the latest alsa-lib from git tree, too. I thought David >>> provides some packages built from the latest repo? >> >> I've found this repository by David: >> >> https://launchpad.net/~diwic/+archive/dkms >> >> however it seems to be deprecated and points to this: >> >> https://code.launchpad.net/~ubuntu-audio-dev/+archive/alsa-dailyvvv >> >> which however only contains "dkms-hda" packages. I'm not sure what >> those packages contain, or rather whether they contain the latest alsa >> and utils. It seems that they "only" contain an out of tree hda >> build, but I'm not sure. >> >> I'll try to compile latest alsa "the Debian way" and see if that changes >> anything. > > The thing I currently compile and maintain are DKMS packages for the HDA > driver. We're never daily built alsa-lib, and the full sound tree builds > have been discontinued since almost everyone used the DKMS packages (or > the full mainline kernel). See > https://wiki.ubuntu.com/Audio/UpgradingAlsa/DKMS for how to install them. Thanks for both of your pointers! > I haven't followed this thread in total, and I hadn't seen the bug > report before it was reported here, but I find it a little strange that > a headphone amp, even at full power, would give out so much heat that > your fan would spin up (I mean, this doesn't happen when you normally > listen to music through headphones, right?). Now that I'm running the 3.7.0-rc6 kernel my laptop is staying rather cool and the fan is mostly off. However with Debian's 3.2.0-4-amd64 kernel it's the contrary, the latop is blowin hot air. The laptop has got a discrete Radeon card, but that card is off and is not showing in powertop. And in powertop's CPU view, the "package" is being shown as being <4% in "Turbo" mode. With 3.7.0-rc6 it's never in "Turbo" mode. Also, with 3.7.0-rc6 after wake from suspend to RAM the Codecs show first on the top in powertops "Overview" but after a few minutes drop out of sight. They are still shown at 100% in powertop however they are shown to use 0mW. So back to your question "this doesn't happen when you normally listen to music through headphones, right?": what I'm doing on the laptop under the 3.2.0-4-amd64 kernel doesn't influence much the output of hot air. I notice however that when I wake up, the laptop starts blowing hot air immediately. And it doesn't stop until I go into alsamixer and press F5. I hear a slight click (as in speakers getting dis/connected) and then "Audio codec hwC0D0: IDT" drops to 0% and the laptop stops blowing. If you go to the original Ubuntu bugreport: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/877560 you'll notice that many users are reporting very similar problems there. > I could be wrong, but > AFAIK, a codec chip just doesn't cause that much heat in /any/ > situation. So it's probably something else? I don't understand why you are saying that it would be the headphones amplyfier. Is "IDT" the amplifier for the headphones only? I.e. not for the laptop's standard speakers? So now that with the 3.7.0-rc6 kernel my laptop runs cool again, I could stop at this point and go on with my own private ways. However it'd be nice if it'd be possible to find out what exactly was causing the problem in Debian's 3.2.0-4-amd64 kernel. It will be Debian's stable kernel for the next 3 years and some of the users will be swearing a lot due to the fan noise and the short battery life. Same for Ubuntu Precise's kernel it seems. Thanks, *t ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2012-11-21 15:12 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-11-16 14:23 100.0% power usage of Device Audio codec (HDA) on wake Tomas Pospisek 2012-11-16 16:04 ` Takashi Iwai 2012-11-17 0:48 ` Tomas Pospisek 2012-11-17 1:17 ` Tomas Pospisek 2012-11-17 10:53 ` Takashi Iwai 2012-11-20 6:54 ` Tomas Pospisek 2012-11-20 7:16 ` Takashi Iwai 2012-11-21 15:12 ` Tomas Pospisek 2012-11-20 8:07 ` David Henningsson 2012-11-20 8:32 ` Takashi Iwai 2012-11-20 8:56 ` David Henningsson 2012-11-20 9:01 ` Takashi Iwai 2012-11-21 14:15 ` Tomas Pospisek 2012-11-21 14:26 ` Takashi Iwai 2012-11-21 14:44 ` Tomas Pospisek
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.