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
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
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
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 Before and after s2ram is unchanged.
Created attachment 7536 [details]
via-01-ac97#0-0+regs Before s2ram.
Created attachment 7537 [details]
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 email@example.com
Is the problem still there in 2.6.18?
I consider this bug as a duplicate of Bug #7236. Whoever can mark that, please
*** This bug has been marked as a duplicate of 7236 ***
This is NOT a duplicate of 7236 - 7236 describes a totally different problem on
On HP laptops it appears that the internal amplifier is not powered after resume
from suspend-to-RAM, see here:
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
Sorry for the misunderstanding if that wasn't clear.
Created attachment 10623 [details]
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
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
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
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.