* Ingo Molnar <[EMAIL PROTECTED]> wrote: > it worked upon the first try, and indeed my testbox crashed within 10 > seconds: > > BUG: Unable to handle kernel NULL pointer dereference > BUG: Unable to handle kernel NULL pointer dereference at virtual address > 00000006
a couple of crashes later i got an important clue: BUG: bad soft irq-flag value 00000f64, openvpn/3386! [<c0104052>] dump_stack+0x1f/0x21 (20) [<c013b883>] check_soft_flags+0x73/0xc9 (24) [<00000f78>] 0xf78 (1066836133) it turns out that a small portion of the softirq processing path was still using the soft IRQ-flag, instead of the raw IRQ-flag! Given enough irq and softirq workload, we were interrupted in a piece of code where the data structure was inconsistent. (tinfo.task was already changed, but %esp not yet) Since interrupts were enabled during the crash printout, it would crash again and again as it got more interrupts. The backtrace printout crashed too due to the inconsistency. That's why you got those repeat ============= lines. the patch below should fix this bug and i've uploaded the -51-30 patch with this fix included. Could you check whether 4K stacks are now stable for you under PREEMPT_RT? so your intuitition about this being related to 4K stacks was completely right. Ingo Index: linux/arch/i386/kernel/irq.c =================================================================== --- linux.orig/arch/i386/kernel/irq.c +++ linux/arch/i386/kernel/irq.c @@ -169,7 +169,7 @@ asmlinkage void do_softirq(void) if (in_interrupt()) return; - local_irq_save(flags); + raw_local_irq_save(flags); if (local_softirq_pending()) { curctx = current_thread_info(); @@ -190,7 +190,7 @@ asmlinkage void do_softirq(void) ); } - local_irq_restore(flags); + raw_local_irq_restore(flags); } EXPORT_SYMBOL(do_softirq); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/