Date: Mon, 25 Oct 2004 22:14:23 +0200
From: Andi Kleen <ak@suse.de>
To: Corey Minyard <minyard@acm.org>
Cc: Andi Kleen <ak@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: Race betwen the NMI handler and the RTC clock in practially all kernels
Message-ID: <20041025201423.GF9142@wotan.suse.de>
References: <417D2305.3020209@acm.org.suse.lists.linux.kernel> <p73u0sik2fa.fsf@verdi.suse.de> <417D5903.6090106@acm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <417D5903.6090106@acm.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1228
Lines: 29

On Mon, Oct 25, 2004 at 02:50:27PM -0500, Corey Minyard wrote:
> According to the comments in 2.4, this code causes the NMI to be 
> re-asserted if another NMI occurred while the NMI handler was running.  
> I have no idea how twiddling with these CMOS registers causes this to 
> happen, but that is supposed to be the intent.  I don't think it has 

I doubt it does anything useful on anything modern.

> anything to do with delays.

Old chipsets didn't like it when you did two accesses to related
registers in a row. Doing a dummy io inbetween causes an delay
that is long enough that fixes that. I think it was just an old fashioned 
way to write out_p(). You need some kind of dummy register for this
and the code used the wrong one.

> 
> I would like to know what this code really does before removing it.

It clears and sets the NMI enable bit of the chipset. IMHO it's useless
because no chipset should clear it. If anything you can just unconditionally
reenable it.

-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/