From owner-freebsd-bugs Tue Jun 6 07:57:27 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id HAA23013 for bugs-outgoing; Tue, 6 Jun 1995 07:57:27 -0700 Received: from bunyip.cc.uq.oz.au (bunyip.cc.uq.oz.au [130.102.2.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id HAA23004 for ; Tue, 6 Jun 1995 07:57:24 -0700 Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au id <01945-0@bunyip.cc.uq.oz.au>; Wed, 7 Jun 1995 00:57:00 +1000 Received: from netfl15a.devetir.qld.gov.au by pandora.devetir.qld.gov.au (8.6.10/DEVETIR-E0.3a) with ESMTP id VAA19165 for ; Tue, 6 Jun 1995 21:06:37 +1000 Received: by netfl15a.devetir.qld.gov.au (8.6.8.1/DEVETIR-0.1) id LAA15596; Tue, 6 Jun 1995 11:04:31 GMT Date: Tue, 6 Jun 1995 11:04:31 GMT From: Stephen Hocking Message-Id: <199506061104.LAA15596@netfl15a.devetir.qld.gov.au> To: bugs@FreeBSD.org Subject: Re: 2.0.5-A: Very disheartening? Sender: bugs-owner@FreeBSD.org Precedence: bulk Might this not have something to do with unzipping something executable into memory and then failing to invalidate the cache entries for the memory you've just unzipped into? It sounds like a failure mode that you'd see with machines that have split I/D caches. I know it's easy to yell suggestions from the sidelines, but wouldn't it be a good idea to invalidate the cache after the image has been unzipped into memory? > >> Once 2.0.5-Alpha is installed and running on a non-compressed kernel, I can >> put the cache back in (or enable it) and everything still works, even with >> memory amounts that would panic or hang with the cache present. > >Just FYI, > >David, Poul and I (mostly holding coats and looking anxious) are all >looking into potential badness in the kzip/MFS code which could >explain this. If it comes to it, we may very well fall back to a 2 >floppy install! We're trying to look at all the options.. > >Something one way or the other will probably be decided in the next >2-3 days. > >If those actually seeing the problem would care at all to play with >kzip a little and see if they can't perhaps narrow the failure mode >down, I'd be more than pleased! It's a lot easier to frown at kernel >printfs() meaninfully when you can actually reproduce the failure >locally! :-) > > Jordan