lkml.org 
[lkml]   [2019]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [LKP] [x86/hotplug] e1056a25da: WARNING:at_arch/x86/kernel/apic/apic.c:#setup_local_APIC
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

\
 
 \ /
  Last update: 2019-06-29 09:15    [W:0.063 / U:1.764 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site