From owner-freebsd-current@FreeBSD.ORG Thu Jun 17 20:20:50 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 EF8F616A4CE for ; Thu, 17 Jun 2004 20:20:50 +0000 (GMT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id E993C43D45 for ; Thu, 17 Jun 2004 20:20:49 +0000 (GMT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Thu, 17 Jun 2004 16:20:15 -0400 Message-ID: From: Don Bowman To: 'Matthew Dillon' , Julian Elischer Date: Thu, 17 Jun 2004 16:20:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" cc: "'current@freebsd.org'" 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, 17 Jun 2004 20:20:51 -0000 From: Matthew Dillon [mailto:dillon@apollo.backplane.com] > :> In acpi_cpu_idle_c1, it does: > :> > :> sti > :> hlt > :> > :> shouldn't there be a NOP in there so that interrupts > :> are guaranteed on? > : > :I think your reading of it is right.. > :but I also think that if it was ALWAYS right we'd see processors > :go idle and never wake up again.... > :Since this doesn't seem to happen, maybe ther eis a bug in > the emulator? > : > :We can always add a nop I guess and see what happens.. > > No no no no! > > The whole point is for interrupts to be disabled when the > HLT instruction > *begins* execution (they're only disabled for one cycle). > Ummm, doesn't STI *enable* interrupts? so you're saying the point is that on entry to acpi_cpu_idle_c1, that the caller has done a CLI? And that the STI then enables interrupts during the HLT instruction? But if this is the case, my jtag emulator shows me that i'm executing 'HLT' and bit 9 of eflags is 0, which is why i don't come out. Is there a possible race condition on an HTT cpu here? I run into this problem rarely, more frequently now with a good test, and the box is locked up solid. The emulator shows me that only 1 processor is still alive, and the others are in the _c1 idle. The processor that's alive has no interrupts routed to it, and it has nothing to do, so it keeps spinning. The system never wakes up, the other 3 stay in _c1, and have interrupts off. Suggestions on how i might be analyzing this wrong? --don