Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

Peter Jeremy wrote: > In my case, I have "WITH_META_MODE=yes" in /etc/src-env.conf and was > using "make buildworld" - which failed. The upgrade worked cleanly > when I manually deleted all the .meta files. If I get a round tuit, sys.mk is setup such that missing .meta file

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On 2017-May-24 20:21:54 +0300, Konstantin Belousov wrote: >No SIGSEGV etc, so I think that the effects seen are due to build system. >rm -rf obj/* is the safest trick, I believe. But the behaviour does indicate that meta mode is not doing the right thing under all

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On 2017-May-24 18:01:42 -0700, "Simon J. Gerraty" wrote: >Peter Jeremy wrote: >> as follows. My suspicion is that meta mode isn't seeing enough of the >> differences between the bootstrap and main build steps and so causing make >> to incorrectly skip

Re: Bug in make setting wrong MAKESYSPATH

Thomas Mueller wrote: > I go into /BETA1/usr/ports/ports-mgmt/synth , run > env MAKESYSPATH make all-depends-list I assume you mean MAKESYSPATH=something? otherwise env itself should vomit > and then it seems to work correctly with no syntax error in >

Re: 64-bit inodes (ino64) Status Update and Call for Testing

Hi Jilles, Thanks for bringing this up. And of course, thanks to kib@ for including the d_namlen size bump and for his work in driving the rest of this change through to completion. On Sun, May 21, 2017 at 5:14 AM, Jilles Tjoelker wrote: > We have another type in this area

Re: Bug in make setting wrong MAKESYSPATH

>From Simon J. Gerraty: > > Thomas Mueller wrote: > > For building the system, MAKESYSPATH should be $SRCDIR/share/mk , to be in > > sync. > > I tried "make -V MAKESYSPATH" from several SRCDIRs, and that's what > > happened. > Yes. If you look at share/mk/src.sys.env.mk

Re: svn commit: r318757 - head

On Wed, 24 May 2017 20:10:00 +0200, "O. Hartmann" wrote: > Am Wed, 24 May 2017 13:04:30 -0500 > Larry Rosenman schrieb: > > > On 5/24/17, 1:01 PM, "O. Hartmann" wrote: > > > > Am Wed, 24 May 2017 19:40:46 +0200 > >

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

Peter Jeremy wrote: > as follows. My suspicion is that meta mode isn't seeing enough of the > differences between the bootstrap and main build steps and so causing make > to incorrectly skip steps. I see a number of places in src/Makefile* where BUILD_TOOLS_META=.NOMETA is

Re: ino64 package fallout

On 24 May, Konstantin Belousov wrote: > On Wed, May 24, 2017 at 10:05:22AM -0700, Don Lewis wrote: >> I just upgraded by package build box and its poudriere jail to r318776 >> and ran into some significant package build fallout. > > There are several reviews that fix ports with most significant

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On 2017-May-24 08:47:41 -0700, Ngie Cooper wrote: >There was another report on the list about a stale MAKEOBJDIRPREFIX > causing someone grief. I think it's safe to say that meta mode and -DNO_CLEAN > might not work across this transition--in particular meta mode

Re: NFS client performance degradation when SMP enabled

What type of network interface do you have? The Intel 1G (em and igb) were switched over to the "iflib" framework a few months ago and that could be the cause. ___ freebsd-current@freebsd.org mailing list

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On Wed, May 24, 2017 at 01:42:39PM -0700, Simon J. Gerraty wrote: > David Wolfskill wrote: > > As far as I can tell, the "ld" command was: > > Since you have the .meta file, it should tell you exactly what the > command was and what path was actually exec'd And now that

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

Ngie Cooper wrote: > There was another report on the list about a stale > MAKEOBJDIRPREFIX causing someone grief. Pointer? What does stale MAKEOBJDIRPREFIX mean? >I think it's safe to say that > meta mode and -DNO_CLEAN might not work across this transition--in >

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

David Wolfskill wrote: > As far as I can tell, the "ld" command was: Since you have the .meta file, it should tell you exactly what the command was and what path was actually exec'd ___ freebsd-current@freebsd.org mailing list

NFS client performance degradation when SMP enabled

Without boring you with too much detail, I have been doing development/testing of pNFS stuff (mostly server side) on a 1 year old kernel (Apr. 12, 2016). When I recently carried the code across to a recent kernel, everything seemed to work, but performance was much slower. After some fiddling

Re: svn commit: r318757 - head

On 5/24/17 1:17 PM, Cy Schubert wrote: > In message <1c1ab22c-60bf-4707-f635-8069aa1e0...@freebsd.org>, Bryan > Drewery wr > ites: >> This is an OpenPGP/MIME signed message (RFC 4880 and 3156) >> --sIw1a8MPU8obGIEqPMSjxuV84b026de6m >> Content-Type: multipart/mixed;

Re: svn commit: r318757 - head

In message <1c1ab22c-60bf-4707-f635-8069aa1e0...@freebsd.org>, Bryan Drewery wr ites: > This is an OpenPGP/MIME signed message (RFC 4880 and 3156) > --sIw1a8MPU8obGIEqPMSjxuV84b026de6m > Content-Type: multipart/mixed; boundary="8b3Tlc1Bt9VfscoFw6tX1N8B8aTeGubhr"; > protected-headers="v1" > From:

Re: ino64: desastrous update - recommendations not working!!!

In message <20170524192734.67a84...@thor.intern.walstatt.dynvpn.de>, "O. Hartma nn" writes: > --Sig_/4+3DjX6aWzM+U5.TkY0/Z6W > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > Am Wed, 24 May 2017 14:15:07 +0200 > "Hartmann, O."

Re: svn commit: r318757 - head

Am Wed, 24 May 2017 12:11:06 -0700 "Ngie Cooper (yaneurabeya)" schrieb: > > On May 24, 2017, at 11:10, O. Hartmann wrote: > > > > Am Wed, 24 May 2017 13:04:30 -0500 > > Larry Rosenman schrieb: > > … > > > I use the

Re: ino64: desastrous update - recommendations not working!!!

Am Wed, 24 May 2017 14:15:07 +0200 "Hartmann, O." schrieb: > On Wed, 24 May 2017 14:31:08 +0300 > Konstantin Belousov wrote: > > > On Wed, May 24, 2017 at 12:42:19PM +0200, Hartmann, O. wrote: > > > On almost every CURRENT that has been updated

Re: svn commit: r318757 - head

> On May 24, 2017, at 11:10, O. Hartmann wrote: > > Am Wed, 24 May 2017 13:04:30 -0500 > Larry Rosenman schrieb: … > I use the traditional "make" way (via portmaster) There were some reports about needing to do “make clean” before “make

Re: svn commit: r318757 - head

Am Wed, 24 May 2017 13:04:30 -0500 Larry Rosenman schrieb: > On 5/24/17, 1:01 PM, "O. Hartmann" wrote: > > Am Wed, 24 May 2017 19:40:46 +0200 > "O. Hartmann" schrieb: > > > Am Wed, 24 May 2017 12:28:51 -0500 >

Re: svn commit: r318757 - head

On 5/24/17, 1:01 PM, "O. Hartmann" wrote: Am Wed, 24 May 2017 19:40:46 +0200 "O. Hartmann" schrieb: > Am Wed, 24 May 2017 12:28:51 -0500 > Larry Rosenman schrieb: > > > I fixed my issues by

Re: svn commit: r318757 - head

Am Wed, 24 May 2017 19:40:46 +0200 "O. Hartmann" schrieb: > Am Wed, 24 May 2017 12:28:51 -0500 > Larry Rosenman schrieb: > > > I fixed my issues by force-rebuilding perl and all installed p5-* ports. > > > > > > > This isn't possible in my case

Re: svn commit: r318757 - head

-- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 On 5/24/17, 12:40 PM, "O. Hartmann" wrote: Am Wed, 24 May 2017 12:28:51 -0500

Re: svn commit: r318757 - head

Am Wed, 24 May 2017 12:28:51 -0500 Larry Rosenman schrieb: > I fixed my issues by force-rebuilding perl and all installed p5-* ports. > > This isn't possible in my case :-( lang/perl rebuilds all right, but every p5-* ports fails with [...] Checking if your kit is

Re: svn commit: r318757 - head

I fixed my issues by force-rebuilding perl and all installed p5-* ports. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281

Re: svn commit: r318757 - head

Am Wed, 24 May 2017 08:06:34 -0500 Larry Rosenman schrieb: > The initial failure: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=peripatus=2017-05-23%2019%3A17%3A42 > > I then recompiled perl, and got: > borg.lerctr.org /home/pgbuildfarm $ cd

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On Wed, May 24, 2017 at 08:15:09AM -0700, David Wolfskill wrote: > On Wed, May 24, 2017 at 07:20:01AM -0700, David Wolfskill wrote: > > ... > > > > I have updated /usr/src back to 318781, then started a new build. > > > So are you building stock 318781, or did you reverted r318750 ? > > > > Stock

Re: ino64 package fallout

On Wed, May 24, 2017 at 10:05:22AM -0700, Don Lewis wrote: > I just upgraded by package build box and its poudriere jail to r318776 > and ran into some significant package build fallout. There are several reviews that fix ports with most significant fallouts, lang/llvm39

Re: ino64 package fallout

On Wed, May 24, 2017 at 10:05:22AM -0700, Don Lewis wrote: > I just upgraded by package build box and its poudriere jail to r318776 > and ran into some significant package build fallout. > > devel/llvm40:build: > > > /usr/bin/c++ -DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -O2 -pipe >

Re: Bug in make setting wrong MAKESYSPATH

Thomas Mueller wrote: > For building the system, MAKESYSPATH should be $SRCDIR/share/mk , to be in > sync. > > I tried "make -V MAKESYSPATH" from several SRCDIRs, and that's what happened. Yes. If you look at share/mk/src.sys.env.mk it detects that it was found via a .../

ino64 package fallout

I just upgraded by package build box and its poudriere jail to r318776 and ran into some significant package build fallout. devel/llvm40:build: /usr/bin/c++ -DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

> On May 24, 2017, at 08:15, David Wolfskill wrote: ... > It completed successfully and a reboot shows: > > FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #354 > r318781M/318781:1200031: Wed May 24 07:31:48 PDT 2017 >

Re: ERROR: ctfconvert: [...] has too many members: 1911 > 1023 _and_ ERROR: rc = -1 No entry found [dwarf_next_cu_header_c(61)]

24.05.2017 18:09, Dimitry Andric пишет: > On 24 May 2017, at 14:58, Boris Samorodov wrote: >> >> JFYI: Today I've got a bunch (as much as 63) of cftconvert errors >> while make buildkernel. There were no such errors tomorrow. The building >> machine is FreeBSD-amd64-r317665. >> >>

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On Wed, May 24, 2017 at 07:20:01AM -0700, David Wolfskill wrote: > ... > > > I have updated /usr/src back to 318781, then started a new build. > > So are you building stock 318781, or did you reverted r318750 ? > > Stock 318781 [*]. I revert as a (nearly) last resort. :-) > > > > While it has

Re: ERROR: ctfconvert: [...] has too many members: 1911 > 1023 _and_ ERROR: rc = -1 No entry found [dwarf_next_cu_header_c(61)]

On 24 May 2017, at 14:58, Boris Samorodov wrote: > > JFYI: Today I've got a bunch (as much as 63) of cftconvert errors > while make buildkernel. There were no such errors tomorrow. The building > machine is FreeBSD-amd64-r317665. > > Errors are not fatal, so the kernel has build

Re: ino64: desastrous update - recommendations not working!!!

On Wed, May 24, 2017 at 4:42 AM, Hartmann, O. wrote: > On almost every CURRENT that has been updated according to UPDATING > entry 2017-05-23 regarding ino64, the recommended update process ends > up in a desaster or, if the old environemnt/kernel is intact, itr > doesn't

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On Wed, May 24, 2017 at 05:16:38PM +0300, Konstantin Belousov wrote: > On Wed, May 24, 2017 at 06:59:05AM -0700, David Wolfskill wrote: > > On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote: > > > If build of r318739 succed, can you try, please, to rebuild the current > > >

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On Wed, May 24, 2017 at 06:59:05AM -0700, David Wolfskill wrote: > On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote: > > If build of r318739 succed, can you try, please, to rebuild the current > > latest sources, but now with reverted r318750 ? > > It did complete successfully.

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote: > ... > > (lldb) bt > > * thread #1, name = 'ld', stop reason = signal SIGSEGV > > * frame #0: 0x > > (lldb) > > > > which isn't entirely unexpected, I suppose, given the nature of SIGSEGV. > Useful gdb is in

Re: svn commit: r318757 - head

The initial failure was NOT, except that the PostgreSQL build builds a PL/Perl interpreter that MIGHT Be considered that. It was unexpected. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 17716 Limpia

Re: ino64: desastrous update - recommendations not working!!!

On Wed, 24 May 2017 14:31:08 +0300 Konstantin Belousov wrote: > On Wed, May 24, 2017 at 12:42:19PM +0200, Hartmann, O. wrote: > > On almost every CURRENT that has been updated according to UPDATING > > entry 2017-05-23 regarding ino64, the recommended update process > > ends

Re: svn commit: r318757 - head

On Wed, May 24, 2017 at 08:06:34AM -0500, Larry Rosenman wrote: > The initial failure: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=peripatus=2017-05-23%2019%3A17%3A42 > > I then recompiled perl, and got: > borg.lerctr.org /home/pgbuildfarm $ cd /home/pgbuildfarm/bin/latest && >

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On Wed, May 24, 2017 at 06:01:43AM -0700, David Wolfskill wrote: > On Wed, May 24, 2017 at 02:10:08PM +0200, Dimitry Andric wrote: > > ... > > > building special pic c library > > > --- libc.so.7 --- > > > cc: error: unable to execute command: Segmentation fault (core dumped) > > > cc: error:

Re: The futur of the roff toolchain

Mr. McKusick, Kirk McKusick wrote: |Thanks for all your work on this project. As I still use roff for |our book and for many of my presentations, it is a topic of interest |to me. That said, I am fine with roff dropping out of base as I can |easily enough bring it in

Re: base packages, ino64 and upgrade

24.05.2017 16:00, Glen Barber пишет: > On Wed, May 24, 2017 at 03:47:47PM +0300, Boris Samorodov wrote: >> Hi All, >> >> Does anyone know the procedure to upgrade for those using base packages? > > 'pkg install FreeBSD-kernel-generic' (or whatever your kernel package is > called), reboot, 'pkg

Re: svn commit: r318757 - head

The initial failure: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=peripatus=2017-05-23%2019%3A17%3A42 I then recompiled perl, and got: borg.lerctr.org /home/pgbuildfarm $ cd /home/pgbuildfarm/bin/latest && ./run_branches.pl --run-all --config=/home/pgbuildfarm/conf/build-farm.conf

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On Wed, May 24, 2017 at 02:10:08PM +0200, Dimitry Andric wrote: > ... > > building special pic c library > > --- libc.so.7 --- > > cc: error: unable to execute command: Segmentation fault (core dumped) > > cc: error: linker command failed due to signal (use -v to see invocation) > > ***

Re: base packages, ino64 and upgrade

On Wed, May 24, 2017 at 03:47:47PM +0300, Boris Samorodov wrote: > Hi All, > > Does anyone know the procedure to upgrade for those using base packages? > 'pkg install FreeBSD-kernel-generic' (or whatever your kernel package is called), reboot, 'pkg upgrade'. Glen signature.asc Description:

ERROR: ctfconvert: [...] has too many members: 1911 > 1023 _and_ ERROR: rc = -1 No entry found [dwarf_next_cu_header_c(61)]

Hi All, JFYI: Today I've got a bunch (as much as 63) of cftconvert errors while make buildkernel. There were no such errors tomorrow. The building machine is FreeBSD-amd64-r317665. Errors are not fatal, so the kernel has build successfully. I didn't dare to try to install it yet. -- WBR, Boris

base packages, ino64 and upgrade

Hi All, Does anyone know the procedure to upgrade for those using base packages? -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On Wed, May 24, 2017 at 04:59:31AM -0700, David Wolfskill wrote: > Yesterday's in-place src update (r318606 -> r318739) was a bit more > "interesting" than usual; as has been noted elsewhere, it really is > necessary to boot the new kernel before the "make installworld" > completes successfully.

Re: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

On 24 May 2017, at 13:59, David Wolfskill wrote: > > Yesterday's in-place src update (r318606 -> r318739) was a bit more > "interesting" than usual; as has been noted elsewhere, it really is > necessary to boot the new kernel before the "make installworld" > completes

ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

Yesterday's in-place src update (r318606 -> r318739) was a bit more "interesting" than usual; as has been noted elsewhere, it really is necessary to boot the new kernel before the "make installworld" completes successfully. That said, it ("make installworld") did complete successfully, and a

Re: ino64: desastrous update - recommendations not working!!!

On Wed, May 24, 2017 at 12:42:19PM +0200, Hartmann, O. wrote: > On almost every CURRENT that has been updated according to UPDATING > entry 2017-05-23 regarding ino64, the recommended update process ends > up in a desaster or, if the old environemnt/kernel is intact, itr > doesn't work. > >

ino64: desastrous update - recommendations not working!!!

On almost every CURRENT that has been updated according to UPDATING entry 2017-05-23 regarding ino64, the recommended update process ends up in a desaster or, if the old environemnt/kernel is intact, itr doesn't work. Procedure: make -jX buildworld buildkernel [successful] make installkernel

Re: svn commit: r318757 - head

On Tue, May 23, 2017 at 04:46:14PM -0500, Larry Rosenman wrote: > My PostgreSQL buildfarm animal BROKE with this change until I force rebuilt > lang/perl5.24 > and all my p5-* ports. So what was the symptoms and the error, exactly ? A lot of efforts were spent to ensure that _consistent_ set of

Re: Bug in make setting wrong MAKESYSPATH

>From Simon J. Gerraty: > Thomas Mueller wrote: > > It seems to me that MAKESYSPATH should match the host building system > > FreeBSD version. > Which would only be correct if building the same version of FreeBSD as > is running on the host. > Many folk work on