Date: Wed, 23 Jun 2004 13:53:19 -0400 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-current@FreeBSD.org Cc: Julian Elischer <julian@elischer.org> Subject: Re: STI, HLT in acpi_cpu_idle_c1 Message-ID: <200406231353.19276.jhb@FreeBSD.org> In-Reply-To: <FE045D4D9F7AED4CBFF1B3B813C85337054EC4B4@mail.sandvine.com> References: <FE045D4D9F7AED4CBFF1B3B813C85337054EC4B4@mail.sandvine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406231353.19276.jhb>