From owner-freebsd-current@FreeBSD.ORG Thu Jun 24 19:14:24 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 9D74216A4CE; Thu, 24 Jun 2004 19:14:24 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E7E743D49; Thu, 24 Jun 2004 19:14:24 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i5OJE7x7054100; Thu, 24 Jun 2004 12:14:07 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i5OJE7Ae054099; Thu, 24 Jun 2004 12:14:07 -0700 (PDT) (envelope-from dillon) Date: Thu, 24 Jun 2004 12:14:07 -0700 (PDT) From: Matthew Dillon Message-Id: <200406241914.i5OJE7Ae054099@apollo.backplane.com> To: John Baldwin References: <200406241438.29489.jhb@FreeBSD.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: Thu, 24 Jun 2004 19:14:24 -0000 :Nothing pending or currently executing. Its ok for this one to be halted :(CPU3), but neither CPU2 nor CPU1 should be halted. CPU2 claims to be :executing Xhardclock which does an EOI in < 20 instructions after it starts. :Does the ISR for CPU 2 clear if you let it continue for a bit? : :-- :John Baldwin <>< http://www.FreeBSD.org/~jhb/ :"Power Users Use the Power to Serve" = http://www.FreeBSD.org I wonder if something in the ACPI code is blocking - allowing queued interrupts to be processed and breaking the 'cli' atomicy. But that would not explain why the ISR shows a delivered but un-EOI'd interrupt. Another possibility is that there is some sort of required DELAY before entering into HLT after calling the ACPI idle code. It is possible that whatever the ACPI idle code is doing to the cpu (e.g. delayed effect from power management adjustments) does not take effect quickly enough and a real interrupt is interrupting the HLT before the hw changes ACPI makes take effect. The changes then take effect in the middle of the real interrupt. This would account for the ISR state though I still don't understand how that cpu could return to the HLT without EOI'ing (maybe the reported instruction address is simply wrong?). I would try adding a DELAY(10) before the hlt, just to see if it has an effect. -Matt Matthew Dillon