Messages in this thread | | | Date | Fri, 9 May 1997 17:01:56 +0200 | From | Martin Mares <> | Subject | Re: [PATCH] NMI trap revised (was Re: NMI errors in 2.0.30??) |
| |
Hi,
> 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).
Martin
| |