From owner-freebsd-current Sat Apr 15 10:38:46 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA17947 for current-outgoing; Sat, 15 Apr 1995 10:38:46 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA17941 for ; Sat, 15 Apr 1995 10:38:43 -0700 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id KAA21617; Sat, 15 Apr 1995 10:38:41 -0700 From: Poul-Henning Kamp Message-Id: <199504151738.KAA21617@ref.tfs.com> Subject: Re: Memory init pattern To: uhclem@nemesis.lonestar.org (Frank Durda IV) Date: Sat, 15 Apr 1995 10:38:41 -0700 (PDT) Cc: freebsd-current@FreeBSD.org, uhclem@nemesis.lonestar.org In-Reply-To: from "Frank Durda IV" at Apr 15, 95 10:12:00 am Content-Type: text Content-Length: 1093 Sender: current-owner@FreeBSD.org Precedence: bulk > It is a good idea to at least initialize all of RAM that we plan to use > but I would pick a less annoying pattern. (Naturally there is some > low memory info like the CMOS size compute and other goodies that we should > utilize before we lay-waste to the below-640K areas, or perhaps we could > limit the re-write to above memory 1Meg, as that is where most of the > bad-inits usually occur.) > > Also, any pattern written must be unique across adjacent two 32-bit > values. In other words, don't write 0x12345678 and in the next 32 bits > write 0x12345678. You are setting yourself up for ghosting in 64/32-bit > system. You wouldn't believe how long it took to prove to SCO this was > happening on a 32/16 bit system, and we had the logic analyzer! > (If you want details on how this happens, send mail. I've written a few > dozen memory diags over the years.) :-( Hmm, how about writing one more ? -- Poul-Henning Kamp -- TRW Financial Systems, Inc. 'All relevant people are pertinent' && 'All rude people are impertinent' => 'no rude people are relevant'