From owner-freebsd-current@FreeBSD.ORG Thu Jun 24 20:11:53 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 72E9A16A4CE for ; Thu, 24 Jun 2004 20:11:53 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C98443D54 for ; Thu, 24 Jun 2004 20:11:53 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 1422 invoked from network); 24 Jun 2004 20:11:33 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 24 Jun 2004 20:11:33 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i5OKBKjo074236; Thu, 24 Jun 2004 16:11:21 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Matthew Dillon Date: Thu, 24 Jun 2004 16:12:22 -0400 User-Agent: KMail/1.6 References: <200406241438.29489.jhb@FreeBSD.org> <200406241914.i5OJE7Ae054099@apollo.backplane.com> In-Reply-To: <200406241914.i5OJE7Ae054099@apollo.backplane.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406241612.22476.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: kris@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 20:11:53 -0000 On Thursday 24 June 2004 03:14 pm, Matthew Dillon wrote: > :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. The ACPI C1 state is just a normal hlt. Only states >= C2 are real ACPI-specific states. Gerritt, did these lockups start happening recently and are these boxes running -current or are they running 5.2.1? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org