From owner-freebsd-current@FreeBSD.ORG Sat Jul 10 12:11:52 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 9C3FE16A4CE; Sat, 10 Jul 2004 12:11:52 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9A2C43D2F; Sat, 10 Jul 2004 12:11:49 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.11] (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i6ACGobC014799; Sat, 10 Jul 2004 06:16:50 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <40EFDCEC.6080307@samsco.org> Date: Sat, 10 Jul 2004 06:11:24 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7) Gecko/20040702 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200407091314.07506.jhb@FreeBSD.org> In-Reply-To: <200407091314.07506.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org 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: Sat, 10 Jul 2004 12:11:52 -0000 John Baldwin wrote: > On Thursday 08 July 2004 08:41 pm, Gerrit Nagelhout wrote: > >>John Baldwin wrote: >> >>>I think it does handle the interrupt, but that the EOI is >>>somehow lost or >>>ignored,or that somehow we don't send an EOI in some edge case. >> >>I switched the 2 CPUs on the system, and the problem did not >>track the CPU, so it is unlikely to be a hardware problem. >>I've been looking through the interrupt code, and one thing >>seems very suspicious, and I am hoping that someone can shed >>some light on it ... ie whether it's legal or not. >>In apic_vector.s, some of the interrupt handlers (hardclock, >>cpuast, and a few others) call doreti. Under certain conditions, >>this can call ast(). The ast function can call PROC_LOCK, >>which is a sleep mutex. >>What would happen in this case? How could the interrupt >>possibly block? At this point, the interrupt handler has >>already called eoi, but not iret. Would the processor except >>other interrupts, or get stuck? >>Thanks, > > > 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 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? Scott