Latest working kernel version: Earliest failing kernel version: Distribution:ubuntu hardy Hardware Environment: ASUS P5LD2-VM => ICH7 + intel_hda audio ( realtec codec ALC882 ) Software Environment: Problem Description: No sound after resume. If i reload snd_hda_intel and suspend/resume agene sound will work. I disable any desktop enviropment to make clear there is no other script makeing this. 1. (sound working) lspci -vvxxxs 00:1b.0 > lspci1 2. echo mem > /sys/power/state 3. resume ( no sound ) and lspci -vvxxxs 00:1b.0 > lspci2 4. rmmod snd_hda_intel && modprobe snd_hda_intel ( sound working now ) 5. lspci -vvxxxs 00:1b.0 > lspci3 6. echo mem > /sys/power/state and resume ( sond working ) 7. lspci -vvxxxs 00:1b.0 > lspci4 diff lspci1 lspci2 29c29 < 40: 03 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 --- > 40: 01 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 betwene lspci2 , lscpi3 or lspci4 no difference.
Created attachment 15362 [details] lspci1 lspci1 before first suspend
Created attachment 15363 [details] lspci2-after-resume lspci2 after resume.
Created attachment 15364 [details] dmesg
I tested kernel 2.6.22 . Sound is working after resume. The difference: 2.6.22 use irq 20 for HDA Intel 2.6.24 use irq 19 both have after boot pci 0x41 = 0x03 and after resume 0x01
Will you please attach the output of acpidump? Please try the boot option of "acpi_new_pts_ordering" and see whether the problem still exists? Thanks.
Created attachment 15368 [details] acpidump
"acpi_new_pts_ordering" do not make any difference.
Ok. It seems like not acpi issue, it was brocken after some alsa commit: bisect/good bd45ac0c5daae35e7c71138172e63df5cf644cf6 bisect/bad 976cd62700ae378df330ec82112da3d17e33a0fe i didn't get to test more. It it bracke some dependency.
It is my first time i use git bisect, so i houp i did't any thing wrong. Here is result of my tests: git bisect good 8c427226ed549af67396794e86246bf2d361ff8f is first bad commit commit 8c427226ed549af67396794e86246bf2d361ff8f Author: Kailang Yang <kailang@realtek.com.tw> Date: Thu Jan 10 13:03:59 2008 +0100 [ALSA] hda-codec - Update realtek codec support 1. Support HP rp5700 2. Fixed alc_subsystem_id function (Bug fixed and support Desktop) 3. Support ASUS EP20 Signed-off-by: Kailang Yang <kailang@realtek.com.tw> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Jaroslav Kysela <perex@perex.cz> :040000 040000 7a026ff0ca16cbed82662969ae91eaad13af3489 95443aea4feae93e85af29ad2e98cd0bdbebe5bb M Documentation :040000 040000 0987ce5757dcb9185354b80dd667f58641c62b1f 4123572e5892045052a5ab0da97545eef98ddbc7 M sound
Created attachment 15408 [details] realteck.diff This patch revert the part wich was brocken for me.
Re-assign this bug to the patch author. :)
Could you run alsa-info.sh before and after suspend (better with --no-upload)? http://hg.alsa-project.org/alsa/raw-file/tip/alsa-info.sh
Created attachment 15956 [details] alsa-info.txt.before
Created attachment 15957 [details] alsa-info.txt.after
The pin-default values are changed during suspend/resume, and this is not what the sound driver does. So, something is screwed up, at least. What happens if you reload the sound driver after resume? Is the alsa-info.sh output identical with the state before suspend?
Also, could you check whether the current Linus git tree works? There are some fixes for auto configuration of Realtek codecs since 2.6.25...
This reports was made with latest linus git.
Created attachment 15958 [details] alsa-info.txt.reload
May it be not a suspend issue but some boot initiation issue? It seems like pci space was reconfigured after suspend.
I made somole test, - blacklisted snd_hda_moduel, - rebooted and suspendet S§ and resume - loaded module ( sound working ) - supend && resume ( sound working too ) Sound working OK if setpci -s 00:1b.0 0x40 return 0x01 but after fresh boot 0x40=0x03. Is it possible to make on boot, setpci -s 00:1b.0 40=01 ?
Seems like there is some thing wrong with autoconfiguration from BIOS. I found new work around, just set module option model=6stack-dig and it working for me without any problem ;)
Could you check whether the latest tree still has the same problem?
seems to be fixed now. than you.
Thanks for checking!