Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[David Cullen]

Dear Folks,

I am trying to get ALSA version 1.0.13 working on an AMCC PowerPC
PPC405EP Taihu board with a Sound Blaster Live! 24-bit 7.1 PCI card.
 I am using a patched 2.6.13 kernel that comes with the board.  I
built the kernel with the sound core built in and I used the
cross-compiler tools to build the ALSA driver, library, and utils.
When I run "speaker-test", it crashes in the ALSA library.  The
problem is that the call to mmap in

   alsa-lib-1.0.13/src/pcm/pcm_mmap.c line 367

which looks like

   ptr = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_FILE|MAP_SHARED,
i->u.mmap.fd, i->u.mmap.offset);

returns a pointer that appears to be valid (0x3001E000) but causes a
kernel OOPS when accessed.

Previous calls to mmap in pcm_hw.c on lines 822 and 854 both
succeed, and the pointers returned can be successfully accessed, but
they use the status and control offsets as parameters to mmap.

I haved traced the problem on the target into the ALSA library using
gdb and into the kernel using kgdb and everything looks like it
works properly.  If I disable the semaphore acquisition in do_mmap2,
I can print the contents of the address in kgdb using

   (gdb) print ((char *)vma->vm_start)[0]

after the call to vm_link in do_mmap_pgoff.  However, the board
locks up after the print command.

Anyone have any experience with this type of problem on PowerPC systems?

-- 
Thank you,
David Cullen
Teligy

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[Takashi Iwai]

At Mon, 27 Nov 2006 17:01:52 -0500,
David Cullen wrote:
> 
> Dear Folks,
> 
> I am trying to get ALSA version 1.0.13 working on an AMCC PowerPC
> PPC405EP Taihu board with a Sound Blaster Live! 24-bit 7.1 PCI card.
>  I am using a patched 2.6.13 kernel that comes with the board.  I
> built the kernel with the sound core built in and I used the
> cross-compiler tools to build the ALSA driver, library, and utils.
> When I run "speaker-test", it crashes in the ALSA library.  The
> problem is that the call to mmap in
> 
>    alsa-lib-1.0.13/src/pcm/pcm_mmap.c line 367
> 
> which looks like
> 
>    ptr = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_FILE|MAP_SHARED,
> i->u.mmap.fd, i->u.mmap.offset);
> 
> returns a pointer that appears to be valid (0x3001E000) but causes a
> kernel OOPS when accessed.
> 
> Previous calls to mmap in pcm_hw.c on lines 822 and 854 both
> succeed, and the pointers returned can be successfully accessed, but
> they use the status and control offsets as parameters to mmap.
> 
> I haved traced the problem on the target into the ALSA library using
> gdb and into the kernel using kgdb and everything looks like it
> works properly.  If I disable the semaphore acquisition in do_mmap2,
> I can print the contents of the address in kgdb using
> 
>    (gdb) print ((char *)vma->vm_start)[0]
> 
> after the call to vm_link in do_mmap_pgoff.  However, the board
> locks up after the print command.
> 
> Anyone have any experience with this type of problem on PowerPC systems?

Possibly a memory coherency problem.  The memory allocated via
dma_alloc_coherent() isn't simply mmappable.

An essential fix would be to add dma_mmap_coherent() to all
architectures and use it for ALSA mmap.  I made some patches quite
ago, but left it rotten for the time being...


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[David Cullen]

Dear Mr. Iwai,

Takashi Iwai wrote:
> At Mon, 27 Nov 2006 17:01:52 -0500,
> David Cullen wrote:
>> 
>> I am trying to get ALSA version 1.0.13 working on an AMCC PowerPC
>> PPC405EP Taihu board with a Sound Blaster Live! 24-bit 7.1 PCI card.
>>  I am using a patched 2.6.13 kernel that comes with the board.  I
>> built the kernel with the sound core built in and I used the
>> cross-compiler tools to build the ALSA driver, library, and utils.
>> When I run "speaker-test", it crashes in the ALSA library.  The
>> problem is that the call to mmap in
>> 
>>    alsa-lib-1.0.13/src/pcm/pcm_mmap.c line 367
>> 
>> which looks like
>> 
>>    ptr = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_FILE|MAP_SHARED,
>> i->u.mmap.fd, i->u.mmap.offset);
>> 
>> returns a pointer that appears to be valid (0x3001E000) but causes a
>> kernel OOPS when accessed.
>> 
>> Previous calls to mmap in pcm_hw.c on lines 822 and 854 both
>> succeed, and the pointers returned can be successfully accessed, but
>> they use the status and control offsets as parameters to mmap.
>> 
>> I haved traced the problem on the target into the ALSA library using
>> gdb and into the kernel using kgdb and everything looks like it
>> works properly.  If I disable the semaphore acquisition in do_mmap2,
>> I can print the contents of the address in kgdb using
>> 
>>    (gdb) print ((char *)vma->vm_start)[0]
>> 
>> after the call to vm_link in do_mmap_pgoff.  However, the board
>> locks up after the print command.
>> 
>> Anyone have any experience with this type of problem on PowerPC systems?
> 
> Possibly a memory coherency problem.  The memory allocated via
> dma_alloc_coherent() isn't simply mmappable.
> 
> An essential fix would be to add dma_mmap_coherent() to all
> architectures and use it for ALSA mmap.  I made some patches quite
> ago, but left it rotten for the time being...
> 

The kernel I am using has this line in the .config file

   CONFIG_NOT_COHERENT_CACHE=y

It also has

   arch\ppc\kernel\dma-mapping.c

with

/*
 * Allocate DMA-coherent memory space and return both the kernel
remapped
 * virtual and bus address for that space.
 */
void *
__dma_alloc_coherent(size_t size, dma_addr_t *handle, int gfp)

defined and

   include\asm-ppc\dma-mapping.h

with

static inline void *dma_alloc_coherent(struct device *dev, size_t size,
                       dma_addr_t * dma_handle, int gfp)
{
#ifdef CONFIG_NOT_COHERENT_CACHE
    return __dma_alloc_coherent(size, dma_handle, gfp);
#else

defined.  However, if I put a breakpoint in __dma_alloc_coherent, it
does not appear to get called.  Is there something special I have to
do to ALSA to get it to use the ppc version of dma_alloc_coherent?

Pardon me for e-mailing you directly if that was not polite behavior
for this list.

-- 
Thank you,
David Cullen
Teligy

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[David Cullen]

Dear Mr. Iwai,

I see that you are back from your vacation.  I hope it was an
ejoyable one.

In alsa-driver-1.0.13/acore/memalloc.c there is this section of code

/*
 *  Hacks
 */

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0)
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 5)

I am using a patched 2.6.13 kernel.  Should I change that last line
to be KERNEL_VERSION(2, 6, 13)?

Also, could you give me some pointers regarding my previous e-mails
regarding this issue:

