On Tue, 2005-08-30 at 15:34 -0700, Daniel Walker wrote:
> Have you tried turning on
> "Non-preemptible critical section latency timing" or "Latency tracing"
I just turned on the following:
CONFIG_CRITICAL_PREEMPT_TIMING
CONFIG_CRITICAL_IRQSOFF_TIMING
CONFIG_LATENCY_TRACE
recompiled and
Have you tried turning on
"Non-preemptible critical section latency timing" or "Latency tracing"
I don't know if it's related to the PI changes, but I'm getting a crash
with those on em64t .
With both above options I get
<0>init[1]: segfault at 8010ef44 rip 8010ef44 rsp
Hi Ingo,
Looks like the BKL is a little more complicated than what I first sent.
I've been analyzing the logic and found that there's a point in time
where the BKL->P1->L1->P2->BKL can exist without any of the spinlocks
protecting it. That is after P1 blocks on L1 but before it schedules
out and
Hi Ingo,
Looks like the BKL is a little more complicated than what I first sent.
I've been analyzing the logic and found that there's a point in time
where the BKL-P1-L1-P2-BKL can exist without any of the spinlocks
protecting it. That is after P1 blocks on L1 but before it schedules
out and
Have you tried turning on
Non-preemptible critical section latency timing or Latency tracing
I don't know if it's related to the PI changes, but I'm getting a crash
with those on em64t .
With both above options I get
0init[1]: segfault at 8010ef44 rip 8010ef44 rsp
On Tue, 2005-08-30 at 15:34 -0700, Daniel Walker wrote:
Have you tried turning on
Non-preemptible critical section latency timing or Latency tracing
I just turned on the following:
CONFIG_CRITICAL_PREEMPT_TIMING
CONFIG_CRITICAL_IRQSOFF_TIMING
CONFIG_LATENCY_TRACE
recompiled and booted.
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> I just found another deadlock in the pi_lock logic. The PI logic is
> very dependent on the P1->L1->P2->L2->P3 order. But our good old
> friend is back, the BKL.
>
> Since the BKL is let go and regrabbed even if a task is grabbing
>
Ingo,
I just found another deadlock in the pi_lock logic. The PI logic is
very dependent on the P1->L1->P2->L2->P3 order. But our good old friend
is back, the BKL.
Since the BKL is let go and regrabbed even if a task is grabbing another
lock, it messes up the order. For example, it can do the
Hubert Tonneau wrote:
I gave this one a spin, and my laptop locked hard after something like one hour
(everything frozen). As a result what I report is probably not very helpfull.
It was the first time I was trying an RT kernel, and the stock kernel works ok
on this laptop (except suspend, but
On Mon, 2005-08-29 at 17:18 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 2005-08-29 at 10:48 +0200, Ingo Molnar wrote:
> >
> > >
> > > - x86_64 boot fix (Daniel Walker)
> >
> > Ingo, Did this work for you?
>
> nope, it's a UP box.
Does it hang early
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-08-29 at 10:48 +0200, Ingo Molnar wrote:
>
> >
> > - x86_64 boot fix (Daniel Walker)
>
> Ingo, Did this work for you?
nope, it's a UP box.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Mon, 2005-08-29 at 10:48 +0200, Ingo Molnar wrote:
>
> - x86_64 boot fix (Daniel Walker)
Ingo, Did this work for you?
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
I gave this one a spin, and my laptop locked hard after something like one hour
(everything frozen). As a result what I report is probably not very helpfull.
It was the first time I was trying an RT kernel, and the stock kernel works ok
on this laptop (except suspend, but one can do without it).
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> I think you have a slight glitch in your patch.
>
> -- Steve
>
> $ patch -p1 -s < /work/realtime-patches/patch-2.6.13-rt1
> The next patch would delete the file Makefile.rej,
> which does not exist
Ingo,
I think you have a slight glitch in your patch.
-- Steve
$ patch -p1 -s < /work/realtime-patches/patch-2.6.13-rt1
The next patch would delete the file Makefile.rej,
which does not exist! Assume -R? [n]
Apply anyway? [n]
-
To unsubscribe from this list: send the line "uns
i have released the 2.6.13-rt1 tree, which can be downloaded from the
usual place:
http://redhat.com/~mingo/realtime-preempt/
the new "eliminate the global PI lock" code from Steven Rostedt is now
ready for prime-time. Smaller fixes otherwise. Please re-report any
remaining r
i have released the 2.6.13-rt1 tree, which can be downloaded from the
usual place:
http://redhat.com/~mingo/realtime-preempt/
the new eliminate the global PI lock code from Steven Rostedt is now
ready for prime-time. Smaller fixes otherwise. Please re-report any
remaining regressions
Ingo,
I think you have a slight glitch in your patch.
-- Steve
$ patch -p1 -s /work/realtime-patches/patch-2.6.13-rt1
The next patch would delete the file Makefile.rej,
which does not exist! Assume -R? [n]
Apply anyway? [n]
-
To unsubscribe from this list: send the line unsubscribe linux
* Steven Rostedt [EMAIL PROTECTED] wrote:
Ingo,
I think you have a slight glitch in your patch.
-- Steve
$ patch -p1 -s /work/realtime-patches/patch-2.6.13-rt1
The next patch would delete the file Makefile.rej,
which does not exist! Assume -R? [n]
Apply anyway? [n]
indeed. I
I gave this one a spin, and my laptop locked hard after something like one hour
(everything frozen). As a result what I report is probably not very helpfull.
It was the first time I was trying an RT kernel, and the stock kernel works ok
on this laptop (except suspend, but one can do without it).
On Mon, 2005-08-29 at 10:48 +0200, Ingo Molnar wrote:
- x86_64 boot fix (Daniel Walker)
Ingo, Did this work for you?
Daniel
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
* Daniel Walker [EMAIL PROTECTED] wrote:
On Mon, 2005-08-29 at 10:48 +0200, Ingo Molnar wrote:
- x86_64 boot fix (Daniel Walker)
Ingo, Did this work for you?
nope, it's a UP box.
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On Mon, 2005-08-29 at 17:18 +0200, Ingo Molnar wrote:
* Daniel Walker [EMAIL PROTECTED] wrote:
On Mon, 2005-08-29 at 10:48 +0200, Ingo Molnar wrote:
- x86_64 boot fix (Daniel Walker)
Ingo, Did this work for you?
nope, it's a UP box.
Does it hang early during like ACPI ,
Hubert Tonneau wrote:
I gave this one a spin, and my laptop locked hard after something like one hour
(everything frozen). As a result what I report is probably not very helpfull.
It was the first time I was trying an RT kernel, and the stock kernel works ok
on this laptop (except suspend, but
Ingo,
I just found another deadlock in the pi_lock logic. The PI logic is
very dependent on the P1-L1-P2-L2-P3 order. But our good old friend
is back, the BKL.
Since the BKL is let go and regrabbed even if a task is grabbing another
lock, it messes up the order. For example, it can do the
* Steven Rostedt [EMAIL PROTECTED] wrote:
Ingo,
I just found another deadlock in the pi_lock logic. The PI logic is
very dependent on the P1-L1-P2-L2-P3 order. But our good old
friend is back, the BKL.
Since the BKL is let go and regrabbed even if a task is grabbing
another lock,
26 matches
Mail list logo
