Discussion:
[uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP
Bair, Richard
2013-09-13 15:28:52 UTC
Permalink
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!
Lennart Sorensen
2013-09-13 16:46:29 UTC
Permalink
Post by Bair, Richard
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
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 <dhowells at 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.guo at freescale.com>
Signed-off-by: David Howells <dhowells at redhat.com>
Tested-by: Lanttor Guo <lanttor.guo at freescale.com>
Cc: Greg Ungerer <gerg at snapgear.com>
Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds at 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
Raju B
2013-11-05 12:40:28 UTC
Permalink
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 <
Post by Bair, Richard
Post by Bair, Richard
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.
Post by Bair, Richard
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?
Post by Bair, Richard
- Older posts indicate modules like page_alloc2 or Kmalloc2
control this so I'm going to investigate these in more detail
Post by Bair, Richard
- RTFMing indicate that this might be the area but I don't see it
menuconfig -> kernel settings -> general settings, try
enabling either the "Permit large allocations" setting, or the
"non-power-of-2"
Post by Bair, Richard
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?
commit fc4d5c292b68ef02514d2072dcbf82d090c34875
Author: David Howells <dhowells at 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.
(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.guo at freescale.com>
Signed-off-by: David Howells <dhowells at redhat.com>
Tested-by: Lanttor Guo <lanttor.guo at freescale.com>
Cc: Greg Ungerer <gerg at snapgear.com>
Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds at 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 at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20131105/369c787d/attachment.html>
Michael Durrant
2013-11-05 17:17:37 UTC
Permalink
Raj,

Which ColdFire are you using?
Which serial interface are you seeing this with (UART/SPI/I2C/..)?

Michael
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
Post by Bair, Richard
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
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?
commit fc4d5c292b68ef02514d2072dcbf82d090c34875
Author: David Howells <dhowells at redhat.com <mailto:dhowells at 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.
(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.guo at freescale.com <mailto:lanttor.guo at freescale.com>>
Signed-off-by: David Howells <dhowells at redhat.com <mailto:dhowells at redhat.com>>
Tested-by: Lanttor Guo <lanttor.guo at freescale.com <mailto:lanttor.guo at freescale.com>>
Cc: Greg Ungerer <gerg at snapgear.com <mailto:gerg at snapgear.com>>
Signed-off-by: Andrew Morton <akpm at linux-foundation.org <mailto:akpm at linux-foundation.org>>
Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org <mailto:torvalds at 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 at uclinux.org <mailto:uClinux-dev at uclinux.org>
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org <mailto:uclinux-dev at uclinux.org>
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20131105/091159b1/attachment.html>
Raju B
2013-11-06 09:40:46 UTC
Permalink
Hi Michael,

The ColdFire is 523x and using UART serial interface.

Thanks & regards,
Raju B
Post by Michael Durrant
Raj,
Which ColdFire are you using?
Which serial interface are you seeing this with (UART/SPI/I2C/..)?
Michael
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 <
Post by Bair, Richard
Post by Bair, Richard
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.
Post by Bair, Richard
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?
Post by Bair, Richard
- Older posts indicate modules like page_alloc2 or Kmalloc2
control this so I'm going to investigate these in more detail
Post by Bair, Richard
- RTFMing indicate that this might be the area but I don't see it
menuconfig -> kernel settings -> general settings, try
enabling either the "Permit large allocations" setting, or the
"non-power-of-2"
Post by Bair, Richard
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?
commit fc4d5c292b68ef02514d2072dcbf82d090c34875
Author: David Howells <dhowells at 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.
(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.guo at freescale.com>
Signed-off-by: David Howells <dhowells at redhat.com>
Tested-by: Lanttor Guo <lanttor.guo at freescale.com>
Cc: Greg Ungerer <gerg at snapgear.com>
Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds at 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 at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing listuClinux-dev at uclinux.orghttp://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
To unsubscribe see:http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20131106/c554f932/attachment.html>
Raju B
2013-11-06 09:46:28 UTC
Permalink
Hi Michael,

is there any mistakes in coldfire kernel level?. can u please
help me to overcome this issue.

Thanks & Regards,
Raju B
Post by Raju B
Hi Michael,
The ColdFire is 523x and using UART serial interface.
Thanks & regards,
Raju B
Post by Michael Durrant
Raj,
Which ColdFire are you using?
Which serial interface are you seeing this with (UART/SPI/I2C/..)?
Michael
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 <
Post by Bair, Richard
Post by Bair, Richard
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.
Post by Bair, Richard
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?
Post by Bair, Richard
- Older posts indicate modules like page_alloc2 or Kmalloc2
control this so I'm going to investigate these in more detail
Post by Bair, Richard
- RTFMing indicate that this might be the area but I don't see
menuconfig -> kernel settings -> general settings, try
enabling either the "Permit large allocations" setting, or the
"non-power-of-2"
Post by Bair, Richard
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?
commit fc4d5c292b68ef02514d2072dcbf82d090c34875
Author: David Howells <dhowells at 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.
(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.guo at freescale.com>
Signed-off-by: David Howells <dhowells at redhat.com>
Tested-by: Lanttor Guo <lanttor.guo at freescale.com>
Cc: Greg Ungerer <gerg at snapgear.com>
Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds at 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 at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing listuClinux-dev at uclinux.orghttp://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
To unsubscribe see:http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20131106/d51a5662/attachment.html>
Michael Durrant
2013-11-07 16:36:58 UTC
Permalink
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
Post by Raju B
Hi Michael,
The ColdFire is 523x and using UART serial interface.
Thanks & regards,
Raju B
Raj,
Which ColdFire are you using?
Which serial interface are you seeing this with (UART/SPI/I2C/..)?
Michael
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
Post by Bair, Richard
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
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?
commit fc4d5c292b68ef02514d2072dcbf82d090c34875
Author: David Howells <dhowells at redhat.com <mailto:dhowells at 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.
(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.guo at freescale.com <mailto:lanttor.guo at freescale.com>>
Signed-off-by: David Howells <dhowells at redhat.com <mailto:dhowells at redhat.com>>
Tested-by: Lanttor Guo <lanttor.guo at freescale.com <mailto:lanttor.guo at freescale.com>>
Cc: Greg Ungerer <gerg at snapgear.com <mailto:gerg at snapgear.com>>
Signed-off-by: Andrew Morton <akpm at linux-foundation.org <mailto:akpm at linux-foundation.org>>
Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org <mailto:torvalds at 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 at uclinux.org <mailto:uClinux-dev at uclinux.org>
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org <mailto:uclinux-dev at uclinux.org>
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org <mailto:uClinux-dev at uclinux.org>
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent byuclinux-dev at uclinux.org <mailto:uclinux-dev at uclinux.org>
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org <mailto:uClinux-dev at uclinux.org>
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org <mailto:uclinux-dev at uclinux.org>
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20131107/d649bbcb/attachment.html>
Raju B
2013-11-10 07:53:11 UTC
Permalink
Hi Michael

Thank You, I will try and get back you.

Thanks & Regards,
Raju
Post by Michael Durrant
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
Hi Michael,
The ColdFire is 523x and using UART serial interface.
Thanks & regards,
Raju B
Post by Michael Durrant
Raj,
Which ColdFire are you using?
Which serial interface are you seeing this with (UART/SPI/I2C/..)?
Michael
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 <
Post by Bair, Richard
Post by Bair, Richard
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.
Post by Bair, Richard
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?
Post by Bair, Richard
- Older posts indicate modules like page_alloc2 or Kmalloc2
control this so I'm going to investigate these in more detail
Post by Bair, Richard
- RTFMing indicate that this might be the area but I don't see
menuconfig -> kernel settings -> general settings, try
enabling either the "Permit large allocations" setting, or the
"non-power-of-2"
Post by Bair, Richard
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?
commit fc4d5c292b68ef02514d2072dcbf82d090c34875
Author: David Howells <dhowells at 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.
(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.guo at freescale.com>
Signed-off-by: David Howells <dhowells at redhat.com>
Tested-by: Lanttor Guo <lanttor.guo at freescale.com>
Cc: Greg Ungerer <gerg at snapgear.com>
Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds at 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 at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing listuClinux-dev at uclinux.orghttp://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
To unsubscribe see:http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing listuClinux-dev at uclinux.orghttp://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
To unsubscribe see:http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20131110/fde9322b/attachment.html>
Raju B
2013-11-12 12:11:32 UTC
Permalink
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
Post by Michael Durrant
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
Hi Michael,
The ColdFire is 523x and using UART serial interface.
Thanks & regards,
Raju B
Post by Michael Durrant
Raj,
Which ColdFire are you using?
Which serial interface are you seeing this with (UART/SPI/I2C/..)?
Michael
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 <
Post by Bair, Richard
Post by Bair, Richard
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.
Post by Bair, Richard
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?
Post by Bair, Richard
- Older posts indicate modules like page_alloc2 or Kmalloc2
control this so I'm going to investigate these in more detail
Post by Bair, Richard
- RTFMing indicate that this might be the area but I don't see
menuconfig -> kernel settings -> general settings, try
enabling either the "Permit large allocations" setting, or the
"non-power-of-2"
Post by Bair, Richard
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?
commit fc4d5c292b68ef02514d2072dcbf82d090c34875
Author: David Howells <dhowells at 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.
(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.guo at freescale.com>
Signed-off-by: David Howells <dhowells at redhat.com>
Tested-by: Lanttor Guo <lanttor.guo at freescale.com>
Cc: Greg Ungerer <gerg at snapgear.com>
Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds at 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 at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing listuClinux-dev at uclinux.orghttp://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
To unsubscribe see:http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing listuClinux-dev at uclinux.orghttp://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
To unsubscribe see:http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20131112/b550ef1b/attachment.html>
Steve deRosier
2013-11-12 14:11:32 UTC
Permalink
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.
Post by Raju B
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
Post by Michael Durrant
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
Hi Michael,
The ColdFire is 523x and using UART serial interface.
Thanks & regards,
Raju B
Post by Michael Durrant
Raj,
Which ColdFire are you using?
Which serial interface are you seeing this with (UART/SPI/I2C/..)?
Michael
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 <
Post by Bair, Richard
Post by Bair, Richard
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.
Post by Bair, Richard
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?
Post by Bair, Richard
- Older posts indicate modules like page_alloc2 or Kmalloc2
control this so I'm going to investigate these in more detail
Post by Bair, Richard
- RTFMing indicate that this might be the area but I don't see
menuconfig -> kernel settings -> general settings, try
enabling either the "Permit large allocations" setting, or the
"non-power-of-2"
Post by Bair, Richard
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?
commit fc4d5c292b68ef02514d2072dcbf82d090c34875
Author: David Howells <dhowells at 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.
(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.guo at freescale.com>
Signed-off-by: David Howells <dhowells at redhat.com>
Tested-by: Lanttor Guo <lanttor.guo at freescale.com>
Cc: Greg Ungerer <gerg at snapgear.com>
Signed-off-by: Andrew Morton <akpm at linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds at 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 at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing listuClinux-dev at uclinux.orghttp://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
To unsubscribe see:http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing listuClinux-dev at uclinux.orghttp://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
To unsubscribe see:http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20131112/d6f856d4/attachment.html>
Loading...