Takashi Iwai wrote:
> At Mon, 27 Nov 2006 17:01:52 -0500,
> David Cullen wrote:
>>
>> I am trying to get ALSA version 1.0.13 working on an AMCC PowerPC
>> PPC405EP Taihu board with a Sound Blaster Live! 24-bit 7.1 PCI
>> card.  I am using a patched 2.6.13 kernel that comes with the
>> board.  I built the kernel with the sound core built in and I
>> used the cross-compiler tools to build the ALSA driver, library,
>> and utils. When I run "speaker-test", it crashes in the ALSA
>> library.  The problem is that the call to mmap in
>>
>>    alsa-lib-1.0.13/src/pcm/pcm_mmap.c line 367
>>
>> which looks like
>>
>>    ptr = mmap(NULL, size, PROT_READ|PROT_WRITE,
>> MAP_FILE|MAP_SHARED, i->u.mmap.fd, i->u.mmap.offset);
>>
>> returns a pointer that appears to be valid (0x3001E000) but
>> causes a kernel OOPS when accessed.
>>
>> Previous calls to mmap in pcm_hw.c on lines 822 and 854 both
>> succeed, and the pointers returned can be successfully accessed,
>> but they use the status and control offsets as parameters to
>> mmap.
>>
>> I haved traced the problem on the target into the ALSA library
>> using gdb and into the kernel using kgdb and everything looks
>> like it works properly.  If I disable the semaphore acquisition
>> in do_mmap2, I can print the contents of the address in kgdb
>> using
>>
>>    (gdb) print ((char *)vma->vm_start)[0]
>>
>> after the call to vm_link in do_mmap_pgoff.  However, the board
>> locks up after the print command.
>>
>> Anyone have any experience with this type of problem on PowerPC
>> systems?
>
> Possibly a memory coherency problem.  The memory allocated via
> dma_alloc_coherent() isn't simply mmappable.
>
> An essential fix would be to add dma_mmap_coherent() to all
> architectures and use it for ALSA mmap.  I made some patches quite
> ago, but left it rotten for the time being...
>

How do I "add dma_mmap_coherent() to all architectures and use it
for ALSA mmap"?

The kernel I am using has this line in the .config file

   CONFIG_NOT_COHERENT_CACHE=y

It also has

   arch\ppc\kernel\dma-mapping.c

with

/*
 * Allocate DMA-coherent memory space and return both the kernel
remapped
 * virtual and bus address for that space.
 */
void *
__dma_alloc_coherent(size_t size, dma_addr_t *handle, int gfp)

defined and

   include\asm-ppc\dma-mapping.h

with

static inline void *dma_alloc_coherent(struct device *dev, size_t size,
                       dma_addr_t * dma_handle, int gfp)
{
#ifdef CONFIG_NOT_COHERENT_CACHE
    return __dma_alloc_coherent(size, dma_handle, gfp);
#else

defined.  However, if I put a breakpoint in __dma_alloc_coherent, it
does not appear to get called.  Is there something special I have to
do to ALSA to get it to use the ppc version of dma_alloc_coherent?

-- 
Thank you,
David Cullen
Teligy


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[Takashi Iwai]

At Tue, 19 Dec 2006 10:12:54 -0500,
David Cullen wrote:
> In alsa-driver-1.0.13/acore/memalloc.c there is this section of code
> 
> /*
>  *  Hacks
>  */
> 
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0)
> #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 5)
> 
> I am using a patched 2.6.13 kernel.  Should I change that last line
> to be KERNEL_VERSION(2, 6, 13)?

That part is a workaround only for the old 2.6 kernels which cause
Oops when NULL is passed to device pointer.  So, it should be
irrelevant.

> Also, could you give me some pointers regarding my previous e-mails
> regarding this issue:
> 
> Takashi Iwai wrote:
> > At Mon, 27 Nov 2006 17:01:52 -0500,
> > David Cullen wrote:
> >>
> >> I am trying to get ALSA version 1.0.13 working on an AMCC PowerPC
> >> PPC405EP Taihu board with a Sound Blaster Live! 24-bit 7.1 PCI
> >> card.  I am using a patched 2.6.13 kernel that comes with the
> >> board.  I built the kernel with the sound core built in and I
> >> used the cross-compiler tools to build the ALSA driver, library,
> >> and utils. When I run "speaker-test", it crashes in the ALSA
> >> library.  The problem is that the call to mmap in
> >>
> >>    alsa-lib-1.0.13/src/pcm/pcm_mmap.c line 367
> >>
> >> which looks like
> >>
> >>    ptr = mmap(NULL, size, PROT_READ|PROT_WRITE,
> >> MAP_FILE|MAP_SHARED, i->u.mmap.fd, i->u.mmap.offset);
> >>
> >> returns a pointer that appears to be valid (0x3001E000) but
> >> causes a kernel OOPS when accessed.
> >>
> >> Previous calls to mmap in pcm_hw.c on lines 822 and 854 both
> >> succeed, and the pointers returned can be successfully accessed,
> >> but they use the status and control offsets as parameters to
> >> mmap.
> >>
> >> I haved traced the problem on the target into the ALSA library
> >> using gdb and into the kernel using kgdb and everything looks
> >> like it works properly.  If I disable the semaphore acquisition
> >> in do_mmap2, I can print the contents of the address in kgdb
> >> using
> >>
> >>    (gdb) print ((char *)vma->vm_start)[0]
> >>
> >> after the call to vm_link in do_mmap_pgoff.  However, the board
> >> locks up after the print command.
> >>
> >> Anyone have any experience with this type of problem on PowerPC
> >> systems?
> >
> > Possibly a memory coherency problem.  The memory allocated via
> > dma_alloc_coherent() isn't simply mmappable.
> >
> > An essential fix would be to add dma_mmap_coherent() to all
> > architectures and use it for ALSA mmap.  I made some patches quite
> > ago, but left it rotten for the time being...
> >
> 
> How do I "add dma_mmap_coherent() to all architectures and use it
> for ALSA mmap"?

Well, for that, we need to patch the kernel itself and add
dma_mmap_coherent() call.  The problem is that the memory returned
from dma_alloc_coherent() isn't the address of the really allocated
pages in your case.  Since the ALSA mmap mode obtains the page via
virt_to_page(), this doesn't work.  Thus, a new function,
dma_mmap_coherent() is required to calculate the real page address and
do the rest of low-level mmap jobs.

A simple solution would be simply disable mmap.
In pci/ca0106/ca0106_main.c, remove SNDRV_PCM_INFO_MMAP and
SNDRV_PCM_INFO_MMAP_VALID from snd_ca0106_playback_hw and
snd_ca0106_capture_hw structs.

Also, disable #if defined(CONFIG_PPC) around
snd_pcm_mmap_status_*() in core/pcm_native.c.

This will reduce the sound system functionality (e.g. no dmix is
available), though.

BTW, any chance to try a newer version of kernel?
I don't want to debug the issues of old kernels but rather fix the
latest kernel...


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[David Cullen]

Takashi Iwai wrote:
> At Tue, 19 Dec 2006 10:12:54 -0500,
> David Cullen wrote:
>> In alsa-driver-1.0.13/acore/memalloc.c there is this section of code
>> 
>> /*
>>  *  Hacks
>>  */
>> 
>> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0)
>> #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 5)
>> 
>> I am using a patched 2.6.13 kernel.  Should I change that last line
>> to be KERNEL_VERSION(2, 6, 13)?
> 
> That part is a workaround only for the old 2.6 kernels which cause
> Oops when NULL is passed to device pointer.  So, it should be
> irrelevant.
> 

OK.  After more closely examining that code, I see that for my
kernel, this code is used

#else

/* for 2.2/2.4 kernels */
#if defined(CONFIG_PCI) || defined(CONFIG_ISA) || defined(__i386__)
#define dma_alloc_coherent(dev,size,addr,flags)
pci_alloc_consistent((struct pci_dev *)(dev),size,addr)
#define dma_free_coherent(dev,size,ptr,addr)
pci_free_consistent((struct pci_dev *)(dev),size,ptr,addr)
#elif CONFIG_SBUS
#define dma_alloc_coherent(dev,size,addr,flags)
sbus_alloc_consistent((struct sbus_dev *)(dev),size,addr)
#define dma_free_coherent(dev,size,ptr,addr)
sbus_free_consistent((struct sbus_dev *)(dev),size,ptr,addr)
#else
#error "Need a bus for dma_alloc_coherent()"
#endif

