hanging tasks - information about task state etc.

[Joel Sherrill]

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