Date: Wed, 23 Jun 2004 13:14:14 -0400 From: Gerrit Nagelhout <gnagelhout@sandvine.com> To: 'John Baldwin' <jhb@FreeBSD.org>, freebsd-current@FreeBSD.org Cc: kris@FreeBSD.org Subject: RE: STI, HLT in acpi_cpu_idle_c1 Message-ID: <FE045D4D9F7AED4CBFF1B3B813C85337054EC4B4@mail.sandvine.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE045D4D9F7AED4CBFF1B3B813C85337054EC4B4>