Re: 2.6.38 in Freescale Feb 2012 BSP
Michael Durrant <[email protected]>
| Newsgroups | gmane.linux.uclinux.devel |
|---|---|
| Message-ID | <[email protected]> |
Raj, Which ColdFire are you using? Which serial interface are you seeing this with (UART/SPI/I2C/..)? Michael On 11/05/2013 07:40 AM, Raju B wrote: > 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 <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> > 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 <[email protected] <mailto:[email protected]>> > Signed-off-by: David Howells <[email protected] <mailto:[email protected]>> > Tested-by: Lanttor Guo <[email protected] <mailto:[email protected]>> > Cc: Greg Ungerer <[email protected] <mailto:[email protected]>> > Signed-off-by: Andrew Morton <[email protected] <mailto:[email protected]>> > Signed-off-by: Linus Torvalds <[email protected] <mailto:[email protected]>> > > 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 > [email protected] <mailto:[email protected]> > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by [email protected] <mailto:[email protected]> > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > > > > > _______________________________________________ > uClinux-dev mailing list > [email protected] > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by [email protected] > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev