Success was: hanging tasks
Joel Sherrill
joel.sherrill at OARcorp.com
Mon Feb 17 23:48:23 UTC 2003
Angelo Fraietta wrote:
>
> Where do I find the change log. I have found a problem with the
> snapshot I was using and am looking to see if if the problem was fixed
> in the latest snapshot. The snapshot I was am using is 20020301 (I am
> trying to get my linux machine to work so I can test the latest
> snapshot)
The snapshots come with a diff of the ChangeLogs between the last
snapshot
and the current one.
That is a pretty old snapshot (although 2002 still seems current to me
:),
and if you are on a 68k, there is a known interrupt problem fixed around
August. Go to http://www.oarcorp.com/cgi-bin/cvsweb.cgi and look
at the ChangeLog for cpukit/score/cpu/m68k. It has a PR number listed
in the ChangeLog also 247?).
I suppose the best thing to do would be to use CVS and ask for a
diff between two arbitrary dates.
> What is happening is this. I have three tasks -- one of which is a
> higher priority than the others which loops indefinitely after waiting
> for an event
> (There are actually 4 tasks, but I removed the tasks running termios -
> including the initialisation - to eliminate termios)
>
> eg
>
> while (1)
> {
> rtems_event_receive (SCHEDULE_EVENT_EVENT_FLAG, RTEMS_WAIT,
>
> rtems_interval(wait_interval), &dummy);
>
> wait_interval = hal_include::Scheduler::processCallback (); //
> note that this function takes two semaphores -- however -- that is not
> the problem
> }
>
> The Second task waits indefinitely for events from the interrupt
> routine. If the task gets
>
> The third task prints the contents of a directory to the console
>
> What has been happening is the higher priority task gets hung up just
> waiting forever unless I make the second task receive an event. I have
> done this by sending an event from my ISR during a diag poll from my
> IO card). This task does nothing in this instance except check for
> valid data and wait again). After doing this the high priority task
> goes again.
>
> I know that the timer is still going as If I am playing a music
> sequence I can hear the music catch up after freezing.
>
> Any Idea if this issue was ever noticed / fixed. (When I get my Linux
> machine working I will attempt to test on the current snapshot)
>
> Joel Sherrill wrote:
>
> > Peter Mueller wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >> Hi Joel,
> >> your hint solved my problem. The serial interface works for a long
> >> time
> >> now without problems. Thanks!
> >> I wonder what the best source of information is regarding all
> >> issues for a
> >> specific cpu family. For example you mentioned a m68k code
> >> generation
> >> issue in some of your last mail now solved in the latest gcc. II
> >> was not
> >> aware of this neither of the bug 267 in gnats. Even I do my mest
> >> to follow
> >> this mailing list closely.
> >> What is the best way to get all this information (for a cpu
> >> family)? Is it
> >> all in gnats?
> >>
> > I wish it were but it isn't because all problems don't become PRs.
> > In general, if you are looking for fixed problems look at the
> > ChangeLog
> > files. The releases now come with ChangeLog diffs.
> >
> >> Peter
> >> On Mon, 27 Jan 2003 13:15:31 -0600
> >> Joel Sherrill <joel.sherrill at OARcorp.com> wrote:
> >>
> >> > Peter Mueller wrote:
> >> >
> >> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> >> Hash: SHA1
> >> >> Hi Joel,
> >> >> yes I'm using m68k (variant of efi332) and the snapshop
> >> >> 20020628.
> >> >>
> >> > Hmmm... a 332 is a cpu32 which I think was one of the variants
> >> > exhibiting this behavior.
> >> >
> >> >> What is PR267? Is there a description of this bug and its
> >> >> solution
> >> >> (btw. is there a bug tracking system like bugzilla available
> >> >> for
> >> >> rtems?)?
> >> >>
> >> > Yes. We have been using GNATS for a while now (we are over PR300
> >> > now).
> >> > http://www.oarcorp.com/cgi-bin/gnatsweb.pl
> >> > User/Password == guest/guest
> >> >
> >> >> In what snapshot is the PR267 fixed?
> >> >>
> >> > Based upon the ChangeLog in score/cpu/m68k, it looks like any
> >> > snapshot
> >> > newer than 26 Aug 2002.
> >> >
> >> >> Thanks,
> >> >> Peter
> >> >> On Mon, 27 Jan 2003 08:18:45 -0600
> >> >> Joel Sherrill <joel.sherrill at OARcorp.com> wrote:
> >> >>
> >> >> > Peter .. what CPU are you using? This sounds a lot like the
> >> >> > behavior people got before an m68k specific fix went in. It
> >> >> > was
> >> >> > tracked as PR267 and CVS shows the last fix as back in
> >> >> > August. Any
> >> >> > chance you are using an m68k and something that old?
> >> >> > Thomas Doerfler wrote:
> >> >> >
> >> >> >> Hello Peter,
> >> >> >>
> >> >> >> > -----BEGIN PGP SIGNED MESSAGE-----
> >> >> >> > Hash: SHA1
> >> >> >> > Hi Joel, Thomas,
> >> >> >> > thanks for your replies. dump_tasks finally helped me to
> >> >> >> > find
> >> >> >> > one problem. A task waiting for an event that gets usually
> >> >> >> > sent
> >> >> >> > from an irq. It turned out that the hardware triggering
> >> >> >> > the irq
> >> >> >> > hangs sometimes so that the irq is missing and my task
> >> >> >> > waits
> >> >> >> > forever.
> >> >> >> >
> >> >> >> Normally I know things the other way round: Software guys
> >> >> >> find
> >> >> >> "hardware errors" and later on the hardware guys find out
> >> >> >> that
> >> >> >> the hardware was not initialized/used properly by the
> >> >> >> software... :-)
> >> >> >>
> >> >> >> > The other thing is not solved. Here I like to ask again
> >> >> >> > for your
> >> >> >> > advice.. One of my tasks handles serial input. After my
> >> >> >> > system
> >> >> >> > runs for a while this task seems to get not scheduled
> >> >> >> > anymore
> >> >> >> > even if the system is not fully loaded. The task state is
> >> >> >> > 8->STATES_DELAYING which means wait for timeout. This is
> >> >> >> > ok
> >> >> >> > because my old efi332 serial driver polls the rcv buffer
> >> >> >> > to
> >> >> >> > check if there is new data and waits for some ticks if
> >> >> >> > nothing
> >> >> >> > is there. Could it be possible that rtems_task_wake_after
> >> >> >> > does
> >> >> >> > not return for any reason?
> >> >> >> >
> >> >> >> Hm, the only reasons I could think of would be:
> >> >> >> - Interrupts for System Tick do no longer occure, because:
> >> >> >> The
> >> >> >> interrupt is blocked, the timer has stopped or something
> >> >> >> similar. Can you check, whether the system tick still
> >> >> >> occures
> >> >> >> when your task hangs? You are working with a 68332 and BDM?
> >> >> >> Stop the system when your task hangs and set a breakpoint
> >> >> >> into
> >> >> >> the timer interrupt function. Does it get hit still?
> >> >> >> - You call "rtems_task_wake_after" with a VERY long delay...
> >> >> >> (quite improbable)
> >> >> >> maybe this helps a bit...
> >> >> >> Thomas.
> >> >> >>
> >> >> >> > Thanks,
> >> >> >> > Peter
> >> >> >> >
> >> >> >> > > Peter, the gdb script I have posted a couple of times is
> >> >> >> > > a
> >> >> >> > > good start on seeing what the tasks in the system are up
> >> >> >> > > to.
> >> >> >> > > I would like to see the gdb script eventually enhanced so
> >> >> >> > > that
> >> >> >> > > it could give you some details
> >> >> >> > > like decoding the task state into English and know that
> >> >> >> > > if in
> >> >> >> > > certain states,
> >> >> >> > > that Wait.id is what the task is waiting on.
> >> >> >> > >
> >> >> >> > >> Thanks,
> >> >> >> > >> Peter
> >> >> >> > >>
> >> >> >> > -----BEGIN PGP SIGNATURE-----
> >> >> >> > Version: GnuPG v1.0.7 (GNU/Linux)
> >> >> >> > iD8DBQE+MtP4UzCcwYQMTJoRAoYTAKClcG5NDW+t/idjCbjY5zkVQ/XS/QCeJdtn
> >> >> >> > LIz5tEKThN0Tw2ibUJKwj2w=
> >> >> >> > =8q0m
> >> >> >> > -----END PGP SIGNATURE-----
> >> >> >> >
> >> >> >> --------------------------------------------
> >> >> >> IMD Ingenieurbuero fuer Microcomputertechnik
> >> >> >> Thomas Doerfler Herbststrasse 8
> >> >> >> D-82178 Puchheim Germany
> >> >> >> email: Thomas.Doerfler at imd-systems.de
> >> >> >> PGP public key available at: http://www.imd-
> >> >> >> systems.de/pgp_keys.htm
> >> >> >>
> >> >> > --
> >> >> > Joel Sherrill, Ph.D. Director of Research &
> >> >> > Development
> >> >> > joel at OARcorp.com On-Line Applications
> >> >> > Research
> >> >> > Ask me about RTEMS: a free RTOS Huntsville AL 35805
> >> >> > Support Available (256) 722-9985
> >> >> >
> >> >> - --
> >> >> -----BEGIN PGP SIGNATURE-----
> >> >> Version: GnuPG v1.0.7 (GNU/Linux)
> >> >> iD8DBQE+NYQaUzCcwYQMTJoRAnP+AJ40cl2znL8aOrcmfmoQZOWtVnrdaQCgvFX/
> >> >> h2nMtyob4C+Q0GRbC52ADt4=
> >> >> =rDda
> >> >> -----END PGP SIGNATURE-----
> >> >>
> >> > --
> >> > Joel Sherrill, Ph.D. Director of Research &
> >> > Development
> >> > joel at OARcorp.com On-Line Applications Research
> >> > Ask me about RTEMS: a free RTOS Huntsville AL 35805
> >> > Support Available (256) 722-9985
> >> >
> >> - --
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.0.7 (GNU/Linux)
> >> iD8DBQE+O7RRUzCcwYQMTJoRAtuEAKDQqRKTbXWaSsgoALm0HF6d9uB1NACfZpEa
> >> OQ3s95oREnuSx2FqeRgoIp4=
> >> =Jxlv
> >> -----END PGP SIGNATURE-----
> >>
>
> --
> Angelo Fraietta
>
> PO Box 859
> Hamilton NSW 2303
>
> Home Page
>
> http://www.users.bigpond.com/angelo_f/
>
> There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
> There are those who seek knowledge to be known by others - that is VANITY
> There are those who seek knowledge in order to serve - that is LOVE
> Bernard of Clairvaux (1090 - 1153)
--
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users
mailing list