Created attachment 90461 [details] dmesg on thinkpad t430s Hello! Users of different ThinkPads with various distributions reported, that they got "choppy" sound output after approximately two suspend and resume cycles. In case of mplayer (virtual terminal) and totem (Gnome-Shell) the sound and video gets choppy, it jumping over three or five seconds. Within ioquake3 the OpenGL seems to run normally, but audio output gets choppy too. See more here: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1088957?comments=all https://bbs.archlinux.org/viewtopic.php?pid=1211774 http://forums.gentoo.org/viewtopic-t-944996-highlight-disabling+lpib+delay+counting.html Sometimes repeated suspend/resumes resolved that temporarily (systemctl suspend or pm-suspend). Thanks :-)
Created attachment 90471 [details] dmesg of thinkpad t430s with vanilla kernel 3.7.1
Is this a regression on 3.7? If yes, try to pass power_save_controller=0 option to snd-hda-intel module. This hits weird issues. If it happens with older kernels, the problem is rather another part, e.g. the accuracy of position reporting. Try a different value for position_fix option of snd-hda-intel module.
Yes. It is a regression on 3.7. I don't tested power_save_controller=0 till now, but I will do. On the launchpad is reported that power_save_controller=0 works, also this commit is mentioned: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=44728e97c35ef31d649dafbbada665e37176f5da
snd-hda-intel.power_save_controller=0 works! Now I will test the commit from above.
I decided to upgrade from Kernel 3.7.1 to 3.7.2 and then apply the patch from above. Sadly I'm now not able to reproduce the bug now. Well, no really sadly ;-) Is that maybe related to this commit from Kernel 3.7.2? commit eeada90a5340368310a59c4b620982055fb022f0 Author: Takashi Iwai <tiwai@suse.de> Date: Wed Dec 12 11:50:12 2012 +0100 ALSA: hda - Move runtime PM check to runtime_idle callback commit 6eb827d23577a4efec2b10a9c4cc9ded268a1d1c upstream. The runtime_idle callback is the right place to check the suspend capability, but currently we do it wrongly in the runtime_suspend callback. This leads to a kernel error message like: pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x50 [snd_hda_intel] returns -11 and the runtime PM core would even repeat the attempts. Reported-and-tested-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=44728e97c35ef31d649dafbbada665e37176f5da To clarify this. I didn't apply this patch to Kernel 3.7.2, because I didn't manged to reproduce the bug within a half hour of suspend/resume-cycles.
I've upgrade to kernel 3.8-rc3 (struggling with other bug) which includes the fix[1] from above. I can't reproduce the bug with this kernel. So it seems fixed (for me). Honesetly, I can't say what excat commit fixed it. Thank you [1]http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=44728e97c35ef31d649dafbbada665e37176f5da