[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] Patch for stability under heavy IRQ load
On Wednesday 06 September 2006 12:29, Brettschneider Falk wrote:
> 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
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.
> microblaze-uclinux mailing list
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive :
+34 665 68 71 68
microblaze-uclinux mailing list
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/