[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:59:53 PDT 2010


Piet Delaney wrote:
> 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.

I just verified the the two other bugs I mentioned still need to be fixed:

Breakpoint 20, bad_page_fault_bp () at arch/xtensa/mm/fault.c:228
1: x/i $pc
0xd00074cb <bad_page_fault_bp+3>:	retw.n
(gdb) bt
#0  bad_page_fault_bp () at arch/xtensa/mm/fault.c:228
#1  0xd0007517 in bad_page_fault (regs=0xd39dbcb0, address=8, sig=11) at arch/xtensa/mm/fault.c:248
#2  0xd0007335 in do_page_fault (regs=0xd39dbcb0) at arch/xtensa/mm/fault.c:142
#3  0xd0002565 in _kernel_exception () at arch/xtensa/kernel/entry.S:747
#4  0xd017b92e in SendPlayChanMail (chan=0x0) at drivers/media/audio/audio_dsp.c:254
#5  0xd017bc04 in audio_dsp_decode (chan_id=0, inp_stream=0xd3a30000 "ÿûÀD", inp_len=61440, outp_stream=0x0, outp_len=0xd39dbe24) at drivers/media/audio/audio_dsp.c:492
#6  0xd017acf0 in cbm60xx_dsp_write (file=0xd387bb80, buf=0x401b90 "ÿûÀD", count=61440, ppos=0xd39dbed0) at drivers/media/audio/cbm60xx_dsp.c:708
#7  0xd007a024 in vfs_write (file=0xd387bb80, buf=0x401b90 "ÿûÀD", count=61440, pos=0xd39dbed0) at fs/read_write.c:347
#8  0xd007a1a0 in sys_write (fd=4, buf=0x401b90 "ÿûÀD", count=61440) at fs/read_write.c:399
#9  0xd0002c54 in system_call () at arch/xtensa/kernel/entry.S:2103
#10 0xd0002395 in _user_exception () at arch/xtensa/kernel/entry.S:321
#11 0xc0000001 in ?? ()
Cannot access memory at address 0xc0000001
(gdb)

and

Init chan
BUG: sleeping function called from invalid context at kernel/rwsem.c:21
in_atomic(): 0, irqs_disabled(): 3, pid: 80, name: dsp_test

Stack: 00000018 b7156bbc 0000000f ffffffff 00000001 00000014 66666666 00003636
        d39d8000 00000001 00000050 00000000 b7119387 d39db810 d39ab680 d3814390
        d39ab680 00000000 000026b8 00000020 b73d47e9 00000000 00000020 d39db7e0
Call Trace:

-piet



  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