From owner-freebsd-hackers Wed Jun 7 12:39:17 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA02423 for hackers-outgoing; Wed, 7 Jun 1995 12:39:17 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA02417 for ; Wed, 7 Jun 1995 12:39:14 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA03556; Mon, 5 Jun 95 13:50:08 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9506051950.AA03556@cs.weber.edu> Subject: Re: 2.0.5-A: Very disheartening? To: davidg@Root.COM Date: Mon, 5 Jun 95 13:50:07 MDT Cc: jgreco@brasil.moneng.mei.com, hackers@freebsd.org In-Reply-To: <199506051743.KAA07302@corbin.Root.COM> from "David Greenman" at Jun 5, 95 10:43:40 am X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@freebsd.org Precedence: bulk > > >Jordan, it does seem like there's something that's not quite kosher with > >2.0.5-A, and it has nothing to do with the floppies, as far as I can tell. > >I now have two systems that are definitely unstable - two entirely different > >types of systems, at that - and both have run earlier revisions of FreeBSD 2 > >and taken heavy poundings with relative grace for over half a year now. > > Considering the kind of extensive testing that I and others have been doing > over the last 2 months, and the relative few changes that have been made to > the kernel (especially in areas that might make a difference in the kind of > problems that you're seeing), I must conclude that the problem is specific to > both your configuration and the way that the installation works. I think there > is some kind of quirk in the kernel gziping and/or compressed MFS that is > being used in the install process that is causing the problem. > I am interested in working with you and others to diagnose and fix the > problem, but I have very little to go by at the moment. Any information that > you can provide about your hardware and the steps you took (such as disabling > or not disabling devices in userconfig, etc.), is escential. I suggest a binary search using deltas. Basically, there are CVS tags for snap revisions. Pull out a kernel source tree and include directory for the earliest snap. Then binary search it down to find the change-of-death. It will take some time, but it will find the problem (log2(n)+1 attempts, to be precise, where 'n' is the number of 2.0 revisions). Unfortunately, it's not that easy to get a full CVS history anywhere but WC, so the work will probably have to be done on thud or freefall. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.