Re: [PATCH] NMI trap revised (was Re: NMI errors in 2.0.30??)

Martin Mares (
Fri, 9 May 1997 17:01:56 +0200


> Also, I wouldn't depend on "modern" motherboards doing the same thing from one
> revision to another.

> I don't think we should even read these bits because we don't *know* if they are
> valid. Only the use and the motherboard know whether parity or non-parity RAM is
> installed.

The bits 6 and 7 were originally defined as 8255 port A (0x60) bank switches
and keyboard acknowledge in the XT. The bus check / memory parity error bits
were present at bits 6 and 7 of 8255 port C (0x62), not depending on the port
C bank switch (0x61 bit 2). On the AT, lots of those bits have been discontinued
since the keyboard handling became completely different and the remaining
bits of ports B and C were folded to single port 0x61 and remapped, so the
enable bits are present as bits 2 and 3 and the error reports bits are bits
6 and 7.

After studying lots of specs and testing it on several motherboards, it
seems that those bits are implemented almost everywhere and hard-wired to zeroes
on the remaining MB's. We probably should honor them and report the reason
to the user if we find any.

> This is really an issue about where hardware initialization should occur. The
> real-mode setup.S seems to be the intended place to do this sort of thing, but
> very few people like writing assembler code so it tends to clutter up the kernel
> proper. I have a few ideas about this. Maybe something will happen in a few
> weeks.

We probably don't have any hardware to be initialized as we must not touch
the enables (see the previous discussion).