Most recent kernel where this bug did not occur: It occured in 2.6.12 too I did not test before Distribution: ubuntu dapper, ubuntu breezy Hardware Environment:HP nx8220 laptop, PCI id :8086:266e Problem Description: After resuming from suspend to RAM, the card behaves as if headphone jack sense were on and the jack were plugged in. All togglings of mixer settings with jack in or out result in the same effect Sound is only heard through the headphones not through the speakers If I only do alsactl power D3 and then D0 instead of systemwide suspend/resume it works ok though. The same problem occurs with the OSS driver. So either both are missing something or the problem is at PCI/ACPI or otherwise out of the driver's responsability. Removing and reloading the module after resume does not fix the issue. When resuming from suspend to disk things are fine, it needs a power cycle apparently. In the mixer settings I do not see an external amplifier switch if this helps in any way. Steps to reproduce: using the software suspend code in dapper (mainline + patches, not swsusp2 if it matters) enter STR. On resume speakers are muted even though they were not before.
Ah, this is exactly as my bug 6072 with the snd_via82xx driver (and even without it). At the report time I didn't have any headphones. Plugging in a nice set, the sound does indeed come out there, even though the Headphone entry in alsamixer is MM (muted). I'm so happy about this progress :-) Gives a datapoint at least.
Here's a diff before and after s2ram of the sound chip registers: --- via-01-ac97#0-0+regs 2006-03-09 00:44:36.000000000 +0100 +++ via-02-ac97#0-0+regs 2006-03-09 00:44:36.000000000 +0100 @@ -45,8 +45,8 @@ 0:58 = 0000 0:5a = 8230 0:5c = 0018 -0:5e = 0008 -0:60 = ffff +0:5e = 0000 +0:60 = 0000 0:62 = 0000 0:64 = 0000 0:66 = 0000 The 5e entry changes whenever I play something, also after resume, but 60 remains zeroed. And a "echo 60 ffff > /proc/asound/card0/codec97#0/ac97#0-0+regs" does nothing. Neither 'echo "60 ffff"', and yes, I do have CONFIG_SND_DEBUG enabled. Uploading the resulting info files:
Created attachment 7535 [details] via-ac97#0-0 via-ac97#0-0 Before and after s2ram is unchanged.
Created attachment 7536 [details] via-01-ac97#0-0+regs via-01-ac97#0-0+regs Before s2ram.
Created attachment 7537 [details] via-02-ac97#0-0+regs via-02-ac97#0-0+regs After s2ram.
I have this in dmesg on return from suspend. The code around it has a FIXME so it is probably not entirely unexpected behaviour AC'97 0 analog subsections not ready it looks for 0x0F in register 0x26 (powerdown) and times out if the four bits there are not 1 meaning subsytem ready. However when I check through /proc after resume it is set to 0x0F. other than that my registers look the same before and after resume. Sometimes reg 72 has the jack input bit set even that is not plugged in but that's all.
I had to cat /proc/asound/card0/codec97#0/ac97#0-0+regs twice after a resume to see the altered regs. First cat was exactly as before suspend - like some kind of cache ghost remaining on disk or in memory. I'll be out at least six hours from now, should someone expect me available.
I have a HP nw8240, which I think is similar model in respect of which this bug was submitted. The symptoms are the same: after suspend to ram, the internal speakers do not work and cannot be made to work again without a reboot--but the rest of the sound system is ok. I am not sure but I guess that the cause of my problem is similar. I would appreciate it if anyone who does have this specific problem could get in touch with me so we could diagnose it more easily. Here is what I wrote about the problem on the ubuntu bug tracker: I checked the hardware on my HP nw8240 laptop and the problem occurs because after suspend to RAM, the 5V power supply to the audio power amp IC is turned off. This is *not* controlled by the amplifier power down pin of the AC97 codec as would usually be the case, so nothing you can do with the AC97 will fix the problem. Indeed, all the AC97 registers are the same before and after suspend. The audio controller PCI configuration space registers are also the same. Clearly, the nw8240 (and maybe other HP laptops) control the audio power amp power supply from somewhere else. I couldn't figure out physically where the signal comes from on the motherboard. I guess it has to do with the ACPI subsystem and the embedded controller-- but as I don't know much about this I am not able to debug it. I am not even sure whether the embedded controller is part of the Intel chipset, or a separate chip. I did play around with an adapted version of the kernel ibm_acpi module's ecdump utility to read and modify the embedded controller registers--but the best I could do by randomly tweaking the registers was crash my machine. Maybe someone who knows a bit about ACPI could suggest some productive ways of mapping out the hardware? Presumably other special features of the laptop, like the shock sensor, could also be accessed through ACPI if this could be figured out. It is important to note that this issue is almost certainly HP-specific and not related to the numerous other "no sound after resume" issues that people have, which are fixable by simply setting the AC97 codec registers correctly. It would be great if someone who is interested in this issue and knows something about ACPI and/or HP laptops could contact me so we could diagnose it. You can contact me on mb@gem.win.co.nz
Is the problem still there in 2.6.18?
I consider this bug as a duplicate of Bug #7236. Whoever can mark that, please do so.
*** This bug has been marked as a duplicate of 7236 ***
This is NOT a duplicate of 7236 - 7236 describes a totally different problem on different hardware. On HP laptops it appears that the internal amplifier is not powered after resume from suspend-to-RAM, see here: https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/21574 This is quite different from the issue described in 7236 - in this bug we cannot get the internal speakers to work at all; 7236 describes a problem where the internal speakers are completely functional but not muted. Clearly in 7236 the amp has power post-resume so we are dealing with a different issue.
There are some suspend fixes for that driver in 2.6.19-rc...
I hope this wasn't closed because of what I said... I don't actually experience the bug so I can't confirm or deny that the patches actually fixed the problem. I was just saying that there were some patches merged that might make a difference. Sorry for the misunderstanding if that wasn't clear.
Created attachment 10623 [details] avoid regression I have this exact same behaviour on an hp nw8000, but my speakers have worked fine from 2.6.16ish up to 2.6.18, and then broke between 2.6.19-rc2 and -rc3. git-bisect showed that the commit 30b35399ceb2398d05837863476dcb12f12f3a82 was the one that triggers it. And as far as I can tell it's broken up to 2.6.20 and may or may not have been fixed after that, because for me the mainline is busted since 2.6.21-rcX, it won't wake up from suspend at all. Attached patch avoids the regression caused by the said commit for 2.6.19 and up, but obviously is not an actual fix for the problem.
If pci_set_power_state() is the cause, I suppose it's a missing piece in the PCI core part. Anyway, I'm not strongly against this workaround, but I'd rather comment out the line (with some description), instead of removing it. Will be committed to ALSA tree soon.
Takashi, actually I think you should be strongly against it. I never meant it for inclusion anywhere. I'm obviously hoping to get the thing fixed but not with that patch. Nevermind it fixes one odd laptop, the problem in any case is elsewhere and that patch only tries to shed some light on that. Besides, removing ok code to get-by with quirky hardware is not something I want to advocate for. Let's not haste into anything, eh? It's awfully hard to find information and/or other reports about this issue, because there have ac97 related issues recently that caused similar symptoms. But I'll keep going at it.