Which means pci_alloc_consistent is called instead of
__dma_alloc_coherent.

>> Also, could you give me some pointers regarding my previous e-mails
>> regarding this issue:
>> 
>> Takashi Iwai wrote:
>> > At Mon, 27 Nov 2006 17:01:52 -0500,
>> > David Cullen wrote:
>> >>
>> >> I am trying to get ALSA version 1.0.13 working on an AMCC PowerPC
>> >> PPC405EP Taihu board with a Sound Blaster Live! 24-bit 7.1 PCI
>> >> card.  I am using a patched 2.6.13 kernel that comes with the
>> >> board.  I built the kernel with the sound core built in and I
>> >> used the cross-compiler tools to build the ALSA driver, library,
>> >> and utils. When I run "speaker-test", it crashes in the ALSA
>> >> library.  The problem is that the call to mmap in
>> >>
>> >>    alsa-lib-1.0.13/src/pcm/pcm_mmap.c line 367
>> >>
>> >> which looks like
>> >>
>> >>    ptr = mmap(NULL, size, PROT_READ|PROT_WRITE,
>> >> MAP_FILE|MAP_SHARED, i->u.mmap.fd, i->u.mmap.offset);
>> >>
>> >> returns a pointer that appears to be valid (0x3001E000) but
>> >> causes a kernel OOPS when accessed.
>> >>
>> >> Previous calls to mmap in pcm_hw.c on lines 822 and 854 both
>> >> succeed, and the pointers returned can be successfully accessed,
>> >> but they use the status and control offsets as parameters to
>> >> mmap.
>> >>
>> >> I haved traced the problem on the target into the ALSA library
>> >> using gdb and into the kernel using kgdb and everything looks
>> >> like it works properly.  If I disable the semaphore acquisition
>> >> in do_mmap2, I can print the contents of the address in kgdb
>> >> using
>> >>
>> >>    (gdb) print ((char *)vma->vm_start)[0]
>> >>
>> >> after the call to vm_link in do_mmap_pgoff.  However, the board
>> >> locks up after the print command.
>> >>
>> >> Anyone have any experience with this type of problem on PowerPC
>> >> systems?
>> >
>> > Possibly a memory coherency problem.  The memory allocated via
>> > dma_alloc_coherent() isn't simply mmappable.
>> >
>> > An essential fix would be to add dma_mmap_coherent() to all
>> > architectures and use it for ALSA mmap.  I made some patches quite
>> > ago, but left it rotten for the time being...
>> >
>> 
>> How do I "add dma_mmap_coherent() to all architectures and use it
>> for ALSA mmap"?
> 
> Well, for that, we need to patch the kernel itself and add
> dma_mmap_coherent() call.  The problem is that the memory returned
> from dma_alloc_coherent() isn't the address of the really allocated
> pages in your case.  Since the ALSA mmap mode obtains the page via
> virt_to_page(), this doesn't work.  Thus, a new function,
> dma_mmap_coherent() is required to calculate the real page address and
> do the rest of low-level mmap jobs.

Where would dma_mmap_coherent be placed?  Which specific file?
Would I replace all calls to mmap with dma_mmap_coherent?  I can
probably figure out how to implement it if you can give me an
example for another architecture.  I tried looking at old patches on
the web, but I had difficulty understanding them.  I think they were
for the ARM architecture.

> A simple solution would be simply disable mmap.
> In pci/ca0106/ca0106_main.c, remove SNDRV_PCM_INFO_MMAP and
> SNDRV_PCM_INFO_MMAP_VALID from snd_ca0106_playback_hw and
> snd_ca0106_capture_hw structs.
> 
> Also, disable #if defined(CONFIG_PPC) around
> snd_pcm_mmap_status_*() in core/pcm_native.c.
> 
> This will reduce the sound system functionality (e.g. no dmix is
> available), though.

At this point, if we can get speaker-test to work, we will be happy.
 So dmix is not necessary (I believe...).  However, I do not know
the complete details of the end user's application, so dmix may be
needed eventually.  If you can give me a few pointers on how to
implement dma_mmap_coherent and sew it into ALSA, that would really
help.

> BTW, any chance to try a newer version of kernel?
> I don't want to debug the issues of old kernels but rather fix the
> latest kernel...

Unfortunately, we're stuck with the 2.6.13 kernel.  We are working
with the AMCC Taihu evaluation board, and the kernel source that
comes with it has been heavily patched to work with that board.
Upgrading the patches to work with a newer kernel is outside the
scope of what we agreed to do.  If you cannot help us as long as we
use the older kernel, I will pass along the information to my manager.

-- 
Thank you,
David Cullen
Teligy

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[Takashi Iwai]

At Wed, 20 Dec 2006 13:29:58 -0500,
David Cullen wrote:
> 
> Takashi Iwai wrote:
> > At Tue, 19 Dec 2006 10:12:54 -0500,
> > David Cullen wrote:
> >> In alsa-driver-1.0.13/acore/memalloc.c there is this section of code
> >> 
> >> /*
> >>  *  Hacks
> >>  */
> >> 
> >> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0)
> >> #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 5)
> >> 
> >> I am using a patched 2.6.13 kernel.  Should I change that last line
> >> to be KERNEL_VERSION(2, 6, 13)?
> > 
> > That part is a workaround only for the old 2.6 kernels which cause
> > Oops when NULL is passed to device pointer.  So, it should be
> > irrelevant.
> > 
> 
> OK.  After more closely examining that code, I see that for my
> kernel, this code is used
> 
> #else
> 
> /* for 2.2/2.4 kernels */
> #if defined(CONFIG_PCI) || defined(CONFIG_ISA) || defined(__i386__)
> #define dma_alloc_coherent(dev,size,addr,flags)
> pci_alloc_consistent((struct pci_dev *)(dev),size,addr)
> #define dma_free_coherent(dev,size,ptr,addr)
> pci_free_consistent((struct pci_dev *)(dev),size,ptr,addr)
> #elif CONFIG_SBUS
> #define dma_alloc_coherent(dev,size,addr,flags)
> sbus_alloc_consistent((struct sbus_dev *)(dev),size,addr)
> #define dma_free_coherent(dev,size,ptr,addr)
> sbus_free_consistent((struct sbus_dev *)(dev),size,ptr,addr)
> #else
> #error "Need a bus for dma_alloc_coherent()"
> #endif
> 
> Which means pci_alloc_consistent is called instead of
> __dma_alloc_coherent.

pci_alloc_consistent() is used only on 2.2/2.4 kernels.
All 2.6.x kernels are using dma_alloc_coherent().


