From owner-freebsd-current@FreeBSD.ORG Mon Jun 28 04:49:51 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 98B3716A4CE for ; Mon, 28 Jun 2004 04:49:51 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75F3343D31 for ; Mon, 28 Jun 2004 04:49:51 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 18595 invoked from network); 28 Jun 2004 04:49:46 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 28 Jun 2004 04:49:45 -0000 Received: from 131.106.56.214 (p58.n-nypop02.stsn.com [199.106.89.58]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i5S4nUfp099352; Mon, 28 Jun 2004 00:49:37 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Gerrit Nagelhout Date: Mon, 28 Jun 2004 00:50:38 -0400 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406280050.38628.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: 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: Mon, 28 Jun 2004 04:49:51 -0000 On Friday 25 June 2004 05:05 pm, Gerrit Nagelhout wrote: > John Baldwin wrote: > > Odd, all it does is eoi fast interrupts earlier. Oh, there's > > a bug. :( In > > the second hunk, change 'pic_disable_source' to 'pic_enable_source'. > > sigh...it just locked up again. I have included the current apic > dump for completeness. Is there anything other information that > would be useful to debug this problem? Hmm, it appears it is consistently CPU1 that thinks that IPI_HARDCLOCK is not being EOI'd. Can you try swapping the CPUs and see if the lockup moves from CPU1 to CPU3? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org