From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755637AbZHEFhb (ORCPT ); Wed, 5 Aug 2009 01:37:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753508AbZHEFhb (ORCPT ); Wed, 5 Aug 2009 01:37:31 -0400 Received: from cantor.suse.de ([195.135.220.2]:51251 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753747AbZHEFha (ORCPT ); Wed, 5 Aug 2009 01:37:30 -0400 Date: Wed, 05 Aug 2009 07:37:30 +0200 Message-ID: From: Takashi Iwai To: Denys Vlasenko Cc: linux-kernel@vger.kernel.org Subject: Re: sound: -EPERM on first mplayer invocation In-Reply-To: <200908050432.35016.vda.linux@googlemail.com> References: <200908022336.48898.vda.linux@googlemail.com> <200908041101.43252.vda.linux@googlemail.com> <200908050432.35016.vda.linux@googlemail.com> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.3 (x86_64-suse-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Wed, 5 Aug 2009 04:32:34 +0200, Denys Vlasenko wrote: > > On Tuesday 04 August 2009 11:16, Takashi Iwai wrote: > > > > > For a long time I observe the following nuisance: > > > > > when I run mplayer for the very first time after boot, > > > > > I can't adjust the volume. mplayer spews this to stderr: > > > > > > > > > > alsa-control: error setting left channel, Operation not permitted > > > > > > > > > > This happens even if I login as root and run mplayer as root. > > > > > > > > > > I tracked it down to snd_ctl_elem_write in sound/core/control.c > > > > > > > > ... > > > > > > > > > > Thus, vd->owner != file. > > > > > > > > > > As I said, it only happens on very first run of mplayer, > > > > > and it isn't a recent change, I think I saw it at least > > > > > for one year with different kernels. > > > > > > > > > > Takashi, any idea what might be happening here? > > > > > How can I help you more with tracking it down? > > > > > > > > This implies that another process (e.g. a sound daemon like PA) > > > > already opened the device and locked this specific control element. > > > > If so, this is no bug but the right behavior. > > > > Check "fuser /dev/snd/controlC*". > > > > > > Nothing uses them: > > > > > > shadow:~# lsof -nP | grep '/dev/.*control' > > > shadow:~# fuser /dev/snd/controlC* > > > shadow:~# > > > > > > I tried running bare X with only xterm and mplayer, > > > > Hm, but according to your debug session, the vd->owner is set > > to a different value, right? Check vd->owner_pid in the error path. > > It'll show the pid blocking that control element. > > I modified 2.6.31-rc2 source as follows: > > static int snd_ctl_elem_write(struct snd_card *card, struct snd_ctl_file *file, > struct snd_ctl_elem_value *control) > { > struct snd_kcontrol *kctl; > struct snd_kcontrol_volatile *vd; > unsigned int index_offset; > int result; > > down_read(&card->controls_rwsem); > kctl = snd_ctl_find_id(card, &control->id); > if (kctl == NULL) { > result = -ENOENT; > } else { > index_offset = snd_ctl_get_ioff(kctl, &control->id); > vd = &kctl->vd[index_offset]; > if (file && vd->owner) > printk("file:%p vd->owner:%p\n", file, vd->owner); > if (!(vd->access & SNDRV_CTL_ELEM_ACCESS_WRITE) || > kctl->put == NULL || > (file && vd->owner && vd->owner != file)) { > if (file && vd->owner) > printk("vd->owner_pid:%d vd->owner->pid:%d file->pid:%d\n", vd->owner_pid, vd->owner->pid, file->pid); > result = -EPERM; > } else { > ... > > and when I start mplayer, I see this: > > dmesg: > file:ffff8800798af940 vd->owner:ffff8800798af940 > file:ffff8800798af940 vd->owner:ffff8800798af940 > > I assume it's some sort of initialization, no EPERM here. > Then I press "lower the volume" key (keypad "/") > in mplayer window, twice: > > dmesg: > file:ffff8800798af8c0 vd->owner:ffff8800798af940 > vd->owner_pid:0 vd->owner->pid:2067 file->pid:2067 > file:ffff8800798af740 vd->owner:ffff8800798af940 > vd->owner_pid:0 vd->owner->pid:2067 file->pid:2067 The file instances are different. It implies that mplayer opens the device at each time but doesn't close. It sounds like a bug in mplayer to me. Takashi