> >> Also, could you give me some pointers regarding my previous e-mails
> >> regarding this issue:
> >> 
> >> Takashi Iwai wrote:
> >> > At Mon, 27 Nov 2006 17:01:52 -0500,
> >> > David Cullen wrote:
> >> >>
> >> >> I am trying to get ALSA version 1.0.13 working on an AMCC PowerPC
> >> >> PPC405EP Taihu board with a Sound Blaster Live! 24-bit 7.1 PCI
> >> >> card.  I am using a patched 2.6.13 kernel that comes with the
> >> >> board.  I built the kernel with the sound core built in and I
> >> >> used the cross-compiler tools to build the ALSA driver, library,
> >> >> and utils. When I run "speaker-test", it crashes in the ALSA
> >> >> library.  The problem is that the call to mmap in
> >> >>
> >> >>    alsa-lib-1.0.13/src/pcm/pcm_mmap.c line 367
> >> >>
> >> >> which looks like
> >> >>
> >> >>    ptr = mmap(NULL, size, PROT_READ|PROT_WRITE,
> >> >> MAP_FILE|MAP_SHARED, i->u.mmap.fd, i->u.mmap.offset);
> >> >>
> >> >> returns a pointer that appears to be valid (0x3001E000) but
> >> >> causes a kernel OOPS when accessed.
> >> >>
> >> >> Previous calls to mmap in pcm_hw.c on lines 822 and 854 both
> >> >> succeed, and the pointers returned can be successfully accessed,
> >> >> but they use the status and control offsets as parameters to
> >> >> mmap.
> >> >>
> >> >> I haved traced the problem on the target into the ALSA library
> >> >> using gdb and into the kernel using kgdb and everything looks
> >> >> like it works properly.  If I disable the semaphore acquisition
> >> >> in do_mmap2, I can print the contents of the address in kgdb
> >> >> using
> >> >>
> >> >>    (gdb) print ((char *)vma->vm_start)[0]
> >> >>
> >> >> after the call to vm_link in do_mmap_pgoff.  However, the board
> >> >> locks up after the print command.
> >> >>
> >> >> Anyone have any experience with this type of problem on PowerPC
> >> >> systems?
> >> >
> >> > Possibly a memory coherency problem.  The memory allocated via
> >> > dma_alloc_coherent() isn't simply mmappable.
> >> >
> >> > An essential fix would be to add dma_mmap_coherent() to all
> >> > architectures and use it for ALSA mmap.  I made some patches quite
> >> > ago, but left it rotten for the time being...
> >> >
> >> 
> >> How do I "add dma_mmap_coherent() to all architectures and use it
> >> for ALSA mmap"?
> > 
> > Well, for that, we need to patch the kernel itself and add
> > dma_mmap_coherent() call.  The problem is that the memory returned
> > from dma_alloc_coherent() isn't the address of the really allocated
> > pages in your case.  Since the ALSA mmap mode obtains the page via
> > virt_to_page(), this doesn't work.  Thus, a new function,
> > dma_mmap_coherent() is required to calculate the real page address and
> > do the rest of low-level mmap jobs.
> 
> Where would dma_mmap_coherent be placed?  Which specific file?

It's somewhere in arch/*/* directory.

> Would I replace all calls to mmap with dma_mmap_coherent?  I can
> probably figure out how to implement it if you can give me an
> example for another architecture.  I tried looking at old patches on
> the web, but I had difficulty understanding them.  I think they were
> for the ARM architecture.

Yes, ARM has already it.

> > A simple solution would be simply disable mmap.
> > In pci/ca0106/ca0106_main.c, remove SNDRV_PCM_INFO_MMAP and
> > SNDRV_PCM_INFO_MMAP_VALID from snd_ca0106_playback_hw and
> > snd_ca0106_capture_hw structs.
> > 
> > Also, disable #if defined(CONFIG_PPC) around
> > snd_pcm_mmap_status_*() in core/pcm_native.c.
> > 
> > This will reduce the sound system functionality (e.g. no dmix is
> > available), though.
> 
> At this point, if we can get speaker-test to work, we will be happy.
>  So dmix is not necessary (I believe...).  However, I do not know
> the complete details of the end user's application, so dmix may be
> needed eventually.  If you can give me a few pointers on how to
> implement dma_mmap_coherent and sew it into ALSA, that would really
> help.

When mmap is disabled in the driver, change the default alsa-lib
configuration, too.  Either edit alsa-lib/src/conf/cards/CA0106.conf
or override the default PCM configuration in /etc/asound.conf, such as
	pcm.!default plughw


> > BTW, any chance to try a newer version of kernel?
> > I don't want to debug the issues of old kernels but rather fix the
> > latest kernel...
> 
> Unfortunately, we're stuck with the 2.6.13 kernel.  We are working
> with the AMCC Taihu evaluation board, and the kernel source that
> comes with it has been heavily patched to work with that board.
> Upgrading the patches to work with a newer kernel is outside the
> scope of what we agreed to do.  If you cannot help us as long as we
> use the older kernel, I will pass along the information to my manager.

OK, that's what I was afraid of...


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[David Cullen]

Dear Mr. Iwai,

1000 thank yous for your help so far.  I have a few more questions
to ask.

Takashi Iwai wrote:
> At Wed, 20 Dec 2006 13:29:58 -0500,
> David Cullen wrote:
>> 
>> Takashi Iwai wrote:
>> > At Tue, 19 Dec 2006 10:12:54 -0500,
>> > David Cullen wrote:
>> >> In alsa-driver-1.0.13/acore/memalloc.c there is this section of code
>> >> 
>> >> /*
>> >>  *  Hacks
>> >>  */
>> >> 
>> >> #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0)
>> >> #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 5)
>> >> 
>> >> I am using a patched 2.6.13 kernel.  Should I change that last line
>> >> to be KERNEL_VERSION(2, 6, 13)?
>> > 
>> > That part is a workaround only for the old 2.6 kernels which cause
>> > Oops when NULL is passed to device pointer.  So, it should be
>> > irrelevant.
>> > 
>> 
>> OK.  After more closely examining that code, I see that for my
>> kernel, this code is used
>> 
>> #else
>> 
>> /* for 2.2/2.4 kernels */
>> #if defined(CONFIG_PCI) || defined(CONFIG_ISA) || defined(__i386__)
>> #define dma_alloc_coherent(dev,size,addr,flags)
>> pci_alloc_consistent((struct pci_dev *)(dev),size,addr)
>> #define dma_free_coherent(dev,size,ptr,addr)
>> pci_free_consistent((struct pci_dev *)(dev),size,ptr,addr)
>> #elif CONFIG_SBUS
>> #define dma_alloc_coherent(dev,size,addr,flags)
>> sbus_alloc_consistent((struct sbus_dev *)(dev),size,addr)
>> #define dma_free_coherent(dev,size,ptr,addr)
>> sbus_free_consistent((struct sbus_dev *)(dev),size,ptr,addr)
>> #else
>> #error "Need a bus for dma_alloc_coherent()"
>> #endif
>> 
>> Which means pci_alloc_consistent is called instead of
>> __dma_alloc_coherent.
> 
> pci_alloc_consistent() is used only on 2.2/2.4 kernels.
> All 2.6.x kernels are using dma_alloc_coherent().
> 
> 

That does not appear to be the case in this kernel.  Once again, by
examining the #if statements, I am left with this code being
included for 2.6.13:

#endif /* < 2.6.5 */

#else

/* for 2.2/2.4 kernels */
#if defined(CONFIG_PCI) || defined(CONFIG_ISA) || defined(__i386__)
#define dma_alloc_coherent(dev,size,addr,flags)
pci_alloc_consistent((struct pci_dev *)(dev),size,addr)
#define dma_free_coherent(dev,size,ptr,addr)
pci_free_consistent((struct pci_dev *)(dev),size,ptr,addr)
#elif CONFIG_SBUS
#define dma_alloc_coherent(dev,size,addr,flags)
sbus_alloc_consistent((struct sbus_dev *)(dev),size,addr)
#define dma_free_coherent(dev,size,ptr,addr)
sbus_free_consistent((struct sbus_dev *)(dev),size,ptr,addr)
#else
#error "Need a bus for dma_alloc_coherent()"
#endif

#endif /* >= 2.6.0 */

NOTE: If the lines

#endif /* < 2.6.5 */

#else

were replaced with something like this

#else
static void *snd_dma_alloc_coherent1(struct device *dev,
    size_t size, dma_addr_t *dma_handle, int flags)
{
    /* No need to check dev on 2.6.5 and greater... */
    return dma_alloc_coherent(dev, size, dma_handle, flags);
}

