Description of problem: I'm not sure it belongs really here, but I could not imagine a better place... When modprobe loads a module, which will cause devices creation, it returns before the devices are all created. If some "install" directive is present, in some modprobe configuration files (/etc/modprobe.conf or inside /etc/modprobe.d), it could fail. On the other hand, insmod does not consider /etc/modprobe.d/ files at all. Version-Release number of selected component (if applicable): 3.3-0.pre1.4.17 How reproducible: Statistically, since it's a race condition. On my system (P-III 1400MHz with 512MB ram) almost always with the sound card driver (snd-ens1370). Steps to Reproduce: 1. There is a file in /etc/modprobe.d/ called ens1370, which restore the mixer defaults, using alsactl, when snd-ens1370 is loaded: install snd-ens1370 /sbin/modprobe --first-time --ignore-install snd-ens1370 && { /sbin/alsactl restore >/dev/null 2>&1 || :; } remove snd-ens1370 { /sbin/alsactl store >/dev/null 2>&1 || :; } ; /sbin/modprobe -r --first-time --ignore-remove snd-ens1370 2. Remove the >/dev/null redirections and type something like: rmmod snd-ens1370; modprobe snd-ens1370 3. Adding some sleep (or better, see below), result in a proper alsactl operation. But, on reboot this does not work, because: rmmod snd-ens1370; insmod /lib/modules/.../snd-ens1370.ko does not consider the /etc/modprobe.d/ at all. In fact adding some "echo" does not show up with the insmod, while it show up with modprobe. I suspect something (udev?) is using insmod on boot with the consequence of not executing the "install" directive of /etc/modprobe.d/ens1370 Actual results: Very often results in an error like: "soundcard not found" from alsactl, when using modprobe, nothing at all when using insmod. Expected results: The "install" directive of the configuration file should take place. Additional info: To avoid the race condition, the configuration file is now: install snd-ens1370 /sbin/modprobe --first-time --ignore-install snd-ens1370 && { until test -c /dev/tty; do sleep 0; done; /sbin/alsactl restore >/dev/null 2>&1 || :; } remove snd-ens1370 { /sbin/alsactl store >/dev/null 2>&1 || :; } ; /sbin/modprobe -r --first-time --ignore-remove snd-ens1370 Which waits until the control file is present, then it goes ahead with alsactl. While this is not really optimal, it works with modprobe, but, as said above, not with insmod.
I don't like this solution - I much prefer having udev rules handle this stuff. m-i-t isn't really supposed to be doing any of this :-) Jon.
/etc/udev/rules.d/90-alsa.rules call /sbin/salsa, which restores the volume
s/volume/mixer settings/
(In reply to comment #2) > /etc/udev/rules.d/90-alsa.rules call /sbin/salsa, which restores the volume I'm very sorry to inform you that it does not work... :-) Well, basically it seems that "/sbin/salsa", which is the command in "/etc/udev/rules.d/90-alsa.rules", does nothing, while "/sbin/salsa -l" loads the audio card settings. At least this is what happens in my machine, I have to run it with "-l" to have all the settings loaded. Specifically, it seems that the PCM volume is not loaded without "-l". I guess a simple patch, adding the "-l" to the udev rule of alsa-utils (which is the owner) should fix this for good. So I re-open the bug and assign to "alsa-utils" of F7 (since it appears also there). Sorry for any confusion.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I was unsure about this one, so I changed the fedora version and the summary, I hope it is not a problem. The issue is that the udev rule for alsa, i.e. /etc/udev/rules.d/90-alsa.rules, does call /sbin/salsa, I guess to load the previous saved settings, without any parameter. In order to load the settings "-l" is required, without it /sbin/salsa seems not to do anything. On the other hand, it does seem that some parameters are anyway loaded, but this could happen within gnome, maybe pulseaudio or something else, so the problem might not be so visible. Hope this helps. piergiorgio
The "-l" parameter loads the volume settings for all souncards. If salsa is run w/o parameters it expects udev sets the proper env variables and tries to determine which soundcard is initialized. But there could be a problem with the card order (especially when the sound config is driven by PA).
Can you try to run "alsaunmute" when your box is booted with disabled audio? Does the alsaunmute utility enable sound for you?
Some additional side notes. I upgraded to F9, so I'll have to re-test in order to see if the problem is still there. You mention "env variables", but the man page of "salsa" does not say anything about those nor the man page of "alsactl", maybe some clarification will be needed also there. I'll try "alsaunmute" as soon as possible. Thanks. pg
Test on F9 is fine. Leave it in needinfo until you do the alsaunmute test, please.
(In reply to comment #10) > Test on F9 is fine. Leave it in needinfo until you do the alsaunmute test, please. Sorry for that, but I did not change the status nor checked the box, it went away by itself (so, let's see if it happens again). Going back to the topic, I tested a different PC, with F9, and there the volume was restored correctly, it seems. I'll test again on the other 2 (different) PCs (again with F9) and if I'll not be able to reproduce the problem, I'll close the issue. If the problem is still there, then I'll test "alsaunmute". pg
You see? It changed from "NEEDINFO" to "ASSIGNED" without any touch from my side. Maybe a bugzilla problem? I'll revert to "NEEDINFO"... pg
Okay, thanks. Btw. If the alsaunmute doesn't work correctly (i.e. there's still any channel what needs to be enabled/raised manually, please attach output of "amixer -c N" where N is a card number (0 for the first one and so on) and write down the channel name)
OK, so I ran another test, this time with some more "thinking". The setting I gave to the volume, using gnome-volume-control, is more or less: master: ~50% pcm and others: ~75% some are disabled. After a fresh boot, master is set to 75%... "salsa -l", from command line, brings it back to 50%. So it seems that the "unmuting" is "defaulting" to 75%... If I run, from root command line, "alsaunmute" I get the following: alsaunmute *** PULSEAUDIO: Unable to connect: Connection refused *** Is your sound server running? *** See: http://www.pulseaudio.org/wiki/Troubleshooting Open error: Connection refused And the master volume is set to 75%. Playing around with gnome-volume-control shows that all the output volumes (except the PC speaker) are set to 75%, when "alsaunmute" is called. "salsa -l", instead, loads, as expected, the saved settings. I'll attach the output of "amixer -c 0" pg
Created attachment 308551 [details] output of "amixer -c 0" lspci -vv output for the audio section: 00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2) Subsystem: ASUSTeK Computer Inc. Unknown device 81cb Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22 Memory at fe024000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/0 Enable- Capabilities: [6c] HyperTransport: MSI Mapping Enable+ Fixed+ Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel
Forgot, the output of "amixe -c 0" was after "salsa -l". pg
Other news. If I run "alsaunmute" as logged in user, I just get the volume set to 75%, without the error about the server. pg
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Changed to F9, since the last reports refer to this version. pg
I noticed that F10 removes the call to "salsa", in /udev/rules.d/90-alsa..., with a direct "alsactl" call. This seems to avoid the issue in F10, maybe a backport could be wise. Thanks, pg
Since I upgraded all the PCs to F10 and the issue does not seem to exist anymore, I close it. pg