Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals

2007-11-17 Thread Steven Rostedt
On Sat, 17 Nov 2007, Remy Bohmer wrote: Hello Steven, The taker of a mutex must also be the one that releases it. I don't see how you could use a mutex for this. It really requires some kind of completion, or a compat_semaphore. I tried several ways of working around the bug, even

Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals

2007-11-17 Thread Steven Rostedt
On Sat, 17 Nov 2007, Steven Rostedt wrote: On Sat, 17 Nov 2007, Remy Bohmer wrote: * PI should only take place if it is for 100% sure that the 'struct semaphore' is used as a mutex. And this is only the case when it is initialised with init_MUTEX(). Well, we can't determine that with

Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals

2007-11-17 Thread Remy Bohmer
Hello Steven, It should print out warnings, do you have CONFIG_DEBUG_RT_MUTEXES set? Nope, not yet... I will do that on Monday also. (On ARM I have as less as debug options enabled per default, because it eats too much CPU-power) * PI should only take place if it is for 100% sure that the

Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals

2007-11-17 Thread Daniel Walker
On Sat, 2007-11-17 at 12:44 +0100, Remy Bohmer wrote: Hello Steven, The taker of a mutex must also be the one that releases it. I don't see how you could use a mutex for this. It really requires some kind of completion, or a compat_semaphore. I tried several ways of working around the

Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals

2007-11-17 Thread Remy Bohmer
Hello Daniel, Thanks for looking into it also. Steven already made clear to me that the 'struct semaphore' type on the RT-kernel should not be used as a counting-semaphore, but as some sort of legacy-mutex... (The confusion that this will cause is clear by now...) I still do not understand the

Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals

2007-11-17 Thread Daniel Walker
On Sat, 2007-11-17 at 18:09 +0100, Remy Bohmer wrote: Actually, IMO, compat_semaphores behave like semaphores should behave, and thus the same as they behave on a non-RT kernel, and at the locations where the semaphores are now misused as mutexes on RT, we should replace them by

Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals

2007-11-17 Thread Ingo Molnar
* Daniel Walker [EMAIL PROTECTED] wrote: Actually, IMO, compat_semaphores behave like semaphores should behave, and thus the same as they behave on a non-RT kernel, and at the locations where the semaphores are now misused as mutexes on RT, we should replace them by

Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals

2007-11-17 Thread Ingo Molnar
* Daniel Walker [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 18:46 +0100, Ingo Molnar wrote: * Daniel Walker [EMAIL PROTECTED] wrote: Actually, IMO, compat_semaphores behave like semaphores should behave, and thus the same as they behave on a non-RT kernel, and at the

Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals

2007-11-17 Thread Daniel Walker
On Sat, 2007-11-17 at 19:04 +0100, Ingo Molnar wrote: split the list with you? Feel free to take any of those :-) dev-sem is nontrivial and probably not possible right now - and some of the others might be problematic too. But there might be fixable ones in the list. This shouldnt become

Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals

2007-11-17 Thread Remy Bohmer
Sure, you want to split the list? split the list with you? Feel free to take any of those :-) dev-sem is nontrivial and probably not possible right now - and some of the others might be problematic too. But there might be fixable ones in the list. This shouldnt become like the BKL