Bug 6072

Summary: Suspend to RAM permanently "mutes" all sound - ALSA loaded or unloaded. PCI related - VIA VT8233
Product: Power Management Reporter: Mats Johannesson (spamcan)
Component: Hibernation/SuspendAssignee: Rafael J. Wysocki (rjwysocki)
Status: REJECTED INSUFFICIENT_DATA    
Severity: normal CC: acpi-bugzilla, bunk, pavel, protasnb, rjwysocki, tiwai
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.23-rc4 Subsystem:
Regression: --- Bisected commit-id:
Bug Depends on:    
Bug Blocks: 7216    
Attachments: dmesg-01-before-s2ram.txt
lspci-vvv-01-before-s2ram.txt
lspci-vvv-02-after-s2ram.txt
lspci-xxx-01-before-s2ram.txt
lspci-xxx-02-after-s2ram.txt

Description Mats Johannesson 2006-02-14 11:12:43 UTC
Most recent kernel where this bug did not occur: Unknown
Distribution: slamd64
Hardware Environment: x86_64
Software Environment: pure terminal and inside X
Problem Description: See below

Steps to reproduce: echo -n "mem">/sys/power/state

(Cc: Pavel since he asked me to do that Wed 25 Jan 2006 in a short e-mail
exchange named "Is suspend-to-ram part of the swsusp or not?")

I've booted as far back as kernel 2.6.12 with no change in behaviour. It doesn't
matter if I compile modules used into the kernel (sound, cpufreq, usb), or if
those modules are loaded or not. Closed source video and wireless unloaded - no
effect. Even booting into the most barebone environment possible, s2ram kills
anything sound-related. Suspend to disk is all OK, however. This is some kind of
a lowlevel PCI problem.

Notebook is an Acer Aspire 1520 (1524) WLMi with an AMD Athlon64 Processor 3400+
on a VIA K8M800 (VT8237 PCI bridge [K8T800 South]), 2 Gig memory. Sound is
normally driven by the ALSA snd_via82xx driver and co.

Nothing short of a reboot will restore sound after a s2ram. If the sound-driver
is loaded, /proc/interrupts show the VIA8233 to be operating normally after the
resume - but... it's "mute".

I've produced some dumps of the PCI space which might shed light on the issue
(will upload later). They were snapped as first thing after a boot in a really
barebone environment, thusly:

#!/bin/sh
/usr/bin/sleep 5
/bin/dmesg >/root/debug/dmesg-01-before-s2ram.txt
/sbin/lspci -vvv >/root/debug/lspci-vvv-01-before-s2ram.txt
/sbin/lspci -xxx >/root/debug/lspci-xxx-01-before-s2ram.txt
/usr/bin/sync
/usr/bin/sleep 5
echo -n "mem">/sys/power/state
/usr/bin/sleep 5
/sbin/lspci -xxx >/root/debug/lspci-xxx-02-after-s2ram.txt
/sbin/lspci -vvv >/root/debug/lspci-vvv-02-after-s2ram.txt
/bin/dmesg >/root/debug/dmesg-02-after-s2ram.txt
/usr/bin/sync
/usr/bin/sleep 5
/sbin/halt

The diff between the two dmesg is:

Stopping tasks: =================|
pnp: Device 00:09 disabled.
Back to C!
PCI: Setting latency timer of device 0000:00:01.0 to 64
ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 17 (level, low) -> IRQ 16
ACPI: PCI Interrupt 0000:00:0b.1[B] -> GSI 18 (level, low) -> IRQ 17
ACPI: PCI Interrupt 0000:00:11.1[A]: no GSI
pnp: Device 00:07 does not supported activation.
pnp: Failed to activate device 00:08.
pnp: Device 00:09 activated.
Restarting tasks... done

Perhaps someone, someday, will make those messages more verbose, and name the
devices...

I don't want to put anyone on the wrong track, but I've experimented with a
section that look relevant in the lspci -xxx diff:

[00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237
AC97 Audio Controller (rev 50)]

@@ -327,7 +327,7 @@
 10: 01 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 25 10 46 00
 30: 00 00 00 00 c0 00 00 00 00 00 00 00 0b 03 00 00
