whenever i am trying to receive data from serial communication continuously in uClinux, I am getting every 10th byte is overwrite by 11 byte and so on....
Iam using freescale coldfire processor. Could you any body please help me to resolve this issue. Thanks & Regards, Raj On Fri, Sep 13, 2013 at 10:16 PM, Lennart Sorensen < lsore...@csclub.uwaterloo.ca> wrote: > On Fri, Sep 13, 2013 at 11:28:52AM -0400, Bair, Richard wrote: > > I have a 4.7MB application that runs on the 2.6.26 kernel (Freescale > BSP) and am working to make it run on the 2.6.38 kernel released in the > ColdFire BSP in Feb 2012. I'm concerned about memory allocation as my > first attempt to run on the 38 kernel appears to be using 2^n memory > allocation vs. allocation that sizes just 1-page over the application. > > > > 1) Can anyone tell me the exact kernel config name that needs to be > adjusted for the 38 kernel to set the default memory allocation? > > - Older posts indicate modules like page_alloc2 or Kmalloc2 > control this so I'm going to investigate these in more detail > > - RTFMing indicate that this might be the area but I don't see it > in the 38 version (LTIB or make menucionfig): > > menuconfig -> kernel settings -> general settings, try > enabling either the "Permit large allocations" setting, or the > "non-power-of-2" > > > > 2) Historically, we use LTIB to create the kernel. Does LTIB expose > most/all settings of the 2.6.38 kernel? Can it be out of sync with the > make menuconfig uClinus kernel? > > Maybe this changed the behaviour you see: > > commit fc4d5c292b68ef02514d2072dcbf82d090c34875 > Author: David Howells <dhowe...@redhat.com> > Date: Wed May 6 16:03:05 2009 -0700 > > nommu: make the initial mmap allocation excess behaviour Kconfig > configurable > > NOMMU mmap() has an option controlled by a sysctl variable that > determines > whether the allocations made by do_mmap_private() should have the > excess > space trimmed off and returned to the allocator. Make the initial > setting > of this variable a Kconfig configuration option. > > The reason there can be excess space is that the allocator only > allocates > in power-of-2 size chunks, but mmap()'s can be made in sizes that > aren't a > power of 2. > > There are two alternatives: > > (1) Keep the excess as dead space. The dead space then remains > unused for the > lifetime of the mapping. Mappings of shared objects such as > libc, ld.so > or busybox's text segment may retain their dead space forever. > > (2) Return the excess to the allocator. This means that the dead > space is > limited to less than a page per mapping, but it means that for a > transient > process, there's more chance of fragmentation as the excess space > may be > reused fairly quickly. > > During the boot process, a lot of transient processes are created, and > this can cause a lot of fragmentation as the pagecache and various > slabs > grow greatly during this time. > > By turning off the trimming of excess space during boot and disabling > batching of frees, Coldfire can manage to boot. > > A better way of doing things might be to have /sbin/init turn this > option > off. By that point libc, ld.so and init - which are all long-duration > processes - have all been loaded and trimmed. > > Reported-by: Lanttor Guo <lanttor....@freescale.com> > Signed-off-by: David Howells <dhowe...@redhat.com> > Tested-by: Lanttor Guo <lanttor....@freescale.com> > Cc: Greg Ungerer <g...@snapgear.com> > Signed-off-by: Andrew Morton <a...@linux-foundation.org> > Signed-off-by: Linus Torvalds <torva...@linux-foundation.org> > > After all before this commit, trimming after allocating was always done. > Now it is only done if you enable this CONFIG, or set the sysctl flag > at runtime, which of course affects behaviour for all allocations after > you change the setting. > > -- > Len Sorensen > _______________________________________________ > 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 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
