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...
Created attachment 7317 [details] dmesg-01-before-s2ram.txt
Created attachment 7318 [details] lspci-vvv-01-before-s2ram.txt
Created attachment 7319 [details] lspci-vvv-02-after-s2ram.txt
Created attachment 7320 [details] lspci-xxx-01-before-s2ram.txt
Created attachment 7321 [details] lspci-xxx-02-after-s2ram.txt
Sounds like driver's bug.
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."
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).
Does it still happen with 2.6.17-rc4?
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.
Well, you provided the needed info, so NEW is now the right state.
Any progress?
Still broken in 2.6.18 final
Can we consider it as a duplicate of Bug #6181?
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.
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.
Does this problem also occur after a resume from disk?
"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.
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.
*** This bug has been marked as a duplicate of 7236 ***
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.
Forgot to change the kernel number when reopening... sorry. Done now.
OK, thanks for the update.
I guess the status hasn't changed?
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.
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.
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 #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?
_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...
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.
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.
wow, a really old problem, I guess the problem still exists in the latest kernel release, say 2.6.27, right?
Hi, Rui It seems that there is no response for more than two months. How about close this bug? Thanks.
close it as there is no response for over 4 months.