Bugzilla – Bug 447624
sound settings not restored after resume or reboot
Last modified: 2009-02-26 14:32:14 UTC
ALSA is configured and works well. But after a resume or a reboot I have to call alsaconf again to get it working.
Please elaborate "get it working", and a bit more detail please. Otherwise I'd ask you like... Is the device present in /proc/asound/cards after boot? Which desktop system are you using? KDE, GNOME, else? Which sound backend? Did it work on 11.0 without problems? Which hardware, more exactly? How did you test with which application?
Created attachment 254401 [details] /proc/asound/cards in working and non working state
I'm using KDE 4. The same issue had been there in openSUSE 11.0 while running KDE 3. For testing I call "aplay /usr/share/sounds/alsa/test.wav" as non root user. In the non working state the command doesn't return and stays in state "SL+" in the process list. Next I'll attach "hwinfo --all" next.
Created attachment 254405 [details] "hwinfo --all --log" output
So, the driver is loaded properly at boot. Then the problem must be the rest. Check the following after the login without rcalsasound restart: - check the permissions of /dev/snd/* files; usually you have to be added in ACL. See the output of "getfacl /dev/snd/*" - check whether any other process (sound subsystem) is running. Check via fuser /dev/snd/*; on KDE4, pulseaudio can be used depending on the setup - check the mixer setup; kmix is known to screw up everything often If another process is running, try to kill it, and try aplay again.
Created attachment 254418 [details] "getfacl --tab -R /dev/snd" output
The user "lmuelle" is a member of the audio group.
Fuser doesn't report any process accessing any of the files in /dev/snd/ I've checked alsamixer and each setting - beside the one of mic which was at 0 - everything is at level 81. kmix isn't running nor have I used it (by intention).
And what is the problem now, exactly?
As soon as I reboot or resume from suspend the sound doesn't work any more. As I workaround I call "alsaconf" each time = after each reboot or resume to get the sound working. With "work" I mean I can't play sound - for example with aplay - as I had been able before the reboot or resume action.
What do you mean "I can't play sound"? You get an application error or don't get the sound output from any output jack?
I don't get the sound output when I try to play /usr/share/sounds/alsa/test.wav for example _but_ I also don't get any error. No error from the application nor from the kernel (/var/log/messages, dmesg). The aplay command as mentioned in comment #3 doesn't return and stays endless in state "SL+". Sound output works as soon as I call alsaconf again. But only till the next reboot or suspend/ resume.
Weird. Usually when the operation is blocked due to the hardware misconfiguration, e.g. DMA isn't started, the driver will give you warnings after a certain time, 10 seconds or so. OK, we should make the things simple. Reboot with runlevel 3 to avoid KDE. Login as root on linux console, and check "aplay -vv somefile.wav". Does it work? If yes, do suspend, resume and check aplay again. Also, run /usr/sbin/alsa-info.sh with --no-upload option, and attach the generated file.
Created attachment 254430 [details] alsa-info output in the working state
Created attachment 254431 [details] alsa-info output in the non working state after resume
Created attachment 254432 [details] alsa-info output in the non working state after resume
Comment on attachment 254431 [details] alsa-info output in the non working state after resume duplicated alsa-info output.
I've performed the test in run level 3 and got the same results. I'm able to play sound (aplay /usr/share/sounds/alsa/test.wav ) as root. I got sound output as expected. Then I called "powersave -U" to suspend to disk. After the resume - I stayed in run level 3 - I had not been able to get the same sound output from the same shell and with the same command line.
OK, then it's the problem of the driver. The PM isn't supported on this board indeed. It's a missing feature in the upstream drivers. But, don't expect that it'll be fixed for 11.1. Adding PM in the driver level isn't too trivial to be fixed in a day. I could close this as UPSTREAM, but as now try to keep open until you can try alsa-driver-kmp on OBS multimedia:audio:KMP repo.
A preliminary patch is ready for testing. It's found in sound-unstable git tree topic/ca0106-resume branch. git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git For building from a tarball, try the latest unstable snapshot from ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz For installation, do the following: - install the kernel-source.rpm matching to your running kernel - run configure % ./configure --with-debug=full --enable-dynamic-minors - run make % make - install modules as root # make install-modules - restart ALSA # rcalsasound restart Then try the procedure in comment#13.
Oops, the tarball contains a build error. Fixing now...
Fixed.
Any news? You can try the latest KOTD instead of building ALSA drivers manually, too.
Ping.
*** Bug 457988 has been marked as a duplicate of this bug. ***
Installed and tested with 2.6.27.8-HEAD_20081211152932_1d101639-default as available from http://ftp.suse.com/pub/projects/kernel/kotd/SL111_BRANCH/ and ran into the same issue. I'm only able to hear random noise after login to KDE.
Good that we can finally go forward, at least for a couple of days. (BTW, you'd better to use HEAD branch of KOTD at this stage... But, it doesn't matter now since ca0106-pm patch should be in SL111_BRANCH, too.) Now, please build the latest ALSA driver and install manually. This will reduce the time of patch testing a lot. This time, you don't need the unstable but the normal snapshot version: ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-snapshot.tar.gz Install kernel-source.rpm, get the tarball above, extract it, run the below: % ./configure --with-debug=full --enable-dynamic-minors % make then as root # make install-modules and reboot. Confirm that the sound driver is loaded and working as before, then check /proc/asound/version whether it's version 1.0.18a. After confirming this, I'll prepare a test patch tomorrow.
Oh, forgot to ask one more thing... If the latest driver doesn't work, please dump the following files (supposing it's the first card) both before and after suspend (or hibernate) to compare: - /proc/asound/card0/ca0106_* - /proc/asound/card0/iec958 - /proc/asound/card0/codec97#*/* [Note that the proc files can't be copied by tar (handled as zero-size files).] Thanks.
I followed the instructions of comment #27. The sound driver got loaded and /proc/asound/version reports version 1.0.18a. Sound is working after reboot to run level 3. After an init 5 and login to KDE I got the same noise as initially reported. After a "service alsasound restart" I had working sound with KDE too.
Does the problem occur after a fresh *reboot*, not resume? If the sound gets broken even just going to runlevel 5, it's possibly the broken mixer setup via kmix. Run "alsactl -f somefile store" at the first KDE login (where the noise appears) to save the mixer elements. Also run it at the working state ("rcalsasound restore" or whatever) and attach the both files to compare. It'd be helpful to gather the proc files in both working and non-working states as in comment#28, too.
This happens even after a fresh reboot. Requested logs follow soon.
Created attachment 260355 [details] alsactl output in the working state
Created attachment 260356 [details] Partial tar ball of /proc/asound/card0 as requested.
Created attachment 260363 [details] alsactl output in the broken state
Created attachment 260364 [details] Partial tar ball of /proc/asound/card0 as requested (non working state). /proc/asound/card0/codec97#*/* isn't available on this system. Neither in the working, nor the non working state.
And, is it the fresh reboot or resume? codec97#0* might be missing in some boards, so it doesn't matter much.
Sorry I overlooked comment #31. So, the procedure to get a broken state is just do graphical login? This is damn weird. This problem is basically independent from the lack of PM support in the earlier kernel. Now the question is what breaks the sound. Do you see any difference in "aplay -v foo.wav" output between the first runlevel 3 and the broken state (also the re-working state after rcalsasound restart)?
There is no difference between the output of aplay before the reboot (running X/ KDE) and after a (re)boot into runlevel 3. Even to load the nvidia module (to support dual head) doesn't change anything. Aplay works as before. Even switching to run level to 5 (kdm) doesn't change anything. But soon after login I get the random noise. In this state I'm able to play a sound. And it's even possible to hear the sound between the noise. The output written by aplay to stderr is identical to previous two cases (KDE without noise and console in run lvel 3). "service alsasound restart" while still being in KDE "fixes" the noise and everything works as expected.
Thanks for checking. Yes, I've seen that alsactl contents are identical among working and non-working cases (although the registers show a bit difference). So, it's still quite puzzling how this is triggered. One thing you can test easily is whether this happens with X or any action of the sound by KDE. Could you re-login in a failsafe session after "rcalsasound restart", and check whether the noisy output occurs again? Or, what happens if you login freshly into a failsafe mode instead of KDE? I'd like to see the influence of X server over other devices...
Sounds works if I use failsafe mode or use fvwm2 as session type. Sound "fails" while using KDE 3 and 4 (which I used for all previous test cases). With KDE 4 I hear the described noise. With KDE 3 I initially hear nothing. But this is a question of the volume. As soon as increased it's identical to KDE 4.
OK, then some service in KDE (e.g. artsd) triggered this. Could you try the patch below? Apply it on alsa-driver*/alsa-kernel directory with patch -p2 option. This essentially disables 44.1KHz for capture streams.
Created attachment 260534 [details] Disable 44.1kHz capture
After applying it, run "make" and "make install-modules".
BTW, try the very latest alsa-driver-snapshot tarball, too. This contains the recent two patches regarding ca0106, especially your mobo, and I'd like to know that it's not breaking. Thanks.
Very strange. I'm with and without your patch - provided by comment #42 - no longer able to suspend. If I unload ALSA (service alsound stop) suspend to disk works. Might I only have tested the reboot case? Anyhow. With the patch of comment #44 ALSA works immediately after KDE started. No restart of the sound system is required.
The suspend/hibernate is another issue, so let's forget that right now. So if I understand correctly, the previous patch (disable 44.1kHz capture) works for the fresh reboot on KDE, solves the noise output? And, is it with the latest alsa-driver-snapshot tarball?
Also, what do you mean "suspend to disk works"? Does the hibernation hang, or just the sound doesn't come up again, or you get the DMA error at playback, or what?
I've applied the patch on top of the ALSA sources you suggested to use in comment 27. To get suspend working I have to stop ALSA first. Or more correkt I have to ensure the particular kernel module is unloaded before. Else the hibernation hangs.
OK, then something wrong in my suspend patch. Could you try to disable the pm callbacks in alsa-driver*/alsa-kernel/pci/ca0106/ca0106_main.c, such as, ===== diff --git a/sound/pci/ca0106/ca0106_main.c b/sound/pci/ca0106/ca0106_main.c index 5763174..7114030 100644 --- a/sound/pci/ca0106/ca0106_main.c +++ b/sound/pci/ca0106/ca0106_main.c @@ -1811,7 +1811,7 @@ static struct pci_driver driver = { .id_table = snd_ca0106_ids, .probe = snd_ca0106_probe, .remove = __devexit_p(snd_ca0106_remove), -#ifdef CONFIG_PM +#if 0 // def CONFIG_PM .suspend = snd_ca0106_suspend, .resume = snd_ca0106_resume, #endif ===== Check whether the hibernation works, at least, not hangs. Of course, the sound device won't be usable after resume with this change.
Disabled the pm callbacks as suggested in comment #49 and hibernation works. As expected the sound device isn't usable afterwards.
OK, then try to enable only the line ".suspend = snd_ca0106_suspend". Take back #if 0, and simply comment out ".resume = snd_ca0106_resume" line. Does the hibernation still work?
Module modified, rebuild, unload and load and hibernation no longer works. I again see the progress and then the system freezes.
Thanks. I found a patch in the resume code. How about the patch below? Apply it on alsa-driver*/alsa-kernel with patch -p2 option.
Created attachment 261301 [details] Fix PM register save/restore
Have the pm callbacks being enabled or disabled? While they are enabled suspend hangs as described.
Yes, enable both. The question is which call in suspend() causes the hang. First off, could you disable two calls in alsa-driver*/alsa-kernel/pci/ca0106/ca0106_main.c:snd_ca0106_suspend()? +++ b/sound/pci/ca0106/ca0106_main.c @@ -1753,9 +1753,9 @@ static int snd_ca0106_suspend(struct pci_dev *pci, pm_mess for (i = 0; i < 4; i++) snd_pcm_suspend_all(chip->pcm[i]); snd_ac97_suspend(chip->ac97); - snd_ca0106_mixer_suspend(chip); + // snd_ca0106_mixer_suspend(chip); - ca0106_stop_chip(chip); + // ca0106_stop_chip(chip); pci_disable_device(pci); pci_save_state(pci); @@ -1782,7 +1782,7 @@ static int snd_ca0106_resume(struct pci_dev *pci) ca0106_init_chip(chip, 1); snd_ac97_resume(chip->ac97); - snd_ca0106_mixer_resume(chip); + // snd_ca0106_mixer_resume(chip); if (chip->details->spi_dac) { for (i = 0; i < ARRAY_SIZE(chip->spi_dac_reg); i++) snd_ca0106_spi_write(chip, chip->spi_dac_reg[i]); BTW, this is against the latest alsa-driver-snapshot. It already includes the patch in comment#54.
Downloaded the current snapshot (19. Dez 15:01) and applied the three changes of comment #56 to disable the three calls. A suspend request leads to the described system freeze.
Hmm, then try to disable the resume callback first (comment out .resume = snd_ca0106_resume line), then try to disable the further calls, e.g. snd_pcm_suspend_all() and snd_ac97_suspend(). Now there should be only calls of snd_power_change_state(), pci_disable_device(), pci_save_state() and pci_set_power_state(). If the hibernation still hangs up, then it's a deeper problem than the sound driver itself. If it doesn't hang, then the newly commented stuff is the culprit...
If I disable the following calls s2disk works again. I tried to activate the function calls in reverse order. As soon as snd_ac97_suspend() is called again we see the same issue again. Index: alsa-driver/alsa-kernel/pci/ca0106/ca0106_main.c =================================================================== --- alsa-driver.orig/alsa-kernel/pci/ca0106/ca0106_main.c +++ alsa-driver/alsa-kernel/pci/ca0106/ca0106_main.c @@ -1750,9 +1750,9 @@ static int snd_ca0106_suspend(struct pci int i; snd_power_change_state(card, SNDRV_CTL_POWER_D3hot); - for (i = 0; i < 4; i++) - snd_pcm_suspend_all(chip->pcm[i]); - snd_ac97_suspend(chip->ac97); + // for (i = 0; i < 4; i++) + // snd_pcm_suspend_all(chip->pcm[i]); + // snd_ac97_suspend(chip->ac97); // snd_ca0106_mixer_suspend(chip); // ca0106_stop_chip(chip); @@ -1808,7 +1808,7 @@ static struct pci_driver driver = { .remove = __devexit_p(snd_ca0106_remove), #ifdef CONFIG_PM .suspend = snd_ca0106_suspend, - .resume = snd_ca0106_resume, + // .resume = snd_ca0106_resume, #endif
Thanks for checking. I think I found the culprit. Could you try the very latest alsa-driver-snapshot tarball? This contains the necessary fixes, and may work as is without patches.
ALSA works after hibernation. I've tested it with the alsa-driver-snapshot.tar.gz from 20. Dez 23:05.
Good to hear. Both fixes are already in SUSE kernel git tree now.
Update released for: kernel-debug, kernel-debug-base, kernel-debug-debuginfo, kernel-debug-debugsource, kernel-debug-extra, kernel-default, kernel-default-base, kernel-default-debuginfo, kernel-default-debugsource, kernel-default-extra, kernel-docs, kernel-kdump, kernel-kdump-debuginfo, kernel-kdump-debugsource, kernel-pae, kernel-pae-base, kernel-pae-extra, kernel-ppc64, kernel-ppc64-base, kernel-ppc64-debuginfo, kernel-ppc64-debugsource, kernel-ppc64-extra, kernel-ps3, kernel-ps3-debuginfo, kernel-ps3-debugsource, kernel-source, kernel-source-debuginfo, kernel-syms, kernel-trace, kernel-trace-base, kernel-trace-debuginfo, kernel-trace-debugsource, kernel-trace-extra, kernel-vanilla, kernel-vanilla-debuginfo, kernel-vanilla-debugsource, kernel-xen, kernel-xen-base, kernel-xen-debuginfo, kernel-xen-debugsource, kernel-xen-extra Products: openSUSE 11.1 (debug, i586, ppc, x86_64)