On Tue, 2007-11-20 at 21:37 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 2007-11-17 at 18:46 +0100, Ingo Molnar wrote:
> >
> > > fixing the top 20:
> >
> > There are about 25 DECLARE_MUTEX() semaphores remaining .. One is the
> > BKL which I would guess c
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-11-17 at 18:46 +0100, Ingo Molnar wrote:
>
> > fixing the top 20:
>
> There are about 25 DECLARE_MUTEX() semaphores remaining .. One is the
> BKL which I would guess can't be converted. The others I've looked at
> appear to be trivial
On Sat, 2007-11-17 at 18:46 +0100, Ingo Molnar wrote:
> fixing the top 20:
>
There are about 25 DECLARE_MUTEX() semaphores remaining .. One is the
BKL which I would guess can't be converted. The others I've looked at
appear to be trivial find/replace changes to get them to use the mutex
type.. A
On Mon, 2007-11-19 at 16:51 +0100, Remy Bohmer wrote:
> Hello Daniel,
>
> Can we coordinate who is doing what somehow, to prevent double work?
I actually haven't looked at any on Ingo's list (i8042tregs).. Feel free
to call out the ones your looking at tho..
Daniel
-
To unsubscribe from this li
Hello Daniel,
Can we coordinate who is doing what somehow, to prevent double work?
Remy
2007/11/19, Daniel Walker <[EMAIL PROTECTED]>:
> On Mon, 2007-11-19 at 02:24 -0500, Jon Masters wrote:
> > On Sat, 2007-11-17 at 09:55 -0800, Daniel Walker wrote:
> >
> > > Sure, you want to split the list?
>
On Mon, 2007-11-19 at 02:24 -0500, Jon Masters wrote:
> On Sat, 2007-11-17 at 09:55 -0800, Daniel Walker wrote:
>
> > Sure, you want to split the list?
>
> I'm happy to grab a few of these too. Let me know if either of you or
> Ingo is working on the whole lot and about to dump it on us ;-)
I wa
On Mon, 19 Nov 2007, Remy Bohmer wrote:
> Hello Steven,
>
> > > OK, I wont be able to work on this this weekend, but I'll try to get to it
> > > on Monday. A better example to show the bug you are looking for is simply
> > > create a mutex and create a thread that grabs that mutex and goes to
>
Hello Steven,
> > OK, I wont be able to work on this this weekend, but I'll try to get to it
> > on Monday. A better example to show the bug you are looking for is simply
> > create a mutex and create a thread that grabs that mutex and goes to
> > sleep. Have your driver read grab that mutex with
On Sat, 2007-11-17 at 09:55 -0800, Daniel Walker wrote:
> Sure, you want to split the list?
I'm happy to grab a few of these too. Let me know if either of you or
Ingo is working on the whole lot and about to dump it on us ;-)
Jon.
-
To unsubscribe from this list: send the line "unsubscribe li
On Sun, Nov 18, 2007 at 01:33:50PM +0100, Peter Zijlstra wrote:
>
> On Sat, 2007-11-17 at 10:12 -0800, Daniel Walker wrote:
>
> > What specifically is wrong with dev->sem ?
>
> Nothing really, other than that they use semaphores to avoid lockdep :-/
>
> I think I know how to annotate this, afte
On Sat, 2007-11-17 at 10:12 -0800, Daniel Walker wrote:
> What specifically is wrong with dev->sem ?
Nothing really, other than that they use semaphores to avoid lockdep :-/
I think I know how to annotate this, after Alan Stern explained all the
use cases, but I haven't come around to implement
> > 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 co
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 b
* 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 a
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 locations where the semaphores are now mis
* 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 different
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 differentl
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 pr
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 a
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
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
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
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 tried
implementing it with kernel threads and pr
On Sat, 17 Nov 2007, Remy Bohmer wrote:
> Hello Steven,
>
> Thanks for your reply
>
> > The above sounds more like you need a completion.
> Funny, I first started with using completion structures, but that did
> not work either. I get similar OOPses on all these kind of locking
> mechanisms, as
Hello Steven,
Thanks for your reply
> The above sounds more like you need a completion.
Funny, I first started with using completion structures, but that did
not work either. I get similar OOPses on all these kind of locking
mechanisms, as long as I use the _interruptible() type. I tried every
wo
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 characte
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 loggi
27 matches
Mail list logo
