Re: STI, HLT in acpi_cpu_idle_c1

On Wednesday 23 June 2004 01:14 pm, Gerrit Nagelhout wrote:
> John Baldwin wrote:
> > bit 19 is set, so vector of 224 + 19 = 243.
> >
> > #define APIC_LOCAL_INTS 240
> > #define APIC_IPI_INTS   (APIC_LOCAL_INTS + 3)
> > #define IPI_AST         APIC_IPI_INTS           /* Generate
> > software trap. */
> >
> > So it's an IPI_AST which is EOI'd before we do anything:
> >
> > IDTVEC(cpuast)
> >         PUSH_FRAME
> >         movl    $KDSEL, %eax
> >         movl    %eax, %ds               /* use KERNEL data segment */
> >         movl    %eax, %es
> >         movl    $KPSEL, %eax
> >         movl    %eax, %fs
> >
> >         movl    lapic, %edx
> >         movl    $0, LA_EOI(%edx)        /* End Of Interrupt to APIC */
> >
> >         FAKE_MCOUNT(TF_EIP(%esp))
> >
> >         MEXITCOUNT
> >         jmp     doreti
> >
> > Hmm nothing in the kernel does an IPI to all but self with
> > IPI_AST.  Only with
> > IPI_RENDEZVOUS in MI code.
>
> Is there a way to prove that the system is in the state that could
> be fixed by your suggested patch?  I can hit the NMI button, and
> get a core file if necessary.  Do you know where the IPI_AST could
> be coming from?  I found a couple of references to it (forward_roundrobin,
> kseq_notify and forward_signal).  I set a breakpoint on these functions,
> as well as Xcpuast, and Xcpuast is getting called regularly without any
> of the others being hit, although I did eventually get a forward_signal.
> The APIC registers after setting the breakpoint on Xcpuast looked very
> similar to what I saw in the lockup.
> Is Matt's theory of a process going to sleep in the middle of the interrupt
> handler possible?  From the Xcpuast function, it doesn't look like any
> blocking calls are executed before the EOI, so I don't see how that's
> possible in this case.
> I will try to reproduce the lockup a few more times, and see if it is
> always getting stuck in the IPI_AST case.
> Thanks,

Note that the vector in icr_low of CPU 3 (which had just sent an IPI) was 0xf6 
== IPI_INVLRNG, not IPI_AST, so whatever IPI CPU 1 is stuck on, it's not the 
one that CPU 3 just sent.  It might be that either CPU 0 or CPU 1 sent the 
IPI since the vector in their icr_lo is 0xf3.  However, you said that you are 
seeing Xcpuast called w/o the known AST sending functions being called?  Can 
you stick a breakpoint in lapic_ipi_vectored() that triggers if the IPI is an 
AST and then do a trace to see where it came from if it wasn't from an 
expected place?

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org