--- Begin Message ---
Send Davinci-linux-open-source mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Davinci-linux-open-source digest..."
Today's Topics:
1. Re: kernel crash while running h264 codec on DM6446 based
board (?a?lar AKY?Z)
2. Re: [Resubmit: PATCH-V2] Introducing ti-media directory
(Laurent Pinchart)
3. flashing u-boot whit ? (Murat Karadeniz)
4. Can dm644x support usb remote sleep and wakeup? (huangsw)
5. RE: kernel crash while running h264 codec on DM6446 based
board (Kamoolkar, Mugdha)
----------------------------------------------------------------------
Message: 1
Date: Wed, 24 Mar 2010 09:22:29 +0200
From: ?a?lar AKY?Z <[email protected]>
To: [email protected]
Subject: Re: kernel crash while running h264 codec on DM6446 based
board
Message-ID: <[email protected]>
Content-Type: Text/Plain; charset="iso-8859-15"
On Wednesday 24 March 2010 06:36:58 am Yuvraj Pasi wrote:
> Hi,
Hi,
> Thanks for the reply. No I'm not calling kill inside the application & the
> kernel does not hang after the crash. I'm able to restart
> the application again after the crash. & every time it runs smoothly for
> some period before it crashes.
>
> thanks & regards
> yuvraj pasi
>
[...]
> > [<bf00d4b0>] (SYNC_WaitSEM+0x0/0x260 [dsplinkk]) from [<bf00c4d4>]
By looking at oops dump I remembered a smilar problem related to sync in
Dsplink. I don't remember my exact oops dump but maybe your problem is
somehow related to it. Have you checked the thread at [1] ?
Secondly, this maybe a memory leak issue. Have you checked your free memory
before and after running your application?
Regards,
Caglar
[1]
http://www.mail-archive.com/[email protected]/msg11540.html
> > (UEVENT_AddBufByPid+0x150/0x17c [dsplinkk])
> > [<bf00c384>] (UEVENT_AddBufByPid+0x0/0x17c [dsplinkk]) from [<bf00c714>]
> > (NOTIFY_KnlFinalize+0x14c/0x16c [dsplinkk])
> > [<bf00c5c8>] (NOTIFY_KnlFinalize+0x0/0x16c [dsplinkk]) from [<bf008930>]
> > (DRV_CallAPI+0x778/0x8f0 [dsplinkk])
> > r6:00008000 r5:00008000 r4:c14edf00
> > [<bf0081b8>] (DRV_CallAPI+0x0/0x8f0 [dsplinkk]) from [<bf008138>]
> > (DRV_Ioctl+0x90/0x110 [dsplinkk])
> > r7:00007302 r6:00000000 r5:4391c0b0 r4:00000000
> > [<bf0080a8>] (DRV_Ioctl+0x0/0x110 [dsplinkk]) from [<c0088f10>]
> > (do_ioctl+0x74/0x84)
> > r7:0000000b r6:4391c0b0 r5:ffffffe7 r4:c6fed160
> > [<c0088e9c>] (do_ioctl+0x0/0x84) from [<c00891ac>]
> > (vfs_ioctl+0x28c/0x2ac) r6:00000000 r5:4391c0b0 r4:c6fed160
> > [<c0088f20>] (vfs_ioctl+0x0/0x2ac) from [<c0089210>]
> > (sys_ioctl+0x44/0x68) r7:c6fed160 r6:00007302 r5:4391c0b0 r4:fffffff7
> > [<c00891cc>] (sys_ioctl+0x0/0x68) from [<c0027e20>]
> > (ret_fast_syscall+0x0/0x2c)
> >
> > According to the FAQ it is a problem with syncronisation between threads.
> > How can I find out which thread calls are causing this problem because my
> > application uses different threads
> > for video encode & decoding , audio encoding & decoding.
> > The backtrace given above is of no help!!!
> >
> >
> > On Mon, Mar 22, 2010 at 11:25 PM, Uppal, Deepali <[email protected]> wrote:
> >
> > Hello,
> >
> >
> >
> > Please check here:
> >
> >
> >
> >
> > http://wiki.davincidsp.com/index.php/DSPLink_FAQs#Why_does_the_MSGQ_get_A
> >PI_call_in_my_application_crash.3F
> >
> >
> >
> > Does this FAQ apply to your scenario?
> >
> >
> >
> > Thanks and Regards,
> > Deepali Uppal
> > DSP/BIOS Link
> > ------------------------------
> >
> > *From:* davinci-linux-open-source-bounces+deepali=ti.com@
> > linux.davincidsp.com
> > [mailto:davinci-linux-open-source-bounces+deepali<davinci-linux-open-sour
> >ce-bounces%2Bdeepali> [email protected]] *On Behalf Of *Yuvraj
> > Pasi
> > *Sent:* Friday, March 19, 2010 2:35 PM
> > *To:* [email protected]
> > *Subject:* kernel crash while running h264 codec on DM6446 based board
> >
> >
> >
> > Hi all,
> > we are using our own custom made board with DM6446. I have written a
> > camera capture application which
> > captures images encodes it in H264, decodes it & then display it on fb.
> > It runs smoothly for some time & then crashes .
> >
> > How do I debug this crash dump so that i can find the source of the
> > problem.
> >
> > ortp-m, *pte=00000000essage-get_pictu, *ppte=00000000re_buffer_size 1
> > 07
> > ortp-messageInternal error: Oops: 7 [#1]
> > Modules linked in: dsplinkk cmemk
> > CPU: 0 Not tainted (2.6.23-davinci1 #219)
> > PC is at SYNC_WaitSEM+0x1d0/0x260 [dsplinkk]
> > LR is at __atomic_notifier_call_chain+0x1c/0x24
> > pc : [<bf00d680>] lr : [<c004959c>] psr: 50000013
> > sp : c1975dd0 ip : 00000000 fp : c1975e44
> > r10: c0038e14 r9 : 00008000 r8 : c7930008
> > r7 : c1974000 r6 : c1975de8 r5 : c7930000 r4 : c1975de0
> > r3 : 00000001 r2 : c04bb900 r1 : 00000002 r0 : c04bb900
> > Flags: nZcV IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> > Control: 0005317f Table: 81794000 DAC: 00000015
> > Process linphonec (pid: 1118, stack limit = 0xc1974260)
> > Stack: (0xc1975dd0 to 0xc1976000)
> > 5dc0: 00000000 c04bb900 c0038e14
> > 00000000
> > 5de0: 00000000 00000000 00000001 c04bb900 c0038e14 c7930008 c7930008
> > c0038edc
> > 5e00: 60000013 ffffffff 00000000 bf02211c 00000000 c7932008 c1975e44
> > 00008000
> > 5e20: c15174c0 bf02211c c67526e0 bf02210c 00000000 00000000 c1975e7c
> > c1975e48
> > 5e40: bf00c4d4 bf00d4c0 bf00b8d8 ffffffff c1975e8c c1975e8c 00000000
> > 00008000
> > 5e60: 00007302 c002861c c1974000 00900036 c1975eac c1975e80 bf00c714
> > bf00c394
> > 5e80: 00000000 00000000 c1975f0c 00000000 c0027ab4 c1975f00 00008000
> > 00008000
> > 5ea0: c1975efc c1975eb0 bf008930 bf00c5d8 40020000 c6687288 00000000
> > 40020000
> > 5ec0: 4002b000 40020000 c748d23c c1975f1c c1975f0c c1975ee0 c006e18c
> > 43f60170
> > 5ee0: 00000000 43f60170 00000000 00007302 c1975f34 c1975f00 bf008138
> > bf0081c8
> > 5f00: 00008000 00000000 40020480 00008200 001eff10 00008000 c75758a0
> > ffffffe7
> > 5f20: 43f60170 00000011 c1975f54 c1975f38 c008b490 bf0080b8 c1975f84
> > c75758a0
> > 5f40: 43f60170 00000000 c1975f7c c1975f58 c008b72c c008b42c 00008680
> > c6752714
> > 5f60: fffffff7 43f60170 00007302 c75758a0 c1975fa4 c1975f80 c008b790
> > c008b4b0
> > 5f80: c0073d9c 00000001 001f02b0 43f61000 00215d70 00000036 00000000
> > c1975fa8
> > 5fa0: c0027e20 c008b75c 001f02b0 43f61000 00000011 00007302 43f60170
> > 00213e60
> > 5fc0: 001f02b0 43f61000 00215d70 00000108 00215d34 000005a0 00000000
> > 43f6016c
> > 5fe0: 001d6024 43f60110 000221e4 401d2294 80000010 00000011 020030fe
> > e2200000
> > Backtrace:
> > [<bf00d4b0>] (SYNC_WaitSEM+0x0/0x260 [dsplinkk]) from [<bf00c4d4>]
> > (UEVENT_AddBufByPid+0x150/0x17c [dsplinkk])
> > [<bf00c384>] (UEVENT_AddBufByPid+0x0/0x17c [dsplinkk]) from [<bf00c714>]
> > (NOTIFY_KnlFinalize+0x14c/0x16c [dsplinkk])
> > [<bf00c5c8>] (NOTIFY_KnlFinalize+0x0/0x16c [dsplinkk]) from [<bf008930>]
> > (DRV_CallAPI+0x778/0x8f0 [dsplinkk])
> > r6:00008000 r5:00008000 r4:c1975f00
> > [<bf0081b8>] (DRV_CallAPI+0x0/0x8f0 [dsplinkk]) from [<bf008138>]
> > (DRV_Ioctl+0x90/0x110 [dsplinkk])
> > r7:00007302 r6:00000000 r5:43f60170 r4:00000000
> > [<bf0080a8>] (DRV_Ioctl+0x0/0x110 [dsplinkk]) from [<c008b490>]
> > (do_ioctl+0x74/0x84)
> > r7:00000011 r6:43f60170 r5:ffffffe7 r4:c75758a0
> > [<c008b41c>] (do_ioctl+0x0/0x84) from [<c008b72c>]
> > (vfs_ioctl+0x28c/0x2ac) r6:00000000 r5:43f60170 r4:c75758a0
> > [<c008b4a0>] (vfs_ioctl+0x0/0x2ac) from [<c008b790>]
> > (sys_ioctl+0x44/0x68) r7:c75758a0 r6:00007302 r5:43f60170 r4:fffffff7
> > [<c008b74c>] (sys_ioctl+0x0/0x68) from [<c0027e20>]
> > (ret_fast_syscall+0x0/0x2c)
> > r7:00000036 r6:00215d70 r5:43f61000 r4:001f02b0
> > Code: eb410c34 e597200c e3a03001 e5823000 (e5953010)
> >
> >
> > --
> > Thanks & regards
> > yuvraj pasi
> >
> >
> >
> >
> > --
> > Thanks & regards
> > yuvraj pasi
>
------------------------------
Message: 2
Date: Wed, 24 Mar 2010 10:05:50 +0100
From: Laurent Pinchart <[email protected]>
To: "Karicheri, Muralidharan" <[email protected]>
Cc: "[email protected]"
<[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [Resubmit: PATCH-V2] Introducing ti-media directory
Message-ID: <[email protected]>
Content-Type: Text/Plain; charset="iso-8859-1"
Hi Murali,
On Tuesday 23 March 2010 18:52:44 Karicheri, Muralidharan wrote:
> Laurent,
>
> > > I'm not too sure to like the ti-media name. It will soon get quite
> > > crowded, and name collisions might occur (look at the linux-omap-camera
> > > tree and the ISP driver in there for instance). Isn't there an internal
> > > name to refer to both the DM6446 and AM3517 that could be used ?
> >
> > [Hiremath, Vaibhav] Laurent,
> >
> > ti-media directory is top level directory where we are putting all TI
> > devices drivers. So having said that, we should worrying about what goes
> > inside this directory.
> > For me ISP is more generic, if you compare davinci and OMAP.
> >
> > Frankly, there are various naming convention we do have from device to
> > device, even if the IP's are being reused. For example, the internal name
> > for OMAP is ISP but Davinci refers it as a VPSS.
>
> Could you explain what name space issue you are referring to in
> linux-omap-camera since I am not quite familiar with that tree?
The linux-omap-camera tree contains a driver for the OMAP3 ISP. Basically,
most source files start with the "isp" prefix and are stored in
drivers/media/video/isp/.
ISP is quite a generic name, and other vendors will probably develop an ISP at
some point (if not already done), so there's already a potential name conflict
today.
Using a dedicated directory in drivers/media/video for TI-specific cores is
definitely a good idea (assuming the same IP cores won't be used by other
vendors in the future).
My concern is that, if we move the ISP driver in drivers/media/video/ti-media,
the directory will soon get quite crowded. If a new TI processor comes up with
a totally incompatible ISP, we will get a name conflict in
drivers/media/video/ti-media. I was thinking about either replacing the "isp"
prefix with "omap3isp" (or similar), or moving the driver to
drivers/media/video/ti-media/omap3isp, but that will impede code sharing code
between the Davinci and OMAP processor families. That's where my uncertainty
comes from.
> Myself and Vaibhav had discussed this in the past and ti-media is the
> generic name that we could agree on. On DM SoCs (DM6446, DM355, DM365) I
> expect ti-media to be the home for all vpfe and vpbe driver files. Since
> we had a case of common IP across OMAP and DMxxx SoCs, we want to place
> all OMAP and DMxxx video driver files in a common directory so that
> sharing the drivers across the SoCs will be easy. We could discuss and
> agree on another name if need be. Any suggestions?
It's not the name ti-media that I don't agree on, it's just that this will
move the problem one step further in the directory hierarchy without actually
solving it :-)
Is it guaranteed today that no TI processors with new generation video blocks
will reuse the names ISP, VPFE and VPBE ? The OMAP3 datasheet refers to VPFE
and VPBE, but luckily those blocks are further divided into subblocks, and the
driver doesn't refer to the VPFE and VPBE directly.
--
Regards,
Laurent Pinchart
------------------------------
Message: 3
Date: Wed, 24 Mar 2010 11:06:50 +0200
From: Murat Karadeniz <[email protected]>
To: [email protected]
Subject: flashing u-boot whit ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
I'm sorry. It might be asked before but i want to ask again for not being in
case of reinvent the wheel.
1- In the Ti 's official web it is said that "Serial Boot and Flash
Loading
Utility" is not supported. Is there any way doing that with new up to date
tool or anything on linux.
2- And i downloaded it but couldn't make it on linux. There were lots of
warning and errors. In the manifest file and on the tar package version is
2.00. any new version of it ?
Thanks for the time and consideration
Best Regards,
Murat Karadeniz
------------------------------
Message: 4
Date: Wed, 24 Mar 2010 17:22:01 +0800
From: "huangsw" <[email protected]>
To: "davinci-linux-open-source"
<[email protected]>
Subject: Can dm644x support usb remote sleep and wakeup?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello everybody, one 3G modem was connected on my DM6446's usb port, i want to
consume less power when there are no datas to transfer through usb port.
I have two questions to ask below:
(1)how to close usb host to power down mode?
(2) If i put the usb host to power down mode,how the usb to be wakeup by the
usb device such as 3G modem?
thanks for any advices.
2010-03-24
huangsw
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://linux.davincidsp.com/pipermail/davinci-linux-open-source/attachments/20100324/aec3d558/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 24 Mar 2010 15:04:11 +0530
From: "Kamoolkar, Mugdha" <[email protected]>
To: ?a?lar AKY?Z <[email protected]>,
"[email protected]"
<[email protected]>
Subject: RE: kernel crash while running h264 codec on DM6446 based
board
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-9"
The dump does indicate that the thread is dying (hence the call to
NOTIFY_KnlFinalize). I suspect that this is happening because your application
is somehow generating a seg fault or something that's getting caught by the
DSPLink default signal handler, then resulting in calling the function that
does the cleanup. When cleanup happens, this crash dump is expected, and you'll
see that you can continue and restart your application.
Can you put prints inside DSPLINK_atExitHandler and DSPLINK_sigHandler
functions (dsplink/gpp/src/api/Linux/drv_api.c), rebuild DSPLink user-side and
see if this print comes up? If yes, then this is probably what's happening, and
you need to find out which signal is getting caught, and what's the cause of
that signal (may be completely DSPLink-unrelated, since we have stress tests
that run for several hours and we have never seen this issue in a normal run).
Regards,
Mugdha
-----Original Message-----
From: ?a?lar AKY?Z [mailto:[email protected]]
Sent: Wednesday, March 24, 2010 12:52 PM
To: [email protected]
Cc: Yuvraj Pasi; Kamoolkar, Mugdha
Subject: Re: kernel crash while running h264 codec on DM6446 based board
On Wednesday 24 March 2010 06:36:58 am Yuvraj Pasi wrote:
> Hi,
Hi,
> Thanks for the reply. No I'm not calling kill inside the application & the
> kernel does not hang after the crash. I'm able to restart
> the application again after the crash. & every time it runs smoothly for
> some period before it crashes.
>
> thanks & regards
> yuvraj pasi
>
[...]
> > [<bf00d4b0>] (SYNC_WaitSEM+0x0/0x260 [dsplinkk]) from [<bf00c4d4>]
By looking at oops dump I remembered a smilar problem related to sync in
Dsplink. I don't remember my exact oops dump but maybe your problem is
somehow related to it. Have you checked the thread at [1] ?
Secondly, this maybe a memory leak issue. Have you checked your free memory
before and after running your application?
Regards,
Caglar
[1]
http://www.mail-archive.com/[email protected]/msg11540.html
> > (UEVENT_AddBufByPid+0x150/0x17c [dsplinkk])
> > [<bf00c384>] (UEVENT_AddBufByPid+0x0/0x17c [dsplinkk]) from [<bf00c714>]
> > (NOTIFY_KnlFinalize+0x14c/0x16c [dsplinkk])
> > [<bf00c5c8>] (NOTIFY_KnlFinalize+0x0/0x16c [dsplinkk]) from [<bf008930>]
> > (DRV_CallAPI+0x778/0x8f0 [dsplinkk])
> > r6:00008000 r5:00008000 r4:c14edf00
> > [<bf0081b8>] (DRV_CallAPI+0x0/0x8f0 [dsplinkk]) from [<bf008138>]
> > (DRV_Ioctl+0x90/0x110 [dsplinkk])
> > r7:00007302 r6:00000000 r5:4391c0b0 r4:00000000
> > [<bf0080a8>] (DRV_Ioctl+0x0/0x110 [dsplinkk]) from [<c0088f10>]
> > (do_ioctl+0x74/0x84)
> > r7:0000000b r6:4391c0b0 r5:ffffffe7 r4:c6fed160
> > [<c0088e9c>] (do_ioctl+0x0/0x84) from [<c00891ac>]
> > (vfs_ioctl+0x28c/0x2ac) r6:00000000 r5:4391c0b0 r4:c6fed160
> > [<c0088f20>] (vfs_ioctl+0x0/0x2ac) from [<c0089210>]
> > (sys_ioctl+0x44/0x68) r7:c6fed160 r6:00007302 r5:4391c0b0 r4:fffffff7
> > [<c00891cc>] (sys_ioctl+0x0/0x68) from [<c0027e20>]
> > (ret_fast_syscall+0x0/0x2c)
> >
> > According to the FAQ it is a problem with syncronisation between threads.
> > How can I find out which thread calls are causing this problem because my
> > application uses different threads
> > for video encode & decoding , audio encoding & decoding.
> > The backtrace given above is of no help!!!
> >
> >
> > On Mon, Mar 22, 2010 at 11:25 PM, Uppal, Deepali <[email protected]> wrote:
> >
> > Hello,
> >
> >
> >
> > Please check here:
> >
> >
> >
> >
> > http://wiki.davincidsp.com/index.php/DSPLink_FAQs#Why_does_the_MSGQ_get_A
> >PI_call_in_my_application_crash.3F
> >
> >
> >
> > Does this FAQ apply to your scenario?
> >
> >
> >
> > Thanks and Regards,
> > Deepali Uppal
> > DSP/BIOS Link
> > ------------------------------
> >
> > *From:* davinci-linux-open-source-bounces+deepali=ti.com@
> > linux.davincidsp.com
> > [mailto:davinci-linux-open-source-bounces+deepali<davinci-linux-open-sour
> >ce-bounces%2Bdeepali> [email protected]] *On Behalf Of *Yuvraj
> > Pasi
> > *Sent:* Friday, March 19, 2010 2:35 PM
> > *To:* [email protected]
> > *Subject:* kernel crash while running h264 codec on DM6446 based board
> >
> >
> >
> > Hi all,
> > we are using our own custom made board with DM6446. I have written a
> > camera capture application which
> > captures images encodes it in H264, decodes it & then display it on fb.
> > It runs smoothly for some time & then crashes .
> >
> > How do I debug this crash dump so that i can find the source of the
> > problem.
> >
> > ortp-m, *pte=00000000essage-get_pictu, *ppte=00000000re_buffer_size 1
> > 07
> > ortp-messageInternal error: Oops: 7 [#1]
> > Modules linked in: dsplinkk cmemk
> > CPU: 0 Not tainted (2.6.23-davinci1 #219)
> > PC is at SYNC_WaitSEM+0x1d0/0x260 [dsplinkk]
> > LR is at __atomic_notifier_call_chain+0x1c/0x24
> > pc : [<bf00d680>] lr : [<c004959c>] psr: 50000013
> > sp : c1975dd0 ip : 00000000 fp : c1975e44
> > r10: c0038e14 r9 : 00008000 r8 : c7930008
> > r7 : c1974000 r6 : c1975de8 r5 : c7930000 r4 : c1975de0
> > r3 : 00000001 r2 : c04bb900 r1 : 00000002 r0 : c04bb900
> > Flags: nZcV IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> > Control: 0005317f Table: 81794000 DAC: 00000015
> > Process linphonec (pid: 1118, stack limit = 0xc1974260)
> > Stack: (0xc1975dd0 to 0xc1976000)
> > 5dc0: 00000000 c04bb900 c0038e14
> > 00000000
> > 5de0: 00000000 00000000 00000001 c04bb900 c0038e14 c7930008 c7930008
> > c0038edc
> > 5e00: 60000013 ffffffff 00000000 bf02211c 00000000 c7932008 c1975e44
> > 00008000
> > 5e20: c15174c0 bf02211c c67526e0 bf02210c 00000000 00000000 c1975e7c
> > c1975e48
> > 5e40: bf00c4d4 bf00d4c0 bf00b8d8 ffffffff c1975e8c c1975e8c 00000000
> > 00008000
> > 5e60: 00007302 c002861c c1974000 00900036 c1975eac c1975e80 bf00c714
> > bf00c394
> > 5e80: 00000000 00000000 c1975f0c 00000000 c0027ab4 c1975f00 00008000
> > 00008000
> > 5ea0: c1975efc c1975eb0 bf008930 bf00c5d8 40020000 c6687288 00000000
> > 40020000
> > 5ec0: 4002b000 40020000 c748d23c c1975f1c c1975f0c c1975ee0 c006e18c
> > 43f60170
> > 5ee0: 00000000 43f60170 00000000 00007302 c1975f34 c1975f00 bf008138
> > bf0081c8
> > 5f00: 00008000 00000000 40020480 00008200 001eff10 00008000 c75758a0
> > ffffffe7
> > 5f20: 43f60170 00000011 c1975f54 c1975f38 c008b490 bf0080b8 c1975f84
> > c75758a0
> > 5f40: 43f60170 00000000 c1975f7c c1975f58 c008b72c c008b42c 00008680
> > c6752714
> > 5f60: fffffff7 43f60170 00007302 c75758a0 c1975fa4 c1975f80 c008b790
> > c008b4b0
> > 5f80: c0073d9c 00000001 001f02b0 43f61000 00215d70 00000036 00000000
> > c1975fa8
> > 5fa0: c0027e20 c008b75c 001f02b0 43f61000 00000011 00007302 43f60170
> > 00213e60
> > 5fc0: 001f02b0 43f61000 00215d70 00000108 00215d34 000005a0 00000000
> > 43f6016c
> > 5fe0: 001d6024 43f60110 000221e4 401d2294 80000010 00000011 020030fe
> > e2200000
> > Backtrace:
> > [<bf00d4b0>] (SYNC_WaitSEM+0x0/0x260 [dsplinkk]) from [<bf00c4d4>]
> > (UEVENT_AddBufByPid+0x150/0x17c [dsplinkk])
> > [<bf00c384>] (UEVENT_AddBufByPid+0x0/0x17c [dsplinkk]) from [<bf00c714>]
> > (NOTIFY_KnlFinalize+0x14c/0x16c [dsplinkk])
> > [<bf00c5c8>] (NOTIFY_KnlFinalize+0x0/0x16c [dsplinkk]) from [<bf008930>]
> > (DRV_CallAPI+0x778/0x8f0 [dsplinkk])
> > r6:00008000 r5:00008000 r4:c1975f00
> > [<bf0081b8>] (DRV_CallAPI+0x0/0x8f0 [dsplinkk]) from [<bf008138>]
> > (DRV_Ioctl+0x90/0x110 [dsplinkk])
> > r7:00007302 r6:00000000 r5:43f60170 r4:00000000
> > [<bf0080a8>] (DRV_Ioctl+0x0/0x110 [dsplinkk]) from [<c008b490>]
> > (do_ioctl+0x74/0x84)
> > r7:00000011 r6:43f60170 r5:ffffffe7 r4:c75758a0
> > [<c008b41c>] (do_ioctl+0x0/0x84) from [<c008b72c>]
> > (vfs_ioctl+0x28c/0x2ac) r6:00000000 r5:43f60170 r4:c75758a0
> > [<c008b4a0>] (vfs_ioctl+0x0/0x2ac) from [<c008b790>]
> > (sys_ioctl+0x44/0x68) r7:c75758a0 r6:00007302 r5:43f60170 r4:fffffff7
> > [<c008b74c>] (sys_ioctl+0x0/0x68) from [<c0027e20>]
> > (ret_fast_syscall+0x0/0x2c)
> > r7:00000036 r6:00215d70 r5:43f61000 r4:001f02b0
> > Code: eb410c34 e597200c e3a03001 e5823000 (e5953010)
> >
> >
> > --
> > Thanks & regards
> > yuvraj pasi
> >
> >
> >
> >
> > --
> > Thanks & regards
> > yuvraj pasi
>
------------------------------
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
End of Davinci-linux-open-source Digest, Vol 51, Issue 68
*********************************************************
--- End Message ---
