[Linux-Xtensa] Re: Audio Driver - applied your git patch, I'm looking into buildingyour config on an LX200...

Piet Delaney pdelaney at tensilica.com
Thu Sep 16 00:43:03 PDT 2010


benn.huang wrote:
> Hi, Piet:
> 
>    the dma_alloc_coherent function has been changed on our platform,
>    you can try the following patch to fix the memory allocation issue.
>    (just comment out the if statement of the function)

I'll pull the tree. Don't forget the stack getting whacked
with the memcpy() in SendPlayChanMail(). The size of the
memcpy() is much larger than the object on the stack your
copying to:
-------------------------------------------------------------------------
(gdb) bt
#0  bad_page_fault_bp () at arch/xtensa/mm/fault.c:228
#1  0xd0007557 in bad_page_fault (regs=0xd3a03cb0, address=8, sig=11) at arch/xtensa/mm/fault.c:248
#2  0xd0007375 in do_page_fault (regs=0xd3a03cb0) at arch/xtensa/mm/fault.c:142
#3  0xd0002575 in _kernel_exception () at arch/xtensa/kernel/entry.S:747
#4  0xd017b96e in SendPlayChanMail (chan=0x0) at drivers/media/audio/audio_dsp.c:254
#5  0xd017bc44 in audio_dsp_decode (chan_id=0, inp_stream=0xd3a30000 "ÿûÀD", inp_len=61440, outp_stream=0x0, outp_len=0xd3a03e24) at drivers/media/audio/audio_dsp.c:492
#6  0xd017ad30 in cbm60xx_dsp_write (file=0xd3a156d0, buf=0x401b90 "ÿûÀD", count=61440, ppos=0xd3a03ed0) at drivers/media/audio/cbm60xx_dsp.c:708
#7  0xd007a064 in vfs_write (file=0xd3a156d0, buf=0x401b90 "ÿûÀD", count=61440, pos=0xd3a03ed0) at fs/read_write.c:347
#8  0xd007a1e0 in sys_write (fd=4, buf=0x401b90 "ÿûÀD", count=61440) at fs/read_write.c:399
#9  0xd0002c64 in system_call () at arch/xtensa/kernel/entry.S:2103
#10 0xd00023a5 in _user_exception () at arch/xtensa/kernel/entry.S:321
#11 0xc0000001 in ?? ()
(gdb)
--------------------------------------------------------------------------

I mentioned it to Truby about an hour ago:
---------------------------------------------------------------------------
Then I hit an interesting citation where in sudio_dsp_decode() it's
using a reasonable pointer in chan (0xd389aee8) but in the function below
it, SendPlayChanMail(), the value appears to be NULL, yet it just executed
code above the preparation to call SendMail() that uses the pointer and
didn't experience an exception. The exception is caused by using an address 0x8.

My guess is that you memcpy() to the local variable 'data' on the stack was
bogus and clobbered the formal on the stack. 'data' is of type 'mailDataT'
but the memcpy is of sizeof(streamT). Looks like a bug. Your copying 16
bytes into a local variable that's only 4 bytes long. Right?

If your not using xt-gdb already I strongly encourage it. It's worth
the short term investment in time. Pays off in spades. Exchanging
information about your problems with git and xt-gdb is the ticket
to our providing low cost support and maximizing the success of your
project.

Could you update the chipbanks git repo with the bug fix and I'll
pull it and continue.

In the mean time I'll work on a DC233 V3 MMU bug fix for Christian
and making the configs for your cores for a LX200 implementation in
case I can get some help from Marc and Steve to add a little RTL
to connect the TIE queues together.
-----------------------------------------------------------------------------------

-piet

