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
[email protected]
24/05/2006 14:55 cc
Daniel Walker <[email protected]>,
[email protected],
[email protected],
Ingo Molnar <[email protected]>, Thomas
Gleixner <[email protected]>
Subject
Re: Ingo's realtime_preempt patch
causes kernel oops
On Wed, 2006-05-24 at 10:06 +0200, [email protected] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
