RE: STI, HLT in acpi_cpu_idle_c1

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,

Gerrit