Messages in this thread | | | Date | Wed, 1 Jun 2005 19:28:41 +0200 (METDST) | From | Esben Nielsen <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.12-rc4-V0.7.47-06 |
| |
Replace init_MUTEX_LOCKED(&policy->lock); with init_MUTEX(&policy->lock); down(&policy->lock);
Compiles here... Would also work upstream.
init_MUTEX_LOCKED() isn't very nice :-(
Esben
On Sat, 28 May 2005, Ingo Molnar wrote:
> > * Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote: > > > I wrote: > > >I'm attaching a patch which changes a semaphore in cpufreq into a > > >completion. With this patch, my system runs OK even with cpufreqd. > > > > > > > Although the patch worked for me, it was probably bogus. > > no, it was quite fine i think. > > > The real reason why cpufreq caused problems was that it does: > > init_MUTEX_LOCKED(&policy->lock); > > and later: > > up(&policy->lock); > > where policy->lock is declared as: > > struct semaphore lock; > > > > In PREEMPT_RT, the init_MUTEX_LOCKED is defined in include/linux/rt_lock.h : > > /* > > * No locked initialization for RT semaphores: > > */ > > #define init_MUTEX_LOCKED(sem) compat_init_MUTEX_LOCKED(sem) > > (BTW, I don't understand why we have init_MUTEX but no init_MUTEX_LOCKED > > for RT semaphores). > > RT semaphores have stricter semantics than Linux semaphores. One > property is that there always needs to be an owner of a semaphore. If a > semaphore gets initialized as init_MUTEX_LOCKED, it is a fair indication > that the semaphore is really used as a completion object - with no > stable owner. (e.g. at insmod time when the init_MUTEX_LOCKED is done, > the insmod thread will go away after some time, leaving the semaphore > 'orphaned') > > > So the fix is to change the lock type into compat_semaphore. I'm > > attaching the patch. It works for me with 2.6.12-rc5-RT-V0.7.47-12. > > it would be nice to get the conversion to completions upstream. It is a > perfectly fine solution. The compat_semaphore thing is another, easier > solution. > > Ingo > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |