STI, HLT in acpi_cpu_idle_c1
John Baldwin
jhb at FreeBSD.org
Wed Jun 23 10:52:22 PDT 2004
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
More information about the freebsd-current
mailing list