Bug 42889
Summary: | Audio prevents CPU from entering sleep states on Thinkpad X201 | ||
---|---|---|---|
Product: | Drivers | Reporter: | Michael (michaelkiesenhofer) |
Component: | Sound(ALSA) | Assignee: | Jaroslav Kysela (perex) |
Status: | RESOLVED WILL_NOT_FIX | ||
Severity: | normal | CC: | ralf, tiwai |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.2 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
Powertop with music. Notice the 0% C3 and C6 in “Package”
Powertop while not playing any music. Everything’s fine. lspci, for completeness alsa-info.sh perf record -a -g sleep 10 while playing audio with mocp perf record -a -g sleep 10 while idling – just for comparison perf record with debug symbols for libasound |
Description
Michael
2012-03-08 13:36:09 UTC
Created attachment 72552 [details]
Powertop with music. Notice the 0% C3 and C6 in “Package”
Created attachment 72553 [details]
Powertop while not playing any music. Everything’s fine.
Don’t ask me why powertop does not display power consumption on my Notebook. And no, the AC is not connected.
Are you sure that you've tested with ALSA raw access? Usually when PulseAudio is installed, alsa-lib pulse plugin is also enabled so that all audio goes through PulseAudio even from ALSA-native apps unless a proper device option is specified. Try "aplay -Dplughw somefile.wav" to see whether it really happens the same problem with ALSA raw access. Created attachment 72554 [details]
lspci, for completeness
(In reply to comment #3) > Are you sure that you've tested with ALSA raw access? Usually when > PulseAudio > is installed, alsa-lib pulse plugin is also enabled so that all audio goes > through PulseAudio even from ALSA-native apps unless a proper device option > is > specified. > > Try "aplay -Dplughw somefile.wav" to see whether it really happens the same > problem with ALSA raw access. Yes. Just tried your command and it’s behaving just the same. Then try position_fix=1 or position_fix=2 option for snd-hda-intel module. Also, check whether model=auto option (again for snd-hda-intel) changes anything. In anyway, run alsa-info.sh with --no-upload option and attach the output to bugzilla. Created attachment 72558 [details]
alsa-info.sh
Comment on attachment 72558 [details]
alsa-info.sh
Tried all three parameters for snd_hda_intel … they unfortunatly didn’t change anything.
Then try bdl_pos_adj=0 option. Still 0% C3 or C6 state when playing sound with that aplay command. The module parameters are correctly applied, according to /sys/module/snd_hda_intel/parameters/. Well, how large buffer are you using? The max buffer size is limited in CONFIG_SND_HDA_PREALLOC_SIZE. As default, it's set relatively small. Set to 2048 or such would help much for power-saving. As mentioned in Kconfig help, it can be changed via proc file, too. Other than that, I have no idea. The driver itself is proven to be very power-aware. On an HP machine here, the power consumption is really small even during playback. I’ve allready played around with the buffer size. It has no effect on the sleep behaviour and very little effect on power consumption. Hi Takashi, I can confirm this bug. It is still present in recent kernels such as 3.2.30 and 3.4.10. On a Thinkpad X201s with the Conexant CX20585 codec power consumption increases by about 7 Watt (from 7 to 14(!) Watt) when playing some audio, no matter if pulseaudio is involved or not. This shortens the battery running time by 50%. On a Thinkpad X200s with Conexant CX20561 this problem does not exist. With the exactly same kernels the power just increases by about 1-2 Watt when playing mp3. Both tested on Ubuntu 12.04 and OpenSUSE 12.1/12.2 The be sure it is no hardware problem I tested the X201s with windows 7. No Problem there, power increase of ~1 Watt when playing a mp3. There are other users with X201 Thinkpads reporting the same problem. Not sure if it is a X201s only problem or all notebooks with CX20585 are affected. As Michael said, neither an increase of the buffer size nor playing with the module parameters changes the situation. Greetings, Ralf I booted with 'nohz=off' to test whether it is the cpu or the sound card using so much power when playing sound. With disabling dynamic ticks, the X201s uses ~ 16.5 Watt when idle. When playing audio it goes to ~ 17.5-18 Watt, a slight increase of less than 2 Watts. So it looks like the problem is indeed a result of cpu wake-ups caused by alsa. Since this bug reduces the battery running time by 50% and increases the temperature of the cpu I would be very, very happy if it could be fixed. What additional information do you need? Please let me know how I can help to track this down. OK, then it must be something in the driver spinning CPU. IIRC, there are two possible places where the things can go bad: 1. The workaround for position reporting 2. The unstable unsol events or other controller-codec mis-communication. The former should be disabled by passing bdl_pos_adj=0. But it seems not helping in this case. (And if the workaround was activated, you should have seen a kernel message.) For checking the latter, the easiest way would be enable tracing for hda_codec. A brief description is found in Documentation/alsa/HD-Audio.txt. I rechecked to be sure, bdl_pos_adj=0 does not help. But I found that setting position_fix=1 saves about 0.5-1 Watts. Nevertheless the overall power consumption of 6 Watts is still too much. Tracing the hda_codec does not show any unsol events or anything else that points to a mis-communication. Since the root of the high power consumption is the cpu leaving the deep package c-states on active audio I tested the acpi_idle driver instead of intel_idle. No luck, same results. May be Len Brown should have a look at this? Ralf If the codec communication looks OK and bdl_pos_adj doesn't change, there should be no wild things driver does. Did you already try to profile by perf? Maybe you can find something there if it's really any CPU task spinning. I can confirm Ralf’s findings. I was too shy to report them myself because I wasn’t sure if I’d done everything correct. Let me try this perf thing … Created attachment 84971 [details]
perf record -a -g sleep 10 while playing audio with mocp
Soooooo, I’ve done a perf record -a -g sleep 10. Unfortunately I don’t really know what to look for in perf report. Maybe someone else can take a look at my recorded file(s).
Created attachment 84981 [details]
perf record -a -g sleep 10 while idling – just for comparison
The record files are almost useless without symbols on your machine :) But at least we can see that the issue isn't in kernel but it's wasted in libasound.so.2. You can take a deeper look via perf report -i perf.data.music Created attachment 85281 [details]
perf record with debug symbols for libasound
Well, I guess that means we close the bug here and I have to go to the alsa guys (and girls)?
I’ve attached the perf record with debug symbols, maybe you can still give me a hint what’s going wrong.
Thank you for everything anyways!
Closed, as it's a user-space alsa-lib issue, if any. |