Feng,
On Fri, 28 Jun 2019, Thomas Gleixner wrote:
> On Fri, 28 Jun 2019, Feng Tang wrote:
> > On Tue, Jun 25, 2019 at 07:32:03PM +0800, Thomas Gleixner wrote:
> > > the head of that branch is:
> > >
> > > 4f3f6d6a7f8e ("x86/apic/x2apic: Add conditional IPI shorthands
> > > support")
> > >
> > > This is WIP and force pushed. There are no incremental changes. Could you
> > > please check again?
> >
> > Since you can't reproduce it yet, we've added some debug hook to get more
> > info, like dmesg below:
> >
> > [ 288.866069] IRR[7]: 0x1000
> > [ 289.890274] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/apic/apic.c:1502
> > setup_local_APIC+0x2d1/0x4f0
>
> > [ 290.182418] queued = 0x1000 acked = 0
> > [ 290.189159] IRR[7]: 0x1000
> >
> > Which shows the IRR[7] was set 0x1000, IIUC, it means vector
> > 0xec, which is for LAPIC timer, and ISRs are all 0 before and
> > after the loop.
>
> Ahhhh. That makes a lot of sense now.
>
> That interrupt is in the IRR, but not in the ISR. So the acknowledge
> attempts are useless because the ack only clears an pending ISR and the IRR
> is not propagated because in the state in which this happens the entry is
> masked.
>
> That function just 'works' by chance not by design. I'll stare into it and
> fix it up for real.
>
> Thank you very much for that information. Your debug was spot on!
I rewrote that function so it actually handles that case correctly along
with some other things which were broken and force pushed the WIP.x86/ipi
branch.
Can you please run exactly that test again against that new version and
verify that this is fixed now?
Thanks,
tglx
