From owner-freebsd-current Sun Apr 21 11:31:42 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA29149 for current-outgoing; Sun, 21 Apr 1996 11:31:42 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA29143 for ; Sun, 21 Apr 1996 11:31:39 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id EAA32380; Mon, 22 Apr 1996 04:30:03 +1000 Date: Mon, 22 Apr 1996 04:30:03 +1000 From: Bruce Evans Message-Id: <199604211830.EAA32380@godzilla.zeta.org.au> To: jdp@polstra.com, jkh@time.cdrom.com Subject: Re: Another 2.2-SNAP soon, folks? Cc: freebsd-current@FreeBSD.org Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >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 sent this to the wrong list: --- I have been debugging the kernel gzip and rebooting the test systems a lot. exec_gzip_imgact() works fine if the final vm_map_remove() is omitted. Otherwise it hangs in various places in vm_map_remove() doing harmless-looking memory accesses, except the vm_map_remove() works OK if it is called only on every second gzip exec (after the previous one has left suitable garbage). It looks like a reference counting problem. The mapping that causes the problem is particularly simple. --- It might be acceptable to simply skip the vm_map_remove() for the fixit version. The vm_map_remove() is for a 4K mmapped window on the input file. There seems to be no problem removing and reallocating this window every 4K for input files larger than 4K. Bruce