Re: Strange Badness with RT Spin Lock

[Darcy Watkins <dwatkins@tranzeo.com>]

Further to what I reported earlier regarding my unusual bug, adding a
memory barrier such as shown below also prevents the oops (and is a lot
cleaner than putting in unused dummy static instance(s) of spinlocks).

This has me scratching my head.  Isn't the PPC405EP a uni-processor?  I
suppose my problem could be an interaction of RT-Preemption with
predictive loads / deferred stores or perhaps there is a memory barrier
related bug in the spinlock/rtmutex code?.


>         // We dispatch the PDU.
>          ...
> 
> #ifdef USE_MUTEX_CHECK_HACK
>          MUTEX_CHECK_SAVE_LOCKED;
> #endif
>          spin_unlock(&tree_lock);
> #ifdef USE_MUTEX_CHECK_HACK
>          rt_mutex_owner_check("process_packed_pdu() - no frag - before
> cblk()");
>          MUTEX_CHECK_SAVE_UNLOCKED;
> #endif
>          clbk(new_skb, gen_header_p->cid);
> 
> 

         barrier(); // memory barrier

> #ifdef USE_MUTEX_CHECK_HACK
>          MUTEX_CHECK_DUMP_ON_BUG;
>          rt_mutex_owner_check("process_packed_pdu() - no frag - after
> cblk()");
> #endif
>          spin_lock(&tree_lock);




On Fri, 2008-08-08 at 12:56 -0700, Darcy Watkins wrote:
> Hello,
> 
> I have a very unusual bug I have been trying to get to the bottom of.
> 
--snip!--


-- 


Regards,

Darcy

--------------
Darcy L. Watkins - Senior Software Developer
Tranzeo Wireless Technologies, Inc.
19273 Fraser Way, Pitt Meadows, BC, Canada V3Y 2V4
T:604-460-6002 ext:410
http://www.tranzeo.com