On Fri, 16 Nov 2007, Remy Bohmer wrote: > Hello All, > > I have a problem with the RT-mutex code and signals. The problem is > very easily reproducible, but I do not have found the root-cause yet. > I hope someone can help me on this one. > > This is what I am doing: > * I have a simple character driver with a read call.(called spi_read() > in the logging below ) > * The read call blocks on a semaphore until some condition in hardware > is reached. (in the routine wait_for_io_level(), see logging below) > * I use a down_interruptible() call on a 'struct semaphore' type > semaphore, which eventually blocks on a mutex. (the semaphore is, of > course, initialised with sema_init() ) The above sounds more like you need a completion. What's used to wake up the caller of down_interruptible? Can you post some code to see what you are doing. That would make it much easier to analyze. -- Steve > > What happens is that when a user-space RT-thread is waiting on the > semaphore through the spi_read() call, and a signal arrives during the > wait at this thread (like e.g. CTRL-C), the kernel starts oopsing > until it is as good as brain-dead. > > If I do NOT sent a posix-signal the code/mutex/semaphore is working > properly for days, > So, it seems to be related by waking up from a blocking situation, > because of a pending posix-signal. > > I tried also the types 'struct compat_semaphore', and mutexes; none of > them work. > In fact the real Mutex type, declared with init_MUTEX() has the same problem. > > Anyone an idea? > Below the kernel oops output. (I run on ARM, but I think that should > not matter for this problem) > - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
