* Chris J Arges wrote:
> > diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
> > index 6cedd7914581..79d6de6fdf0a 100644
> > --- a/arch/x86/kernel/apic/vector.c
> > +++ b/arch/x86/kernel/apic/vector.c
> > @@ -144,6 +144,8 @@ __assign_irq_vector(int irq, struct irq_cfg *c
On Wed, Apr 01, 2015 at 02:39:13PM +0200, Ingo Molnar wrote:
>
> * Chris J Arges wrote:
>
> > This was only tested only on the L1, so I can put this on the L0 host and
> > run
> > this as well. The results:
> >
> > [ 124.897002] apic: vector c1, new-domain move in progress
>
* Chris J Arges wrote:
> This was only tested only on the L1, so I can put this on the L0 host and run
> this as well. The results:
>
> [ 124.897002] apic: vector c1, new-domain move in progress
>
> [ 124.954827] apic: vector d1, sent cleanup vector, move completed
On Wednesday, April 1, 2015 at 6:40:06 AM UTC+8, Chris J Arges wrote:
> On Tue, Mar 31, 2015 at 12:56:56PM +0200, Ingo Molnar wrote:
> >
> > * Linus Torvalds wrote:
> >
> > > Ok, interesting. So the whole "we try to do an APIC ACK with the ISR
> > > bit clear" seems to be a real issue.
> >
> > It'
On Tue, Mar 31, 2015 at 12:56:56PM +0200, Ingo Molnar wrote:
>
> * Linus Torvalds wrote:
>
> > Ok, interesting. So the whole "we try to do an APIC ACK with the ISR
> > bit clear" seems to be a real issue.
>
> It's interesting in particular when it happens with an edge-triggered
> interrupt so
* Linus Torvalds wrote:
> Ok, interesting. So the whole "we try to do an APIC ACK with the ISR
> bit clear" seems to be a real issue.
It's interesting in particular when it happens with an edge-triggered
interrupt source: it's much harder to miss level triggered IRQs, which
stay around until
6 matches
Mail list logo
