IBM Support

PM62144: Issue found with IDF framework in low power

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as program error.

Error description

  • Here is an issue we found, using the IDF framework.
    On DPF projects, the IDF recurrence is set to 10ms and the IDF
    framework
    task is called every 10ms in 'high power' mode.
    But this the framework is sometimes also used in 'low power'
    mode, with
    a longer scheduler task recurrence. We use a system time that is
    not
    affected by the BCM mode to increment by n the free running
    counter of
    the framework.
    Issue found:
    When two time outs are pending in low power mode, sometimes one
    time out
    is never notified: it is keeped undefinitely in the 'busy list'
    of the
    time out manger.
    Explainations:
    The IDF framework task call a TM manager function that returns a
    timeout
    that just expired or NULL if none. The lastTicks variable is
    updated on
    each call with the current time counter value, wether a new
    timeout to
    notify was found or not.
    struct RiCTimeout* RiCTmManager_getExpiredTimeout(void) {
    ../..
    RiCTmManager.lastTicks = currentTicks;
    return aTimeout;
    /*#]*/
    }
    A small function is called to evaluate if a time out has expired
    or not,
    using indirectly the lastTicks value.
    RiCBoolean RiCTimeout_isExpired(RiCTimeout* const me, timeUnit
    lastTicks, timeUnit currTicks) {
    /*#[ operation isExpired(timeUnit,timeUnit) */
    if (lastTicks ?= currTicks)
    {
    return( (me-?deliveryTicks ?= currTicks) ??
    (lastTicks ?= me-?deliveryTicks));
    }
    else
    {
    /* system tick counter was reset */
    return( (me-?deliveryTicks ?= currTicks) ||
    (lastTicks ?= me-?deliveryTicks));
    }
    /*#]*/
    }
    If a timeout's deliveryTicks value is lower than lastTicks value
    it will
    not be notified. This is what happens when two timeouts have
    very close
    deliveryTicks values. If the timeout with the greatest
    deliveryTicks
    value is notified first, the second will never be considered as
    'expired'.
    We fixed the issue by moving the RiCTmManager.lastTicks update
    in the
    tick() routine of the IDF framework task:
    static void tick(struct RiCTask* aTask) {
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    ****************************************************************
    * PROBLEM DESCRIPTION:                                         *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    When using the IDF framework in "low power" mode, if two
    timeouts are pending, sometimes one timeout is never
    notified - it is kept indefinitely on the "busy list" of the
    timeout manager.
    

Problem conclusion

  • This problem was solved by the modification made to
    RiCTimeout_isExpired in a previous release.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM62144

  • Reported component name

    TLOGIC RHAPSODY

  • Reported component ID

    5724V74RP

  • Reported release

    750

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-04-10

  • Closed date

    2012-11-27

  • Last modified date

    2012-11-27

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

  • Fixed component name

    TLOGIC RHAPSODY

  • Fixed component ID

    5724V74RP

Applicable component levels

  • R750 PSN

       UP



Document information

More support for: Rational Rhapsody

Software version: 7.5

Reference #: PM62144

Modified date: 27 November 2012