On Mon, Sep 10, 2012 at 08:19:18PM +0100, Alan Cox wrote:
> On Mon, 10 Sep 2012 10:57:04 -0700
> Anton Vorontsov wrote:
>
> > On Mon, Sep 10, 2012 at 12:16:24PM +0100, Alan Cox wrote:
> > > > serial port, the CPU receives NMI exception, and we fall into KDB
> > > > shell. So, it is our "debug co
On Mon, 10 Sep 2012 10:57:04 -0700
Anton Vorontsov wrote:
> On Mon, Sep 10, 2012 at 12:16:24PM +0100, Alan Cox wrote:
> > > serial port, the CPU receives NMI exception, and we fall into KDB
> > > shell. So, it is our "debug console", and it is able to interrupt
> > > (and thus debug) even IRQ ha
On Mon, Sep 10, 2012 at 12:16:24PM +0100, Alan Cox wrote:
> > serial port, the CPU receives NMI exception, and we fall into KDB
> > shell. So, it is our "debug console", and it is able to interrupt
> > (and thus debug) even IRQ handlers themselves.
>
> You seem to have an assumption of single cor
> serial port, the CPU receives NMI exception, and we fall into KDB shell.
> So, it is our "debug console", and it is able to interrupt (and thus
> debug) even IRQ handlers themselves.
You seem to have an assumption of single core here. What happens if the
NMI hits CPU #0 and the serial IRQ hits
This patch implements a new callback: clear_irqs. It is used for the
cases when KDB-entry (e.g. NMI) and KDB IO (e.g. serial port) shares the
same interrupt. To get the idea, let's take some real example (ARM
machine): we have a serial port which interrupt is routed to an NMI, and
the interrupt is
5 matches
Mail list logo