Hello, I wrote:
could you resend them to me please?
Seeing that GENERIC_TIME has been thrown out from the -rt patch,
[...]
hm, i did that accidentally during a rebase. That was certainly not
meant to be a persistent condition.
ok, the delta below is what i've managed to restore from
Hello, I wrote:
could you resend them to me please?
Seeing that GENERIC_TIME has been thrown out from the -rt patch,
[...]
hm, i did that accidentally during a rebase. That was certainly not
meant to be a persistent condition.
ok, the delta below is what i've managed to restore from
Ingo Molnar wrote:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
could you resend them to me please?
Seeing that GENERIC_TIME has been thrown out from the -rt patch,
[...]
hm, i did that accidentally during a rebase. That was certainly not
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
>
> > >could you resend them to me please?
> >
> >Seeing that GENERIC_TIME has been thrown out from the -rt patch,
> > [...]
>
> hm, i did that accidentally during a rebase. That was certainly not
>
* Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
> >could you resend them to me please?
>
>Seeing that GENERIC_TIME has been thrown out from the -rt patch,
> [...]
hm, i did that accidentally during a rebase. That was certainly not
meant to be a persistent condition.
Ingo
-
To
Hello.
Ingo Molnar wrote:
as usual, bugreports, fixes and suggestions are welcome,
Be aware that even with the newest -rt patch, the PowerPC TOD
vsyscalls are still broken, i.e. glibc may return imprecise/incorrect
results for the related calls -- despite arch/powerpc/kernel/time.c
has
Hello.
Ingo Molnar wrote:
as usual, bugreports, fixes and suggestions are welcome,
Be aware that even with the newest -rt patch, the PowerPC TOD
vsyscalls are still broken, i.e. glibc may return imprecise/incorrect
results for the related calls -- despite arch/powerpc/kernel/time.c
has
* Sergei Shtylyov [EMAIL PROTECTED] wrote:
could you resend them to me please?
Seeing that GENERIC_TIME has been thrown out from the -rt patch,
[...]
hm, i did that accidentally during a rebase. That was certainly not
meant to be a persistent condition.
Ingo
-
To unsubscribe
* Ingo Molnar [EMAIL PROTECTED] wrote:
* Sergei Shtylyov [EMAIL PROTECTED] wrote:
could you resend them to me please?
Seeing that GENERIC_TIME has been thrown out from the -rt patch,
[...]
hm, i did that accidentally during a rebase. That was certainly not
meant to be a
Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
* Sergei Shtylyov [EMAIL PROTECTED] wrote:
could you resend them to me please?
Seeing that GENERIC_TIME has been thrown out from the -rt patch,
[...]
hm, i did that accidentally during a rebase. That was certainly not
meant
* Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
> >as usual, bugreports, fixes and suggestions are welcome,
>
>Be aware that even with the newest -rt patch, the PowerPC TOD
> vsyscalls are still broken, i.e. glibc may return imprecise/incorrect
> results for the related calls -- despite
Hello everybody.
Ingo Molnar wrote:
i have released the 2.6.19-rt6 tree, which can be downloaded from the
usual place:
http://redhat.com/~mingo/realtime-preempt/
[...]
as usual, bugreports, fixes and suggestions are welcome,
Be aware that even with the newest -rt patch, the
Hello everybody.
Ingo Molnar wrote:
i have released the 2.6.19-rt6 tree, which can be downloaded from the
usual place:
http://redhat.com/~mingo/realtime-preempt/
[...]
as usual, bugreports, fixes and suggestions are welcome,
Be aware that even with the newest -rt patch, the
* Sergei Shtylyov [EMAIL PROTECTED] wrote:
as usual, bugreports, fixes and suggestions are welcome,
Be aware that even with the newest -rt patch, the PowerPC TOD
vsyscalls are still broken, i.e. glibc may return imprecise/incorrect
results for the related calls -- despite
* Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > i think it's the UP vs. SMP difference. We are chasing some SMP
> > latencies right now that trigger on boxes that have deeper C sleep
> > states. idle=poll seems to work around those problems.
>
> well C-states do cause latencies... as
On Thu, 2006-12-07 at 13:07 -0800, Fernando Lopez-Lezcano wrote:
> On Thu, 2006-12-07 at 21:58 +0100, Ingo Molnar wrote:
> > * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote:
> >
> > > Much better performance in terms of xruns with Jackd. Hardly any at
> > > all as it should be. I'm starting
On Thu, 2006-12-07 at 21:58 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote:
>
> > Much better performance in terms of xruns with Jackd. Hardly any at
> > all as it should be. I'm starting to test -rt8 right now.
> >
> > Now, I still don't have an smp machine to
On Thu, 2006-12-07 at 21:58 +0100, Ingo Molnar wrote:
> * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote:
>
> > Much better performance in terms of xruns with Jackd. Hardly any at
> > all as it should be. I'm starting to test -rt8 right now.
> >
> > Now, I still don't have an smp machine to
* Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote:
> Much better performance in terms of xruns with Jackd. Hardly any at
> all as it should be. I'm starting to test -rt8 right now.
>
> Now, I still don't have an smp machine to test so the improvement
> could be because I'm just running 64
On Tue, 2006-12-05 at 18:11 +0100, Ingo Molnar wrote:
> i have released the 2.6.19-rt6 tree, which can be downloaded from the
> usual place:
>
> http://redhat.com/~mingo/realtime-preempt/
>
> more info about the -rt patchset can be found on the RT wiki:
>
> http://rt.wiki.kernel.org
>
>
* K.R. Foley <[EMAIL PROTECTED]> wrote:
> > ah, indeed. I went for a slightly different approach - see the patch
> > below. Sending an NMI to all CPUs is not something that is tied to
> > KEXEC, it belongs into nmi.c.
> >
> > Ingo
>
> Much better I think. It still requires the patch
Ingo Molnar wrote:
> * K.R. Foley <[EMAIL PROTECTED]> wrote:
>
>> Ingo Molnar wrote:
>>
>> The attached patch is necessary to build 2.6.19-rt8 without KEXEC
>> enabled. Without KEXEC enabled crash.c doesn't get included. I believe
>> this is correct.
>
> ah, indeed. I went for a slightly
* K.R. Foley <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
>
> The attached patch is necessary to build 2.6.19-rt8 without KEXEC
> enabled. Without KEXEC enabled crash.c doesn't get included. I believe
> this is correct.
ah, indeed. I went for a slightly different approach - see the patch
Ingo Molnar wrote:
The attached patch is necessary to build 2.6.19-rt8 without KEXEC
enabled. Without KEXEC enabled crash.c doesn't get included. I believe
this is correct.
--
kr
--- linux-2.6.19/arch/i386/kernel/nmi.c.orig 2006-12-07 09:35:22.0 -0600
+++
* K.R. Foley <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> > i have released the 2.6.19-rt6 tree, which can be downloaded from the
> > usual place:
>
> Attached patch fixes rtc histogram. Looks like it got broken around
> 2.6.18-rt?, probably during the merge for 2.6.18?
thanks, applied.
Ingo Molnar wrote:
> i have released the 2.6.19-rt6 tree, which can be downloaded from the
> usual place:
>
Attached patch fixes rtc histogram. Looks like it got broken around
2.6.18-rt?, probably during the merge for 2.6.18?
--
kr
--- linux-2.6.19/drivers/char/rtc.c.orig 2006-12-06
Ingo Molnar wrote:
i have released the 2.6.19-rt6 tree, which can be downloaded from the
usual place:
Attached patch fixes rtc histogram. Looks like it got broken around
2.6.18-rt?, probably during the merge for 2.6.18?
--
kr
--- linux-2.6.19/drivers/char/rtc.c.orig 2006-12-06
* K.R. Foley [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
i have released the 2.6.19-rt6 tree, which can be downloaded from the
usual place:
Attached patch fixes rtc histogram. Looks like it got broken around
2.6.18-rt?, probably during the merge for 2.6.18?
thanks, applied. I have
Ingo Molnar wrote:
The attached patch is necessary to build 2.6.19-rt8 without KEXEC
enabled. Without KEXEC enabled crash.c doesn't get included. I believe
this is correct.
--
kr
--- linux-2.6.19/arch/i386/kernel/nmi.c.orig 2006-12-07 09:35:22.0 -0600
+++
* K.R. Foley [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
The attached patch is necessary to build 2.6.19-rt8 without KEXEC
enabled. Without KEXEC enabled crash.c doesn't get included. I believe
this is correct.
ah, indeed. I went for a slightly different approach - see the patch
below.
* K.R. Foley [EMAIL PROTECTED] wrote:
ah, indeed. I went for a slightly different approach - see the patch
below. Sending an NMI to all CPUs is not something that is tied to
KEXEC, it belongs into nmi.c.
Ingo
Much better I think. It still requires the patch below, which
On Tue, 2006-12-05 at 18:11 +0100, Ingo Molnar wrote:
i have released the 2.6.19-rt6 tree, which can be downloaded from the
usual place:
http://redhat.com/~mingo/realtime-preempt/
more info about the -rt patchset can be found on the RT wiki:
http://rt.wiki.kernel.org
this is a
On Thu, 2006-12-07 at 21:58 +0100, Ingo Molnar wrote:
* Fernando Lopez-Lezcano [EMAIL PROTECTED] wrote:
Much better performance in terms of xruns with Jackd. Hardly any at
all as it should be. I'm starting to test -rt8 right now.
Now, I still don't have an smp machine to test so the
On Thu, 2006-12-07 at 13:07 -0800, Fernando Lopez-Lezcano wrote:
On Thu, 2006-12-07 at 21:58 +0100, Ingo Molnar wrote:
* Fernando Lopez-Lezcano [EMAIL PROTECTED] wrote:
Much better performance in terms of xruns with Jackd. Hardly any at
all as it should be. I'm starting to test -rt8
* Arjan van de Ven [EMAIL PROTECTED] wrote:
i think it's the UP vs. SMP difference. We are chasing some SMP
latencies right now that trigger on boxes that have deeper C sleep
states. idle=poll seems to work around those problems.
well C-states do cause latencies... as advertized in
35 matches
Mail list logo