static void snd_dma_free_coherent1(struct device *dev, size_t size,
    void *dma_addr, dma_addr_t dma_handle)
{
    /* No need to check dev on 2.6.5 and greater... */
    return dma_free_coherent(dev, size, dma_addr, dma_handle);
}
#endif /* < 2.6.5 */

#else

then what you are asserting would make sense to me.

>> >> Also, could you give me some pointers regarding my previous e-mails
>> >> regarding this issue:
>> >> 
>> >> Takashi Iwai wrote:
>> >> > At Mon, 27 Nov 2006 17:01:52 -0500,
>> >> > David Cullen wrote:
>> >> >>
>> >> >> I am trying to get ALSA version 1.0.13 working on an AMCC PowerPC
>> >> >> PPC405EP Taihu board with a Sound Blaster Live! 24-bit 7.1 PCI
>> >> >> card.  I am using a patched 2.6.13 kernel that comes with the
>> >> >> board.  I built the kernel with the sound core built in and I
>> >> >> used the cross-compiler tools to build the ALSA driver, library,
>> >> >> and utils. When I run "speaker-test", it crashes in the ALSA
>> >> >> library.  The problem is that the call to mmap in
>> >> >>
>> >> >>    alsa-lib-1.0.13/src/pcm/pcm_mmap.c line 367
>> >> >>
>> >> >> which looks like
>> >> >>
>> >> >>    ptr = mmap(NULL, size, PROT_READ|PROT_WRITE,
>> >> >> MAP_FILE|MAP_SHARED, i->u.mmap.fd, i->u.mmap.offset);
>> >> >>
>> >> >> returns a pointer that appears to be valid (0x3001E000) but
>> >> >> causes a kernel OOPS when accessed.
>> >> >>
>> >> >> Previous calls to mmap in pcm_hw.c on lines 822 and 854 both
>> >> >> succeed, and the pointers returned can be successfully accessed,
>> >> >> but they use the status and control offsets as parameters to
>> >> >> mmap.
>> >> >>
>> >> >> I haved traced the problem on the target into the ALSA library
>> >> >> using gdb and into the kernel using kgdb and everything looks
>> >> >> like it works properly.  If I disable the semaphore acquisition
>> >> >> in do_mmap2, I can print the contents of the address in kgdb
>> >> >> using
>> >> >>
>> >> >>    (gdb) print ((char *)vma->vm_start)[0]
>> >> >>
>> >> >> after the call to vm_link in do_mmap_pgoff.  However, the board
>> >> >> locks up after the print command.
>> >> >>
>> >> >> Anyone have any experience with this type of problem on PowerPC
>> >> >> systems?
>> >> >
>> >> > Possibly a memory coherency problem.  The memory allocated via
>> >> > dma_alloc_coherent() isn't simply mmappable.
>> >> >
>> >> > An essential fix would be to add dma_mmap_coherent() to all
>> >> > architectures and use it for ALSA mmap.  I made some patches quite
>> >> > ago, but left it rotten for the time being...
>> >> >
>> >> 
>> >> How do I "add dma_mmap_coherent() to all architectures and use it
>> >> for ALSA mmap"?
>> > 
>> > Well, for that, we need to patch the kernel itself and add
>> > dma_mmap_coherent() call.  The problem is that the memory returned
>> > from dma_alloc_coherent() isn't the address of the really allocated
>> > pages in your case.  Since the ALSA mmap mode obtains the page via
>> > virt_to_page(), this doesn't work.  Thus, a new function,
>> > dma_mmap_coherent() is required to calculate the real page address and
>> > do the rest of low-level mmap jobs.
>> 
>> Where would dma_mmap_coherent be placed?  Which specific file?
> 
> It's somewhere in arch/*/* directory.
> 
>> Would I replace all calls to mmap with dma_mmap_coherent?  I can
>> probably figure out how to implement it if you can give me an
>> example for another architecture.  I tried looking at old patches on
>> the web, but I had difficulty understanding them.  I think they were
>> for the ARM architecture.
> 
> Yes, ARM has already it.
>

In arch/arm/mm/consistent.c I find the following lines:

int dma_mmap_coherent(struct device *dev,
    struct vm_area_struct *vma, void *cpu_addr,
    dma_addr_t dma_addr, size_t size)
{
    vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
    return dma_mmap(dev, vma, cpu_addr, dma_addr, size);
}
EXPORT_SYMBOL(dma_mmap_coherent);

Can I add this code verbatim to a file in arch/ppc/mm?  For example,
could I add it to 4xx_mmu.c?  Or do I need to make a copy of
consistent.c in arch/ppc/mm?  I apologize for all the questions, but
when I look at this code I am reminded of the quote from ADVENT:
"You are in a maze of twisty little passages, all alike."

>> > A simple solution would be simply disable mmap.
>> > In pci/ca0106/ca0106_main.c, remove SNDRV_PCM_INFO_MMAP and
>> > SNDRV_PCM_INFO_MMAP_VALID from snd_ca0106_playback_hw and
>> > snd_ca0106_capture_hw structs.
>> > 
>> > Also, disable #if defined(CONFIG_PPC) around
>> > snd_pcm_mmap_status_*() in core/pcm_native.c.
>> > 
>> > This will reduce the sound system functionality (e.g. no dmix is
>> > available), though.
>> 
>> At this point, if we can get speaker-test to work, we will be happy.
>>  So dmix is not necessary (I believe...).  However, I do not know
>> the complete details of the end user's application, so dmix may be
>> needed eventually.  If you can give me a few pointers on how to
>> implement dma_mmap_coherent and sew it into ALSA, that would really
>> help.
> 
> When mmap is disabled in the driver, change the default alsa-lib
> configuration, too.  Either edit alsa-lib/src/conf/cards/CA0106.conf
> or override the default PCM configuration in /etc/asound.conf, such as
> 	pcm.!default plughw
> 
> 

Currently, /etc/asound.conf is

pcm.ca0106 {
    type hw
    card 0
}

ctl.ca0106 {
    type hw
    card 0
}

I am confused about where is the right place to put

    pcm.!default plughw

Do I just add another section that looks like this

pcm.!default {
    type plughw
    card 0
}

or do I just add the line to asound.conf?

>> > BTW, any chance to try a newer version of kernel?
>> > I don't want to debug the issues of old kernels but rather fix the
>> > latest kernel...
>> 
>> Unfortunately, we're stuck with the 2.6.13 kernel.  We are working
>> with the AMCC Taihu evaluation board, and the kernel source that
>> comes with it has been heavily patched to work with that board.
>> Upgrading the patches to work with a newer kernel is outside the
>> scope of what we agreed to do.  If you cannot help us as long as we
>> use the older kernel, I will pass along the information to my manager.
> 
> OK, that's what I was afraid of...

Yes, sorry.  Again, 1000 thank yous for the help you have already
given me.  While I can write device drivers and applications, I am
not used to delving into the details of memory management for such
complicated software as the ALSA drivers and library, especially on
an esoteric architecture.

I will stab forward with the no-mmap approach first after reviewing
your responses with my manager.

-- 
Thank you,
David Cullen
Teligy


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[David Cullen]

Dear Mr. Iwai,

I made the changes you suggested to work around the problem with
mmap.  However, when I run speaker-test now, I get another problem:

/usr/local/src/files # speaker-test

speaker-test 1.0.13

Playback device is default
Stream parameters are 48000Hz, S16_BE, 1 channels
Using 16 octaves of pink noise
ALSA lib pcm_plug.c:773:(snd_pcm_plug_hw_refine_schange) Unable to
find an usable access for 'default'
Sample format not available for playback: Invalid argument
Setting of hwparams failed: Invalid argument

