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 On Thu, Nov 7, 2013 at 11:00 AM, <uclinux-dev-requ...@uclinux.org> wrote: > Send uClinux-dev mailing list submissions to > uclinux-dev@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-requ...@uclinux.org > > You can reach the person managing the list at > uclinux-dev-ow...@uclinux.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of uClinux-dev digest..." > > > Today's Topics: > > 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 <mdurr...@uclinux.org> > To: uclinux-dev@uclinux.org > Subject: Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP > Message-ID: <527bc1aa.7090...@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 > > 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.org<mailto: > mdurr...@uclinux.org>> wrote: > > > > > > 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 <mailto:uClinux-dev@uclinux.org> > >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > >> This message was resent byuclinux-...@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 <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 > > 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 > > -------------- 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@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 > > End of uClinux-dev Digest, Vol 21, Issue 5 > ****************************************** >
_______________________________________________ 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
