Linux-kernel mailing list archive 2000-23,: Re: Why reassert ix86 NMI?

# Re: Why reassert ix86 NMI?

Maciej W. Rozycki (macro@ds2.pg.gda.pl)
Tue, 6 Jun 2000 18:10:05 +0200 (MET DST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Stephen C. Tweedie: "Re: New Linux 2.5 - 2.6 TODO (Alan Cox suggestsdelaying"
- Previous message: Chris Mason: "Re: (reiserfs) Re: New Linux 2.5 - 2.6 TODO (Alan Cox suggests"

On Tue, 6 Jun 2000, Richard B. Johnson wrote:

> The reads (marked dummy) of the CMOS data port don't do anything useful
> because there is already a long delay caused by the two index selections.

Just a safeguard for old i386s and similar crap.

> Leaving the CMOS index at 0x0f (the shutdown-byte offset) is not a
> really good idea. A power-failure can (read will) corrupt the byte
> at which the index is pointing. The result may be that upon subsequent
> boot, you may have to manually boot because the BIOS can get confused if
> the shutdown byte was any of the 'return-from-protected' mode bytes and it
> wasn't really what happened.

That's not a problem as BIOSes ask the 8042 keyboard controller (bit #2
of the status register; also in the command byte) whether it is a poweron
or cold reset startup or just a reboot. If it's the former, the shutdown
type is not checked at all and a normal POST procedure happens.

> If anybody is modifying the existing software in that file, I suggest:
>
> outb(0x80, 0x70); /* Wiggle NMI enable bit */
> outb(0x00, 0x70);

That would be dangerous as an NMI can happen in the middle of an RTC
memory access sequence. Corrupting the shutdown type is harmless, on the
other hand. Well, corrupting seconds is not a disaster, either, but the
clock may be used by the userland for some purpose.

Ideally, this RTC memory access could be protected with a spinlock with
the index value shadowed in a static variable (it's write-only, sigh). I
don't think it's worth the hassle, though, as we should never reach this
code in the first place. And if we do we'd better ask the operator to
reboot, anyway. Which we do, sort of.

    --
    +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
    +--------------------------------------------------------------+
    +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

- Next message: Stephen C. Tweedie: "Re: New Linux 2.5 - 2.6 TODO (Alan Cox suggestsdelaying"
- Previous message: Chris Mason: "Re: (reiserfs) Re: New Linux 2.5 - 2.6 TODO (Alan Cox suggests"