From owner-freebsd-current@FreeBSD.ORG  Fri Jul  9 00:41:57 2004
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 7033016A4CE; Fri,  9 Jul 2004 00:41:57 +0000 (GMT)
Received: from mail.sandvine.com (sandvine.com [199.243.201.138])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 77C9243D2D; Fri,  9 Jul 2004 00:41:56 +0000 (GMT)
	(envelope-from gnagelhout@sandvine.com)
Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72)
	id <312Y51L4>; Thu, 8 Jul 2004 20:41:55 -0400
Message-ID: <FE045D4D9F7AED4CBFF1B3B813C85337054EC50F@mail.sandvine.com>
From: Gerrit Nagelhout <gnagelhout@sandvine.com>
To: 'John Baldwin' <jhb@FreeBSD.org>
Date: Thu, 8 Jul 2004 20:41:53 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
cc: kris@FreeBSD.org
cc: freebsd-current@FreeBSD.org
cc: Julian Elischer <julian@elischer.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
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jul 2004 00:41:57 -0000

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,

Gerrit