On Wednesday 13 Jul 2005 16:30, Ingo Molnar wrote:
> * 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,
This fixes the issue. It's one more 'crossed t' on the rt-preempt patches.
I'll let you know if I discover anything else; your work has already allowed
us to bring the responsiveness of our instrument to 300us which is low enough
for the real-time PCR industry. Thanks a lot!
This debugging process has been extremely eye opening, thanks for the detailed
descriptions of what's gone wrong at every stage. I just wish I was competent
enough to fix these things myself.
--
Cheers,
Alistair.
personal: alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student: CS/CSim Undergraduate
contact: 1F2 55 South Clerk Street,
Edinburgh. EH8 9PP.
-
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/
