Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262019AbUJYUsk (ORCPT ); Mon, 25 Oct 2004 16:48:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262018AbUJYUs3 (ORCPT ); Mon, 25 Oct 2004 16:48:29 -0400 Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:2566 "EHLO pollux.ds.pg.gda.pl") by vger.kernel.org with ESMTP id S262043AbUJYUrE (ORCPT ); Mon, 25 Oct 2004 16:47:04 -0400 Date: Mon, 25 Oct 2004 21:47:01 +0100 (BST) From: "Maciej W. Rozycki" To: Andi Kleen Cc: Corey Minyard , linux-kernel@vger.kernel.org Subject: Re: Race betwen the NMI handler and the RTC clock in practially all kernels In-Reply-To: <20041025201758.GG9142@wotan.suse.de> Message-ID: References: <417D2305.3020209@acm.org.suse.lists.linux.kernel> <20041025201758.GG9142@wotan.suse.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1756 Lines: 36 On Mon, 25 Oct 2004, Andi Kleen wrote: > > It's not the dummy read that causes the problem. It's the index write > > that does. It can be solved pretty easily by not changing the index. It > > True. It has to be cached once. You mean once per write, don't you? The index is w/o, unfortunately. > > The use is correct. Bit #7 at I/O port 0x70 controls the NMI line > > pass-through flip-flop. "0" means "pass-through" and "1" means "force > > inactive." As the NMI line is level-driven and the NMI input is > > edge-triggered, the sequence is needed to regenerate an edge if another > > NMI arrives via the line (not via the APIC) while the handler is running. > > At least in the datasheet I'm reading (AMD 8111) it is just a global > enable/disable bit. The flip-flop is expected to be connected to the NMI input of the processor, which for systems using local APICs means their LINT1 inputs (I think it's broadcasted for all existing systems, although in principle only the BSP needs to be connected). But from the local APIC's point of view LINT1 is just another local interrupt line which may or may not be programmed for the NMI delivery mode and moreover, NMIs may arrive via the LINT0 input or from the performance counter interrupt if programmed so (this is the case with the NMI watchdog) or from another APIC as an IPI or an ordinary interrupt. These alternative sources are of course unaffected by the flip-flop unless you have a strange implementation of the local APIC. Maciej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/