Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Jun 2002 10:28:00 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        David Wolfskill <david@catwhisker.org>
Cc:        des@FreeBSD.ORG, sheldonh@starjuice.net, current@FreeBSD.ORG
Subject:   Re: i386 tinderbox failure
Message-ID:  <200206271728.g5RHS0Yl041759@apollo.backplane.com>
References:   <200206271445.g5REjCY1015495@bunrab.catwhisker.org>

next in thread | previous in thread | raw e-mail | index | archive | help
    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 
					<dillon@backplane.com>


:>Date: Thu, 27 Jun 2002 16:33:36 +0200
:>From: Sheldon Hearn <sheldonh@starjuice.net>
:
:>> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206271728.g5RHS0Yl041759>