Most recent kernel where this bug did not occur: all 2.6.x Distribution: Debian Sarge Hardware Environment: Thinkpad A21m Software Environment: Problem Description: When I suspend to Ram and resume cs46xx stop working. If I rmmod modprobe snd_cs46xx sound start working, but If I do this often comp sometime freeze Steps to reproduce: Close and open lid switch a try to play some song
Upstream bug: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1946
Has it been fixed after 2.6.16-rc6?
Rejecting due to the lack of response.
Sorry I lost previous mail. This but isn't fixed. problem still exists in 2.6.18. But I resubmit bug to ALSA. Dan
Is the problem still present in 2.6.19-rc6? If so, does it happen after a resume from RAM or from disk?
I now use 2.6.18. I try 2.6.19-rc6 and let you know.
Please reopen this bug if it's still present with kernel 2.6.20.
I compile 2.6.20 on this week and let you know.
with 2.6.20 still the same after suspend/resume sound stop working. cat /etc/hosts > /dev/dsp newer returns. Reload modules help.
Can you please try the suspend to disk and see if the problem occurs after the resume?
I try suspend to disk and resume and sound doesn't work situation is the same.
I'm thinking that this may or may not be related, but the 2.6.19-rc3 patch (namely the commit 30b35399ceb2398d05837863476dcb12f12f3a82) broke atleast the intel8x0 on my laptop (HP NW8000)so that sounds from the speakers remained dead. When I removed the line: pci_set_power_state(pci, pci_choose_state(pci, state)); from the intel8x0_suspend function it works again after the supend as it has always as far back as I can remember. Same remove-that-line also does the trick for newer kernels (I actually started noticing that after the FC6 upgraded to 2.6.19 base). I did check that the pci_choose_state does indeed return 3 (PCI_D3hot ain't it?), which seems ok, so the actual reason why that breaks the sounds from the speakers (headphones do work!) on my laptop I have no idea. Perhaps someone with more understanding on the pci power settings can have a go at this. I'm more than willing to try out patches or be more verbose about this. For now I'll just stick to commenting out that line for my kernels.
Can you please send your one-liner patch to LKML (Cc to the ALSA development list maybe) with the information why it's needed?
sure, I would've done that straight way, but it's just that the one-liner in question is most certainly not a proper _fix_. but yes, it probably best to report there, too, atleast it's worth pointing out that the given regression does break sounds after suspend atleast on some hw.
The problem of cs46xx driver is very likely different from intel8x0. It never worked with some Thinkpad models. The call of pci_set_power_state(pci, pci_choose_state(pci, state)) in the suspend callback was added because it is what Documentation/power/pci.txt tells. How can this call be harmful? Or, is it the order of pci_save_state() and pci_disable_device()? Tommi, could you try to exchange pci_save_state() and pci_disable_device() lines in suspend?
takashi: Doesn't work. There's likely some state-like settings that's not being saved using mere pci_save_state, or more likely not restored upon resume. I recall having read somewhere about some amplifier power setting on laptops, but I can't remeber that much more accurately than that. I'll try to google that up and let you know if I'll find the right threads again. In anycase this seems like a wrong bug entry to deal with this issue, eh? #6181 might be closer. I'll try go through the bugzilla listings once more and see if there's some other information that might be related, but it'll probably have to wait for next week.
OK, let's continue the discussion about intel8x0 on #6181.
What is the current status of this bug?
It's a long-standing problem (likely specific to thinkpad), and hard to fix without a hardware...
So what's the next step. whould it be helpful to get guidance from ACPI side? Contacting laptop/chipset manufacturers?
Patch submited to alsa-devel list and patch aviable there [last patch]. https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1946
Has this patch fixed problem for you Daniel?
I don't know now. I must test it this week. Please be patient.
Situation is much better, but in dmesg I found this warnings: dsp_spos: WARNING current parameter data may be overwriten! dsp_spos: symbol <sposCB> duplicated dsp_spos: symbol <nullSCB> duplicated dsp_spos: symbol <FGtaskTreeHdr> duplicated dsp_spos: symbol <BGtaskTreeHdr> duplicated dsp_spos: symbol <TimingMasterSCBInst> duplicated dsp_spos: symbol <CodecOutSCB_I> duplicated dsp_spos: symbol <MasterMixSCB> duplicated dsp_spos: symbol <CodecInSCB> duplicated dsp_spos: symbol <WriteBackSCB> duplicated dsp_spos: symbol <VariDecimateSCB> duplicated dsp_spos: symbol <RecordMixerSCB> duplicated dsp_spos: symbol <CodecOutSCB_Rear> duplicated dsp_spos: symbol <RearMixerSCB> duplicated dsp_spos: symbol <MagicSnoopSCB_I> duplicated dsp_spos: symbol <SPIOWriteSCB> duplicated dsp_spos: symbol <SrcTaskSCB_SPDIFI> duplicated dsp_spos: symbol <SPDIFOSCB> duplicated dsp_spos: symbol <SPDIFISCB> duplicated dsp_spos: symbol <AsynCodecInputSCB> duplicated ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 usb usb1: root hub lost power or was res I mean that this patch is not 100% correct. With this patch I cannot resume propertly from hibernation.
A better patch was already merged to 2.6.23-rc1 tree. Give it a try.
:-( With 2.6.23-rc1 sound after resume did't work. cat /etc/hosts > /dev/dsp never returns. And after resume I get OOPS :-(. Situation is the same as before.
I can reproduce the same problem, on a Thinkpad T22, with the same sound card using 2.6.24.-rc4. I dont get any OOPS, and cs46xx is built into the kernel(not module). Running cat /etc/hosts > /dev/dsp never returns after the resume.
Switching to another DSP core solve my problem.
Can you provide some more details, thanks.
Look at this bug. https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1946 Switch to OLD DSP image solve problem.
I still don't understand what the "OLD DSP image" is and why switching to in apparently helps. May I see the patch please? Also, is it fixed in the latest mainline kernel?
Run menuconfig and go Drivers->Sound->Alsa <M> Cirrus Logic (Sound Fusion) CS4281 x x x x <M> Cirrus Logic (Sound Fusion) CS4280/CS461x/CS462x/CS463x x x x x [ ] Cirrus Logic (Sound Fusion) New DSP support and disable New DSP support compile new kernel and enjoy.
Thanks for the clarification. Still, this seems to mean that suspend is only supported if the old DSP is used. If that's the case, we have only a workaround and the problem is still not fixed.
Or my sound card work well only with old DSP code I dont' know sorry.
still present in 2.6.28 on thinkpad a21m. using OLD_DSP is no solution, since it breaks features (i.e.: multiple programs using soundcard at the same time).