Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP
I think it was already suggested: you need to enable flow-control. Either hardware if you've got the pins setup right on that port or software (xon/xoff) if you don't. On Tue, Nov 12, 2013 at 4:11 AM, Raju B raju3...@gmail.com wrote: Hi Michael, I have tried with baudrate = 9600 and 19200, then it is working fine(i.e getting data, no overruns). but i want to use high speed(115200). can u please give any suggestion to over come this. Thanks r Regards, Raju On Thu, Nov 7, 2013 at 10:06 PM, Michael Durrant mdurr...@uclinux.orgwrote: Raju, I would expect data overruns causing lost characters if your CPU utilization is high and your kernel driver can't get back to servicing the UART IRQ fast enough. Your MCF523x part appears to have only a small FIFO buffer (a shift register and 3 receiver registers). So if the data rate is faster than the kernel can remove the data hardware FIFO it is likely you will miss data due to overruns. So in your case the 10th character was lost (overwritten) by the next character. Sounds like you need DMA support for the UART you are using or perhaps slow down the incoming data or perhaps turn hardware flow control on. Michael On 11/06/2013 04:40 AM, Raju B wrote: Hi Michael, The ColdFire is 523x and using UART serial interface. Thanks regards, Raju B On Tue, Nov 5, 2013 at 10:47 PM, Michael Durrant mdurr...@uclinux.orgwrote: 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 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
Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP
Hi Michael, The ColdFire is 523x and using UART serial interface. Thanks regards, Raju B On Tue, Nov 5, 2013 at 10:47 PM, Michael Durrant mdurr...@uclinux.orgwrote: 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 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 listuClinux-dev@uclinux.orghttp://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
Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP
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
Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP
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 lsore...@csclub.uwaterloo.ca mailto: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 mailto: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 mailto:lanttor@freescale.com Signed-off-by: David Howells dhowe...@redhat.com mailto:dhowe...@redhat.com Tested-by: Lanttor Guo lanttor@freescale.com mailto:lanttor@freescale.com Cc: Greg Ungerer g...@snapgear.com mailto:g...@snapgear.com Signed-off-by: Andrew Morton a...@linux-foundation.org mailto:a...@linux-foundation.org Signed-off-by: Linus Torvalds torva...@linux-foundation.org mailto: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 mailto:uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org mailto:uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev ___ uClinux-dev mailing list uClinux-dev@uclinux.org
[uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP
Still struggling with 2.6.38 kernel and memory allocation. We've been RTFMing but still aren't able to run on 2.6.38. Any insight much appreciated. BACKGROUND: === - Application is unchanged and runs on 2.6.26 and not on 2.6.38. Both versions are based on Freescale BSP releases. - Application only has 32MB of RAM total...same for both working and failing case. - Application will spawn 3x additional threads. - Application is 4.7MB application...it appears to allocate 8Mb then an additional 8MB for each thread. I believe this occurs via vfork(). THOUGHTS: = - It is my understanding that 2^n allocation has been present since 2.6 introduction so I think this is the same from version 26 to 38. Q1: Does the kernel always allocate memory via mmap()? Q2: Is mmap() used for kernel allocation and user-land allocation? Q3: Is there a good summary of exactly what transpires in terms of memory allocation as the kernel runs a user-land program? - If mmap() is the primary allocator, I think there may be a trimming capability difference from 26 to 38 based on Len Sorensen's input for memory allocations by mmap() as follows: (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. Q4: Has anyone used option 2 and if so exactly how do you set the variable and when? For the when part, do you do this post the kernel bring up? Q5: It sounds like a common method is to not trim during boot and then turn this on for large memory allocations...true? Recommended? Q6: Can anyone confirm if 26 was configured to always trim memory after allocation and 38 is not? - Tools for better memory utilization debug: Q7: What tools can we use to better understand the memory footprint of the application and threads? We're using Top but need significantly more detail. Q8: Is there a proc location that details memory allocation per program? In summary, any recommendations on how to debug memory allocation would be most helpful. At this time our Freescale support has been unhelpful in resolving this issue. Thanks! -Rich ___ 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] 2.6.38 in Freescale Feb 2012 BSP
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? Thanks! ___ 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] 2.6.38 in Freescale Feb 2012 BSP
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
