Hi I think we are seeing this bug based on some detection code the Daniels added. They can explain the detection code and send you a patch but it basically verifies that the value of is_executing is as expected when you begin to restore the heir. If not, it traps.
We don't see this under normal block/unblock operations but there is a "check for migrations" pass at the end of those and affinity changes which does a check if the highest priority ready thread could displace a scheduled thread. When this pass runs, we end up wanting to move an executing thread from one core to another. This seems to very reliably trip their check. I wondered if we had optimized the migration code until it broke so I locally replaced it with set state/clear state which we know works. So we identify a scheduled thread which could be replaced with the highest priority ready thread with the consideration of affinity. If so, then we set state migrating on that scheduled thread and then clear that state. This should (and does) result in the desired highest priority thread replacing in in the scheduled set. But the check is tripped when that scheduled/executing thread is outgoing thread on one core and incoming on another. I see this as two state changes within a single scheduler operation but that sounds the same as your double migration. We are likely replacing heir twice and tripping the same condition. If you want a test case of this, we can get our code cleaned up and push it. Gaisler will have to send their test code. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel