[uClinux-dev] uClinux-dev Digest, Vol 21, Issue 5

DJ Regan

2013-11-10 02:32:09 UTC

Hi Michael, Question to you - would Raj's stream behave a little more
chaotic if cpu loading caused the problem?

Hi Raj, When you say every 10th character is over-written - does this
pattern hold true irrespective of the amount of data streamed? If you sent
several kilobytes of data - it is only each 10th byte that is clobbered?
...what are your frame rate and flow control settings? Here's another
thought (purely a troubleshooting measure)... what happens when you
throttle back data throughput to one character per second or less - Does
the 10th character still get blown away? I haven't looked at the driver
code - but, it made me curious to see the size of the driver's queue. Is
the queue size also coincidentally 10 +/-1 characters deep?

Just brain storming with you all. ;-)

Excited to hear what root cause is...
--DJ

Send uClinux-dev mailing list submissions to
uclinux-dev at uclinux.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
or, via email, send a message with subject or body 'help' to
uclinux-dev-request at uclinux.org
You can reach the person managing the list at
uclinux-dev-owner at uclinux.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of uClinux-dev digest..."
1. Re: 2.6.38 in Freescale Feb 2012 BSP (Michael Durrant)
----------------------------------------------------------------------
Message: 1
Date: Thu, 07 Nov 2013 11:36:58 -0500
From: Michael Durrant <mdurrant at uclinux.org>
To: uclinux-dev at uclinux.org
Subject: Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP
Message-ID: <527BC1AA.7090906 at uclinux.org>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
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
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 <

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
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

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.

lanttor.guo at freescale.com>>
dhowells at redhat.com>>
lanttor.guo at freescale.com>>
gerg at snapgear.com>>
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

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

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

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-0001.html
------------------------------
_______________________________________________
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
End of uClinux-dev Digest, Vol 21, Issue 5
******************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20131109/4506b73a/attachment.html>

Raju B

2013-11-11 04:39:30 UTC

Permalink

Hi DJ and Michale,

As per your mail, I have checked for 2 to 3 hours continuously, i have
observed 2 things here.
i). some times i have got every 10th byte is over write by
11th byte(10th Byte is not received). and
ii). Most of the cases 114 byte is over write by 115 byte(i.e
114th byte is not received)

in my code, i have taken receiver buffer size is 512 bytes and continuously
i am sending 256 bytes for 100 loops, and i have initialized input and out
put flags correctly. The baud rate is 115200bps. I am thinking to use
different available flags and queue buffer. please inform me if u have any
idea.

Thanks & Regards,
Raju

Post by DJ Regan
Hi Michael, Question to you - would Raj's stream behave a little more
chaotic if cpu loading caused the problem?
Hi Raj, When you say every 10th character is over-written - does this
pattern hold true irrespective of the amount of data streamed? If you sent
several kilobytes of data - it is only each 10th byte that is clobbered?
...what are your frame rate and flow control settings? Here's another
thought (purely a troubleshooting measure)... what happens when you
throttle back data throughput to one character per second or less - Does
the 10th character still get blown away? I haven't looked at the driver
code - but, it made me curious to see the size of the driver's queue. Is
the queue size also coincidentally 10 +/-1 characters deep?
Just brain storming with you all. ;-)
Excited to hear what root cause is...
--DJ

Send uClinux-dev mailing list submissions to
uclinux-dev at uclinux.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
or, via email, send a message with subject or body 'help' to
uclinux-dev-request at uclinux.org
You can reach the person managing the list at
uclinux-dev-owner at uclinux.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of uClinux-dev digest..."
1. Re: 2.6.38 in Freescale Feb 2012 BSP (Michael Durrant)
----------------------------------------------------------------------
Message: 1
Date: Thu, 07 Nov 2013 11:36:58 -0500
From: Michael Durrant <mdurrant at uclinux.org>
To: uclinux-dev at uclinux.org
Subject: Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP
Message-ID: <527BC1AA.7090906 at uclinux.org>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
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 DJ Regan
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....