http://bugzilla.kernel.org/show_bug.cgi?id=6072
Summary: Suspend to RAM permanently "mutes" all sound - ALSA
loaded or unloaded. PCI related - VIA VT8233
Kernel Version: 2.6.16-rc3
Status: NEW
Severity: normal
Owner: [EMAIL PROTECTED]
Submitter: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
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...
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
acpi-bugzilla mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
