Re: Ingo's realtime_preempt patch causes kernel oops

From: Yann . LEPROVOST
Date: Wed May 24 2006 - 10:03:35 EST


Yeah, I'm using minicom to log in through the serial debug unit, meaning
that there are probably many incoming intterrupts corresponding to input
characters...

Yann




Steven Rostedt
<rostedt@goodmis.
org> To
Yann.LEPROVOST@xxxxxxxxxx
24/05/2006 14:55 cc
Daniel Walker <dwalker@xxxxxxxxxx>,
linux-kernel@xxxxxxxxxxxxxxx,
linux-kernel-owner@xxxxxxxxxxxxxxx,
Ingo Molnar <mingo@xxxxxxx>, Thomas
Gleixner <tglx@xxxxxxxxxxxxx>
Subject
Re: Ingo's realtime_preempt patch
causes kernel oops










On Wed, 2006-05-24 at 10:06 +0200, Yann.LEPROVOST@xxxxxxxxxx wrote:
> The debug serial unit is part of the mainline kernel, this is the common
> link to work with the CSB637 Cogent board.
> I don't know about others AT91RM9200 based board.
>
> AT91RM9200 also have others USART, but there are no available output
> connectors on the CSB637 board.
>

Hi Yann,

OK, do you only get the prints from the serial? If so than that is OK,
but if you also log in through the serial, then that is a problem. In
other words, do you have something like mgetty running to log in through
the serial?

Looking at the at91_interrupt it can call mutex spin_locks if receiving
data. So this needs care.

Thomas or Ingo,

Maybe the handling of IRQs needs to handle the case that shared irq can
have both a NODELAY and a thread. The irq descriptor could have a
NODELAY set if any of the actions are NODELAY, but before calling the
interrupt handler (in interrupt context), check if the action is NODELAY
or not, and if not, wake up the thread if not done so already.

thoughts?

-- Steve




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/