-40: 05 c1 00 00 40 00 00 00 00 00 00 00 3f 00 00 00
+40: 00 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00
 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[00:11.6 Communication controller: VIA Technologies, Inc. AC'97 Modem Controller
(rev 80)]

@@ -345,7 +345,7 @@
 10: 01 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 25 10 46 00
 30: 00 00 00 00 d0 00 00 00 00 00 00 00 0b 03 00 00
-40: 05 c1 00 00 40 00 00 00 00 00 00 00 3f 00 00 00
+40: 00 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00
 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The modem is not used at all by me, and seems mostly to be a "ghost" on the
sound chip. Anyway, at the 40: address we see two values being changed after a
resume. The "3f" thing is read-only but the first one not. So, booting into the
same barebone environment - without suspending - I've written a "0001" there.
Here's the result:

After booting, a push on [Backspace] at an empty bash command prompt gives a
short "Bell"/"Sound-Beep" (ALSA is not loaded, remember).

After a "pcitweak -w 00:11:05 -h 64 0x0100" to simulate a resume from s2ram, the
push on [Backspace] produces a "Bell" of circa three times higher volume than
the original.

After a "pcitweak -w 00:11:05 -h 64 0xc105" to restore the value, a push on
[Backspace] produces _nothing_! Sound has been "muted" like after a s2ram resume.

Loading ALSA at this stage does not restore any sound.

But if I don't load ALSA, I can flip back and forth between 0xc105 (no sound)
and 0x0100 (sound with an abnormal volume). If a s2ram has happened, no writing
to that PCI address alters the "mute" state.

I've tried poking at other diffs in the PCI space without success.

My output from acpidump has already been uploaded to bug 5767 so won't be resent:

http://bugzilla.kernel.org/attachment.cgi?id=6910&action=view

Let's see if I can attach more than one file at a time for the PCI dumps...
Comment 1 Mats Johannesson 2006-02-14 11:16:20 UTC
Created attachment 7317 [details]
dmesg-01-before-s2ram.txt
Comment 2 Mats Johannesson 2006-02-14 11:17:49 UTC
Created attachment 7318 [details]
lspci-vvv-01-before-s2ram.txt
Comment 3 Mats Johannesson 2006-02-14 11:18:51 UTC
Created attachment 7319 [details]
lspci-vvv-02-after-s2ram.txt
Comment 4 Mats Johannesson 2006-02-14 11:19:52 UTC
Created attachment 7320 [details]
lspci-xxx-01-before-s2ram.txt
Comment 5 Mats Johannesson 2006-02-14 11:21:18 UTC
Created attachment 7321 [details]
lspci-xxx-02-after-s2ram.txt
Comment 6 Shaohua 2006-02-22 19:18:58 UTC
Sounds like driver's bug.
Comment 7 Mats Johannesson 2006-03-08 14:13:07 UTC
The bug 6181 about a snd-intel8x0 experience reveal the sound coming out through
the headphone jack. I'll copy what I just added to that entry:

"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 8 Mats Johannesson 2006-03-08 16:10:17 UTC
Uploaded ac97#0-0 and ac97#0-0+regs files to bug 6181 since one register is
changed after s2ram (and remains so even after trying to echo the old value back).
Comment 9 Pavel Machek 2006-05-19 02:59:47 UTC
Does it still happen with 2.6.17-rc4?
Comment 10 Mats Johannesson 2006-05-21 21:01:42 UTC
Yes, 2.6.17-rc4-git6 is speaker mute after s2ram, only headphone out available.

Reading the actual chip markings of the southbridge reveals it to be a VT8235
and I've managed to hunt down the full datasheet.

As can be seen in my original pci-dumps 00:11.5 (audio) has been initialized to
C1 at offset 41 [AC Link Interface Control] after boot - without alsa loaded.
Offset 40 [AC Link Interface Status] is a read-only register and showing 05.
This means:

_Offset 40 (bit 0->7 order) RO_
1 = Codec CID=00b -- ready (audio ctrlr can access codec)
0 = Low-Power Status -- AC97 Codecs not in low-power mode
1 = Codec CID=01b -- ready (...)
0 = Reserved
0 = Codec CID=10b -- not ready
0 = Codec CID=11b -- not ready
0 = Reserved
0 = Reserved

