Actually, that's intentional (not a bug). The DSPLINK_atExitHandler () is
registered with atExit so that DSPLink will cleanup in case the user has not
called all DSPLink shutdown APIs. However, when there is an abnormal
termination, we have the DSPLink signal handler calling it once more for
correct behavior in a specific condition (in our latest release, we've added
this comment here ...):
/* It is necessary to call the cleanup function
* from signal handler context to ensure that the
* cleanup is not interrupted by another signal.
* Just exit (0) is not enough as the at exit handler
* can be pre-empted by a signal.
*/
DSPLINK_atExitHandler () ;
/* Force hard stop on the process */
exit (0) ;
The actual usage is still disabling signal handling in DSPLink as I said
before. By removing the function call from the DSPLink signal handler, the
problem is simply hidden. If you had installed your application's signal
handler before calling DSPLINK PROC_setup or PROC_attach, then the DSPLink
signal handler would override your application signal handler in that thread.
In case your termination signal happened to get caught by this one thread,
your application's cleanup would never happen, since your signal handler
wouldn't execute.
Even if DSPLINK_atExitHandler gets called twice, it won't cause any issues,
because the function is written considering that this will happen (all APIs
have the required checks in place).
The signal behavior that we saw, especially in multi-threaded scenarios was
very complex, so we may have missed something in our implementation ... Please
let me know if that's the case.
Regards,
Mugdha
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, July 25, 2008 1:41 PM
To: Kamoolkar, Mugdha
Cc: [email protected]
Subject: RE: CERuntime_init/exit + threads
Thanks again!
I was looking that the sources for dsplink and noticed what think is a bug:
dsplink/gpp/src/api/Linux/drv_api.c
In DRV_installCleanupRoutines, you install atexit(&DSPLINK_atExitHandler) In
your signal handler, there's a big problem... my comments are inserted with DAK
tag
static
void
DSPLINK_sigHandler (int sigNum)
{
TRC_1ENTER ("DSPLINK_sigHandler", sigNum) ;
DSPLINK_atExitHandler () ; /* DAK - This will be called by the system when
exit(0) is called! */
/* Force hard stop on the process */
exit (0) ;
TRC_0LEAVE ("DSPLINK_sigHandler") ; /* DAK - Never gets to here because of
exit(0) */
return ;
}
When the handler executes, DSPLINK_atExitHandler() will be called twice because
exit(0) will fire off the atexit that you registered previously.
I commented out the DSPLINK_atExitHandler() from the signal handler and now my
app runs fine even with the overloaded signals.
Hope that helps anyone else out there with strange CE 2.10.01 behaviors after
program termination.
Regards,
David
DAVID A. KONDRAD
Software Design Engineer
On-Q/Legrand
www.onqlegrand.com
"Kamoolkar,
Mugdha"
<[EMAIL PROTECTED]> To
"[EMAIL PROTECTED]"
07/25/2008 04:17 <[EMAIL PROTECTED]>
PM cc
"[EMAIL PROTECTED]
vincidsp.com"
<[EMAIL PROTECTED]
vincidsp.com>
Subject
RE: CERuntime_init/exit + threads
David,
Yes, for CE, you should actually change it in file
Processor_dsplink_linkcfg_OS.c (that's the corresponding OS-specific dynamic
configuration file in Codec Engine). This configuration will override the
default DSPLink configuration in the cetools directory. I just mentioned basic
changes in DSPLink, but a CE user will need to change the Codec Engine
configuration.
The method you have mentioned, to check for an existing signal handler sounds
useful. We'll check it out.
Regards,
Mugdha
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, July 25, 2008 12:17 PM
To: Kamoolkar, Mugdha
Cc: [email protected]
Subject: RE: CERuntime_init/exit + threads
Mugdha,
Thanks for the info... do I need to edit any code in the IPC also?
I think a better policy would be to check the signalhandler_t value that is
returned from setting the handler against SIG_DFL and either emit a warning or
not install a handler at all.
DAVID A. KONDRAD
Software Design Engineer
On-Q/Legrand
Telephone (800) 321-2343 x311
www.onqlegrand.com
"Kamoolkar,
Mugdha"
<[EMAIL PROTECTED]> To
"[EMAIL PROTECTED]"
07/25/2008 03:02 <[EMAIL PROTECTED]>,
PM "[EMAIL PROTECTED]
vincidsp.com"
<[EMAIL PROTECTED]
vincidsp.com>
cc
Subject
RE: CERuntime_init/exit + threads
David,
DSPLink installs a signal handler by default to cleanup its own resources.
But you can disable it by updating in the DSPLink dynamic configuration file
CFG_Linux.c. Set HANDLESIGNALS to FALSE.
FALSE, /* HANDLESIGNALS : Should signals be
handled for cleanup */
Recommended policy is exactly what you're doing ... i.e. writing your own
signal handler for cleanup. DSPLink only installs a signal handler to enable
early development when your application is not yet fully developed and may
frequently crash/require you to Ctrl C. At that point, you definitely wouldn't
have a signal handler written in your application. Once the application
stabilizes, you can (and should) write your own signal handlers and disable the
DSPLink signal handling.
Regards,
Mugdha
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Friday, July 25, 2008 11:26 AM
To: [email protected]
Subject: CERuntime_init/exit + threads
Greetings,
We're experiencing some really weird things with CE 2.10.01 + threads...
I've checked that our threads are all opening their own CE handles and we don't
have mutual exclusion problems...
However, we can't seem to terminate the application smoothly...
I've installed a signal handler for SIGINT and we're shutting down our threads
before calling CERuntime_exit.
Questions:
1. Does CE install any signal handlers?
2. Does each thread require it's own call to CERuntime_init/exit pairs?
(Docs don't specify)
3. What is the recommended signal handling policy for CE enabled apps?
Regards,
David
DAVID A. KONDRAD
Software Design Engineer
On-Q/Legrand
www.onqlegrand.com
davinci-linux-ope
n-source-request@
linux.davincidsp. To
com [EMAIL PROTECTED]
Sent by: incidsp.com
davinci-linux-ope cc
n-source-bounces@
linux.davincidsp. Subject
com Davinci-linux-open-source Digest,
Vol 31, Issue 40
07/24/2008 01:00
PM
Please respond to
davinci-linux-ope
[EMAIL PROTECTED]
vincidsp.com
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: YAFFS2 with checkpointing on DM355 (Phil Quiney)
----------------------------------------------------------------------
Message: 1
Date: Thu, 24 Jul 2008 16:44:10 +0100
From: "Phil Quiney" <[EMAIL PROTECTED]>
Subject: RE: YAFFS2 with checkpointing on DM355
To: "Jon Povey" <[EMAIL PROTECTED]>,
<[email protected]>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="utf-8"
Hi Jon,
I discovered /proc/yaffs and that was telling me that my file system was yaffs
and not yaffs2.
It looks like YAFFS2 does not like the 16k erase block size of the MX27 NAND
FLASH module. I tried a kernel with the 'auto YAFFS switch' removed (it is
supposed to use the -t option to mount rather than 'guess' from the erase block
size) and it refused to mount as yaffs2. From what I can see
YAFFS2 needs 2k erase blocks and anything else forces YAFFS1.
So no checkpointing then ;-(
Regards
Phil Q
Phil Quiney, Senior Software Engineer
Trinity Convergence
Cambridge Business Park
Cowley Road
Cambridge CB4 0WZ, UK
T: +44(0)1223-435536
F: +44(0)1223-435560
www.trinityconvergence.com
-----Original Message-----
From:
[EMAIL PROTECTED]
davinci-linux-open-source-bounces+avincidsp.com
[mailto:[EMAIL PROTECTED]
On Behalf Of Jon Povey
Sent: 24 July 2008 15:53
To: [email protected]
Subject: RE: YAFFS2 with checkpointing on DM355
> -----Original Message-----
> From: Phil Quiney [mailto:[EMAIL PROTECTED]
> Sent: 24 July 2008 15:45
> To: Jon Povey; [email protected]
> Subject: RE: YAFFS2 with checkpointing on DM355
> I tried mounting the NAND partition with yaffs2 and it seems to take
> around 11-15 seconds to mount regardless of content.
> The MX27 core is an ARM926EJ-S running at 400MHz (199 BogoMIPS).
>
> When unmounting - it printed 'save exit: isCheckpointed 0' on the
> console - whatever that means.
Hmm, that looks like it's not creating a checkpoint, for whatever reason.
When I tried the recent YAFFS2 code it said isCheckpointed 1 on unmount (but
failed to mount again).
I have read that checkpointing can reduce several-second mount times down to
the order of a second.. When I was googling around at some point, I don't have
a source handy for that.
> Are there any YEFFS related settings you want me to change & try
> again?
The kernel config looked OK to me, I don't know enough about YAFFS2 to know why
it might not have been checkpointing properly, if that was the case.
For want of a better, and quicker, idea at the moment I am chopping down my
root fs as much as possible and will try shrinking the mtd partition too, and
see what that does for my boot times. If I can get it down to around 3s that
will be acceptable.. There are some gains to be had in optimising the startup
scripts too.
Commercial pressures are nudging me that way for an initial release:
later on I can take the time to fix YAFFS2 on DM355 and release a firmware
update.
--
Jon Povey, Design Engineer
[EMAIL PROTECTED] | +44(0)1280 825983
Racelogic is a limited company registered in England. Registered number
2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks,
MK18 1TB .
The information contained in this electronic mail transmission is intended by
Racelogic Ltd for the use of the named individual or entity to which it is
directed and may contain information that is confidential or privileged.
If you have received this electronic mail transmission in error, please delete
it from your system without copying or forwarding it, and notify the sender of
the error by reply email so that the sender's address records can be corrected.
The views expressed by the sender of this communication do not necessarily
represent those of Racelogic Ltd. Please note that Racelogic reserves the right
to monitor e-mail communications passing through its network
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
------------------------------
_______________________________________________
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 31, Issue 40
*********************************************************
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
