Takashi Iwai wrote: > At Sun, 06 May 2012 12:32:14 +0400, > Konstantin Khlebnikov wrote: >> >> Konstantin Khlebnikov wrote: >>> Mainline commit 785f857d1cb0856b612b46a0545b74aa2596e44a >>> ("ALSA: hda - Set codec to D3 forcibly even if not used") >>> breaks sound for my notebook (thinkpad x220), >>> looks like codec cannot wake from power-save state after resume. >>> After reverting looks like all works fine. >>> >>> how to reproduce: >>> * unplug the power cord (to enable hda power safe mode) >>> * play something and stop >>> * wait until the background noise disappears (codec went into power-save mode) >>> * suspend >>> * resume >>> * play something again and hear the silence >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> Please read the FAQ at http://www.tux.org/lkml/ >> >> Bump > > It's a weekend, so don't expect quick responces from any normal person > :) Yeah, sorry. In this country a mess with holidays and weekends. > > Which 3.4-rc did you try? There was a known problem with this codec > regarding the power-up sequence, but this should have been fixed in > the very recent version. Bug still in latest v3.4-rc6. This is serious degradation since v3.3, so I hope it will be fixed before release. > > If the latest Linus tree still shows the problem, try sound git tree > master or for-next branch. > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git I don't see there anything related to this problem. Bug is still there. It's 100% reproductible and disappears after reverting that commit. Looks like driver missed one power-up cycle after system-resume, after second power-save down/up cycle all work fine. > > Then attach g output (run with --no-upload option) before > and after S3 (i.e. working and non-working states). see attachments (kernel is v3.4-rc6 with changes from your branch) start mplayer (work fine) alsa-info.sh -> alsa-info.before stop mplayer suspend resume start mplayer (doesn't work) alsa-info.sh -> alsa-info.after stop mplayer wait a second start mplayer (work fine) > > >> BTW, I don't see any locks around hda power-save code, for example hda_power_work() reads >> codec->power_on and codec->power_count without any locks. This seems racy. > > Yeah, we may add an extra spinlock. But it's not too critical for the > whole operation, so I didn't care much so far. At most, you'll miss one > power-save cycle. Maybe a good time to fix it now for 3.5. I'm afraid this code can easily miss one power-up cycle and stays in power-save mode. This can be unrelated to my problem, but from my point of view this is very careless. For example snd_hda_power_up() can easily race with hda_power_work(). > > > thanks, > > Takashi