Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262013AbUJYUtN (ORCPT ); Mon, 25 Oct 2004 16:49:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262062AbUJYUsz (ORCPT ); Mon, 25 Oct 2004 16:48:55 -0400 Received: from cantor.suse.de ([195.135.220.2]:648 "EHLO Cantor.suse.de") by vger.kernel.org with ESMTP id S262013AbUJYUsH (ORCPT ); Mon, 25 Oct 2004 16:48:07 -0400 Date: Mon, 25 Oct 2004 22:41:44 +0200 From: Andi Kleen To: Andi Kleen Cc: "Maciej W. Rozycki" , Corey Minyard , linux-kernel@vger.kernel.org Subject: Re: Race betwen the NMI handler and the RTC clock in practially all kernels II Message-ID: <20041025204144.GA27518@wotan.suse.de> 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 Content-Disposition: inline In-Reply-To: <20041025201758.GG9142@wotan.suse.de> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 874 Lines: 20 > > 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. I checked the Intel datasheets now. Problem is that they define this register as read-only, and the only way to access it works using a very chipset specific way (alternative LPC interface) So it's impossible to check the old value. The original code is the only way to do this (if it's even needed, Intel also doesn't say anything about this bit being a flip-flop). Only possible change would be to write an alternative index. -Andi - 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/