* Ingo Molnar [EMAIL PROTECTED] wrote:
* cinetic bellini [EMAIL PROTECTED] wrote:
LD .tmp_vmlinux1
arch/i386/kernel/built-in.o: In function `do_IRQ':
: undefined reference to `irq_show_regs_callback'
make: *** [.tmp_vmlinux1] Error 1
I am not sure if I have to enable
* Robert Schwebel [EMAIL PROTECTED] wrote:
Thomas,
this is our current series to make -rt work on ARM, currently based on
2.6.19-rt15. The clockevent patches are already merged in 2.6.20-rc1
via Russell, so they are provided here only for completeness. I'm
going to update the latency
* Rui Nuno Capela [EMAIL PROTECTED] wrote:
First one is about building for UP (CONFIG_SMP not set) on my old P4
laptop. As it seems, all my build attempts failed at the final link
stage, with undefined references to paravirt_enable. After disabling
CONFIG_PARAVIRT I get a similar failure,
* K.R. Foley [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
i have released the v2.6.20-rt1 kernel, which can be downloaded from the
usual place:
I have a couple of questions regarding priorities of the softirqs, IRQ
handlers, etc.
With some exceptions, back in 2.6.18 and prior
* Luca Abeni [EMAIL PROTECTED] wrote:
Hi all,
Looking at patch-2.6.21-rc3-rt0, it seems to me that it contains a lot
of unrelated stuff, such as:
that's Linus' post -rc3 -git tree.
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-rt-users in
the body of a
* Guennadi Liakhovetski [EMAIL PROTECTED] wrote:
could you send the patch for that? Is it upstream already?
It's indeed an IrDA bug (though mainly visible under rt-preempt) and
the patch has been sent to the maintainer and to stable.
could you please bounce it to me too? I usually put
* Sébastien Dugué [EMAIL PROTECTED] wrote:
I see that the calls to profile_tick() have been commented out in
the different timer handlers. Why is this so?
The only remaining place calling profile_tick() (well, in fact
__profile_tick()) is the NMI watchdog ticker, but I don't enable
* Rui Nuno Capela [EMAIL PROTECTED] wrote:
Hi,
Just tried to build 2.6.21-rc5-rt6 and it is failing on build time.
Just to let you know that -rt5 was doing fine with very same .config .
oops - indeed! I've uploaded -rc5-rt7 with the fix. (it includes a few
other fixes as well)
note that
* Dave Sperry [EMAIL PROTECTED] wrote:
I checked the clock source and in both the vanilla and rt cases and
they were both acpi_pm
ok, thanks for double-checking that.
Here's the oprofile for my vanilla case:
i tried your workload and i think i managed to optimize it some more: i
have
* David Sperry [EMAIL PROTECTED] wrote:
there are a few other things i'm working on to improve this. I've
uploaded -rt9 which is the current state of affairs. Note that using
-rt9 you'll likely only see IRQ-8406 overhead in the system, because
i've added an optimization to do process
* Guennadi Liakhovetski [EMAIL PROTECTED] wrote:
Remove repeated #define
Signed-off-by: G. Liakhovetski [EMAIL PROTECTED]
thanks, applied.
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-rt-users in
the body of a message to [EMAIL PROTECTED]
More majordomo
i have released the v2.6.20-rt1 kernel, which can be downloaded from the
usual place:
http://redhat.com/~mingo/realtime-preempt/
more info about the -rt patchset can be found in the RT wiki:
http://rt.wiki.kernel.org
This is a fixes-only release.
to build a 2.6.21-rt1 tree, the
i'm pleased to announce the v2.6.20-rt2 kernel, which can be downloaded
from the usual place:
http://redhat.com/~mingo/realtime-preempt/
more info about the -rt patchset can be found in the RT wiki:
http://rt.wiki.kernel.org
This is a fixes-mostly release and has been assembled by
* Daniel Walker [EMAIL PROTECTED] wrote:
On Wed, 2007-05-16 at 20:04 +0200, Ingo Molnar wrote:
i'm pleased to announce the v2.6.20-rt2 kernel, which can be downloaded
from the usual place:
2.6.21-rt2 ?
oops, right! :-)
- fixes for various problems by Steven Rostedt and Clark
* Daniel Walker [EMAIL PROTECTED] wrote:
http://lkml.org/lkml/2007/5/3/368
hm - trace_hardirqs_on() should never be called with irqs on -
lockdep could break for example. Could you try to fix the call site
instead?
If that's the case why check if they're enabled inside
* Daniel Walker [EMAIL PROTECTED] wrote:
I don't know. irqs_off_preempt_count() could get used someplace else,
where you would want to flip the preempt_count() check .. It seems
sane to combine your patch with mine ..
irqs_off_preempt_count() (!__get_cpu_var(trace_cpu_idle)
i'm pleased to announce the v2.6.21-rt3 kernel, which can be downloaded
from the usual place:
http://redhat.com/~mingo/realtime-preempt/
more info about the -rt patchset can be found in the RT wiki:
http://rt.wiki.kernel.org
This is a fixes-only release assembled by Thomas Gleixner.
* Daniel Walker [EMAIL PROTECTED] wrote:
I copied the patch into the first email, I did look at it which is why
you got an email. Your introducing the patch , it's for you to explain
why it needs to be there.. considering that the comment says hack in
it, I have to wonder what the
* Paul E. McKenney [EMAIL PROTECTED] wrote:
2.6.21.4-rt12 boots on 4-CPU Opteron and passes several hours of
rcutorture. However, if I simply do modprobe rcutorture, the kernel
threads do not spread across the CPUs as I would expect them to, even
given CFS. Instead, the readers all
* Paul E. McKenney [EMAIL PROTECTED] wrote:
hm, what affinity do they start out with? Could they all be pinned
to CPU#0 by default?
They start off with affinity masks of 0xf on a 4-CPU system. I would
expect them to load-balance across the four CPUs, but they stay all on
the same
* Steven Rostedt [EMAIL PROTECTED] wrote:
This bit me in the butt.
I couldn't understand why my init app was segfaulting, with a kernel
address, but a user RIP and RSP. Well, the RIP I think was bogus, but
the kernel address was always the start of mcount. Looking deeper,
I printed
* Chris Wright [EMAIL PROTECTED] wrote:
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
Chris, thanks a hell of a lot for looking into this!!!
-rt doesn't do much with paravirt, but since both -rt and lguest are two
things I love to play with, it was really bothering me that they were
* Chris Wright [EMAIL PROTECTED] wrote:
thanks! I ran into this before and asked for the fastcalls to not be
removed from upstream paravirt.c but to no avail it seems. It does
no harm to anyone to keep the 'fastcall' declarations and
definitions for places where _actual assembly code_
* Manfred Gruber [EMAIL PROTECTED] wrote:
hi !
I use a arm4vt ep93xx processor with 2.6.21.5-rt18.
When i run cyclictest with -i 1 and -n -p 90 -b 1000 i see some strange
latencies in poison_obj.
disable SLAB_DEBUG. And look into your 'dmesg' output, the -rt kernel
will warn about
* Gregory Haskins [EMAIL PROTECTED] wrote:
On Thu, 2007-07-12 at 14:07 +0200, Ingo Molnar wrote:
* Gregory Haskins [EMAIL PROTECTED] wrote:
Hi Ingo, Thomas, and the greater linux-rt community,
I just wanted to let you guys know that our team has a port of
the 21.5-rt20
* Remy Bohmer [EMAIL PROTECTED] wrote:
Hello Arjan,
Thanks for this suggestion.
(please dont top-post, ever. See:
www.zipworld.com.au/~akpm/linux/patches/stuff/top-posting.txt)
But I looked at Systemtap before, and as I remember, it is very
flexible, but it only traces function calls.
* Fernando Lopez-Lezcano [EMAIL PROTECTED] wrote:
On Tue, 2007-07-17 at 21:32 +0200, Ingo Molnar wrote:
* Fernando Lopez-Lezcano [EMAIL PROTECTED] wrote:
I do get flash 9 (I know, not the best example) and tomboy to hang as
reported by one of my Planet CCRMA users - flash 9 tested
* Fernando Lopez-Lezcano [EMAIL PROTECTED] wrote:
does lockdep pinpoint anything?
Lots of stuff, and at the end the lock report for the problem.
Hopefully some of this will help... I have attached the whole bootup
sequence as logged in /var/log/messages.
yeah, it pinpointed the bug. It
* Rui Nuno Capela [EMAIL PROTECTED] wrote:
Maybe I was too quick, but `make all` on is failing here:
does -rt6 work better?
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-rt-users in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
i've released the v2.6.23-rc1-rt0 kernel, which can be downloaded from
the usual place:
http://redhat.com/~mingo/realtime-preempt/
as the rt0 name suggests it, this is a devel release, the first one
after a rebase to 2.6.23-rc1. There's lots of changes and a reduction of
50 patches (we
* Gene Heskett [EMAIL PROTECTED] wrote:
The above stanza still needs some tlc. I built a 2.6.22.1-rt6 (rt5
wouldn't build) using the same old config that a make oldconfig didn't
fuss about, but the reboot never completed, see the attached, heavily
smunched camera shot of the panic.
* Fernando Lopez-Lezcano [EMAIL PROTECTED] wrote:
apparently you caught that 3 seconds window where the .23-rc1-rt1
release script moved old patches into the older/ directory :-)
Yup, good timing... :-) Hard to do again...
(BTW, will you keep 2.6.22.x patches going for a while?)
yeah,
* Sébastien Dugué [EMAIL PROTECTED] wrote:
Hi Ingo, Thomas,
this one-liner fixes a bug in balance_rt_tasks() which sometimes
manifests by having a lower prio task being scheduled while a higher
prio task is sitting waiting on another runqueue.
This is pretty hard to reproduce on
* Gene Heskett [EMAIL PROTECTED] wrote:
Changing the root (hd0,0) to (sd0,0) failed. Grub can't parse the
(sd0,0).
that (hd0,0) is a BIOS identification and needs no changing.
could you send me your grub.conf?
Ingo
-
To unsubscribe from this list: send the line unsubscribe
* Ankita Garg [EMAIL PROTECTED] wrote:
Hi,
This patch adds support to display captured -rt stats under
/proc/schedstat.
hm, could you add it to /proc/sched_debug instead? That's where all the
runqueue values are showing up normally. I'm also a bit wary about
introducing a new schedstats
* Ankita Garg [EMAIL PROTECTED] wrote:
This patch adds support to display captured -rt stats under
/proc/schedstat.
hm, could you add it to /proc/sched_debug instead? That's where all
the runqueue values are showing up normally. I'm also a bit wary
about introducing a new
* John Sigler [EMAIL PROTECTED] wrote:
With a pair of the following in the middle:
softirq--4 0 670us : call_rcu (rt_run_flush)
softirq--4 0D..1 670us : __rcu_advance_callbacks (call_rcu)
Any idea what went wrong in the above function trace? Why is the
kernel spinning in
* John Sigler [EMAIL PROTECTED] wrote:
does your test-app have higher priority than softirq--4 ?
PID 4 is [softirq-timer/0] and has priority 50 in SCHED_FIFO. My
process has priority 80 in SCHED_RR. It is waiting for IRQ10.
My user-space app has higher priority than everything except
* Dragan Noveski [EMAIL PROTECTED] wrote:
hi list, i am trying to compile the 2.6.22.1-rt7 here and i get this
error while running 'make make modules':
ok - i've released rt8 which should have this fixed.
Ingo
-
To unsubscribe from this list: send the line unsubscribe
* Ankita Garg [EMAIL PROTECTED] wrote:
I'd suggest to not put a probe into a preempt-off section - put it
to the beginning and to the end of schedule() to capture
context-switches. _stp_print_flush() is in the systemtap-generated
module, right? Maybe the problem is resolved by
* Daniel Walker [EMAIL PROTECTED] wrote:
I don't know about the slowness, but I think the BUG warnings are from
CONFIG_DEBUG_SHIRQ .
Try this patch,
Signed-off-by: Daniel Walker [EMAIL PROTECTED]
- local_irq_save(flags);
+
* Ankita Garg [EMAIL PROTECTED] wrote:
The probe point did get triggered, and soon after that I had the
following in dmesg, leading to system hang...
BUG: scheduling while atomic: softirq-rcu/3/0x0004/52, CPU#3
Call Trace:
#DB [81033555] __schedule_bug+0x4b/0x4f
...
the smp_mb() is rubbish too.
could you try the patch below, does it fix the problem?
Ingo
-
Subject: relay: fix timer madness
From: Ingo Molnar [EMAIL PROTECTED]
remove timer calls (!!!) from deep within the tracing infrastructure.
This was totally
* Gregory Haskins [EMAIL PROTECTED] wrote:
This code allows FUNCTION_CALL IPIs to become preemptible by executing
them in kthread context instead of interrupt context. They are
referred to as Virtual Function Call IPIs (VFCIPI) because we no
longer rely on the actual FCIPI facility.
[ mail re-sent with lkml Cc:-ed. _Please_ Cc: all patches to lkml too!
Unless you want -rt to suffer the fate of -ck, keep upstream involved
all the time. The recent /proc/interrupts-all discussion with upstream
folks showed the clear benefits of that approach. ]
* Gregory Haskins
* Ingo Molnar [EMAIL PROTECTED] wrote:
* Gregory Haskins [EMAIL PROTECTED] wrote:
This code allows FUNCTION_CALL IPIs to become preemptible by
executing them in kthread context instead of interrupt context.
They are referred to as Virtual Function Call IPIs (VFCIPI)
because we
* Gregory Haskins [EMAIL PROTECTED] wrote:
as far as the prioritization of function calls goes, _that_ makes
sense, but it should not be a separate API but should be done to our
normal workqueue APIs. That not only extends the effects of
priorities to all current workqueue using
* Steven Rostedt [EMAIL PROTECTED] wrote:
OK, I sent this out once before but it must have slipped under the
radar. http://lkml.org/lkml/2007/6/28/325
thanks - applied.
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-rt-users in
the body of a message to [EMAIL
* Steven Rostedt [EMAIL PROTECTED] wrote:
Ingo,
The below ifndef, shouldn't that be ifndef CONFIG_PREEMPT_SOFTIRQS ? I
hit that warning while I was running !PREEMPT_RT but with both hard
and softiqs as threads.
yeah, indeed - fixed.
P.S. I really found out that the system becomes VERY
* Steven Rostedt [EMAIL PROTECTED] wrote:
I don't have time to look further now, and it's something that isn't
easily reproducible (Well, it happened once out of two boots). If
you need me to look further, or need a config or dmesg (I have
both), then just give me a holler.
Silly
* Steven Rostedt [EMAIL PROTECTED] wrote:
The code on line 133 is:
WARN_ON_ONCE(current-rcu_read_lock_nesting NR_CPUS);
I have NR_CPUS set to 2 since the box I'm running this on only has 2
cpus and I see no reason to waste more data structures.
Is rcu read lock nesting deeper
* Peter Williams [EMAIL PROTECTED] wrote:
I've just been reviewing these patches and have spotted a possible
error in the file arch/ia64/kernel/time.c in that the scope of the
#ifdef on CONFIG_TIME_INTERPOLATION seems to have grown quite a lot
since 2.2.23-rc1-rt7. It used to chop out one
* Daniel Walker [EMAIL PROTECTED] wrote:
Replace the old PICK_OP style macros with PICK_FUNCTION. Although,
seqlocks has some alien code, which I also replaced as can be seen
from the line count below.
ok, i very much like the cleanup effects here, could you resend your
latest version of
* Josh Triplett [EMAIL PROTECTED] wrote:
sched_fair.c defines print_cfs_stats, and sched_debug.c uses it, but
sched.c includes both sched_fair.c and sched_debug.c, so all the
references to print_cfs_stats occur in the same compilation unit.
Thus, mark print_cfs_stats static.
* Clark Williams [EMAIL PROTECTED] wrote:
Attached is a minor patch against the broken out -rt4 which fixes a
couple of things that break an StGit import of the patch series.
thanks, applied this to the .23-rc2 queue.
Ingo
-
To unsubscribe from this list: send the line unsubscribe
* Oleg Nesterov [EMAIL PROTECTED] wrote:
On 08/01, Gregory Haskins wrote:
On Thu, 2007-08-02 at 02:22 +0400, Oleg Nesterov wrote:
No,
You sure are a confident one ;)
Yeah, this is a rare case when I am very sure I am right ;)
I strongly believe you guys take a _completely_
* Sven-Thorsten Dietrich [EMAIL PROTECTED] wrote:
Same issue has been fixed in mainline by:
diff-tree de0cf899bbf06b6f64a5dce9c59d74c41b6b4232 (from
5d2b3d3695a841231b65b55
Author: Oleg Nesterov [EMAIL PROTECTED]
Date: Sun Aug 12 18:08:19 2007 +0200
signed-off-by: Sven-Thorsten
* Steven Rostedt [EMAIL PROTECTED] wrote:
Changes since V1:
Updated to git tree 55b70a0300b873c0ec7ea6e33752af56f41250ce
Various clean ups suggested by Gregory Haskins, Dmitry Adamushko,
and Peter Zijlstra.
ok, i like this new approach - nice work! I'd suggest we test it in
* Nick Piggin [EMAIL PROTECTED] wrote:
[10138.175796] [c0105de3] show_trace+0x12/0x14
[10138.180291] [c0105dfb] dump_stack+0x16/0x18
[10138.184769] [c011609f] native_smp_call_function_mask+0x138/0x13d
[10138.191117] [c0117606] smp_call_function+0x1e/0x24
[10138.196210] [c012f85c]
* Steven Rostedt [EMAIL PROTECTED] wrote:
Ingo,
Do we still need to have the realtime-lsm.patch? It has been
considered obsolete for over a year now. Can we finally remove it.
yeah, we can drop it.
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-rt-users in
* 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
* 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
* 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 find
* Gregory Haskins [EMAIL PROTECTED] wrote:
Ingo,
This series applies on GIT commit
2254c2e0184c603f92fc9b81016ff4bb53da622d (2.6.24-rc4 (ish) git HEAD)
please post patches against sched-devel.git - it has part of your
previous patches included already, plus some cleanups i did to them,
* Steven Rostedt [EMAIL PROTECTED] wrote:
Ingo,
This patch prevents a panic on a failed bootmem alloc in the
initialization of the tracer buffers.
thanks, good catch!
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-rt-users in
the body of a message to [EMAIL
* Gautham R Shenoy [EMAIL PROTECTED] wrote:
Hello everyone,
This patchset is an updated version of the preemptible RCU patchset
that Paul McKenney had posted it in September earlier this year that
can be found here -- http://lkml.org/lkml/2007/9/10/213
This patchset incorporates the
* Steven Rostedt [EMAIL PROTECTED] wrote:
On Thu, 13 Dec 2007, Gautham R Shenoy wrote:
Currently it is based against the latest linux-2.6-sched-devel.git
Awaiting your feedback!
Hi Gautham,
Thanks for posting this. I believe this is the same version of preempt
RCU as we have
* Gautham R Shenoy [EMAIL PROTECTED] wrote:
Preempt-RCU: Update RCU Documentation.
From: Paul E. McKenney [EMAIL PROTECTED]
This patch updates the RCU documentation to reflect preemptible RCU as
well as recent publications.
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
Gautham,
* Gregory Haskins [EMAIL PROTECTED] wrote:
Hi Steven,
I posted a suspend-to-ram fix to sched-devel earlier today:
http://lkml.org/lkml/2007/12/17/445
This fix should also be applied to -rt as I introduced the same
regression there. Here is a version of the fix for 23-rt13. I can
* Frank Ch. Eigler [EMAIL PROTECTED] wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
[...] Firstly, why on earth does a full format string have to be
passed in for something as simple as a CPU id? This way we basically
codify it forever that tracing _has_ to be expensive when
enabled
* Frank Ch. Eigler [EMAIL PROTECTED] wrote:
[...] this is a general policy matter. It is _so much easier_ to add
markers if they _can_ have near-zero overhead (as in 1-2
instructions). Otherwise we'll keep arguing about it, especially if
any is added to performance-critical codepath.
* Frank Ch. Eigler [EMAIL PROTECTED] wrote:
Hi -
On Wed, Jan 02, 2008 at 06:01:57PM +0100, Ingo Molnar wrote:
[...]
well, -freorder-blocks seems to be default-enabled at -O2 on gcc 4.2, so
we should already be getting that, right?
Right.
[...] So it would be nice if we could
hm. Why is the ticket spinlock patch included in this patchset? It just
skews your performance results unnecessarily. Ticket spinlocks are
independent conceptually, they are already upstream in 2.6.25-rc2 and
-rt will have them automatically once we rebase to .25.
and if we take the ticket
73 matches
Mail list logo
