Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261259AbUJYUKe (ORCPT ); Mon, 25 Oct 2004 16:10:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261239AbUJYUKU (ORCPT ); Mon, 25 Oct 2004 16:10:20 -0400 Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:55568 "EHLO pollux.ds.pg.gda.pl") by vger.kernel.org with ESMTP id S261313AbUJYUHu (ORCPT ); Mon, 25 Oct 2004 16:07:50 -0400 Date: Mon, 25 Oct 2004 21:07:42 +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: Message-ID: References: <417D2305.3020209@acm.org.suse.lists.linux.kernel> 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: 1737 Lines: 39 On Mon, 25 Oct 2004, Andi Kleen wrote: > > They traced it down to the following code in arch/kernel/traps.c (now > > in include/asm-i386/mach-default/mach_traps.c): > > > > outb(0x8f, 0x70); > > inb(0x71); /* dummy */ > > outb(0x0f, 0x70); > > inb(0x71); /* dummy */ > > Just use a different dummy register, like 0x80 which is normally used > for delaying IO (I think that is what the dummy access does) 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 may be done if an auxiliary variable is used and other users of the index cooperate. The dummy read isn't really necessary, but of course someone broke their RTC access logic, so it was added as a workaround. But then the firmware may screw it up if it changes the index from within the SMM. > But I'm pretty sure this NMI handling is incorrect anyways, its > use of bits doesn't match what the datasheets say of modern x86 > chipsets say. Perhaps it would be best to just get rid of > that legacy register twiddling completely. 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. 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/