Inappropriate ioctl for device on alsalib with uclibc and arm platform

Inappropriate ioctl for device on alsalib with uclibc and arm platform

[Federico Fuga]

Hi,

Maybe I am a little bit off-topic here, but I think this question may be related with a bug (maybe not in the alsa library, but I am a little confused now), so I apologize in advance.
I am building a uclibc-based system on arm board.
I have compiled the library 1.0.14a with uClibc 0.9.29 and kernel
2.6.23.1 / kernel headers 2.6.22.
Settings the config params of mixer with "alsactl restore" fails with
an "inappropriate ioctl for device" error:

# alsactl restore
alsactl: set_control:1159: Cannot write control '2:0:0:Speaker Playback
Volume:0' : Inappropriate ioctl for device

while traceing with strace I see that:

open("/usr/lib/libasound.so.2", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0755, st_size=716844, ...}) = 0
close(4)                                = 0
open("/dev/snd/controlC0", O_RDONLY)    = 4
close(4)                                = 0
open("/dev/snd/controlC0", O_RDWR)      = 4
ioctl(4, USBDEVFS_CONTROL, 0xbeab09ec)  = 0
ioctl(4, UI_DEV_CREATE, 0xbeab0ad0)     = 0
ioctl(4, USBDEVFS_CONNECTINFO, 0xbeab0654) = 0
ioctl(4, USBDEVFS_HUB_PORTINFO, 0xbeab0768) = -1 ENOTTY (Inappropriate
ioctl for device)
write(2, "alsactl", 7alsactl)                  = 7


but aplay see all the board and seems to work properly:

# aplay  -l
**** List of PLAYBACK Hardware Devices ****
card 0: EMX270 [EM-X270], device 0: AC97 HiFi AC97 HiFi-AC97-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: EMX270 [EM-X270], device 1: AC97 Aux AC97 Aux-AC97-1 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
# aplay -L
default:CARD=EMX270
    EM-X270,
    Default Audio Device
null
    Discard all samples (playback) or generate zero samples (capture)
# speaker-test

speaker-test 1.0.14

Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 8 to 32768
Period size range from 8 to 2040
Using max buffer size 32768
Periods = 4
was set period_size = 1024
was set buffer_size = 32768
 0 - Front Left
Time per period = 2.528627
 0 - Front Left
Time per period = 2.999174

But I hear no sound (the levels are all off).
In a similar installation based on glibc (Armstrong linux) with the same
version of kernel, alsa and all other stuff works correctly.

root@em-x270:~$ cat /proc/asound/devices
  0: [ 0]   : control
 16: [ 0- 0]: digital audio playback
 17: [ 0- 1]: digital audio playback
 24: [ 0- 0]: digital audio capture
 33:        : timer


The device nodes in /dev/sound are created by udev, and major/minor codes and permissions seems ok.
Can you give me some hint on how to solve this issue?

Thank you in advance

ing. Federico Fuga

Re: Inappropriate ioctl for device on alsalib with uclibc and arm platform

[Takashi Iwai]

At Mon, 19 Nov 2007 16:21:39 +0100,
Federico Fuga wrote:
> 
> Hi,
> 
> Maybe I am a little bit off-topic here, but I think this question may be related with a bug (maybe not in the alsa library, but I am a little confused now), so I apologize in advance.
> I am building a uclibc-based system on arm board.
> I have compiled the library 1.0.14a with uClibc 0.9.29 and kernel
> 2.6.23.1 / kernel headers 2.6.22.
> Settings the config params of mixer with "alsactl restore" fails with
> an "inappropriate ioctl for device" error:
> 
> # alsactl restore
> alsactl: set_control:1159: Cannot write control '2:0:0:Speaker Playback
> Volume:0' : Inappropriate ioctl for device
> 
> while traceing with strace I see that:
> 
> open("/usr/lib/libasound.so.2", O_RDONLY) = 4
> fstat(4, {st_mode=S_IFREG|0755, st_size=716844, ...}) = 0
> close(4)                                = 0
> open("/dev/snd/controlC0", O_RDONLY)    = 4
> close(4)                                = 0
> open("/dev/snd/controlC0", O_RDWR)      = 4
> ioctl(4, USBDEVFS_CONTROL, 0xbeab09ec)  = 0
> ioctl(4, UI_DEV_CREATE, 0xbeab0ad0)     = 0
> ioctl(4, USBDEVFS_CONNECTINFO, 0xbeab0654) = 0
> ioctl(4, USBDEVFS_HUB_PORTINFO, 0xbeab0768) = -1 ENOTTY (Inappropriate

Looks like the definition of SNDRV_CTL_ICOTL_ELEM_WRITE doesn't match
with the user-space and the kernel, most likely the size of struct
snd_ctl_elem_value.  This might be a word alignment issue.


Takashi

Re: Inappropriate ioctl for device on alsalib with uclibc and arm platform

[Federico Fuga]

Takashi Iwai ha scritto:
> At Mon, 19 Nov 2007 16:21:39 +0100,
> Federico Fuga wrote:
> # alsactl restore
> alsactl: set_control:1159: Cannot write control '2:0:0:Speaker Playback
> Volume:0' : Inappropriate ioctl for device
>
> while traceing with strace I see that:
>
> open("/usr/lib/libasound.so.2", O_RDONLY) = 4
> fstat(4, {st_mode=S_IFREG|0755, st_size=716844, ...}) = 0
> close(4)                                = 0
> open("/dev/snd/controlC0", O_RDONLY)    = 4
> close(4)                                = 0
> open("/dev/snd/controlC0", O_RDWR)      = 4
> ioctl(4, USBDEVFS_CONTROL, 0xbeab09ec)  = 0
> ioctl(4, UI_DEV_CREATE, 0xbeab0ad0)     = 0
> ioctl(4, USBDEVFS_CONNECTINFO, 0xbeab0654) = 0
> ioctl(4, USBDEVFS_HUB_PORTINFO, 0xbeab0768) = -1 ENOTTY (Inappropriate
>   
>
> Looks like the definition of SNDRV_CTL_ICOTL_ELEM_WRITE doesn't match
> with the user-space and the kernel, most likely the size of struct
> snd_ctl_elem_value.  This might be a word alignment issue.
>
>   

Hi Takashi,

thank you for your response. I have tracked the problem to the kernel
space and found exactly what you say (structure size). I didn't think
about word alignment, I will try by changeing the gcc options.
Do you think I should look at the cross compiler or at the parameters
passed to gcc while compiling the alsa library?
Thank you very much.

Federico

Re: Inappropriate ioctl for device on alsalib with uclibc and arm platform

[Takashi Iwai]

At Tue, 20 Nov 2007 17:51:22 +0100,
Federico Fuga wrote:
> 
> Takashi Iwai ha scritto:
> > At Mon, 19 Nov 2007 16:21:39 +0100,
> > Federico Fuga wrote:
> > # alsactl restore
> > alsactl: set_control:1159: Cannot write control '2:0:0:Speaker Playback
> > Volume:0' : Inappropriate ioctl for device
> >
> > while traceing with strace I see that:
> >
> > open("/usr/lib/libasound.so.2", O_RDONLY) = 4
> > fstat(4, {st_mode=S_IFREG|0755, st_size=716844, ...}) = 0
> > close(4)                                = 0
> > open("/dev/snd/controlC0", O_RDONLY)    = 4
> > close(4)                                = 0
> > open("/dev/snd/controlC0", O_RDWR)      = 4
> > ioctl(4, USBDEVFS_CONTROL, 0xbeab09ec)  = 0
> > ioctl(4, UI_DEV_CREATE, 0xbeab0ad0)     = 0
> > ioctl(4, USBDEVFS_CONNECTINFO, 0xbeab0654) = 0
> > ioctl(4, USBDEVFS_HUB_PORTINFO, 0xbeab0768) = -1 ENOTTY (Inappropriate
> >   
> >
> > Looks like the definition of SNDRV_CTL_ICOTL_ELEM_WRITE doesn't match
> > with the user-space and the kernel, most likely the size of struct
> > snd_ctl_elem_value.  This might be a word alignment issue.
> >
> >   
> 
> Hi Takashi,
> 
> thank you for your response. I have tracked the problem to the kernel
> space and found exactly what you say (structure size). I didn't think
> about word alignment, I will try by changeing the gcc options.
> Do you think I should look at the cross compiler or at the parameters
> passed to gcc while compiling the alsa library?

Well, I vaguely remember about the ARM cross-compiling problem.
Checking the mail archive might help...


Takashi

Re: Inappropriate ioctl for device on alsalib with uclibc and arm platform

[Federico Fuga]

Takashi Iwai ha scritto:
>>> ioctl(4, USBDEVFS_HUB_PORTINFO, 0xbeab0768) = -1 ENOTTY (Inappropriate
>>>   
>>>
>>> Looks like the definition of SNDRV_CTL_ICOTL_ELEM_WRITE doesn't match
>>> with the user-space and the kernel, most likely the size of struct
>>> snd_ctl_elem_value.  This might be a word alignment issue.
>>>       
> Well, I vaguely remember about the ARM cross-compiling problem.
> Checking the mail archive might help...
>   

Hi,

I have solved that problem.
While compiling the kernel, the alsa modules (not the alsa-driver, but
that one included in the "vanilla" sources) are compiled with the option
-mabi=aapcs-linux.
When compiling the library, that option is missing, using, as default,
another abi and, evidently, another data alignment => another struct
size => another ioctl.
I send you that for reference, but I think that a more general solution
should be nice.
Best regards, ant thank you for your interest.

ing. Federico Fuga