Re: [PATCH] 2.6.17-rt1 : fix x86_64 oops

[Ingo Molnar <mingo@elte.hu>]

* Dipankar Sarma <dipankar@in.ibm.com> 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?

	Ingo

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()) {
 		set_current_state(TASK_INTERRUPTIBLE);
 		do_hardirq(desc);
 		cond_resched_all();
+		local_irq_disable();
 		__do_softirq();
-//		do_softirq_from_hardirq();
 		local_irq_enable();
 #ifdef CONFIG_SMP
 		/*
 		 * 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]);
 #endif
 		schedule();
 	}