Thanks! This confirms my theory that the bug is in the kernel. I think
that the dmasound module which you are using as your sound driver contains
uninitialised static variables, which are supposed to contain 0 initially
but in fact contain rubbish - in your case it happens to be -1, which is
an invalid value and causes malfunction of the driver (-1 = -EPERM).
I'm reassigning this bug to kernel-image-2.6.10-powerpc until proven
wrong. Below is my analysis and a suggestion how to fix it. I just don't
have a powerpc machine to test it myself. You may also find that using
ALSA rather than OSS driver will probably not exhibit this problem.
On Friday, 11 Mar, Vincent Lefevre wrote:
>
> Here's what I got when I hadn't changed the microphone value:
>
> open("/dev/mixer", O_RDWR) = 9
> ...
> ioctl(9, 0x40044d07, 0x7ffff03c) = -1 EPERM (Operation not permitted)
First time it barfed on reading the value of mixer element 7 - microphone
(SOUND_MIXER_READ_MIC ioctl).
> And after using gnome-volume-control:
>
> open("/dev/mixer", O_RDWR) = 9
> ...
> ioctl(9, 0x40044d07, 0x7ffff03c) = 0
> ioctl(9, 0xc0044d07, 0x7fffef00) = 0
> ...
> ioctl(9, 0x40044d0c, 0x7ffff03c) = 0
> ioctl(9, 0xc0044d0c, 0x7fffef00) = -1 EPERM (Operation not permitted)
After microphone volume had been changed with gnome-volume-control,
SOUND_MIXER_READ_MIC went fine, but we got EPERM at element 12 - input
gain.
Looking at sound/oss/dmasound/dmasound_awacs.c, lines 1989 and 1982, we
can see that the variables responsible are mic_lev and ip_gain. In lines
178-182, mic_lev and ip_gain can be seen as two of the uninitialised
static variables.
When IOCTL_OUT is passed a negative value, it treats it as error code and
returns it intact instead of storing it in the user-provided location.
Thus, when mic_lev and ip_gain contain the invalid value -1 due to their
non-initialisation, it is returned as error code EPERM from the ioctl.
Once mic_lev has been assigned a valid value by gnome-volume-control, it
no longer causes this error condition.
I suggest that identifying all uninitialised static variables in the
dmasound directory and explicitly initialising them with 0 should fix this
problem.
Note that I was surprised to learn that bss is not zeroed out when a
module is loaded, thus breaking the convention that all non-initialised
statics automatically initialise to 0. But it appears to be so.
Nikita
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
