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
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
