<html>
<head>
</head>
<body>
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)<br>
<br>
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<br>
(There are actually 4 tasks, but I removed the tasks running termios - including
the initialisation - to eliminate termios)<br>
<br>
eg <br>
<br>
while (1)<br>
{<br>
rtems_event_receive (SCHEDULE_EVENT_EVENT_FLAG, RTEMS_WAIT, <br>
rtems_interval(wait_interval),
&dummy);<br>
<br>
<br>
wait_interval = hal_include::Scheduler::processCallback (); // note that
this function takes two semaphores -- however -- that is not the problem<br>
}<br>
<br>
The Second task waits indefinitely for events from the interrupt routine.
If the task gets <br>
<br>
The third task prints the contents of a directory to the console<br>
<br>
<br>
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.<br>
<br>
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. <br>
<br>
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)<br>
<br>
Joel Sherrill wrote:<br>
<blockquote type="cite" cite="mid:3E3E8B65.27ED27E1@OARcorp.com">
<pre wrap=""><br>Peter Mueller wrote:<br></pre>
<blockquote type="cite">
<pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: SHA1<br><br>Hi Joel,<br><br>your hint solved my problem. The serial interface works for a long time<br>now without problems. Thanks!<br>I wonder what the best source of information is regarding all issues for a<br>specific cpu family. For example you mentioned a m68k code generation<br>issue in some of your last mail now solved in the latest gcc. II was not<br>aware of this neither of the bug 267 in gnats. Even I do my mest to follow<br>this mailing list closely.<br><br>What is the best way to get all this information (for a cpu family)? Is it<br>all in gnats?<br></pre>
</blockquote>
<pre wrap=""><!----><br>I wish it were but it isn't because all problems don't become PRs.<br><br>In general, if you are looking for fixed problems look at the ChangeLog<br>files. The releases now come with ChangeLog diffs.<br><br></pre>
<blockquote type="cite">
<pre wrap="">Peter<br><br>On Mon, 27 Jan 2003 13:15:31 -0600<br>Joel Sherrill <a class="moz-txt-link-rfc2396E" href="mailto:joel.sherrill@OARcorp.com"><joel.sherrill@OARcorp.com></a> wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap=""><br>Peter Mueller wrote:<br></pre>
<blockquote type="cite">
<pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: SHA1<br><br>Hi Joel,<br><br>yes I'm using m68k (variant of efi332) and the snapshop 20020628.<br></pre>
</blockquote>
<pre wrap="">Hmmm... a 332 is a cpu32 which I think was one of the variants<br>exhibiting this behavior.<br><br></pre>
<blockquote type="cite">
<pre wrap="">What is PR267? Is there a description of this bug and its solution<br>(btw. is there a bug tracking system like bugzilla available for<br>rtems?)?<br></pre>
</blockquote>
<pre wrap="">Yes. We have been using GNATS for a while now (we are over PR300 now).<br><br><a class="moz-txt-link-freetext" href="http://www.oarcorp.com/cgi-bin/gnatsweb.pl">http://www.oarcorp.com/cgi-bin/gnatsweb.pl</a><br><br>User/Password == guest/guest<br><br></pre>
<blockquote type="cite">
<pre wrap="">In what snapshot is the PR267 fixed?<br></pre>
</blockquote>
<pre wrap="">Based upon the ChangeLog in score/cpu/m68k, it looks like any snapshot<br>newer than 26 Aug 2002.<br><br></pre>
<blockquote type="cite">
<pre wrap="">Thanks,<br>Peter<br><br>On Mon, 27 Jan 2003 08:18:45 -0600<br>Joel Sherrill <a class="moz-txt-link-rfc2396E" href="mailto:joel.sherrill@OARcorp.com"><joel.sherrill@OARcorp.com></a> wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap="">Peter .. what CPU are you using? This sounds a lot like the<br>behavior people got before an m68k specific fix went in. It was<br>tracked as PR267 and CVS shows the last fix as back in August. Any<br>chance you are using an m68k and something that old?<br><br>Thomas Doerfler wrote:<br></pre>
<blockquote type="cite">
<pre wrap="">Hello Peter,<br><br></pre>
<blockquote type="cite">
<pre wrap="">-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: SHA1<br><br>Hi Joel, Thomas,<br><br>thanks for your replies. dump_tasks finally helped me to find<br>one problem. A task waiting for an event that gets usually sent<br>from an irq. It turned out that the hardware triggering the irq<br>hangs sometimes so that the irq is missing and my task waits<br>forever.<br></pre>
</blockquote>
<pre wrap="">Normally I know things the other way round: Software guys find<br>"hardware errors" and later on the hardware guys find out that<br>the hardware was not initialized/used properly by the<br>software... :-)<br><br></pre>
<blockquote type="cite">
<pre wrap="">The other thing is not solved. Here I like to ask again for your<br>advice.. One of my tasks handles serial input. After my system<br>runs for a while this task seems to get not scheduled anymore<br>even if the system is not fully loaded. The task state is<br>8->STATES_DELAYING which means wait for timeout. This is ok<br>because my old efi332 serial driver polls the rcv buffer to<br>check if there is new data and waits for some ticks if nothing<br>is there. Could it be possible that rtems_task_wake_after does<br>not return for any reason?<br></pre>
</blockquote>
<pre wrap="">Hm, the only reasons I could think of would be:<br><br>- Interrupts for System Tick do no longer occure, because: The<br>interrupt is blocked, the timer has stopped or something<br>similar. Can you check, whether the system tick still occures<br>when your task hangs? You are working with a 68332 and BDM?<br>Stop the system when your task hangs and set a breakpoint into<br>the timer interrupt function. Does it get hit still?<br><br>- You call "rtems_task_wake_after" with a VERY long delay...<br>(quite improbable)<br><br>maybe this helps a bit...<br>Thomas.<br><br></pre>
<blockquote type="cite">
<pre wrap="">Thanks,<br>Peter<br><br></pre>
<blockquote type="cite">
<pre wrap="">Peter, the gdb script I have posted a couple of times is a<br>good start on seeing what the tasks in the system are up to.<br>I would like to see the gdb script eventually enhanced so that<br>it could give you some details<br>like decoding the task state into English and know that if in<br>certain states,<br>that Wait.id is what the task is waiting on.<br><br></pre>
<blockquote type="cite">
<pre wrap="">Thanks,<br>Peter<br><br></pre>
</blockquote>
</blockquote>
<pre wrap="">-----BEGIN PGP SIGNATURE-----<br>Version: GnuPG v1.0.7 (GNU/Linux)<br><br>iD8DBQE+MtP4UzCcwYQMTJoRAoYTAKClcG5NDW+t/idjCbjY5zkVQ/XS/QCeJdtn<br>LIz5tEKThN0Tw2ibUJKwj2w=<br>=8q0m<br>-----END PGP SIGNATURE-----<br></pre>
</blockquote>
<pre wrap="">--------------------------------------------<br>IMD Ingenieurbuero fuer Microcomputertechnik<br>Thomas Doerfler Herbststrasse 8<br>D-82178 Puchheim Germany<br>email: <a class="moz-txt-link-abbreviated" href="mailto:Thomas.Doerfler@imd-systems.de">Thomas.Doerfler@imd-systems.de</a><br>PGP public key available at: <a class="moz-txt-link-freetext" href="http://www.imd">http://www.imd</a>-<br>systems.de/pgp_keys.htm<br></pre>
</blockquote>
<pre wrap="">--<br>Joel Sherrill, Ph.D. Director of Research & Development<br><a class="moz-txt-link-abbreviated" href="mailto:joel@OARcorp.com">joel@OARcorp.com</a> On-Line Applications Research<br>Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>Support Available (256) 722-9985<br><br></pre>
</blockquote>
<pre wrap="">- --<br>-----BEGIN PGP SIGNATURE-----<br>Version: GnuPG v1.0.7 (GNU/Linux)<br><br>iD8DBQE+NYQaUzCcwYQMTJoRAnP+AJ40cl2znL8aOrcmfmoQZOWtVnrdaQCgvFX/<br>h2nMtyob4C+Q0GRbC52ADt4=<br>=rDda<br>-----END PGP SIGNATURE-----<br></pre>
</blockquote>
<pre wrap="">--<br>Joel Sherrill, Ph.D. Director of Research & Development<br><a class="moz-txt-link-abbreviated" href="mailto:joel@OARcorp.com">joel@OARcorp.com</a> On-Line Applications Research<br>Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>Support Available (256) 722-9985<br><br></pre>
</blockquote>
<pre wrap="">- --<br>-----BEGIN PGP SIGNATURE-----<br>Version: GnuPG v1.0.7 (GNU/Linux)<br><br>iD8DBQE+O7RRUzCcwYQMTJoRAtuEAKDQqRKTbXWaSsgoALm0HF6d9uB1NACfZpEa<br>OQ3s95oREnuSx2FqeRgoIp4=<br>=Jxlv<br>-----END PGP SIGNATURE-----<br></pre>
</blockquote>
<pre wrap=""><!----><br></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="$mailwrapcol">--
Angelo Fraietta
PO Box 859
Hamilton NSW 2303
Home Page
<a class="moz-txt-link-freetext" href="http://www.users.bigpond.com/angelo_f/">http://www.users.bigpond.com/angelo_f/</a>
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)</pre>
<br>
</body>
</html>