From owner-freebsd-alpha Tue Nov 27 6:23:40 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 41D9B37B503 for ; Tue, 27 Nov 2001 06:23:27 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id JAA03471; Tue, 27 Nov 2001 09:23:04 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id fAREMcw76783; Tue, 27 Nov 2001 09:22:38 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15363.41389.989266.267710@grasshopper.cs.duke.edu> Date: Tue, 27 Nov 2001 09:22:37 -0500 (EST) To: Wilko Bulte Cc: Thiemo Nordenholz , Falko Meyer , freebsd-alpha@FreeBSD.ORG Subject: Re: mprotect() takes quite long -- anyone knows this? In-Reply-To: <20011127151024.A3785@freebie.xs4all.nl> References: <3C03741A.55375021@yahoo.de> <20011127123654.A56998@mygiea.ham01.thiemo.net> <20011127151024.A3785@freebie.xs4all.nl> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Wilko Bulte writes: > On Tue, Nov 27, 2001 at 12:36:57PM +0100, Thiemo Nordenholz wrote: > > > > I think this can't be defective memory because this machine uses ECC-RAM > > > and you would see massive ECC-errors in this case. > > > > Do you know what FreeBSD does when an ECC error is encountered? Does it log > > it? Does it just silently discard the information? Can the kernel know about > > ECC corrective actions at all? I have no clue of all that... Another > > information I'd be happy to get :-) > > Kernels in general can know about ECC errors. Tru64 e.g. handles them. > So the hardware is there. I once had dodgy memory in a AS2100A which > FreeBSD crashed on. But Tru64 and VMS ran on the same hardware OK. > This was a while ago, I'm not sure if there have been changes in > this area. Tru64 is smart enough not to use memory the console marked as bad, but we're not. I've also heard that Tru64 has a memory tester that walks all of physical memory at bootup and if it finds bad pages, it puts them aside so they don't get used. This might explain why it sits there for so long when it boots, but before it probes devices.. In terms of actual uncorrectable ecc errors after the system is up & running, I think we handle it the same way -- we don't. After all, if you have a multi-bit error, there's not a lot that you can do to correct it. You can figure out who's using the page & kill the app if its dirty (or invalidate the page if its clean) but that's about all. I think Tru64 panic's with a processor uncorrectable machine check just like we do. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message