This is my asound.conf file:

pcm.ca0106 {
    type hw
    card 0
}

ctl.ca0106 {
    type hw
    card 0
}

pcm.!default plughw

What am I doing wrong?

-- 
Thank you,
David Cullen
Teligy
(864) 527-1263 Office
(864) 415-7063 Cell

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[Takashi Iwai]

At Wed, 20 Dec 2006 14:06:37 -0500,
David Cullen wrote:
> 
> >> >> Also, could you give me some pointers regarding my previous e-mails
> >> >> regarding this issue:
> >> >> 
> >> >> Takashi Iwai wrote:
> >> >> > At Mon, 27 Nov 2006 17:01:52 -0500,
> >> >> > David Cullen wrote:
> >> >> >>
> >> >> >> I am trying to get ALSA version 1.0.13 working on an AMCC PowerPC
> >> >> >> PPC405EP Taihu board with a Sound Blaster Live! 24-bit 7.1 PCI
> >> >> >> card.  I am using a patched 2.6.13 kernel that comes with the
> >> >> >> board.  I built the kernel with the sound core built in and I
> >> >> >> used the cross-compiler tools to build the ALSA driver, library,
> >> >> >> and utils. When I run "speaker-test", it crashes in the ALSA
> >> >> >> library.  The problem is that the call to mmap in
> >> >> >>
> >> >> >>    alsa-lib-1.0.13/src/pcm/pcm_mmap.c line 367
> >> >> >>
> >> >> >> which looks like
> >> >> >>
> >> >> >>    ptr = mmap(NULL, size, PROT_READ|PROT_WRITE,
> >> >> >> MAP_FILE|MAP_SHARED, i->u.mmap.fd, i->u.mmap.offset);
> >> >> >>
> >> >> >> returns a pointer that appears to be valid (0x3001E000) but
> >> >> >> causes a kernel OOPS when accessed.
> >> >> >>
> >> >> >> Previous calls to mmap in pcm_hw.c on lines 822 and 854 both
> >> >> >> succeed, and the pointers returned can be successfully accessed,
> >> >> >> but they use the status and control offsets as parameters to
> >> >> >> mmap.
> >> >> >>
> >> >> >> I haved traced the problem on the target into the ALSA library
> >> >> >> using gdb and into the kernel using kgdb and everything looks
> >> >> >> like it works properly.  If I disable the semaphore acquisition
> >> >> >> in do_mmap2, I can print the contents of the address in kgdb
> >> >> >> using
> >> >> >>
> >> >> >>    (gdb) print ((char *)vma->vm_start)[0]
> >> >> >>
> >> >> >> after the call to vm_link in do_mmap_pgoff.  However, the board
> >> >> >> locks up after the print command.
> >> >> >>
> >> >> >> Anyone have any experience with this type of problem on PowerPC
> >> >> >> systems?
> >> >> >
> >> >> > Possibly a memory coherency problem.  The memory allocated via
> >> >> > dma_alloc_coherent() isn't simply mmappable.
> >> >> >
> >> >> > An essential fix would be to add dma_mmap_coherent() to all
> >> >> > architectures and use it for ALSA mmap.  I made some patches quite
> >> >> > ago, but left it rotten for the time being...
> >> >> >
> >> >> 
> >> >> How do I "add dma_mmap_coherent() to all architectures and use it
> >> >> for ALSA mmap"?
> >> > 
> >> > Well, for that, we need to patch the kernel itself and add
> >> > dma_mmap_coherent() call.  The problem is that the memory returned
> >> > from dma_alloc_coherent() isn't the address of the really allocated
> >> > pages in your case.  Since the ALSA mmap mode obtains the page via
> >> > virt_to_page(), this doesn't work.  Thus, a new function,
> >> > dma_mmap_coherent() is required to calculate the real page address and
> >> > do the rest of low-level mmap jobs.
> >> 
> >> Where would dma_mmap_coherent be placed?  Which specific file?
> > 
> > It's somewhere in arch/*/* directory.
> > 
> >> Would I replace all calls to mmap with dma_mmap_coherent?  I can
> >> probably figure out how to implement it if you can give me an
> >> example for another architecture.  I tried looking at old patches on
> >> the web, but I had difficulty understanding them.  I think they were
> >> for the ARM architecture.
> > 
> > Yes, ARM has already it.
> >
> 
> In arch/arm/mm/consistent.c I find the following lines:
> 
> int dma_mmap_coherent(struct device *dev,
>     struct vm_area_struct *vma, void *cpu_addr,
>     dma_addr_t dma_addr, size_t size)
> {
>     vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>     return dma_mmap(dev, vma, cpu_addr, dma_addr, size);
> }
> EXPORT_SYMBOL(dma_mmap_coherent);
> 
> Can I add this code verbatim to a file in arch/ppc/mm?  For example,
> could I add it to 4xx_mmu.c?  Or do I need to make a copy of
> consistent.c in arch/ppc/mm?  I apologize for all the questions, but
> when I look at this code I am reminded of the quote from ADVENT:
> "You are in a maze of twisty little passages, all alike."

The implementation depends pretty much on the architecture.
(Also, dma_mmap() is no global function but specific only for ARM.)
Since the vm_region struct is different between ppc and arm (the page
pointer is missing in ppc version), it cannot be copied as it is.

A simple (but totally untested) version would be like below:

int dma_mmap_coherent(struct device *dev,
		struct vm_area_struct *vma, void *cpu_addr,
		dma_addr_t dma_addr, size_t size)
{
	unsigned long pfn;

	pfn = page_to_pfn(virt_to_page(bus_to_virt(dma_addr)));
	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
	return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
				vma->vm_end - vma->vm_start,
				vma->vm_pgprot);
}

(This might not work for some ppc models, though...)

Then either add .mmap callback to each of snd_pcm_ops table in ca0106
that calls dma_mmap_coherent() above, or change snd_pcm_default_mmap
to call dma_mmap_coherent() directly instead of nopage method.
For the former way, take a look at sound/arm/aaci.c (and devdma.c) as
a reference.

> 
> >> > A simple solution would be simply disable mmap.
> >> > In pci/ca0106/ca0106_main.c, remove SNDRV_PCM_INFO_MMAP and
> >> > SNDRV_PCM_INFO_MMAP_VALID from snd_ca0106_playback_hw and
> >> > snd_ca0106_capture_hw structs.
> >> > 
> >> > Also, disable #if defined(CONFIG_PPC) around
> >> > snd_pcm_mmap_status_*() in core/pcm_native.c.
> >> > 
> >> > This will reduce the sound system functionality (e.g. no dmix is
> >> > available), though.
> >> 
> >> At this point, if we can get speaker-test to work, we will be happy.
> >>  So dmix is not necessary (I believe...).  However, I do not know
> >> the complete details of the end user's application, so dmix may be
> >> needed eventually.  If you can give me a few pointers on how to
> >> implement dma_mmap_coherent and sew it into ALSA, that would really
> >> help.
> > 
> > When mmap is disabled in the driver, change the default alsa-lib
> > configuration, too.  Either edit alsa-lib/src/conf/cards/CA0106.conf
> > or override the default PCM configuration in /etc/asound.conf, such as
> > 	pcm.!default plughw
> > 
> > 
> 
> Currently, /etc/asound.conf is
> 
> pcm.ca0106 {
>     type hw
>     card 0
> }
> 
> ctl.ca0106 {
>     type hw
>     card 0
> }
> 
> I am confused about where is the right place to put
> 
>     pcm.!default plughw
> 
> Do I just add another section that looks like this
> 
> pcm.!default {
>     type plughw
>     card 0
> }
> 
> or do I just add the line to asound.conf?

