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/Suspend | Assignee: | 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
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. |