From owner-freebsd-current@FreeBSD.ORG Wed Jun 23 17:14:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97D7C16A4CE; Wed, 23 Jun 2004 17:14:26 +0000 (GMT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id A750D43D4C; Wed, 23 Jun 2004 17:14:25 +0000 (GMT) (envelope-from gnagelhout@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Jun 2004 13:14:22 -0400 Message-ID: From: Gerrit Nagelhout To: 'John Baldwin' , freebsd-current@FreeBSD.org Date: Wed, 23 Jun 2004 13:14:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" cc: Julian Elischer cc: kris@FreeBSD.org Subject: RE: STI, HLT in acpi_cpu_idle_c1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2004 17:14:26 -0000 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