Re: [uClinux-dev] [PATCH] add Blackfin to the README
Hi Mike, On 01/19/2010 10:12 AM, Mike Frysinger wrote: Signed-off-by: Mike Frysingervap...@gentoo.org Applied. Thanks Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close,FAX: +61 7 3891 3630 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Disk Cache overlaying Shared Memory?
After more detail examination of this problem, what I see is that the storage for the shared memory appears to be allocated via RAMFS in the pagecache in tiny-shmem.c (i.e. a non-mmu platform) and the storage is mmapped when the shmat is performed. When the pagecache hits its threshold of low RAM and starts to cleanup, the mmapped storage for the shared memory segment gets cleaned up as well old file cache entries. Eventually this storage gets re-used as pagecache and makes it appear as though the JFFS2 file system has overwritten the shared memory block when in reality the storage was freed and re-used. From looking at the code, either the page is not getting properly flagged as being mmapped on shmat or I am missing something in the pagecache cleanup code since it appears that any mmapped storage in the pagecache will always be ignored during cleanup. Any ideas? John Moore John B Moore jmo...@moreycorp.com Sent by: uclinux-dev-boun...@uclinux.org 01/20/2010 03:49 PM Please respond to uClinux development list uclinux-dev@uclinux.org To uClinux development list uclinux-dev@uclinux.org cc Subject [uClinux-dev] Disk Cache overlaying Shared Memory? I am running a 2.6.17 uClinux kernel on a Coldfire 5233 and am having an issue where it appears as though the disk cache is overlaying shared memory. In the application, I have allocated a 4K block of shared memory and am writing files to a JFFS2 file system. The Cached data size continues to grow as I continue to write files until about 1M of RAM is still available at which point the shared memory block gets overwritten with part of the data that was just written to JFFS2. This happens consistently and is easily reproducible. If I am not using shared memory but just malloc a block of storage instead, no overlay happens and the cache grows only slightly larger before it levels off as the cache cleans itself up. Any ideas why this overlay may be happening? John Moore This e-mail, including attachments, may contain information that is confidential and/or proprietary, and may only be used by the person to whom this email is addressed. If the recipient of this e-mail is not the intended recipient or an authorized agent, the reader is hereby notified that any dissemination, distribution, or copying of this e-mail is prohibited. If this e-mail has been delivered to you in error, please notify the sender by replying to this message and deleting this e-mail immediately.___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev This e-mail, including attachments, may contain information that is confidential and/or proprietary, and may only be used by the person to whom this email is addressed. If the recipient of this e-mail is not the intended recipient or an authorized agent, the reader is hereby notified that any dissemination, distribution, or copying of this e-mail is prohibited. If this e-mail has been delivered to you in error, please notify the sender by replying to this message and deleting this e-mail immediately.___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] [PATCH] debug: add a gcc-2 compat tweak
GCC-2.x has a bug with empty arg expansion in macros.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
stubs.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/stubs.h b/stubs.h
index 7e5308d..615cab5 100644
--- a/stubs.h
+++ b/stubs.h
@@ -41,7 +41,7 @@
#define _debug(lvl, fmt, args...) \
do { \
if (lvl = DEBUG) { \
- fprintf(stderr, %s:%i: fmt, __func__, __LINE__, ##
args); \
+ fprintf(stderr, %s:%i: fmt, __func__, __LINE__ , ##
args); \
fflush(stderr); \
} \
} while (0)
--
1.6.6
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH] debug: add a gcc-2 compat tweak
Mike Frysinger wrote:
GCC-2.x has a bug with empty arg expansion in macros.
if (lvl = DEBUG) { \
- fprintf(stderr, %s:%i: fmt, __func__, __LINE__, ##
args); \
+ fprintf(stderr, %s:%i: fmt, __func__, __LINE__ , ##
args); \
fflush(stderr); \
Assuming it's what it looks like, it's not a GCC-2.x bug, it's the old
GCC varargs behavior, which was documented and behaved like that since
very old versions of GCC.
You may wish to change the description if you submit it again.
If GCC 2.x support is still desired, this ought to be an easy thing to
grep for (comma followed by ##) and add to checkpatch.pl.
-- Jamie
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH] debug: add a gcc-2 compat tweak
Jivin Mike Frysinger lays it down ...
GCC-2.x has a bug with empty arg expansion in macros.
Applied with updated comment.
At first I wondered which uClinux stubs.h you were patching ;-)
Cheers,
Davidm
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
stubs.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/stubs.h b/stubs.h
index 7e5308d..615cab5 100644
--- a/stubs.h
+++ b/stubs.h
@@ -41,7 +41,7 @@
#define _debug(lvl, fmt, args...) \
do { \
if (lvl = DEBUG) { \
- fprintf(stderr, %s:%i: fmt, __func__, __LINE__, ##
args); \
+ fprintf(stderr, %s:%i: fmt, __func__, __LINE__ , ##
args); \
fflush(stderr); \
} \
} while (0)
--
1.6.6
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
--
David McCullough, david_mccullo...@securecomputing.com, Ph:+61 734352815
McAfee - SnapGear http://www.snapgear.comhttp://www.uCdot.org
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] [PATCH] debug: add a gcc-2 compat tweak
On Thursday 21 January 2010 20:21:31 Jamie Lokier wrote:
Mike Frysinger wrote:
GCC-2.x has a bug with empty arg expansion in macros.
- fprintf(stderr, %s:%i: fmt, __func__, __LINE__, ## args); \
+ fprintf(stderr, %s:%i: fmt, __func__, __LINE__ , ## args); \
Assuming it's what it looks like, it's not a GCC-2.x bug, it's the old
GCC varargs behavior, which was documented and behaved like that since
very old versions of GCC.
i'm not really familiar with gcc-2 ... i didnt get into messing with toolchain
stuff until like gcc-3.4 era. it looks like a bug to me as gcc-3+ works fine.
if you wanted to elaborate ...
this one fails:
#define debug(fmt, args...) x(fmt, moo, ## args)
main(){debug(a);}
these work:
#define debug(fmt, args...) x(fmt, moo , ## args)
main(){debug(a);}
#define debug(fmt, args...) x(fmt, ## args)
main(){debug(a);}
-mike
signature.asc
Description: This is a digitally signed message part.
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
