Success was: hanging tasks

Sat Feb 1 11:49:37 UTC 2003

-----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?

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-----