The above (using aliasing) might work possibly only with the recent
alsa-lib.  With the older alsa-lib, you'd need to define the following
in /etc/asound.conf:

pcm.!default {
	type plug
	slave.pcm {
		type hw
		card 0
	}
}

This will override the default PCM.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[Takashi Iwai]

At Thu, 21 Dec 2006 11:07:04 -0500,
David Cullen wrote:
> 
> Dear Mr. Iwai,
> 
> I made the changes you suggested to work around the problem with
> mmap.  However, when I run speaker-test now, I get another problem:
> 
> /usr/local/src/files # speaker-test
> 
> speaker-test 1.0.13
> 
> Playback device is default
> Stream parameters are 48000Hz, S16_BE, 1 channels
> Using 16 octaves of pink noise
> ALSA lib pcm_plug.c:773:(snd_pcm_plug_hw_refine_schange) Unable to
> find an usable access for 'default'
> Sample format not available for playback: Invalid argument
> Setting of hwparams failed: Invalid argument
> 
> This is my asound.conf file:
> 
> pcm.ca0106 {
>     type hw
>     card 0
> }
> 
> ctl.ca0106 {
>     type hw
>     card 0
> }
> 
> pcm.!default plughw
> 
> What am I doing wrong?

As mentioned in the previous mail, it should be like

pcm.!default {
	type plug
	slave.pcm {
		type hw
		card 0
	}
}


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[David Cullen]

Dear Mr. Iwai,

Takashi Iwai wrote:
> As mentioned in the previous mail, it should be like
> 
> pcm.!default {
> 	type plug
> 	slave.pcm {
> 		type hw
> 		card 0
> 	}
> }

I put only those lines in my asound.conf file and I still got this
output:

/etc # speaker-test

speaker-test 1.0.13

Playback device is default
Stream parameters are 48000Hz, S16_BE, 1 channels
Using 16 octaves of pink noise
ALSA lib pcm_plug.c:773:(snd_pcm_plug_hw_refine_schange) Unable to
find an usable access for 'default'
Sample format not available for playback: Invalid argument
Setting of hwparams failed: Invalid argument

I put back the original ca0106 stuff at the beginning of my
asound.conf file, as in

pcm.ca0106 {
    type hw
    card 0
}

ctl.ca0106 {
    type hw
    card 0
}

pcm.!default {
    type plug
    slave.pcm {
        type hw
        card 0
    }
}

but I still got the same error when I ran speaker-test.  Should I
punt and try to implement your suggested version of dma_mmap_coherent?

-- 
Thank you,
David Cullen
Teligy
(864) 527-1263 Office
(864) 415-7063 Cell

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[Takashi Iwai]

At Thu, 21 Dec 2006 12:01:01 -0500,
David Cullen wrote:
> 
> Dear Mr. Iwai,
> 
> Takashi Iwai wrote:
> > As mentioned in the previous mail, it should be like
> > 
> > pcm.!default {
> > 	type plug
> > 	slave.pcm {
> > 		type hw
> > 		card 0
> > 	}
> > }
> 
> I put only those lines in my asound.conf file and I still got this
> output:
> 
> /etc # speaker-test
> 
> speaker-test 1.0.13
> 
> Playback device is default
> Stream parameters are 48000Hz, S16_BE, 1 channels
> Using 16 octaves of pink noise
> ALSA lib pcm_plug.c:773:(snd_pcm_plug_hw_refine_schange) Unable to
> find an usable access for 'default'
> Sample format not available for playback: Invalid argument
> Setting of hwparams failed: Invalid argument

Does aplay work?


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[David Cullen]

Takashi Iwai wrote:
> At Thu, 21 Dec 2006 12:01:01 -0500,
> David Cullen wrote:
>> 
>> Dear Mr. Iwai,
>> 
>> Takashi Iwai wrote:
>> > As mentioned in the previous mail, it should be like
>> > 
>> > pcm.!default {
>> > 	type plug
>> > 	slave.pcm {
>> > 		type hw
>> > 		card 0
>> > 	}
>> > }
>> 
>> I put only those lines in my asound.conf file and I still got this
>> output:
>> 
>> /etc # speaker-test
>> 
>> speaker-test 1.0.13
>> 
>> Playback device is default
>> Stream parameters are 48000Hz, S16_BE, 1 channels
>> Using 16 octaves of pink noise
>> ALSA lib pcm_plug.c:773:(snd_pcm_plug_hw_refine_schange) Unable to
>> find an usable access for 'default'
>> Sample format not available for playback: Invalid argument
>> Setting of hwparams failed: Invalid argument
> 
> Does aplay work?
> 
> Takashi

This is what happens when I try aplay:

/usr/share/sounds/alsa # aplay Noise.wav
Playing WAVE 'Noise.wav' : Signed 16 bit Little Endian, Rate 48000
Hz, Mono
ALSA lib pcm_plug.c:773:(snd_pcm_plug_hw_refine_schange) Unable to
find an usable access for 'default'
aplay: set_params:929: Channels count non available

Do I need to fire up gdb?

-- 
Thank you,
David Cullen
Teligy

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[Takashi Iwai]

At Thu, 21 Dec 2006 12:50:51 -0500,
David Cullen wrote:
> 
> Takashi Iwai wrote:
> > At Thu, 21 Dec 2006 12:01:01 -0500,
> > David Cullen wrote:
> >> 
> >> Dear Mr. Iwai,
> >> 
> >> Takashi Iwai wrote:
> >> > As mentioned in the previous mail, it should be like
> >> > 
> >> > pcm.!default {
> >> > 	type plug
> >> > 	slave.pcm {
> >> > 		type hw
> >> > 		card 0
> >> > 	}
> >> > }
> >> 
> >> I put only those lines in my asound.conf file and I still got this
> >> output:
> >> 
> >> /etc # speaker-test
> >> 
> >> speaker-test 1.0.13
> >> 
> >> Playback device is default
> >> Stream parameters are 48000Hz, S16_BE, 1 channels
> >> Using 16 octaves of pink noise
> >> ALSA lib pcm_plug.c:773:(snd_pcm_plug_hw_refine_schange) Unable to
> >> find an usable access for 'default'
> >> Sample format not available for playback: Invalid argument
> >> Setting of hwparams failed: Invalid argument
> > 
> > Does aplay work?
> > 
> > Takashi
> 
> This is what happens when I try aplay:
> 
> /usr/share/sounds/alsa # aplay Noise.wav
> Playing WAVE 'Noise.wav' : Signed 16 bit Little Endian, Rate 48000
> Hz, Mono
> ALSA lib pcm_plug.c:773:(snd_pcm_plug_hw_refine_schange) Unable to
> find an usable access for 'default'
> aplay: set_params:929: Channels count non available

Hm, this looks like you don't use plug layer?
Make sure that you have no ~/.asoundrc file.  Then try

	% aplay -Dplughw foo.wav

"plughw" is a standard PCM name defined in /usr/share/cards/alsa.conf,
so it should work even without /etc/asound.conf.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[David Cullen]

