lkml.org 
[lkml]   [1997]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.538 / U:1.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site