_Offset 41 (bit 0->7 order) RW_
1 = Reserved (datasheet wrongly claims it to always read 0 - it's always 1 here)
0 = Reserved
0 = 3D Audio Channel Slots 3/4 -- disabled (default)
0 = Variable-Sample-Rate On-Demand Mode -- disabled (default)
0 = AC-Link Serial Data Out -- Release SDO (default)
0 = AC-Link Sync -- Release SYNC (default)
1 = AC-Link Reset -- De-assert AC-Link Reset (not default)
1 = AC-Link Interface -- Enable (not default)

So when offset 40 turns up as 00 and offset 41 as 01 after a resume from s2ram
it clearly reveals that someone/something has turned off the whole AC-Link.

When alsa is loaded at boot, offset 41 is a CD instead of C1 - meaning that 3D
audio channel and variable sample rate has been enabled. Doing a s2ram and
resume from this stage, the audio registers come up unchanged (ie 05cd). So
alsa(?) ensures the state to be unaltered.

From a speaker-mute situation I've unloaded alsa and written to offset 41, but
neither ED (warm reset) nor 8D (cold reset) could restore the speakers when alsa
got loaded again.

The recently filed bug 6575 "sound only through headphones when acpi turned on"
also hints towards acpi pulling nasty tricks. So, David (comment #6 ) I do
believe this bugreport to belong here.

I've looked at all the other PCI registers that change after a s2ram, but
nothing else seem to be related. They are perfectly natural things like "PCI PNP
Interrupt routing" and "GP3 Timer" etc.

Pavel, is NEEDINFO satisfied? I'll try to flip it back to NEW... unsure about
the finer points of bugzilla reporting, I am.
Comment 11 Pavel Machek 2006-05-22 02:34:37 UTC
Well, you provided the needed info, so NEW is now the right state.
Comment 12 Rafael J. Wysocki 2006-09-29 07:37:48 UTC
Any progress?
Comment 13 Mats Johannesson 2006-09-29 07:39:50 UTC
Still broken in 2.6.18 final
Comment 14 Rafael J. Wysocki 2006-11-13 10:44:01 UTC
Can we consider it as a duplicate of Bug #6181?
Comment 15 Mats Johannesson 2006-11-13 14:18:18 UTC
Was that question directed at me Rafael? I'd say yes, if the other was flipped
from alsa to acpi... I can't do what the last commenter have done (measure the
voltages), but it sounds plausible.

However, observe what he said:

"problem. Indeed, all the AC97 registers are the same before and after suspend.
The audio controller PCI configuration space registers are also the same."

Whereas my PCI space is altered (if alsa isn't loaded). Perhaps he didn't test
without alsa.

Well, you people are the ones to track the issue, so you decide about duplicate
status, not me.
Comment 16 Rafael J. Wysocki 2006-11-15 04:35:17 UTC
The question was directed at everyone who had any opition about that. ;-)

Well, I think both problems are of "ALSA vs ACPI" kind, so it's sufficient to
have one bugzilla entry for both until we state they are two separate problems
indeed.
Comment 17 Rafael J. Wysocki 2006-11-17 09:55:04 UTC
Does this problem also occur after a resume from disk?
Comment 18 Mats Johannesson 2006-11-18 05:28:38 UTC
"anything sound-related. Suspend to disk is all OK, however. This is some kind
of a lowlevel PCI problem."

Nope. The act of booting restored sound to its proper state.

I can however not verify/test anything nowadays. The system back then was
extremely 'clean' and barebone with only the kernel being constantly upgraded.

A couple of weeks ago I installed ubuntu 6.10 (but chucked their slow kernel in
favour of 2.6.19-rc5). Trying suspend ram/disk today revealed that _nothing_
works. Black screen when to disk but no shutdown. Power off when suspend to ram,
but black screen on resume (from inside X).

I'll probably have to tinker quite a lot to get anything working now, and it's
not high on my todo-list - primarily because _sound does not work after resume_
(through speakers ;-) To me that is a serious show-stopper.

So please, don't ask me to perform anything in the near future. I'll have
nothing to add. The history and details are all listed above.

2.6.19-rc5 is the last dysfunctional that I can confirm, right now.

Comment 19 Rafael J. Wysocki 2006-11-19 03:57:10 UTC
It looks like we have the problem reported once again in Bug #7236, so I'm going
to make this one a duplicate of that bug.
Comment 20 Rafael J. Wysocki 2006-11-19 04:07:40 UTC

*** This bug has been marked as a duplicate of 7236 ***
Comment 21 Mats Johannesson 2007-04-28 15:02:45 UTC
Rafael, I saw you removing the link to the meta-bug 7216 today. Hmmm... well
here's an update on my end.

The fix for intel8x0 (not calling pci_set_power_state on suspend) as in the
patch Greg posted for the stable 2.6.20, does NOT work for this via chip. I've
tried a kernel.org 2.6.21 with both via82xx.c and via82xx_modem.c patched like
that. No cigar...

So business as usual. Sound after s2ram on this machine seems like a total no-go.

I'm opening the this bug again since hiding it as duplicate will only confuse
matters.

Comment 22 Mats Johannesson 2007-04-28 15:03:56 UTC
Forgot to change the kernel number when reopening... sorry. Done now.
Comment 23 Rafael J. Wysocki 2007-04-28 16:04:22 UTC
OK, thanks for the update.
Comment 24 Rafael J. Wysocki 2007-05-30 11:19:46 UTC
I guess the status hasn't changed?
Comment 25 Natalie Protasevich 2007-06-19 00:29:13 UTC
Mats,
Can you please do the refresh on status for 2.6.22-rc5. Some fixes went in that might have fixed your problem.
Thanks.
Comment 26 Mats Johannesson 2007-06-19 16:58:21 UTC
Rafael, Natalie,
linux-2.6.22-rc5-git3 tried under Ubuntu 7.04. No change. Sound shifted from speakers to headphone jack after suspend to memory. I wish you a nice summer.
Comment 27 Takashi Iwai 2007-06-20 10:05:33 UTC
Could you try to comment out the call of pci_set_power_state() in snd_via82xx_suspend() ?  There were S2R-related bugs on intel8x0, and that call was the culprit.
Comment 28 Mats Johannesson 2007-06-24 15:16:35 UTC
Comment #21 shows that I tried the intel hack two months ago, Takashi. Nothing changed. Though I don't remember if I disabled the call in snd_via82xx_resume() as well... Probably did, since it seems strange to do a follow-up call when not having done the first part. Anyway, I did it according to the patch Greg posted.

Hmm. Why can't I as the reporter change status from needinfo?
Comment 29 Mats Johannesson 2007-06-24 17:01:25 UTC
_Hack re-done on 2.6.22-rc5-git3_

via82xx.c and via82xx_modem.c first disabled pci_set_power_state() only in snd_via82xx_suspend(), then also in snd_via82xx_resume(). No change, no difference.

I went crazy and also disabled pci_save_state() and pci_restore_state(). On resume from s2r then got some kind of cascading errors: ALSA "AC'97 codec is not ready" and "codec_read: codec 0 is not valid [0xffffffff]", after which "ACPI: EC:" got read timeouts and Exceptions/Errors galore, and the machine lost both keyboard and touch pad.

Well, it was worth a try...
Comment 30 Mats Johannesson 2007-08-28 11:06:31 UTC
No change in bug behaviour with 2.6.23-rc4 (perhaps suspend to disk got the brunt of code changes this development round). Let's see if you manage a fix within a year - at which time this notebook gets its pension life as the usual "closet server". I'll be sure to stay away from VIA hardware in the next machine.

Happy Autumn.
Comment 31 ykzhao 2008-09-25 20:29:21 UTC
hi, Mats
    Will you please try the latest kernel(2.6.27-rc6) and see whether the problem still exists?
   If exist, please attach the output of lspci -vvvxxx after and before suspend. Of course the output of dmesg is also required.
    Thanks.
Comment 32 Zhang Rui 2008-11-19 22:48:14 UTC
wow, a really old problem,
I guess the problem still exists in the latest kernel release, say 2.6.27, right?
Comment 33 ykzhao 2009-02-11 21:31:02 UTC
Hi, Rui
    It seems that there is no response for more than two months. How about close this bug?
    Thanks.
Comment 34 Zhang Rui 2009-02-11 22:14:38 UTC
close it as there is no response for over 4 months.