Takashi Iwai wrote:
> At Thu, 21 Dec 2006 12:50:51 -0500,
> David Cullen wrote:
>> 
>> Takashi Iwai wrote:
>> > At Thu, 21 Dec 2006 12:01:01 -0500,
>> > David Cullen wrote:
>> >> 
>> >> Dear Mr. Iwai,
>> >> 
>> >> Takashi Iwai wrote:
>> >> > As mentioned in the previous mail, it should be like
>> >> > 
>> >> > pcm.!default {
>> >> > 	type plug
>> >> > 	slave.pcm {
>> >> > 		type hw
>> >> > 		card 0
>> >> > 	}
>> >> > }
>> >> 
>> >> I put only those lines in my asound.conf file and I still got this
>> >> output:
>> >> 
>> >> /etc # speaker-test
>> >> 
>> >> speaker-test 1.0.13
>> >> 
>> >> Playback device is default
>> >> Stream parameters are 48000Hz, S16_BE, 1 channels
>> >> Using 16 octaves of pink noise
>> >> ALSA lib pcm_plug.c:773:(snd_pcm_plug_hw_refine_schange) Unable to
>> >> find an usable access for 'default'
>> >> Sample format not available for playback: Invalid argument
>> >> Setting of hwparams failed: Invalid argument
>> > 
>> > Does aplay work?
>> > 
>> > Takashi
>> 
>> This is what happens when I try aplay:
>> 
>> /usr/share/sounds/alsa # aplay Noise.wav
>> Playing WAVE 'Noise.wav' : Signed 16 bit Little Endian, Rate 48000
>> Hz, Mono
>> ALSA lib pcm_plug.c:773:(snd_pcm_plug_hw_refine_schange) Unable to
>> find an usable access for 'default'
>> aplay: set_params:929: Channels count non available
> 
> Hm, this looks like you don't use plug layer?
> Make sure that you have no ~/.asoundrc file.  Then try
> 
> 	% aplay -Dplughw foo.wav
> 
> "plughw" is a standard PCM name defined in /usr/share/cards/alsa.conf,
> so it should work even without /etc/asound.conf.
> 
> 
> Takashi
> 

I verified that there are no .asoundrc files in the filesystem.
However, this is the result of the aplay test:

/usr/share/sounds/alsa # aplay -Dplughw Noise.wav
ALSA lib pcm_hw.c:1358:(_snd_pcm_hw_open) Invalid value for card
aplay: main:556: audio open error: No such device

-- 
Thank you,
David Cullen
Teligy

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[David Cullen]

Dear Mr. Iwai,

Takashi Iwai wrote:
> 
> The implementation depends pretty much on the architecture.
> (Also, dma_mmap() is no global function but specific only for ARM.)
> Since the vm_region struct is different between ppc and arm (the page
> pointer is missing in ppc version), it cannot be copied as it is.
> 
> A simple (but totally untested) version would be like below:
> 
> int dma_mmap_coherent(struct device *dev,
> 		struct vm_area_struct *vma, void *cpu_addr,
> 		dma_addr_t dma_addr, size_t size)
> {
> 	unsigned long pfn;
> 
> 	pfn = page_to_pfn(virt_to_page(bus_to_virt(dma_addr)));
> 	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> 	return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
> 				vma->vm_end - vma->vm_start,
> 				vma->vm_pgprot);
> }
> 
> (This might not work for some ppc models, though...)
> 
> Then either add .mmap callback to each of snd_pcm_ops table in ca0106
> that calls dma_mmap_coherent() above, or change snd_pcm_default_mmap
> to call dma_mmap_coherent() directly instead of nopage method.
> For the former way, take a look at sound/arm/aaci.c (and devdma.c) as
> a reference.
> 

I implemented this solution but speaker-test hangs in pcm.c, line 2299:

(gdb) frame 1
#1  0x0ff1df40 in snd_pcm_wait_nocheck (pcm=0x10032830, timeout=-1)
    at pcm.c:2299
2299            err_poll = poll(pfd, npfds, timeout);

Any idea what is going wrong here?

-- 
Thank you,
David Cullen
Teligy
(864) 527-1263 Office
(864) 415-7063 Cell

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[David Cullen]

Dear Mr. Iwai,

Takashi Iwai wrote:
> The implementation depends pretty much on the architecture.
> (Also, dma_mmap() is no global function but specific only for ARM.)
> Since the vm_region struct is different between ppc and arm (the page
> pointer is missing in ppc version), it cannot be copied as it is.
> 
> A simple (but totally untested) version would be like below:
> 
> int dma_mmap_coherent(struct device *dev,
> 		struct vm_area_struct *vma, void *cpu_addr,
> 		dma_addr_t dma_addr, size_t size)
> {
> 	unsigned long pfn;
> 
> 	pfn = page_to_pfn(virt_to_page(bus_to_virt(dma_addr)));
> 	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> 	return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
> 				vma->vm_end - vma->vm_start,
> 				vma->vm_pgprot);
> }
> 
> (This might not work for some ppc models, though...)
> 
> Then either add .mmap callback to each of snd_pcm_ops table in ca0106
> that calls dma_mmap_coherent() above, or change snd_pcm_default_mmap
> to call dma_mmap_coherent() directly instead of nopage method.
> For the former way, take a look at sound/arm/aaci.c (and devdma.c) as
> a reference.
> 

I implemented the "former way".  However, when I put a breakpoint in
__dma_alloc_coherent it does not get called when I run speaker-test.
 It does get called during execution of "modprobe snd-ca0106".

Also, when I try to look at the memory allocated by the problematic
call to mmap in gdb, I get the following results:

Breakpoint 1, snd_pcm_mmap (pcm=0x10031880) at pcm_mmap.c:383
383                 ptr = mmap(NULL, size, PROT_READ|PROT_WRITE,
MAP_FILE|MAP_SHARED, i->u.mmap.fd, i->u.mmap.offset);
(gdb) n
384                 if (ptr == MAP_FAILED) {
(gdb) print (void *)ptr
$1 = (void *) 0x3001e000
(gdb) print ptr[0]
Cannot access memory at address 0x3001e000

So, while these changes eliminate the bugcheck, it does not appear
to be the correct solution.

-- 
Thank you,
David Cullen
Teligy
(864) 527-1263 Office
(864) 415-7063 Cell

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Call to mmap in ALSA lib 1.0.13 fails in src/pcm/pcm_mmap.c line 367

[Takashi Iwai]

At Mon, 08 Jan 2007 10:37:40 -0500,
David Cullen wrote:
> 
> Dear Mr. Iwai,
> 
> Takashi Iwai wrote:
> > The implementation depends pretty much on the architecture.
> > (Also, dma_mmap() is no global function but specific only for ARM.)
> > Since the vm_region struct is different between ppc and arm (the page
> > pointer is missing in ppc version), it cannot be copied as it is.
> > 
> > A simple (but totally untested) version would be like below:
> > 
> > int dma_mmap_coherent(struct device *dev,
> > 		struct vm_area_struct *vma, void *cpu_addr,
> > 		dma_addr_t dma_addr, size_t size)
> > {
> > 	unsigned long pfn;
> > 
> > 	pfn = page_to_pfn(virt_to_page(bus_to_virt(dma_addr)));
> > 	vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> > 	return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
> > 				vma->vm_end - vma->vm_start,
> > 				vma->vm_pgprot);
> > }
> > 
> > (This might not work for some ppc models, though...)
> > 
> > Then either add .mmap callback to each of snd_pcm_ops table in ca0106
> > that calls dma_mmap_coherent() above, or change snd_pcm_default_mmap
> > to call dma_mmap_coherent() directly instead of nopage method.
> > For the former way, take a look at sound/arm/aaci.c (and devdma.c) as
> > a reference.
> > 
> 
> I implemented the "former way".  However, when I put a breakpoint in
> __dma_alloc_coherent it does not get called when I run speaker-test.
>  It does get called during execution of "modprobe snd-ca0106".

You mean change ca0106 codes to add dma_alloc_coherent() as mmap
callback?  Then please show the patch you changed.  It's easier to
check.


Takashi

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV