Date: Mon, 12 Jun 1995 07:52:21 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Cc: gibbs@freefall.cdrom.com, evanc@synapse.net, hackers@freebsd.org Subject: Re: Problem with 2940 Message-ID: <199506121152.HAA26421@hda.com> In-Reply-To: <199506120055.RAA01675@gndrsh.aac.dev.com> from "Rodney W. Grimes" at Jun 11, 95 05:55:18 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Rodney W. Grimes writes: > > > Or display hardware that is adding a bit to the character, or main > memory (do you have 36 bit simms and a chip set that does memory > parity creation and checking)? I find that it is very hard to believe > you even got far enough to get the system booted if the data was really > this way in memory or on disk, all your binaries should be corrupt. > > This also tends to rule out the cache, as your binaries should be blowing > chunks all over the place (or maybe they are and you failed to mention > that). > > I am really really suspecting display hardware here, can you telnet in > and see if the files look fine over a telnet connection???? > > Do cksums on the files match those from a good system?? > I'm also surprised that he managed to post that message yet sees this type of failure in the text files. Recall that he says that if he re-extracts the files and they come out OK they stay OK. The failure is consistent with a given file. That seems to eliminate anything outside of the disk-memory-disk loop. -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506121152.HAA26421>