Bug 238044 - /etc/udev/rules.d/90-alsa.rules calls /sbin/salsa without parameter
/etc/udev/rules.d/90-alsa.rules calls /sbin/salsa without parameter
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: alsa-utils (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jaroslav Kysela
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-26 14:15 EDT by Piergiorgio Sartor
Modified: 2009-01-13 12:13 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-13 12:13:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of "amixer -c 0" (4.74 KB, text/plain)
2008-06-06 13:39 EDT, Piergiorgio Sartor
no flags Details

  None (edit)
Description Piergiorgio Sartor 2007-04-26 14:15:30 EDT
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.
Comment 1 Jon Masters 2007-08-20 03:24:51 EDT
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.
Comment 2 Harald Hoyer 2007-08-20 05:49:08 EDT
 /etc/udev/rules.d/90-alsa.rules call /sbin/salsa, which restores the volume
Comment 3 Harald Hoyer 2007-08-20 05:49:41 EDT
s/volume/mixer settings/
Comment 4 Piergiorgio Sartor 2007-08-20 13:28:45 EDT
(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.
Comment 5 Bug Zapper 2008-05-14 08:13:14 EDT
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
Comment 6 Piergiorgio Sartor 2008-05-14 17:00:07 EDT
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
Comment 7 Martin Stransky 2008-06-02 06:34:44 EDT
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).
Comment 8 Martin Stransky 2008-06-02 06:38:04 EDT
Can you try to run "alsaunmute" when your box is booted with disabled audio?
Does the alsaunmute utility enable sound for you?
Comment 9 Piergiorgio Sartor 2008-06-04 03:42:20 EDT
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
Comment 10 Martin Stransky 2008-06-04 03:57:30 EDT
Test on F9 is fine. Leave it in needinfo until you do the alsaunmute test, please.
Comment 11 Piergiorgio Sartor 2008-06-05 04:40:37 EDT
(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
Comment 12 Piergiorgio Sartor 2008-06-05 04:46:24 EDT
You see?
It changed from "NEEDINFO" to "ASSIGNED" without any touch from my side.
Maybe a bugzilla problem?

I'll revert to "NEEDINFO"...

pg
Comment 13 Martin Stransky 2008-06-06 11:18:34 EDT
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)
Comment 14 Piergiorgio Sartor 2008-06-06 13:37:51 EDT
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
Comment 15 Piergiorgio Sartor 2008-06-06 13:39:58 EDT
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
Comment 16 Piergiorgio Sartor 2008-06-06 13:52:00 EDT
Forgot, the output of "amixe -c 0" was after "salsa -l".

pg
Comment 17 Piergiorgio Sartor 2008-06-06 14:05:34 EDT
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
Comment 18 Bug Zapper 2008-11-26 02:14:26 EST
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
Comment 19 Piergiorgio Sartor 2008-11-26 14:01:31 EST
Changed to F9, since the last reports refer to this version.

pg
Comment 20 Piergiorgio Sartor 2008-12-03 10:38:33 EST
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
Comment 21 Piergiorgio Sartor 2009-01-13 12:13:16 EST
Since I upgraded all the PCs to F10 and the issue does not seem to exist anymore, I close it.

pg

Note You need to log in before you can comment on or make changes to this bug.