Stuck in a 'for' loop in _Watchdog_Insert.

[Thomas Doerfler]

Nick,

I agree, the result of the "next" operation should not point to itself.

You are not hitting the "strict aliasing rule" problem we have found
years ago?

Hint: search for "alias" and "Peer Stritzinger" in the mailing list archive.

wkr,

Thomas.


Am 20.05.2010 17:13, schrieb Nick Thomas:
> 
>> Nick,
>>
>> unfortunately you do not provide real information about the system you
>> are using. So it is really difficult to help you :-(
>>
> 
> Hi Thomas,
> 
> The system I am using is RTEMS 4.7.1. It's code in watchdoginsert.c,
> watchdogadjust.c and watchdogtickle.c, these are all in cpukit/score/src.
> So, they are not specific to any hardware.
> 
> There is already a comment in _Watchdog_Tickle in watchdogtickle.c which
> says this:
> 
>   /*
>    * For some reason, on rare occasions the_watchdog->delta_interval
>    * of the head of the watchdog chain is 0.  Before this test was
>    * added, on these occasions an event (which usually was supposed
>    * to have a timeout of 1 tick would have a delta_interval of 0, which
>    * would be decremented to 0xFFFFFFFF by the unprotected 
>    * "the_watchdog->delta_interval--;" operation.
>    * This would mean the event would not timeout, and also the chain would
>    * be blocked, because a timeout with a very high number would be at the
>    * head, rather than at the end.
>    * The test "if (the_watchdog->delta_interval != 0)"
>    * here prevents this from occuring. 
>    * 
>    * We were not able to categorically identify the situation that causes 
>    * this, but proved it to be true empirically.  So this check causes 
>    * correct behaviour in this circumstance.
>    * 
>    * The belief is that a race condition exists whereby an event at the head
>    * of the chain is removed (by a pending ISR or higher priority task)
>    * during the _ISR_Flash( level ); in _Watchdog_Insert, but the watchdog 
>    * to be inserted has already had its delta_interval adjusted to 0, and 
>    * so is added to the head of the chain with a delta_interval of 0.  
>    * 
>    * Steven Johnson - 12/2005 (gcc-3.2.3 -O3 on powerpc)
>    */
> 
> This describes pretty much the behavior I am seeing, i.e.
> the_watchdog->delta_interval == 0.
> 
> However, contrary to the above comments - removing the _ISR_Flash( level )
> call from _Watchdog_Insert doesn't fix the issue.
> 
> I understand why I am stuck in this 'for' loop when this happens, but I
> don't understand why this code doesn't break out of it when we get to the
> end of the linked list:
> 
> if ( delta_interval == 0 || !_Watchdog_Next( after ) )
>        break;
> 
> i.e. why doesn't !_Watchdog_Next( after ) return NULL at the end of the
> list?
> 
> For some reason it points back to itself!!!!! So the for loop is still
> engaged.
> 
> 
> Regards
> 
> Nick
> 
> 
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users


-- 
--------------------------------------------
Embedded Brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18908079-2
Fax:   +49-89-18908079-9