Bug 6181 - snd-intel8x0 speakers mute after resume from suspend to RAM
Summary: snd-intel8x0 speakers mute after resume from suspend to RAM
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Ihab
Depends on:
Reported: 2006-03-07 02:59 UTC by Jani Monoses
Modified: 2007-08-31 06:17 UTC (History)
2 users (show)

See Also:
Kernel Version:
Regression: ---
Bisected commit-id:

via-ac97#0-0 (550 bytes, text/plain)
2006-03-08 16:02 UTC, Mats Johannesson
via-01-ac97#0-0+regs (768 bytes, text/plain)
2006-03-08 16:04 UTC, Mats Johannesson
via-02-ac97#0-0+regs (768 bytes, text/plain)
2006-03-08 16:04 UTC, Mats Johannesson
avoid regression (361 bytes, patch)
2007-03-06 04:19 UTC, Tommi Kyntola
Details | Diff

Description Jani Monoses 2006-03-07 02:59:53 UTC
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

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.
Comment 1 Mats Johannesson 2006-03-08 14:07:52 UTC
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.
Comment 2 Mats Johannesson 2006-03-08 15:59:32 UTC
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:
Comment 3 Mats Johannesson 2006-03-08 16:02:53 UTC
Created attachment 7535 [details]

via-ac97#0-0 Before and after s2ram is unchanged.
Comment 4 Mats Johannesson 2006-03-08 16:04:11 UTC
Created attachment 7536 [details]

via-01-ac97#0-0+regs Before s2ram.
Comment 5 Mats Johannesson 2006-03-08 16:04:58 UTC
Created attachment 7537 [details]

via-02-ac97#0-0+regs After s2ram.
Comment 6 Jani Monoses 2006-03-08 20:57:02 UTC
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.
Comment 7 Mats Johannesson 2006-03-09 00:03:40 UTC
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.
Comment 8 Mario Becroft 2006-09-26 09:02:21 UTC
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
Comment 9 Pavel Machek 2006-09-29 04:13:18 UTC
Is the problem still there in 2.6.18?
Comment 10 Rafael J. Wysocki 2006-11-19 04:11:15 UTC
I consider this bug as a duplicate of Bug #7236.  Whoever can mark that, please
do so.
Comment 11 Adrian Bunk 2006-11-19 14:58:40 UTC

*** This bug has been marked as a duplicate of 7236 ***
Comment 12 Bryn Hughes 2006-11-22 13:59:11 UTC
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:


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.
Comment 13 Dan Carpenter 2006-11-23 11:29:16 UTC
There are some suspend fixes for that driver in 2.6.19-rc...
Comment 14 Dan Carpenter 2006-11-23 23:51:14 UTC
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.
Comment 15 Tommi Kyntola 2007-03-06 04:19:12 UTC
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.
Comment 16 Takashi Iwai 2007-03-09 07:17:20 UTC
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.
Comment 17 Tommi Kyntola 2007-03-12 00:00:52 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.