[lkml]   [2006]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: [PATCH] 2.6.17-rt1 : fix x86_64 oops

* Dipankar Sarma <> wrote:

> > I have been able to reproduce a similar looking oopse with 2.6.16-rt29.
> > 2.6.16-rt20 works fine. I will try to track it down to the exact
> > release as far as I can.
> OK, it looks as if rt20 is fine but rt21 is broken. So something that
> got in rt21 is causing this oops.

thanks! That really narrows it down.

> Ingo, do you have a suspect ?

I suspect it's the patch below. That patch (from John) relaxes the
affinities of IRQ threads: if there are /proc/irq/*/smp_affinity entries
that have multiple bits set an IRQ thread is allowed to jump from one
CPU to another while it is executing a IRQ-handler. It _should_ be fine
but i'd not be surprised if that caused breakage ...

if this is the cause of the crash, would be hard for you trying to
figure out _which_ IRQ thread is so sensitive to affinity?


Index: linux/kernel/irq/manage.c
--- linux.orig/kernel/irq/manage.c
+++ linux/kernel/irq/manage.c
@@ -717,24 +717,21 @@ static int do_irqd(void * __desc)
if (param.sched_priority > 25)
curr_irq_prio = param.sched_priority - 1;

-// param.sched_priority = 1;
sys_sched_setscheduler(current->pid, SCHED_FIFO, &param);

while (!kthread_should_stop()) {
+ local_irq_disable();
-// do_softirq_from_hardirq();
* Did IRQ affinities change?
- if (!cpu_isset(smp_processor_id(), irq_affinity[irq])) {
- mask = cpumask_of_cpu(any_online_cpu(irq_affinity[irq]));
- set_cpus_allowed(current, mask);
- }
+ if (!cpus_equal(current->cpus_allowed, irq_affinity[irq]));
+ set_cpus_allowed(current, irq_affinity[irq]);
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at
 \ /
  Last update: 2006-07-04 08:50    [W:0.059 / U:6.888 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site