STI, HLT in acpi_cpu_idle_c1
Gerrit Nagelhout
gnagelhout at sandvine.com
Wed Jun 23 10:14:26 PDT 2004
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
More information about the freebsd-current
mailing list