> 
> On Wed, 15 Sep 2010 20:28:09 -0700
> Piet Delaney <pdelaney at tensilica.com> wrote:
> 
>> truby.zhuang wrote:
>>> Hi,piet:
>>>  
>>> Thx for your reply.
>>>  
>>> *1. About the git*
>>>  
>>> Consider that I do not know If it is ok to push my codes to the git
>>> you give me last time,
>>> I just make a patch which include dirver code of 507T only;
>>> *I have send a tar package to Twang a long time ago*, which
>>> includes the other part of codes
>>> (dsp_code and test routine).
>> Looks like I didn't have the git repo set up quite right.
>> I made a new copy of xtensa-2.6.29-smp and seem to have
>> fixed the problem. The repo is as before owned by you
>> and Chipbanks. I pushed your patch and since have made
>> a small asm fix to allow it to work a bit on the DC233 I/O port.
>>
>> Your test program runs into a memory allocation problem when
>> I start it on the target.
>> ------------------------------
>> [root at DC_C_233L test]# ./dsp_test
>> open dsp dev
>> init oss device:3 ok
>>
>> open audio dsp dev
>> --------------------------------
>>
>> I'm Wondering if you changed how memory is allocated. Wondering if my
>> change from allocating memory to ZONE_NORMAL instead of ZONE_DMA is
>> completely correct:
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>> (gdb) up #1  0xd00498c8 in __out_of_memory (gfp_mask=209, order=0) at
>> mm/oom_kill.c:542 (gdb) bt
>> #0  oom_kill_process (p=0xd39c49a0, gfp_mask=209, order=0,
>> points=102, mem=0x0, message=0xd02279ec "Out of memory") at
>> mm/oom_kill.c:391 #1  0xd00498c8 in __out_of_memory (gfp_mask=209,
>> order=0) at mm/oom_kill.c:542 #2  0xd00499f9 in out_of_memory
>> (zonelist=0xd02b6db8, gfp_mask=209, order=0) at mm/oom_kill.c:626 #3
>> 0xd004be8e in __alloc_pages_internal (gfp_mask=209, order=0,
>> zonelist=0xd02b6db8, nodemask=0x0) at mm/page_alloc.c:1625 #4
>> 0xd004c0c8 in __alloc_pages (gfp_mask=209, order=0,
>> zonelist=0xd02b6db8) at include/linux/gfp.h:178 #5  0xd004c072 in
>> alloc_pages_node (nid=0, gfp_mask=209, order=0) at
>> include/linux/gfp.h:199 #6  0xd004c014 in __get_free_pages
>> (gfp_mask=209, order=0) at mm/page_alloc.c:1681 #7  0xd0006604 in
>> dma_alloc_coherent (dev=0x0, size=32, handle=0xd39cbc70, flag=209) at
>> arch/xtensa/kernel/pci-dma.c:44 #8  0xd017a9be in cbm60xx_dsp_open
>> (inode=0xd3454a80, file=0xd3a03200) at
>> drivers/media/audio/cbm60xx_dsp.c:368 #9  0xd007d7f8 in chrdev_open
>> (inode=0xd3454a80, filp=0xd3a03200) at fs/char_dev.c:396 #10
>> 0xd0078bc9 in __dentry_open (dentry=0xd3453c90, mnt=0xd380c388,
>> flags=2, f=0xd3a03200, open=0xd007d6d0 <chrdev_open>,
>> cred=0xd39fd2e0) at fs/open.c:839 #11 0xd0078f79 in nameidata_to_filp
>> (nd=0xd39cbde4, flags=2) at fs/open.c:942 #12 0xd0085156 in
>> do_filp_open (dfd=-100, pathname=0xd3a0b000 "/dev/adsp", open_flag=2,
>> mode=0) at fs/namei.c:1779 #13 0xd007918c in do_sys_open (dfd=-100,
>> filename=0x400a00 "/dev/adsp", flags=2, mode=0) at fs/open.c:1035 #14
>> 0xd007926c in sys_open (filename=0x400a00 "/dev/adsp", flags=2,
>> mode=0) at fs/open.c:1056 #15 0xd0002c64 in system_call () at
>> arch/xtensa/kernel/entry.S:2103 #16 0xd00023a5 in _user_exception ()
>> at arch/xtensa/kernel/entry.S:321 #17 0xc0000001 in ?? () Cannot
>> access memory at address 0xc0000001 (gdb)
>>
> 
> 
> diff --git a/arch/xtensa/kernel/pci-dma.c b/arch/xtensa/kernel/pci-dma.c
> index f615776..394d656 100644
> --- a/arch/xtensa/kernel/pci-dma.c
> +++ b/arch/xtensa/kernel/pci-dma.c
> @@ -48,9 +48,12 @@ dma_alloc_coherent(struct device *dev,size_t
> size,dma_addr_t *handle,gfp_t flag) 
>         /* We currently don't support coherent memory outside KSEG */
>  
> +       /* Commented out on chipsbank' platform */
> +#if 0
>         if (ret < XCHAL_KSEG_CACHED_VADDR
>             || ret >= XCHAL_KSEG_CACHED_VADDR + XCHAL_KSEG_SIZE)
>                 BUG();
> +#endif
>  
>  
>         if (ret != 0) {
> 
> 
> 



More information about the linux-xtensa mailing list