Bug 489048 - HAL first sends out DeviceAdded and then fixes ACLS. Should be the other way round.
HAL first sends out DeviceAdded and then fixes ACLS. Should be the other way ...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
: 491706 493775 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-06 17:20 EST by Michael Monreal
Modified: 2010-06-28 07:24 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 07:24:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Log1: working (29.07 KB, text/plain)
2009-03-13 10:46 EDT, Michael Monreal
no flags Details
Log2: fail, then work on 2nd try (29.51 KB, text/plain)
2009-03-13 10:47 EDT, Michael Monreal
no flags Details
strace of 'pulseaudio -v' before changing persmissions of /dev/snd/* (166.46 KB, application/octet-stream)
2009-07-11 09:41 EDT, Vladimir Ivanovic
no flags Details
strace of 'pulseaudio -v' after changing persmissions of /dev/snd/* (361.42 KB, application/octet-stream)
2009-07-11 09:43 EDT, Vladimir Ivanovic
no flags Details

  None (edit)
Description Michael Monreal 2009-03-06 17:20:02 EST
If I plug in my usb headset when the Sound Preferences window is not open, I cannot use it. If I open the Sound Preferences, no new device has shown up.

On the other hand, if I open Sound Preferences and then plug in the usb headset, the new in/out devices show up an I can chose them.
Comment 1 Bastien Nocera 2009-03-09 05:50:17 EDT
That doesn't make a lot of sense.

Do you see the device being found in the gnome-volume-control logs? Does pulseaudio show that the new device was added when you plug it in?
Comment 2 Michael Monreal 2009-03-10 09:26:14 EDT
Hard for me to see a pattern as well... my impression was that sometimes the detection of newly connected hardware takes a bit longer and if you open the preferences before the detection is done, the device will not show up. But maybe it's just that sometimes PulseAudio (or something else) just doesn't detect the device correctly? Also, if the device does not show up, disconnecting/reconnecting does not help, it will only show up if the volume applet is restarted it seems.
Comment 3 Bastien Nocera 2009-03-12 10:07:15 EDT
Could you please get actual debug output from pulseaudio and gnome-volume-control when reproducing the problem?

If the device fails to show up, also check your kernel logs (in dmesg), and lshal whether the device showed up lower down the levels.

For pulseaudio:
pulseaudio -k ; pulseaudio --log-level=3
For gnome-volume-control:
gnome-volume-control --debug

Thanks.
Comment 4 Michael Monreal 2009-03-13 10:45:31 EDT
Ok this is weird. I was so sure this was related to the volume applet/mixer somehow but looks like you're right and it's further down the stack.

I'm not sure if this is a DBus/HAL/Pulse/other bug though. I'm going to attach two logs. Once where it worked totally fine after boot, and one where the headset was only detected after unpluggung and replugging. Feel free to re-assign or tell me where to file a new bug for this... thanks.
Comment 5 Michael Monreal 2009-03-13 10:46:31 EDT
Created attachment 335097 [details]
Log1: working
Comment 6 Michael Monreal 2009-03-13 10:47:10 EDT
Created attachment 335098 [details]
Log2: fail, then work on 2nd try
Comment 7 Bastien Nocera 2009-03-13 21:54:42 EDT
Looks like pulseaudio is suspending the device.
Comment 8 Lennart Poettering 2009-03-19 08:09:58 EDT
Nah, this is unrelated to suspending.

The interesting part is the "E: module-alsa-card.c: Card '1' doesn't exist: Permission denied"

Apparently HAL tells us that there is a new device before actually adjusting the ACLs on the device file. This is a race in HAL and needs to be fixed there.
Comment 9 Richard Hughes 2009-03-20 08:00:27 EDT
I'm not sure HAL has any guarantee that ACL's are set before announcing the device add. David?
Comment 10 Richard Hughes 2009-03-20 08:01:07 EDT
I'm not sure HAL has any guarantee that ACL's are set before announcing the device add. David?
Comment 11 Lennart Poettering 2009-03-24 15:15:02 EDT
It's actually not about the DeviceAdded signal. When that fails PA is fine with that. However the ACLAdded signal matters. When that signal is triggered PA will try again and expects ACLs to be set up properly. And obviously it would be a bug in HAL if it would send this out without having adjusted the ACLs?

Maybe the bug here is actually that HAL does not send out the ACLAdded signal at all?
Comment 12 Lennart Poettering 2009-03-24 15:19:06 EDT
Let me rephrase this: PA looks for both the ACLAdded and the DeviceAdded signal. On either one it will try to reopen the device. If one of them fails due to permission problems then hopefully the other one works.
Comment 13 Lennart Poettering 2009-03-24 15:19:19 EDT
*** Bug 491706 has been marked as a duplicate of this bug. ***
Comment 14 Lennart Poettering 2009-04-05 09:00:39 EDT
As it seems when a new device is plugged in HAL will (at least sometimes) send out DeviceAdded and only then fix up the ACLs. And it won't send ACLAdded for that device afterwards. So clients have no clue when the device is actually usable.

HAL should not send DeviceAdded before ACLs are properly set up.

/me is tempted to raise this to a blocker bug.
Comment 15 Lennart Poettering 2009-04-10 10:44:20 EDT
*** Bug 493775 has been marked as a duplicate of this bug. ***
Comment 16 Chris Shoemaker 2009-05-28 15:06:51 EDT
Is there a work-around for this bug, so I can get sound in F11?  Should I restart pulseaudio whenever a new device is inserted?
Comment 17 Chris Shoemaker 2009-05-28 21:09:13 EDT
It seems like the other dups of this bug were USB devices, but I see this with
my built-in snd_hda_intel on a Dell Precision M4400:

I: main.c: Running in system mode: yes
I: main.c: Fresh high-resolution timers available! Bon appetit!
D: rtclock.c: Timer slack is set to 50 us.
D: memblock.c: Using private memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65472
D: cli-command.c: Checking for existance of '/usr/lib64/pulse-0.9.15/modules/module-hal-detect.so': success
D: dbus-util.c: Successfully connected to D-Bus system bus 02ab72393ece651a05ef16244a1f31ca as :1.94
D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/computer_alsa_timer
D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_8086_293e_sound_card_0_alsa_playback_0
D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_8086_293e_sound_card_0_alsa_capture_0
D: module-hal-detect.c: Not loaded device /org/freedesktop/Hal/devices/pci_8086_293e_sound_card_0_alsa_hw_specific_0
D: module-hal-detect.c: Loading module-alsa-card with arguments 'device_id=0 name=pci_8086_293e_sound_card_0 card_name=alsa_card.pci_8086_293e_sound_card_0 tsched=1'
E: module-alsa-card.c: Card '0' doesn't exist: Permission denied
E: module.c: Failed to load  module "module-alsa-card" (argument: "device_id=0 name=pci_8086_293e_sound_card_0 card_name=alsa_card.pci_8086_293e_sound_card_0 tsched=1"): initialization failed.
Comment 18 Bug Zapper 2009-06-09 07:58:00 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Sergio Monteiro Basto 2009-07-04 04:43:11 EDT
(In reply to comment #17)
> It seems like the other dups of this bug were USB devices, but I see this with
> my built-in snd_hda_intel on a Dell Precision M4400:

> E: module-alsa-card.c: Card '0' doesn't exist: Permission denied
> E: module.c: Failed to load  module "module-alsa-card" (argument: "device_id=0
> name=pci_8086_293e_sound_card_0 card_name=alsa_card.pci_8086_293e_sound_card_0
> tsched=1"): initialization failed.  

I got on my built-in snd_hda_intel:
lsmod | grep intel
snd_intel8x0           27412  3
snd_intel8x0m          12892  5
snd_ac97_codec         91488  2 snd_intel8x0,snd_intel8x0m
snd_pcm                62476  5 snd_intel8x0,snd_intel8x0m,snd_ac97_codec
snd                    48764  19 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm,snd_timer
snd_page_alloc          7592  3 snd_intel8x0,snd_intel8x0m,snd_pcm

Jul  4 09:37:00 segulix pulseaudio[2433]: module-alsa-card.c: Failed to find a working profile.
Jul  4 09:37:00 segulix pulseaudio[2433]: module.c: Failed to load  module "module-alsa-card" (argument: "device_id=1 name=pci_8086_266d_sound_card_0 card_name=alsa_card.pci_8086_266d_sound_card_0 tsched=1"): initialization failed.
Comment 20 Vladimir Ivanovic 2009-07-11 09:38:11 EDT
I had to

 # chmod 666 /dev/snd/*

to get sound to work. I still get the

  E: polkit.c: Cannot set UID on session object.

error.

I am attaching two files:

  1. Output of 'strace -fFo /tmp/pulseaudio.log pulseaudio -v' followed by 'pulseaudio -k' before changing the permissions of /dev/snd/*.
  2. Output of the same two commands after changing the permissions of /dev/snd/*.
Comment 21 Vladimir Ivanovic 2009-07-11 09:41:25 EDT
Created attachment 351343 [details]
strace of 'pulseaudio -v' before changing persmissions of /dev/snd/*
Comment 22 Vladimir Ivanovic 2009-07-11 09:43:15 EDT
Created attachment 351344 [details]
strace of 'pulseaudio -v' after changing persmissions of /dev/snd/*
Comment 23 Vladimir Ivanovic 2009-07-11 09:54:18 EDT
(In reply to comment #20)
> I had to
> 
>  # chmod 666 /dev/snd/*
> 
> to get sound to work. I still get the
> 
>   E: polkit.c: Cannot set UID on session object.
> 
> error.
> 
> I am attaching two files:
> 
>   1. Output of 'strace -fFo /tmp/pulseaudio.log pulseaudio -v' followed by
> 'pulseaudio -k' before changing the permissions of /dev/snd/*.
>   2. Output of the same two commands after changing the permissions of
> /dev/snd/*.  

I forgot to mention that I had added myself (unprivileged) to audio, pulse-rt and pulse-access before running these commands. As expected, removing myself from these groups did not prevent sound from working after I changed the permissions on /dev/snd*.
Comment 24 Sergio Monteiro Basto 2009-07-12 11:41:04 EDT
(In reply to comment #19)
I forgot tell that I always have SELinux disable.

SELinux:  Disabled at runtime.
SELinux:  Unregistering netfilter hooks
Comment 25 Bill McGonigle 2009-07-16 22:04:24 EDT
(In reply to comment #14)
> As it seems when a new device is plugged in HAL will (at least sometimes) send
> out DeviceAdded and only then fix up the ACLs. And it won't send ACLAdded for
> that device afterwards. So clients have no clue when the device is actually
> usable.
> 
> HAL should not send DeviceAdded before ACLs are properly set up.
> 
> /me is tempted to raise this to a blocker bug.  

I attempted to chase this for a little while before I realized I was in too deep, but, if I understand what I saw, it looks like ACL's are set with a call to hal-acl-tool as a 'callout' by hald.  What I wasn't able to figure out was if the callout runner waits for the callout process completion.  If not, that could potentially cause your race.

Should this be raised upstream?
Comment 26 Bug Zapper 2010-04-27 09:07:31 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  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 '11'.

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 11'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 11 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 27 Bug Zapper 2010-06-28 07:24:39 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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