The best APIC documentation are the old data sheets for the external
APIC chips. I don't know if they cover things in such detail.
> In this case the latter NMI will actually have an overflow state to
> process so it's not a spurious NMI.
But we cannot distinguish it right? The spurious detector
On Sun, Feb 16, 2014 at 07:38:50PM +0100, Andi Kleen wrote:
> > This reminds me of the late-ack stuff;
> >
> > The way I understand interrupts to work is that when you raise the
> > interrupt it gets latched, when you ACK you drop the latch. Then when it
> > gets re-raised while its still in progr
> This reminds me of the late-ack stuff;
>
> The way I understand interrupts to work is that when you raise the
> interrupt it gets latched, when you ACK you drop the latch. Then when it
> gets re-raised while its still in progress, it gets latched again and
> the irq-enable at the end of the runn
On Fri, Feb 14, 2014 at 04:44:08PM -0800, Andi Kleen wrote:
>
> Make intel_pmu_handle_irq() take the full exit path when returning early.
This reminds me of the late-ack stuff;
The way I understand interrupts to work is that when you raise the
interrupt it gets latched, when you ACK you drop the
From: Markus Metzger
[From Markus, just sending for him because he had problems with his mail]
When using BTS on Core i7-4*, I get the below kernel warning.
$ perf record -c 1 -e branches:u ls
Message from syslogd@labpc1501 at Nov 11 15:49:25 ...
kernel:[ 438.317893] Uhhuh. NMI received for u
From: Markus Metzger
[From Markus, just sending for him because he had problems with his mail]
When using BTS on Core i7-4*, I get the below kernel warning.
$ perf record -c 1 -e branches:u ls
Message from syslogd@labpc1501 at Nov 11 15:49:25 ...
kernel:[ 438.317893] Uhhuh. NMI received for u
6 matches
Mail list logo
