On Sat, 2007-07-14 at 12:49 +0200, Maarten Maathuis wrote:
> Were can -rt3 be found?
http://lkml.org/lkml/2007/7/13/159
> On 7/13/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-07-13 at 16:02 +0200, Maarten Maathuis wrote:
> > > I have determined that version 2.6.22.1-rt2 freeze a
Were can -rt3 be found?
On 7/13/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
On Fri, 2007-07-13 at 16:02 +0200, Maarten Maathuis wrote:
> I have determined that version 2.6.22.1-rt2 freeze after:
>
> NET: Register protocol family 2
>
> This is very early in the boot stage, and i cannot determin
Maarten Maathuis wrote:
I have determined that version 2.6.22.1-rt2 freeze after:
NET: Register protocol family 2
This is very early in the boot stage, and i cannot determine what
exactly causes it.
It happens if either high resolution timers or dynamic ticks are active.
There's a race in th
On Fri, 2007-07-13 at 16:02 +0200, Maarten Maathuis wrote:
> I have determined that version 2.6.22.1-rt2 freeze after:
>
> NET: Register protocol family 2
>
> This is very early in the boot stage, and i cannot determine what
> exactly causes it.
>
> It happens if either high resolution timers or
[EMAIL PROTECTED]:~$ uname -r
2.6.19.1-rt15_00
And I'm totally thrilled since this is the first -rt kernel that I've
tried and been able to boot since .16-rt29. Yay!
[EMAIL PROTECTED]:~$ zcat /proc/config.gz | egrep "HZ.*=y"
CONFIG_HZ_1000=y
100 revs; min: 5008 max: 5034 avg: 5015
100 revs; mi
On Fri, 15 Dec 2006, Ingo Molnar wrote:
>
> so these results look pretty normal to me.
Ingo, Did you run this with high res turned off? That will simulate his
scenerio more so.
> Modified code attached below.
> (Change the '#if 1' to '#if 0' to get the select() measurement.)
Your code is almo
* tike64 <[EMAIL PROTECTED]> wrote:
> I made my test code visible if you want to take a look: www dot
> riihineva dot no-ip dot org uphill public uphill test-rt.c
on x86, with nanosleep i get:
# ./test-rt
100 revs; min: 5026 max: 5099 avg: 5062
100 revs; min: 5031 max: 5105 avg: 5065
100 re
Steven Rostedt <[EMAIL PROTECTED]> wrote:
> So you got a big jitter using nanosleep??? If that's the case, could
> you post the times you got. I'll also boot a kernel with the latest
> -rt patch, without highres compiled, and see if I can reproduce the
> same on x86.
You're very kind! Here you go
On Thu, 14 Dec 2006, tike64 wrote:
> Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > ...
> > it's ok for the timer to be a little over, but it must never be a
> > little under.
> > ...
> > So we make sure the timer goes off in (n+1) ms, and not just (n).
Oops, that should have read (n+1) 10ms, or
Steven Rostedt <[EMAIL PROTECTED]> wrote:
> ...
> it's ok for the timer to be a little over, but it must never be a
> little under.
> ...
> So we make sure the timer goes off in (n+1) ms, and not just (n).
Ok, this makes sense - thanks.
What confuses / confused me is that I have 4 combinations:
w
On Thu, 14 Dec 2006, tike64 wrote:
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > tike64 <[EMAIL PROTECTED]> wrote:
> > > Ok, understood; I tried this:
> > >
> > > t = raw_timer();
> > > ts.tv_nsec = 500;
> > > ts.tv_sec = 0;
> > > nanosleep(&ts, 0);
> > > t = raw_timer() - t;
> > >
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> tike64 <[EMAIL PROTECTED]> wrote:
> > Ok, understood; I tried this:
> >
> > t = raw_timer();
> > ts.tv_nsec = 500;
> > ts.tv_sec = 0;
> > nanosleep(&ts, 0);
> > t = raw_timer() - t;
> >
> > It is better but I still see 8ms occasiona
* tike64 <[EMAIL PROTECTED]> wrote:
> Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > Also, have you tried this with a nanosleep instead of a select.
> > Select's timeout is just that, a timeout. It's not suppose to be
> > accurate, as long as it doesn't expire early. The reason I state
> > this,
Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Also, have you tried this with a nanosleep instead of a select.
> Select's timeout is just that, a timeout. It's not suppose to be
> accurate, as long as it doesn't expire early. The reason I state
> this, is that select uses a different mechanism than n
For -rt issues, please CC Ingo Molnar, and for High Res issues, please
CC Thomas Gleixner.
On Fri, 2006-12-01 at 01:07 -0800, tike64 wrote:
> > Hi,
> >
> > Without the support of High Resolution Timer
> > supported, the timer resolution wouldn't change.
>
> Ok, I understand that. I was not expe
> Hi,
>
> Without the support of High Resolution Timer
> supported, the timer resolution wouldn't change.
Ok, I understand that. I was not expecting more
resolution. I expected only that I would get more
precise 10ms delays. What confuses me is that the
delays roughly doubled.
> With high-resolu
Hi,
Without the support of High Resolution Timer supported,
the timer resolution wouldn't change.
With high-resolution-timer supported,
our arm926-based board could get resolution like 40~50us.
There are codes you can reference ,may be you should just try to implement it.
JFI, Thanks.
From: tike
Daniel Walker wrote:
You can resolve it if you enable SMP .
Daniel
thanx - that's done it.
shayne
On Mon, 2005-08-01 at 08:18 +1000, Shayne O'Connor wrote:
trying to compile 2.6.13.rc4 with ingo's RT patch
(realtime-preempt-2.6.13-rc4-RT-V0.7.52-07) but keep getting this error
n
Vladimir V. Saveliev wrote:
ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.12/reiser4-for-2.6.12-realtime-preempt-2.6.12-final-V0.7.51-29.patch.gz
It applies to 2.6.12 +
http://people.redhat.com/mingo/realtime-preempt/older/realtime-preempt-2.6.12-final-V0.7.51-29
Ah, this is just what I wa
Hello
Steven Rostedt wrote:
On Tue, 2005-07-12 at 19:37 -0400, Keenan Pepper wrote:
I naively changed these two calls from
init_MUTEX_LOCKED(&name);
to
init_MUTEX(&name);
down(&name);
but I'm not sure if that's right. I guess I'll see when I try to boot it!
No, since it probably wont b
On Tue, 2005-07-12 at 19:37 -0400, Keenan Pepper wrote:
>
> I naively changed these two calls from
>
> init_MUTEX_LOCKED(&name);
>
> to
>
> init_MUTEX(&name);
> down(&name);
>
> but I'm not sure if that's right. I guess I'll see when I try to boot it!
No, since it probably wont be "uped" by
On Tue, 2005-07-12 at 19:37 -0400, Keenan Pepper wrote:
> but I'm not sure if that's right. I guess I'll see when I try to boot it!
>
The standard fix is to make it a compat_semaphore. See the list
archives for details.
Lee
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
Lee Revell wrote:
Maybe you could apply the broken out reiser4 patches from -mm and the
realtime preempt patches. Testing with PREEMPT_DESKTOP and latency
tracing enabled will tell you whether reiser4 has any latency hot spots.
I'm trying this now and it's not exactly trivial; the patches conf
Lee Revell wrote:
>On Tue, 2005-07-12 at 15:55 -0400, Keenan Pepper wrote:
>
>
>>Ingo Molnar's realtime-preempt patches used to be based on the -mm
>>kernels, but now they appear to be based on the mainline kernels, so
>>they don't support reiser4 (at least until reiser4 is merged into
>>main
On Tue, 2005-07-12 at 15:55 -0400, Keenan Pepper wrote:
> Ingo Molnar's realtime-preempt patches used to be based on the -mm
> kernels, but now they appear to be based on the mainline kernels, so
> they don't support reiser4 (at least until reiser4 is merged into
> mainline, which is looking unc
> I've tried whether having nmi_watchdog has any influence, to no
> distinguishable result; readprofile always says zero times. And
> I'm sure I have LOCAL_APIC=y (see attached config.gz)
Damn, forgot the attachement. Here it goes.
Sorry.
--
rncbc aka Rui Nuno Capela
[EMAIL PROTECTED]
config-2.6
> * Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
>
>> After several trials, with CONFIG_PROFILING=y and profile=1
>> nmi_watchdog=2 as boot parameters, I'm almost convinced I'm doing
>> something wrong :)
>>
>> - `readprofile` always just outputs one line:
>>
>> 0 total
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
> After several trials, with CONFIG_PROFILING=y and profile=1
> nmi_watchdog=2 as boot parameters, I'm almost convinced I'm doing
> something wrong :)
>
> - `readprofile` always just outputs one line:
>
> 0 total
> * Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
>
>> OTOH, I'll take this chance to show you something that is annoying me
>> for quite some time. Just look to the attached chart where I've marked
>> the spot with an arrow and a question mark. Its just one example of a
>> strange behavior/phenomenon
> * Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
>
>> OTOH, I'll take this chance to show you something that is annoying me
>> for quite some time. Just look to the attached chart where I've marked
>> the spot with an arrow and a question mark. Its just one example of a
>> strange behavior/phenomenon
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
> OTOH, I'll take this chance to show you something that is annoying me
> for quite some time. Just look to the attached chart where I've marked
> the spot with an arrow and a question mark. Its just one example of a
> strange behavior/phenomenon wh
>> -- - -
>> RT-V0.7.51-13 RT-V0.7.49-01
>> -- - -
>
>> Delay Maximum . . . . . . . . : 333 295 usecs
>> Cycle Maximum . . . . . . . .
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
> OK.
>
> Just for the heads up, here goes todays summary results regarding my
> jack_test4.2 test suite against 2.6.12 kernels configured with
> PREEMPT_RT, but... now with 99.9% certainty :)
thanks for the testing!
> --
> * Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
>
>> Hi all,
>>
>> These are one of my latest consolidated results while using (my)
>> jack_test4.2 suite, against a couple of 2.6.12 kernels patched for
>> PREEMPT_RT, on my [EMAIL PROTECTED]/UP laptop.
>>
>> See anything funny?
>
> hm, you dont seem
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i have just done a jack_test4.1 run, and indeed larger latencies seem
> to have crept in. (But i forgot to chrt the sound IRQ above the
> network IRQ, so i'll retest.)
with the sound irq chrt-ed to prio 90 the latencies look pretty good:
***
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> These are one of my latest consolidated results while using (my)
> jack_test4.2 suite, against a couple of 2.6.12 kernels patched for
> PREEMPT_RT, on my [EMAIL PROTECTED]/UP laptop.
>
> See anything funny?
hm, you dont seem to have
On Tue, 2005-07-05 at 18:13 -0700, William Weston wrote:
> Audio without xruns is an RT requirement, IMHO ;-}
>
This isn't even an opinion, it's a fact. If you are capturing data and
your audio handling thread does not get scheduled in (periods_per_buffer
- 1) * period_time time units, you lose
On Wed, 6 Jul 2005, Carlo Scarfoglio wrote:
> Compilation stops at this point:
>
> make[1]: `arch/i386/kernel/asm-offsets.s' is up to date.
>CHK include/linux/compile.h
>CHK usr/initramfs_list
>CC net/ipv4/netfilter/ip_conntrack_proto_tcp.o
> net/ipv4/netfilter/ip_conntra
* Sven Dietrich <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> this patch turns off the preemptable BKL when
> either PREEMPT_VOLUNTARY or PREEMPT_NONE is selected.
thanks, added it to my tree.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
39 matches
Mail list logo
