Re: [microblaze-uclinux] Patch for stability under heavy IRQ load

[Alejandro Lucero <alucero@xxxxxxxxx>]

On Wednesday 06 September 2006 12:29, Brettschneider Falk wrote:
> Hi,
>
> Alejandro Lucero wrote:
> > I did the RTLinux port to microblaze/uClinux. It works but
> > under some heavy
> > tests system crashes. The testbench is:
> >
> > 	- 500us periodic RT task
> > 	- ping flood from another machine
> > 	- endless shell script doing some 'ls -l' commands on a
> > NFS mounted directory
> >
> > I'm using the addresses 0x1000 to 0x4000 (related with LMB
> > and not used by
> > uClinux) to log system calls entries, system calls exits and context
> > switches. The entry.S file has been modified to do it and to
> > check some
> > erroneous values as a system call number greater then 250
> > which will stop the
> > machine. A counter tells me where was the address of the last
> > entry and then
> > I can know what was the last thing done by the OS. After a
> > lot of tests I
> > know this is always after a sys_execve and it shows the
> > system call returns
> > to the address of the brki instruction of previous process
> > frame (destroyed
> > during the normal execve work). The problem is I don't know
> > if this is the
> > point (I have re-read carefully the code and I cant see any
> > track) or this
> > situation is created from a previous error on vfork.
> >
> > I have not a lot of time to work on this, so I use some time
> > during the nights
> > but it is not enough until now.
> >
> > I think at this point this could be more a problem of the
> > RTLinux port instead
> > of a uClinux one, but if there's someone with the same
> > problems and without
> > RTlinux working, then things change.
> >
> > Is it the case for you?
>
> Unfortunately, I don't have TCP. So I'm not able to try to reproduce your
> special scenario.
> Concerning your RTLinux patch: This sounds very interesting. Is it public
> somehow? Do you have a faster OS response with it now? Here, the time from
> IRQ to user app reaction is about 600µs which is quite slow, and I'm very
> interested in improving it.

So I guess you don't have the same problem, then I will focus in the RTLinux 
part.

My idea is to release the RTLinux work soon with a free version (I have an 
agreement to do that with FSMLabs, RTLinux patent owner), but I'd like to do 
the release with a stable version. By now, I can run a RT task during long 
periods without problems, but when I do the same with the ping flood and the 
endless shell script the system crashes after some time.

About the latencies, I have some numbers:

A 500us periodic RT task, with a stressed uCLinux system, has a jitter of 
124us and a worst case irq timer of 62us. The best times are obtained with 
the RTLinux code at LMB: 29us for jittter and 24 for timer interrupt.



> Cheers,
> F@lk
>
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@xxxxxxxxxxxxxx
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive :
> http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/

-- 
Alejandro Lucero
Director Técnico
+34 665 68 71 68
Valencia (SPAIN)
www.os3sl.com

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/