This can sometimes happen, if we have stupid code that does things like this:
mutex_kernel_wait(&tss_tree_mutex); // lock the mutex
mutex_kernel_wait(&tss_tree_mutex); // attempt to lock it again
This will never work, because our mutexing code presumes multi-tasking to be enabled (which is a bit silly, but it's the way it is) and will try to dispatch the next available task if the mutex happens to be locked... This all makes sense if multi-tasking is indeed enabled, since you don't want to wait in the current timeslice more than necessary; it's better to give another process a (smaller) slice to let it run, hopefully reducing overall lock contention.
So, if mutex_kernel_wait is being called like this, dispatch_next should do a DEBUG_HALT, clearly indicating that this likely to be the problem. This will simplify our lives while debugging the code.
This can sometimes happen, if we have stupid code that does things like this:
This will never work, because our mutexing code presumes multi-tasking to be enabled (which is a bit silly, but it's the way it is) and will try to dispatch the next available task if the mutex happens to be locked... This all makes sense if multi-tasking is indeed enabled, since you don't want to wait in the current timeslice more than necessary; it's better to give another process a (smaller) slice to let it run, hopefully reducing overall lock contention.
So, if
mutex_kernel_waitis being called like this,dispatch_nextshould do aDEBUG_HALT, clearly indicating that this likely to be the problem. This will simplify our lives while debugging the code.