[alsa-devel] Problems with 32 bit apps on 64 bit OS using dmix and snd-ioctl32
I've already sent this to the alsa-user list, but may be this a better place to ask:
I have a problem using 32 bit (i386) playback applications on a 64 bit (x86_64) CentOS4/RHEL4 based kernel (based on kernel 2.6.9).
I've installed alsa-driver, alsa-lib and alsa-utils 1.0.13 (newer versions of alsa-driver don't build with this kernel)
If I try to run a 32 bit copy of aplay on a 64 bit machine that doesn't support hardware mixing (e.g. HDA NVidia) - i.e. uses dmix by default, I get:
aplay: pcm_write:1268: write error: Invalid argument
and /var/log/messages reports:
Sep 4 16:45:37 wstemp-b kernel: ioctl32(aplay:28133): Unknown cmd fd(3) cmd(40045402){00} arg(ffffae88) on /dev/snd/timer Sep 4 16:45:37 wstemp-b kernel: ioctl32(aplay:28133): Unknown cmd fd(5) cmd(c008551a){00} arg(080678a0) on /dev/snd/controlC0 Sep 4 16:45:37 wstemp-b kernel: ioctl32(aplay:28133): Unknown cmd fd(5) cmd(c008551b){00} arg(080678a0) on /dev/snd/controlC0 Sep 4 16:45:37 wstemp-b kernel: ioctl32(aplay:28133): Unknown cmd fd(3) cmd(000054a0){00} arg(00000320) on /dev/snd/timer
I've done some searching to find a solution - and found out that in more recent kernels, snd-ioctl32 has been obsoleted - and if I do use a more modern kernel, then using a 32 bit version of aplay works OK on a newer 64 bit kernel.
However, for other (not sound related) reasons, I need to run the RHEL4/CentOS4 2.6.9 kernel ...
I had a look at the alsa-driver code, and acore/ioctl32/timer32_new.c contains:
#if 0 /* ** FIXME ** * The following four entries are disabled because they conflict * with the TCOC* definitions. * Unfortunately, the current ioctl32 wrapper uses a single * hash table for all devices. Once when the wrapper is fixed * with the table based on devices, they'll be back again. */ MAP_COMPAT(SNDRV_TIMER_IOCTL_START), MAP_COMPAT(SNDRV_TIMER_IOCTL_STOP), MAP_COMPAT(SNDRV_TIMER_IOCTL_CONTINUE), MAP_COMPAT(SNDRV_TIMER_IOCTL_PAUSE), #endif
If I change the '#if 0' to '#if 1', recompile and reload with this new snd-ioctl32 module, then the 32 bit aplay works without an error ... although /var/log/messages still reports:
Sep 4 17:05:26 wstemp-b kernel: ioctl32(aplay:28926): Unknown cmd fd(3) cmd(40045402){00} arg(ffffadb8) on /dev/snd/timer Sep 4 17:05:26 wstemp-b kernel: ioctl32(aplay:28926): Unknown cmd fd(5) cmd(c008551a){00} arg(080678a0) on /dev/snd/controlC0 Sep 4 17:05:26 wstemp-b kernel: ioctl32(aplay:28926): Unknown cmd fd(5) cmd(c008551b){00} arg(080678a0) on /dev/snd/controlC0
... but at least I get sound out!
So, what is the danger of using these 'disabled' ioctls?
I can't find any reference to 'TCOC* definitions' - what are these ???
Thanks
James Pearson
At Wed, 05 Sep 2007 12:10:40 +0100, James Pearson wrote:
I've already sent this to the alsa-user list, but may be this a better place to ask:
I have a problem using 32 bit (i386) playback applications on a 64 bit (x86_64) CentOS4/RHEL4 based kernel (based on kernel 2.6.9).
I've installed alsa-driver, alsa-lib and alsa-utils 1.0.13 (newer versions of alsa-driver don't build with this kernel)
If I try to run a 32 bit copy of aplay on a 64 bit machine that doesn't support hardware mixing (e.g. HDA NVidia) - i.e. uses dmix by default, I get:
aplay: pcm_write:1268: write error: Invalid argument
and /var/log/messages reports:
Sep 4 16:45:37 wstemp-b kernel: ioctl32(aplay:28133): Unknown cmd fd(3) cmd(40045402){00} arg(ffffae88) on /dev/snd/timer Sep 4 16:45:37 wstemp-b kernel: ioctl32(aplay:28133): Unknown cmd fd(5) cmd(c008551a){00} arg(080678a0) on /dev/snd/controlC0 Sep 4 16:45:37 wstemp-b kernel: ioctl32(aplay:28133): Unknown cmd fd(5) cmd(c008551b){00} arg(080678a0) on /dev/snd/controlC0 Sep 4 16:45:37 wstemp-b kernel: ioctl32(aplay:28133): Unknown cmd fd(3) cmd(000054a0){00} arg(00000320) on /dev/snd/timer
I've done some searching to find a solution - and found out that in more recent kernels, snd-ioctl32 has been obsoleted - and if I do use a more modern kernel, then using a 32 bit version of aplay works OK on a newer 64 bit kernel.
However, for other (not sound related) reasons, I need to run the RHEL4/CentOS4 2.6.9 kernel ...
I had a look at the alsa-driver code, and acore/ioctl32/timer32_new.c contains:
#if 0 /* ** FIXME ** * The following four entries are disabled because they conflict * with the TCOC* definitions. * Unfortunately, the current ioctl32 wrapper uses a single * hash table for all devices. Once when the wrapper is fixed * with the table based on devices, they'll be back again. */ MAP_COMPAT(SNDRV_TIMER_IOCTL_START), MAP_COMPAT(SNDRV_TIMER_IOCTL_STOP), MAP_COMPAT(SNDRV_TIMER_IOCTL_CONTINUE), MAP_COMPAT(SNDRV_TIMER_IOCTL_PAUSE), #endif
If I change the '#if 0' to '#if 1', recompile and reload with this new snd-ioctl32 module, then the 32 bit aplay works without an error ... although /var/log/messages still reports:
Sep 4 17:05:26 wstemp-b kernel: ioctl32(aplay:28926): Unknown cmd fd(3) cmd(40045402){00} arg(ffffadb8) on /dev/snd/timer Sep 4 17:05:26 wstemp-b kernel: ioctl32(aplay:28926): Unknown cmd fd(5) cmd(c008551a){00} arg(080678a0) on /dev/snd/controlC0 Sep 4 17:05:26 wstemp-b kernel: ioctl32(aplay:28926): Unknown cmd fd(5) cmd(c008551b){00} arg(080678a0) on /dev/snd/controlC0
... but at least I get sound out!
So, what is the danger of using these 'disabled' ioctls?
I can't find any reference to 'TCOC* definitions' - what are these ???
A typo of TIOC* or TC*. They are defined in asm-*/ioctls.h.
These are used for syscalls like fcntl(). Thus, it's indeed dangerous to define these.
Can't you build the new alsa-driver with old kernel? Then, together with the new alsa-lib, the problem should go away.
Takashi
Takashi Iwai wrote:
So, what is the danger of using these 'disabled' ioctls?
I can't find any reference to 'TCOC* definitions' - what are these ???
A typo of TIOC* or TC*. They are defined in asm-*/ioctls.h.
These are used for syscalls like fcntl(). Thus, it's indeed dangerous to define these.
Can't you build the new alsa-driver with old kernel? Then, together with the new alsa-lib, the problem should go away.
I can't build either alsa-driver 1.0.14 or 1.0.15rc1 - they bomb out with:
CC [M] /tmp/alsa-driver-1.0.15rc1/misc/ac97_bus.o In file included from /tmp/alsa-driver-1.0.15rc1/misc/ac97_bus.c:1: /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:30: error: syntax error before "pm_message_t" /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:31: warning: function declaration isn't a prototype /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c: In function `ac97_bus_suspend': /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:34: error: `dev' undeclared (first use in this function) /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:34: error: (Each undeclared identifier is reported only once /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:34: error: for each function it appears in.) /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:35: error: `state' undeclared (first use in this function) /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c: In function `ac97_bus_resume': /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:45: error: too few arguments to function make[4]: *** [/tmp/alsa-driver-1.0.15rc1/misc/ac97_bus.o] Error 1
However, even if I could build 1.0.14/15rc1, I'm not sure if they would help - as I think the important output from the configure script (alsa-driver 1.0.13 and above) is:
checking for new unlocked/compat_ioctl... no
and in include/config.h:
/* #undef CONFIG_SND_HAVE_NEW_IOCTL */
So, as far as I can tell, means that I have to use the snd-ioctl32 module, which has the problems I originally described.
Is this correct?
Thanks
James Pearson
At Wed, 05 Sep 2007 15:38:33 +0100, James Pearson wrote:
Takashi Iwai wrote:
So, what is the danger of using these 'disabled' ioctls?
I can't find any reference to 'TCOC* definitions' - what are these ???
A typo of TIOC* or TC*. They are defined in asm-*/ioctls.h.
These are used for syscalls like fcntl(). Thus, it's indeed dangerous to define these.
Can't you build the new alsa-driver with old kernel? Then, together with the new alsa-lib, the problem should go away.
I can't build either alsa-driver 1.0.14 or 1.0.15rc1 - they bomb out with:
CC [M] /tmp/alsa-driver-1.0.15rc1/misc/ac97_bus.o In file included from /tmp/alsa-driver-1.0.15rc1/misc/ac97_bus.c:1: /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:30: error: syntax error before "pm_message_t" /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:31: warning: function declaration isn't a prototype /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c: In function `ac97_bus_suspend': /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:34: error: `dev' undeclared (first use in this function) /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:34: error: (Each undeclared identifier is reported only once /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:34: error: for each function it appears in.) /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:35: error: `state' undeclared (first use in this function) /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c: In function `ac97_bus_resume': /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:45: error: too few arguments to function make[4]: *** [/tmp/alsa-driver-1.0.15rc1/misc/ac97_bus.o] Error 1
However, even if I could build 1.0.14/15rc1, I'm not sure if they would help - as I think the important output from the configure script (alsa-driver 1.0.13 and above) is:
checking for new unlocked/compat_ioctl... no
and in include/config.h:
/* #undef CONFIG_SND_HAVE_NEW_IOCTL */
So, as far as I can tell, means that I have to use the snd-ioctl32 module, which has the problems I originally described.
Is this correct?
No, this is perfectly OK. The problem isn't that you use snd-ioctl32 module but that the driver is still old and it doesn't accept the new defined ioctls. The later version of alsa-driver uses the newer ioctls so that they don't conflict even on snd-ioctl32 module.
The right solution is to get the latest alsa-driver working on your system. I guess the build problem above is very specific to RedHat. Unfortunately, I can't help much because I have little clue about funny RedHat modifications. The error implies, however, some configure mismatch. Maybe showing the configure output would help a little bit to know what's happening there...
Takashi
Takashi Iwai wrote:
At Wed, 05 Sep 2007 15:38:33 +0100, James Pearson wrote:
Takashi Iwai wrote:
So, what is the danger of using these 'disabled' ioctls?
I can't find any reference to 'TCOC* definitions' - what are these ???
A typo of TIOC* or TC*. They are defined in asm-*/ioctls.h.
These are used for syscalls like fcntl(). Thus, it's indeed dangerous to define these.
Can't you build the new alsa-driver with old kernel? Then, together with the new alsa-lib, the problem should go away.
I can't build either alsa-driver 1.0.14 or 1.0.15rc1 - they bomb out with:
CC [M] /tmp/alsa-driver-1.0.15rc1/misc/ac97_bus.o In file included from /tmp/alsa-driver-1.0.15rc1/misc/ac97_bus.c:1: /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:30: error: syntax error before "pm_message_t" /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:31: warning: function declaration isn't a prototype /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c: In function `ac97_bus_suspend': /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:34: error: `dev' undeclared (first use in this function) /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:34: error: (Each undeclared identifier is reported only once /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:34: error: for each function it appears in.) /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:35: error: `state' undeclared (first use in this function) /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c: In function `ac97_bus_resume': /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:45: error: too few arguments to function make[4]: *** [/tmp/alsa-driver-1.0.15rc1/misc/ac97_bus.o] Error 1
However, even if I could build 1.0.14/15rc1, I'm not sure if they would help - as I think the important output from the configure script (alsa-driver 1.0.13 and above) is:
checking for new unlocked/compat_ioctl... no
and in include/config.h:
/* #undef CONFIG_SND_HAVE_NEW_IOCTL */
So, as far as I can tell, means that I have to use the snd-ioctl32 module, which has the problems I originally described.
Is this correct?
No, this is perfectly OK. The problem isn't that you use snd-ioctl32 module but that the driver is still old and it doesn't accept the new defined ioctls. The later version of alsa-driver uses the newer ioctls so that they don't conflict even on snd-ioctl32 module.
The right solution is to get the latest alsa-driver working on your system. I guess the build problem above is very specific to RedHat. Unfortunately, I can't help much because I have little clue about funny RedHat modifications. The error implies, however, some configure mismatch. Maybe showing the configure output would help a little bit to know what's happening there...
OK, I'll do a bit more poking about to see if I can get 1.0.15rc1 to build ...
Thanks
James Pearson
Configure output:
# ./configure --with-redhat=yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for ranlib... ranlib checking for a BSD-compatible install... /usr/bin/install -c checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking whether time.h and sys/time.h may both be included... yes checking whether gcc needs -traditional... no checking for current directory... /tmp/alsa-driver-1.0.15rc1 checking cross compile... checking for directory with kernel source... /lib/modules/2.6.9-42.0.3.mpc23smp/source checking for directory with kernel build... /lib/modules/2.6.9-42.0.3.mpc23smp/build checking for kernel linux/version.h... yes checking for kernel linux/autoconf.h... yes checking for kernel version... 2.6.9-42.0.3.mpc23smp checking for GCC version... Kernel compiler: gcc 3.4.6 20060404 (Red Hat 3.4.6-3) Used compiler: gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3) checking for built-in ALSA... no checking for existing ALSA module... yes checking for Red Hat kernel... yes checking for SUSE kernel... auto checking for SUSE kernel... no checking for CONFIG_EXPERIMENTAL... yes checking for kernel linux/config.h... yes checking to modify of kernel linux/kmod.h... no checking for kernel linux/utsrelease.h... no Creating a dummy <linux/utsrelease.h>... checking for kernel linux/compiler.h... yes checking for kernel linux/pm.h... yes checking for kernel linux/spinlock.h... yes checking for kernel linux/irq.h... yes checking for kernel linux/threads.h... yes checking for kernel linux/rwsem.h... yes checking for kernel linux/gameport.h... yes checking for kernel media/v4l2-dev.h... no Creating a dummy <media/v4l2-dev.h>... checking for kernel linux/devfs_fs_kernel.h... yes checking for kernel linux/highmem.h... yes checking for kernel linux/workqueue.h... yes checking for kernel linux/dma-mapping.h... yes checking for kernel asm/hw_irq.h... yes checking for kernel linux/device.h... yes checking for kernel linux/platform_device.h... no Creating <linux/platform_device.h>... checking for kernel linux/isa.h... no Creating <linux/isa.h>... checking for kernel linux/jiffies.h... yes checking for kernel linux/compat.h... yes checking for kernel linux/log2.h... no Creating a dummy <linux/log2.h>... checking for kernel linux/adb.h... yes checking for kernel linux/cuda.h... yes checking for kernel linux/pmu.h... yes checking for kernel linux/moduleparam.h... yes checking for kernel linux/syscalls.h... yes checking for kernel linux/firmware.h... yes checking for kernel linux/err.h... yes checking for kernel linux/bitmap.h... yes checking for kernel linux/mutex.h... yes checking for kernel linux/latency.h... no Creating <linux/latency.h>... checking for kernel asm/irq_regs.h... no Creating a dummy <asm/irq_regs.h>... checking for kernel module symbol versions... yes checking for PCI support in kernel... yes checking for I2C driver in kernel... module checking for I2C_POWERMAC in kernel... unknown checking for firmware loader... yes checking for input subsystem in kernel... yes checking for directory to store kernel modules... /lib/modules/2.6.9-42.0.3.mpc23smp/kernel/sound checking for verbose procfs... on checking for verbose printk... on checking for debug level... none checking for ISA support in kernel... no checking for processor type... x86_64 checking for 32bit compat support... yes checking for SMP... yes checking for Video device support in kernel... yes checking for ISA PnP driver in kernel... yes checking for PnP driver in kernel... yes checking for Kernel ISA-PnP support... no checking for Kernel ISA-PnP module support... no checking for strlcpy... yes checking for snprintf... yes checking for vsnprintf... yes checking for scnprintf... yes checking for sscanf... yes checking for vmalloc_to_page... yes checking for old kmod... no checking for PDE... yes checking for pci_set_consistent_dma_mask... yes checking for pci_dev_present... no checking for msleep... yes checking for msleep_interrupt... yes checking for msecs_to_jiffies... yes checking for tty->count is the atomic type... no checking for video_get_drvdata... yes checking for io_remap_pfn_range... no checking for new io_remap_page_range... yes checking for kcalloc... yes checking for kstrdup... yes checking for kzalloc... yes checking for create_workqueue with flags... no checking for saved_config_space in pci_dev... yes checking for new pci_save_state... no checking for register_sound_special_device... no checking for driver version... 1.0.15rc1 checking for sequencer support... yes checking for OSS/Free emulation... yes checking for OSS PCM plugin system inclusion... yes checking for RTC callback support in kernel... may be buggy, skipped checking for HPET support... no checking for dynamic minor numbers... no checking for support of old API... yes checking for Procfs support... yes checking for USB support... yes checking for class_simple... yes checking for old driver suspend/resume callbacks... yes checking for removal of page-reservation for nopage/mmap... no checking for nested class_device... no checking for new IRQ handler... no checking for gfp_t... yes checking for PnP suspend/resume... no checking for new unlocked/compat_ioctl... no checking for x86-compatible PC... no checking for High-Res timers... no checking for kernel PCMCIA checking for PCMCIA support... yes checking for PC9800 support in kernel... no checking for parallel port support... yes checking for power management... yes checking for which soundcards to compile driver for... all configure: creating ./config.status config.status: creating version config.status: creating Makefile.conf config.status: WARNING: Makefile.conf.in seems to ignore the --datarootdir setting config.status: creating snddevices config.status: creating utils/alsa-driver.spec config.status: creating utils/buildrpm config.status: creating toplevel.config config.status: creating utils/alsasound config.status: creating utils/alsasound.posix config.status: creating include/pci_ids_compat.h config.status: creating include/i2c-id_compat.h config.status: creating include/config.h config.status: creating include/config1.h config.status: creating include/version.h config.status: include/version.h is unchanged config.status: creating include/autoconf-extra.h Hacking autoconf.h...
At Wed, 05 Sep 2007 16:36:10 +0100, James Pearson wrote:
Takashi Iwai wrote:
At Wed, 05 Sep 2007 15:38:33 +0100, James Pearson wrote:
Takashi Iwai wrote:
So, what is the danger of using these 'disabled' ioctls?
I can't find any reference to 'TCOC* definitions' - what are these ???
A typo of TIOC* or TC*. They are defined in asm-*/ioctls.h.
These are used for syscalls like fcntl(). Thus, it's indeed dangerous to define these.
Can't you build the new alsa-driver with old kernel? Then, together with the new alsa-lib, the problem should go away.
I can't build either alsa-driver 1.0.14 or 1.0.15rc1 - they bomb out with:
CC [M] /tmp/alsa-driver-1.0.15rc1/misc/ac97_bus.o In file included from /tmp/alsa-driver-1.0.15rc1/misc/ac97_bus.c:1: /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:30: error: syntax error before "pm_message_t" /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:31: warning: function declaration isn't a prototype /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c: In function `ac97_bus_suspend': /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:34: error: `dev' undeclared (first use in this function) /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:34: error: (Each undeclared identifier is reported only once /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:34: error: for each function it appears in.) /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:35: error: `state' undeclared (first use in this function) /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c: In function `ac97_bus_resume': /tmp/alsa-driver-1.0.15rc1/misc/../alsa-kernel/ac97_bus.c:45: error: too few arguments to function make[4]: *** [/tmp/alsa-driver-1.0.15rc1/misc/ac97_bus.o] Error 1
However, even if I could build 1.0.14/15rc1, I'm not sure if they would help - as I think the important output from the configure script (alsa-driver 1.0.13 and above) is:
checking for new unlocked/compat_ioctl... no
and in include/config.h:
/* #undef CONFIG_SND_HAVE_NEW_IOCTL */
So, as far as I can tell, means that I have to use the snd-ioctl32 module, which has the problems I originally described.
Is this correct?
No, this is perfectly OK. The problem isn't that you use snd-ioctl32 module but that the driver is still old and it doesn't accept the new defined ioctls. The later version of alsa-driver uses the newer ioctls so that they don't conflict even on snd-ioctl32 module.
The right solution is to get the latest alsa-driver working on your system. I guess the build problem above is very specific to RedHat. Unfortunately, I can't help much because I have little clue about funny RedHat modifications. The error implies, however, some configure mismatch. Maybe showing the configure output would help a little bit to know what's happening there...
OK, I'll do a bit more poking about to see if I can get 1.0.15rc1 to build ...
Thanks
James Pearson
Configure output:
# ./configure --with-redhat=yes
The output looks OK to me. Does the patch (to alsa-driver tree) fix the problem?
Takashi
diff -r adfe4179d670 misc/ac97_bus.c --- a/misc/ac97_bus.c Fri Aug 31 12:22:35 2007 +0200 +++ b/misc/ac97_bus.c Wed Sep 05 18:09:42 2007 +0200 @@ -1,1 +1,3 @@ +#include <sound/driver.h> +#include <sound/core.h> #include "../alsa-kernel/ac97_bus.c"
Takashi Iwai wrote:
OK, I'll do a bit more poking about to see if I can get 1.0.15rc1 to build ...
Thanks
James Pearson
Configure output:
# ./configure --with-redhat=yes
The output looks OK to me. Does the patch (to alsa-driver tree) fix the problem?
Takashi
diff -r adfe4179d670 misc/ac97_bus.c --- a/misc/ac97_bus.c Fri Aug 31 12:22:35 2007 +0200 +++ b/misc/ac97_bus.c Wed Sep 05 18:09:42 2007 +0200 @@ -1,1 +1,3 @@ +#include <sound/driver.h> +#include <sound/core.h> #include "../alsa-kernel/ac97_bus.c"
Yes ... I did something similar - copied in ../alsa-kernel/ac97_bus.c and patched with alsa-driver-1.0.13/pci/ac97/ac97_bus.patch - which makes it compile - it bombs out later on some of the soc/ code - but as nothing similar exists in 1.0.13, I just skipped that with 'make -i' ...
However, with these 1.0.15rc1 modules installed, and using alsa-lib-1.0.15rc1, I get exactly the same problem with 32 bit apps:
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono aplay: pcm_write:1268: write error: Invalid argument
amd dmesg has:
ioctl32(aplay:6228): Unknown cmd fd(3) cmd(40045402){00} arg(ffffac98) on /dev/snd/timer ioctl32(aplay:6228): Unknown cmd fd(5) cmd(c008551a){00} arg(0806ccd0) on /dev/snd/controlC0 ioctl32(aplay:6228): Unknown cmd fd(5) cmd(c008551b){00} arg(0806ccd0) on /dev/snd/controlC0 ioctl32(aplay:6228): Unknown cmd fd(3) cmd(000054a0){00} arg(00000325) on /dev/snd/timer
James Pearson
At Wed, 05 Sep 2007 17:54:35 +0100, James Pearson wrote:
Takashi Iwai wrote:
OK, I'll do a bit more poking about to see if I can get 1.0.15rc1 to build ...
Thanks
James Pearson
Configure output:
# ./configure --with-redhat=yes
The output looks OK to me. Does the patch (to alsa-driver tree) fix the problem?
Takashi
diff -r adfe4179d670 misc/ac97_bus.c --- a/misc/ac97_bus.c Fri Aug 31 12:22:35 2007 +0200 +++ b/misc/ac97_bus.c Wed Sep 05 18:09:42 2007 +0200 @@ -1,1 +1,3 @@ +#include <sound/driver.h> +#include <sound/core.h> #include "../alsa-kernel/ac97_bus.c"
Yes ... I did something similar - copied in ../alsa-kernel/ac97_bus.c and patched with alsa-driver-1.0.13/pci/ac97/ac97_bus.patch - which makes it compile - it bombs out later on some of the soc/ code - but as nothing similar exists in 1.0.13, I just skipped that with 'make -i' ...
Hm, maybe it's better to specify 2.6.16 or so for SND_SOC in alsa-driver/kconfig-vers. Could you check whether it works?
However, with these 1.0.15rc1 modules installed, and using alsa-lib-1.0.15rc1, I get exactly the same problem with 32 bit apps:
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono aplay: pcm_write:1268: write error: Invalid argument
amd dmesg has:
ioctl32(aplay:6228): Unknown cmd fd(3) cmd(40045402){00} arg(ffffac98) on /dev/snd/timer ioctl32(aplay:6228): Unknown cmd fd(5) cmd(c008551a){00} arg(0806ccd0) on /dev/snd/controlC0 ioctl32(aplay:6228): Unknown cmd fd(5) cmd(c008551b){00} arg(0806ccd0) on /dev/snd/controlC0 ioctl32(aplay:6228): Unknown cmd fd(3) cmd(000054a0){00} arg(00000325) on /dev/snd/timer
Do you use the latest alsa-lib, too? The old alsa-lib tries only the old ioctl, of course...
Takashi
Takashi Iwai wrote:
Hm, maybe it's better to specify 2.6.16 or so for SND_SOC in alsa-driver/kconfig-vers. Could you check whether it works?
Yes, this works - after I figured out that I needed to regenerate the configure script after changing kconfig-vers ...
alsa-driver 1.0.15rc1 now builds OK on RHEL4/CentOS4 (with a patched misc/ac97_bus.c and SND_SOC set to 2.6.16 in kconfig-vers)
However, with these 1.0.15rc1 modules installed, and using alsa-lib-1.0.15rc1, I get exactly the same problem with 32 bit apps:
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono aplay: pcm_write:1268: write error: Invalid argument
amd dmesg has:
ioctl32(aplay:6228): Unknown cmd fd(3) cmd(40045402){00} arg(ffffac98) on /dev/snd/timer ioctl32(aplay:6228): Unknown cmd fd(5) cmd(c008551a){00} arg(0806ccd0) on /dev/snd/controlC0 ioctl32(aplay:6228): Unknown cmd fd(5) cmd(c008551b){00} arg(0806ccd0) on /dev/snd/controlC0 ioctl32(aplay:6228): Unknown cmd fd(3) cmd(000054a0){00} arg(00000325) on /dev/snd/timer
Do you use the latest alsa-lib, too? The old alsa-lib tries only the old ioctl, of course...
Yes, I've installed the 32 bit and 64 bit alsa-lib-1.0.15rc1 packages - and I still get the above errors ...
Do I need to build alsa-lib with any special options? I configured alsa-lib using:
configure --enable-static=yes --datadir=/etc
As this is how the 1.0.6 alsa-lib RHEL4 RPM was configured.
Does building alsa-lib depend on the alsa-driver version installed? - as I built the 32 bit version on a 'stock' CentOS4/RHEL4 install that didn't have the alsa-driver 1.0.15rc1 installed - would this make a difference?
Thanks
James Pearson
At Thu, 06 Sep 2007 11:26:35 +0100, James Pearson wrote:
Takashi Iwai wrote:
Hm, maybe it's better to specify 2.6.16 or so for SND_SOC in alsa-driver/kconfig-vers. Could you check whether it works?
Yes, this works - after I figured out that I needed to regenerate the configure script after changing kconfig-vers ...
alsa-driver 1.0.15rc1 now builds OK on RHEL4/CentOS4 (with a patched misc/ac97_bus.c and SND_SOC set to 2.6.16 in kconfig-vers)
Thanks for confirmation. I'll fix this on HG tree later.
However, with these 1.0.15rc1 modules installed, and using alsa-lib-1.0.15rc1, I get exactly the same problem with 32 bit apps:
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono aplay: pcm_write:1268: write error: Invalid argument
amd dmesg has:
ioctl32(aplay:6228): Unknown cmd fd(3) cmd(40045402){00} arg(ffffac98) on /dev/snd/timer ioctl32(aplay:6228): Unknown cmd fd(5) cmd(c008551a){00} arg(0806ccd0) on /dev/snd/controlC0 ioctl32(aplay:6228): Unknown cmd fd(5) cmd(c008551b){00} arg(0806ccd0) on /dev/snd/controlC0 ioctl32(aplay:6228): Unknown cmd fd(3) cmd(000054a0){00} arg(00000325) on /dev/snd/timer
Do you use the latest alsa-lib, too? The old alsa-lib tries only the old ioctl, of course...
Yes, I've installed the 32 bit and 64 bit alsa-lib-1.0.15rc1 packages - and I still get the above errors ...
Do I need to build alsa-lib with any special options? I configured alsa-lib using:
configure --enable-static=yes --datadir=/etc
As this is how the 1.0.6 alsa-lib RHEL4 RPM was configured.
You shouldn't use --enable-static for the dynamic library. Yes, usually it's OK, but alsa-lib has some special handling for static binding, so it cannot be built with dynamic lib together.
Thus, for 64bit version,
% ./configure --datadir=/etc --libdir=/usr/lib64
for 32bit version,
% ./configure --datadir=/etc
And make sure that all sound apps are killed once (otherwise the old configured dmix instance may remain undead and conflict with the new setting).
Does building alsa-lib depend on the alsa-driver version installed? - as I built the 32 bit version on a 'stock' CentOS4/RHEL4 install that didn't have the alsa-driver 1.0.15rc1 installed - would this make a difference?
alsa-lib has backward compatibility, so it should work with the older drivers. The kernel ABI is usually kept, but some exceptional cases like this timer ioctl changes can be supported only by the newer alsa-lib. But, in principle, it's safer to update both alsa-driver and alsa-lib.
Also, it's recommended to keep the same version for both 32 and 64bit alsa-lib, too, especially about dmix stuff.
Takashi
Takashi Iwai wrote:
You shouldn't use --enable-static for the dynamic library. Yes, usually it's OK, but alsa-lib has some special handling for static binding, so it cannot be built with dynamic lib together.
Thus, for 64bit version,
% ./configure --datadir=/etc --libdir=/usr/lib64
for 32bit version,
% ./configure --datadir=/etc
And make sure that all sound apps are killed once (otherwise the old configured dmix instance may remain undead and conflict with the new setting).
Does building alsa-lib depend on the alsa-driver version installed? - as I built the 32 bit version on a 'stock' CentOS4/RHEL4 install that didn't have the alsa-driver 1.0.15rc1 installed - would this make a difference?
alsa-lib has backward compatibility, so it should work with the older drivers. The kernel ABI is usually kept, but some exceptional cases like this timer ioctl changes can be supported only by the newer alsa-lib. But, in principle, it's safer to update both alsa-driver and alsa-lib.
Also, it's recommended to keep the same version for both 32 and 64bit alsa-lib, too, especially about dmix stuff.
Rebuilt alsa-lib 1.0.15rc1 for both 32 and 64 bit as above, installed and rebooted - however, I still can't get it to play with 32 bit apps - I still get:
% aplay test.wav Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono aplay: pcm_write:1268: write error: Invalid argument
dmesg:
ioctl32(aplay:5957): Unknown cmd fd(3) cmd(40045402){00} arg(ffffacb8) on /dev/snd/timer ioctl32(aplay:5957): Unknown cmd fd(5) cmd(c008551a){00} arg(0807a140) on /dev/snd/controlC0 ioctl32(aplay:5957): Unknown cmd fd(5) cmd(c008551b){00} arg(0807a140) on /dev/snd/controlC0 ioctl32(aplay:5957): Unknown cmd fd(3) cmd(000054a0){00} arg(00000325) on /dev/snd/timer
Thanks
James Pearson
At Thu, 06 Sep 2007 12:56:05 +0100, James Pearson wrote:
Takashi Iwai wrote:
You shouldn't use --enable-static for the dynamic library. Yes, usually it's OK, but alsa-lib has some special handling for static binding, so it cannot be built with dynamic lib together.
Thus, for 64bit version,
% ./configure --datadir=/etc --libdir=/usr/lib64
for 32bit version,
% ./configure --datadir=/etc
And make sure that all sound apps are killed once (otherwise the old configured dmix instance may remain undead and conflict with the new setting).
Does building alsa-lib depend on the alsa-driver version installed? - as I built the 32 bit version on a 'stock' CentOS4/RHEL4 install that didn't have the alsa-driver 1.0.15rc1 installed - would this make a difference?
alsa-lib has backward compatibility, so it should work with the older drivers. The kernel ABI is usually kept, but some exceptional cases like this timer ioctl changes can be supported only by the newer alsa-lib. But, in principle, it's safer to update both alsa-driver and alsa-lib.
Also, it's recommended to keep the same version for both 32 and 64bit alsa-lib, too, especially about dmix stuff.
Rebuilt alsa-lib 1.0.15rc1 for both 32 and 64 bit as above, installed and rebooted - however, I still can't get it to play with 32 bit apps - I still get:
% aplay test.wav Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono aplay: pcm_write:1268: write error: Invalid argument
dmesg:
ioctl32(aplay:5957): Unknown cmd fd(3) cmd(40045402){00} arg(ffffacb8) on /dev/snd/timer ioctl32(aplay:5957): Unknown cmd fd(5) cmd(c008551a){00} arg(0807a140) on /dev/snd/controlC0 ioctl32(aplay:5957): Unknown cmd fd(5) cmd(c008551b){00} arg(0807a140) on /dev/snd/controlC0 ioctl32(aplay:5957): Unknown cmd fd(3) cmd(000054a0){00} arg(00000325) on /dev/snd/timer
Ah, I see the point.
With ALSA 1.0.15rc1, we can safely uncomment #if 0 .. #endif in timer32_new.c and timer32_old.c. These no longer conflict with existing ioctls. I forgot about it.
The patch is below.
Takashi
diff -r adfe4179d670 acore/ioctl32/timer32_new.c --- a/acore/ioctl32/timer32_new.c Fri Aug 31 12:22:35 2007 +0200 +++ b/acore/ioctl32/timer32_new.c Thu Sep 06 14:06:40 2007 +0200 @@ -88,18 +88,11 @@ struct ioctl32_mapper timer_mappers[] = { SNDRV_TIMER_IOCTL_INFO32, AP(timer_info) }, MAP_COMPAT(SNDRV_TIMER_IOCTL_PARAMS), { SNDRV_TIMER_IOCTL_STATUS32, AP(timer_status) }, -#if 0 - /* ** FIXME ** - * The following four entries are disabled because they conflict - * with the TCOC* definitions. - * Unfortunately, the current ioctl32 wrapper uses a single - * hash table for all devices. Once when the wrapper is fixed - * with the table based on devices, they'll be back again. - */ + /* The ioctls are changed, so we can enable them again */ + /* The old ioctls conflict with TIOC_* definitions */ MAP_COMPAT(SNDRV_TIMER_IOCTL_START), MAP_COMPAT(SNDRV_TIMER_IOCTL_STOP), MAP_COMPAT(SNDRV_TIMER_IOCTL_CONTINUE), MAP_COMPAT(SNDRV_TIMER_IOCTL_PAUSE), -#endif { 0 }, }; diff -r adfe4179d670 acore/ioctl32/timer32_old.c --- a/acore/ioctl32/timer32_old.c Fri Aug 31 12:22:35 2007 +0200 +++ b/acore/ioctl32/timer32_old.c Thu Sep 06 14:06:40 2007 +0200 @@ -88,18 +88,11 @@ struct ioctl32_mapper timer_mappers[] = { SNDRV_TIMER_IOCTL_INFO32, AP(timer_info) }, MAP_COMPAT(SNDRV_TIMER_IOCTL_PARAMS), { SNDRV_TIMER_IOCTL_STATUS32, AP(timer_status) }, -#if 0 - /* ** FIXME ** - * The following four entries are disabled because they conflict - * with the TCOC* definitions. - * Unfortunately, the current ioctl32 wrapper uses a single - * hash table for all devices. Once when the wrapper is fixed - * with the table based on devices, they'll be back again. - */ + /* The ioctls are changed, so we can enable them again */ + /* The old ioctls conflict with TIOC_* definitions */ MAP_COMPAT(SNDRV_TIMER_IOCTL_START), MAP_COMPAT(SNDRV_TIMER_IOCTL_STOP), MAP_COMPAT(SNDRV_TIMER_IOCTL_CONTINUE), MAP_COMPAT(SNDRV_TIMER_IOCTL_PAUSE), -#endif { 0 }, };
Takashi Iwai wrote:
Ah, I see the point.
With ALSA 1.0.15rc1, we can safely uncomment #if 0 .. #endif in timer32_new.c and timer32_old.c. These no longer conflict with existing ioctls. I forgot about it.
The patch is below.
Takashi
diff -r adfe4179d670 acore/ioctl32/timer32_new.c --- a/acore/ioctl32/timer32_new.c Fri Aug 31 12:22:35 2007 +0200 +++ b/acore/ioctl32/timer32_new.c Thu Sep 06 14:06:40 2007 +0200 @@ -88,18 +88,11 @@ struct ioctl32_mapper timer_mappers[] = { SNDRV_TIMER_IOCTL_INFO32, AP(timer_info) }, MAP_COMPAT(SNDRV_TIMER_IOCTL_PARAMS), { SNDRV_TIMER_IOCTL_STATUS32, AP(timer_status) }, -#if 0
- /* ** FIXME **
* The following four entries are disabled because they conflict* with the TCOC* definitions.* Unfortunately, the current ioctl32 wrapper uses a single* hash table for all devices. Once when the wrapper is fixed* with the table based on devices, they'll be back again.*/
- /* The ioctls are changed, so we can enable them again */
- /* The old ioctls conflict with TIOC_* definitions */ MAP_COMPAT(SNDRV_TIMER_IOCTL_START), MAP_COMPAT(SNDRV_TIMER_IOCTL_STOP), MAP_COMPAT(SNDRV_TIMER_IOCTL_CONTINUE), MAP_COMPAT(SNDRV_TIMER_IOCTL_PAUSE),
-#endif { 0 }, }; diff -r adfe4179d670 acore/ioctl32/timer32_old.c --- a/acore/ioctl32/timer32_old.c Fri Aug 31 12:22:35 2007 +0200 +++ b/acore/ioctl32/timer32_old.c Thu Sep 06 14:06:40 2007 +0200 @@ -88,18 +88,11 @@ struct ioctl32_mapper timer_mappers[] = { SNDRV_TIMER_IOCTL_INFO32, AP(timer_info) }, MAP_COMPAT(SNDRV_TIMER_IOCTL_PARAMS), { SNDRV_TIMER_IOCTL_STATUS32, AP(timer_status) }, -#if 0
- /* ** FIXME **
* The following four entries are disabled because they conflict* with the TCOC* definitions.* Unfortunately, the current ioctl32 wrapper uses a single* hash table for all devices. Once when the wrapper is fixed* with the table based on devices, they'll be back again.*/
- /* The ioctls are changed, so we can enable them again */
- /* The old ioctls conflict with TIOC_* definitions */ MAP_COMPAT(SNDRV_TIMER_IOCTL_START), MAP_COMPAT(SNDRV_TIMER_IOCTL_STOP), MAP_COMPAT(SNDRV_TIMER_IOCTL_CONTINUE), MAP_COMPAT(SNDRV_TIMER_IOCTL_PAUSE),
-#endif { 0 }, };
Thanks!
I guess this change also needs to go into the next rc ...
James
At Thu, 06 Sep 2007 13:15:11 +0100, James Pearson wrote:
Takashi Iwai wrote:
Ah, I see the point.
With ALSA 1.0.15rc1, we can safely uncomment #if 0 .. #endif in timer32_new.c and timer32_old.c. These no longer conflict with existing ioctls. I forgot about it.
The patch is below.
Takashi
diff -r adfe4179d670 acore/ioctl32/timer32_new.c --- a/acore/ioctl32/timer32_new.c Fri Aug 31 12:22:35 2007 +0200 +++ b/acore/ioctl32/timer32_new.c Thu Sep 06 14:06:40 2007 +0200 @@ -88,18 +88,11 @@ struct ioctl32_mapper timer_mappers[] = { SNDRV_TIMER_IOCTL_INFO32, AP(timer_info) }, MAP_COMPAT(SNDRV_TIMER_IOCTL_PARAMS), { SNDRV_TIMER_IOCTL_STATUS32, AP(timer_status) }, -#if 0
- /* ** FIXME **
* The following four entries are disabled because they conflict* with the TCOC* definitions.* Unfortunately, the current ioctl32 wrapper uses a single* hash table for all devices. Once when the wrapper is fixed* with the table based on devices, they'll be back again.*/
- /* The ioctls are changed, so we can enable them again */
- /* The old ioctls conflict with TIOC_* definitions */ MAP_COMPAT(SNDRV_TIMER_IOCTL_START), MAP_COMPAT(SNDRV_TIMER_IOCTL_STOP), MAP_COMPAT(SNDRV_TIMER_IOCTL_CONTINUE), MAP_COMPAT(SNDRV_TIMER_IOCTL_PAUSE),
-#endif { 0 }, }; diff -r adfe4179d670 acore/ioctl32/timer32_old.c --- a/acore/ioctl32/timer32_old.c Fri Aug 31 12:22:35 2007 +0200 +++ b/acore/ioctl32/timer32_old.c Thu Sep 06 14:06:40 2007 +0200 @@ -88,18 +88,11 @@ struct ioctl32_mapper timer_mappers[] = { SNDRV_TIMER_IOCTL_INFO32, AP(timer_info) }, MAP_COMPAT(SNDRV_TIMER_IOCTL_PARAMS), { SNDRV_TIMER_IOCTL_STATUS32, AP(timer_status) }, -#if 0
- /* ** FIXME **
* The following four entries are disabled because they conflict* with the TCOC* definitions.* Unfortunately, the current ioctl32 wrapper uses a single* hash table for all devices. Once when the wrapper is fixed* with the table based on devices, they'll be back again.*/
- /* The ioctls are changed, so we can enable them again */
- /* The old ioctls conflict with TIOC_* definitions */ MAP_COMPAT(SNDRV_TIMER_IOCTL_START), MAP_COMPAT(SNDRV_TIMER_IOCTL_STOP), MAP_COMPAT(SNDRV_TIMER_IOCTL_CONTINUE), MAP_COMPAT(SNDRV_TIMER_IOCTL_PAUSE),
-#endif { 0 }, };
Thanks!
I guess this change also needs to go into the next rc ...
Yeah, the patches were already merged to HG tree.
Takashi
On 05/09/2007, James Pearson james-p@moving-picture.com wrote:
Takashi Iwai wrote:
Does the patch (to alsa-driver tree) fix the problem?
Takashi
diff -r adfe4179d670 misc/ac97_bus.c --- a/misc/ac97_bus.c Fri Aug 31 12:22:35 2007 +0200 +++ b/misc/ac97_bus.c Wed Sep 05 18:09:42 2007 +0200 @@ -1,1 +1,3 @@ +#include <sound/driver.h> +#include <sound/core.h> #include "../alsa-kernel/ac97_bus.c"
Yes ... I did something similar - copied in ../alsa-kernel/ac97_bus.c and patched with alsa-driver-1.0.13/pci/ac97/ac97_bus.patch - which makes it compile
Just to follow up on this, your patch that just adds:
#include <sound/driver.h> #include <sound/core.h>
to misc/ac97_bus.c is not enough for it to compile on RHEL4/CentOS4 ... however, copying in ../alsa-kernel/ac97_bus.c and patching with alsa-driver-1.0.13/pci/ac97/ac97_bus.patch does work. It still needs the #ifdef CONFIG_SND_OLD_DRIVER_SUSPEND stuff
James Pearson
participants (2)
-
James Pearson -
Takashi Iwai