Problems with 32 bit apps on 64 bit OS using dmix and snd-ioctl32

Problems with 32 bit apps on 64 bit OS using dmix and snd-ioctl32

[James Pearson]

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

Re: Problems with 32 bit apps on 64 bit OS using dmix and snd-ioctl32

[Takashi Iwai]

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

Re: Problems with 32 bit apps on 64 bit OS using dmix and snd-ioctl32

[James Pearson]

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

Re: Problems with 32 bit apps on 64 bit OS using dmix and snd-ioctl32

[Takashi Iwai]

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

Re: Problems with 32 bit apps on 64 bit OS using dmix and snd-ioctl32

[James Pearson]

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...

Re: Problems with 32 bit apps on 64 bit OS using dmix and snd-ioctl32

[Takashi Iwai]

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"

Re: Problems with 32 bit apps on 64 bit OS using dmix and snd-ioctl32

[James Pearson]

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

Re: Problems with 32 bit apps on 64 bit OS using dmix and snd-ioctl32

[Takashi Iwai]

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

Re: Problems with 32 bit apps on 64 bit OS using dmix and snd-ioctl32

[James Pearson]

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

Re: Problems with 32 bit apps on 64 bit OS using dmix and snd-ioctl32

[Takashi Iwai]

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

Re: Problems with 32 bit apps on 64 bit OS using dmix and snd-ioctl32

[James Pearson]

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

Re: Problems with 32 bit apps on 64 bit OS using dmix and snd-ioctl32

[Takashi Iwai]

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 },
 };

Re: Problems with 32 bit apps on 64 bit OS using dmix and snd-ioctl32

[James Pearson]

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

Re: Problems with 32 bit apps on 64 bit OS using dmix and snd-ioctl32

[Takashi Iwai]

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

Re: Problems with 32 bit apps on 64 bit OS using dmix and snd-ioctl32

[James Pearson]

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