From owner-freebsd-current@FreeBSD.ORG Sun Jul 11 12:17:44 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 E388A16A4CE; Sun, 11 Jul 2004 12:17:44 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48C9143D4C; Sun, 11 Jul 2004 12:17:44 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i6BCHd4u006028; Sun, 11 Jul 2004 22:17:39 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) i6BCHRnl004786; Sun, 11 Jul 2004 22:17:36 +1000 Date: Sun, 11 Jul 2004 22:17:26 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Scott Long In-Reply-To: <40EFDCEC.6080307@samsco.org> Message-ID: <20040711215816.T1987@epsplex.bde.org> References: <200407091314.07506.jhb@FreeBSD.org> <40EFDCEC.6080307@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: Gerrit Nagelhout cc: Julian Elischer 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: Sun, 11 Jul 2004 12:17:45 -0000 On Sat, 10 Jul 2004, Scott Long wrote: > John Baldwin wrote: > > Once the EOI is sent to the APIC, the processor will except other interrupts. > > However, most of the interrupt code also runs with interrupts disabled. The > > exception is in ast(), meaning that another interrupt can come in and nest > > during an ast(), but ast() is not called during nested returns, so it won't > > nest infinitely. iret doesn't do any sort of EOI magic, all it does is popf > > followed by ret. The popf usually enables interrupts when it restores the > > interrupt flag's state. It might still be a hardware problem in the chipset, > > esp. since it always happens on a logical CPU. The fact that no other boxes > > in the field besides the two identical boxes you have have demonstrated this > > problem makes me very suspicious with respect to the hardware. > > > > Well, the real question is what happens in when the interrupt context > has to contest on the proc lock in ast(). What goes to sleep, and how This never happens, because ast() is never called in interrupt context. > it wake up? Does the interrupt context have a real process/thread > associated with it, or does it pretend to be curthread, or what? Since > the whole point of ithreads was to allow sleep locks in interrupt > handlers, isn't this a major violation? ast() is only called on return to user mode. This implies that curthread is a user thread (the one returning to user mode). It can never be an ithread. Most ast()s are on return from syscalls. Some are on return from interrupts, but these are best thought of as being in process context too. The interrupt has been completely handled (*) except for the final return from it. As an implementation detail, ast() is called directly before returning. I believe entry to ast() was originally in hardware on VAXes. There was a hardware instruction to schedule an additional trap on return. We could still do this in hardware on i386's at least by scheduling a trace trap, but a direct call is better. The SMP case still needs hardware (an IPI) for non-current CPUs. (*) Except possibly for magic and bugs. E.g., the iret after an NMI is special on at least some i386's, but is not handled right. Bruce