login
Search
After a 1.5 years sabbatical from preempt-rt we are pleased to announce a refactored preempt-rt patch against linux-2.6.29-rc4. The patch is working on x86 (32 and 64bit) but we have not yet updated ARM, PPC and MIPS (work in progress). We also dropped some experimental features of the base preempt-rt queue 2.6.26.8-rt15 simply because we wanted to survive the forward port over 3 kernel releases with the least amount of surprises. These features (e.g. multiple reader PI locks) are not essential for the preempt-rt functionality and need some serious overhaul anyway. The interested -rt observer might have noticed that we based our work on the 2.6.26.8-rt15 patch queue and did not pick the git-rt tree which is based on 2.6.28. The reason for this is that we wanted to pick the most stable patch queue and the git-rt tree has a lot of rewritten new code. Our work is not making the work which was done over the last months in the git-rt tree obsolete, quite the contrary: we want to provide a stable yet latest-kernel based foundation and integrate those changes gradually, as they become ready. The further plan for the new -rt series is to merge it fully into git and integrate it into the -tip git tree so it gets the same treatment as all of our -tip based work: fully automated compile and boot testing. Furthermore an automated multi architecture -rt performance regression test based on the same infrastructure is currently being built. The integration into the -tip tree also allows us to seperate out parts of -rt which are ready for mainline more easily and integrate them with our usual propagation to mainline. The structure of the patches is likely to change over the next days when we tackle the git integration, but we appreciate your feedback in the form of comments, bugreports and patches. Enough said. You can find the new patches at the following location: http://www.kernel.org/pub/linux/kernel/projects/rt/ Information on the RT patch can be found at: ...
Hi! I get some sleep while atomic warnings. I've put the log and my config in attachment.
Note, it's a wicked bug: I can't reproduce it anymore.
I would have been glad to give you an irqsoff trace but I can't :-)
Oh yes I have two other warnings, for the second one, I'm not sure
this is really only present in -rt.
The first one, a lockdep warning:
[ 2.975320] ---------------------------------
[ 2.975320] inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
[ 2.975320] swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[ 2.975320] (per_cpu__lock_slab_irq_locks_locked#2){+-..}, at: [<ffffffff802f6823>] kfree+0x43/0xc0
[ 2.975320] {hardirq-on-W} state was registered at:
[ 2.975320] [<ffffffff802822c5>] __lock_acquire+0x6f5/0x1b20
[ 2.975320] [<ffffffff8028378f>] lock_acquire+0x9f/0xe0
[ 2.975320] [<ffffffff8077c7f5>] rt_spin_lock+0x85/0xb0
[ 2.975320] [<ffffffff802f8251>] kmem_cache_alloc+0x51/0x1f0
[ 2.975320] [<ffffffff80253eab>] copy_process+0x9b/0x1500
[ 2.975320] [<ffffffff802553a0>] do_fork+0x90/0x4a0
[ 2.975320] [<ffffffff80213552>] kernel_thread+0x82/0xe0
[ 2.975320] [<ffffffff802135ba>] child_rip+0xa/0x20
[ 2.975320] [<ffffffffffffffff>] 0xffffffffffffffff
[ 2.975320] irq event stamp: 18114
[ 2.975320] hardirqs last enabled at (18113): [<ffffffff8021a935>] default_idle+0x55/0x60
[ 2.975320] hardirqs last disabled at (18114): [<ffffffff8021222a>] save_args+0x6a/0x70
[ 2.975320] softirqs last enabled at (0): [<ffffffff8025449d>] copy_process+0x68d/0x1500
[ 2.975320] softirqs last disabled at (0): [<(null)>] (null)
[ 2.975320]
[ 2.975320] other info that might help us debug this:
[ 2.975320] no locks held by swapper/0.
[ 2.975320]
[ 2.975320] stack backtrace:
[ 2.975320] Pid: 0, comm: swapper Not tainted 2.6.29-rc4-rt1-tip #1
[ 2.975320] Call Trace:
[ 2.975320] <IRQ> [<ffffffff8027fcbc>] print_usage_bug+0x19c/0x200
[ 2.975320] [<ffffffff8021e6af>] ? save_stack_trace+0x2f/0x50
[ 2.975320] [<ffffffff80280315>] mark_lock+0x2a5/0xcd0
[ 2.975320] ...hm, that's a complex one - we do kfree() from IPI context, dunno why this that should be harmless - unless you only get it under -rt1. Ingo --
The patch below might do the trick - it offloads this to a softirq.
Not tested yet.
Ingo
------------------>
Subject: rt: fix ipi kfree(), introduce IPI_SOFTIRQ
From: Ingo Molnar <mingo@elte.hu>
Date: Thu Feb 12 09:06:11 CET 2009
in 2.6.28 generic_smp_call_function_interrupt() grew a kfree(),
which is a rather complex, sleepable method under -rt. But the
IPI code runs as a hardirq - which cannot run such code.
So defer this work to a softirq context instead. It still stays
on the same CPU so the percpu IPI assumptions are upheld.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
include/linux/interrupt.h | 1 +
include/linux/smp.h | 3 +++
init/main.c | 1 +
kernel/smp.c | 15 +++++++++++++--
4 files changed, 18 insertions(+), 2 deletions(-)
Index: tip/include/linux/interrupt.h
===================================================================
--- tip.orig/include/linux/interrupt.h
+++ tip/include/linux/interrupt.h
@@ -257,6 +257,7 @@ enum
SCHED_SOFTIRQ,
HRTIMER_SOFTIRQ,
RCU_SOFTIRQ, /* Preferable RCU should always be the last softirq */
+ IPI_SOFTIRQ,
/* Entries after this are ignored in split softirq mode */
MAX_SOFTIRQ,
Index: tip/include/linux/smp.h
===================================================================
--- tip.orig/include/linux/smp.h
+++ tip/include/linux/smp.h
@@ -104,6 +104,9 @@ void ipi_call_lock(void);
void ipi_call_unlock(void);
void ipi_call_lock_irq(void);
void ipi_call_unlock_irq(void);
+void ipi_init(void);
+#else
+static inline void ipi_init(void) { }
#endif
/*
Index: tip/init/main.c
===================================================================
--- tip.orig/init/main.c
+++ tip/init/main.c
@@ -606,6 +606,7 @@ asmlinkage void __init start_kernel(void
/* init some links before init_ISA_irqs() */
early_irq_init();
init_IRQ();
+ ipi_init();
pidhash_init();
init_timers();
hrtimers_init();
Index: ...On a second thought ... I think we could eliminate the kfree() instead, and keep the atomicity of IPI cross-calls. Linus expressed doubts about the IPI kmalloc()/kfree() pair we do in the generic SMP IPI code, suggesting that it probably does not help performance all that much - so such a change might be upstream-able as well and would keep -rt closer to mainline. Ingo --
ok, it's lightly tested now: it built and booted up fine to X with your config. Ingo --
The simple fix is something like:
---
kernel/smp.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/kernel/smp.c b/kernel/smp.c
index bbedbb7..9b974c1 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -252,7 +252,11 @@ int smp_call_function_single(int cpu, void (*func) (void *info), void *info,
* will make sure the callee is done with the
* data before a new caller will use it.
*/
+#ifndef CONFIG_PREEMPT_RT
data = kmalloc(sizeof(*data), GFP_ATOMIC);
+#else
+ data = NULL;
+#endif
if (data)
data->flags = CSD_FLAG_ALLOC;
else {
@@ -347,7 +351,11 @@ void smp_call_function_many(const struct cpumask *mask,
return;
}
+#ifndef CONFIG_PREEMPT_RT
data = kmalloc(sizeof(*data) + cpumask_size(), GFP_ATOMIC);
+#else
+ data = NULL;
+#endif
if (unlikely(!data)) {
/* Slow path. */
for_each_online_cpu(cpu) {
--
ok, i made it unconditional (not just a PREEMPT_RT hac) and did the
cleanup below on top of it.
I dont think repeat, queued IPIs are all that interesting from a
performance point of view. If they are, it will all be clearly
bisectable.
Ingo
--------------->
Subject: generic-ipi: remove kmalloc, cleanup
From: Ingo Molnar <mingo@elte.hu>
Now that we dont use the kmalloc() sequence anymore, remove
CSD_FLAG_ALLOC and all its dependencies.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
kernel/smp.c | 86 +++++++++++------------------------------------------------
1 file changed, 17 insertions(+), 69 deletions(-)
Index: tip/kernel/smp.c
===================================================================
--- tip.orig/kernel/smp.c
+++ tip/kernel/smp.c
@@ -17,8 +17,7 @@ __cacheline_aligned_in_smp DEFINE_RAW_SP
enum {
CSD_FLAG_WAIT = 0x01,
- CSD_FLAG_ALLOC = 0x02,
- CSD_FLAG_LOCK = 0x04,
+ CSD_FLAG_LOCK = 0x02,
};
struct call_function_data {
@@ -85,15 +84,6 @@ static void generic_exec_single(int cpu,
csd_flag_wait(data);
}
-static void rcu_free_call_data(struct rcu_head *head)
-{
- struct call_function_data *data;
-
- data = container_of(head, struct call_function_data, rcu_head);
-
- kfree(data);
-}
-
/*
* Invoked by arch to handle an IPI for call function. Must be called with
* interrupts disabled.
@@ -138,8 +128,6 @@ void generic_smp_call_function_interrupt
smp_wmb();
data->csd.flags &= ~CSD_FLAG_WAIT;
}
- if (data->csd.flags & CSD_FLAG_ALLOC)
- call_rcu(&data->rcu_head, rcu_free_call_data);
}
rcu_read_unlock();
@@ -190,8 +178,7 @@ void generic_smp_call_function_single_in
} else if (data_flags & CSD_FLAG_LOCK) {
smp_wmb();
data->flags &= ~CSD_FLAG_LOCK;
- } else if (data_flags & CSD_FLAG_ALLOC)
- kfree(data);
+ }
}
/*
* See comment on outer loop
@@ -236,13 +223,11 @@ int smp_call_function_single(int cpu, vo
/*
* We are calling a function on a single ...Right, except I really don't like the smp_call_function_many() slow path that's now the only path. Rusty did that I think, but he also had some idea on how to fix it, I think it boiled down to sticking a count in the call data instead of the full cpumask. So I'd rather we first fix that code, and then remove the kmalloc --
Right, I can't see a way around carrying that cpumask, there's just too
much that can go wrong without it.
So it put in unconditionally, how about this?
--
Subject: generic-smp: remove single ipi fallback for smp_call_function_many()
In preparation of removing the kmalloc() calls from the generic-ipi code
get rid of the single ipi fallback for smp_call_function_many().
Because we cannot get around carrying the cpumask in the data -- imagine
2 such calls with different but overlapping masks -- put in a full mask.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
kernel/smp.c | 47 ++++++++++++++++++++++++-----------------------
1 files changed, 24 insertions(+), 23 deletions(-)
diff --git a/kernel/smp.c b/kernel/smp.c
index bbedbb7..e6658e5 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -26,7 +26,7 @@ struct call_function_data {
spinlock_t lock;
unsigned int refs;
struct rcu_head rcu_head;
- unsigned long cpumask_bits[];
+ struct cpumask cpumask;
};
struct call_single_queue {
@@ -111,13 +111,13 @@ void generic_smp_call_function_interrupt(void)
list_for_each_entry_rcu(data, &call_function_queue, csd.list) {
int refs;
- if (!cpumask_test_cpu(cpu, to_cpumask(data->cpumask_bits)))
+ if (!cpumask_test_cpu(cpu, &data->cpumask))
continue;
data->csd.func(data->csd.info);
spin_lock(&data->lock);
- cpumask_clear_cpu(cpu, to_cpumask(data->cpumask_bits));
+ cpumask_clear_cpu(cpu, &data->cpumask);
WARN_ON(data->refs == 0);
data->refs--;
refs = data->refs;
@@ -137,8 +137,10 @@ void generic_smp_call_function_interrupt(void)
*/
smp_wmb();
data->csd.flags &= ~CSD_FLAG_WAIT;
- }
- if (data->csd.flags & CSD_FLAG_ALLOC)
+ } else if (data->csd.flags & CSD_FLAG_LOCK) {
+ smp_wmb();
+ data->csd.flags &= ~CSD_FLAG_LOCK;
+ } else if (data->csd.flags & CSD_FLAG_ALLOC)
call_rcu(&data->rcu_head, rcu_free_call_data);
}
rcu_read_unlock();
@@ -302,6 +304,8 @@ void ...Hmm, I think this bit ought to go in rcu_free_call_data(), otherwise we can have that same race again.. I'd better put a comment in on why we use RCU here. --
Wont the first CPU that runs the callback unlock this? And then we run the risk of two back to back callers on the same CPU, having the second caller possibly corrupt the first. --
No, there's a ref count in there that ensures the last one unlocks it. But that's still not enough, the global queue is RCU protected. Suppose you have 4 cpus, and use smp_function_call_mask() to 2 others, now its possible the 4th is also doing global ipis and is traversing the global queue. Therefore, if you remove the cfd when its done, it might be the 4th cpu is in it trying to iterate to the next entry --> BANG. The solution used is RCU freeing cfd's. This also means we have to RCU free the LOCK flag, sadly an RCU grace period is waaaay too long to spin wait on. Hence this whole solution is not quite feasible. There's various alternative solutions, but I'm not quite sure which makes most sense. The one I'm currently pondering is using the global queue only for all-but-self cfd's, this matches the all-but-self ipi APIC case. For smaller masks we could queue a csd per queue and send single ipis. --
OK, if you really want this, please just change it to: unsigned long cpumask_bits[BITS_TO_LONGS(CONFIG_NR_CPUS)]; The 'struct cpumask' will be undefined soon when CONFIG_CPUMASK_OFFSTACK=y, which will prevent assignment and declaration on stack. I'd be fascinated to see perf numbers once you kill the kmalloc. Because this patch will add num_possible_cpus * NR_CPUS/8 bytes to the kernel which is something we're trying to avoid unless necessary. Thanks, Rusty. --
You're free to make it a pointer and do node affine allocations from an init section of choice and add a hotplug handler. But I'm not quite sure how perf is affected by size overhead on ridiculous configs. --
No, I meant "can you actually measure the perf win of this patch?". If you did so, I missed it? But if this patch is worthwhile, the right way to do this is make it a cpumask_var_t, and do the alloc_cpumask_var_node() in that init routine. Thanks, Rusty. --
Over what, the always single-ipi case, or the kmalloc case? The thing is, we're removing that kmalloc because its somewhat of a wart Right, and installing a hotplug handler and ... *sigh* --
It'll work, but its not mergable upstream like this, it greatly pessimizes the smp_function_call() performance. --
The fix below addresses a lockdep warning i triggered with your config.
(You could hit this if you try to use s2ram or hibernation or explicit
CPU hotplug ops.)
Ingo
-------------->
Subject: sched: cpu hotplug fix
From: Ingo Molnar <mingo@elte.hu>
Date: Thu Feb 12 11:35:40 CET 2009
rq_attach_root() does a kfree() with the runqueue lock held.
That's not a very wise move, fix it.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
kernel/sched.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
Index: tip/kernel/sched.c
===================================================================
--- tip.orig/kernel/sched.c
+++ tip/kernel/sched.c
@@ -7619,20 +7619,26 @@ static void free_rootdomain(struct root_
static void rq_attach_root(struct rq *rq, struct root_domain *rd)
{
+ struct root_domain *old_rd = NULL;
unsigned long flags;
spin_lock_irqsave(&rq->lock, flags);
if (rq->rd) {
- struct root_domain *old_rd = rq->rd;
+ old_rd = rq->rd;
if (cpumask_test_cpu(rq->cpu, old_rd->online))
set_rq_offline(rq);
cpumask_clear_cpu(rq->cpu, old_rd->span);
- if (atomic_dec_and_test(&old_rd->refcount))
- free_rootdomain(old_rd);
+ /*
+ * If we dont want to free the old_rt yet then
+ * set old_rd to NULL to skip the freeing later
+ * in this function:
+ */
+ if (!atomic_dec_and_test(&old_rd->refcount))
+ old_rd = NULL;
}
atomic_inc(&rd->refcount);
@@ -7643,6 +7649,9 @@ static void rq_attach_root(struct rq *rq
set_rq_online(rq);
spin_unlock_irqrestore(&rq->lock, flags);
+
+ if (old_rd)
+ free_rootdomain(old_rd);
}
static int __init_refok init_rootdomain(struct root_domain *rd, bool bootmem)
--
i tried your config and after a few bootups the warning did trigger. It's the new resource counter code. The IRQ flags disabling it does seems a bit dubious to me. Peter, what do you think? Frederic, could you try the patch below? Ingo -----------> Subject: rt: res_counter fix From: Ingo Molnar <mingo@elte.hu> Date: Thu Feb 12 11:11:47 CET 2009 Frederic Weisbecker reported this warning: [ 45.228562] BUG: sleeping function called from invalid context at kernel/rtmutex.c:683 [ 45.228571] in_atomic(): 0, irqs_disabled(): 1, pid: 4290, name: ntpdate [ 45.228576] INFO: lockdep is turned off. [ 45.228580] irq event stamp: 0 [ 45.228583] hardirqs last enabled at (0): [<(null)>] (null) [ 45.228589] hardirqs last disabled at (0): [<ffffffff8025449d>] copy_process+0x68d/0x1500 [ 45.228602] softirqs last enabled at (0): [<ffffffff8025449d>] copy_process+0x68d/0x1500 [ 45.228609] softirqs last disabled at (0): [<(null)>] (null) [ 45.228617] Pid: 4290, comm: ntpdate Tainted: G W 2.6.29-rc4-rt1-tip #1 [ 45.228622] Call Trace: [ 45.228632] [<ffffffff8027dfb0>] ? print_irqtrace_events+0xd0/0xe0 [ 45.228639] [<ffffffff8024cd73>] __might_sleep+0x113/0x130 [ 45.228646] [<ffffffff8077c811>] rt_spin_lock+0xa1/0xb0 [ 45.228653] [<ffffffff80296a3d>] res_counter_charge+0x5d/0x130 [ 45.228660] [<ffffffff802fb67f>] __mem_cgroup_try_charge+0x7f/0x180 [ 45.228667] [<ffffffff802fc407>] mem_cgroup_charge_common+0x57/0x90 [ 45.228674] [<ffffffff80212096>] ? ftrace_call+0x5/0x2b [ 45.228680] [<ffffffff802fc49d>] mem_cgroup_newpage_charge+0x5d/0x60 [ 45.228688] [<ffffffff802d94ce>] __do_fault+0x29e/0x4c0 [ 45.228694] [<ffffffff8077c843>] ? rt_spin_unlock+0x23/0x80 [ 45.228700] [<ffffffff802db8b5>] handle_mm_fault+0x205/0x890 [ 45.228707] [<ffffffff80212096>] ? ftrace_call+0x5/0x2b [ 45.228714] [<ffffffff8023495e>] do_page_fault+0x11e/0x2a0 [ 45.228720] [<ffffffff8077e5a5>] page_fault+0x25/0x30 [ 45.228727] ...
Please try v2 below - it might even build ;-) Ingo -------------------> Subject: rt: res_counter fix From: Ingo Molnar <mingo@elte.hu> Date: Thu Feb 12 11:11:47 CET 2009 Frederic Weisbecker reported this warning: [ 45.228562] BUG: sleeping function called from invalid context at kernel/rtmutex.c:683 [ 45.228571] in_atomic(): 0, irqs_disabled(): 1, pid: 4290, name: ntpdate [ 45.228576] INFO: lockdep is turned off. [ 45.228580] irq event stamp: 0 [ 45.228583] hardirqs last enabled at (0): [<(null)>] (null) [ 45.228589] hardirqs last disabled at (0): [<ffffffff8025449d>] copy_process+0x68d/0x1500 [ 45.228602] softirqs last enabled at (0): [<ffffffff8025449d>] copy_process+0x68d/0x1500 [ 45.228609] softirqs last disabled at (0): [<(null)>] (null) [ 45.228617] Pid: 4290, comm: ntpdate Tainted: G W 2.6.29-rc4-rt1-tip #1 [ 45.228622] Call Trace: [ 45.228632] [<ffffffff8027dfb0>] ? print_irqtrace_events+0xd0/0xe0 [ 45.228639] [<ffffffff8024cd73>] __might_sleep+0x113/0x130 [ 45.228646] [<ffffffff8077c811>] rt_spin_lock+0xa1/0xb0 [ 45.228653] [<ffffffff80296a3d>] res_counter_charge+0x5d/0x130 [ 45.228660] [<ffffffff802fb67f>] __mem_cgroup_try_charge+0x7f/0x180 [ 45.228667] [<ffffffff802fc407>] mem_cgroup_charge_common+0x57/0x90 [ 45.228674] [<ffffffff80212096>] ? ftrace_call+0x5/0x2b [ 45.228680] [<ffffffff802fc49d>] mem_cgroup_newpage_charge+0x5d/0x60 [ 45.228688] [<ffffffff802d94ce>] __do_fault+0x29e/0x4c0 [ 45.228694] [<ffffffff8077c843>] ? rt_spin_unlock+0x23/0x80 [ 45.228700] [<ffffffff802db8b5>] handle_mm_fault+0x205/0x890 [ 45.228707] [<ffffffff80212096>] ? ftrace_call+0x5/0x2b [ 45.228714] [<ffffffff8023495e>] do_page_fault+0x11e/0x2a0 [ 45.228720] [<ffffffff8077e5a5>] page_fault+0x25/0x30 [ 45.228727] [<ffffffff8043e1ed>] ? __clear_user+0x3d/0x70 [ 45.228733] [<ffffffff8043e1d1>] ? __clear_user+0x21/0x70 The reason is the raw IRQ flag use of kernel/res_counter.c. The irq flags tricks ...
On Thu, 12 Feb 2009 11:21:13 +0100 I'm sorry for no knowledge about RT. Could you teach me what local_irq_save_nort() does ? Hmm, how about just replacaing _irq() with preempt_disable()/enable() ? xxx_nort() is better ? AFAIK, these will not be called from irq context. (Added Balbir to CC:) Regards, --
_nort() will just turn them into NOPs in essence. The question is, are these local IRQ flags manipulations really needed in this code, and if yes, why? Ingo --
On Thu, 12 Feb 2009 12:28:54 +0100 From my point of view, No. But original design of res_coutner used irqsave/restore(). The author may think of use this function from irq-context. But now, it seems it's better to remove them, Hmm. Thanks, -Kame --
We needed the local IRQ flags, since these counters are updated from page fault context and from reclaim context with lru_lock held with IRQ's disabled. I've been thinking about replacing the spin lock with seq lock, but have not gotten to it yet. -- Balbir --
Ah, in that case we can get away with _nort I think, as both those contexts are preemptable on -rt. --
On Thu, 12 Feb 2009 22:28:33 +0530 Hmm ? I can't understand. Why we have to disable IRQ here again ? And, - try_to_unmap() is called in shrink_page_list(), there, no zone->lru_lock. - page fault path doesn't hold zone->lru_lock. My concern is only shmem. But I think it doesn't call charge() within lock, actually. Thanks, -Kame --
On Fri, 13 Feb 2009 08:56:40 +0900
Clarification :)
res_counter_charge() is called from
- page fault
=> under down_read(mmap_sem), lock_page() may be held. IRQ=ENABLED)
- add_to_page_cache
=> under lock_page(), mapping->tree_lock is *not* held, IRQ=DISABLED
- shmem
=> info->lock is held, we use __GFP_NOWAIT here. IRQ=ENABLED
- shmem
=> info->lock is *not* held with GFP_KERNEL here, IRQ=ENABLED.
- migration
=> under lock_page() and mmap_sem, IRQ=ENABLED
res_counter_uncharge() is called from
- page_remove_rmap()//(Only when ANON)
=> anon_vma->lock and pte_lock(),lock_page() can be held. IRQ=ENABLED?
- remove_from_page_cache()
=> lock_page() and mapping->tree_lock is held, IRQ=DISABLED.
Summary:
"Charge" is considered as heavy operation and the call path is placed where the
thread can sleep, AMAP.
"Uncharge" is considered as light operation and call path is under some # of
spinlocks.
Bye,
-Kame
--
Ok, I tested it through 3 bootups and it did not triggered.
But it's absolutely not a guarantee, as I said, I tried to reproduce it
with several bootups yesterday and I couln't see it again.
But by reading the warning and your patch, yes it is supposed to solve it :)
The reason for which I wanted to send an irqsoff trace is that the above lines are false.
addr2line -e vmlinux ffffffff8025449d
/home/me/linux/rt/linux-2.6.29-rc4/kernel/fork.c:1107 (before your patch)
Which is this area in copy_process:
#ifdef CONFIG_NUMA
p->mempolicy = mpol_dup(p->mempolicy);
if (IS_ERR(p->mempolicy)) {
retval = PTR_ERR(p->mempolicy);
p->mempolicy = NULL;
goto bad_fork_cleanup_cgroup;
}
mpol_fix_fork_child_flag(p); // <-- 1107
#endif
Nothing here disables irq.
That's why I wanted to provide an irqsoff trace. But, heh I only had to read
res_counter_charge() :-)
--
copy_process() has: #endif p->hardirq_enable_ip = 0; p->hardirq_enable_event = 0; p->hardirq_disable_ip = _THIS_IP_; p->hardirq_disable_event = 0; p->softirqs_enabled = 1; p->softirq_enable_ip = _THIS_IP_; p->softirq_enable_event = 0; p->softirq_disable_ip = 0; p->softirq_disable_event = 0; p->hardirq_context = 0; p->softirq_context = 0; #endif the sequence count of 0 basically tells you it hasn't been set yet. --
maybe we should initialize it to -1 to make this more apparent? Ingo --
--
It is to reflect the actual state at copy_process(), although I think here's a little buglet: ifdef CONFIG_TRACE_IRQFLAGS p->irq_events = 0; #ifdef __ARCH_WANT_INTERRUPTS_ON_CTXSW p->hardirqs_enabled = 1; #else p->hardirqs_enabled = 0; #endif p->hardirq_enable_ip = 0; p->hardirq_enable_event = 0; p->hardirq_disable_ip = _THIS_IP_; p->hardirq_disable_event = 0; p->softirqs_enabled = 1; p->softirq_enable_ip = _THIS_IP_; p->softirq_enable_event = 0; p->softirq_disable_ip = 0; p->softirq_disable_event = 0; p->hardirq_context = 0; p->softirq_context = 0; #endif I think the hardirq_enable/disable_ip should also depend on __ARCH_WANT_INTERRUPTS_ON_CTXSW. --
I think the current state makes sense, it reflects the actual state of copy_process. --
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 11 Feb 2009 23:43:44 +0100 (CET) Hi Thomas, I got the following after booting on my T60: - ------------[ cut here ]------------ WARNING: at crypto/blkcipher.c:327 blkcipher_walk_first+0x72/0x1aa() Hardware name: Modules linked in: fuse i915 drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect autofs4 coretemp sunrpc nf_conntrack_netbios_ns xt_state ipt_REJECT iptable_filter ip_tables cpufreq_ondemand dm_multipath scsi_dh uinput btusb bluetooth sg snd_hda_codec_analog snd_hda_intel snd_hda_codec iwl3945 snd_hwdep e1000e lib80211 snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss video snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 i2c_core thinkpad_acpi rfkill output iTCO_wdt iTCO_vendor_support button joydev hwmon dm_snapshot dm_zero dm_mirror dm_region_hash dm_log uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode] Pid: 9, comm: sirq-tasklet/0 Not tainted 2.6.29-rc4-rt1-tip #50 Call Trace: [<ffffffff8023bd23>] warn_slowpath+0xaf/0xd6 [<ffffffff8035d176>] blkcipher_walk_first+0x72/0x1aa [<ffffffff802309cb>] ? enqueue_task_fair+0x25/0x68 [<ffffffff8035d2f6>] blkcipher_walk_virt+0x1a/0x1c [<ffffffff803620af>] crypto_ecb_crypt+0x2b/0x9a [<ffffffff80359d20>] ? setkey+0xc4/0xd8 [<ffffffff8036426a>] ? arc4_crypt+0x0/0x5e [<ffffffff8036214f>] crypto_ecb_decrypt+0x31/0x33 [<ffffffff8035c8fb>] ? setkey+0xba/0xcd [<ffffffff8022bf8f>] ? __wake_up_common+0x49/0x7f [<ffffffff80519beb>] ieee80211_wep_decrypt_data+0x5e/0x95 [<ffffffff80519d3a>] ieee80211_wep_decrypt+0x118/0x16f [<ffffffff80519ddc>] ieee80211_crypto_wep_decrypt+0x4b/0x93 [<ffffffff80524d8f>] ieee80211_invoke_rx_handlers+0x26b/0x1395 [<ffffffff8021ce0f>] ? native_smp_send_reschedule+0x59/0x5b [<ffffffff8022c699>] ? resched_task+0x60/0x62 [<ffffffff802367a9>] ? try_to_wake_up+0x352/0x364 [<ffffffff802367ca>] ? default_wake_function+0xf/0x11 [<ffffffff80526418>] ...
no, removing the warning would just hide the real bug.
Could you try the fix below please?
Ingo
--------------------------------->
Subject: irq threading: fix PF_HARDIRQ definition
From: Ingo Molnar <mingo@elte.hu>
Date: Thu Feb 12 09:29:14 CET 2009
Clark Williams reported the following warning:
WARNING: at crypto/blkcipher.c:327 blkcipher_walk_first+0x72/0x1aa()
[<ffffffff8035d176>] blkcipher_walk_first+0x72/0x1aa
[<ffffffff8035d2f6>] blkcipher_walk_virt+0x1a/0x1c
[<ffffffff803620af>] crypto_ecb_crypt+0x2b/0x9a
[<ffffffff8036214f>] crypto_ecb_decrypt+0x31/0x33
[<ffffffff80519beb>] ieee80211_wep_decrypt_data+0x5e/0x95
[<ffffffff80519d3a>] ieee80211_wep_decrypt+0x118/0x16f
[<ffffffff80519ddc>] ieee80211_crypto_wep_decrypt+0x4b/0x93
[<ffffffff80524d8f>] ieee80211_invoke_rx_handlers+0x26b/0x1395
[<ffffffff80526418>] __ieee80211_rx_handle_packet+0x55f/0x59c
[<ffffffff80526c82>] __ieee80211_rx+0x508/0x572
[<ffffffff80517451>] ieee80211_tasklet_handler+0x6d/0xff
[<ffffffff80241192>] __tasklet_action+0xa1/0x112
[<ffffffff80241277>] tasklet_action+0x39/0x3b
[<ffffffff80240eef>] ksoftirqd+0x162/0x278
Which comes from:
if (WARN_ON_ONCE(in_irq()))
return -EDEADLK;
This warning is surprising, as it clearly comes from a softirq
context.
The in_irq() definition looks like this on -rt:
#define in_irq() (hardirq_count() || (current->flags & PF_HARDIRQ))
hardirq_count() is correct, but looking at PF_HARDIRQ's definition in sched.h:
#define PF_EXITPIDONE 0x00000008 /* pi exit done on shut down */
#define PF_VCPU 0x00000010 /* I'm a virtual CPU */
#define PF_HARDIRQ 0x08000020 /* hardirq context */
#define PF_NOSCHED 0x00000020 /* Userspace does not expect scheduling */
#define PF_FORKNOEXEC 0x00000040 /* forked but didn't exec */
Reveals that due to a typo it not only overlaps the PF_NOSCHED bit, but
also has a spurious 0x08000000 component.
Move it to a free ...The reason is that when we forward ported the definition, i first moved it to the 0x08000000 slot - but that slot was already taken. (our PF_ task flag space is really crowded ...) Then i moved it to a free spot, 0x20. Or so i thought: a later -rt patch in the queue introduced PF_NOSCHED which overlapped it. But the bigger problem was the spurious 0x08000000 component, which overlaps with: #define PF_SOFTIRQ 0x08000000 /* softirq context */ Explaining why the warning triggered in ksoftirqd ;-) Anyway, my fix should solve this. Do you still see the lockup under X? (make sure you also have the IPI fix applied, see the patch in this same thread.) Ingo --
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 12 Feb 2009 09:42:22 +0100 That did it (the IPI patch and the redefinition). I'm up with: $ uname -a Linux torg 2.6.29-rc4-rt1-tip #51 SMP PREEMPT RT Thu Feb 12 09:40:06 CST 2009 x86_64 x86_64 x86_64 GNU/Linux Thanks, I'll do some latency testing on my test boxes next... Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmUU2gACgkQHyuj/+TTEp3c7wCgjnQuYgoLmGOmq26a2T198eh/ KdgAnjmX+cqwxYAtzaHeMH6/nO6MNuUH =NHh/ -----END PGP SIGNATURE-----
We are pleased to announce the first update to our new preempt-rt series. It fixes the reported bugs and some more. Download locations: http://rt.et.redhat.com/download/ http://www.kernel.org/pub/linux/kernel/projects/rt/ Information on the RT patch can be found at: http://rt.wiki.kernel.org/index.php/Main_Page to build the 2.6.29-rc4-rt2 tree, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29-rc4.tar.bz2 http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc4-rt2.bz2 The broken out patches are also available at the same download locations. Enjoy ! Thomas, Ingo --
Hi, It fixes the rt-concerned warning I had. Now, a new little lockdep info, tell me if you need my config, I changed it a bit: [ 0.012874] INFO: trying to register non-static key. [ 0.012940] the code is fine but needs lockdep annotation. [ 0.013008] turning off the locking correctness validator. [ 0.013847] Pid: 0, comm: swapper Not tainted 2.6.29-rc4-rt2-tip #2 [ 0.013917] Call Trace: [ 0.013981] [<ffffffff80285985>] __lock_acquire+0x1825/0x1b20 [ 0.014053] [<ffffffff802846fb>] ? __lock_acquire+0x59b/0x1b20 [ 0.014125] [<ffffffff80283326>] ? mark_held_locks+0x56/0xa0 [ 0.014197] [<ffffffff80285d1f>] lock_acquire+0x9f/0xe0 [ 0.014267] [<ffffffff80780ea8>] ? rt_spin_lock_slowlock+0x38/0x310 [ 0.014342] [<ffffffff80783211>] __spin_lock_irqsave+0x51/0x70 [ 0.014415] [<ffffffff80780ea8>] ? rt_spin_lock_slowlock+0x38/0x310 [ 0.014489] [<ffffffff80780ea8>] rt_spin_lock_slowlock+0x38/0x310 [ 0.014562] [<ffffffff802836dc>] ? debug_check_no_locks_freed+0x9c/0x160 [ 0.014636] [<ffffffff80781edc>] rt_spin_lock+0x4c/0xa0 [ 0.014706] [<ffffffff80276f51>] compat_down_timeout+0x21/0x60 [ 0.014780] [<ffffffff804910ca>] acpi_os_wait_semaphore+0x4e/0x5d [ 0.014853] [<ffffffff804aafa9>] acpi_ut_acquire_mutex+0x43/0x87 [ 0.014926] [<ffffffff804a06cd>] acpi_ns_root_initialize+0x28/0x2ab [ 0.014999] [<ffffffff80449d88>] ? __raw_spin_lock_init+0x38/0x70 [ 0.015073] [<ffffffff80acbd6a>] acpi_initialize_subsystem+0x69/0x91 [ 0.015147] [<ffffffff80acc24a>] acpi_early_init+0x50/0xf5 [ 0.015219] [<ffffffff80aa1ea5>] start_kernel+0x3d2/0x4ca [ 0.015290] [<ffffffff80aa12b9>] x86_64_start_reservations+0x99/0xb9 [ 0.015362] [<ffffffff80aa13d5>] x86_64_start_kernel+0xfc/0x10b [ 0.015436] [<ffffffff80aa1140>] ? early_idt_handler+0x0/0x71 Oh and I just tested the tracers. It seems to run fine for all of them except sysprof. It passes the self-test but doesn't produce any trace when I manually ...
About sysprof, it's an -rt problem, I don't see it on -tip. The sysprof hrtimer callback is never called. I'm digging to see what is happening. --
I didn't put my ftrace_printk at the right place. It doesn't come from hrtimer. The problem comes from get_irq_regs() which always returns NULL on the sysprof hrtimer calback, then the trace is immediately dropped by sysprof. That's weird, smp_apic_timer_interrupt() calls set_irq_regs() so it should find it. Now I'm preempted by my bed. --
Ah, that makes sense - under -rt the default hrtimer execution is to execute in a softirq context. Could you try the patch below please, does it fix sysprof? Ingo ------------------> Subject: rt: sysprof hrtimer fix From: Ingo Molnar <mingo@elte.hu> Date: Fri Feb 13 08:22:14 CET 2009 Frederic Weisbecker noticed that sysprof does not work under .29-rt2, and tracked it down to a NULL result that get_irq_regs() gives to the sysprof plugin. The reason for the NULL is that it executes in the HRTIMER_SOFTIRQ context, hence it does not interrupt any real context and thus there's no IRQ registers to take a look at. Since the sysprof functionality is atomic, the fix is to move the sysprof hrtimers to hardirq context. Reported-by: Frederic Weisbecker <fweisbec@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> --- kernel/trace/trace_sysprof.c | 1 + 1 file changed, 1 insertion(+) Index: tip/kernel/trace/trace_sysprof.c =================================================================== --- tip.orig/kernel/trace/trace_sysprof.c +++ tip/kernel/trace/trace_sysprof.c @@ -202,6 +202,7 @@ static void start_stack_timer(void *unus hrtimer_init(hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); hrtimer->function = stack_trace_timer_fn; + hrtimer->irqsafe = 1; hrtimer_start(hrtimer, ns_to_ktime(sample_period), HRTIMER_MODE_REL); } --
Yes! Thanks :-) Tested-by: Frederic Weisbecker <fweisbec@gmail.com> So, just a thing. -rt make the hrtimer's timers running on softirq context because the hrtimer_interrupt doesn't run as a threaded interrupt, and then it is not preemptible right? In that case, sysprof will continue to run in hardirq context, as before, and it will considerably increase the latency. And that matters here. So I think it is important to put it on the reminder: --------------------> Subject: [PATCH] rt: add sysprof to the latency overhead reminder From: Frederic Weisbecker <fweisbec@gmail.com> Since sysprof uses the hrtimer on hardirq with interrupts disabled, it adds a latency overhead. Add it to the latency reminder. Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> --- --- linux-2.6.29-rc4/init/~main.c 2009-02-13 12:51:54.000000000 +0100 +++ linux-2.6.29-rc4/init/main.c 2009-02-13 12:55:40.000000000 +0100 @@ -904,7 +904,7 @@ static int __init kernel_init(void * unu WARN_ON(irqs_disabled()); #endif -#define DEBUG_COUNT (defined(CONFIG_DEBUG_RT_MUTEXES) + defined(CONFIG_IRQSOFF_TRACER) + defined(CONFIG_PREEMPT_TRACER) + defined(CONFIG_STACK_TRACER) + defined(CONFIG_WAKEUP_LATENCY_HIST) + defined(CONFIG_DEBUG_SLAB) + defined(CONFIG_DEBUG_PAGEALLOC) + defined(CONFIG_LOCKDEP) + (defined(CONFIG_FTRACE) - defined(CONFIG_FTRACE_MCOUNT_RECORD))) +#define DEBUG_COUNT (defined(CONFIG_DEBUG_RT_MUTEXES) + defined(CONFIG_IRQSOFF_TRACER) + defined(CONFIG_PREEMPT_TRACER) + defined(CONFIG_STACK_TRACER) + defined(CONFIG_WAKEUP_LATENCY_HIST) + defined(CONFIG_DEBUG_SLAB) + defined(CONFIG_DEBUG_PAGEALLOC) + defined(CONFIG_LOCKDEP) + defined(CONFIG_SYSPROF_TRACER) + (defined(CONFIG_FTRACE) - defined(CONFIG_FTRACE_MCOUNT_RECORD))) #if DEBUG_COUNT > 0 printk(KERN_ERR "*****************************************************************************\n"); @@ -924,6 +924,9 @@ static int __init kernel_init(void * unu #ifdef CONFIG_PREEMPT_TRACER printk(KERN_ERR "* CONFIG_PREEMPT_TRACER ...
hm, not sure. Do you know it numerically how much worst-case overhead it induces? Ingo --
Not at all. But when I find some time, I will compare some rt average tests with and without sysprof. --
Hi, Setting CONFIG_PERF_COUNTERS make my build, hang really early. Likely before ohci1394_dma=early stuff, because firescope doesn't seem to work. With attached config the system boots up to the point after /etc/rc.sysinit (this is a fedora 10 system) activates the swap. Then all I see from upstart/init is "Message from illegal source". And the system seems to stop the boot process. Strange, isn't it? So this is what I could capture with attached config, by inserting "/bin/bash" into /etc/rc.sysinit after swap activation: [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Linux version 2.6.29-rc4-rt2-tip (thomas@localhost.localdomain) (gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) ) #54 SMP PREEMPT RT Thu Feb 19 16:29:15 CET 2009 [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] NSC Geode by NSC [ 0.000000] Cyrix CyrixInstead [ 0.000000] Centaur CentaurHauls [ 0.000000] Transmeta GenuineTMx86 [ 0.000000] Transmeta TransmetaCPU [ 0.000000] UMC UMC UMC UMC [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) [ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000ede00 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 000000007f0c8000 (usable) [ 0.000000] BIOS-e820: 000000007f0c8000 - 000000007f2c9000 (ACPI NVS) [ 0.000000] BIOS-e820: 000000007f2c9000 - 000000007feb9000 (ACPI data) [ 0.000000] BIOS-e820: 000000007feb9000 - 000000007feef000 (ACPI NVS) [ 0.000000] BIOS-e820: 000000007feef000 - 000000007ff00000 (ACPI data) [ 0.000000] BIOS-e820: 000000007ff00000 - 0000000080000000 (reserved) [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] BIOS-e820: 00000000fed14000 - ...
Hmm, this appears unimplemented on -rt, shouldn't hurt much, but could Caused by CONFIG_HIGHPTE=y, as long as TLB flushes are IPIs we really need to disable IRQs for gup_fast() and thus will either need non-preemptible kmap or disabled high-pte or disable the gup_fast() fast-path, which would be a shame. --
Hi, Are you interested in these BUG reports? Without CONFIG_HIGHPTE kernel boots and seems to work correct, but I'm hitting these two BUGs: [ 19.840100] BUG: sleeping function called from invalid context at arch/x86/mm/highmem_32.c:8 [ 19.840105] in_atomic(): 0, irqs_disabled(): 1, pid: 718, name: IRQ-14 [ 19.840110] Pid: 718, comm: IRQ-14 Tainted: G W 2.6.29-rc4-rt2-tip #55 [ 19.840113] Call Trace: [ 19.840123] [<c0444cbd>] __might_sleep+0xda/0xf0 [ 19.840128] [<c043ee31>] kmap+0x50/0x77 [ 19.840133] [<c0663e35>] sg_miter_next+0xc1/0xdf [ 19.840137] [<c0663ee8>] sg_copy_buffer+0x95/0xc5 [ 19.840141] [<c0663f35>] sg_copy_to_buffer+0x1d/0x33 [ 19.840149] [<c0774ab1>] atapi_qc_complete+0x25a/0x2c5 [ 19.840153] [<c076dece>] __ata_qc_complete+0xb4/0xcd [ 19.840157] [<c076f844>] ata_qc_complete+0x1be/0x1d7 [ 19.840162] [<c077c812>] ata_hsm_qc_complete+0xa9/0xd3 [ 19.840166] [<c077ceb7>] ata_sff_hsm_move+0x67b/0x6da [ 19.840171] [<c077d19b>] ata_sff_interrupt+0x15d/0x205 [ 19.840176] [<c049440a>] handle_IRQ_event+0x4b/0xce [ 19.840180] [<c0494ac7>] do_irqd+0x141/0x271 [ 19.840184] [<c0494986>] ? do_irqd+0x0/0x271 [ 19.840189] [<c0467022>] kthread+0x4a/0x82 [ 19.840192] [<c0466fd8>] ? kthread+0x0/0x82 [ 19.840197] [<c0420b67>] kernel_thread_helper+0x7/0x10 and: [ 357.286589] BUG: sleeping function called from invalid context at arch/x86/mm/highmem_32.c:8 [ 357.286597] in_atomic(): 0, irqs_disabled(): 1, pid: 718, name: IRQ-14 [ 357.286605] Pid: 718, comm: IRQ-14 Tainted: G W 2.6.29-rc4-rt2-tip #55 [ 357.286611] Call Trace: [ 357.286624] [<c0444cbd>] __might_sleep+0xda/0xf0 [ 357.286631] [<c043ee31>] kmap+0x50/0x77 [ 357.286640] [<c0663e35>] sg_miter_next+0xc1/0xdf [ 357.286647] [<c0663ee8>] sg_copy_buffer+0x95/0xc5 [ 357.286654] [<c0663f35>] sg_copy_to_buffer+0x1d/0x33 [ 357.286664] [<c0774ab1>] atapi_qc_complete+0x25a/0x2c5 [ 357.286672] [<c076dece>] ...
They appear to be identical, so I'll consider them two instances of one
sg_copy_buffer() seems to disable IRQs, however since on -rt everything
is a irq-thread and kmap is preemptible, we don't appear to have that
need.
CC'd everybody who ever touched the file.
---
lib/scatterlist.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index b7b449d..4c6510d 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -426,7 +426,7 @@ static size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents,
sg_miter_start(&miter, sgl, nents, SG_MITER_ATOMIC);
- local_irq_save(flags);
+ local_irq_save_nort(flags);
while (sg_miter_next(&miter) && offset < buflen) {
unsigned int len;
@@ -445,7 +445,7 @@ static size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents,
sg_miter_stop(&miter);
- local_irq_restore(flags);
+ local_irq_restore_nort(flags);
return offset;
}
--
With above patch I get a lot of warnings in lib/scatterlist.c:395 sg_miter_stop+0x5a/0xa4(). Like: [ 34.946650] ------------[ cut here ]------------ [ 34.946653] WARNING: at lib/scatterlist.c:395 sg_miter_stop+0x5a/0xa4() [ 34.946655] Hardware name: MacBookPro1,1 [ 34.946657] Modules linked in: ath5k mac80211 cfg80211 video [last unloaded: scsi_wait_scan] [ 34.946665] Pid: 8, comm: sirq-block/0 Tainted: G W 2.6.29-rc4-rt2-tip #56 [ 34.946690] Call Trace: [ 34.946694] [<c0451e50>] warn_slowpath+0x8a/0xd3 [ 34.946698] [<c09ab0e4>] ? __spin_unlock+0x1e/0x43 [ 34.946703] [<c04476d6>] ? enqueue_task_fair+0x2df/0x331 [ 34.946707] [<c0442c7c>] ? enqueue_task+0x70/0x8e [ 34.946711] [<c044cf91>] ? try_to_wake_up+0x2eb/0x306 [ 34.946715] [<c0663e0a>] sg_miter_stop+0x5a/0xa4 [ 34.946719] [<c0663fd6>] sg_copy_buffer+0xa3/0xbe [ 34.946723] [<c0664041>] sg_copy_from_buffer+0x1d/0x33 [ 34.946728] [<c0774c3d>] ata_scsi_rbuf_fill+0x59/0x90 [ 34.946731] [<c07760ed>] ? ata_scsiop_inq_80+0x0/0x41 [ 34.946735] [<c0755b3e>] ? scsi_done+0x0/0x2d [ 34.946739] [<c0755b3e>] ? scsi_done+0x0/0x2d [ 34.946743] [<c0774e24>] ata_scsi_simulate+0x1b0/0x1f8 [ 34.946747] [<c0755b3e>] ? scsi_done+0x0/0x2d [ 34.946752] [<c0775178>] ata_scsi_queuecmd+0x16d/0x1bc [ 34.946756] [<c0755de0>] scsi_dispatch_cmd+0x18a/0x208 [ 34.946760] [<c075b378>] scsi_request_fn+0x349/0x487 [ 34.946764] [<c064bcb6>] blk_invoke_request_fn+0x75/0x146 [ 34.946768] [<c064c671>] __blk_run_queue+0x2d/0x42 [ 34.946772] [<c064c6ac>] blk_run_queue+0x26/0x46 [ 34.946775] [<c075a836>] scsi_run_queue+0x283/0x321 [ 34.946780] [<c075b6c9>] scsi_next_command+0x36/0x54 [ 34.946783] [<c075b8e2>] scsi_end_request+0x84/0xa1 [ 34.946787] [<c075beb9>] scsi_io_completion+0x1a4/0x3a6 [ 34.946792] [<c075c1be>] ? scsi_device_unbusy+0x8c/0xa3 [ 34.946796] [<c0755b25>] scsi_finish_command+0xd3/0xec [ 34.946800] [<c075c3bc>] ...
could you edit lib/scatterlist.c line 395 and remove this line:
WARN_ON(!irqs_disabled());
?
Ingo
--
FYI: These patches in RT2: rt-fix-ipi-kfree-introduce-ipi_softirq.patch rt-fix-ipi-kfree-introduce-ipi_softirq-cleanup.patch Cause a hard-lock when running dhcp on my 8-way AMD box. Reverting them eliminates the issue. Sven --
can you try the patches in: http://lkml.org/lkml/2009/2/17/385 http://lkml.org/lkml/2009/2/17/384 http://lkml.org/lkml/2009/2/17/387 --
These work with 2.6.29-rc4-rt2. Also fixes serial console stall. I applied them before RT and had to tweak these patches: preempt-realtime-ipi-call-lock-raw.patch preempt-realtime-x86_64.patch Thanks! Sven --
Hi, I got this warning, that i never saw before with a non rt-preempt kernel. But maybe it's just coincidence... [22652.437889] ------------[ cut here ]------------ [22652.437898] WARNING: at net/mac80211/rx.c:2234 __ieee80211_rx+0x85/0x53e [mac80211]() [22652.437904] Hardware name: MacBookPro1,1 [22652.437908] Modules linked in: ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables nf_conntrack_ftp ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables x_tables ath5k mac80211 cfg80211 video [last unloaded: scsi_wait_scan] [22652.437952] Pid: 23, comm: sirq-tasklet/1 Tainted: G W 2.6.29-rc4-rt2-tip #57 [22652.437958] Call Trace: [22652.437970] [<c0451e50>] warn_slowpath+0x8a/0xd3 [22652.437981] [<c0665165>] ? plist_add+0x73/0x8e [22652.437990] [<c0447d8e>] ? enqueue_pushable_task+0x62/0x79 [22652.437999] [<c04480f1>] ? enqueue_task_rt+0x203/0x247 [22652.438029] [<f90e78bf>] __ieee80211_rx+0x85/0x53e [mac80211] [22652.438039] [<c09aafaa>] ? __spin_unlock_irq+0x1e/0x44 [22652.438057] [<f92e14af>] ath5k_tasklet_rx+0x406/0x457 [ath5k] [22652.438067] [<c045787e>] __tasklet_action+0x8c/0x100 [22652.438075] [<c04579d8>] tasklet_action+0x67/0x7f [22652.438083] [<c04575e3>] ksoftirqd+0x12d/0x223 [22652.438091] [<c04574b6>] ? ksoftirqd+0x0/0x223 [22652.438099] [<c0467022>] kthread+0x4a/0x82 [22652.438106] [<c0466fd8>] ? kthread+0x0/0x82 [22652.438114] [<c0420b67>] kernel_thread_helper+0x7/0x10 [22652.438120] ---[ end trace a7919e7f17c0a727 ]--- --
Hi, Is this one probably rt-preempt related? BUG: unable to handle kernel paging request at 00100100 IP: [<f8aa431c>] __nf_conntrack_find+0xd6/0x109 [nf_conntrack] *pde = 34ece067 *pte = 00000000 Oops: 0000 [#1] PREEMPT SMP last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0/energy_full Modules linked in: nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ftp nf_conntrack_ipv6 xt_state nf_conntrack ath5k mac80211 cfg80211 video [last unloaded: scsi_wait_scan] Pid: 5, comm: sirq-timer/0 Tainted: G W (2.6.29-rc4-rt2-tip #60) MacBookPro1,1 EIP: 0060:[<f8aa431c>] EFLAGS: 00010206 CPU: 0 EIP is at __nf_conntrack_find+0xd6/0x109 [nf_conntrack] EAX: f4853240 EBX: f7053d38 ECX: 00100100 EDX: f4f5c640 ESI: ea190868 EDI: c0e07ec0 EBP: f7053cc8 ESP: f7053cb8 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 preempt:00000001 Process sirq-timer/0 (pid: 5, ti=f7053000 task=f7064dc0 task.ti=f7053000) Stack: 985792de f7053d38 c0e07ec0 c0e07ec0 f7053ce0 f8aa4731 985792de f7053d38 f8ba3bb8 c0e07ec0 f7053d70 f8aa59c5 f6b81a00 f1ec5ef4 00000003 00000002 f8ab132c 00000014 f7053d94 00000014 f7053d30 06053d4e f5a92000 f67f2980 Call Trace: [<f8aa4731>] ? nf_conntrack_find_get+0x26/0x75 [nf_conntrack] [<f8aa59c5>] ? nf_conntrack_in+0x15a/0x45d [nf_conntrack] [<f8ba2472>] ? ipv4_conntrack_local+0x3d/0x58 [nf_conntrack_ipv4] [<c089cdaf>] ? nf_iterate+0x4f/0x93 [<c08b3938>] ? dst_output+0x0/0x2b [<c08b3938>] ? dst_output+0x0/0x2b [<c089cf84>] ? nf_hook_slow+0x65/0xd3 [<c08b3938>] ? dst_output+0x0/0x2b [<c08b3938>] ? dst_output+0x0/0x2b [<c08b5292>] ? __ip_local_out+0x9f/0xba [<c08b3938>] ? dst_output+0x0/0x2b [<c08b52c8>] ? ip_local_out+0x1b/0x3d [<c08b5b31>] ? ip_queue_xmit+0x2cf/0x358 [<c0442c7c>] ? enqueue_task+0x70/0x8e [<c08ca3de>] ? tcp_v4_send_check+0x85/0xd0 [<c08c680e>] ? tcp_transmit_skb+0x5f9/0x642 [<c08c5d35>] ? tcp_current_mss+0x66/0xeb [<c08c81b0>] ? tcp_retransmit_skb+0x4f2/0x632 [<c08c99b0>] ? tcp_write_timer+0x3c2/0x592 ...
We are pleased to announce the next update to our new preempt-rt
series. It forwards to 2.6.29-rc6 and fixes
- various 32bit highmem related problems
- paravirt interaction
- sg list warnings
- IPI updates
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29-rc6-rt2 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29-rc6.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc6-rt2.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
Thomas, Ingo
--
We are pleased to announce the next update to our new preempt-rt
series. It contains only one new patch:
- fix the nf_conntrack bug, which was reported by various folks
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29-rc6-rt3 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29-rc6.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc6-rt3.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
We are pleased to announce the next update to our new preempt-rt
series. It contains only one new patch:
- fix the nf_conntrack bug, which was reported by various folks
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29-rc6-rt3 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29-rc6.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc6-rt3.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
Hi, Should suspend&resume to ram work with this patchset applied? greets thomas --
If it works for you without (plain .29-rc6), then it ought to work with. --
plain .29-rc6 suspends and resumes just fine. but .29-rc6-rt3 suspends just fine, but never resumes. Is there an early_dma thing for the resume path for 1394? greets thomas --
We are pleased to announce the next update to our new preempt-rt
series. It contains only one new patch:
- port forward to 2.6.29-rc7
- disable CONFIG_MAXCPUS for now (undebugged runtime bug)
- fix CONFIG_HIGHMEM problems
- fix netfilter problems
- make debugobjects -rt safe
- various build fixes
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29-rc7-rt1 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29-rc7.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc7-rt1.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
Hi This should be http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc7-rt1.patch.bz2 As far as i understand this is again for x86. I tried some patches to get the ARM platform working as the platform i am working on (phytec i.mx31) is not supported by the stable 2.6.26-rt release. The attached patches are for reference only as i think some of them are on their way via the pengutronix git tree and others are just hacks to get this thing compile. These patches enable rt functionality as tested with cyclictest but the kernel is not stable, so some pieces are missing. So my question is, what pieces are missing on the ARM platform to get it working? Regards Tim The following patches are against the 2.6.29-rc4-rt2 in an attempt to get ARM working. Subject: [PATCH] add compile fixes to rt patchset for arm --- arch/arm/Kconfig | 13 +------------ arch/arm/include/asm/thread_info.h | 3 ++- arch/arm/plat-mxc/include/mach/memory.h | 2 ++ include/linux/spinlock.h | 3 ++- 4 files changed, 7 insertions(+), 14 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index dbfdf87..ceb2e01 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -838,18 +838,7 @@ config LOCAL_TIMERS accounting to be spread across the timer interval, preventing a "thundering herd" at every timer tick. -config PREEMPT - bool "Preemptible Kernel (EXPERIMENTAL)" - depends on EXPERIMENTAL - help - This option reduces the latency of the kernel when reacting to - real-time or interactive events by allowing a low priority process to - be preempted even if it is in kernel mode executing a system call. - This allows applications to run more reliably even when the system is - under load. - - Say Y here if you are building a kernel for a desktop, embedded - or real-time system. Say N if you are unsure. +source ...
Hello Tim, See the follow up mail I will write on Thomas announcement for my I suggested a better fix already last time. Moreover I think imx isn't Doing this in arch/arm/include/asm/bitops.h is less intrusive and it It would be easier to check your patch if it didn't contain reverts of earlier changes. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | --
Hello, on top of 2.6.29-rc7-rc1 I did some ARM related fixes that you can find at git://git.pengutronix.de/git/ukl/linux-2.6.git v2.6.29-rc7-rt1-pu The top commit currently isn't pretty as it contains several independant fixes. Some of them are netX specific so you probably don't need them, but they shouldn't hurt you either. I will update this branch as I continue working in a non-fast-forward manner. I use TopGit to manage this branch, you might want to use it, too, if you intend to follow my work. My status quo is: Testing tracer sched_switch: PASSED Testing tracer function: PASSED Testing tracer irqsoff: .. no entries found ..FAILED! Testing tracer preemptoff: .. no entries found ..FAILED! Testing tracer preemptirqsoff: .. no entries found ..<4>------------[ cut here ]------------ WARNING: at /ptx/work/octopus/WORK_2_A/ukl/gsrc/linux-2.6/kernel/trace/trace.c:683 warn_slowpath+0x18/0xa0() Modules linked in: [<c0244d40>] (dump_stack+0x0/0x18) from [<c003787c>] (warn_slowpath+0x6c/0xa0) [<c0037810>] (warn_slowpath+0x0/0xa0) from [<c00750d0>] (tracing_start+0x60/0xdc) r3:ffffffff r2:00000000 r7:c074aaf0 r6:c0748a0c r5:60000013 r4:c074aac8 [<c0075070>] (tracing_start+0x0/0xdc) from [<c0076430>] (trace_selftest_startup_preemptirqsoff+0x1ac/0x1d8) r5:c1c1a000 r4:ffffffff [<c0076284>] (trace_selftest_startup_preemptirqsoff+0x0/0x1d8) from [<c00760c4>] (register_tracer+0x118/0x240) [<c0075fac>] (register_tracer+0x0/0x240) from [<c000ebbc>] (init_irqsoff_tracer+0x24/0x38) r7:c000eb98 r6:00000000 r5:c001c44c r4:c001c2b8 [<c000eb98>] (init_irqsoff_tracer+0x0/0x38) from [<c00232c4>] (__exception_text_end+0x5c/0x1a4) [<c0023268>] (__exception_text_end+0x0/0x1a4) from [<c00085a4>] (kernel_init+0x90/0x1c0) r8:00000000 r7:00000000 r6:00000000 r5:c001c44c r4:c001c2b8 [<c0008514>] (kernel_init+0x0/0x1c0) from [<c003aebc>] (do_exit+0x0/0x798) r5:00000000 r4:00000000 ---[ end trace da227214a82491b7 ]--- FAILED! The warning is triggered here ...
Hello, I still have this problem. I digged into irqsoff without finding the reason. Looking at trace_selftest_startup_irqsoff I saw that trace_buffer_lock_reserve is called thrice successfully. Up to now I didn't try to do much with my system, but just booting doesn't yield such BUGs or Warnings anymore. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | --
We are pleased to announce the next update to our new preempt-rt
series.
- port forward to 2.6.29-rc8
- disable -rt conflicting config options
- hotplug cpu fixes (peterz)
- slab/pagealloc lock breaks (peterz / tglx)
- sigqueue caching for -rt tasks
- posixtimer thread avoid useless wakeups
- various build fixes (mingo, frank ....)
- lots of tracer updates from -tip (check the tip git logs)
The outstanding improvement is the slab/pagealloc change which breaks
and splits locking and brought down worst case latencies in
problematic use cases from >500us to <100us.
As a side note:
There seems to be a wide spread underestimation of the problem spots
exposed by preempt-rt. The usual shrug off answer is:
"I don't care about -rt. Come back if you can expose the same
problem in the mainline kernel."
This is a fundamentally wrong answer.
preempt-rt mostly exposes existing latency spots and magnifies
them
Reducing latencies in -rt by a factor 5 will be not that
prominent in a non-rt setup, but the problematic code area
will still produce measureable latency problems.
I'm well aware of the tradeoff between determinitic behaviour and
throughput, but problematic spots (e.g. lock contentions) hurt
both.
So can we please put down the stupid "I don't care about -rt"
attitudes and accept that we have to think about the mutual
benefits of deterministic and throughput aspects without hurting
each other ?
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29-rc8-rt1 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29-rc8.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc8-rt1.bz2
The broken out patches are also ...Do you have a time estimate for -rt2/ARM support, and is there anything that can be done to help (testing, etc). Thanks, Cliff -- ======================= Cliff Brake http://bec-systems.com --
Yup, the patches need full testing. Thanks, tglx --
We are pleased to announce the next update to our new preempt-rt
series.
- resurrected ARM and PowerPC support
- tracing fixes for ARM (Uwe Kleine-Koenig)
The support for ARM/PowerPC has only been lightly tested. It might
crash and burn your system, make your hair curl, frigthen your cat and
give you sleepless nights. You have been warned !
On PowerPC watch out for the following warning:
__do_IRQ called for irq X. PREEMPT_RT will crash your system soon.
__do_IRQ is deprecated and -rt does not support it anymore. Most of
the PowerPC subarchitectures do not longer use it, but you might be
unlucky and hit one of the remaining users. RT will spit out the
message above and then do what it said. :)
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29-rc8-rt1 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29-rc8.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc8-rt2.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
During a build attempt on powerpc, I am seeing:
In file included from include/linux/mmzone.h:776,
from include/linux/gfp.h:5,
from include/linux/slab.h:13,
from include/linux/percpu.h:6,
from include/linux/rcupdate.h:40,
from include/linux/rculist.h:11,
from include/linux/dcache.h:7,
from include/linux/fs.h:299,
from init/do_mounts_rd.c:4:
/root/linux-2.6.29-rc8/arch/powerpc/include/asm/mmzone.h:32: error:
expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before
‘numa_cpumask_lookup_table’
In file included from include/linux/topology.h:35,
from include/linux/gfp.h:8,
from include/linux/slab.h:13,
from include/linux/percpu.h:6,
from include/linux/rcupdate.h:40,
from include/linux/rculist.h:11,
from include/linux/dcache.h:7,
from include/linux/fs.h:299,
from init/do_mounts_rd.c:4:
/root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h: In function
‘node_to_cpumask’:
/root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h:22: error:
‘numa_cpumask_lookup_table’ undeclared (first use in this function)
/root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h:22: error:
(Each undeclared identifier is reported only once
/root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h:22: error:
for each function it appears in.)
/root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h: In function
‘node_to_first_cpu’:
/root/linux-2.6.29-rc8/arch/powerpc/include/asm/topology.h:29: error:
‘numa_cpumask_lookup_table’ undeclared (first use in this function)
make[1]: *** [init/do_mounts_rd.o] Error 1
make[1]: *** Waiting for unfinished jobs....
I have locally fixed by adding an include just above the cpumask_t
reference. The include may belong elsewhere, but in case I got it
right,.. ...you got it right :-) The full fix (the bug also affects sparc) is already queued up - see it below. Ingo --------------> From 0c7e5b187fc599a40c1e6392926424d26cd0cf41 Mon Sep 17 00:00:00 2001 From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Thu, 19 Mar 2009 22:03:22 +1100 Subject: [PATCH] numa, cpumask: move numa_node_id default implementation to topology.h, fix Impact: build fix for powerpc and sparc Caused by commit 082edb7bf443eb8eda15b482d16ad9dd8137ad24 ("numa, cpumask: move numa_node_id default implementation to topology.h") from the cpus4096 tree which removed the include of linux/topology.h from linux/mmzone.h. Same for sparc64 defconfig. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-b: Rusty Russell <rusty@rustcorp.com.au> Cc: ppc-dev <linuxppc-dev@ozlabs.org> LKML-Reference: <20090319220322.3baa4613.sfr@canb.auug.org.au> Signed-off-by: Ingo Molnar <mingo@elte.hu> --- arch/powerpc/include/asm/mmzone.h | 1 + arch/sparc/include/asm/mmzone.h | 2 ++ 2 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/mmzone.h b/arch/powerpc/include/asm/mmzone.h index 19f299b..35acac9 100644 --- a/arch/powerpc/include/asm/mmzone.h +++ b/arch/powerpc/include/asm/mmzone.h @@ -8,6 +8,7 @@ #define _ASM_MMZONE_H_ #ifdef __KERNEL__ +#include <linux/cpumask.h> /* * generic non-linear memory support: diff --git a/arch/sparc/include/asm/mmzone.h b/arch/sparc/include/asm/mmzone.h index ebf5986..e8c6487 100644 --- a/arch/sparc/include/asm/mmzone.h +++ b/arch/sparc/include/asm/mmzone.h @@ -3,6 +3,8 @@ #ifdef CONFIG_NEED_MULTIPLE_NODES +#include <linux/cpumask.h> + extern struct pglist_data *node_data[]; #define NODE_DATA(nid) (node_data[nid]) --
We are pleased to announce the next update to our new preempt-rt
series.
- fix a x86 32bit PAE pagetable corruption caused by a hard to
trigger race.
- update to latest linus and tip
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29-rc8-rt3 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29-rc8.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc8-rt3.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
Hi, It doesn't seem to be available (404). But I can see a 2.6.29-rc8-rt4.bz2 downloadable. --
This is a channel log from #linux-rt
19:57 < clark|w> tglx, just how small was the -rt3 window (which I hit btw)?
19:58 < tglx> you mean how long -rt3 was up on the web ?
19:58 < clark|w> yeah
19:58 < tglx> half an hour or so
19:59 < clark|w> because I got it, built/booted it (64-bit) and was running it
up til thismorning when I saw that you'd released -rt4 :)
19:59 < tglx> 64bit was fine
19:59 < tglx> I fixed a 32bit PAE bug in -rt2 and when I pushed out -rt3 I did
not notice that half of the fix was lost
20:00 < tglx> so I zapped it and pushed out rt4
20:00 < clark|w> cool
20:00 < clark|w> good think I'm 64bit clean :)
20:00 < tglx> but I was too tired to send out another mail
Just FYI
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
We are pleased to announce the next update to our new preempt-rt
series.
- port forward to 2.6.29 final
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29-rt1 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.29.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rt1.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
Is this valid ? -- JSR --
Hi, I understood statement that Thosmas explained about invalid access of 2.6.29-rt1 soruces. In general, We remeber rc directory (./v2.6/testing/ and release directory (./v2.6/) certainly. Release Version is located in http://www.kernel.org/pub/linux/kernel/v2.6/ site. RC Version is located in http://www.kernel.org/pub/linux/kernel/v2.6/testing/ site. I summarized quick howto per notice of "2.6.* rt patch" file. fc9#> wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.tar.bz2 (If linux version is RC[release candidate] version, use "wget http://www.kernel.org/pub/linux/kernel/v2.6/testing/***" command.) fc9#> wget http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rt1.bz2 fc9#> tar xjf ./linux-2.6.29.tar.bz2 fc9#> tar xvjf ./patch-2.6.29-rt1-broken-out.tar.bz2 fc9#> cd ./linux-2.6.29 fc9#> for i in `cat ../patches/series | grep patch | grep -v "#" `;do echo "+++ patching $i"; patch -p1 < ../patches/$i;done fc9#> cp ./arch/x86/configs/i386_defconfig ./.config fc9#> make menuconfig ..... Below Omission ..... Regards, GeunSik Lim -- Regards, GeunSik Lim -- --
Hi, I understood statement that Thosmas explained about invalid access of 2.6.29-rt1 soruces. In general, We remeber rc directory (./v2.6/testing/ and release directory (./v2.6/) certainly. Release Version is located in http://www.kernel.org/pub/linux/kernel/v2.6/ site. RC Version is located in http://www.kernel.org/pub/linux/kernel/v2.6/testing/ site. I summarized quick howto per notice of "2.6.* rt patch" file. fc9#> wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.tar.bz2 (If linux version is RC[release candidate] version, use "wget http://www.kernel.org/pub/linux/kernel/v2.6/testing/***" command.) fc9#> wget http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rt1.bz2 fc9#> tar xjf ./linux-2.6.29.tar.bz2 fc9#> tar xvjf ./patch-2.6.29-rt1-broken-out.tar.bz2 fc9#> cd ./linux-2.6.29 fc9#> for i in `cat ../patches/series | grep patch | grep -v "#" `;do echo "+++ patching $i"; patch -p1 < ../patches/$i;done fc9#> cp ./arch/x86/configs/i386_defconfig ./.config fc9#> make menuconfig ..... Below Omission ..... Regards, GeunSik Lim --
We are pleased to announce the next update to our new preempt-rt
series.
- fix a fork/exit bug in the signal per task cache (/me puts on
a huge brown paper bag - Thanks to Phillipe Reynes and Will
Schmidt for reporting and testing)
- fix a group scheduling migration accounting bug (decoded with
and fixed by Peter Zijlstra - reported by Robin Gareus)
- tlb gather rework by Peter Zijlstra - Thanks Peter !
- the usual fixlets
The tlb rework might be incomplete on some of the uncountable
incarnations of PowerPC and ARM platforms, so look out for wreckage
and keep the usual tools (fire-extinguishers, brooms, buckets etc.)
handy.
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29-rt2 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rt2.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
I can confirm that the tlb rework does appear to be missing some parts for Power. (Using 2.6.29-rt3 on pseries ppc64) arch/powerpc/kernel/built-in.o:(.toc1+0x4d0): undefined reference to `per_cpu__ppc64_tlb_batch' <...> mm/built-in.o:(.toc1+0xed0): more undefined references to `per_cpu__ppc64_tlb_batch' follow Not clear to me if this is just missing a "DEFINE_PER_CPU_LOCKED" to replace the removed "DEFINE_PER_CPU", (similar to the prior RT patches), or if the tlb rework is more involved. So, I will patiently remain tuned in. :-) Thanks, -Will --
No, the DEFINE_PER_CPU was removed accidentaly. Should have stayed there Thanks, tglx -------- Index: linux-2.6-tip/arch/powerpc/mm/tlb_hash64.c =================================================================== --- linux-2.6-tip.orig/arch/powerpc/mm/tlb_hash64.c +++ linux-2.6-tip/arch/powerpc/mm/tlb_hash64.c @@ -32,6 +32,8 @@ #include <asm/bug.h> #include <asm/machdep.h> +DEFINE_PER_CPU(struct ppc64_tlb_batch, ppc64_tlb_batch); + /* * A linux PTE was changed and the corresponding hash table entry * neesd to be flushed. This function will either perform the flush --
Thanks for the quick respin.
Panic during boot:
<snip>
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
ide-cd driver 5.00
mice: PS/2 mouse device common for all mice
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
Freeing unused kernel memory: 292k freed
Red Hat nash version 5.1.19.6 starting
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x00000c30
cpu 0x3: Vector: 400 (Instruction Access) at [c0000000e8203b00]
pc: 0000000000000c30
lr: c0000000000b7d24: .rcu_process_callbacks+0xc0/0xec
sp: c0000000e8203d80
msr: 8000000040009032
current = 0xc0000000e81ff0f0
paca = 0xc000000000663800
pid = 53, comm = sirq-rcu/3
enter ? for help
[c0000000e8203d80] c0000000000b7d24 .rcu_process_callbacks+0xc0/0xec
(unreliable)
[c0000000e8203e10] c000000000070f48 .ksoftirqd+0x208/0x39c
[c0000000e8203f00] c000000000085a34 .kthread+0x78/0xc4
[c0000000e8203f90] c000000000029818 .kernel_thread+0x54/0x70
3:mon>
3:mon> r
R00 = c0000000e8480100 R16 = c000000000467280
R01 = c0000000e8203d80 R17 = c000000000465980
R02 = 000000000014ff97 R18 = 0000000000000000
R03 = c0000000e6b6b880 R19 = c0000000e8200000
R04 = 0000000000000001 R20 = c00000000065be58
R05 = c000000000663800 R21 = 0000000000000000
R06 = c0000000e8203cc8 R22 = 0000000000000003
R07 = 0000000000200200 R23 = 0000000000000003
R08 = 0000000000000001 R24 = c000000000663800
R09 = c0000000e6b60eb0 R25 = c000000000696f00
R10 = c000000000538280 R26 = c00000000079e620
R11 = 0000000000000001 R27 = 0000000000000100
R12 = 0000000084000082 R28 = 0000000000000001
R13 = c000000000663800 R29 = c00000000079ea28
R14 = 0000000000000000 R30 = c0000000005d1538
R15 = 0000000002100000 R31 = c0000000e8480100
pc = 0000000000000c30
lr = c0000000000b7d24 .rcu_process_callbacks+0xc0/0xec
msr = 8000000040009032 cr = ...Will, could you see if the below makes your splat go away?
diff --git a/arch/powerpc/include/asm/tlb.h b/arch/powerpc/include/asm/tlb.h
index ec82dac..3ddc8f6 100644
--- a/arch/powerpc/include/asm/tlb.h
+++ b/arch/powerpc/include/asm/tlb.h
@@ -38,6 +38,8 @@ struct arch_mmu_gather {
struct pte_freelist_batch *batch;
};
+#define ARCH_MMU_GATHER_INIT (struct arch_mmu_gather){ .batch = NULL, }
+
#if !defined(CONFIG_PPC_STD_MMU)
#define tlb_flush(tlb) flush_tlb_mm((tlb)->mm)
diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index 7f2167e..50a09de 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -71,6 +71,10 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned int full_m
tlb->nr = ~0U;
tlb->fullmm = full_mm_flush;
+
+#ifdef HAVE_ARCH_MMU_GATHER
+ tlb->arch = ARCH_MMU_GATHER_INIT;
+#endif
}
static inline void
--
We are pleased to announce the next update to our new preempt-rt
series.
- rebased to 2.6.29.1
- powerpc64 tlb rework fix by Peter
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.1-rt4 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.1.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt4.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
Thanks for cc'ing me... Just a heads up. I'm still having shutdown/suspend problems with this release as before (I had not reported the suspend problem, I think - machine hangs and has to be power cycled). Booting with "noreplace-smp" fixes both. Is this something I could disable through configuration options? I was also seeing a hard hang when running a java program (with the Fedora 10 open source java) - the swingosc gui component of SuperCollider 3 (a computer music synthesis program). Impossible to know what had failed, machine completely catatonic and nothing left on the logs. I managed to start the same program _once_ (have not tested again) with 2.6.29.1/rt4 + some patches & config from fc10' koji 2.6.29.1-15. The mouse seemed to pause a couple of times and then I killed the program. Restarting it again was successful. Sorry to not have more hard info... -- Fernando --
No. I have this shutdown/suspend thing on my todo list. Can you send me your .config please ? This happens with the stock -rt kernel or do Too bad that I can't find my crystal ball :) Thanks, tglx --
Ah, ok. No problem. If it were not for this feature I'd probably release Other patches on top of it. I'm building rpm packages merging the latest Fedora .src.rpm's with rt (as I have been doing for a long long time). I have to have as close a kernel as possible to the Fedora kernels (drivers + configs, within reason - some of the stuff does not patch cleanly of course[*]). The kernel I'm testing is merged with 2.6.29.1-15 / fc10. Sigh, I know, I know, I have to try to test with the vanilla tree. I don't anticipate having time to do that soon (concert tomorrow, trip You __have__ one?? Wow. Anyway, it seems that the java problem is gone or something else killed it (another software upgrade perhaps?). Which is good. Thanks again, looking forward to the next release! -- Fernando [*] over the years I have tried different approaches and this is the one that has given me kernels that work and are most compatible with the rest of Fedora.
For me it is repeatable (on both a laptop and a desktop machine so it does not appear to be very hardware specific). It might be of course an interaction with the Fedora patches I use. In the category of "I wish I had a crystal ball" reports with no hard data, I can confirm that my build of rt4 does hang. I was trying 2.6.29.1-rt4 during a rehearsal for a concert yesterday[*] and after a hard hang I reverted to the vanilla Fedora kernel (which is what I had been using because of that problem - no clues left behind in logs). -- Fernando [*] a T61 lenovo laptop with intel graphics running jack 1.9.1, linuxsampler, supercollider with two instances of the synthesis engine doing both audio and midi processing, a convolution reverb using jconv, ambisonics decoding through two instances of ambdec and the java based swingosc supercollider gui. Very loaded. --
Hmm. Can you upload your full patch queue and the binary rpm so I can give it a test ride ? Thanks, tglx --
Sure, no problem. I just did a release to planetcore-testing repo (with a warning to the planetccrma list), you can find it here: http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/i386/r... http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/x86_64... (the one I have tested and hangs is the i386 PAE version) Source here: http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetcore/testing/10/SRPMS/ (if you don't want to figure out the .src.rpm - I would not blame you - I can give you a list of the patches that were actually applied - of the ones that are included in the package) -- Fernando --
Fernando, No problem. I know how to distangle those beasts. Still I have no reproducer yet. One of my 32bit test machines survived a 200 cycle test w/o showing it. Is there anything special what you run, load ... ? Looks like I need to add a 32bit install to my T61 in the hope to reproduce. Thanks, tglx --
Arghh, I don't know what it could be then. You mean 200 power cycles?? Not that I can think of right now. This happens on 32 bit installs on both Fedora 9 and Fedora 10. Nothing special installed, of course I have the Planet CCRMA packages but they don't involve additional kernel Sorry for the inconvenience. Additional installs, argh (BTW, I won't be reading email for at least a week, of to LAC2009 tomorrow with a week of R&R before - please keep cc'ing me on rt stuff). Thanks!!! -- Fernando --
Fernando, Does it trigger when you just boot up and the immediately shut down w/o doing any work on it ? Could you try whether the following triggers the bug as well: Boot up, do work or whatever. Make sure your data is sycned to disk. :) # echo 0 >/sys/devices/system/cpu/cpu1/online If that does not trigger, then check whether it survives the Can you provide the list of modules loaded ? Thanks, tglx --
Yes. Just tried again. Clarification: triggers on a "halt -p", _not_ on It triggers it immediately (in my laptop), I tried from a text console and it spews things and at the bottom a poke_text thing like before (after a while I got a couple of messages from iwl3945 about a timeout and somehow it started to reboot, either when I pressed the power button Three lists attached, first all modules after I login, then modules after a single user boot and then two more after I removed bluetooth and 80211* modules on a hunch, fails to power off in all cases (I first saw a ref to blue something at the very top of the dump, so removed that, then saw a reference to 80211 at the top, removed that, then I gave up :-) -- Fernando
Maybe I am a special case, somehow: -------- Forwarded Message -------- From: Timo Sivula To: planetccrma@ccrma.Stanford.EDU Subject: Re: [PlanetCCRMA] for brave users only, kernel 2.6.29.1-rt4 for fc10 Date: Tue, 07 Apr 2009 12:46:41 +0300 ma, 2009-04-06 kello 12:00 -0700, planetccrma-request@ccrma.Stanford.EDU Starts and closes fine here with my system. Also has not made my mouse slow, yet. However, neither ndiswrapper 1.53 nor 1.54 does compile with this kernel. --
Thank you for new release announce. I am using new version ( linux-2.6.29.1-rt4 ) now . config file is http://leemgs1.googlecode.com/files/i386.2.6.29.1-rt4.ftrace.config.20090404 I have one question. What is "broken-out" 's meaning for rt patch file? When I opened realtime patch files for vanilla kernel, I always checked 2 files like belows. http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt4-broken-out.tar.bz2 <-- collection of seperate files for each patch. http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt4.bz2 <-- only one patch file. What is difference meaning of file-name format between "patch-2.6.29.1-rt4-broken-out.tar.bz2" and "patch-2.6.29.1-rt4.bz2" ? I have always wondered that. I am sorry for sending this stupid and easy question. Thanks, GeunSik Lim, -- Regards, GeunSik Lim -- --
GeunSik, The broken out tar ball contains a patch series of smaller patches, which need to be applied in a give order. The order is determined from the series file. It's a "quilt" series. quilt is a patch series management tool. "man script" We keep those smaller patches for various reasons: - It's way easier to move forward to the next kernel version with smaller patches than with a huge all in one patch. - It's easier to split out functionality from the patches and rework that particular issue and replace the patches in the series The broken out series is provided for people who want to look into the details of the patches and for preempt-rt developers. patch-2.6.X-rtY.bz2 is the combination of all patches from the series applied. We provide this as a conveniance for users and testers so they just have to apply one big patch. Thanks, tglx --
We are pleased to announce the next update to our new preempt-rt
series.
- include the futex rework + requeue_pi support (Darren Hart)
The futex changes need profound testing. As we know from prior futex
work the best stress tests for the futex interface are RT-Java-VMs
especially with enterprise work loads on larger machines. Can the
folks who have access to such monstrosities please unleash the beasts
and give the futex code a good work out ? Please tell your sysadmin
upfront that he should be stand by to fix up the resulting wreckage
which might vary from harmless to system replacement.
Unfortunately I was not able to track down the weird 32bit PAE
shutdown crash, so the affected users need to stick to the
nosmp-alternatives work around for now.
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.1-rt5 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.1.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt5.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
We are pleased to announce the next update to our new preempt-rt
series.
- rt locks fixes (Jan Blunck, tglx)
- kvm vs. -rt fixes (Jan Blunck)
- hpet interrupt fix (tglx, reported and tested by Hans Peter Bock)
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.1-rt6 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.1.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt6.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
Dear Thomas Thank you for your notice about new rt patch. I am running linux-2.6.29.1-rt6 on Q9300 with fedora 9 distribution normally like belows. So I changed version from linux-2.6.29-rt2 to linux-2.6.29.1-rt6. I will test about a various case with linux-2.6.29.1-rt6 version. [invain@fedora9 invain]$ uname -a Linux fedora9 2.6.29.1-rt6-lgs #1 SMP PREEMPT RT Fri Apr 10 10:02:20 KST 2009 i686 i686 i386 GNU/Linux [invain@fedora9 invain]$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz stepping : 7 cpu MHz : 2494.087 cache size : 3072 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi flexpriority bogomips : 4988.17 clflush size : 64 power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz stepping : 7 cpu MHz : 2494.087 cache size : 3072 KB physical id : 0 siblings : 1 core id : 1 cpu cores : 4 apicid : 1 initial apicid : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi flexpriority bogomips : 4987.23 clflush size : 64 power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : ...
We are pleased to announce the next update to our new preempt-rt
series.
- futex testing fallout fix (Darren Hart)
- kvm vs. -rt fix resurrected (tglx)
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.1-rt7 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.1.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt7.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
We are pleased to announce the next update to our new preempt-rt
series.
- 32bit PAE SMP alternatives crash fixed (mainline fix)
- hrtimer UP deadlock fix (tglx)
- missing fixlets picked from -24/26 (clarkw, acme)
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.1-rt8 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.1.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt8.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
when using patch-2.6.29.1-rt8 with CONFIG_PREEMPT_SOFTIRQS=y, but not
enable PREEMPT_RT, there will be an error when linking kernel:
undefined reference to hrtimer_wait_for_timer
I found that, hrtimer_wait_for_timer is only defined when PREEMPT_RT is
enabled, but in include/linux/hrtimer.h, the source code is like this:
#ifdef CONFIG_PREEMPT_SOFTIRQS
extern void hrtimer_wait_for_timer(const struct hrtimer *timer);
#else
# define hrtimer_wait_for_timer(timer) do { cpu_relax(); } while (0)
a possible fix should be:
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 8bafa35..1c1cdf3 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -366,7 +366,7 @@ static inline int hrtimer_restart(struct hrtimer
*timer)
}
/* Softirq preemption could deadlock timer removal */
-#ifdef CONFIG_PREEMPT_SOFTIRQS
+#if defined(CONFIG_PREEMPT_SOFTIRQS) && defined(CONFIG_PREEMPT_RT)
extern void hrtimer_wait_for_timer(const struct hrtimer *timer);
#else
# define hrtimer_wait_for_timer(timer) do { cpu_relax(); } while (0)
--
Wu Zhangjin
DSLab, Lanzhou University, China
www.lemote.com, Jiangsu Province, China
--
We are pleased to announce the next update to our new preempt-rt
series.
- hrtimer fix softirq handling
- x86/64 build fix for empty sections
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.1-rt9 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.1.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.1-rt9.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
We are pleased to announce the next update to our new preempt-rt
series.
- update to 2.6.29.2
- HPET/IOAPIC mainline fix
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.2-rt10 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.2.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.2-rt10.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
We are pleased to announce the next update to our new preempt-rt
series.
- ioperm fix for x86/32bit
- hrtimer fix for !highres
- futex updates (Darren Hart)
- sys_rt_tgsigqueueinfo added for testing
The MIPS support is still work in progress, but I expect that it will
hit -rt12.
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.2-rt11 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.2.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.2-rt11.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
We are pleased to announce the next update to our new preempt-rt
series.
- rebase to 2.6.29.3 (NOP)
- loadavg optimization
- futex updates (tglx, peterz)
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.3-rt12 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.3.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.3-rt12.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
This patch resulted in a broken build for me, until I did this: --- a/patch-2.6.29.3-rt12 +++ b/patch-2.6.29.3-rt12 @@ -121754,7 +121754,7 @@ Index: linux-2.6-tip/kernel/sched.c } /* -@@ -2801,6 +3177,15 @@ static void update_cpu_load(struct rq *t +@@ -2801,6 +3177,17 @@ static void update_cpu_load(struct rq *t new_load += scale-1; this_rq->cpu_load[i] = (old_load*(scale-1) + new_load) >> i; } @@ -121765,8 +121765,10 @@ Index: linux-2.6-tip/kernel/sched.c + this_rq->calc_load_update += LOAD_FREQ; + calc_load_account_active(this_rq); + ++#ifdef CONFIG_SMP + if (this_rq->cpu == calc_load_cpu) + calc_global_load(); ++#endif } #ifdef CONFIG_SMP I have no idea if that is a valid thing to do, but it seems to work for me. Regards, Hugo Vincent --
Darn. the patch is halfways right. the #ifdef needs to be only around the if() line. Otherwise your /proc/loadavg values will never be updated. I'll push out -rt13 with the proper fix.. Thanks, tglx --
We are pleased to announce the next update to our new preempt-rt
series.
- rebase to 2.6.29.4 (no conflicts)
- futex updates (tglx, dvhart)
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.4-rt15 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.4.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.4-rt15.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
We are pleased to announce the next update to our new preempt-rt
series.
- fix loadavg bug on 64bit
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.4-rt16 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.4.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.4-rt16.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
Thank you for notice of 2.6.29.r-rt16 release. This is a report about "/proc/interrupts" result in my development system. * System requirements : Core2 Quad Q6600 , LV-676 Motherboard , SATA 160G, DDR2 3G , ftp://ftp.commell.com.tw/COMMELL/support/LV-676/BIOS/676x161.zip. In summary, I can't get irq loadbalancing(/proc/interrupts) in my system using 2.6.29.4-rt16 linux kernel because of LV-676 motherboard's H/W problem. ( I disabled [ ]irqbalance - userspace with "ntsysv" command in this experiment . ) [geunsik@centos5.3 ~]$ [geunsik@centos5.3 ~]$ [geunsik@centos5.3 ~]$ cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 136 0 0 0 IO-APIC-edge timer 1: 2 0 0 0 IO-APIC-edge i8042 3: 2 0 0 0 IO-APIC-edge 4: 2 0 0 0 IO-APIC-edge 6: 2 0 0 0 IO-APIC-edge floppy 7: 0 0 0 0 IO-APIC-edge lpptest 8: 1 0 0 0 IO-APIC-edge rtc 9: 1 0 0 0 IO-APIC-fasteoi acpi 16: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb3 18: 15030 2133 4521 0 IO-APIC-fasteoi libata, libata, uhci_hcd:usb6 19: 1133 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb7 20: 3 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2, uhci_hcd:usb5 21: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4 223: 871 0 0 0 PCI-MSI-edge eth1 NMI: 0 0 0 0 Non-maskable interrupts LOC: 158448 161871 160140 161074 Local timer interrupts RES: 735 822 1378 1028 Rescheduling interrupts CAL: 3397 ...
We are pleased to announce the next update to our new preempt-rt
series.
- tracing updates (Luis)
- latency histograms (Carsten)
- build warning fixes (Clark)
2.6.29.4-rt17 is the last major update to the 2.6.29 -rt series.
There will be bugfix releases as necessary and eventually an extra
update release once the real hwlat (former SMIdetector) module / tool
is published by JCM aka. Jon "slaCker" Masters.
In the meantime I'm moving on to 30-rt.
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.4-rt17 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.4.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.4-rt17.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
We are pleased to announce the next update to our new preempt-rt
series.
- futex bug fix (tglx)
- hwlat latency detector module (Jon Cool Masters)
I have to say it works pretty well when you call someone a Slacker :)
Clark is working on user space tools which help you to use it w/o
fiddling module parameters. It's going to be in the next rt-tests
release which has a not yet defined schedule. I wonder whether I
should try that slacker trick again :)
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.4-rt18 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.4.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.4-rt18.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
We are pleased to announce the next update to our new preempt-rt
series.
- futex: plug page ref leak (stupid me)
- hwlat: add missing include (ukleinek)
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.4-rt19 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.4.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.4-rt19.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
We are pleased to announce the next update to our new preempt-rt
series.
- update to 2.6.29.5 (2.6.29.5-rt20, which I uploaded yesterday but
did not announce due to the findings below)
- softirq: lower default priority below hardirq default priority
This fixes a long standing default priority configuration problem of
the -rt series. On UP machines this can result in net_tx softirq
running in an endless loop and starving the irq threads and the other
softirq threads and of course everything with lower priority. It might
be possible to happen on a SMP machine when the hardirq thread
affinities are tweaked in the right way.
What happens is:
tx interrupt
lock(card->tx_lock);
dev_kfree_skb_any(skb);
blocks on a contended lock
net_tx softirq runs
unlocks contended lock but does not schedule away due to equal prio
repeat:
calls xmit
try_lock(card->tx_lock) fails
-> reschedule skb which keeps net_tx running
goto repeat;
The scheduler does not schedule away net_tx, so this goes on forever.
This has been there forever, but it seems to be easier to trigger in
the 29 -rt series which is probably due to the slab cache lock breaks
we did.
The problem is restricted to a dozen of wireless adapters and network
cards where e1000e is the most popular one. We could patch the
affected drivers for -rt, but we need to have a closer look at the
general assumptions of drivers vs. hardirq/softirq. Note, this is not
a mainline problem as the semantics are entirely correct there.
Lowering the priorities of the softirq threads below the hardirq
threads priorities is a safe workaround for now. It prevents the
runaway scenario under all circumstances as it resembles the mainline
semantics closely.
For all existing -rt systems the problem can be solved w/o patching
the kernel by adjusting the priority of the softirq threads from the
init scripts with chrt.
It's extremly hard to trigger this, we ...We are pleased to announce the next update to our new preempt-rt
series.
- fix the network live lock issue for real
- disable preemption across iomap atomic section
- indentify false positives in the softirq pending check
in the nohz code.
The network issue which I described in the -21 release still persists
between net-rx and net-tx softirqs. The real fix is replacing the
spin_trylock with spin_lock in the affected drivers.
On -rt we had several unexplained reports of cpus going idle with a
pending softirq. I got hands on a trace of such a situation. What
happens is that a softirq is blocked on a lock which is held by a task
which is either blocked itself or running on another CPU. When there
is no other active task on the CPU then it goes idle but the softirq
pending bit of the blocked softirq thread is still set. This leads to
false positive warnings. To filter out those cases the blocked state
of the softirq needs to be checked instead of printing the warning
blindly.
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.5-rt22 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.5.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.5-rt22.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
--
We are pleased to announce the next update to our new preempt-rt
series.
- update to 2.6.29.6
- compile fixes (Wu Zhangjin)
- powerpc highmem fix
- hwlat smp_processor_id() fix (Carsten)
- ktime_get* speedups (Martin)
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.29.6-rt23 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.29.6.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29.6-rt22.bz2
The broken out patches are also available at the same download
locations.
Enjoy !
tglx
P.S.: 30-rt is coming close and runs the final tests right now
--
I'm getting slightly weird behavior from rt23 in an intel quad core machine (my T61 laptop is fine), rt22 was fine. It is some timer issue, if I type continuously I get (every few seconds) repeated keys. Nothing in the logs, nothing in dmesg that is (significantly) different from an rt22 boot. --
Hmm. The only change which touches timer related stuff is the ktime*
speedups. Can you please apply the revert patch below and check
whether that changes anything? If not, then we need to look at the
2.6.29.5 -> .6 delta.
Thanks,
tglx
-----
diff --git b/kernel/hrtimer.c a/kernel/hrtimer.c
index 93affb0..cb8a15c 100644
--- b/kernel/hrtimer.c
+++ a/kernel/hrtimer.c
@@ -46,6 +46,37 @@
#include <asm/uaccess.h>
+/**
+ * ktime_get - get the monotonic time in ktime_t format
+ *
+ * returns the time in ktime_t format
+ */
+ktime_t ktime_get(void)
+{
+ struct timespec now;
+
+ ktime_get_ts(&now);
+
+ return timespec_to_ktime(now);
+}
+EXPORT_SYMBOL_GPL(ktime_get);
+
+/**
+ * ktime_get_real - get the real (wall-) time in ktime_t format
+ *
+ * returns the time in ktime_t format
+ */
+ktime_t ktime_get_real(void)
+{
+ struct timespec now;
+
+ getnstimeofday(&now);
+
+ return timespec_to_ktime(now);
+}
+
+EXPORT_SYMBOL_GPL(ktime_get_real);
+
/*
* The timer bases:
*
@@ -73,6 +104,31 @@ DEFINE_PER_CPU(struct hrtimer_cpu_base, hrtimer_bases) =
}
};
+/**
+ * ktime_get_ts - get the monotonic clock in timespec format
+ * @ts: pointer to timespec variable
+ *
+ * The function calculates the monotonic clock from the realtime
+ * clock and the wall_to_monotonic offset and stores the result
+ * in normalized timespec format in the variable pointed to by @ts.
+ */
+void ktime_get_ts(struct timespec *ts)
+{
+ struct timespec tomono;
+ unsigned long seq;
+
+ do {
+ seq = read_seqbegin(&xtime_lock);
+ getnstimeofday(ts);
+ tomono = wall_to_monotonic;
+
+ } while (read_seqretry(&xtime_lock, seq));
+
+ set_normalized_timespec(ts, ts->tv_sec + tomono.tv_sec,
+ ts->tv_nsec + tomono.tv_nsec);
+}
+EXPORT_SYMBOL_GPL(ktime_get_ts);
+
/*
* Get the coarse grained time at the softirq based on xtime and
* wall_to_monotonic.
diff --git b/kernel/time/timekeeping.c a/kernel/time/timekeeping.c
index 4c99c98..3192dd0 100644
--- ...The bad behavior is gone with the patch reverted. But life is not so simple :-) I rebooted into the newer kernel and the problem was gone. Then I rebooted into the older (unreverted) kernel and the problem was not there either! Sigh. Then I powered down the machine, powered up in the older kernel and the problem was there. Powered down, powered up in the newer kernel and the problem was gone. Warm boot into the older kernel and the problem is _not_ there. So it would seem there's something getting screwed up at the hardware level that the reverted patch "fixes"... When the problem happens it is very obvious. And also affects the screensaver, of course. I don't see it in my laptop and on another P4 based machine running fc11 (as opposed to fc10 in the others) and a different build. Thanks! -- Fernando --
Remove extra line before EXPORT_SYMBOL_GPL(ktime_get_real); -- JSR --
I am getting the same issue, reliably reproducibly - though ironically only with the proprietary NVIDIA. Key repeats, screen going "No signal" for a sec, sometimes comes back, sometimes hangs the whole machine. This 2nd part (timekeeping.c) of your patch unfortunately does not apply on -rt23, but I have edited it manually to get a result. Works ok so far. (BTW, CONFIG_GENERIC_TIME=y). --
The problem is reproducible on 2.6.31-rc8-rt9. Keys repeat, and the patch for 2.6.31-rt does not want to compile anymore. --
We are pleased to announce the next update to our new preempt-rt
series.
- update to 2.6.31-rc4
This is a major rework of the rt patch series. Thanks to Clark
Williams and John Kacur for providing the merge to 2.6.30 while I was
stabilizing .29-rt. While the 30-rt series looked quite stable, we
decided to skip 30-rt entirely to keep track with the ongoing mainline
development for various reaons. The .31-rt series is planned to be
stabilized as we have done with .29-rt.
The main changes in this release are:
- interrupt threading
interrupt threading is now a pure extension of the mainline
threaded interrupt infrastructure. This reduced the patch size of
the forced irq threading to mere
8 files changed, 178 insertions(+), 13 deletions(-)
Another interesting detail is that the new forced threaded code
uses per device threads instead of per interrupt line threads as
we have done in the past. This was just a logical consequence of
the per device thread (voluntary threading) infrastructure in
mainline and allows us now to share an interrupt line between a
hardirq based handler and a threaded handler device. One use case
which comes to my mind is AT91 which shares the timer and the
serial port interrupt; we now can solve that problem w/o nasty
hacks by requesting a threaded handler for the serial port which
shuts up the serial device interrupt in the hard interrupt handler
part.
- rework of the locking infrastructure
Up to now the -rt patches changed the raw_spinlock_t to
__raw_spinlock_t and added another two levels of underscores to
many of the locking primitives. A compiler trick was used to chose
the implementation for RT=y and RT=n compiles depending on the lock
type in the lock definition.
This is nasty as there is no destinction in the source code which
kind of lock we are dealing with except if one looks up the lock
definition/declaration. It definitely was a ...this change breaks the compilation of the binary nvidia kernel module. in order to build the module, i need to apply the attached patch. best, tim -- tim@klingt.org http://tim.klingt.org Silence is only frightening to people who are compulsively verbalizing. William S. Burroughs
Please report this to nvidia. They have accepted patches in the past for -rt support and have been reasonably easy to work with. -- Darren Hart IBM Linux Technology Center Real-Time Linux Team --
Thomas Gleixner wrote: > We are pleased to announce the next update to our new preempt-rt > series. > > - update to 2.6.31-rc4 > > This is a major rework of the rt patch series. Thanks to Clark > Williams and John Kacur for providing the merge to 2.6.30 while I was > stabilizing .29-rt. While the 30-rt series looked quite stable, we > decided to skip 30-rt entirely to keep track with the ongoing mainline > development for various reaons. The .31-rt series is planned to be > stabilized as we have done with .29-rt. I hit this on boot on an IBM Thinkpad T60p (Intel Core Duo). Haven't had a chance to dig in yet, but wanted to post sooner rather than later. [ 4.764702] Freeing unused kernel memory: 552k freed [ 4.765205] Write protecting the kernel text: 4552k [ 4.765389] Write protecting the kernel read-only data: 1776k [ 4.766458] BUG: sleeping function called from invalid context at kernel/rtmutex.c:684 [ 4.766596] in_atomic(): 1, irqs_disabled(): 0, pid: 103, name: init [ 4.766723] Pid: 103, comm: init Not tainted 2.6.31-rc4-rt1-dvh01 #1 [ 4.766848] Call Trace: [ 4.766973] [<c012d881>] __might_sleep+0xe1/0x100 [ 4.767099] [<c056ccba>] rt_spin_lock+0x2a/0x70 [ 4.767224] [<c018243a>] res_counter_uncharge+0x2a/0x50 [ 4.767350] [<c01e6e23>] __mem_cgroup_uncharge_common+0x93/0x190 [ 4.767477] [<c01e6fb8>] mem_cgroup_uncharge_page+0x28/0x30 [ 4.767604] [<c01d6b87>] page_remove_rmap+0x47/0x50 [ 4.767728] [<c01cf2d9>] unmap_vmas+0x349/0x6b0 [ 4.767852] [<c01d45e5>] exit_mmap+0xc5/0x1c0 [ 4.767977] [<c037d634>] ? get_random_int+0xb4/0xe0 [ 4.768114] [<c0140481>] mmput+0x51/0xc0 [ 4.768237] [<c01ef651>] flush_old_exec+0x381/0x6c0 [ 4.768361] [<c01ea0c6>] ? vfs_read+0x126/0x190 [ 4.768484] [<c01eea3f>] ? kernel_read+0x3f/0x60 [ 4.768609] [<c02228cb>] load_elf_binary+0x33b/0x18c0 [ 4.768734] [<c012f06f>] ? __wake_up+0x3f/0x50 [ 4.768859] [<c01ccfee>] ? kunmap_high+0x7e/0xb0 [ ...
On Thu, 30 Jul 2009 16:20:26 -0700 Ok, here's a traceback I got running 2.6.31-rc4-rt1 on a Lenovo T60 that had been running for a while: BUG: scheduling while atomic: gkrellm/0x00000001/2483, CPU#0 Modules linked in: ati_remote pl2303 usbserial fuse i915 drm i2c_algo_bit sunrpc ipv6 cpufreq_ondemand acpi_cpufreq freq_table loop dm_multipath scsi_dh kvm_intel kvm uinput arc4 ecb iwl3945 btusb iwlcore snd_hda_codec_analog bluetooth snd_hda_intel snd_hda_codec snd_hwdep mac80211 snd_pcm thinkpad_acpi snd_timer hwmon snd cfg80211 soundcore video rfkill iTCO_wdt iTCO_vendor_support sr_mod joydev cdrom ata_generic yenta_socket snd_page_alloc pcspkr i2c_i801 i2c_core output e1000e ata_piix rsrc_nonstatic sg ahci libata sd_mod scsi_mod dm_snapshot dm_zero dm_mirror dm_region_hash dm_log dm_mod uhci_hcd ohci_hcd ssb [last unloaded: microcode] Pid: 2483, comm: gkrellm Not tainted 2.6.31-rc4-rt1 #31 Call Trace: [<ffffffff8105742b>] __schedule_bug+0x97/0x9c [<ffffffff8153856b>] __schedule+0xc7/0x112c [<ffffffff8153c8c6>] ? _atomic_spin_unlock+0x46/0x62 [<ffffffff81539ad5>] schedule+0x1f/0x70 [<ffffffff8153b163>] rt_spin_lock_slowlock+0x313/0x475 [<ffffffff8153c1ed>] rt_spin_lock+0xd4/0xd9 [<ffffffff810c5d6b>] res_counter_uncharge+0x2e/0x53 [<ffffffff8115b1f5>] __mem_cgroup_uncharge_common+0x24e/0x376 [<ffffffff8115b3f7>] mem_cgroup_uncharge_page+0x52/0x54 [<ffffffff8113e9ca>] page_remove_rmap+0x5a/0x7d [<ffffffff8112eb62>] unmap_vmas+0xb0b/0x111b [<ffffffff81112ec0>] ? __alloc_pages_nodemask+0x1ea/0xa16 [<ffffffff81137f16>] unmap_region+0x148/0x294 [<ffffffff81139940>] do_munmap+0x35d/0x3e5 [<ffffffff81139a0e>] sys_munmap+0x46/0x5d [<ffffffff8100cf72>] system_call_fastpath+0x16/0x1b Steven seemed to think that we have a mismatched preempt_disable() and preempt_enable() but I haven't had enough coffee to actually try debugging it. Clark
We (I) can't write to this file :) However, I'll try to attack the remaining bkl that resides in tty... Thanks, --
I took a look at the perms, then the history - looks like you sorted it out. -- Darren Hart IBM Linux Technology Center Real-Time Linux Team --
Yeah, I just had to register. I'm an idiot. --
BUG: scheduling while atomic: kjournald2/0x00000001/1128, CPU#1 Modules linked in: olympic forcedeth rndis_wlan floppy [last unloaded: scsi_wait_scan] Pid: 1128, comm: kjournald2 Tainted: G W 2.6.31-rc4-rt1 #3 Call Trace: [<ffffffff81809a2d>] ? __schedule+0x88/0x76c [<ffffffff8109baca>] ? task_blocks_on_rt_mutex+0x15b/0x1c4 [<ffffffff8180a45b>] ? schedule+0x1a/0x3e [<ffffffff8180b22e>] ? rt_spin_lock_slowlock+0x149/0x21c [<ffffffff810e630d>] ? lock_cpu_pcp+0x4b/0x85 [<ffffffff810e762b>] ? free_hot_cold_page+0x5a/0x216 [<ffffffff8110fe0a>] ? slab_irq_enable+0x9d/0xc1 [<ffffffff81110516>] ? kmem_cache_free+0x42/0xc3 [<ffffffff811df024>] ? jbd2_journal_remove_journal_head+0x2d/0x54 [<ffffffff811dbe56>] ? journal_clean_one_cp_list+0x82/0xed [<ffffffff811dbf0a>] ? __jbd2_journal_clean_checkpoint_list+0x49/0xa0 [<ffffffff811d9e1d>] ? jbd2_journal_commit_transaction+0x2f3/0x125a [<ffffffff8180a162>] ? thread_return+0x51/0xe4 [<ffffffff810884bd>] ? autoremove_wake_function+0x0/0x55 [<ffffffff810797d1>] ? try_to_del_timer_sync+0x59/0x77 [<ffffffff811e00f2>] ? kjournald2+0x106/0x27c [<ffffffff810884bd>] ? autoremove_wake_function+0x0/0x55 [<ffffffff811dffec>] ? kjournald2+0x0/0x27c [<ffffffff8108800e>] ? kthread+0x90/0x98 [<ffffffff8102cf8a>] ? child_rip+0xa/0x20 [<ffffffff81087f7e>] ? kthread+0x0/0x98 [<ffffffff8102cf80>] ? child_rip+0x0/0x20 --
I'm seeing the following if CONFIG_PREEMPT_RT is disabled: Freeing unused kernel memory: 636k freed Write protecting the kernel read-only data: 11512k BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff810b330b>] pagevec_move_tail+0x2b/0x140 PGD 0 Oops: 0000 [#1] SMP last sysfs file: CPU 1 Pid: 1, comm: init Tainted: G W 2.6.31-rc4-rt1tirq #7 IBM eServer BladeCenter LS20 -[885065U]- RIP: 0010:[<ffffffff810b330b>] [<ffffffff810b330b>] pagevec_move_tail+0x2b/0x140 RSP: 0018:ffff880111a818a0 EFLAGS: 00010046 RAX: 0000000000000001 RBX: 0000000000000206 RCX: 0000000000000000 RDX: 0000000003b70630 RSI: 0000000000000000 RDI: ffff880028045c60 RBP: ffff880111a818d0 R08: 0000000000000000 R09: ffff88010f4e3d30 R10: 0000000000000002 R11: 00000000ca416065 R12: 0000000000000000 R13: ffff880028045c60 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880028037000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000010f44c000 CR4: 00000000000006a0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process init (pid: 1, threadinfo ffff880111a80000, task ffff880111a7b770) Stack: ffff88010f44dad8 0000000000000206 0000000000000005 0000000000000001 <0> ffff88010f44dad8 00007fffd7d6a000 ffff880111a81900 ffffffff810b3481 <0> 00000000fffffff4 0000000000001000 00000000fffffff4 00007fffffffe000 Call Trace: [<ffffffff810b3481>] lru_add_drain+0x61/0x80 [<ffffffff810e7547>] setup_arg_pages+0x1b7/0x3b0 [<ffffffff810ea0d5>] ? inode_permission+0x65/0xb0 [<ffffffff8133eb9b>] ? get_random_int+0x5b/0x60 [<ffffffff81122a34>] load_elf_binary+0x4d4/0x1e40 [<ffffffff810ab276>] ? generic_file_aio_read+0x5e6/0x640 [<ffffffff810e1b51>] ? do_sync_read+0xf1/0x130 [<ffffffff812d3d11>] ? strrchr+0x11/0x30 [<ffffffff81120530>] ? load_misc_binary+0x80/0x3d0 [<ffffffff810e620f>] ...
Hi, I am seeing below kernel panic on 8 way Intel and 4 way AMD blades. Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: init Not tainted 2.6.31-rc4-rt1-autotest #1 Call Trace: [<ffffffff8104c887>] panic+0xc1/0x171 [<ffffffff8104ec9a>] ? put_files_struct+0xc3/0xe6 [<ffffffff81394313>] ? rt_write_unlock+0x1c/0x32 [<ffffffff810582fd>] ? exit_ptrace+0xab/0x130 [<ffffffff81394313>] ? rt_write_unlock+0x1c/0x32 [<ffffffff810500af>] do_exit+0x88/0x726 [<ffffffff810507d5>] do_group_exit+0x88/0xbb [<ffffffff8105082d>] sys_exit_group+0x25/0x3d [<ffffffff8100be2b>] system_call_fastpath+0x16/0x1b Thanks, Gowri --
On Wed, 05 Aug 2009 11:36:03 +0530 Gowri, Would you post your .config so we can see what options you have enabled? Clark
Hi Clark, Thanks for the attention. I just looked at error message before the trace I posted. setuproot: moving /dev failed: No such file or directory no fstab.sys, mounting internal defaults setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory Switching to new root and running init. unmounting old /dev unmounting old /proc unmounting old /sys switchroot: mount failed: No such file or directory Only if I set CONFIG_SYSFS_DEPRECATED_V2=y, I could successfully boot which I have tested with this kernel in same system. Is it not set by default from 2.6.31 onwards ? Thanks, --
On Thu, 06 Aug 2009 12:16:15 +0530 I wasn't sure when it would move from 'y' to 'n', but looks like .31 is it. You'll need that option back on for booting on RHEL (since the boot infrastructure uses the old /sys format) but I don't think you'll need it for Fedora. Not sure about SLERT. Bet Greg Haskins would know though :) Clark
The default 'n' works fine for Fedora 10 and Fedora 11. --
You need it Y to boot on SLES 10 / SLERT 10 file systems. Its ok with 'N' on openSUSE 10.3 or later. --
Thanks Clark! Yes, Fedora 10 (or 11) might have updated mkinitrd as in https://bugzilla.redhat.com/show_bug.cgi?id=489151 , if I am right! Regards, --
I'm unable to do a clean build of this on powerpc64. Related to changes in the locking code, I'm sure. I've spent some time poking at this, but it's not something I think I will be able to figure out short-term. Suggestions are welcomed. :-) I can share my .config if requested, but I suspect the problem will be obvious to someone more familiar with the spinlock changes. The build error: /test/willschm/linux-2.6.31-rtx/kernel/spinlock.c: In function ‘_atomic_spin_lock’: /test/willschm/linux-2.6.31-rtx/kernel/spinlock.c:103: error: implicit declaration of function ‘_raw_atomic_spin_trylock’ /test/willschm/linux-2.6.31-rtx/kernel/spinlock.c:103: error: implicit declaration of function ‘_raw_atomic_spin_relax’ I can't find the definitions for ‘_raw_atomic_spin_trylock’ or ‘_raw_atomic_spin_relax’ with any of my grepping either, for any of the architectures. I suspect this ties back into the CONFIG_GENERIC_LOCKBREAK being defined, or not being defined for the architecture. (It's on for Power, not on for x86). With lots of code trimmed, the relevant code appears to be (in kernel/spinlock.c) : #if !defined(CONFIG_GENERIC_LOCKBREAK) || defined(CONFIG_DEBUG_LOCK_ALLOC) ... #else BUILD_LOCK_OPS(atomic_spin, atomic_spinlock); /* line 103*/ #fi As an experiment, I did force the CONFIG_GENERIC_LOCKBREAK option off and built successfully, but my system turns into a doorstop during very early boot, down the find_legacy_serial_ports() path, eventually ending up stuck in _atomic_spin_lock()->debug_smp_processor_id(). This is before the early console or xmon itself has gone through setup, so not a lot of debug options.. :-o :-) Thanks, --
Fix below. Thanks,
tglx
-------
commit ffc969930727238b847176c203bdbe1f9dffe403
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Tue Aug 11 20:03:47 2009 +0200
locks: Fix PREEMPT=y, LOCKBREAK=y, DEBUG_LOCK_ALLOC=n compile
Should be folded back into the atomic lock conversion
Reported-by: Will Schmidt <will_schmidt@vnet.ibm.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
diff --git a/kernel/lock-internals.h b/kernel/lock-internals.h
index 4f0bc8b..76f694c 100644
--- a/kernel/lock-internals.h
+++ b/kernel/lock-internals.h
@@ -9,8 +9,8 @@
* (We do this in a function because inlining it would be excessive.)
*/
-#define BUILD_LOCK_OPS(op, locktype) \
-void __lockfunc _##op##_lock(locktype##_t *lock) \
+#define BUILD_LOCK_OPS(prefix, op, locktype) \
+void __lockfunc _##prefix##_lock(locktype##_t *lock) \
{ \
for (;;) { \
preempt_disable(); \
@@ -20,15 +20,15 @@ void __lockfunc _##op##_lock(locktype##_t *lock) \
\
if (!(lock)->break_lock) \
(lock)->break_lock = 1; \
- while (!op##_can_lock(lock) && (lock)->break_lock) \
+ while (!prefix##_can_lock(lock) && (lock)->break_lock) \
_raw_##op##_relax(&lock->raw_lock); \
} \
(lock)->break_lock = 0; \
} \
\
-EXPORT_SYMBOL(_##op##_lock); \
+EXPORT_SYMBOL(_##prefix##_lock); \
\
-unsigned long __lockfunc _##op##_lock_irqsave(locktype##_t *lock) \
+unsigned long __lockfunc _##prefix##_lock_irqsave(locktype##_t *lock) \
{ \
unsigned long flags; \
\
@@ -42,23 +42,23 @@ unsigned long __lockfunc _##op##_lock_irqsave(locktype##_t *lock) \
\
if (!(lock)->break_lock) \
(lock)->break_lock = 1; \
- while (!op##_can_lock(lock) && (lock)->break_lock) \
+ while (!prefix##_can_lock(lock) && (lock)->break_lock) \
_raw_##op##_relax(&lock->raw_lock); \
} \
(lock)->break_lock = 0; \
return ...Thanks Thomas,
Still doesn't boot, but after turning on every spinlock and early
debug option I could find I have some more data. :-)
The .find_legacy_serial_ports function in the backtrace is very very
early during boot. I'll do a bit more looking around to see if it's
anything obvious,..
Thanks,
-Will
-----><-----
Found initrd at 0xc000000003b00000:0xc000000003c8d000
-> pSeries_init_early()
-> fw_cmo_feature_init()
CMO_PageSize = 4096
CMO not enabled, PrPSP=-1, SecPSP=-1
<- fw_cmo_feature_init()
<- pSeries_init_early()
=============================================
[ INFO: possible recursive locking detected ]
2.6.31-rc4-rt1-wms.aug12 #2
---------------------------------------------
swapper/0 is trying to acquire lock:
(devtree_lock){......}, at: [<c0000000006683fc>] .of_find_property+0x78/0x140
but task is already holding lock:
(devtree_lock){......}, at: [<c0000000006694f0>] .of_find_compatible_node+0x48/0x158
other info that might help us debug this:
1 lock held by swapper/0:
#0: (devtree_lock){......}, at: [<c0000000006694f0>] ...Will,
I almost expected some wreckage from converting a rwlock to a
spinlock. Grr. That code really takes the lock recursive. None of my
powerpc systems triggered that code path. :(
So the reason for having a rwlock was not the concurrent access, it
was just the lazy^W reuse of the existing functions which lead to
recursive locking.
As it's the only code in tree which would need the real rwlock version
I fixed up the of code instead of creating all the extra rwlock
functions for rt.
Does the patch below fix it ?
Thanks,
tglx
-----
commit 925df9b36dc9abe0bab32cbd2ac544d773da71ff
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Thu Aug 13 09:04:10 2009 +0200
OF: Fixup resursive locking code paths
The conversion of devtree_lock from rwlock to spinlock unearthed
recursive locking pathes. Instead of going down the hassle of having
an atomic_rwlock implementation fixup the code pathes to avoid the
recursive locking.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 26f4a62..3626e37 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -59,16 +59,14 @@ int of_n_size_cells(struct device_node *np)
}
EXPORT_SYMBOL(of_n_size_cells);
-struct property *of_find_property(const struct device_node *np,
- const char *name,
- int *lenp)
+static struct property *__of_find_property(const struct device_node *np,
+ const char *name, int *lenp)
{
struct property *pp;
if (!np)
return NULL;
- atomic_spin_lock(&devtree_lock);
for (pp = np->properties; pp != 0; pp = pp->next) {
if (of_prop_cmp(pp->name, name) == 0) {
if (lenp != 0)
@@ -76,6 +74,18 @@ struct property *of_find_property(const struct device_node *np,
break;
}
}
+
+ return pp;
+}
+
+struct property *of_find_property(const struct device_node *np,
+ const char *name,
+ int *lenp)
+{
+ struct property ...Yes, and thanks for spinning that up for me.
With this patch, the reported problem is cleared up.. :-) Now I'm
getting as far as finding the other processors in the system before it
stops. :-(
Last output on the console is
"
...
clockevent: decrementer mult[83126e97] shift[32] cpu[3]
Processor 3 found.
clockevent: decrementer mult[83126e97] shift[32] cpu[4]
Processor 4 found.
"
Some other info is in the log_buf, I got this via xmon dump, and parsed
it by hand, try to ignore the extra spaces.. :-)
<7>xics: map virq 16, hwi rq 0x2.
<7>irq: i rq 2 on host nul l mapped to virt ual irq 16.
<7>xi cs: unmask virq 16.
<7> -> map to hwirq 0x2.
<6>Te sting tracer nop : PASSED.
<7>cloc kevent: decremen ter mult[83126e9 7] shift[32] cpu [1].
<4>Processor 1 found..
<7>clo ckevent: decreme nter mult[83126e 97] shift[32] cp u[2].
<4>Processo r 2 found..
<7>cl ockevent: decrem enter mult[83126 e97] shift[32] c pu[3].
<4>Process or 3 found..
<7>c lockevent: decre menter mult[8312 6e97] shift[32] cpu[4].
<4>Proces sor 4 found..
<4> .
<4>============ ================ =====.
<4>[ INFO: inconsistent lo ck state ].
<4>2. 6.31-rc4-rt1-wms .aug12 #3.
<4>--- ---------------- --------------.
< 4>inconsistent { HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage..
<4>irq/16 -IPI/3 [HC1[1]:S C0[0]:HE0:SE1] t akes:.
<4> (devtr ee_lock){?.+...} , at: [
<c0000000 006684f8>] .of_f ind_property+0x4 c/0x9c.
<4>{HARDI RQ-ON-W} state w as registered at :.
<4> [
<c000000 000119090>] .__l ock_acquire+0x69 8/0x900.
<4> [
<c 00000000011a3ec> ] .lock_acquire+ 0x144/0x194.
<4> [
<c0000000007ac 7d8>] ._atomic_s pin_lock+0x58/0x 84.
<4> [
<c00000 0000668dfc>] .of _find_node_by_na me+0x40/0x110.
<4 > [
<c0000000005 0d320>] .hvc_fin d_vtys+0x128/0x1 68.
<4> [
<c00000 0000b78c68>] .co nsole_init+0x50/ 0x7c.
<4> [
<c000 000000b34d70>] . start_kernel+0x3 40/0x59c.
<4> [
< c0000000000083d8 >] .start_here_c ommon+0x1c/0x44.
<4>irq event sta mp: 9532942.
<4>h ardirqs last en abled at (953294 1): ...On Thu, 30 Jul 2009 02:48:04 +0200 (CEST) I searched the mails in this chain, but did not find the following BUG reported yet. I hit this once while booting up. INIT: version 2.86 bootingBUG: unable to handle kernel NULL pointer dereference at 0000000000000024 IP: [<ffffffff81050fe6>] try_to_wake_up+0x3b/0x2e2 PGD 0 Oops: 0000 [#1] PREEMPT SMP last sysfs file: /sys/block/sda/dev CPU 5 Modules linked in: dm_region_hash dm_log dm_mod ata_piix libata shpchp mptsas mptscsih mptbase scsi_transport_sas sd_mod scsi_mod crc_t10dif ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd Pid: 0, comm: swapper Not tainted 2.6.31-rc4-rt1 #1 IBM eServer BladeCenter HS21 -[7995AAA]- RIP: 0010:[<ffffffff81050fe6>] [<ffffffff81050fe6>] try_to_wake_up+0x3b/0x2e2 RSP: 0018:ffff880028199e38 EFLAGS: 00010082 RAX: 0000000000000000 RBX: 000000000000001e RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000000 RBP: ffff880028199e88 R08: b000000000000000 R09: 0000000000000001 R10: 0000000000000001 R11: 017dbbb7ec537836 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880028196000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000000000024 CR3: 0000000001001000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 0, threadinfo ffff88022f342000, task ffff88022f340000) Stack: ffffffff810bd00b 00000000ec537836 ffffffff81619840 ffff88022c58e640 <0> 017dbbb7ec537836 ffffffff81619840 ffff88022c58e640 0000000000000001 <0> 0000000000000004 0000000000000000 ffff880028199ea8 ffffffff810513fb Call Trace: <IRQ> [<ffffffff810bd00b>] ? handle_edge_irq+0x35/0x13d [<ffffffff810513fb>] wake_up_process+0x2a/0x40 [<ffffffff810baf12>] handle_IRQ_event+0x169/0x1a1 [<ffffffff810bd0b7>] handle_edge_irq+0xe1/0x13d [<ffffffff8100f031>] ...
I hit this occasionally as well. -- -- Darren Hart IBM Linux Technology Center Real-Time Linux Team --
Here come a few that fix stuff for ARM. Expect some more later. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | --
This was missed in commit
fd2bde5 (genirq: Convert irqdesc lock to atomic_spinlock)
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
arch/arm/include/asm/mach/irq.h | 4 ++--
mm/highmem.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/mach/irq.h b/arch/arm/include/asm/mach/irq.h
index acac530..3981cf2 100644
--- a/arch/arm/include/asm/mach/irq.h
+++ b/arch/arm/include/asm/mach/irq.h
@@ -26,9 +26,9 @@ extern int show_fiq_list(struct seq_file *, void *);
*/
#define do_bad_IRQ(irq,desc) \
do { \
- spin_lock(&desc->lock); \
+ atomic_spin_lock(&desc->lock); \
handle_bad_irq(irq, desc); \
- spin_unlock(&desc->lock); \
+ atomic_spin_unlock(&desc->lock); \
} while(0)
#endif
diff --git a/mm/highmem.c b/mm/highmem.c
index 66e915a..214eefd 100644
--- a/mm/highmem.c
+++ b/mm/highmem.c
@@ -372,8 +372,8 @@ void *kmap_high_get(struct page *page)
lock_kmap_any(flags);
vaddr = (unsigned long)page_address(page);
if (vaddr) {
- BUG_ON(pkmap_count[PKMAP_NR(vaddr)] < 1);
- pkmap_count[PKMAP_NR(vaddr)]++;
+ BUG_ON(atomic_read(&pkmap_count[PKMAP_NR(vaddr)]) < 1);
+ atomic_add(1, pkmap_count[PKMAP_NR(vaddr)]);
}
unlock_kmap_any(flags);
return (void*) vaddr;
--
1.6.3.3
--
ups, this hunk doesn't belong here. I will follow up with a corrected patch. Sorry Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | --
This was missed in commit
fd2bde5 (genirq: Convert irqdesc lock to atomic_spinlock)
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
arch/arm/include/asm/mach/irq.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/mach/irq.h b/arch/arm/include/asm/mach/irq.h
index acac530..3981cf2 100644
--- a/arch/arm/include/asm/mach/irq.h
+++ b/arch/arm/include/asm/mach/irq.h
@@ -26,9 +26,9 @@ extern int show_fiq_list(struct seq_file *, void *);
*/
#define do_bad_IRQ(irq,desc) \
do { \
- spin_lock(&desc->lock); \
+ atomic_spin_lock(&desc->lock); \
handle_bad_irq(irq, desc); \
- spin_unlock(&desc->lock); \
+ atomic_spin_unlock(&desc->lock); \
} while(0)
#endif
--
1.6.3.3
--
This fixes the following error: CC drivers/mfd/ucb1x00-core.o drivers/mfd/ucb1x00-core.c: In function 'ucb1x00_adc_enable': drivers/mfd/ucb1x00-core.c:138: error: implicit declaration of function 'down' drivers/mfd/ucb1x00-core.c: In function 'ucb1x00_adc_disable': drivers/mfd/ucb1x00-core.c:196: error: implicit declaration of function 'up' drivers/mfd/ucb1x00-core.c: In function 'ucb1x00_probe': drivers/mfd/ucb1x00-core.c:500: error: implicit declaration of function 'sema_init' Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: linux-kernel@vger.kernel.org --- Hello, should this better be converted to mutex_lock/mutex_unlock? Best regards Uwe --- drivers/mfd/ucb1x00-core.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mfd/ucb1x00-core.c b/drivers/mfd/ucb1x00-core.c index fea9085..3c59c26 100644 --- a/drivers/mfd/ucb1x00-core.c +++ b/drivers/mfd/ucb1x00-core.c @@ -24,6 +24,7 @@ #include <linux/interrupt.h> #include <linux/device.h> #include <linux/mutex.h> +#include <linux/semaphore.h> #include <mach/dma.h> #include <mach/hardware.h> -- 1.6.3.3 --
This fixes a build warning for 2.6.31-rc5 (ARCH=arm, ixp2000_defconfig):
CC arch/arm/mach-ixp2000/core.o
arch/arm/mach-ixp2000/core.c:217: warning: initialization from incompatible pointer type
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Dmitry Baryshkov <dbaryshkov@gmail.com>
---
arch/arm/mach-ixp2000/core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-ixp2000/core.c b/arch/arm/mach-ixp2000/core.c
index babb225..e24e3d0 100644
--- a/arch/arm/mach-ixp2000/core.c
+++ b/arch/arm/mach-ixp2000/core.c
@@ -197,7 +197,7 @@ unsigned long ixp2000_gettimeoffset (void)
return offset / ticks_per_usec;
}
-static int ixp2000_timer_interrupt(int irq, void *dev_id)
+static irqreturn_t ixp2000_timer_interrupt(int irq, void *dev_id)
{
/* clear timer 1 */
ixp2000_reg_wrb(IXP2000_T1_CLR, 1);
--
1.6.3.3
--
This fixes a a build failure for 2.6.31-rc4-rt1 (ARCH=arm, msm_defconfig): CC arch/arm/mach-msm/proc_comm.o /ptx/work/octopus/WORK_2_A/ukl/gsrc/linux-2.6/arch/arm/mach-msm/proc_comm.c:43: error: expected '=', ',', ';', 'asm' or '__attribute__' before '__cacheline_aligned_in_smp' /ptx/work/octopus/WORK_2_A/ukl/gsrc/linux-2.6/arch/arm/mach-msm/proc_comm.c: In function 'msm_proc_comm': /ptx/work/octopus/WORK_2_A/ukl/gsrc/linux-2.6/arch/arm/mach-msm/proc_comm.c:76: error: 'proc_comm_lock' undeclared (first use in this function) /ptx/work/octopus/WORK_2_A/ukl/gsrc/linux-2.6/arch/arm/mach-msm/proc_comm.c:76: error: (Each undeclared identifier is reported only once /ptx/work/octopus/WORK_2_A/ukl/gsrc/linux-2.6/arch/arm/mach-msm/proc_comm.c:76: error: for each function it appears in.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Russell King <linux@arm.linux.org.uk> Cc: Brian Swetland <swetland@google.com> --- arch/arm/mach-msm/proc_comm.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-msm/proc_comm.c b/arch/arm/mach-msm/proc_comm.c index 915ee70..e825c36 100644 --- a/arch/arm/mach-msm/proc_comm.c +++ b/arch/arm/mach-msm/proc_comm.c @@ -14,6 +14,7 @@ * */ +#include <linux/cache.h> #include <linux/delay.h> #include <linux/errno.h> #include <linux/io.h> -- 1.6.3.3 --
This fixes a build failure for 2.6.31-rc4-rt1 (ARCH=arm, s3c2410_defconfig): CC [M] sound/soc/s3c24xx/s3c2443-ac97.o sound/soc/s3c24xx/s3c2443-ac97.c:50: warning: type defaults to 'int' in declaration of 'DECLARE_MUTEX' sound/soc/s3c24xx/s3c2443-ac97.c:50: warning: parameter names (without types) in function declaration sound/soc/s3c24xx/s3c2443-ac97.c: In function 's3c2443_ac97_read': sound/soc/s3c24xx/s3c2443-ac97.c:59: error: 'ac97_mutex' undeclared (first use in this function) sound/soc/s3c24xx/s3c2443-ac97.c:59: error: (Each undeclared identifier is reported only once sound/soc/s3c24xx/s3c2443-ac97.c:59: error: for each function it appears in.) sound/soc/s3c24xx/s3c2443-ac97.c: In function 's3c2443_ac97_write': sound/soc/s3c24xx/s3c2443-ac97.c:93: error: 'ac97_mutex' undeclared (first use in this function) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Takashi Iwai <tiwai@suse.de> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Timur Tabi <timur@freescale.com> Cc: Eric Miao <eric.miao@marvell.com> Cc: alsa-devel@alsa-project.org Cc: linux-kernel@vger.kernel.org --- sound/soc/s3c24xx/s3c2443-ac97.c | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/sound/soc/s3c24xx/s3c2443-ac97.c b/sound/soc/s3c24xx/s3c2443-ac97.c index 3f03d5d..bf16f20 100644 --- a/sound/soc/s3c24xx/s3c2443-ac97.c +++ b/sound/soc/s3c24xx/s3c2443-ac97.c @@ -47,7 +47,7 @@ static struct s3c24xx_ac97_info s3c24xx_ac97; static DECLARE_COMPLETION(ac97_completion); static u32 codec_ready; -static DECLARE_MUTEX(ac97_mutex); +static DEFINE_MUTEX(ac97_mutex); static unsigned short s3c2443_ac97_read(struct snd_ac97 *ac97, unsigned short reg) @@ -56,7 +56,7 @@ static unsigned short s3c2443_ac97_read(struct snd_ac97 *ac97, u32 ac_codec_cmd; u32 stat, addr, data; ...
This fixes a a build failure for 2.6.31-rc4-rt1 (ARCH=arm, davinci_all_defconfig): drivers/watchdog/davinci_wdt.c: In function 'wdt_enable': drivers/watchdog/davinci_wdt.c:102: error: 'CLOCK_TICK_RATE' undeclared (first use in this function) drivers/watchdog/davinci_wdt.c:102: error: (Each undeclared identifier is reported only once drivers/watchdog/davinci_wdt.c:102: error: for each function it appears in.) Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Wim Van Sebroeck <wim@iguana.be> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.arm.linux.org.uk --- drivers/watchdog/davinci_wdt.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/watchdog/davinci_wdt.c b/drivers/watchdog/davinci_wdt.c index 83e22e7..4a136d7 100644 --- a/drivers/watchdog/davinci_wdt.c +++ b/drivers/watchdog/davinci_wdt.c @@ -26,6 +26,8 @@ #include <linux/io.h> #include <linux/device.h> +#include <mach/timex.h> + #define MODULE_NAME "DAVINCI-WDT: " #define DEFAULT_HEARTBEAT 60 -- 1.6.3.3 --
The two commits b38cb5a (mm: remove kmap_lock) and 3297e76 (highmem: atomic highmem kmap page pinning) conflict (without causing a text based conflict) because the latter introduces a usage of kmap_lock. The actual compiler output is (e.g. for ARCH=arm, stmp378x_defconfig): CC mm/highmem.o mm/highmem.c: In function 'pkmap_try_free': mm/highmem.c:116: warning: unused variable 'addr' mm/highmem.c: In function 'kmap_high_get': mm/highmem.c:372: error: 'kmap_lock' undeclared (first use in this function) mm/highmem.c:372: error: (Each undeclared identifier is reported only once mm/highmem.c:372: error: for each function it appears in.) mm/highmem.c:375: error: invalid operands to binary < (have 'atomic_t' and 'int') mm/highmem.c:376: error: wrong type argument to increment The problems in lines 116 and 375f are resolved by the patch below, but I don't know highmem enough to fix the remaining error. Moreover I don't have a machine that makes use of highmem. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Nicolas Pitre <nico@marvell.com> Cc: MinChan Kim <minchan.kim@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Li Zefan <lizf@cn.fujitsu.com> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org --- mm/highmem.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/mm/highmem.c b/mm/highmem.c index 66e915a..4aa9eea 100644 --- a/mm/highmem.c +++ b/mm/highmem.c @@ -113,10 +113,10 @@ static int pkmap_try_free(int pos) */ if (!pte_none(pkmap_page_table[pos])) { struct page *page = pte_page(pkmap_page_table[pos]); - unsigned long addr = PKMAP_ADDR(pos); pte_t *ptep = &pkmap_page_table[pos]; - VM_BUG_ON(addr != (unsigned long)page_address(page)); + VM_BUG_ON((unsigned long)PKMAP_ADDR(pos) != + (unsigned ...
This fixes the build failure with ARCH_NEEDS_KMAP_HIGH_GET. This is only compile tested. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Nicolas Pitre <nico@marvell.com> Cc: MinChan Kim <minchan.kim@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Li Zefan <lizf@cn.fujitsu.com> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org --- Hello this bases on the patch "[PATCH RT 9/6] [RFH] Build failure on 2.6.31-rc4-rt1 in mm/highmem.c" earlier in this thread. I don't know if kmap_high_get() has to call kmap_account(). Anyone? As I don't have any knowledge about highmem (or mm in general) I'll go into hiding before tglx caughts me with his trout. Best regards Uwe mm/highmem.c | 79 ++++++++++++++++++++------------------------------------- 1 files changed, 28 insertions(+), 51 deletions(-) diff --git a/mm/highmem.c b/mm/highmem.c index 4aa9eea..b5f5faf 100644 --- a/mm/highmem.c +++ b/mm/highmem.c @@ -75,26 +75,6 @@ pte_t * pkmap_page_table; static DECLARE_WAIT_QUEUE_HEAD(pkmap_wait); - -/* - * Most architectures have no use for kmap_high_get(), so let's abstract - * the disabling of IRQ out of the locking in that case to save on a - * potential useless overhead. - */ -#ifdef ARCH_NEEDS_KMAP_HIGH_GET -#define lock_kmap() spin_lock_irq(&kmap_lock) -#define unlock_kmap() spin_unlock_irq(&kmap_lock) -#define lock_kmap_any(flags) spin_lock_irqsave(&kmap_lock, flags) -#define unlock_kmap_any(flags) spin_unlock_irqrestore(&kmap_lock, flags) -#else -#define lock_kmap() spin_lock(&kmap_lock) -#define unlock_kmap() spin_unlock(&kmap_lock) -#define lock_kmap_any(flags) \ - do { spin_lock(&kmap_lock); (void)(flags); } while (0) -#define unlock_kmap_any(flags) \ - do { spin_unlock(&kmap_lock); (void)(flags); } ...
I think it should, since it uses kunmap_high() to undo whatever
kmap_high_get() did. Now, if there'd been a kmap_high_put()... :-)
it has one, whereas the result of your patch seems to be that it'll
actually create one if its not found.
Something like the below ought to do I guess.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
arch/arm/include/asm/highmem.h | 1 +
arch/arm/mm/dma-mapping.c | 2 +-
mm/highmem.c | 50 ++++++++++++++++++---------------------
3 files changed, 25 insertions(+), 28 deletions(-)
diff --git a/arch/arm/include/asm/highmem.h b/arch/arm/include/asm/highmem.h
index 7f36d00..4d9573b 100644
--- a/arch/arm/include/asm/highmem.h
+++ b/arch/arm/include/asm/highmem.h
@@ -19,6 +19,7 @@ extern pte_t *pkmap_page_table;
extern void *kmap_high(struct page *page);
extern void *kmap_high_get(struct page *page);
+extern void *kmap_high_put(struct page *page);
extern void kunmap_high(struct page *page);
extern void *kmap(struct page *page);
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 1576176..4a166d9 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -551,7 +551,7 @@ static void dma_cache_maint_contiguous(struct page *page, unsigned long offset,
if (vaddr) {
vaddr += offset;
inner_op(vaddr, vaddr + size);
- kunmap_high(page);
+ kmap_high_put(page);
}
}
diff --git a/mm/highmem.c b/mm/highmem.c
index 66e915a..b2eaefe 100644
--- a/mm/highmem.c
+++ b/mm/highmem.c
@@ -75,26 +75,6 @@ pte_t * pkmap_page_table;
static DECLARE_WAIT_QUEUE_HEAD(pkmap_wait);
-
-/*
- * Most architectures have no use for kmap_high_get(), so let's abstract
- * the disabling of IRQ out of the locking in that case to save on a
- * potential useless overhead.
- */
-#ifdef ARCH_NEEDS_KMAP_HIGH_GET
-#define lock_kmap() spin_lock_irq(&kmap_lock)
-#define unlock_kmap() spin_unlock_irq(&kmap_lock)
-#define lock_kmap_any(flags) ...I don't have enough context to review this patch, but your understanding of the kmap_high_get() purpose is right. Nicolas --
Hello, ... on irc Peter and me agreed it's not that wrong :-) Anyhow, I merged The patch with all it's dependencies based on -rc6 is available on git://git.pengutronix.de/git/ukl/linux-2.6.git kmap-testing Niko: Your review would be very welcome because neither Peter nor me have a machine with highmem. Best regards Uwe From fafb2e9964cd01535a61f20a45093ba053169f06 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Uwe=20Kleine-K=C3=B6nig?= <u.kleine-koenig@pengutronix.de> Date: Fri, 14 Aug 2009 21:45:55 +0200 Subject: [PATCH] Fix kmap_high_get() as kmap locking is gone MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit This has the pros of both Peter's and my patch: - It obsoletes ARCH_NEEDS_KMAP_HIGH_GET without introducing a big overhead for the archs not having defined that symbol. - no code duplication between kmap_high_get and kmap_high - a nice kmap_high_put function that does the same as kunmap_high without accounting - no compiler warning about mismatched declarations Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Nicolas Pitre <nico@marvell.com> Cc: MinChan Kim <minchan.kim@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Li Zefan <lizf@cn.fujitsu.com> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org --- arch/arm/include/asm/highmem.h | 3 +- arch/arm/mm/dma-mapping.c | 2 +- mm/highmem.c | 98 +++++++++++++++++----------------------- 3 files changed, 43 insertions(+), 60 deletions(-) diff --git a/arch/arm/include/asm/highmem.h b/arch/arm/include/asm/highmem.h index 7f36d00..2082ed8 100644 --- a/arch/arm/include/asm/highmem.h +++ b/arch/arm/include/asm/highmem.h @@ -15,10 +15,9 @@ extern pte_t *pkmap_page_table; -#define ARCH_NEEDS_KMAP_HIGH_GET - extern void ...
It should not be using CLOCK_TICK_RATE - there was a move to clean up the use of that symbol and restrict it just to the i8253 PIT. Please create something else like DAVINCI_TICK_RATE instead. --
Actually, I have an alternate fix for this which I was planning to
submit for 2.6.32. This one drops CLOCK_TICK_RATE and uses the clock
framework to get the right tick frequency.
Here it is.
Kevin
From 6eea62609126739ce03e447c5fca49269ad5d12a Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@deeprootsystems.com>
Date: Tue, 10 Feb 2009 20:30:37 -0800
Subject: [PATCH] watchdog: davinci: use clock framework for timer frequency
Remove use of CLOCK_TICK_RATE in favor of using clock framework
for getting timer frequency.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
drivers/watchdog/davinci_wdt.c | 21 +++++++++++++++++++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/davinci_wdt.c b/drivers/watchdog/davinci_wdt.c
index 83e22e7..5ed89e4 100644
--- a/drivers/watchdog/davinci_wdt.c
+++ b/drivers/watchdog/davinci_wdt.c
@@ -25,6 +25,7 @@
#include <linux/uaccess.h>
#include <linux/io.h>
#include <linux/device.h>
+#include <linux/clk.h>
#define MODULE_NAME "DAVINCI-WDT: "
@@ -69,6 +70,7 @@ static unsigned long wdt_status;
static struct resource *wdt_mem;
static void __iomem *wdt_base;
+struct clk *wdt_clk;
static void wdt_service(void)
{
@@ -86,6 +88,10 @@ static void wdt_enable(void)
{
u32 tgcr;
u32 timer_margin;
+ u32 wdt_freq;
+
+ BUG_ON(!wdt_clk);
+ wdt_freq = clk_get_rate(wdt_clk);
spin_lock(&io_lock);
@@ -99,9 +105,9 @@ static void wdt_enable(void)
iowrite32(0, wdt_base + TIM12);
iowrite32(0, wdt_base + TIM34);
/* set timeout period */
- timer_margin = (((u64)heartbeat * CLOCK_TICK_RATE) & 0xffffffff);
+ timer_margin = (((u64)heartbeat * wdt_freq) & 0xffffffff);
iowrite32(timer_margin, wdt_base + PRD12);
- timer_margin = (((u64)heartbeat * CLOCK_TICK_RATE) >> 32);
+ timer_margin = (((u64)heartbeat * wdt_freq) >> 32);
iowrite32(timer_margin, wdt_base + PRD34);
/* enable run continuously */
iowrite32(ENAMODE12_PERIODIC, wdt_base + ...if (WARN_ON(IS_ERR(wdt_clk))) --
Updated version:
From c7b99413b5323a5f7faa00e86d623b0711fcd0d0 Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@deeprootsystems.com>
Date: Tue, 10 Feb 2009 20:30:37 -0800
Subject: [PATCH] watchdog: davinci: use clock framework for timer frequency
Remove use of CLOCK_TICK_RATE in favor of using clock framework
for getting timer frequency.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
drivers/watchdog/davinci_wdt.c | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/davinci_wdt.c b/drivers/watchdog/davinci_wdt.c
index 83e22e7..43c42f5 100644
--- a/drivers/watchdog/davinci_wdt.c
+++ b/drivers/watchdog/davinci_wdt.c
@@ -25,6 +25,7 @@
#include <linux/uaccess.h>
#include <linux/io.h>
#include <linux/device.h>
+#include <linux/clk.h>
#define MODULE_NAME "DAVINCI-WDT: "
@@ -69,6 +70,7 @@ static unsigned long wdt_status;
static struct resource *wdt_mem;
static void __iomem *wdt_base;
+struct clk *wdt_clk;
static void wdt_service(void)
{
@@ -86,6 +88,9 @@ static void wdt_enable(void)
{
u32 tgcr;
u32 timer_margin;
+ u32 wdt_freq;
+
+ wdt_freq = clk_get_rate(wdt_clk);
spin_lock(&io_lock);
@@ -99,9 +104,9 @@ static void wdt_enable(void)
iowrite32(0, wdt_base + TIM12);
iowrite32(0, wdt_base + TIM34);
/* set timeout period */
- timer_margin = (((u64)heartbeat * CLOCK_TICK_RATE) & 0xffffffff);
+ timer_margin = (((u64)heartbeat * wdt_freq) & 0xffffffff);
iowrite32(timer_margin, wdt_base + PRD12);
- timer_margin = (((u64)heartbeat * CLOCK_TICK_RATE) >> 32);
+ timer_margin = (((u64)heartbeat * wdt_freq) >> 32);
iowrite32(timer_margin, wdt_base + PRD34);
/* enable run continuously */
iowrite32(ENAMODE12_PERIODIC, wdt_base + TCR);
@@ -199,6 +204,12 @@ static int __devinit davinci_wdt_probe(struct platform_device *pdev)
struct resource *res;
struct device *dev = &pdev->dev;
+ wdt_clk = clk_get(dev, NULL);
+ if ...Much better - and only a minor nit which doesn't deserve a repost - wdt_freq should probably match the return type of clk_get_rate. IOW unsigned long. --
Wim, If you're OK with this, can you queue this one for 2.6.32? Thanks, Kevin --
I'm also OK with this. I'll queue it up in my -next tree today or tomorrow. Kind regards, Wim. --
This fixes a a build failure for 2.6.31-rc4-rt1 (ARCH=arm, mv78xx0_defconfig and others): mm/bounce.c: In function 'bounce_copy_vec': mm/bounce.c:52: error: implicit declaration of function 'local_irq_save_nort' mm/bounce.c:56: error: implicit declaration of function 'local_irq_restore_nort' Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Li Zefan <lizf@cn.fujitsu.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.arm.linux.org.uk --- mm/bounce.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/mm/bounce.c b/mm/bounce.c index 2fd099c..4a91eed 100644 --- a/mm/bounce.c +++ b/mm/bounce.c @@ -13,6 +13,7 @@ #include <linux/init.h> #include <linux/hash.h> #include <linux/highmem.h> +#include <linux/interrupt.h> #include <asm/tlbflush.h> #include <trace/events/block.h> -- 1.6.3.3 --
We are pleased to announce the next update to our new preempt-rt
series.
- update to 2.6.31-rc6
- ARM updates (Uwe Kleine-Koenig)
- OF fixes
- threaded interrupt crash fix (Linus)
- locking build fix
- minor fixes all over the place
There is a known boot problem on PSeries machines which is still
investigated by Will. If you have access to such a beast please help
to get this decoded.
I have not merged one of the proposed fixed for the ARM highmem
problem. We really want someone with such a hardware to have a look
and confirm the fix.
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Git release branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/2.6.31-rc6
Git development branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/head
Gitweb:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=rt/2.6.31...
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.31-rc6-rt2 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.tar.bz2
http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.31-rc6.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.31-rc6-rt2.bz2
Thanks to Clark and John for collecting patches and providing updated
trees while I was on vacation.
Enjoy !
tglx
--
We are pleased to announce the next update to our new preempt-rt
series.
[ I skipped -rt3 as it failed in testing ]
- update to the ONESHOT irq infrastructure scheduled for mainline
- scheduling while atomic fix in tty_ldisc
The know problems (PSeries / ARM highmem) still persist and we have a
new one which is related to cgroup memcontrol. The latter one is easy
to fix but will have to wait for the next release.
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Git release branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/2.6.31-rc6
Git development branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/head
Gitweb:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=rt/2.6.31...
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.31-rc6-rt4 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.tar.bz2
http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.31-rc6.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.31-rc6-rt4.bz2
Enjoy !
tglx
--
We are pleased to announce the next update to our new preempt-rt
series.
- update to Linus' latest
- Fixed the Pseries mystery: missed to exclude per cpu timers from
forced threading so the IPI handlers got threaded
- cgroup memcontrol preemption problem fixed
So the only known remaining one is ARM highmem
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Git release branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/2.6.31-rc6
Git development branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/head
Gitweb:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=rt/2.6.31...
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.31-rc6-rt5 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.tar.bz2
http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.31-rc6.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.31-rc6-rt5.bz2
Enjoy !
tglx
--
Hey Thomas, Peter, Ingo,
I'm still seeing the odd SMP scheduler behavior (where all the
processes line up on a single cpu) with -rt5. This can be easily
reproduced with a "make -j8 bzImage". I'm I the only one seeing this?
Any suggestions on further debugging this?
thanks
-john
--
I am seeing it with 2.6.31-rcX-rtY kernels on both a 8 CPU AMD/Intel box Specjbb was returning pathetically low numbers which turns out to be because all threads are running on just one of the cpus --
We are pleased to announce the next update to our new preempt-rt
series.
- update to Linus' latest
- load accounting/balancing fix (peterz)
As last time ARM highmem remains as unresolved.
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Git release branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/2.6.31-rc6
Git development branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/head
Gitweb:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=rt/2.6.31...
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.31-rc6-rt6 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.tar.bz2
http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.31-rc6.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.31-rc6-rt6.bz2
Enjoy !
tglx
--
We are pleased to announce the next update to our new preempt-rt
series.
- update to Linus' latest
- perf counter crash fix (peterz)
- disabled MARKERS on RT. Code with no use(rs) which just causes
trouble.
- edge irq forced threading fix. Fixes the IDE "interrupt lost"
reports
Known issues:
- ARM highmem
- scheduler load balancing oddities. Peter is working on it.
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Git release branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/2.6.31
Git development branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/head
Gitweb:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=rt/2.6.31
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.31-rc7-rt8 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.tar.bz2
http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.31-rc7.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.31-rc7-rt8.bz2
Enjoy !
tglx
--
Hi Thomas, Here's one more atomic_spin_lock conversion for a driver update that went in for -rc7. Kevin From 4faf27a4c0ceaddd7cb13f5d11928babc9c4cddc Mon Sep 17 00:00:00 2001 From: Kevin Hilman <khilman@deeprootsystems.com> Date: Thu, 27 Aug 2009 13:51:47 +0300 Subject: [PATCH -rt] MFD: twl4030: convert irq_desc lock to atomic spinlock Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> --- drivers/mfd/twl4030-irq.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c index 7d43083..c1bc157 100644 --- a/drivers/mfd/twl4030-irq.c +++ b/drivers/mfd/twl4030-irq.c @@ -458,12 +458,12 @@ static void twl4030_sih_do_edge(struct work_struct *work) bytes[byte] &= ~(0x03 << off); - spin_lock_irq(&d->lock); + atomic_spin_lock_irq(&d->lock); if (d->status & IRQ_TYPE_EDGE_RISING) bytes[byte] |= BIT(off + 1); if (d->status & IRQ_TYPE_EDGE_FALLING) bytes[byte] |= BIT(off + 0); - spin_unlock_irq(&d->lock); + atomic_spin_unlock_irq(&d->lock); edge_change &= ~BIT(i); } -- 1.6.4 --
We are pleased to announce the next update to our new preempt-rt
series.
- update to Linus' latest
- more perf counters rt education
- !RT build fix (jstultz)
- MFD rt fix (khilman)
Known issues:
- ARM highmem
- scheduler load balancing oddities. Peter is working on it.
- latency tracer oddities (latency tracers in combination with
events). Steven is working on those
Give it a good testing. We aim for releasing a stable .31-rt in less
than 24 hrs after Linus releases .31 :)
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Git release branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/2.6.31
Git development branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/head
Gitweb:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=rt/2.6.31
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.31-rc8-rt9 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.tar.bz2
http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.31-rc8.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.31-rc8-rt9.bz2
Enjoy !
tglx
--
We are pleased to announce the next update to our new preempt-rt
series.
- update to 2.6.31
- timekeeping 32bit overflow fix
- rt locking fix for rw_locks and rwsems. Solves a kvm crash
- kvm might sleep warning fix
- remove empty cpumask warning in x86(32bit) IPI code
- tracer fixes - picked from mainline
- perf counter fix - picked from mainline
Known issues:
- ARM highmem
- scheduler load balancing oddities. Peter is working on it.
- timer_interrupt hang check (fix queued for .31-rt11)
Pending updates:
- I'm planning to add back MIPS support in the .31-rt11 release.
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Git release branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/2.6.31
Git development branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/head
Gitweb:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=rt/2.6.31
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.31-rt10 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.31.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.31-rt10.bz2
Enjoy !
tglx
--
Oops, forgot to mention that the latency histograms are back. Thanks to Carsten Emde for keeping up with the ongoing changes in the tracer infrastructure. tglx --
We are pleased to announce the next update to our new preempt-rt
series.
- latencytop fix
- disable SPARSE_IRQ, DMAR, IRQ_REMAP for -rt
Known issues:
- ARM highmem
- scheduler load balancing oddities. Peter is working on it.
- timer_interrupt hang check (still working on somthing useful)
The planned "add back MIPS support" is postponed to rt12.
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Git release branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/2.6.31
Git development branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/head
Gitweb:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=rt/2.6.31
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.31-rt11 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.31.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.31-rt11.bz2
Enjoy !
tglx
--
Great work Tom. I am very glad to see -rt branch in -tip tree. When -rt will hit linus tree, .33 or .34 ? Thanks, -- JSR --
Note, Thomas is German, not American. German's do not shorten their We're working on it. But don't expect it that early. Our estimate is the same as we've said for the last 5 years. "It will be in next year". -- Steve --
Hello Steve, Thanks for clarification. Now I understood why he started unnecessary wars and his funny actions(shouts when need to stay mum and stay mum Great. -- JSR --
On Sep 19, 2009, at 10:01, Jaswinder Singh Rajput I hope you realize that this is in no way funny or amusing. I wouldn't normally make a deal out of it, but what you just said is offensive toward Thomas and you should apologize. Think before making such comments please - I bet you've never met Thomas, for if you had you'd know he's one of the nicest people around. That he is German should have no bearing and such comments are outmoded and wrong. Jon. --
Hitting a repeating BUG at boot on my Thinkpad T60p: [ 2.861699] BUG: sleeping function called from invalid context at kernel/rtmutex.c:684 [ 2.861839] in_atomic(): 1, irqs_disabled(): 0, pid: 777, name: sleep [ 2.861967] Pid: 777, comm: sleep Not tainted 2.6.31-rc4-rt1-dvh01 #1 [ 2.862092] Call Trace: [ 2.862217] [<c012d881>] __might_sleep+0xe1/0x100 [ 2.862343] [<c056ccba>] rt_spin_lock+0x2a/0x70 [ 2.862468] [<c018243a>] res_counter_uncharge+0x2a/0x50 [ 2.862593] [<c01e6e23>] __mem_cgroup_uncharge_common+0x93/0x190 [ 2.862720] [<c01e6fb8>] mem_cgroup_uncharge_page+0x28/0x30 [ 2.862845] [<c01d6b87>] page_remove_rmap+0x47/0x50 [ 2.862969] [<c01cf2d9>] unmap_vmas+0x349/0x6b0 [ 2.863093] [<c01d45e5>] exit_mmap+0xc5/0x1c0 [ 2.863217] [<c0140481>] mmput+0x51/0xc0 [ 2.863339] [<c0146465>] exit_mm+0x105/0x140 [ 2.863462] [<c01465b5>] do_exit+0x115/0x760 [ 2.863584] [<c0146cc4>] sys_exit+0x14/0x20 [ 2.863707] [<c0103025>] syscall_call+0x7/0xb I'm looking for a problem with preempt_disable() between LinuxCon seesions now. But if someone already knows the problem, thought I'd post. Thanks, -- Darren Hart IBM Linux Technology Center Real-Time Linux Team --
On Tue, 22 Sep 2009 11:31:51 -0700 I saw that (or something very similar) on my T60 a couple of versions back but thought it got fixed. Send me your .config, will you? Clark
Ugh, nevermind, this was an -rc4 kernel. 2.6.31-rt11 does not see this problem. -- Darren Hart IBM Linux Technology Center Real-Time Linux Team --
Do you have any reports that there is a bug in the SPARSE_IRQ code or why did you disable it? Thanks, Jan --
Sparse irq is allocating memory in irq/preempt disabled regions which makes preempt debug pretty unhappy. It needs some restructuring of that code. dmar and irqremap have the same problem. Thanks, tglx
Is this with the patch I sent on Aug 31: [PATCH] Allocate memory before disabling memory in irq_to_desc_alloc_node() Thanks, Jan --
Just a light workload and a couple boot tests so far, 2.6.31-rt11 appears to be running good on my powerpc64 systems. (power6 JS22 blades). Thanks. :-) --
We are pleased to announce the next update to our new preempt-rt
series.
- Forward to 2.6.31.2
- Futex fix
- iptables fix
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Git release branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/2.6.31
Git development branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/head
Gitweb:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=rt/2.6.31
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.31.2-rt13 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.31.2.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.31.2-rt13.bz2
Enjoy !
tglx
--
Hi Thomas, Great! But I was wondering if you missed this one: http://patchwork.kernel.org/patch/50044/ Remy --
Yup, slipped through. Queued for the next release. Thanks, tglx --
Correction. I dropped the patch as it is just a sloppy work around.
Why creating the thread in the first place ? Real fix below.
Thanks,
tglx
---
diff --git a/kernel/softirq.c b/kernel/softirq.c
index aae8d45..3526976 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -1161,6 +1161,8 @@ static int __cpuinit cpu_callback(struct notifier_block *nfb,
per_cpu(ksoftirqd, hotcpu)[i].tsk = NULL;
}
for (i = 0; i < NR_SOFTIRQS; i++) {
+ if (!softirq_names[i])
+ continue;
p = kthread_create(ksoftirqd,
&per_cpu(ksoftirqd, hotcpu)[i],
"sirq-%s/%d", softirq_names[i],
@@ -1177,8 +1179,11 @@ static int __cpuinit cpu_callback(struct notifier_block *nfb,
break;
case CPU_ONLINE:
case CPU_ONLINE_FROZEN:
- for (i = 0; i < NR_SOFTIRQS; i++)
- wake_up_process(per_cpu(ksoftirqd, hotcpu)[i].tsk);
+ for (i = 0; i < NR_SOFTIRQS; i++) {
+ p = per_cpu(ksoftirqd, hotcpu)[i].tsk;
+ if (p)
+ wake_up_process(p);
+ }
break;
#ifdef CONFIG_HOTPLUG_CPU
case CPU_UP_CANCELED:
@@ -1192,9 +1197,11 @@ static int __cpuinit cpu_callback(struct notifier_block *nfb,
for (i = 0; i < NR_SOFTIRQS; i++) {
param.sched_priority = MAX_RT_PRIO-1;
p = per_cpu(ksoftirqd, hotcpu)[i].tsk;
- sched_setscheduler(p, SCHED_FIFO, &param);
- per_cpu(ksoftirqd, hotcpu)[i].tsk = NULL;
- kthread_stop(p);
+ if (p) {
+ sched_setscheduler(p, SCHED_FIFO, &param);
+ per_cpu(ksoftirqd, hotcpu)[i].tsk = NULL;
+ kthread_stop(p);
+ }
}
takeover_tasklets(hotcpu);
break;
--
But I did not do this because I thought this was sloppy as well, I guessed you would never accept a patch that only looks at defining the name, how wrong could I be... ;-) So, going for the cleaner solution, I was going for not defining the HRTIMER_SOFTIRQ in the enum in include/linux/interrupt.h in the first place, but that would touch even more code, and at least that makes clear how much the code is strangled. The loop 'for (i = 0; i < NR_SOFTIRQS; i++)' is used at many more places, would this 'if (!softirq_names[i])' not be required at other places as well? Remy --
Hi Thomas, Well, I noticed a few minutes ago that the sirq-hrtimer is periodically being scheduled (every 50msec here) It does not do much, but it still it does something... (no idea what though) So, is it really right to prevent it from starting up? Remy --
Yeah, noticed as well. It's due to the deferred handling of signal Nope. We just name it unconditionally :) Thanks, tglx --
We are pleased to announce the next update to our new preempt-rt
series.
- Forward to 2.6.31.4
- Handle futex spurious wakeups
- slab fixes for NUMA (peterz)
The slab problem is still not completely resolved. It's hard to
reproduce and was only seen on Nehalem dual socket systems so far. If
you have such a machine you might help providing a back trace, just run
while true; do hackbench N; done
until it explodes. Adjust N to your system, the larger the
better. Make sure you have a serial console to capture the oops.
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Git release branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/2.6.31
Git development branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/head
Gitweb:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=rt/2.6.31
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.31.4-rt14 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.31.4.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.31.4-rt14.bz2
Enjoy !
tglx
--
Could some guru rebase to 2.6.31.5 please? I get two failed chunks in kernel/futex.c Would be appreciated... --
tip/rt/2.6.31 [1] is at v2.6.31.5-rt16 (but untagged). You might get kernel/futex.c from there. I assume -rt16 isn't released yet as there is no tag. Best regards Uwe [1] http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=refs/head... -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | --
Thanks! I managed to get a package done for it and I'm running it, so far so good. Do you know why it has not been officially released yet? Anything I should watch out for? -- Fernando --
Simply because I did not come around as I'm swamped with my mail backlog. :(
tglxGreat! Thanks for the heads up.... -- Fernando --
B1;2005;0cWe are pleased to announce the next update to our new preempt-rt
series.
- forward to 2.6.31.5
- scheduler improvements (peterz, dino)
- various security fixes
- tracer enhancements (carsten)
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Git release branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/2.6.31
Git development branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/head
Gitweb:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=rt/2.6.31
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.31.5-rt17 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.31.5.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.31.5-rt17.bz2
Enjoy !
tglx
--
We are pleased to announce the next update to our new preempt-rt
series.
- forward to 2.6.31.6
- Add missing preemption point in ksoftirqd (Jupyung Lee)
Download locations:
http://rt.et.redhat.com/download/
http://www.kernel.org/pub/linux/kernel/projects/rt/
Git release branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/2.6.31
Git development branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/head
Gitweb:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=rt/2.6.31
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
to build the 2.6.31.6-rt19 tree, the following patches should be
applied:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.31.6.tar.bz2
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.31.6-rt19.bz2
Enjoy !
tglx
--
We are pleased to announce the next update to our new preempt-rt
series.
- forward to 2.6.31.12
- large number of RCU assumption fixes vs. cred and tasklist_lock
- Priority Inheritance POSIX compliance fix
- workaround for Priority Protection POSIX compliance problem
- misc. fixlets here and there
It took quite a while to get this update out for various reasons:
- mainline merge of the locking infrastructure changes which are a
further milestone on the way to full rt integration. That merge
will shave off a large portion of the rt patch (don't worry, we
have enough new and exiting stuff in the pipeline to keep the
patch size large enough)
- fixing RCU assumptions in mainline and backport to 31-rt
- lots of brain twisting around the POSIX scheduling policy
compliance problems which got reported vs. Priority
Inheritance/Protection
- an extended christmas break and the resulting email backlog
- our new housemate: http://tglx.de/~tglx/housemate.png
Further plans:
- a last big feature for 31-rt is pending, which is worth a separate
release: Nick Piggins VFS scalability patches. I'm still running
tests on that, so no promise.
- I'm going to switch 31-rt into maintaince mode (with or without
the VFS patches) and concentrate on getting .33-rcX-rt out. Yes,
there will be no .32-rt. The reason is simply that the locking
changes which got merged into .33 are making my life easier and
are the base to sort out more ready for the mainline stuff.
Download locations:
http://rt.et.redhat.com/download/ (temporary out of sync)
http://www.kernel.org/pub/linux/kernel/projects/rt/
Git release branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/2.6.31
Git development branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/head
Gitweb:
...Hello, I have done build tests for ARCH=arm on 2.6.31.12-rt20 and to fix most platforms I needed to cherry pick three commits from post-2.6.31 mainline: 9fd868f ([WATCHDOG] davinci: use clock framework for timer frequency) b9696ea (net: Fix IXP 2000 network driver building.) 0bfb34f (ARM: S3C2440: mini2440: Fix missing CONFIG_S3C_DEV_USB_HOST) (One of these fails to cleanly apply on top of 2.6.31.12-rt20 so I made them available at git://git.pengutronix.de/git/ukl/linux-2.6.git rt/arm based on tip/rt/arm). Then there is a problem with highmem (only on ARM). A fix was discussed already earlier, but as there havn't been anyone volunteering to test it, Thomas didn't take it. As I don't have a machine needing highmem I cannot test either. So I just resend it as it changed slightly since the last post to keep it in the archives (or for the case Thomas wants to take it now). It's available at git://git.pengutronix.de/git/ukl/linux-2.6.git rt/highmemfix basing on the oldest commit having v2.6.31.7~101 and a7a08ef below .31.12-rt20. I'll send it as a reply to this mail, too. This only leaves a single defconfig broken that I havn't investigated yet. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | --
This obsoletes ARCH_NEEDS_KMAP_HIGH_GET without introducing a big
overhead for the archs not having defined that symbol and removes some
duplicated code previously found in kmap_high_get and kmap_high.
Before this patch three ARM defconfigs (namely cm_x300, mv78xx0 and
stmp378x) failed to compile as the part protected by
ARCH_NEEDS_KMAP_HIGH_GET wasn't adapted by commit
b38cb5a (mm: remove kmap_lock)
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
arch/arm/include/asm/highmem.h | 3 +-
arch/arm/mm/dma-mapping.c | 2 +-
mm/highmem.c | 89 ++++++++++++++++------------------------
3 files changed, 38 insertions(+), 56 deletions(-)
diff --git a/arch/arm/include/asm/highmem.h b/arch/arm/include/asm/highmem.h
index 7f36d00..2082ed8 100644
--- a/arch/arm/include/asm/highmem.h
+++ b/arch/arm/include/asm/highmem.h
@@ -15,10 +15,9 @@
extern pte_t *pkmap_page_table;
-#define ARCH_NEEDS_KMAP_HIGH_GET
-
extern void *kmap_high(struct page *page);
extern void *kmap_high_get(struct page *page);
+extern void kmap_high_put(struct page *page);
extern void kunmap_high(struct page *page);
extern void *kmap(struct page *page);
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 1576176..4a166d9 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -551,7 +551,7 @@ static void dma_cache_maint_contiguous(struct page *page, unsigned long offset,
if (vaddr) {
vaddr += offset;
inner_op(vaddr, vaddr + size);
- kunmap_high(page);
+ kmap_high_put(page);
}
}
diff --git a/mm/highmem.c b/mm/highmem.c
index 446b75c..a3dd375 100644
--- a/mm/highmem.c
+++ b/mm/highmem.c
@@ -75,26 +75,6 @@ pte_t * pkmap_page_table;
static DECLARE_WAIT_QUEUE_HEAD(pkmap_wait);
-
-/*
- * Most architectures have no use for kmap_high_get(), so let's ...I have a hard time to see, why these patches fix most
No, I don't. Thanks,
tglx
Hello Thomas, That's right. The more exact wording is: After cherry picking these most platforms (i.e. 133/137) compile without error. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | --
We are pleased to announce the next update to our new preempt-rt
series.
- fixes and cherry-picks all over the place
- tracer fixes from Carsten
Short log of the changes since v2.6.31.12-rt20
bfbf2bf: v2.6.31.12-rt21
16e4137: tracing: Include zero offset in timer histogram
75df1a4: tracing: Do not assume shared prio in latency histogram
5f18c0d: sched: Run task on same cpu if idle and allowed
e4ab2c9: tracing: Abort wakeup hist if task already running
49cf381: tracing: Abort wakeup tracer if task already running
91b077f: tracing: Fix taskstates in sched_switch trace
27d8f71: mutex: Move in_interrupt() debug code
2309ca6: lockdep: Fix LOCKDEP=N compile of no_validate class
68fd52c: lockdep: Add novalidate class for dev->mutex
e99b72b: sched: Don't use possibly stale sched_class
449c496: tracing: fix transposed numbers of lock_depth and preempt_count
3862a7e: futex: Handle futex value corruption gracefully
b9be6de: futex: Handle user space corruption gracefully
eb9a3d2: futex_lock_pi() key refcnt fix
54afa95: futexes: Remove rw parameter from get_futex_key()
365db4e: bkl: Fix fatfingered irq_enable logic
86f64b7: rework-hrtimer_offset-hist.patch
005ab8c: [WATCHDOG] davinci: use clock framework for timer frequency
05a3118: net: Fix IXP 2000 network driver building.
3e786b2: ARM: S3C2440: mini2440: Fix missing CONFIG_S3C_DEV_USB_HOST
This is (hopefully) the last release in the 31-rt series.
Download locations:
http://rt.et.redhat.com/download/ (temporary out of sync)
http://www.kernel.org/pub/linux/kernel/projects/rt/
Git release branch:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/2.6.31
Gitweb:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.git;a=shortlog;h=rt/2.6.31
Information on the RT patch can be found at:
http://rt.wiki.kernel.org/index.php/Main_Page
...Hello Thomas, Thank you for this announce. I just put this new version into the Gentoo Pro-Audio overlay, which is thus now available for Gentoo users. Kind regards, Xavier. --
We are pleased to announce the next update to our new preempt-rt
series.
- Forward to 2.6.33-rc8
Finally I managed to get that beast tamed.
Some folks were already joking, that my dog ate the 33-rt patch. The
truth is that my reject fixup skills were one line off in the mm/*
code which resulted in -rt eating my files :)
When I fixed the wreckage of my own stupidty I found out that -rt
triggered a nasty and hard to reproduce mainline scheduler bug, which
refused to reproduce with kernel tracing enabled. Thanks to Peter
Zijlstra for helping me to decode the initial mainline problem and the
ones which resulted from fixing the mainline bug!
It's all fixed now and I'm pretty happy about the state of this
release with the following exceptions:
1) it is only runtime tested on x86_64 (compiles on x86_32, arm,
powerpc_32/64).
I'm going to throw it at my testing infrastructure tomorrow, but I
wanted to release this before .33-final and of course you folks
are heartely invited to help out with fixing the fallout :)
2) I broke the histogram tracer stuff simply because I got lost in
the divergence of -rt and mainline kernel/trace/* changes
I apologize to Carsten, but I'm sure he will fix that in no time
as usual
The current state of the patch on x86_64 is: rock stable!
[rt-tests]# chrt -f 1 ./cyclictest -t -a -n -d0 -p80 -i125
policy: fifo: loadavg: 509.19 490.53 486.66 364/1055 31899
T: 0 (27682) P:80 I:125 C:1170997397 Min: 2 Act: 3 Avg: 3 Max: 34
T: 1 (27683) P:79 I:125 C:1170997397 Min: 2 Act: 3 Avg: 3 Max: 34
That's an uptime of ~1.6 days with a load of hackbench, recursive
grep and extensive networking traffic going on.
The merge of the spinlock namespace cleanup and the initial
annotations took a big chunk away from the -rt patch size:
patch-2.6.31.12-rt21.patch 1680354
patch-2.6.33-rc8.patch 1179390
patch-2.6.33-rc8+git.patch 1067064
We are zooming in, but ...Woohoo! More -rt fun. Unfortunately, I can't log in on my T500 with this kernel though. The following shows-up on my serial console. ------------[ cut here ]------------ WARNING: at /home/jkacur/rt.linux.git/net/mac80211/rx.c:2467 ieee80211_rx+0x4c/0 x721 [mac80211]() Hardware name: 2241B48 Modules linked in: bridge stp bnep sco btusb l2cap crc16 bluetooth sunrpc ipt_RE JECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT xt_tc pudp nf_conntrack_ipv6 xt_state ip6table_filter ip6_tables x_tables ipv6 cpufreq _ondemand acpi_cpufreq ext3 jbd mbcache dm_mirror dm_region_hash dm_log dm_multi path scsi_dh dm_mod kvm_intel kvm uinput arc4 ecb snd_hda_codec_conexant iwlagn snd_hda_intel iwlcore snd_hda_codec snd_hwdep snd_seq_dummy mac80211 snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss thinkpad_ac pi snd_pcm firewire_ohci firewire_core hwmon video ppdev tpm_tis cfg80211 sr_mod battery wmi ricoh_mmc parport_pc sg tpm cdrom tpm_bios button ac ata_generic e1 000e iTCO_wdt snd_timer sdhci_pci pata_acpi sdhci i2c_i801 i2c_core parport mmc_ core iTCO_vendor_support snd joydev snd_page_alloc pcspkr intel_agp soundcore cr c_itu_t rfkill output ahci libata sd_mod scsi_mod crc_t10dif xfs exportfs uhci_h cd ohci_hcd ehci_hcd [last unloaded: microcode] Pid: 10, comm: sirq-tasklet/0 Not tainted 2.6.33-rc8-rt1-debug #1 Call Trace: [<ffffffffa033524f>] ? ieee80211_rx+0x4c/0x721 [mac80211] [<ffffffff81041f25>] warn_slowpath_common+0x77/0xa4 [<ffffffff81041f61>] warn_slowpath_null+0xf/0x11 [<ffffffffa033524f>] ieee80211_rx+0x4c/0x721 [mac80211] [<ffffffffa039f380>] ? iwl_led_pattern+0x17a/0x189 [iwlcore] [<ffffffff810c0fd1>] ? free_compound_page+0x16/0x18 [<ffffffffa039f3f5>] ? iwl_leds_background+0x66/0x219 [iwlcore] [<ffffffffa0393524>] iwl_rx_reply_rx+0xc29/0xc5a [iwlcore] [<ffffffff8106ee74>] ? trace_hardirqs_on+0xd/0xf [<ffffffff8135cf7e>] ? _raw_spin_unlock_irqrestore+0x4c/0x68 [<ffffffff811b4e32>] ? unmap_single+0x27/0x4f ...
Fix below. Thanks,
tglx
----
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 82a30c1..e735c17 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2464,7 +2464,7 @@ void ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb)
struct ieee80211_supported_band *sband;
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
- WARN_ON_ONCE(softirq_count() == 0);
+ WARN_ON_ONCE_NONRT(softirq_count() == 0);
if (WARN_ON(status->band < 0 ||
status->band >= IEEE80211_NUM_BANDS))
--
Thanks Thomas That patch fixes the symptom I reported, but unfortunately, I still can't log-in to my laptop without the machine freezing. Not sure why, investigating. John --
On Mon, Feb 22, 2010 at 01:23:33PM +0100, John Kacur wrote: | On Mon, Feb 22, 2010 at 12:28 PM, Thomas Gleixner <tglx@linutronix.de> wrote: | > On Mon, 22 Feb 2010, John Kacur wrote: | >> On Mon, Feb 22, 2010 at 12:24 AM, Thomas Gleixner <tglx@linutronix.de> wrote: | >> > We are zooming in, but there is still a way to go! | >> > | >> | >> Woohoo! More -rt fun. | >> | >> Unfortunately, I can't log in on my T500 with this kernel though. | >> The following shows-up on my serial console. | >> ------------[ cut here ]------------ | >> WARNING: at /home/jkacur/rt.linux.git/net/mac80211/rx.c:2467 ieee80211_rx+0x4c/0 | >> x721 [mac80211]() | > | > Fix below. Thanks, | > | > tglx | > ---- | > diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c | > index 82a30c1..e735c17 100644 | > --- a/net/mac80211/rx.c | > +++ b/net/mac80211/rx.c | > @@ -2464,7 +2464,7 @@ void ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb) | > struct ieee80211_supported_band *sband; | > struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb); | > | > - WARN_ON_ONCE(softirq_count() == 0); | > + WARN_ON_ONCE_NONRT(softirq_count() == 0); | > | > if (WARN_ON(status->band < 0 || | > status->band >= IEEE80211_NUM_BANDS)) | > -- | | Thanks Thomas | | That patch fixes the symptom I reported, but unfortunately, I still | can't log-in to my laptop without the machine freezing. | Not sure why, investigating. John, I have a similar issue. But I suspect it may be KMS related (I had a similar issue on the early 2.6.31-rt days). I also noticed that the keyboard is kinda crazy (echoing a lot) on console. As soon as I have more results I will post them here. Luis -- [ Luis Claudio R. Goncalves Red Hat - Realtime Team ] [ Fingerprint: 4FDD B8C4 3C59 34BD 8BE9 2696 7203 D980 A448 C8F8 ] --
Found it, at least it make my mouse/keyboard work again and fixes the
weird double character problem on VT login.
Thanks,
tglx
----
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 25642d1..1efad98 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -563,15 +563,20 @@ irq_wait_for_interrupt(struct irq_desc *desc, struct irqaction *action)
* handler finished. unmask if the interrupt has not been disabled and
* is marked MASKED.
*/
-static void irq_finalize_oneshot(unsigned int irq, struct irq_desc *desc)
+static void irq_finalize_oneshot(unsigned int irq, struct irq_desc *desc,
+ struct irqaction *action)
{
chip_bus_lock(irq, desc);
+#ifndef CONFIG_PREEMPT_RT
raw_spin_lock_irq(&desc->lock);
if (!(desc->status & IRQ_DISABLED) && (desc->status & IRQ_MASKED)) {
desc->status &= ~IRQ_MASKED;
desc->chip->unmask(irq);
}
raw_spin_unlock_irq(&desc->lock);
+#else
+ preempt_hardirq_thread_done(desc, action);
+#endif
chip_bus_sync_unlock(irq, desc);
}
@@ -645,7 +650,7 @@ static int irq_thread(void *data)
action->thread_fn(action->irq, action->dev_id);
if (oneshot)
- irq_finalize_oneshot(action->irq, desc);
+ irq_finalize_oneshot(action->irq, desc, action);
}
wake = atomic_dec_and_test(&desc->threads_active);
--
Thanks Thomas The fix seems to work for me. I've got some other issues, but for now I'm going to assume they are the same acpi problems I have reported to lkml for the "vanilla" -rc8 John --
Sorry, spoke to soon, graphical login still freezing. I did nohz=off and nmi_watchdog=2 as you told me in the irc session, and got a nice oops, here it is. ------------[ cut here ]------------ Kernel BUG at ffffffff81045d73 [verbose debug info unavailable] invalid opcode: 0000 [#1] PREEMPT SMP last sysfs file: /sys/class/power_supply/BAT0/energy_full CPU 0 Pid: 3467, comm: firefox-bin Tainted: G D 2.6.33-rc8-rt1-debug #2 2241B4 8/2241B48 RIP: 0010:[<ffffffff81045d73>] [<ffffffff81045d73>] do_exit+0x776/0x784 RSP: 0018:ffff88002be06e28 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000003 RDI: ffff880115638000 RBP: ffff88002be06e98 R08: 0000000000000002 R09: 0000000000000001 R10: 0000000000000002 R11: 0000000000000046 R12: ffff88002be06e48 R13: ffff8801157fd200 R14: ffff88011546d080 R15: ffff8801157fd4c0 FS: 0000000000000000(0000) GS:ffff88002be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b CR2: 00000034e64a7ce0 CR3: 0000000139bd3000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process firefox-bin (pid: 3467, threadinfo ffff880115638000, task ffff8801157fd2 00) Stack: 0000000081602f00 ffffffff8135cf95 ffff8801157fd4c0 ffff8801157fd1f0 <0> ffff88002be06e48 ffff88002be06e48 ffff88002bfcbb20 0000000000000001 <0> 0000000000000007 ffffffff811aca40 0000000000000046 ffff88002be06f58 Call Trace: <NMI> [<ffffffff8135cf95>] ? _raw_spin_unlock_irqrestore+0x63/0x68 [<ffffffff811aca40>] ? delay_tsc+0x6/0xc6 [<ffffffff8135e31f>] die_nmi+0xef/0xf8 [<ffffffff8135e971>] nmi_watchdog_tick+0x159/0x1d6 [<ffffffff8135de29>] do_nmi+0xc2/0x28a [<ffffffff8135d86a>] nmi+0x1a/0x2c [<ffffffff811aca40>] ? delay_tsc+0x6/0xc6 <<EOE>> [<ffffffff811ac9d5>] __delay+0xa/0xc [<ffffffff811b0d50>] do_raw_spin_lock+0xde/0x146 [<ffffffff8135ce39>] ...
Dear Thomas, This is a report about booting test with linux-2.6.33.rc8-rt1 by Thomas. I also can't boot linux-2.6.33.rc8-rt1 version on my desktop pc like John Kacur. But, This Error message is different in my case. So, I returned linux version from this version to linux-2.6.31-rt14 version now. - version info : Linux-2.6.33.rc8-rt1 - H/W Spec : intel Core2Quad Q9400 , SATA HDD320G I uploaded screenshot about booting error on my Q9400 based desktop pc. http://picasaweb.google.com/leemgs/LinuxRelatedScreenshot#5441436536331947314 And, I attached my config file to compile linux-2.6.33.rc8-rt1. Regards, Geunsik Lim. -- Regards, GeunSik Lim ( Samsung Electronics ) Blog : http://blog.naver.com/invain/ e-Mail: geunsik.lim@samsung.com leemgs@gmail.com , leemgs1@gmail.com --
Hi GeunSik, Try the latest tip/rt/head and it should now be fixed up! Thanks, -- Dhaval --
On Wed, Feb 24, 2010 at 10:19 AM, Dhaval Giani Thank you for your opinion to test with recent version. So, I tried linux-2.6.33-rc8-rt1 based on tip/rt/head as you explained. Git development branch: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git rt/head Unfortunately, The result is same. I am testing this kernel on Q9400/Q6600. I uploaded screenshot to share booting error on my desktop pc(Intel Core2 Quad Q6600) http://picasaweb.google.com/leemgs/LinuxRelatedScreenshot#5441820350816247458 So, I returned linux version to linux-2.6.29-rt14 as previously. -- Regards, GeunSik Lim ( Samsung Electronics ) Blog : http://blog.naver.com/invain/ e-Mail: geunsik.lim@samsung.com leemgs@gmail.com , leemgs1@gmail.com --
What's the sha1 of the head commit ? Thanks, tglx --
Dear Thoomas,
Below was the recent commit number when I typed "git clone" command.
commit ed0799048b4a38ffb6e33755ba5e6b5dfa9a24d2
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Feb 21 23:14:28 2010 +0100
v2.6.33-rt1
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit b635a77f9aadc5ed3fc5a949e3f219c24cdd254c
Author: Carsten Emde <C.Emde@osadl.org>
Date: Sat Jan 16 17:14:04 2010 +0100
hwlat_detector-avoid-smp_processor_id.patch
Avoid smp_processor_id() in preemptible code.
Signed-off-by: Carsten Emde <C.Emde@osadl.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
. . . . . . below omission . . . . . .
and, version info is 2.6.33-rc8-rt1 as belows.
[invain@localhost head]$ head Makefile
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 33
EXTRAVERSION = -rc8-rt1
NAME = Man-Eating Seals of Antiquity
# *DOCUMENTATION*
# To see a list of typical targets execute "make help"
# More info can be located in ./README
# Comments in this file are targeted only to the developer, do not
Thanks,
Geunsik Lim.
--
Regards,
GeunSik Lim ( Samsung Electronics )
Blog : http://blog.naver.com/invain/
e-Mail: geunsik.lim@samsung.com
leemgs@gmail.com , leemgs1@gmail.com
--
--
Thomas. Um. I checked new -rt tag now. I will move rt number from v2.6.33-rc8-rt2 to v2.6.33-rc8-rt2. And then, I will test v2.6.33-rc8-rt2 on my desktop pc 1) intel core2 quad Q6600 (SSD 64G , 2G DDR RAM ) 2) intel core2 quad Q9400 (SATA 320G, 2G DDR RAM) Thanks, Geunsik Lim. -- Regards, GeunSik Lim ( Samsung Electronics ) Blog : http://blog.naver.com/invain/ e-Mail: geunsik.lim@samsung.com leemgs@gmail.com , leemgs1@gmail.com -- --
Hi Thomas, Thank you for linux-2.6.33-rc8-rt2 release quickly. :) I can boot this linux version on my desktop (intel core2 Quad Q9400) successfully now. I uploaded a screenshot file. * Booting result of linux-2.6.33-rc8-rt2 on Q9400 PC. --> Passed. http://picasaweb.google.com/leemgs/LinuxRelatedScreenshot#5441865625183643634 Thanks. Geunsik Lim. commit 5fd3a249542494b19e3c77c92b5d5ddc7fb8ece4 Author: Thomas Gleixner <tglx@linutronix.de> Date: Wed Feb 24 17:45:03 2010 +0100 v2.6.33-rc8-rt2 Signed-off-by: Thomas Gleixner <tglx@linutronix.de> commit c3bde8f3a7af0bcdc8844102a08896e3fdd77153 Merge: ed07990 5f00286 Author: Thomas Gleixner <tglx@linutronix.de> Date: Wed Feb 24 17:44:48 2010 +0100 Merge branch 'rt/head' into rt/2.6.33 Conflicts: Makefile Signed-off-by: Thomas Gleixner <tglx@linutronix.de> -- Regards, GeunSik Lim ( Samsung Electronics ) Blog : http://blog.naver.com/invain/ e-Mail: geunsik.lim@samsung.com leemgs@gmail.com , leemgs1@gmail.com -- --
> I will move rt number from v2.6.33-rc8-rt2 to v2.6.33-rc8-rt2. oops. sorry. from v2.6.33-rc8-rt1 to v2.6.33-rc8-rt2. -- Regards, GeunSik Lim ( Samsung Electronics ) Blog : http://blog.naver.com/invain/ e-Mail: geunsik.lim@samsung.com leemgs@gmail.com , leemgs1@gmail.com -- --
So you cloned the rt/2.6.33 branch of tip. rt/head does not have release numbers. The version in the Makefile is simply 2.6.33-rc8-rt. rt/head is where development happens. When stuff seems stable I update rt/2.6.xx and bump the -rt version and tag it. Thanks, tglx
Thank you for explanation of the rt/*** branch meaning. :) Currently, I am using the rt/2.6.33 branch with "git checkout -b v2.6.33-rc8-rt2 v2.6.33-rc8-rt2" command. [invain@localhost 2.6.33]$ git branch master v2.6.33-rc8-rt1 * v2.6.33-rc8-rt2 [invain@localhost 2.6.33]$ pwd /opt/rt/2.6.33 As I reported finally now is normal with -rc8-rt2. * Booting result of linux-2.6.33-rc8-rt2 on Q9400 PC. --> Passed. -- Regards, GeunSik Lim ( Samsung Electronics ) Blog : http://blog.naver.com/invain/ e-Mail: geunsik.lim@samsung.com leemgs@gmail.com , leemgs1@gmail.com -- --
This Happens when there is an external device(storage) plugged in. -- -- Sujit K M blog(http://kmsujit.blogspot.com/) --
index_ptr needs to be freed on the error path.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/kernel/trace/latency_hist.c b/kernel/trace/latency_hist.c
index b3b5ea2..8edc70c 100644
--- a/kernel/trace/latency_hist.c
+++ b/kernel/trace/latency_hist.c
@@ -204,8 +204,10 @@ static void *l_start(struct seq_file *m, loff_t *pos)
, my_hist->beyond_hist_bound_samples
, MAX_ENTRY_NUM, "samples");
}
- if (index >= MAX_ENTRY_NUM)
+ if (index >= MAX_ENTRY_NUM) {
+ kfree(index_ptr);
return NULL;
+ }
*index_ptr = index;
return index_ptr;
--
Thanks a lot for spotting this leak. We even don't need to allocate the
memory, if index >= MAX_ENTRY_NUM.
This patch applies to 2.6.31.12-rt21 and 2.6.33-rc8-rt (rt/head).
Signed-off-by: Carsten Emde <C.Emde@osadl.org>
Index: head/kernel/trace/latency_hist.c
===================================================================
--- head.orig/kernel/trace/latency_hist.c
+++ head/kernel/trace/latency_hist.c
@@ -218,13 +218,10 @@ void notrace latency_hist(int latency_ty
static void *l_start(struct seq_file *m, loff_t *pos)
{
- loff_t *index_ptr = kmalloc(sizeof(loff_t), GFP_KERNEL);
+ loff_t *index_ptr = NULL;
loff_t index = *pos;
struct hist_data *my_hist = m->private;
- if (!index_ptr)
- return NULL;
-
if (index == 0) {
char minstr[32], avgstr[32], maxstr[32];
@@ -263,10 +260,12 @@ static void *l_start(struct seq_file *m,
MAX_ENTRY_NUM - my_hist->offset,
"samples");
}
- if (index >= MAX_ENTRY_NUM)
- return NULL;
+ if (index < MAX_ENTRY_NUM) {
+ index_ptr = kmalloc(sizeof(loff_t), GFP_KERNEL);
+ if (index_ptr)
+ *index_ptr = index;
+ }
- *index_ptr = index;
return index_ptr;
}
--
kernel/trace/latency_hist.c
373 static ssize_t
374 latency_hist_show_maxlatproc(struct file *filp, char __user *ubuf,
375 size_t cnt, loff_t *ppos)
376 {
377 char buf[1024];
This is a large buffer to put on the stack.
regards,
dan carpenter
--
Thanks! Remove stack allocation of buffer space, use dyn memory instead. Use a better assumption to estimate the required buffer space. Signed-off-by: Carsten Emde <C.Emde@osadl.org>
Hi, I am facing NULL pointer deference error with beagle board. The bootargs used are - setenv bootargs 'console=ttyS2,115200n8 root=/dev/mmcblk0p2 rootwait rootfstype=ext3 omapfb.mode=dvi:800x600MR-24@60 omapdss.def_disp=dvi omapfb.vram=0:8M,1:2M,2:4M mem=216M' setenv bootcmd 'mmc init;fatload mmc 0 0x80200000 uImage;bootm 0x80200000' The crash log is as follows - Waiting for root device /dev/mmcblk0p2... Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: Oops: 805 [#1] PREEMPT last sysfs file: Modules linked in: CPU: 0 Not tainted (2.6.33-rc8-rt1 #3) PC is at rt_spin_lock_slowlock+0x64/0x220 LR is at rt_spin_lock_slowlock+0x24/0x220 pc : [<c029f85c>] lr : [<c029f81c>] psr: 60000093 sp : cd1a1ed8 ip : cd1a1f08 fp : 00000053 r10: cd3bc664 r9 : c039c8c4 r8 : cd3bc400 r7 : cd1a0000 r6 : cd3bc664 r5 : 60000013 r4 : cd3bc664 r3 : 00000000 r2 : cd3fb480 r1 : 00000000 r0 : cd1a1ed8 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 80004019 DAC: 00000017 Process irq/83-mmc0 (pid: 355, stack limit = 0xcd1a02e8) Stack: (0xcd1a1ed8 to 0xcd1a2000) 1ec0: 00000001 00000006 1ee0: cd070040 c0397f48 00000001 cd3fb480 ffffffff 00000002 cd3bc664 60000013 1f00: 00000000 cd1a0000 00000000 c029f9f0 00000000 cd3bc600 cd0c3ef4 cd3bc664 1f20: 00000000 cd3bc400 cd3bc664 c0213850 cd0c2000 cd0c201c cd3fb480 00000017 1f40: 00000000 cd3bc600 00000000 00018000 00000001 00000000 cd3bc664 c020bb94 1f60: cd0c3f24 c02145fc c039c880 cd3d07c0 cd1a0000 cd3d07e4 08000000 c039c8c4 1f80: c039c8dc c00768e8 cd3d07c0 00000032 cd1a1f88 cd021e58 cd1a1fbc c0076828 1fa0: cd3d07c0 00000000 00000000 00000000 00000000 c0060ae8 00000000 00000000 1fc0: cd1a1fc0 cd1a1fc0 cd1a1fc8 cd1a1fc8 00000000 00000000 cd1a1fd8 cd1a1fd8 1fe0: 00000000 00000000 00000000 00000000 00000000 c0028ec4 107fcd00 0a33ef94 [<c029f85c>] ...
Migrated to 2.6.33-rc8-rt2 but still am facing the same issue. Regards, Amit -----Original Message----- From: linux-rt-users-owner@vger.kernel.org [mailto:linux-rt-users-owner@vger.kernel.org] On Behalf Of Chatterjee, Amit Sent: Wednesday, February 24, 2010 5:50 PM To: LKML; rt-users Subject: 2.6.33-rc8-rt1 on Beagle Hi, I am facing NULL pointer deference error with beagle board. The bootargs used are - setenv bootargs 'console=ttyS2,115200n8 root=/dev/mmcblk0p2 rootwait rootfstype=ext3 omapfb.mode=dvi:800x600MR-24@60 omapdss.def_disp=dvi omapfb.vram=0:8M,1:2M,2:4M mem=216M' setenv bootcmd 'mmc init;fatload mmc 0 0x80200000 uImage;bootm 0x80200000' The crash log is as follows - Waiting for root device /dev/mmcblk0p2... Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: Oops: 805 [#1] PREEMPT last sysfs file: Modules linked in: CPU: 0 Not tainted (2.6.33-rc8-rt1 #3) PC is at rt_spin_lock_slowlock+0x64/0x220 LR is at rt_spin_lock_slowlock+0x24/0x220 pc : [<c029f85c>] lr : [<c029f81c>] psr: 60000093 sp : cd1a1ed8 ip : cd1a1f08 fp : 00000053 r10: cd3bc664 r9 : c039c8c4 r8 : cd3bc400 r7 : cd1a0000 r6 : cd3bc664 r5 : 60000013 r4 : cd3bc664 r3 : 00000000 r2 : cd3fb480 r1 : 00000000 r0 : cd1a1ed8 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 80004019 DAC: 00000017 Process irq/83-mmc0 (pid: 355, stack limit = 0xcd1a02e8) Stack: (0xcd1a1ed8 to 0xcd1a2000) 1ec0: 00000001 00000006 1ee0: cd070040 c0397f48 00000001 cd3fb480 ffffffff 00000002 cd3bc664 60000013 1f00: 00000000 cd1a0000 00000000 c029f9f0 00000000 cd3bc600 cd0c3ef4 cd3bc664 1f20: 00000000 cd3bc400 cd3bc664 c0213850 cd0c2000 cd0c201c cd3fb480 00000017 1f40: 00000000 cd3bc600 00000000 00018000 00000001 00000000 cd3bc664 c020bb94 1f60: cd0c3f24 c02145fc c039c880 cd3d07c0 cd1a0000 cd3d07e4 08000000 c039c8c4 1f80: ...
Hello,
This corresponds to:
BUG_ON(rt_mutex_owner(lock) == current);
in rt_spin_lock_slowlock. If you had CONFIG_BUG_VERBOSE this would have
I assume the problem is that the function omap_hsmmc_request tries to be
clever in a non-rt compatible way:
/*
* Prevent races with the interrupt handler because of unexpected
* interrupts, but not if we are already in interrupt context i.e.
* retries.
*/
if (!in_interrupt()) {
spin_lock_irqsave(&host->irq_lock, host->flags);
But looking at the backtrace in this context in_interrupt() would be
true in !PREEMPT_RT.
You might want to report that to the author(s) of
drivers/mmc/host/omap_hsmmc.c.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
mm/slab.c
2117 kmem_freepages(cachep, addr, *this_cpu);
2118 if (OFF_SLAB(cachep)) {
2119 if (this_cpu)
We already dereferenced "this_cpu" two lines earlier.
2120 __cache_free(cachep->slabp_cache, slabp, this_cpu);
2121 else
2122 kmem_cache_free(cachep->slabp_cache, slabp);
regards,
dan carpenter
--
Good catch. Thanks,
tglx
--
Hi Thomas, I could not boot into it in 8 way intel or 4 way amd blades, running RHEL 5.4 + MRG realtime kernel. --------- Waiting for driver initialization. Scanning and configuring dmraid supported devices Trying to resume from /dev/sda2 Unable to access resume device (/dev/sda2) Creating root device. Mounting root filesystem. mount: could not find filesystem '/dev/root' Setting up other filesystems. Setting up new root fs setuproot: moving /dev failed: No such file or directory no fstab.sys, mounting internal defaults setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory Switching to new root and running init. unmounting old /dev unmounting old /proc unmounting old /sys switchroot: mount failed: No such file or directory Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: init Not tainted 2.6.33-rc8-rt1-autotest #1 Call Trace: [<ffffffff8103b7f9>] panic+0xaf/0x170 [<ffffffff8108c755>] ? call_rcu+0x10/0x12 [<ffffffff813266d0>] ? rt_write_unlock+0x9/0xb [<ffffffff81045809>] ? exit_ptrace+0x9c/0x10d [<ffffffff8103e8d1>] do_exit+0x79/0x714 [<ffffffff8132931c>] ? do_page_fault+0x329/0x338 [<ffffffff8103efe4>] do_group_exit+0x78/0xa5 [<ffffffff8103f023>] sys_exit_group+0x12/0x16 [<ffffffff81002a2b>] system_call_fastpath+0x16/0x1b -------- .config I used is below: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.33-rc8-rt1 # Tue Feb 23 03:37:05 2010 # CONFIG_64BIT=y # CONFIG_X86_32 is not ...
mica.ghostprotocols.net login: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<(null)>] (null) PGD 37ea1067 PUD bae52067 PMD 0 Oops: 0010 [#1] PREEMPT SMP last sysfs file: /sys/class/misc/autofs/dev CPU 0 Pid: 7341, comm: perf Not tainted 2.6.33-rc8-rt #1 0KN122/PowerEdge 1900 RIP: 0010:[<0000000000000000>] [<(null)>] (null) RSP: 0018:ffff8800bae01990 EFLAGS: 00010046 RAX: ffffffff8140a060 RBX: ffff88012f0206c0 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff88012f0206c0 RDI: ffff8800282d0300 RBP: ffff8800bae019b8 R08: ffff8800282c3e68 R09: ffff8800bac16238 R10: ffffffff81600000 R11: ffff8800bae01b38 R12: 0000000000000001 R13: ffff8800282d0300 R14: ffff8800282d0300 R15: 0000000000000001 FS: 00007f862804b6e0(0000) GS:ffff880028200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 00000000baf13000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process perf (pid: 7341, threadinfo ffff8800bae00000, task ffff880037f580c0) Stack: ffffffff8102caee ffff8800282d0300 ffff88012f0206c0 ffff8800282d0300 <0> ffff8800282d0300 ffff8800bae019d8 ffffffff8102cb29 ffff8800bac16238 <0> 0000000000000003 ffff8800bae01a38 ffffffff8103aeb3 ffff8800bae019f8 Call Trace: [<ffffffff8102caee>] ? enqueue_task+0x45/0x55 [<ffffffff8102cb29>] activate_task+0x2b/0x33 [<ffffffff8103aeb3>] try_to_wake_up+0x1cc/0x33c [<ffffffff81330d37>] ? preempt_schedule_irq+0x6a/0x76 [<ffffffff8103b072>] wake_up_process_mutex+0x15/0x17 [<ffffffff8106ac2e>] wakeup_next_waiter+0x85/0x15e [<ffffffff813319e5>] rt_spin_lock_slowunlock+0x3e/0x5c [<ffffffff8106a302>] rt_spin_lock_fastunlock+0x35/0x37 [<ffffffff81331f67>] rt_spin_unlock+0x10/0x12 [<ffffffff8105a5a7>] remove_wait_queue+0x49/0x4e [<ffffffff810f0927>] free_poll_entry+0x19/0x25 [<ffffffff810f095d>] poll_freewait+0x2a/0x6b [<ffffffff810f0c81>] ...
Seeing this here, otherwise seems fine: BUG: sleeping function called from invalid context at arch/x86/mm/highmem_32.c:9 in_atomic(): 1, irqs_disabled(): 0, pid: 1984, name: Xorg Pid: 1984, comm: Xorg Not tainted 2.6.31.12-1.rt21.1.fc11.ccrma.i686.rtPAE #1 Call Trace: [<c0431852>] __might_sleep+0xc6/0xcb [<c042b494>] kmap+0x47/0x5a [<f8049ca7>] i915_gem_pwrite_ioctl+0x3ea/0x631 [i915] [<f7f61721>] drm_ioctl+0x208/0x2a9 [drm] [<f80498bd>] ? i915_gem_pwrite_ioctl+0x0/0x631 [i915] [<c0589d80>] ? inode_has_perm+0x69/0x84 [<c07a31ff>] ? rt_mutex_lock+0x28/0x2b [<c046a7f3>] ? rt_down+0x1a/0x1d [<c04e6581>] vfs_ioctl+0x5c/0x76 [<c04e6ae9>] do_vfs_ioctl+0x4a0/0x4de [<c058a00f>] ? selinux_file_ioctl+0x43/0x46 [<c04e6b6d>] sys_ioctl+0x46/0x66 [<c04090d3>] sysenter_do_call+0x12/0x28 -- Fernando --
io_mapping_map_atomic_wc() still appears to use the actual kmap_atomic stuff, and we seem to miss an kmap_prot_pfn() function to fill that gap with, I'll try and implement that tomorrow. --
Hi all,
When I tried to migrate RT-Preempt/linux-mips from 2.6.29.6-rt23 to
2.6.31-rc8, and compile the kernel without PREEMPT_RT. there is a
"kernel panic" take place:
...
find the frame buffer:start=40000000
input: AT Translated Set 2 keyboard as /class/input/input0
usb 1-1: new high speed USB device using ehci_hcd and address 2
atkbd.c: keyboard reset failed on isa0060/serio1
usb 1-1: configuration #1 chosen from 1 choice
usb 2-1: new high speed USB device using ehci_hcd and address 2
usb 2-1: configuration #1 chosen from 1 choice
scsi0 : SCSI emulation for USB Mass Storage devices
Unhandled kernel unaligned access[#1]:
Cpu 0
$ 0 : 0000000000000000 000000001400c4e0 0000000000000018
0000000000000001
$ 4 : ffffffff806175e8 ffffffff806175f0 ffffffffffffffff
ffffffff803c9f84
$ 8 : 00000000000028db ffffffff806b0d75 0000000000000018
74735f6d69616c63
$12 : 0000000000000000 ffffffff80205dbc 0000000000000000
98000000be128000
$16 : ffffffff80620780 980000000100a192 0000000000000002
ffffffff80650e50
$20 : ffffffff80650e50 0000000000000006 ffffffff806b84f8
0000000000000001
$24 : 0000000000000028 ffffffff803c9598
$28 : 98000000be04c000 98000000be04fa40 0000000000000003
ffffffff8027dc70
Hi : 000000000000010a
Lo : 000000003df58000
epc : ffffffff8027dc70 ____pagevec_lru_add+0x1b4/0x364
Not tainted
ra : ffffffff8027dc70 ____pagevec_lru_add+0x1b4/0x364
Status: 1400c4e2 KX SX UX KERNEL EXL
Cause : 00008010
BadVA : 980000000100a192
PrId : 00006303 (ICT Loongson-2)
Modules linked in:
Process swapper (pid: 1, threadinfo=98000000be04c000,
task=98000000be04b818, tls=0)Stack : 0000000000000498 0000000000000030
0000000000000440 0000000000000000
980000000100a158 0000000000000000 0000000000020058
0000000000000000
98000000bd00ae30 0000000000000050 ffffffffffffffef
ffffffff80651980
0000000000000000 ffffffff80273e2c 0000000000000000
ffffffff80651980
980000000100a158 ffffffff802746f8 0000000000000000
98000000bd00ae30
...Some of the data and insight I've gleamed out of my pSeries system. I don't really have answers, but perhaps a hint that will help someone else identify the cause, or point me in a particular direction. :-) Booting the system seems mostly OK with maxcpus=1, though this INFO message appears on the console. (This does repeat after a while..) : INFO: task irq/16-IPI:3 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Call Trace: [c00000006a3a7a50] [c00000006a3a2b78] 0xc00000006a3a2b78 (unreliable) [c00000006a3a7c20] [c0000000000123e8] .__switch_to+0x1d4/0x278 [c00000006a3a7cc0] [c000000000470fe8] .__schedule+0x860/0x938 [c00000006a3a7db0] [c0000000004713d4] .schedule+0x2c/0x60 [c00000006a3a7e30] [c000000000092820] .kthread+0x78/0xb4 [c00000006a3a7f90] [c00000000002a618] .kernel_thread+0x54/0x70 INFO: lockdep is turned off. INFO: task irq/18-RAS_EPOW:155 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Call Trace: [c000000068203a50] [c00000006a44ed78] 0xc00000006a44ed78 (unreliable) [c000000068203c20] [c0000000000123e8] .__switch_to+0x1d4/0x278 [c000000068203cc0] [c000000000470fe8] .__schedule+0x860/0x938 [c000000068203db0] [c0000000004713d4] .schedule+0x2c/0x60 [c000000068203e30] [c000000000092820] .kthread+0x78/0xb4 [c000000068203f90] [c00000000002a618] .kernel_thread+0x54/0x70 INFO: lockdep is turned off. *************** Processor 1 found. BUG: using smp_processor_id() in preemptible [00000000] code: irq/16-IPI/3 caller is .xics_ipi_action_lpar+0x14/0x68 Call Trace: [c00000006a3a7bc0] [c00000000001182c] .show_stack+0x70/0x184 (unreliable) [c00000006a3a7c70] [c00000000029a210] .debug_smp_processor_id+0x1c8/0x250 [c00000006a3a7d10] [c0000000000502cc] .xics_ipi_action_lpar+0x14/0x68 [c00000006a3a7d90] [c0000000000ce0c0] .irq_thread+0x110/0x250 [c00000006a3a7e30] [c000000000092850] .kthread+0xa8/0xb4 [c00000006a3a7f90] [c00000000002a618] ...
Will, Hmm. Why is the IPI threaded ? Can you check older (working) RT versions whether the IPIs were threaded there as well ? Thanks, tglx --
Hi Thomas, fyi and for list awareness, I was able to boot 2.6.31-rc6-rt5 (out of .git tip/rt/...) successfully on my system. (power6 pseries JS22). Currently up and running kernbench, all cpus utilized.. good stuff. :-) Thanks, --
I'm seeing some bad scheduler behavior with this patch. I've seen occasional bad behavior with 2.6.29-rt as well, but with .31-rt its much worse. I'm running a SCHED_OTHER cpubound benchmark (censored to xxxxxxxxxxxxx in the logs) that runs for a number of minutes. With 2.6.31-rc6 I'm seeing really poor numbers and if I cat /proc/sched_debug I see all of the cpu bound tasks are running on the same cpu, while the other procs are basically idle. See the log below: Any thoughts on how to debug this? thanks -john Sched Debug Version: v0.09, 2.6.31-rc6-rt2 #2 now at 1293360.710541 msecs .jiffies : 4295960656 .sysctl_sched_latency : 60.000000 .sysctl_sched_min_granularity : 12.000000 .sysctl_sched_wakeup_granularity : 15.000000 .sysctl_sched_child_runs_first : 0.000001 .sysctl_sched_features : 113917 cpu#0, 2193.531 MHz .nr_running : 4 .load : 4096 .nr_switches : 4053338 .nr_load_updates : 1293349 .nr_uninterruptible : 43 .next_balance : 4295.960682 .curr->pid : 3515 .clock : 1293360.013589 .cpu_load[0] : 181618 .cpu_load[1] : 181618 .cpu_load[2] : 181618 .cpu_load[3] : 181618 .cpu_load[4] : 181618 .rt.rt_nr_running : 0 .rt.rt_nr_uninterruptible : -2 .rto_schedule : 1302873 .rto_schedule_tail : 0 .rto_wakeup : 0 .rto_pulled : 0 .rto_pushed : 0 .yld_count : 1 .sched_switch : 0 .sched_count : 8418031 .sched_goidle : 731106 .ttwu_count : 2747402 .ttwu_local ...
Thomas didn't like that I censored the benchmark, so until I know better about what I can say there, I've reproduced a similar effect with a make -j8 bzImage. See below: thanks -john Sched Debug Version: v0.09, 2.6.31-rc6-rt2 #2 now at 3297823.422240 msecs .jiffies : 4297965119 .sysctl_sched_latency : 60.000000 .sysctl_sched_min_granularity : 12.000000 .sysctl_sched_wakeup_granularity : 15.000000 .sysctl_sched_child_runs_first : 0.000001 .sysctl_sched_features : 113917 cpu#0, 2193.531 MHz .nr_running : 4 .load : 3087 .nr_switches : 10622255 .nr_load_updates : 3297812 .nr_uninterruptible : 51 .next_balance : 4297.965146 .curr->pid : 26387 .clock : 3297823.016251 .cpu_load[0] : 180594 .cpu_load[1] : 231489 .cpu_load[2] : 238710 .cpu_load[3] : 236501 .cpu_load[4] : 233349 .rt.rt_nr_running : 0 .rt.rt_nr_uninterruptible : -13 .rto_schedule : 3359261 .rto_schedule_tail : 0 .rto_wakeup : 0 .rto_pulled : 0 .rto_pushed : 0 .yld_count : 1 .sched_switch : 0 .sched_count : 17260145 .sched_goidle : 1789234 .ttwu_count : 7093762 .ttwu_local : 7041555 .bkl_count : 544 cfs_rq[0]: .exec_clock : 1526490.657852 .MIN_vruntime : 1697673.859107 .min_vruntime : 1697721.435148 .max_vruntime : 1697722.132915 .spread : 48.273808 .spread0 ...
Same thing happens w/ 2.6.31-rc6-rt4. config attached. Simple busy loops like: while true; do ls > /dev/null; done & while true; do ls > /dev/null; done & while true; do ls > /dev/null; done & while true; do ls > /dev/null; done & Also show the same behavior. thanks -john
One of my users has been hitting an issue with suspend, the machine suspends but will not come back alive. Below is the latest debug info he sent me (the issue still happens with rt23, got a report this morning) -- Fernando On Wed, 2009-07-01 at 19:53 -0500, S C Rigler wrote: Amazingly enough, I was finally able to get some information logged by following some of the steps in basic-pm-debugging.txt. This test modes also created the exact same log message. Here it is with -- Fernando --
