Messages in this thread | | | Date | Sat, 29 Jun 2019 09:15:17 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [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
| |