hanging tasks - information about task state etc.

[Peter Mueller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Joel,

yes I'm using m68k (variant of efi332) and the snapshop 20020628.
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?)?
In what snapshot is the PR267 fixed?

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