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