Date: Wed, 29 Jul 1998 17:46:37 -0500 (CDT) From: Mike Isely <isely@enteract.com> To: Chris Pirih <proverbs@wolfenet.com> Cc: aic7xxx Mailing List <AIC7xxx@FreeBSD.ORG>, rgb@phy.duke.edu, Mike Isely <isely@pobox.com> Subject: Re: Puzzle for Doug... Message-ID: <Pine.BSI.3.95.980729173534.16529B-100000@nathan.enteract.com> In-Reply-To: <3.0.5.32.19980729134413.0098e800@popserv.wolfenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 29 Jul 1998, Chris Pirih wrote:
> At 11:27 AM 07/29/1998 -0400, Robert G. Brown wrote:
> >What if the memory was remapped to a nonexistent location? You write
> >to the location and there is nothing there. You read from the
> >location and get nulls -- obviously a parity violation but now
> >remapped to a location where the error comes up as NMI.
>
> I like that theory! There doesn't even have to be a write, just a
> read -- machines without parity/ECC memory would return 0xFF... or
> whatever, and machines with parity/ECC would NMI.
I agree now. Accessing memory-mapped devices in a parity-sensitive system
has got to be a sticky business. Obviously if you read a device register,
there's no parity information. Yet a memory access must be parity checked
(assuming of course the system supports it). Therefore the chipset has to
somehow know on an access-by-access basis what is going to have parity and
what isn't. If the code accesses what it thinks is a device location but
is in fact unmapped memory, what's the chipset going to do? Treat as
memory or device hardware? If it (randomly) decides that's memory well
there's a really good chance it's a parity error and then you get the NMI.
Note that in order for this theory to be right, such an access has to get
past the system's page tables first. The page tables usually stop such
abuse with a page-not-present fault which is converted by the system into
some kind of software error signal. That's why random bad memory accesses
usually result in SIGSEGV (for user mode) or a panic (for kernel mode).
So what's probably happened here is that something somewhere has decided
there must be something at that bad address, set up the page table(s)
appropriately, and punched through to the system bus, only to be rewarded
by a NMI-caused parity error because in fact there's nothing really there!
-Mike
| Mike Isely | PGP fingerprint
POSITIVELY NO | | 03 54 43 4D 75 E5 CC 92
UNSOLICITED JUNK MAIL! | isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8
| (spam-foiling address) |
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.980729173534.16529B-100000>