From owner-aic7xxx Wed Jul 29 15:47:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA18707 for aic7xxx-outgoing; Wed, 29 Jul 1998 15:47:16 -0700 (PDT) (envelope-from owner-aic7xxx@FreeBSD.ORG) Received: from smtp.enteract.com (thor.enteract.com [206.54.252.9]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA18691 for ; Wed, 29 Jul 1998 15:47:05 -0700 (PDT) (envelope-from isely@enteract.com) Received: (qmail 25316 invoked from network); 29 Jul 1998 22:46:27 -0000 Received: from nathan.enteract.com (isely@207.229.129.3) by thor.enteract.com with SMTP; 29 Jul 1998 22:46:27 -0000 Date: Wed, 29 Jul 1998 17:46:37 -0500 (CDT) From: Mike Isely Reply-To: Mike Isely To: Chris Pirih cc: aic7xxx Mailing List , rgb@phy.duke.edu, Mike Isely Subject: Re: Puzzle for Doug... In-Reply-To: <3.0.5.32.19980729134413.0098e800@popserv.wolfenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aic7xxx@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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