From owner-freebsd-current Thu Jun 27 10:28:10 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 6586137B401; Thu, 27 Jun 2002 10:28:03 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.12.3) with ESMTP id g5RHS2l1041896; Thu, 27 Jun 2002 10:28:02 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g5RHS0Yl041759; Thu, 27 Jun 2002 10:28:00 -0700 (PDT) (envelope-from dillon) Date: Thu, 27 Jun 2002 10:28:00 -0700 (PDT) From: Matthew Dillon Message-Id: <200206271728.g5RHS0Yl041759@apollo.backplane.com> To: David Wolfskill Cc: des@FreeBSD.ORG, sheldonh@starjuice.net, current@FreeBSD.ORG Subject: Re: i386 tinderbox failure References: <200206271445.g5REjCY1015495@bunrab.catwhisker.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It would be great if you guys could re-test with the pmap fix (/usr/src/sys/i386/i386/pmap.c r1.326). I believe that the pmap bug was to blame for all of these issues but I need verification before I have the comfort level necessary to do the MFC I intended to do. -Matt Matthew Dillon :>Date: Thu, 27 Jun 2002 16:33:36 +0200 :>From: Sheldon Hearn : :>> Wed Jun 26 19:00:10 PDT 2002 :>> /usr/libexec/ld-elf.so.1: /usr/bin/cvs: Shared object has no run-time symbol table : :>I got this testing the RMEM_LIMIT patches, but it only crops up after :>about an hour of heavy ports building. You'll get this for just any :>binary that uses mmap(). : :I managed to get it while building today's -CURRENT (running -CURRENT :form yesterday). : :Backing down to the previous day's kernel allowed me to get through the :build process. (It had died during "stage 4: populating :/usr/obj/usr/src/i386/usr/include," and I'm well byond that for the :present build -- I'm in the install phase.) : :>Unfortunately, I haven't had time to produce any useful debugging :>information, so I can't be sure it's really the RMEM_LIMIT patches. : :Well, the following is a list of each file under /usr/src/sys that :changed between the two kernels: : :U sys/conf/NOTES :U sys/conf/files :U sys/conf/options :U sys/ddb/db_examine.c :U sys/ddb/db_expr.c :U sys/i386/i386/pmap.c :U sys/kern/kern_exec.c :U sys/kern/kern_jail.c :U sys/kern/kern_module.c :U sys/kern/kern_subr.c :U sys/kern/uipc_cow.c :U sys/kern/uipc_jumbo.c :U sys/kern/uipc_socket.c :U sys/kern/uipc_syscalls.c :U sys/modules/ti/Makefile :U sys/net/if_media.c :U sys/netinet/ip_output.c :U sys/pci/if_ti.c :U sys/pci/if_tireg.h :U sys/pci/ti_fw.h :U sys/pci/ti_fw2.h :U sys/sparc64/include/pmap.h :U sys/sparc64/sparc64/bus_machdep.c :U sys/sparc64/sparc64/pmap.c :U sys/sys/jumbo.h :U sys/sys/mbuf.h :U sys/sys/resource.h :U sys/sys/socketvar.h :U sys/sys/tiio.h :U sys/sys/uio.h :U sys/ufs/ufs/ufs_readwrite.c :U sys/vm/device_pager.c :U sys/vm/uma_core.c :U sys/vm/vm_fault.c :U sys/vm/vm_map.c :U sys/vm/vm_map.h :U sys/vm/vm_mmap.c :U sys/vm/vm_object.c :U sys/vm/vm_object.h :U sys/vm/vm_page.c :U sys/vm/vm_page.h :U sys/vm/vm_unix.c : :so I have a fair degree of confidence that changes to some subset of the :above files was responsible. And this is on a PIII, so the sparc64 :files are unlikely to have been to blame.... :-} : :Cheers, :david (links to my resume at http://www.catwhisker.org/~david) :-- :David H. Wolfskill david@catwhisker.org :Trying to support or use Microsoft products makes about as much sense :as painting the outside of a house with watercolors. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message