Success was: hanging tasks
Angelo Fraietta
angelo_f at bigpond.com
Mon Feb 17 05:00:20 UTC 2003
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)
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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20030217/3172f33d/attachment-0001.html>
More information about the users
mailing list