From owner-freebsd-current Sun Apr 21 09:40:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA25069 for current-outgoing; Sun, 21 Apr 1996 09:40:19 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id JAA25064 for ; Sun, 21 Apr 1996 09:40:16 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.6.12) with ESMTP id JAA25438; Sun, 21 Apr 1996 09:40:10 -0700 (PDT) Message-Id: <199604211640.JAA25438@austin.polstra.com> To: jkh@time.cdrom.com Cc: freebsd-current@freebsd.org Subject: Re: Another 2.2-SNAP soon, folks? In-reply-to: <5325.830102379@time.cdrom.com> Date: Sun, 21 Apr 1996 09:40:10 -0700 From: John Polstra Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Any objections / reports of known brokenness which would make this > a bad time for a SNAP? I would very much like to see gzipped executables working again. Without them, you can't use the fixit disk. (I know, I know, you can use it with an older install disk. But that's not quite the same.) I realize that the proper answer to a statement like this is, "Feel free to fix it yourself." I tried for almost a whole day. But I don't know the kernel well at all, and gzipped executables crash it without so much as a complaint on the console, let alone a bona-fide panic. So I was limited to the time-honored technique of sprinkling printfs throughout the offending code. I got some clues that way, but the results were very anomalous. In fact, they would seem to support Terry's hypothesis about the processor cache. (This was on a 486DX2, by the way.) I'd be happy to share what I learned, FWIW, with anyone who wants to try and fix gzipped executables. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth