* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> On Sat, 2005-02-05 at 08:59 +0100, Ingo Molnar wrote:
>
> > hm - i had a fix in this area in the -V0.7 series. Then i thought this
> > is a performance fix only and dropped it eventually, but could you give
> > it a go - does it fix the deadlock?
>
* Steven Rostedt [EMAIL PROTECTED] wrote:
On Sat, 2005-02-05 at 08:59 +0100, Ingo Molnar wrote:
hm - i had a fix in this area in the -V0.7 series. Then i thought this
is a performance fix only and dropped it eventually, but could you give
it a go - does it fix the deadlock?
On Sat, 2005-02-05 at 08:59 +0100, Ingo Molnar wrote:
> hm - i had a fix in this area in the -V0.7 series. Then i thought this
> is a performance fix only and dropped it eventually, but could you give
> it a go - does it fix the deadlock?
>
> Ingo
Yep, it worked! I tried a similar fix
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> while(unlikely(error == IN_WAKEUP)) {
> cpu_relax();
> error = queue.status;
> }
>
> So, what looks to be happening is that as soon as the parent wakes up
> the child, the child preempts the parent, and hits
* Steven Rostedt [EMAIL PROTECTED] wrote:
while(unlikely(error == IN_WAKEUP)) {
cpu_relax();
error = queue.status;
}
So, what looks to be happening is that as soon as the parent wakes up
the child, the child preempts the parent, and hits this while
On Sat, 2005-02-05 at 08:59 +0100, Ingo Molnar wrote:
hm - i had a fix in this area in the -V0.7 series. Then i thought this
is a performance fix only and dropped it eventually, but could you give
it a go - does it fix the deadlock?
Ingo
Yep, it worked! I tried a similar fix earlier
On Thu, 2005-02-03 at 21:18 -0500, Steven Rostedt wrote:
> Here's the problem: If I raise the priorities of the processes before
> zeroing the semaphore, the machine hangs. If I zero the semaphore
> before raising the priorities, the program runs fine.
Hi Ingo,
I've looked into this and found
On Thu, 2005-02-03 at 21:18 -0500, Steven Rostedt wrote:
Here's the problem: If I raise the priorities of the processes before
zeroing the semaphore, the machine hangs. If I zero the semaphore
before raising the priorities, the program runs fine.
Hi Ingo,
I've looked into this and found
> OK that was the note I was about to send, but like I stated, it isn't a
> problem now that the timer interrupt is back to a hard interrupt. I just
> showing this to you so you can see the real problem. Maybe I'm missing
> something, and maybe I'm not. I'll try to write up something that shows
On Tue, 2005-02-01 at 21:14 +0100, Ingo Molnar wrote:
> i have released the -V0.7.37-02 Real-Time Preemption patch, which can be
> downloaded from the usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> the big change in the patch is increased architecture support: most
> notable
* Eugeny S. Mints <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> >i have released the -V0.7.37-02 Real-Time Preemption patch, which can be
> >downloaded from the usual place:
> >
> > http://redhat.com/~mingo/realtime-preempt/
> Minor fix for deadlock tracer: "...acquired at XXX" may print
Ingo Molnar wrote:
i have released the -V0.7.37-02 Real-Time Preemption patch, which can be
downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
Minor fix for deadlock tracer: "...acquired at XXX" may print caller's
of an up() eip instead of eip of caller of a down() in
Ingo Molnar wrote:
i have released the -V0.7.37-02 Real-Time Preemption patch, which can be
downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
Minor fix for deadlock tracer: ...acquired at XXX may print caller's
of an up() eip instead of eip of caller of a down() in
* Eugeny S. Mints [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
i have released the -V0.7.37-02 Real-Time Preemption patch, which can be
downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
Minor fix for deadlock tracer: ...acquired at XXX may print caller's
of
On Tue, 2005-02-01 at 21:14 +0100, Ingo Molnar wrote:
i have released the -V0.7.37-02 Real-Time Preemption patch, which can be
downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
the big change in the patch is increased architecture support: most
notable i've
OK that was the note I was about to send, but like I stated, it isn't a
problem now that the timer interrupt is back to a hard interrupt. I just
showing this to you so you can see the real problem. Maybe I'm missing
something, and maybe I'm not. I'll try to write up something that shows
the
i have released the -V0.7.37-02 Real-Time Preemption patch, which can be
downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
the big change in the patch is increased architecture support: most
notable i've merged the MIPS patch from Manish Lachwani. Also, the x64
port
i have released the -V0.7.37-02 Real-Time Preemption patch, which can be
downloaded from the usual place:
http://redhat.com/~mingo/realtime-preempt/
the big change in the patch is increased architecture support: most
notable i've merged the MIPS patch from Manish Lachwani. Also, the x64
port
18 matches
Mail list logo
