From owner-freebsd-ppc@freebsd.org Sun Jul 2 02:42:20 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7700D9A4AF for ; Sun, 2 Jul 2017 02:42:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A55827BC16 for ; Sun, 2 Jul 2017 02:42:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15511 invoked from network); 2 Jul 2017 02:42:13 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 Jul 2017 02:42:13 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sat, 01 Jul 2017 22:42:13 -0400 (EDT) Received: (qmail 27971 invoked from network); 2 Jul 2017 02:42:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Jul 2017 02:42:13 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8EF97EC893D; Sat, 1 Jul 2017 19:42:12 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r320521 (e.g.): another powerpc64 problem: programs using fgets crash trying to store address over code instead of into __cleanup_info__ Message-Id: Date: Sat, 1 Jul 2017 19:42:11 -0700 To: Konstantin Belousov , FreeBSD PowerPC ML , FreeBSD Current , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 02:42:21 -0000 [Note: this is from a amd64 -> powerpc64 cross-build based on system clang 4 instead of gcc 4.2.1. I'm building a gcc 4.2.1 based system currently so that I can test a more standard configuration. But I'm one of the ones that experiments with finding things to report for clang targeting powerpc64 and powerpc.] powerpc64 is having programs crash with an attempt to store addresses over code instead of into __cleanup_info__ when fgets is used. ntpd is an example. As is sshd (although I've looked at its details less). Building up the context for this claim. . . public declaration: struct _pthread_cleanup_info { __uintptr_t pthread_cleanup_pad[8]; }; private declaration: struct pthread_cleanup { struct pthread_cleanup *prev; void (*routine)(void *); void *routine_arg; int onheap; }; ntpd and sshd die with segmentation faults in: void __pthread_cleanup_push_imp(void (*routine)(void *), void *arg, struct _pthread_cleanup_info *info) { struct pthread *curthread =3D _get_curthread(); struct pthread_cleanup *newbuf; newbuf =3D (void *)info; newbuf->routine =3D routine; newbuf->routine_arg =3D arg; newbuf->onheap =3D 0; newbuf->prev =3D curthread->cleanup; curthread->cleanup =3D newbuf; } at the statement: newbuf->routine =3D routine; But it turns out that the bt is like: __pthread_cleanup_push_imp(routine=3D0x507b1248 = <__stdio_cancel_cleanup>, arg=3D0x0, info=3D0x509eaaf4) __pthread_cleanup_push_imp_int(p0=3D0x507b1248,p1=3D0x0) fgets (buf=3D0x51415000 "", n=3D511, fp=3D0x507d4c40) . . . Note the 2 arguments to __pthread_cleanup_push_imp_int when called from fgets but the 3 arguemnts to __pthread_cleanup_push_imp . . . fgets uses FLOCK_CANCELSAFE(fp) : #define FLOCKFILE_CANCELSAFE(fp) = \ { = \ struct _pthread_cleanup_info __cleanup_info__; = \ if (__isthreaded) { = \ _FLOCKFILE(fp); = \ ___pthread_cleanup_push_imp( = \ __stdio_cancel_cleanup, (fp), = \ &__cleanup_info__); = \ } else { = \ ___pthread_cleanup_push_imp( = \ __stdio_cancel_cleanup, NULL, = \ &__cleanup_info__); = \ } = \ { #define FUNLOCKFILE_CANCELSAFE() = \ (void)0; = \ } = \ ___pthread_cleanup_pop_imp(1); = \ } where here the NULL case is in use. 3 arguments. But: STUB_FUNC2(__pthread_cleanup_push_imp, PJT_CLEANUP_PUSH_IMP, void, = void*, void *); which is use of: #define STUB_FUNC2(name, idx, ret, p0_type, p1_type) \ static ret FUNC_EXP(name)(p0_type, p1_type) __used; \ static ret FUNC_INT(name)(p0_type, p1_type) __used; \ WEAK_REF(FUNC_EXP(name), name); \ WEAK_REF(FUNC_INT(name), __CONCAT(_, name)); \ typedef ret (*FUNC_TYPE(name))(p0_type, p1_type); \ static ret FUNC_EXP(name)(p0_type p0, p1_type p1) \ { \ FUNC_TYPE(name) func; \ func =3D (FUNC_TYPE(name))__thr_jtable[idx][0]; \ return (func(p0, p1)); \ } \ static ret FUNC_INT(name)(p0_type p0, p1_type p1) \ { \ FUNC_TYPE(name) func; \ func =3D (FUNC_TYPE(name))__thr_jtable[idx][1]; \ return (func(p0, p1)); \ } so only 2 arguments to func (i.e., __pthread_cleanup_push_imp here). Compared to: ___pthread_cleanup_push_imp( = \ __stdio_cancel_cleanup, NULL, = \ &__cleanup_info__); = \ As a result junk is used instead of &__cleanup_info__. On powerpc64 it happens to be the address of ___pthread_cleanup_push_imp that happens to be in r5 (normally the third argument) at the time. So: newbuf->routine =3D routine; tries to replace the first instruction of ___pthread_cleanup_push_imp . As far as I can tell what should be used is: =20 #define STUB_FUNC3(name, idx, ret, p0_type, p1_type, p2_type) \ static ret FUNC_EXP(name)(p0_type, p1_type, p2_type) __used; \ static ret FUNC_INT(name)(p0_type, p1_type, p2_type) __used; \ WEAK_REF(FUNC_EXP(name), name); \ WEAK_REF(FUNC_INT(name), __CONCAT(_, name)); \ typedef ret (*FUNC_TYPE(name))(p0_type, p1_type, p2_type); \ static ret FUNC_EXP(name)(p0_type p0, p1_type p1, p2_type p2) \ { \ FUNC_TYPE(name) func; \ func =3D (FUNC_TYPE(name))__thr_jtable[idx][0]; \ return (func(p0, p1, p2)); \ } \ static ret FUNC_INT(name)(p0_type p0, p1_type p1, p2_type p2) \ { \ FUNC_TYPE(name) func; \ func =3D (FUNC_TYPE(name))__thr_jtable[idx][1]; \ return (func(p0, p1, p2)); \ } with the p2_type being: struct _pthread_cleanup_info * but I'm not expert in this code. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Jul 2 03:33:52 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96B94D9B88D for ; Sun, 2 Jul 2017 03:33:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 517C37D898 for ; Sun, 2 Jul 2017 03:33:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3071 invoked from network); 2 Jul 2017 03:33:50 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 Jul 2017 03:33:50 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sat, 01 Jul 2017 23:33:50 -0400 (EDT) Received: (qmail 2110 invoked from network); 2 Jul 2017 03:33:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Jul 2017 03:33:50 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A4495EC9366; Sat, 1 Jul 2017 20:33:49 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320521 (e.g.): another powerpc64 problem: programs using fgets crash trying to store address over code instead of into __cleanup_info__ Date: Sat, 1 Jul 2017 20:33:49 -0700 References: To: FreeBSD PowerPC ML , FreeBSD Current , freebsd-hackers@freebsd.org In-Reply-To: Message-Id: <87FABF66-3023-47E4-8F8F-6E76B7B84046@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 03:33:52 -0000 [I've now got a route to get information from the old PowerMac so-called "Quad Core" despite sshd being broken. So I add gdb output material as evidence to go with the more source code level analysis from before.] On 2017-Jul-1, at 7:42 PM, Mark Millard wrote: > [Note: this is from a amd64 -> powerpc64 cross-build based > on system clang 4 instead of gcc 4.2.1. I'm building a > gcc 4.2.1 based system currently so that I can test > a more standard configuration. But I'm one of the ones > that experiments with finding things to report for > clang targeting powerpc64 and powerpc.] >=20 > powerpc64 is having programs crash with an attempt > to store addresses over code instead of into > __cleanup_info__ when fgets is used. ntpd is an > example. As is sshd (although I've looked at > its details less). >=20 > Building up the context for this claim. . . >=20 > public declaration: >=20 > struct _pthread_cleanup_info { > __uintptr_t pthread_cleanup_pad[8]; > }; >=20 > private declaration: >=20 > struct pthread_cleanup { > struct pthread_cleanup *prev; > void (*routine)(void *); > void *routine_arg; > int onheap; > }; >=20 > ntpd and sshd die with segmentation faults in: >=20 > void > __pthread_cleanup_push_imp(void (*routine)(void *), void *arg, > struct _pthread_cleanup_info *info) > { > struct pthread *curthread =3D _get_curthread(); > struct pthread_cleanup *newbuf; >=20 > newbuf =3D (void *)info; > newbuf->routine =3D routine; > newbuf->routine_arg =3D arg; > newbuf->onheap =3D 0; > newbuf->prev =3D curthread->cleanup; > curthread->cleanup =3D newbuf; > } >=20 > at the statement: newbuf->routine =3D routine; >=20 > But it turns out that the bt is like: >=20 > __pthread_cleanup_push_imp(routine=3D0x507b1248 = <__stdio_cancel_cleanup>, arg=3D0x0, info=3D0x509eaaf4) > __pthread_cleanup_push_imp_int(p0=3D0x507b1248,p1=3D0x0) > fgets (buf=3D0x51415000 "", n=3D511, fp=3D0x507d4c40) > . . . >=20 > Note the 2 arguments to __pthread_cleanup_push_imp_int when called > from fgets but the 3 arguemnts to __pthread_cleanup_push_imp . . . >=20 > fgets uses FLOCK_CANCELSAFE(fp) : >=20 > #define FLOCKFILE_CANCELSAFE(fp) = \ > { = \ > struct _pthread_cleanup_info __cleanup_info__; = \ > if (__isthreaded) { = \ > _FLOCKFILE(fp); = \ > ___pthread_cleanup_push_imp( = \ > __stdio_cancel_cleanup, (fp), = \ > &__cleanup_info__); = \ > } else { = \ > ___pthread_cleanup_push_imp( = \ > __stdio_cancel_cleanup, NULL, = \ > &__cleanup_info__); = \ > } = \ > { > #define FUNLOCKFILE_CANCELSAFE() = \ > (void)0; = \ > } = \ > ___pthread_cleanup_pop_imp(1); = \ > } >=20 > where here the NULL case is in use. 3 arguments. >=20 > But: >=20 > STUB_FUNC2(__pthread_cleanup_push_imp, PJT_CLEANUP_PUSH_IMP, void, = void*, void *); >=20 > which is use of: >=20 > #define STUB_FUNC2(name, idx, ret, p0_type, p1_type) \ > static ret FUNC_EXP(name)(p0_type, p1_type) __used; \ > static ret FUNC_INT(name)(p0_type, p1_type) __used; \ > WEAK_REF(FUNC_EXP(name), name); \ > WEAK_REF(FUNC_INT(name), __CONCAT(_, name)); \ > typedef ret (*FUNC_TYPE(name))(p0_type, p1_type); \ > static ret FUNC_EXP(name)(p0_type p0, p1_type p1) \ > { \ > FUNC_TYPE(name) func; \ > func =3D (FUNC_TYPE(name))__thr_jtable[idx][0]; \ > return (func(p0, p1)); \ > } \ > static ret FUNC_INT(name)(p0_type p0, p1_type p1) \ > { \ > FUNC_TYPE(name) func; \ > func =3D (FUNC_TYPE(name))__thr_jtable[idx][1]; \ > return (func(p0, p1)); \ > } >=20 > so only 2 arguments to func (i.e., __pthread_cleanup_push_imp > here). >=20 > Compared to: >=20 > ___pthread_cleanup_push_imp( = \ > __stdio_cancel_cleanup, NULL, = \ > &__cleanup_info__); = \ >=20 > As a result junk is used instead of &__cleanup_info__. > On powerpc64 it happens to be the address of > ___pthread_cleanup_push_imp that happens to be > in r5 (normally the third argument) at the time. >=20 > So: >=20 > newbuf->routine =3D routine; >=20 > tries to replace the first instruction of > ___pthread_cleanup_push_imp . >=20 > As far as I can tell what should be used is: >=20 > #define STUB_FUNC3(name, idx, ret, p0_type, p1_type, p2_type) \ > static ret FUNC_EXP(name)(p0_type, p1_type, p2_type) __used; \ > static ret FUNC_INT(name)(p0_type, p1_type, p2_type) __used; \ > WEAK_REF(FUNC_EXP(name), name); \ > WEAK_REF(FUNC_INT(name), __CONCAT(_, name)); \ > typedef ret (*FUNC_TYPE(name))(p0_type, p1_type, p2_type); \ > static ret FUNC_EXP(name)(p0_type p0, p1_type p1, p2_type p2) \ > { \ > FUNC_TYPE(name) func; \ > func =3D (FUNC_TYPE(name))__thr_jtable[idx][0]; \ > return (func(p0, p1, p2)); \ > } \ > static ret FUNC_INT(name)(p0_type p0, p1_type p1, p2_type p2) \ > { \ > FUNC_TYPE(name) func; \ > func =3D (FUNC_TYPE(name))__thr_jtable[idx][1]; \ > return (func(p0, p1, p2)); \ > } >=20 > with the p2_type being: struct _pthread_cleanup_info * >=20 > but I'm not expert in this code. The backtrace for ntpd : Loaded symbols for /libexec/ld-elf.so.1 #0 __pthread_cleanup_push_imp (routine=3D0x50649248 = <__stdio_cancel_cleanup>, arg=3D0x0, info=3D0x50403af4) at = /usr/src/lib/libthr/thread/thr_clean.c:57 57 newbuf->routine =3D routine; (gdb) bt #0 __pthread_cleanup_push_imp (routine=3D0x50649248 = <__stdio_cancel_cleanup>, arg=3D0x0, info=3D0x50403af4) at = /usr/src/lib/libthr/thread/thr_clean.c:57 #1 0x0000000050603cbc in __pthread_cleanup_push_imp_int (p0=3D0x50649248,= p1=3D0x0) at /usr/src/lib/libc/gen/_pthread_stubs.c:283 #2 0x00000000505850a0 in vfprintf_l (fp=3D0x5066cc40, locale=3D, fmt0=3D0x50618523 "<%d>", ap=3D0xffffffffffffc150 "") at = printfcommon.h:75 #3 0x000000005058b034 in fprintf (fp=3D0x50649248, fmt=3D0x50403af4 = "`") at /usr/src/lib/libc/stdio/fprintf.c:55 #4 0x00000000505d22e0 in vsyslog (pri=3D, = fmt=3D0x50618523 "<%d>", ap=3D0xffffffffffffc150 "") at = /usr/src/lib/libc/gen/syslog.c:171 #5 0x00000000505d2138 in syslog (pri=3D1348768328, fmt=3D0x0) at = /usr/src/lib/libc/gen/syslog.c:128 #6 0x0000000010095eb8 in 00000016.plt_call.OBJ_sn2nid () #7 0x00000000100965e0 in 00000016.plt_call.OBJ_sn2nid () #8 0x000000001004624c in ntpdmain (argc=3D0, argv=3D) at /usr/src/contrib/ntp/ntpd/ntpd.c:602 #9 0x0000000010046020 in main (argc=3D1348768328, argv=3D0x0) at = /usr/src/contrib/ntp/ntpd/ntpd.c:394 #10 0x0000000010008b5c in 00000016.plt_call.OBJ_sn2nid () #11 0x00000000500e2b70 in .text () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 Note the expected use of r5 in the below. 0x50403af4 <__pthread_cleanup_push_imp>: nop 0x50403af8 <__pthread_cleanup_push_imp+4>: ld r6,18288(r2) 0x50403afc <__pthread_cleanup_push_imp+8>: cmpldi r6,0 0x50403b00 <__pthread_cleanup_push_imp+12>: beq- 0x50403b10 = <__pthread_cleanup_push_imp+28> 0x50403b04 <__pthread_cleanup_push_imp+16>: mr r6,r13 0x50403b08 <__pthread_cleanup_push_imp+20>: ld r6,-28680(r6) 0x50403b0c <__pthread_cleanup_push_imp+24>: b 0x50403b14 = <__pthread_cleanup_push_imp+32> 0x50403b10 <__pthread_cleanup_push_imp+28>: li r6,0 0x50403b14 <__pthread_cleanup_push_imp+32>: std r3,8(r5) 0x50403b18 <__pthread_cleanup_push_imp+36>: li r3,0 0x50403b1c <__pthread_cleanup_push_imp+40>: std r4,16(r5) 0x50403b20 <__pthread_cleanup_push_imp+44>: stw r3,24(r5) 0x50403b24 <__pthread_cleanup_push_imp+48>: ld r3,552(r6) 0x50403b28 <__pthread_cleanup_push_imp+52>: std r3,0(r5) 0x50403b2c <__pthread_cleanup_push_imp+56>: std r5,552(r6) 0x50403b30 <__pthread_cleanup_push_imp+60>: blr 0x50403b34 <__pthread_cleanup_push_imp+64>: .long 0x0 0x50403b38 <__pthread_cleanup_push_imp+68>: .long 0x0 0x50403b3c <__pthread_cleanup_push_imp+72>: .long 0x0 But note the use of r5 in the below: r5=3D=3D0x50403af4 results, replacing any potential r5 from the call to __pthread_cleanup_push_imp_int . Also r5's value is replaced without accessing or recording the value it the __pthread_cleanup_push_imp_int's start. r5 0x50403af4 1346386676 0x50603c80 <__pthread_cleanup_push_imp_int>: mflr r0 0x50603c84 <__pthread_cleanup_push_imp_int+4>: std r31,-8(r1) 0x50603c88 <__pthread_cleanup_push_imp_int+8>: std r0,16(r1) 0x50603c8c <__pthread_cleanup_push_imp_int+12>: stdu r1,-128(r1) 0x50603c90 <__pthread_cleanup_push_imp_int+16>: mr r31,r1 0x50603c94 <__pthread_cleanup_push_imp_int+20>: nop 0x50603c98 <__pthread_cleanup_push_imp_int+24>: std r2,40(r1) 0x50603c9c <__pthread_cleanup_push_imp_int+28>: ld r5,-22408(r2) 0x50603ca0 <__pthread_cleanup_push_imp_int+32>: ld r5,968(r5) 0x50603ca4 <__pthread_cleanup_push_imp_int+36>: ld r6,8(r5) 0x50603ca8 <__pthread_cleanup_push_imp_int+40>: ld r11,16(r5) 0x50603cac <__pthread_cleanup_push_imp_int+44>: ld r5,0(r5) 0x50603cb0 <__pthread_cleanup_push_imp_int+48>: mr r2,r6 0x50603cb4 <__pthread_cleanup_push_imp_int+52>: mtctr r5 0x50603cb8 <__pthread_cleanup_push_imp_int+56>: bctrl 0x50603cbc <__pthread_cleanup_push_imp_int+60>: ld r2,40(r1) 0x50603cc0 <__pthread_cleanup_push_imp_int+64>: addi r1,r1,128 0x50603cc4 <__pthread_cleanup_push_imp_int+68>: ld r0,16(r1) 0x50603cc8 <__pthread_cleanup_push_imp_int+72>: ld r31,-8(r1) 0x50603ccc <__pthread_cleanup_push_imp_int+76>: mtlr r0 0x50603cd0 <__pthread_cleanup_push_imp_int+80>: blr 0x50603cd4 <__pthread_cleanup_push_imp_int+84>: .long 0x0 0x50603cd8 <__pthread_cleanup_push_imp_int+88>: .long 0x0 0x50603cdc <__pthread_cleanup_push_imp_int+92>: .long 0x0 As the above code is set up for passing 2 arguments to __pthread_cleanup_push_imp (in r3 and r4) the above code uses r5 as a scratch register to hold the computed address of __pthread_cleanup_push_imp. This is not what __pthread_cleanup_push_imp is designed for in its use of r5. But in the below r5 was expected to be passed in to __pthread_cleanup_push_imp_int even though __pthread_cleanup_push_imp_int ignores the r5 value that is supplied. 0x505da750 : mflr r0 0x505da754 : std r31,-8(r1) 0x505da758 : std r0,16(r1) 0x505da75c : stdu r1,-256(r1) 0x505da760 : mr r31,r1 . . . 0x505da7b8 : bl 0x5048a9a0 = <00000017.plt_call._flockfile> 0x505da7bc : ld r2,40(r1) 0x505da7c0 : nop 0x505da7c4 : addi r5,r31,112 0x505da7c8 : mr r4,r29 0x505da7cc : b 0x505da7dc 0x505da7d0 : nop 0x505da7d4 : addi r5,r31,112 0x505da7d8 : li r4,0 0x505da7dc : ld r3,-23664(r2) 0x505da7e0 : bl 0x50603c80 = <__pthread_cleanup_push_imp_int> 0x505da7e4 : nop . . . Conclusion: __pthread_cleanup_push_imp_int should expect and handle 3 arguments and propagate all 3 to __pthread_cleanup_push_imp, not using r5 for the address of __pthread_cleanup_push_imp . I'll only give the backtrace for sshd. Also I've removed the garbage text shown for appname=3D in #8 and just used ". . .". Note that #0 through #2 are very similar to the above for ntpd: same problem for sshd. #0 __pthread_cleanup_push_imp (routine=3D0x507b1248 = <__stdio_cancel_cleanup>, arg=3D0x0, info=3D0x509eaaf4) at = /usr/src/lib/libthr/thread/thr_clean.c:57 #1 0x000000005076bcbc in __pthread_cleanup_push_imp_int (p0=3D0x507b1248,= p1=3D0x0) at /usr/src/lib/libc/gen/_pthread_stubs.c:283 #2 0x00000000507427e4 in fgets (buf=3D0x51415000 "", n=3D511, = fp=3D0x507d4c40) from /lib/libc.so.7 #3 0x00000000504e5268 in file_gets (bp=3D, = buf=3D0x507d4c40 "", size=3D0) at = /usr/src/crypto/openssl/crypto/bio/bss_file.c:461 #4 0x00000000504f0678 in BIO_gets (b=3D, = in=3D0x51415000 "", inl=3D) at = /usr/src/crypto/openssl/crypto/bio/bio_lib.c:303 #5 0x000000005047eaa8 in def_load_bio (conf=3D0x51415000, = in=3D0x5140e000, line=3D0x507d4c40) at = /usr/src/crypto/openssl/crypto/conf/conf_def.c:260 #6 0x000000005047f5b4 in def_load (conf=3D, = name=3D, line=3D0x51415000) at = /usr/src/crypto/openssl/crypto/conf/conf_def.c:207 #7 0x000000005047e518 in NCONF_load (conf=3D0x507b1248, file=3D0x0, = eline=3D0x509eaaf4) at = /usr/src/crypto/openssl/crypto/conf/conf_lib.c:265 #8 0x000000005041e97c in CONF_modules_load_file (filename=3D, appname=3D0x507c3da0 ". . .",=20 flags=3D1363206144) at = /usr/src/crypto/openssl/crypto/conf/conf_mod.c:179 #9 0x00000000503ce39c in OPENSSL_config (config_name=3D0x51415000 "") = at /usr/src/crypto/openssl/crypto/conf/conf_sap.c:90 #10 0x00000000500e6200 in Fssh_ssh_OpenSSL_add_all_algorithms () at = /usr/src/crypto/openssh/openbsd-compat/openssl-compat.c:78 #11 0x000000001000e0e0 in main (ac=3D0, av=3D) at = /usr/src/crypto/openssh/sshd.c:1553 #12 0x000000001000d4bc in 00000016.plt_call.Fssh_scan_scaled () #13 0x0000000050057b70 in .text () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Jul 2 03:41:00 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5378BD9BB73; Sun, 2 Jul 2017 03:41:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BDB837DDF1; Sun, 2 Jul 2017 03:40:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v623eqH4040937 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Jul 2017 06:40:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v623eqH4040937 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v623eq4j040934; Sun, 2 Jul 2017 06:40:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 2 Jul 2017 06:40:52 +0300 From: Konstantin Belousov To: Mark Millard Cc: FreeBSD PowerPC ML , FreeBSD Current , freebsd-hackers@freebsd.org Subject: Re: head -r320521 (e.g.): another powerpc64 problem: programs using fgets crash trying to store address over code instead of into __cleanup_info__ Message-ID: <20170702034052.GE1935@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 03:41:00 -0000 On Sat, Jul 01, 2017 at 07:42:11PM -0700, Mark Millard wrote: > powerpc64 is having programs crash with an attempt > to store addresses over code instead of into > __cleanup_info__ when fgets is used. ntpd is an > example. As is sshd (although I've looked at > its details less). Yes, I think you are right. I also see how this worked on amd64, where I tested the change. Try this. diff --git a/lib/libc/gen/_pthread_stubs.c b/lib/libc/gen/_pthread_stubs.c index 18a23216d50..fcf7ff04fed 100644 --- a/lib/libc/gen/_pthread_stubs.c +++ b/lib/libc/gen/_pthread_stubs.c @@ -279,10 +279,11 @@ STUB_FUNC2(pthread_kill, PJT_KILL, int, void *, int) STUB_FUNC2(pthread_setcancelstate, PJT_SETCANCELSTATE, int, int, void *) STUB_FUNC2(pthread_setcanceltype, PJT_SETCANCELTYPE, int, int, void *) STUB_FUNC(pthread_testcancel, PJT_TESTCANCEL, void) -STUB_FUNC1(__pthread_cleanup_pop_imp, PJT_CLEANUP_POP_IMP, int, int) -STUB_FUNC2(__pthread_cleanup_push_imp, PJT_CLEANUP_PUSH_IMP, void, void*, void *); -STUB_FUNC1(_pthread_cancel_enter, PJT_CANCEL_ENTER, int, int) -STUB_FUNC1(_pthread_cancel_leave, PJT_CANCEL_LEAVE, int, int) +STUB_FUNC1(__pthread_cleanup_pop_imp, PJT_CLEANUP_POP_IMP, void, int) +STUB_FUNC3(__pthread_cleanup_push_imp, PJT_CLEANUP_PUSH_IMP, void, void *, + void *, void *); +STUB_FUNC1(_pthread_cancel_enter, PJT_CANCEL_ENTER, void, int) +STUB_FUNC1(_pthread_cancel_leave, PJT_CANCEL_LEAVE, void, int) static int stub_zero(void) From owner-freebsd-ppc@freebsd.org Sun Jul 2 04:53:57 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB6D2D9D401 for ; Sun, 2 Jul 2017 04:53:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6858C7FECC for ; Sun, 2 Jul 2017 04:53:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10665 invoked from network); 2 Jul 2017 04:53:55 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 2 Jul 2017 04:53:55 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sun, 02 Jul 2017 00:53:55 -0400 (EDT) Received: (qmail 26071 invoked from network); 2 Jul 2017 04:53:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 2 Jul 2017 04:53:55 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B9F90EC81E6; Sat, 1 Jul 2017 21:53:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320521 (e.g.): another powerpc64 problem: programs using fgets crash trying to store address over code instead of into __cleanup_info__ From: Mark Millard In-Reply-To: <20170702034052.GE1935@kib.kiev.ua> Date: Sat, 1 Jul 2017 21:53:54 -0700 Cc: FreeBSD PowerPC ML , FreeBSD Current , freebsd-hackers@freebsd.org, bob prohaska Content-Transfer-Encoding: quoted-printable Message-Id: <63F748A7-9750-4065-B268-6E19A6BEC829@dsl-only.net> References: <20170702034052.GE1935@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 04:53:57 -0000 On 2017-Jul-1, at 8:40 PM, Konstantin Belousov = wrote: > On Sat, Jul 01, 2017 at 07:42:11PM -0700, Mark Millard wrote: >> powerpc64 is having programs crash with an attempt >> to store addresses over code instead of into >> __cleanup_info__ when fgets is used. ntpd is an >> example. As is sshd (although I've looked at >> its details less). >=20 > Yes, I think you are right. I also see how this worked on amd64, > where I tested the change. >=20 > Try this. >=20 > diff --git a/lib/libc/gen/_pthread_stubs.c = b/lib/libc/gen/_pthread_stubs.c > index 18a23216d50..fcf7ff04fed 100644 > --- a/lib/libc/gen/_pthread_stubs.c > +++ b/lib/libc/gen/_pthread_stubs.c > @@ -279,10 +279,11 @@ STUB_FUNC2(pthread_kill, PJT_KILL, int, void *, = int) > STUB_FUNC2(pthread_setcancelstate, PJT_SETCANCELSTATE, int, int, void = *) > STUB_FUNC2(pthread_setcanceltype, PJT_SETCANCELTYPE, int, int, void *) > STUB_FUNC(pthread_testcancel, PJT_TESTCANCEL, void) > -STUB_FUNC1(__pthread_cleanup_pop_imp, PJT_CLEANUP_POP_IMP, int, int) > -STUB_FUNC2(__pthread_cleanup_push_imp, PJT_CLEANUP_PUSH_IMP, void, = void*, void *); > -STUB_FUNC1(_pthread_cancel_enter, PJT_CANCEL_ENTER, int, int) > -STUB_FUNC1(_pthread_cancel_leave, PJT_CANCEL_LEAVE, int, int) > +STUB_FUNC1(__pthread_cleanup_pop_imp, PJT_CLEANUP_POP_IMP, void, int) > +STUB_FUNC3(__pthread_cleanup_push_imp, PJT_CLEANUP_PUSH_IMP, void, = void *, > + void *, void *); > +STUB_FUNC1(_pthread_cancel_enter, PJT_CANCEL_ENTER, void, int) > +STUB_FUNC1(_pthread_cancel_leave, PJT_CANCEL_LEAVE, void, int) >=20 > static int > stub_zero(void) That fixed the issue for my powerpc64 context. For examples: sshd and ntpd are running. I'll go rebuild the rest of my contexts now. Thanks! =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Mon Jul 3 11:21:21 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72B059E452C for ; Mon, 3 Jul 2017 11:21:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2522D683A5 for ; Mon, 3 Jul 2017 11:21:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20803 invoked from network); 3 Jul 2017 11:21:19 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 3 Jul 2017 11:21:19 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Mon, 03 Jul 2017 07:21:19 -0400 (EDT) Received: (qmail 25295 invoked from network); 3 Jul 2017 11:21:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 3 Jul 2017 11:21:18 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2AEDAEC8143; Mon, 3 Jul 2017 04:21:18 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r320570 (e.g.): ld crashes on powerpc64. . . (this was during port builds, I got about 65 of them) Message-Id: <39759CC6-03A4-4041-8B2C-93E030E733AB@dsl-only.net> Date: Mon, 3 Jul 2017 04:21:17 -0700 To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 11:21:21 -0000 Using one of the examples for illustration of what is common to each that I've looked at: Core was generated by `/usr/bin/ld --eh-frame-hdr -Bstatic -o conftest = /usr/lib/crt1.o /usr/lib/crti.o'. Program terminated with signal 11, Segmentation fault. #0 0x000000001002dc78 in .text () (gdb) bt #0 0x000000001002dc78 in .text () #1 0x000000001000101c in ppc_before_allocation () at = eelf64ppc_fbsd.c:204 #2 0x0000000010009a2c in ldemul_before_allocation () at = /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldemul.c:= 78 #3 0x0000000010017844 in lang_process () at = /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldlang.c:= 5785 #4 0x00000000100219b0 in main (argc=3D0, argv=3D) = at = /usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmain.c:= 459 #5 0x000000001000049c in .text () #1 source around eelf64ppc_fbsd.c:204 being: 199 TLS segment layout so that certain optimizations = can be done. */ 200 expld.phase =3D lang_mark_phase_enum; 201 expld.dataseg.phase =3D exp_dataseg_none; 202 one_lang_size_sections_pass (NULL, TRUE); 203=09 204 if (!ppc64_elf_tls_optimize (output_bfd, &link_info)) 205 einfo ("%X%P: TLS problem %E\n"); 206=09 207 /* We must not cache anything from the preliminary = sizing. */ 208 lang_reset_memory_regions (); where lines 202/204 are: 0x0000000010000ff4 : li r3,0 0x0000000010000ff8 : li r4,1 0x0000000010000ffc : bl 0x10013fbc = 0x0000000010001000 : nop 0x0000000010001004 : nop 0x0000000010001008 : addis r4,r2,1 0x000000001000100c : addi r3,r2,-11840 0x0000000010001010 : addi r4,r4,-5320 0x0000000010001014 : ld r3,0(r3) 0x0000000010001018 : bl 0x1002d90c = <.text+186188> 0x000000001000101c : nop And that last bl starts out at: 0x1002d90c <.text+186188>: mflr r0 0x1002d910 <.text+186192>: mfcr r12 0x1002d914 <.text+186196>: std r31,-8(r1) 0x1002d918 <.text+186200>: std r0,16(r1) 0x1002d91c <.text+186204>: stw r12,8(r1) 0x1002d920 <.text+186208>: stdu r1,-384(r1) 0x1002d924 <.text+186212>: mr r31,r1 0x1002d928 <.text+186216>: nop 0x1002d92c <.text+186220>: std r30,368(r31) 0x1002d930 <.text+186224>: addi r30,r2,11904 0x1002d934 <.text+186228>: std r28,352(r31) 0x1002d938 <.text+186232>: std r14,240(r31) 0x1002d93c <.text+186236>: std r15,248(r31) 0x1002d940 <.text+186240>: std r16,256(r31) 0x1002d944 <.text+186244>: std r17,264(r31) 0x1002d948 <.text+186248>: std r18,272(r31) 0x1002d94c <.text+186252>: std r19,280(r31) 0x1002d950 <.text+186256>: std r20,288(r31) 0x1002d954 <.text+186260>: std r21,296(r31) 0x1002d958 <.text+186264>: std r22,304(r31) 0x1002d95c <.text+186268>: std r23,312(r31) 0x1002d960 <.text+186272>: std r24,320(r31) 0x1002d964 <.text+186276>: std r25,328(r31) 0x1002d968 <.text+186280>: std r26,336(r31) 0x1002d96c <.text+186284>: std r27,344(r31) 0x1002d970 <.text+186288>: std r29,360(r31) 0x1002d974 <.text+186292>: mr r28,r4 0x1002d978 <.text+186296>: ld r3,0(r30) . . . (r3 is replaced before its value is used.) Around 0x000000001002dc78 (for #0) is: 0x1002dc0c <.text+186956>: b 0x1002de6c <.text+187564> 0x1002dc10 <.text+186960>: cmplwi r4,0 0x1002dc14 <.text+186964>: beq- 0x1002e0a0 <.text+188128> 0x1002dc18 <.text+186968>: li r3,20 0x1002dc1c <.text+186972>: li r22,4 0x1002dc20 <.text+186976>: li r30,0 0x1002dc24 <.text+186980>: li r6,0 0x1002dc28 <.text+186984>: b 0x1002dc64 <.text+187044> 0x1002dc2c <.text+186988>: li r6,1 0x1002dc30 <.text+186992>: cmplwi r4,0 0x1002dc34 <.text+186996>: li r30,80 0x1002dc38 <.text+187000>: beq- 0x1002dc40 <.text+187008> 0x1002dc3c <.text+187004>: li r30,0 0x1002dc40 <.text+187008>: li r3,17 0x1002dc44 <.text+187012>: li r22,1 0x1002dc48 <.text+187016>: b 0x1002dc64 <.text+187044> 0x1002dc4c <.text+187020>: li r6,1 0x1002dc50 <.text+187024>: cmplwi r5,0 0x1002dc54 <.text+187028>: beq- 0x1002e0a0 <.text+188128> 0x1002dc58 <.text+187032>: li r3,18 0x1002dc5c <.text+187036>: li r22,2 0x1002dc60 <.text+187040>: li r30,0 0x1002dc64 <.text+187044>: cmpwi r6,0 0x1002dc68 <.text+187048>: crnot 4*cr5+lt,eq 0x1002dc6c <.text+187052>: beq- cr2,0x1002dd14 <.text+187220> 0x1002dc70 <.text+187056>: bge- cr5,0x1002dcf4 <.text+187188> 0x1002dc74 <.text+187060>: ld r4,544(r15) 0x1002dc78 <.text+187064>: ld r4,80(r4) 0x1002dc7c <.text+187068>: cmpldi r4,0 0x1002dc80 <.text+187072>: bne- 0x1002dc94 <.text+187092> 0x1002dc84 <.text+187076>: b 0x1002dcac <.text+187116> info reg show r4 as 0x0. I expect that the failure is during the tls_get_addr dereference in htab->tls_get_addr->elf.plt.plist in the first loop below: htab->tls_get_addr is NULL as far as I can tell. . . In ppc_before_allocation : if (expecting_tls_get_addr) { struct plt_entry *ent; for (ent =3D htab->tls_get_addr->elf.plt.plist; ent !=3D NULL; ent =3D ent->next) if (ent->addend =3D=3D 0) { if (ent->plt.refcount > 0) { ent->plt.refcount -=3D 1; expecting_tls_get_addr =3D 0; } break; } } if (expecting_tls_get_addr) { struct plt_entry *ent; for (ent =3D htab->tls_get_addr_fd->elf.plt.plist; ent !=3D NULL; ent =3D ent->next) if (ent->addend =3D=3D 0) { if (ent->plt.refcount > 0) ent->plt.refcount -=3D 1; break; } } =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Jul 4 09:17:19 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2BF47D8B394 for ; Tue, 4 Jul 2017 09:17:19 +0000 (UTC) (envelope-from bounce_YPt7oVRExLxd87Cz_WMjUTU4nq1JgBtNM_9750d51253cbe3af_10@m-tdevelopment-mail.com) Received: from mail35.outbound.mta-3.com (mail35.outbound.mta-3.com [69.63.158.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7D30741B2 for ; Tue, 4 Jul 2017 09:17:18 +0000 (UTC) (envelope-from bounce_YPt7oVRExLxd87Cz_WMjUTU4nq1JgBtNM_9750d51253cbe3af_10@m-tdevelopment-mail.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=mykey2; d=mta-3.com; h=Reply-To:Sender:List-Unsubscribe:From:To:Subject:MIME-Version:Date:Message-Id:Content-Type; bh=6rlGqt1sjTmND1Vz4lj8YxoEE50=; b=snmFx5kpJ2Z234NYezMAMvcCAViGSv8rwxGcxr5As1nQMv4KnaiT7++NPOCm0luz8swURCRWxU1O dV8DtAK+an8KxqDFOjz2etPRNgQrSOEIxdQgl8CLPMjIwESB6efuuQatfVz4smBO75Dq2tTfCVjl 72IBb9RJy3BVmTPqI/HAQtJKOXizi6LvQGdQ6G0d2J9kVWMKffX7aH5bzBv3Pury+7nI6kRmmucS k4kEi/KhEIq3nl6HI+IQiLCAfndcMmCZx/42830q7L0tZ1xx5COGsFs8Ml6VEfm6tAd1BlKqP8z9 UFQs3saL7joswRKT3uiNI8eYIh7+FnO/rKh4PQ== Received: from localhost (10.10.204.20) by mail35.outbound.mta-3.com id hbdehs29cjoo for ; Tue, 4 Jul 2017 11:17:16 +0200 (envelope-from ) Reply-To: newsletter@m-t.co.za X-Priority: 3 Sender: "M&T Marketing" X-Report-Abuse: X-Data: WMjUTU4nq1JgBtNM.9750d51253cbe3af X-Data-EUID: 7d00488b38097631f826dd8ab2e47a13 X-Data-Rating: 60 X-Contact-Score: 0 From: M&T Marketing To: freebsd-ppc@freebsd.org Subject: Development in Centurion MIME-Version: 1.0 Date: Tue, 04 Jul 2017 11:17:01 +0200 Message-Id: <201707041111416.11884.562@m-t.co.za> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 09:17:19 -0000 M%26T_Header.jpg ( http://comms.m-tdevelopment-mail.com/servlet/link/9695/31907/58966533/344203 ) Centurion Peach_Orchard__Logo.jpg ( http://comms.m-tdevelopment-mail.com/servlet/link/9695/31907/58966533/344204 ) Facilities.jpg ( http://comms.m-tdevelopment-mail.com/servlet/link/9695/31907/58966533/344205 ) Peach_Orchard_Stacks_image.jpg ( http://comms.m-tdevelopment-mail.com/servlet/link/9695/31907/58966533/344206 ) Peach_Orchard_Prices.jpg ( http://comms.m-tdevelopment-mail.com/servlet/link/9695/31907/58966533/344207 ) Ben 078 784 9901 ben@m-t.co.za ( ben@m-t.co.za?subject=Peach%20Orchard%20e-mail%20newsletter%20enquiry ) Key_places_in_the_area.jpg ( http://comms.m-tdevelopment-mail.com/servlet/link/9695/31907/58966533/344208 ) Peach-Orchard_MAP.jpg ( http://comms.m-tdevelopment-mail.com/servlet/link/9695/31907/58966533/344209 ) Show_Times.jpg ( http://comms.m-tdevelopment-mail.com/servlet/link/9695/31907/58966533/344210 ) From owner-freebsd-ppc@freebsd.org Tue Jul 4 16:01:41 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71F05D94CBA for ; Tue, 4 Jul 2017 16:01:41 +0000 (UTC) (envelope-from braslau.list@comcast.net) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [96.114.154.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "resqmta-po-01v.sys.comcast.net", Issuer "COMODO RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E6B17F9A5 for ; Tue, 4 Jul 2017 16:01:40 +0000 (UTC) (envelope-from braslau.list@comcast.net) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-09v.sys.comcast.net with SMTP id SQ6bdrvyr4mxCSQ6dd2GQ5; Tue, 04 Jul 2017 15:51:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1499183475; bh=zhwzy6e0PfBUF9+HnpsrpElch36fUu06TrwKujMMUgA=; h=Received:Received:Date:From:To:Subject:Message-ID:MIME-Version: Content-Type; b=DWJD+gPsPKM+hZOXlhjPVBeEwDr46lVhr1w67Ylyka0zxTrdNtparOKjUfpSnQSNK 63TiptoLQUoxqjduG+XdAihv1mRSN66Jg0l/eFkF26SVdCgU9ccFkza5iI207U28DX nBIlLBoklr1pT6QzqR6rHax4b9mUE6u1Ecgdo9Ro3++JBMaYIVWq2m5ukqJJGwmooq T5dmuEJH8gWdlAJ1aVTZQDDtr76FTG2OQEKA83/3gxmpVDkRtgtfMfr1r8MkF9P8E3 MDpXJ0/fawGb/adqV+IhKlKF9L8XGKLpymSWhKKOtAsQFEp4uK/Ea7+cq+GfX5KdJg LdgdYFQ0lh8Hw== Received: from zoo.hsd1.co.comcast.net ([IPv6:2601:282:8000:7637:dd3b:8d2c:578e:ae54]) by resomta-po-11v.sys.comcast.net with SMTP id SQ6cd0oD4naRwSQ6ddgWmK; Tue, 04 Jul 2017 15:51:15 +0000 Date: Tue, 4 Jul 2017 09:51:13 -0600 From: Alan Braslau To: freebsd-ppc@freebsd.org Subject: powerpc64 update from source kernel panic (11.0) Message-ID: <20170704094533.43507ae2@zoo.hsd1.co.comcast.net> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-apple-darwin16.6.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfMSj6iSMsUsB4fO4i/RyEaBModj+FTv84TOmYVP91iTTgb2c81bHJ7VjMsFlrIQdpfic5lQfk+nsr5IQ943AUfoGre1cR4InLJxQnRQHrxH6l6o0iYIU hNZLi2Hprywg605Tcj6vs0g4miMnbzrLrFudwprydwONs5YBbX63pYB75+CQOmqrtGxPR9Rv7gSgIQ== X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 16:01:41 -0000 Hello ppc mailing list, I installed freebsd 11.0 powerpc64 on an iMac G5 without any problems and have installed a fairly complete functional system. However, upgrading from source (unmodified configuration) results in a kernel panic upon boot. Has anyone experienced this? Thank you Alan From owner-freebsd-ppc@freebsd.org Tue Jul 4 19:34:46 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BDEAD991F3 for ; Tue, 4 Jul 2017 19:34:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D01A4133A for ; Tue, 4 Jul 2017 19:34:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14133 invoked from network); 4 Jul 2017 19:29:36 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 4 Jul 2017 19:29:36 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Tue, 04 Jul 2017 15:28:04 -0400 (EDT) Received: (qmail 19583 invoked from network); 4 Jul 2017 19:28:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Jul 2017 19:28:04 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id F3EF1EC85D5; Tue, 4 Jul 2017 12:28:03 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: system clang on powerpc64 vs building lang/gcc7-devel with it: xgcc gets segmentation fault Message-Id: <493B86B0-608C-4DCF-83F4-398385F8F01D@dsl-only.net> Date: Tue, 4 Jul 2017 12:28:03 -0700 To: FreeBSD PowerPC ML , FreeBSD Toolchain X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 19:34:46 -0000 I have submitted: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D81315 for the below, presuming for now that the problem is on the GCC side of things. Hopefully it is not tied to include-fixed/ now being empty. [We will see if the GCC folks object to the include-fixed/ having empty or not.] I was trying to build lang/gcc7-devel on FreeBSD head -r320570 on a powerpc64. The xgcc stage got the following segmentation fault. (By contrast 32-bit powerpc's build completed without having this problem.) And the crash was repeatable: the below is from a -save-temps rerun. xgcc: warning: -pipe ignored because -save-temps specified Reading specs from = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/specs = COLLECT_GCC=3D/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./g= cc/xgcc Target: powerpc64-portbld-freebsd12.0 Configured with: = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/configure= --enable-multilib --with-build-config=3Dbootstrap-debug --disable-nls = --enable-gnu-indirect-function --libdir=3D/usr/local/lib/gcc7 = --libexecdir=3D/usr/local/libexec/gcc7 --program-suffix=3D7 = --with-as=3D/usr/local/bin/as --with-gmp=3D/usr/local = --with-gxx-include-dir=3D/usr/local/lib/gcc7/include/c++/ = --with-ld=3D/usr/local/bin/ld --with-pkgversion=3D'FreeBSD Ports = Collection' --with-system-zlib --enable-languages=3Dc,c++,objc,fortran = --prefix=3D/usr/local --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/gcc7 --build=3Dpowerpc64-portbld-freebsd12.0 Thread model: posix gcc version 7.1.1 20170629 (FreeBSD Ports Collection)=20 COLLECT_GCC_OPTIONS=3D'-v' '-save-temps' '-shared-libgcc' '-B' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc' = '-nostdinc++' = '-L/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-port= bld-freebsd12.0/libstdc++-v3/src' = '-L/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-port= bld-freebsd12.0/libstdc++-v3/src/.libs' = '-L/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-port= bld-freebsd12.0/libstdc++-v3/libsupc++/.libs' '-B' = '/usr/local/powerpc64-portbld-freebsd12.0/bin/' '-B' = '/usr/local/powerpc64-portbld-freebsd12.0/lib/' '-isystem' = '/usr/local/powerpc64-portbld-freebsd12.0/include' '-isystem' = '/usr/local/powerpc64-portbld-freebsd12.0/sys-include' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc+= +-v3/../libgcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbl= d-freebsd12.0/libstdc++-v3/include/powerpc64-portbld-freebsd12.0' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbl= d-freebsd12.0/libstdc++-v3/include' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc+= +-v3/libsupc++' '-D' '_GLIBCXX_SHARED' '-fno-implicit-templates' '-Wall' = '-Wextra' '-Wwrite-strings' '-Wcast-qual' '-Wabi' = '-fdiagnostics-show-location=3Donce' '-ffunction-sections' = '-fdata-sections' '-frandom-seed=3Dclass_type_info.lo' '-O2' '-pipe' = '-B' '/usr/local/bin/' '-D' 'LIBICONV_PLUG' '-g' '-fno-strict-aliasing' = '-B' '/usr/local/bin/' '-D' 'LIBICONV_PLUG' '-c' '-fPIC' '-D' 'PIC' '-D' = '_GLIBCXX_SHARED' '-o' 'class_type_info.o' /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/cc1plus = -E -quiet -nostdinc++ -v -I = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++= -v3/../libgcc -I = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbld= -freebsd12.0/libstdc++-v3/include/powerpc64-portbld-freebsd12.0 -I = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbld= -freebsd12.0/libstdc++-v3/include -I = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++= -v3/libsupc++ -iprefix = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/gcc/../lib/gcc7/g= cc/powerpc64-portbld-freebsd12.0/7.1.1/ -isystem = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/include = -isystem = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/include-fix= ed -D _GLIBCXX_SHARED -D LIBICONV_PLUG -D LIBICONV_PLUG -D PIC -D = _GLIBCXX_SHARED -isystem = /usr/local/powerpc64-portbld-freebsd12.0/include -isystem = /usr/local/powerpc64-portbld-freebsd12.0/sys-include = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++= -v3/libsupc++/class_type_info.cc -Wall -Wextra -Wwrite-strings = -Wcast-qual -Wabi -fno-implicit-templates = -fdiagnostics-show-location=3Donce -ffunction-sections -fdata-sections = -frandom-seed=3Dclass_type_info.lo -fno-strict-aliasing -fPIC -g = -fworking-directory -O2 -fpch-preprocess -o class_type_info.ii ignoring nonexistent directory = "/usr/local/powerpc64-portbld-freebsd12.0/include" ignoring nonexistent directory = "/usr/local/powerpc64-portbld-freebsd12.0/sys-include" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/gcc/../lib/gcc7/= gcc/powerpc64-portbld-freebsd12.0/7.1.1/include" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/gcc/../lib/gcc7/= gcc/powerpc64-portbld-freebsd12.0/7.1.1/include-fixed" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/gcc/../lib/gcc7/= gcc/powerpc64-portbld-freebsd12.0/7.1.1/../../../../../powerpc64-portbld-f= reebsd12.0/include" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/gcc/../lib/gcc7/= gcc/../../../lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.1.1/include" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/gcc/../lib/gcc7/= gcc/../../../lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.1.1/include-fixe= d" ignoring nonexistent directory = "/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/gcc/../lib/gcc7/= gcc/../../../lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.1.1/../../../../= ../powerpc64-portbld-freebsd12.0/include" #include "..." search starts here: #include <...> search starts here: = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++= -v3/../libgcc = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbld= -freebsd12.0/libstdc++-v3/include/powerpc64-portbld-freebsd12.0 = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbld= -freebsd12.0/libstdc++-v3/include = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++= -v3/libsupc++ /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/include = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/include-fix= ed /usr/local/include /usr/include End of search list. COLLECT_GCC_OPTIONS=3D'-v' '-save-temps' '-shared-libgcc' '-B' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc' = '-nostdinc++' = '-L/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-port= bld-freebsd12.0/libstdc++-v3/src' = '-L/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-port= bld-freebsd12.0/libstdc++-v3/src/.libs' = '-L/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-port= bld-freebsd12.0/libstdc++-v3/libsupc++/.libs' '-B' = '/usr/local/powerpc64-portbld-freebsd12.0/bin/' '-B' = '/usr/local/powerpc64-portbld-freebsd12.0/lib/' '-isystem' = '/usr/local/powerpc64-portbld-freebsd12.0/include' '-isystem' = '/usr/local/powerpc64-portbld-freebsd12.0/sys-include' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc+= +-v3/../libgcc' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbl= d-freebsd12.0/libstdc++-v3/include/powerpc64-portbld-freebsd12.0' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbl= d-freebsd12.0/libstdc++-v3/include' '-I' = '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc+= +-v3/libsupc++' '-D' '_GLIBCXX_SHARED' '-fno-implicit-templates' '-Wall' = '-Wextra' '-Wwrite-strings' '-Wcast-qual' '-Wabi' = '-fdiagnostics-show-location=3Donce' '-ffunction-sections' = '-fdata-sections' '-frandom-seed=3Dclass_type_info.lo' '-O2' '-pipe' = '-B' '/usr/local/bin/' '-D' 'LIBICONV_PLUG' '-g' '-fno-strict-aliasing' = '-B' '/usr/local/bin/' '-D' 'LIBICONV_PLUG' '-c' '-fPIC' '-D' 'PIC' '-D' = '_GLIBCXX_SHARED' '-o' 'class_type_info.o' /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/cc1plus = -fpreprocessed class_type_info.ii -quiet -dumpbase class_type_info.cc = -auxbase-strip class_type_info.o -g -O2 -Wall -Wextra -Wwrite-strings = -Wcast-qual -Wabi -version -fno-implicit-templates = -fdiagnostics-show-location=3Donce -ffunction-sections -fdata-sections = -frandom-seed=3Dclass_type_info.lo -fno-strict-aliasing -fPIC -o = class_type_info.s GNU C++14 (FreeBSD Ports Collection) version 7.1.1 20170629 = (powerpc64-portbld-freebsd12.0) compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 4.0.0 = (tags/RELEASE_400/final 297347), GMP version 6.1.2, MPFR version = 3.1.5-p2, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=3D30 --param = ggc-min-heapsize=3D4096 GNU C++14 (FreeBSD Ports Collection) version 7.1.1 20170629 = (powerpc64-portbld-freebsd12.0) compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 4.0.0 = (tags/RELEASE_400/final 297347), GMP version 6.1.2, MPFR version = 3.1.5-p2, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=3D30 --param = ggc-min-heapsize=3D4096 Compiler executable checksum: 9b3c45692665b5f6f0fb0529d1f75edd = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++= -v3/libsupc++/class_type_info.cc: In member function 'virtual bool = __cxxabiv1::__class_type_info::__do_upcast(const = __cxxabiv1::__class_type_info*, void**) const': = /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++= -v3/libsupc++/class_type_info.cc:45:6: internal compiler error: = Segmentation fault bool __class_type_info:: ^~~~~~~~~~~~~~~~~ no stack trace because unwind library not available Please submit a full bug report, with preprocessed source if appropriate. See for instructions. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Jul 4 20:36:12 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06D6AD9A846 for ; Tue, 4 Jul 2017 20:36:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 877843176 for ; Tue, 4 Jul 2017 20:36:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5382 invoked from network); 4 Jul 2017 20:36:09 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 4 Jul 2017 20:36:09 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Tue, 04 Jul 2017 16:36:09 -0400 (EDT) Received: (qmail 25662 invoked from network); 4 Jul 2017 20:36:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Jul 2017 20:36:09 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C3D6AEC8678; Tue, 4 Jul 2017 13:36:08 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: powerpc64 update from source kernel panic (11.0) Message-Id: Date: Tue, 4 Jul 2017 13:36:08 -0700 To: braslau.list@comcast.net, FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 20:36:12 -0000 Alan Braslau braslau.list at comcast.net wrote on Tue Jul 4 16:01:41 UTC 2017 : > I installed freebsd 11.0 powerpc64 on an iMac G5 without any problems > and have installed a fairly complete functional system. > > However, upgrading from source (unmodified configuration) results in a > kernel panic upon boot. Has anyone experienced this? It might help folks to be more explicit about. . . What specific version before the upgrade? release/11.0.0/ release/11.0.1/ releng/11.0/ for what -r3????? stable/11/ for what -r3????? What specific version for the attempted "upgrade to": release/11.0.1/ releng/11.0/ for what -r3????? releng/11.1/ for what -r3????? stable/11/ for what -r3????? I've assumed above that you did not try to upgrade to: head/ for some -r3????? (also called CURRENT or 12-CURRENT). But I could be wrong. head/ is more likely to end up with odd problems and has had some recent ones. === Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Jul 4 20:55:00 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1FA13D9AC8F for ; Tue, 4 Jul 2017 20:55:00 +0000 (UTC) (envelope-from braslau.list@comcast.net) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "resqmta-po-01v.sys.comcast.net", Issuer "COMODO RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E5C0637C9 for ; Tue, 4 Jul 2017 20:54:59 +0000 (UTC) (envelope-from braslau.list@comcast.net) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-02v.sys.comcast.net with SMTP id SUqIdfLJ2y5scSUqYdYd8J; Tue, 04 Jul 2017 20:54:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1499201698; bh=Ap3Ej2N1Wprkr0jnFyYQNdpb5MKBYmJ7cFhRg0zY/eQ=; h=Received:Received:Date:From:To:Subject:Message-ID:MIME-Version: Content-Type; b=eKAnSuOV76faMICxdEZ3/xnAudhD1/HDtuzXOxM7WOjasNcqWCIi4Ja/RV/VJmdDw DrzKax5ci5hsWh3IVwDSn2dYOYYdZ/eK2/3enYbgm+A4LYzkGFWPahlFAqsXMWpfjU NxZc7BztTlhU6OutP572KoIFeejRqBuBtPBQK7rAINQX3F29ZVWZtfjKJYqQFrgv7M vr12kG5nFirFPWlV4b1/oS97rnec5cB//zrYSIqCY+x0IAWyArBdTSGhylGcDdS397 OZDR4o4EYpKCyNEroHIgekkhAt5Ws4Yrcq/luvDUyc9GO0VKOijRcpw2/Kv1hb8rrD wSItG+zZrsfnw== Received: from zoo.hsd1.co.comcast.net ([IPv6:2601:282:8000:7637:b0f6:5c54:9af2:6790]) by resomta-po-18v.sys.comcast.net with SMTP id SUqXdKvUgZTksSUqYdCKMa; Tue, 04 Jul 2017 20:54:58 +0000 Date: Tue, 4 Jul 2017 14:54:56 -0600 From: Alan Braslau To: Mark Millard Cc: FreeBSD PowerPC ML Subject: Re: powerpc64 update from source kernel panic (11.0) Message-ID: <20170704145456.6d8c095e@zoo.hsd1.co.comcast.net> In-Reply-To: References: X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-apple-darwin16.6.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfBtEeTg3FjsYQaB/Nx7q0sdhhbKENnZpEUOSZ+SnGmRPMePFUIdefyAoXQ63ulN+00ftr8ew0GiObSwQQars5CDgCRz4YCFTqlLbdvyaJC+L366W/Vy3 COEHVN8bqO4FQr7TFcJQLItXJ43hyO7qBj7meFH6WZ70Zk0MLcGDMA5qcfUBxNlGsWnJO93NWcv8qZgXc2RCj8dc4/b3rPDFVfw= X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 20:55:00 -0000 On Tue, 4 Jul 2017 13:36:08 -0700 Mark Millard wrote: > Alan Braslau braslau.list at comcast.net wrote on > Tue Jul 4 16:01:41 UTC 2017 : > > > I installed freebsd 11.0 powerpc64 on an iMac G5 without any > > problems and have installed a fairly complete functional system. > > > > However, upgrading from source (unmodified configuration) results > > in a kernel panic upon boot. Has anyone experienced this? > > > > It might help folks to be more explicit > about. . . > > What specific version before the upgrade? > > release/11.0.0/ > release/11.0.1/ > releng/11.0/ for what -r3????? > stable/11/ for what -r3????? > > What specific version for the attempted > "upgrade to": > > release/11.0.1/ > releng/11.0/ for what -r3????? > releng/11.1/ for what -r3????? > stable/11/ for what -r3????? > > > I've assumed above that you did not > try to upgrade to: > > head/ for some -r3????? > > (also called CURRENT or 12-CURRENT). > But I could be wrong. head/ is more > likely to end up with odd problems > and has had some recent ones. > > > === > Mark Millard > markmi at dsl-only.net > I'm sorry, I thought that it could be assumed that I installed RELEASE: I simply installed 11.0-RELEASE-p1 (from an iso image) and updated the source from base/releng/11.0 which gave me revision 320623. make buildworld make kernel shutdown -r now -> kernel panic then... boot kernel.old I did not try anything custom. Alan From owner-freebsd-ppc@freebsd.org Tue Jul 4 22:16:41 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7798ED9BEE4 for ; Tue, 4 Jul 2017 22:16:41 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2AA636527B for ; Tue, 4 Jul 2017 22:16:41 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-qt0-x229.google.com with SMTP id 32so173854065qtv.1 for ; Tue, 04 Jul 2017 15:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=si2TZMWdAGer0nB+ql6Pjl5rCqoHjt+i9Wt15ybvrcQ=; b=WhpjjN+GBPt96s4tQd/woUVSfXk2saGQpL1WSTVzVw/6KUV027+wbMHj00tK7ojZNY KgKedQAyVXGN56NspiSocCHJt+QbrOnDFN8Na4CLBIhKKI8HiFVohZxnAIRG36RL7SZg bjSFgrtiBEpg7eJCQuGqwlZvboRrWhZdP7pBnemFqp5ApHU/uFPkkAjw9vLahDtEHzK0 pUebzoEGDQsxPEqYTFloBkrUXAWbt+Chhoy+/gJfUNciJ58PTozs0oFM+WuwnP6r657X BtKGntDSFrzFOw7FhYD7pIDgcu3Tvsekmyeqlem5gSqv/ilyk4j9dLwrwJDtqdypCSnx RyOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=si2TZMWdAGer0nB+ql6Pjl5rCqoHjt+i9Wt15ybvrcQ=; b=ZWh8ikOXwRUK0W6MCYfur4o26ySosy383H+ec3kW57gunlmSMEdHFa49NFvjuuTHZR X+HbCXJc0RBZysKTV0MMrR2r7NOjKk87tarA0+rAENsHkKwFfSrBuvhNUS5BgovDN8rM BhoGuGHepPeFojoD6W/6UPXuz2uXRt74/xlUlJsGy7zN93ZCZvEDKfxfNnLKNSE+IUGH AWBJVSz/TH0uc93C2lXdrWoQLjgYEiqtGB3B5Td1A4M/lNeNGfKmnhRhuT8sXv5TFiMX ptn9Mc2IzwfFm1zHo4dhJiYGrOjQ+lungYcNDXhws+OSrUcIDsND3NFL5RS3pKcUaDS9 6IEA== X-Gm-Message-State: AKS2vOyoVDN7GAtTbsyR6PgnPtrNLKepJosXKXQxUJ58aKpZkBh68M7O PAX7wLfSVw0HluYfvh/OQWQwdGf5VA== X-Received: by 10.200.56.177 with SMTP id f46mr54106317qtc.234.1499206600262; Tue, 04 Jul 2017 15:16:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.161.129 with HTTP; Tue, 4 Jul 2017 15:16:39 -0700 (PDT) Received: by 10.12.161.129 with HTTP; Tue, 4 Jul 2017 15:16:39 -0700 (PDT) In-Reply-To: <20170704145456.6d8c095e@zoo.hsd1.co.comcast.net> References: <20170704145456.6d8c095e@zoo.hsd1.co.comcast.net> From: Justin Hibbits Date: Tue, 4 Jul 2017 17:16:39 -0500 Message-ID: Subject: Re: powerpc64 update from source kernel panic (11.0) To: Alan Braslau Cc: Mark Millard , FreeBSD PowerPC ML Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 22:16:41 -0000 On Jul 4, 2017 15:55, "Alan Braslau" wrote: On Tue, 4 Jul 2017 13:36:08 -0700 Mark Millard wrote: > Alan Braslau braslau.list at comcast.net wrote on > Tue Jul 4 16:01:41 UTC 2017 : > > > I installed freebsd 11.0 powerpc64 on an iMac G5 without any > > problems and have installed a fairly complete functional system. > > > > However, upgrading from source (unmodified configuration) results > > in a kernel panic upon boot. Has anyone experienced this? > > > > It might help folks to be more explicit > about. . . > > What specific version before the upgrade? > > release/11.0.0/ > release/11.0.1/ > releng/11.0/ for what -r3????? > stable/11/ for what -r3????? > > What specific version for the attempted > "upgrade to": > > release/11.0.1/ > releng/11.0/ for what -r3????? > releng/11.1/ for what -r3????? > stable/11/ for what -r3????? > > > I've assumed above that you did not > try to upgrade to: > > head/ for some -r3????? > > (also called CURRENT or 12-CURRENT). > But I could be wrong. head/ is more > likely to end up with odd problems > and has had some recent ones. > > > === > Mark Millard > markmi at dsl-only.net > I'm sorry, I thought that it could be assumed that I installed RELEASE: I simply installed 11.0-RELEASE-p1 (from an iso image) and updated the source from base/releng/11.0 which gave me revision 320623. make buildworld make kernel shutdown -r now -> kernel panic then... boot kernel.old I did not try anything custom. Alan Do you have a backtrace from the panic? - Justin From owner-freebsd-ppc@freebsd.org Tue Jul 4 22:37:35 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71CD7D9C37E for ; Tue, 4 Jul 2017 22:37:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2733D65A1E for ; Tue, 4 Jul 2017 22:37:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10548 invoked from network); 4 Jul 2017 22:37:33 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 4 Jul 2017 22:37:33 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Tue, 04 Jul 2017 18:37:33 -0400 (EDT) Received: (qmail 26699 invoked from network); 4 Jul 2017 22:37:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Jul 2017 22:37:33 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6A6F8EC85D5; Tue, 4 Jul 2017 15:37:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: powerpc64 update from source kernel panic (11.0) From: Mark Millard In-Reply-To: <20170704145456.6d8c095e@zoo.hsd1.co.comcast.net> Date: Tue, 4 Jul 2017 15:37:31 -0700 Cc: FreeBSD PowerPC ML , Justin Hibbits Content-Transfer-Encoding: 7bit Message-Id: <19637A8C-9C28-42D9-8E3E-E30E998D787A@dsl-only.net> References: <20170704145456.6d8c095e@zoo.hsd1.co.comcast.net> To: Alan Braslau X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 22:37:35 -0000 On 2017-Jul-4, at 1:54 PM, Alan Braslau wrote: >> Alan Braslau braslau.list at comcast.net wrote on >> Tue Jul 4 16:01:41 UTC 2017 : >> >>> I installed freebsd 11.0 powerpc64 on an iMac G5 without any >>> problems and have installed a fairly complete functional system. >>> >>> However, upgrading from source (unmodified configuration) results >>> in a kernel panic upon boot. Has anyone experienced this? > . . . > I'm sorry, I thought that it could be assumed that I installed RELEASE: > I simply installed 11.0-RELEASE-p1 (from an iso image) and updated the > source from base/releng/11.0 which gave me revision 320623. > > make buildworld > make kernel > shutdown -r now > -> kernel panic > then... > boot kernel.old > > I did not try anything custom. I probably also should have asked if you are using 32-bit FreeBSD or 64-bit. (G5's can use either when things are working.) -r320623 is from head (not from releng/11.0/ ): https://svnweb.freebsd.org/base/head/?view=log s shows: Revision 320623 - Directory Listing Modified Mon Jul 3 23:27:57 2017 UTC (23 hours, 2 minutes ago) by jasone Update jemalloc to 5.0.1. If this is real then you have jumped to a binary incompatible kernel relative to your world. (That may not be the only problem and you might not have even got that far.) As of when I looked head was up to -r320659 . I list the below in case the 320623 is a typo or some such. . . https://svnweb.freebsd.org/base/releng/11.0/?view=log shows: -r317487 from 2017-Apr-27 -r316722 from 2017-Apr-12 -r314125 from 2017-Feb-23 (I'll stop there.) https://svnweb.freebsd.org/base/releng/11.1/?view=log shows: -r320654 from 2017-Jul-4 -r320639 from 2017-Jul-4 -r320608 from 2017-Jul-3 (I'll stop there.) https://svnweb.freebsd.org/base/stable/11/?view=log shows: -r320645 from 2017-Jul-4 -r320641 from 2017-Jul-4 -r320638 from 2017-Jul-4 -r320621 from 2017-Jul-3 (I'll stop there.) Can you report for sure what you actually got? === Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Jul 4 22:40:44 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E758ED9C3F5 for ; Tue, 4 Jul 2017 22:40:44 +0000 (UTC) (envelope-from braslau.list@comcast.net) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "resqmta-po-01v.sys.comcast.net", Issuer "COMODO RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF4E765A94 for ; Tue, 4 Jul 2017 22:40:44 +0000 (UTC) (envelope-from braslau.list@comcast.net) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-10v.sys.comcast.net with SMTP id SWSwdz0Ja8ozzSWT2dhGDc; Tue, 04 Jul 2017 22:38:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1499207928; bh=2uGvbkLzvg1bGvNmnsAqb62OB2EmXmfhZh3GpMc86V8=; h=Received:Received:Date:From:To:Subject:Message-ID:MIME-Version: Content-Type; b=UhfgT08w79A0cK3CZKQ7rNFt68RjgaVyPR4ri8lr1WlEcp6XdxpCLQPTB5epkXXzr qw4qtweY8QIoFGOVRk8bTAsc+Du1FT4a8BUgiXhT5PtVMzLaaR70TUmf9YEDGzc7Ut OHeOps9yLpC7zbD812GwKZy4bFpy8q4YnfXWCJM1ETs4p+sEk4oSUueFQfZh5S2wbL qhj6xn8pUdWnUNf7jsXoGOPzOegeACwsy3h5XGLB1Dfkni22eGHSL+DD0wEJm2CFNu cy1GH00bb5+jCMZ1z+0TYh7ebx3d/vQ0R1VTs3TRslzMY16ICeIkDYG9OxQDq660uA izlrZmdBIkwxg== Received: from zoo.hsd1.co.comcast.net ([IPv6:2601:282:8000:7637:b0f6:5c54:9af2:6790]) by resomta-po-05v.sys.comcast.net with SMTP id SWT0dDgewQPoKSWT1dLWzT; Tue, 04 Jul 2017 22:38:48 +0000 Date: Tue, 4 Jul 2017 16:38:44 -0600 From: Alan Braslau To: Justin Hibbits Cc: Mark Millard , FreeBSD PowerPC ML Subject: Re: powerpc64 update from source kernel panic (11.0) Message-ID: <20170704163844.2afcd745@zoo.hsd1.co.comcast.net> In-Reply-To: References: <20170704145456.6d8c095e@zoo.hsd1.co.comcast.net> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-apple-darwin16.6.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfICLH0Mne+zaKaimEfrf4QEAxvqGabEhPCisCAv+jmOR0N8sQdx7zwo75QOfadqaOll252n0miSiayoHxAYZgVdfNRZ5EFbE7DINRl40Xqz2O5MJ8DdD y2AY3AgrSavFkjaT3jpCE8lFeQyDd8sXs6VeMuaVikCUTQjHJiVYlgOyP9TnECQXoni4oaPekJ/P0JCaYlhlVWz/sY7Jc+MFs7BApC3piHU/zuanDTx8uTQN axu+7lQuP/1z/1y+XojP4w== X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 22:40:45 -0000 On Tue, 4 Jul 2017 17:16:39 -0500 Justin Hibbits wrote: > On Jul 4, 2017 15:55, "Alan Braslau" wrote: > > On Tue, 4 Jul 2017 13:36:08 -0700 > Mark Millard wrote: > > > Alan Braslau braslau.list at comcast.net wrote on > > Tue Jul 4 16:01:41 UTC 2017 : > > > > > I installed freebsd 11.0 powerpc64 on an iMac G5 without any > > > problems and have installed a fairly complete functional system. > > > > > > However, upgrading from source (unmodified configuration) results > > > in a kernel panic upon boot. Has anyone experienced this? > > > > > > > > It might help folks to be more explicit > > about. . . > > > > What specific version before the upgrade? > > > > release/11.0.0/ > > release/11.0.1/ > > releng/11.0/ for what -r3????? > > stable/11/ for what -r3????? > > > > What specific version for the attempted > > "upgrade to": > > > > release/11.0.1/ > > releng/11.0/ for what -r3????? > > releng/11.1/ for what -r3????? > > stable/11/ for what -r3????? > > > > > > I've assumed above that you did not > > try to upgrade to: > > > > head/ for some -r3????? > > > > (also called CURRENT or 12-CURRENT). > > But I could be wrong. head/ is more > > likely to end up with odd problems > > and has had some recent ones. > > > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > I'm sorry, I thought that it could be assumed that I installed > RELEASE: I simply installed 11.0-RELEASE-p1 (from an iso image) and > updated the source from base/releng/11.0 which gave me revision > 320623. > > make buildworld > make kernel > shutdown -r now > -> kernel panic > then... > boot kernel.old > > I did not try anything custom. > > Alan > > > Do you have a backtrace from the panic? ... kldload: unexpected relocation type 1606324608 panic: vm_fault: fault on nofault entry, addr: c000000001c80000 cpuid = 0 KDB: stack backtrace #1 0x614874 at .vpanic+0x190 #1 0x614910 at .panic+0x38 #2 0x9dc298 at .vm_fault_hold+0x1ac #3 0x9dffe4 at .vm_fault+0x9c #4 0xa6d3dc at .trap_pfault+0xb0 #5 0xa6f1d0 at .trap+0x1b6c #6 0xa62850 at .powerpc_interrupt+0x1c4 Uptime: 1s Silly me - I think that I figured it out. I had if_bwn_load="YES" in /boot/loader.conf Removing this, the new kernel boots. I guess that the module is incompatible and gets updated with installworld. I'm testing this hypothesis... Maybe the handbook section 23.5 ought to be corrected to specify removing the loading of all modules in loader.conf? Alan From owner-freebsd-ppc@freebsd.org Tue Jul 4 22:52:53 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55FF4D9C946 for ; Tue, 4 Jul 2017 22:52:53 +0000 (UTC) (envelope-from braslau.list@comcast.net) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "resqmta-po-01v.sys.comcast.net", Issuer "COMODO RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 281C565FBA for ; Tue, 4 Jul 2017 22:52:53 +0000 (UTC) (envelope-from braslau.list@comcast.net) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-12v.sys.comcast.net with SMTP id SWged4z2GdI0qSWgedH2nB; Tue, 04 Jul 2017 22:52:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1499208772; bh=5AytTQ/BOHR6pUpPQyAqNCx1pcTtr3iKva4JR+lg6hA=; h=Received:Received:Date:From:To:Subject:Message-ID:MIME-Version: Content-Type; b=aI9igWut6DWqKmIBGtKomP5vwJhUfAc8Vuys365nvjHg+M4ymny4th9RMKmb9ahRO YCvxXyNcYx1UrqMDhiSsKC3H0lLeZF4wvp3uf3LU5zCwvqpA2JPtgA468JTpOof4fw R5Qbq3/7g+ERuiWvg6tkMBe977tyaFyyV8ROyfCvOevbd+85NdBFwMRdyYgpvZqgvH dyu4PXB91DBcyyBYVWWuhgkPfMhNvpSAjiE7RgqbTzaMwfwnL0Sgy++yTn7noszmqT lf/+Wz+u/Wva+x0mcJTqXzcHD1v54s/IKDCtMBP+RxUWlt7ZlqrjpOiDR4Ck1HWtvD 2uMrOENd77QXw== Received: from zoo.hsd1.co.comcast.net ([IPv6:2601:282:8000:7637:b0f6:5c54:9af2:6790]) by resomta-po-12v.sys.comcast.net with SMTP id SWgddmmn8dPKDSWgddWbj1; Tue, 04 Jul 2017 22:52:52 +0000 Date: Tue, 4 Jul 2017 16:52:49 -0600 From: Alan Braslau To: Mark Millard Cc: FreeBSD PowerPC ML , Justin Hibbits Subject: Re: powerpc64 update from source kernel panic (11.0) Message-ID: <20170704165249.10d01228@zoo.hsd1.co.comcast.net> In-Reply-To: <19637A8C-9C28-42D9-8E3E-E30E998D787A@dsl-only.net> References: <20170704145456.6d8c095e@zoo.hsd1.co.comcast.net> <19637A8C-9C28-42D9-8E3E-E30E998D787A@dsl-only.net> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-apple-darwin16.6.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfFWPUD1sl2ei2wZ6jIggWQJTmFbaqwvkm6yRVyWxZyQfCQygH4ucCGOyWtAupjyJCae+Y81xaD5a3krxclsTBps3p4sDoAAQ3rugfAfo9r8Ut9EEOYp/ 9mMAAKGIGWWaO3kKpva6qXFNVh4uRIwCR+2Kasygw4cRdD8V2fBtCDOqUpuk23BT0Jxb1zf/4Wb8Z46wvRV5LfPfjus2Q954uAp4belzdsW3KVGJR1ekYrRi d3bI+QnvoGtDPlI9EZEzIQ== X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 22:52:53 -0000 On Tue, 4 Jul 2017 15:37:31 -0700 Mark Millard wrote: > On 2017-Jul-4, at 1:54 PM, Alan Braslau > wrote: > > >> Alan Braslau braslau.list at comcast.net wrote on > >> Tue Jul 4 16:01:41 UTC 2017 : > >> > >>> I installed freebsd 11.0 powerpc64 on an iMac G5 without any > >>> problems and have installed a fairly complete functional system. > >>> > >>> However, upgrading from source (unmodified configuration) results > >>> in a kernel panic upon boot. Has anyone experienced this? > > . . . > > I'm sorry, I thought that it could be assumed that I installed > > RELEASE: I simply installed 11.0-RELEASE-p1 (from an iso image) and > > updated the source from base/releng/11.0 which gave me revision > > 320623. > > > > make buildworld > > make kernel > > shutdown -r now > > -> kernel panic > > then... > > boot kernel.old > > > > I did not try anything custom. > > I probably also should have asked if you are > using 32-bit FreeBSD or 64-bit. (G5's can use > either when things are working.) > > -r320623 is from head (not from releng/11.0/ ): > > https://svnweb.freebsd.org/base/head/?view=log s shows: > > Revision 320623 - Directory Listing > Modified Mon Jul 3 23:27:57 2017 UTC (23 hours, 2 minutes ago) by > jasone Update jemalloc to 5.0.1. > > If this is real then you have jumped to a binary incompatible > kernel relative to your world. (That may not be the only > problem and you might not have even got that far.) > > As of when I looked head was up to -r320659 . > > I list the below in case the 320623 is a typo or some such. . . > > https://svnweb.freebsd.org/base/releng/11.0/?view=log shows: > > -r317487 from 2017-Apr-27 > -r316722 from 2017-Apr-12 > -r314125 from 2017-Feb-23 > (I'll stop there.) > > https://svnweb.freebsd.org/base/releng/11.1/?view=log shows: > > -r320654 from 2017-Jul-4 > -r320639 from 2017-Jul-4 > -r320608 from 2017-Jul-3 > (I'll stop there.) > > https://svnweb.freebsd.org/base/stable/11/?view=log shows: > > -r320645 from 2017-Jul-4 > -r320641 from 2017-Jul-4 > -r320638 from 2017-Jul-4 > -r320621 from 2017-Jul-3 > (I'll stop there.) > > > Can you report for sure what you actually got? > > === > Mark Millard > markmi at dsl-only.net > 320623 seemed odd and typing svn up gives 320659 and svn info indeed gives 317487 (2017-04-27) as the last changed revision. (am I misusing svn?) Also, I thought that I specified powerpc64. Indeed, the problem seems to be the loading of a kmod that does not get updated until installworld. My fault (or some missing information in the handbook). Alan From owner-freebsd-ppc@freebsd.org Tue Jul 4 23:28:18 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F15CD9D23B for ; Tue, 4 Jul 2017 23:28:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BF59566BC1 for ; Tue, 4 Jul 2017 23:28:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18835 invoked from network); 4 Jul 2017 23:32:35 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 4 Jul 2017 23:32:35 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Tue, 04 Jul 2017 19:28:16 -0400 (EDT) Received: (qmail 31718 invoked from network); 4 Jul 2017 23:28:15 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 4 Jul 2017 23:28:15 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 4A61AEC90E0; Tue, 4 Jul 2017 16:28:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: powerpc64 update from source kernel panic (11.0) From: Mark Millard In-Reply-To: <20170704165249.10d01228@zoo.hsd1.co.comcast.net> Date: Tue, 4 Jul 2017 16:28:14 -0700 Cc: FreeBSD PowerPC ML , Justin Hibbits Content-Transfer-Encoding: 7bit Message-Id: <7800C44D-8FD9-480B-8D53-D505F72F082E@dsl-only.net> References: <20170704145456.6d8c095e@zoo.hsd1.co.comcast.net> <19637A8C-9C28-42D9-8E3E-E30E998D787A@dsl-only.net> <20170704165249.10d01228@zoo.hsd1.co.comcast.net> To: Alan Braslau X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 23:28:18 -0000 On 2017-Jul-4, at 3:52 PM, Alan Braslau wrote: > On Tue, 4 Jul 2017 15:37:31 -0700 > Mark Millard wrote: > >> On 2017-Jul-4, at 1:54 PM, Alan Braslau >> wrote: >> >>>> Alan Braslau braslau.list at comcast.net wrote on >>>> Tue Jul 4 16:01:41 UTC 2017 : >>>> >>>>> I installed freebsd 11.0 powerpc64 on an iMac G5 without any >>>>> problems and have installed a fairly complete functional system. >>>>> >>>>> However, upgrading from source (unmodified configuration) results >>>>> in a kernel panic upon boot. Has anyone experienced this? >>> . . . >>> I'm sorry, I thought that it could be assumed that I installed >>> RELEASE: I simply installed 11.0-RELEASE-p1 (from an iso image) and >>> updated the source from base/releng/11.0 which gave me revision >>> 320623. >>> >>> make buildworld >>> make kernel >>> shutdown -r now >>> -> kernel panic >>> then... >>> boot kernel.old >>> >>> I did not try anything custom. >> >> I probably also should have asked if you are >> using 32-bit FreeBSD or 64-bit. (G5's can use >> either when things are working.) >> >> -r320623 is from head (not from releng/11.0/ ): >> >> https://svnweb.freebsd.org/base/head/?view=log s shows: >> >> Revision 320623 - Directory Listing >> Modified Mon Jul 3 23:27:57 2017 UTC (23 hours, 2 minutes ago) by >> jasone Update jemalloc to 5.0.1. >> >> If this is real then you have jumped to a binary incompatible >> kernel relative to your world. (That may not be the only >> problem and you might not have even got that far.) >> >> As of when I looked head was up to -r320659 . >> >> I list the below in case the 320623 is a typo or some such. . . >> >> https://svnweb.freebsd.org/base/releng/11.0/?view=log shows: >> >> -r317487 from 2017-Apr-27 >> -r316722 from 2017-Apr-12 >> -r314125 from 2017-Feb-23 >> (I'll stop there.) >> >> https://svnweb.freebsd.org/base/releng/11.1/?view=log shows: >> >> -r320654 from 2017-Jul-4 >> -r320639 from 2017-Jul-4 >> -r320608 from 2017-Jul-3 >> (I'll stop there.) >> >> https://svnweb.freebsd.org/base/stable/11/?view=log shows: >> >> -r320645 from 2017-Jul-4 >> -r320641 from 2017-Jul-4 >> -r320638 from 2017-Jul-4 >> -r320621 from 2017-Jul-3 >> (I'll stop there.) >> >> >> Can you report for sure what you actually got? >> >> === >> Mark Millard >> markmi at dsl-only.net >> > > 320623 seemed odd > and typing svn up gives 320659 > and svn info indeed gives 317487 (2017-04-27) as the last changed > revision. There are two revisions for svn. If you explicitly use update -r?????? the two will be equal, for example: # svnlite info /usr/src | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 320570 Last Changed Rev: 320570 But if you just grab the most current without specifying then the "Last Changed Rev" number is what you want to reference. The other number will reflect the global svn state across branches and such and so frequently will appear more recent than what is actually checked out and also possibly pointing into the wrong branch. > (am I misusing svn?) > > Also, I thought that I specified powerpc64. I agree that I likely should have taken "freebsd 11.0 powerpc64" to mean: TARGET_ARCH=powerpc64 But, with things already being odd, I wanted to be sure it was just not the processor-type that was being specified. (In head TARGET_ARCH=powerpc recently has had extra problems that did not show up for TARGET_ARCH=powerpc64 .) > Indeed, the problem seems to be the loading of a kmod that does not get > updated until installworld. My fault (or some missing information in > the handbook). I've never used PORTS_MODULES or the like so I'm unsure of the details for avoiding compatibility issues. === Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Jul 4 23:55:51 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62F0DD9D74D for ; Tue, 4 Jul 2017 23:55:51 +0000 (UTC) (envelope-from braslau.list@comcast.net) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "resqmta-po-01v.sys.comcast.net", Issuer "COMODO RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 272F26751C for ; Tue, 4 Jul 2017 23:55:51 +0000 (UTC) (envelope-from braslau.list@comcast.net) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-05v.sys.comcast.net with SMTP id SXfZdjD40krxnSXfZdJfOl; Tue, 04 Jul 2017 23:55:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1499212549; bh=s5aVE9p4Ug6LlheUqM5SVu5McFp1Rz0JYBJ/+KnQ25M=; h=Received:Received:Date:From:To:Subject:Message-ID:MIME-Version: Content-Type; b=mwGr+bdvyGuQ6jat202GMyJoizT4ka+7NVG3rtD3JDOeHBA4+k50zzln8xw9cjEUH KaQbuDwVvH2QSsWHaTyClpi6/zXlp1vrED7IM04h7ehCTm1sSzBm3tO+T7f+T9zp1p TSH6MM2hN2rcmx7ESvBvMBaI9grPlF14boRFWktC1uhpg+iPLylEXW9DjTIAqE0QV0 UEYiOHGmAL7UxyodOllw5qP5eiaAQz3lsv1LswSVG+TfBIiYTJqIDS4GIdbPkjXx6W F9fUYzxlaHzI0NvcWWchwPuCHlenE4CcGeRhqjs+qnZTlsV5SKkVXIBZRp/k8cjEax zc1Ffar7r/crg== Received: from zoo.hsd1.co.comcast.net ([IPv6:2601:282:8000:7637:b0f6:5c54:9af2:6790]) by resomta-po-01v.sys.comcast.net with SMTP id SXfYdSnNGPheQSXfZd47Bs; Tue, 04 Jul 2017 23:55:49 +0000 Date: Tue, 4 Jul 2017 17:55:46 -0600 From: Alan Braslau To: Mark Millard Cc: FreeBSD PowerPC ML , Justin Hibbits Subject: Re: powerpc64 update from source kernel panic (11.0) Message-ID: <20170704175546.3f006aee@zoo.hsd1.co.comcast.net> In-Reply-To: <7800C44D-8FD9-480B-8D53-D505F72F082E@dsl-only.net> References: <20170704145456.6d8c095e@zoo.hsd1.co.comcast.net> <19637A8C-9C28-42D9-8E3E-E30E998D787A@dsl-only.net> <20170704165249.10d01228@zoo.hsd1.co.comcast.net> <7800C44D-8FD9-480B-8D53-D505F72F082E@dsl-only.net> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-apple-darwin16.6.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfAMGtR5rqHWOGGT8JSYNplbpyu5red43CoJGwtXIzFujbQb5G/KL/eJXuUN1aOWiU6V1hgEpulbvOi73HnlkHAQa8R6DXt5qEviz5rLA3jUd6ysVeG67 OHZQ5IwAvE/Bng0aedKaEVar+nWe8cYzJxMf5ArKx70Snwjk6WP/p3yU/NbwZY8YkLQX+P3s7GvKQ6EUxU8SL9CsPZJXMMuv6Z5UsQDd9Ds07qYVRZdVqEHO g+dAVgxm6VHXKhYiLnLxQw== X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 23:55:51 -0000 On Tue, 4 Jul 2017 16:28:14 -0700 Mark Millard wrote: > On 2017-Jul-4, at 3:52 PM, Alan Braslau > wrote: > > > On Tue, 4 Jul 2017 15:37:31 -0700 > > Mark Millard wrote: > > > >> On 2017-Jul-4, at 1:54 PM, Alan Braslau > >> wrote: > >> > >>>> Alan Braslau braslau.list at comcast.net wrote on > >>>> Tue Jul 4 16:01:41 UTC 2017 : > >>>> > >>>>> I installed freebsd 11.0 powerpc64 on an iMac G5 without any > >>>>> problems and have installed a fairly complete functional system. > >>>>> > >>>>> However, upgrading from source (unmodified configuration) > >>>>> results in a kernel panic upon boot. Has anyone experienced > >>>>> this? > >>> . . . > >>> I'm sorry, I thought that it could be assumed that I installed > >>> RELEASE: I simply installed 11.0-RELEASE-p1 (from an iso image) > >>> and updated the source from base/releng/11.0 which gave me > >>> revision 320623. > >>> > >>> make buildworld > >>> make kernel > >>> shutdown -r now > >>> -> kernel panic > >>> then... > >>> boot kernel.old > >>> > >>> I did not try anything custom. > >> > >> I probably also should have asked if you are > >> using 32-bit FreeBSD or 64-bit. (G5's can use > >> either when things are working.) > >> > >> -r320623 is from head (not from releng/11.0/ ): > >> > >> https://svnweb.freebsd.org/base/head/?view=log s shows: > >> > >> Revision 320623 - Directory Listing > >> Modified Mon Jul 3 23:27:57 2017 UTC (23 hours, 2 minutes ago) by > >> jasone Update jemalloc to 5.0.1. > >> > >> If this is real then you have jumped to a binary incompatible > >> kernel relative to your world. (That may not be the only > >> problem and you might not have even got that far.) > >> > >> As of when I looked head was up to -r320659 . > >> > >> I list the below in case the 320623 is a typo or some such. . . > >> > >> https://svnweb.freebsd.org/base/releng/11.0/?view=log shows: > >> > >> -r317487 from 2017-Apr-27 > >> -r316722 from 2017-Apr-12 > >> -r314125 from 2017-Feb-23 > >> (I'll stop there.) > >> > >> https://svnweb.freebsd.org/base/releng/11.1/?view=log shows: > >> > >> -r320654 from 2017-Jul-4 > >> -r320639 from 2017-Jul-4 > >> -r320608 from 2017-Jul-3 > >> (I'll stop there.) > >> > >> https://svnweb.freebsd.org/base/stable/11/?view=log shows: > >> > >> -r320645 from 2017-Jul-4 > >> -r320641 from 2017-Jul-4 > >> -r320638 from 2017-Jul-4 > >> -r320621 from 2017-Jul-3 > >> (I'll stop there.) > >> > >> > >> Can you report for sure what you actually got? > >> > >> === > >> Mark Millard > >> markmi at dsl-only.net > >> > > > > 320623 seemed odd > > and typing svn up gives 320659 > > and svn info indeed gives 317487 (2017-04-27) as the last changed > > revision. > > There are two revisions for svn. If you explicitly use > update -r?????? the two will be equal, for example: > > # svnlite info /usr/src | grep "Re[plv]" > Relative URL: ^/head > Repository Root: svn://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 320570 > Last Changed Rev: 320570 > > But if you just grab the most current without > specifying then the "Last Changed Rev" number > is what you want to reference. > > The other number will reflect the global svn > state across branches and such and so frequently > will appear more recent than what is actually > checked out and also possibly pointing into > the wrong branch. > > > (am I misusing svn?) > > > > Also, I thought that I specified powerpc64. > > I agree that I likely should have taken > "freebsd 11.0 powerpc64" to mean: > > TARGET_ARCH=powerpc64 > > But, with things already being odd, I wanted to > be sure it was just not the processor-type that > was being specified. (In head TARGET_ARCH=powerpc > recently has had extra problems that did not > show up for TARGET_ARCH=powerpc64 .) > > > Indeed, the problem seems to be the loading of a kmod that does not > > get updated until installworld. My fault (or some missing > > information in the handbook). > > I've never used PORTS_MODULES or the like > so I'm unsure of the details for avoiding > compatibility issues. > > > === > Mark Millard > markmi at dsl-only.net > Thank you for the explanations. I had simply typed: mv /usr/src /usr/src.bak svn co https://svn.freebsd.org/base/releng/11.0 /usr/src I may have done an svn up the next day before buildworld. (I have never specified revisions, as I have usually used svn on an entire project repository.) By the way, the handbook does not suggest using "svn up -rXXXXXX" so I do not know that I did anything unusual. I still don't get the problem as I am not using any PORTS_MODULES. I see that /boot/kernel is a directory containing all of its modules, as is /boot/kernel.old The updated system is running, and I have moved the loading of the wireless module from /boot/loader.conf to /etc/rc.conf. Maybe this module is fussy about when it is loaded and perhaps it is not generally recommended to load modules via loader.conf. Note that the module loaded previous to the update of the kernel via loader.conf. Sorry for this noise... Alan From owner-freebsd-ppc@freebsd.org Wed Jul 5 00:33:40 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 37A56D9E42C for ; Wed, 5 Jul 2017 00:33:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EC330683BC for ; Wed, 5 Jul 2017 00:33:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19072 invoked from network); 5 Jul 2017 00:33:38 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 5 Jul 2017 00:33:38 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Tue, 04 Jul 2017 20:33:38 -0400 (EDT) Received: (qmail 19537 invoked from network); 5 Jul 2017 00:33:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Jul 2017 00:33:38 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 64A25EC85D5; Tue, 4 Jul 2017 17:33:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: powerpc64 update from source kernel panic (11.0) From: Mark Millard In-Reply-To: <20170704175546.3f006aee@zoo.hsd1.co.comcast.net> Date: Tue, 4 Jul 2017 17:33:36 -0700 Cc: FreeBSD PowerPC ML , Justin Hibbits Content-Transfer-Encoding: quoted-printable Message-Id: <126985AE-747B-4CC9-8460-C53BFE6E3CEC@dsl-only.net> References: <20170704145456.6d8c095e@zoo.hsd1.co.comcast.net> <19637A8C-9C28-42D9-8E3E-E30E998D787A@dsl-only.net> <20170704165249.10d01228@zoo.hsd1.co.comcast.net> <7800C44D-8FD9-480B-8D53-D505F72F082E@dsl-only.net> <20170704175546.3f006aee@zoo.hsd1.co.comcast.net> To: Alan Braslau X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 00:33:40 -0000 On 2017-Jul-4, at 4:55 PM, Alan Braslau = wrote: > On Tue, 4 Jul 2017 16:28:14 -0700 > Mark Millard wrote: >=20 >> On 2017-Jul-4, at 3:52 PM, Alan Braslau >> wrote: >>=20 >>> . . . >>=20 >> There are two revisions for svn. If you explicitly use >> update -r?????? the two will be equal, for example: >>=20 >> # svnlite info /usr/src | grep "Re[plv]"=20 >> Relative URL: ^/head >> Repository Root: svn://svn0.us-west.freebsd.org/base >> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >> Revision: 320570 >> Last Changed Rev: 320570 >>=20 >> But if you just grab the most current without >> specifying then the "Last Changed Rev" number >> is what you want to reference. >>=20 >> The other number will reflect the global svn >> state across branches and such and so frequently >> will appear more recent than what is actually >> checked out and also possibly pointing into >> the wrong branch. >>=20 >>> (am I misusing svn?) >>>=20 >>> Also, I thought that I specified powerpc64. =20 >>=20 >> I agree that I likely should have taken >> "freebsd 11.0 powerpc64" to mean: >>=20 >> TARGET_ARCH=3Dpowerpc64 >>=20 >> But, with things already being odd, I wanted to >> be sure it was just not the processor-type that >> was being specified. (In head TARGET_ARCH=3Dpowerpc >> recently has had extra problems that did not >> show up for TARGET_ARCH=3Dpowerpc64 .) >>=20 >>> Indeed, the problem seems to be the loading of a kmod that does not >>> get updated until installworld. My fault (or some missing >>> information in the handbook). =20 >>=20 >> I've never used PORTS_MODULES or the like >> so I'm unsure of the details for avoiding >> compatibility issues. >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >=20 > Thank you for the explanations. > I had simply typed: >=20 > mv /usr/src /usr/src.bak > svn co https://svn.freebsd.org/base/releng/11.0 /usr/src >=20 > I may have done an >=20 > svn up >=20 > the next day before buildworld. > (I have never specified revisions, as I have usually used svn on an > entire project repository.) I update via: svnlite update -r?????? /usr/src/ or for ports: svnlite update -r????? /usr/ports/ (The ending "/"s are optional.) I try to monitor enough to pick what I hope will be stable/reliable versions from what I've seen --and that will have specific things of interest. I rarely simply grab the most recent version of the /usr/src/ tree, at least for contexts in which I'm using head. Note that this -r?????? based update does update a whole project directory tree. If I establish a new /usr/src/ tree I use: svnlite co -r?????? . . . /usr/src/ again being specific about which version that I get. But that is just me. > By the way, the handbook does not suggest using "svn up -rXXXXXX" so I > do not know that I did anything unusual. = https://www.freebsd.org/doc/en/articles/committers-guide/subversion-primer= .html does say: 5.3.4. Updating the Tree To update a working copy to either the latest revision, or a specific = revision: % svn update % svn update -r12345 To show local changes and files that are out-of-date do: % svn status --show-updates (This does presume one has cd'd to the top of the directory tree to be updated since they do not list the path on the command lines.) > I still don't get the problem as I am not using any PORTS_MODULES. > I see that /boot/kernel is a directory containing all of its modules, > as is /boot/kernel.old Lack of use of PORTS_MODULES would imply that kernel builds end up with the older, none-updated module being present. I expect that PORTS_MODULES purpose is to keep modules from ports up to date with system builds, being rebuilt based on updated headers and such. But I do not know the details of its use or what else may be required. installkernel, delete-old, and the like do not deal with removing modules that have been removed from the newer system or are otherwise not being installed any more. I periodically do something like: ls -lTt /boot/kernel/ | tail -20 to see if I've got something that is not being updated as expected. (The times are install times here, not build times, so old dates mean "not recently installed".) But I do not add any modules to the defaults or have any from ports. (My context is normally some variant of head since around when clang 3.8 became a project.) > The updated system is running, and I have moved the loading of the > wireless module from /boot/loader.conf to /etc/rc.conf. Maybe this > module is fussy about when it is loaded and perhaps it is not = generally > recommended to load modules via loader.conf. Note that the module > loaded previous to the update of the kernel via loader.conf. Interesting. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Wed Jul 5 19:36:13 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C3DAD8F773; Wed, 5 Jul 2017 19:36:13 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2812D6A1CC; Wed, 5 Jul 2017 19:36:13 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 2FDBE1183A; Wed, 5 Jul 2017 19:36:12 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 68A24589B; Wed, 5 Jul 2017 19:36:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 1BFMCoBk0twv; Wed, 5 Jul 2017 19:36:06 +0000 (UTC) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing) DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 92D805896 To: Mark Millard , Ed Maste Cc: FreeBSD Toolchain , FreeBSD PowerPC ML References: <0E42D991-D350-4DC1-A683-CEA506167520@dsl-only.net> From: Bryan Drewery Organization: FreeBSD Message-ID: Date: Wed, 5 Jul 2017 12:36:04 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tRAFk1842448Qbna1EXMCDiGJhW1W5n2x" X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 19:36:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tRAFk1842448Qbna1EXMCDiGJhW1W5n2x Content-Type: multipart/mixed; boundary="IE5eqqjihpXp6xEoUSdoF6G8Rf4c1iWLi"; protected-headers="v1" From: Bryan Drewery To: Mark Millard , Ed Maste Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Message-ID: Subject: Re: head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing) References: <0E42D991-D350-4DC1-A683-CEA506167520@dsl-only.net> In-Reply-To: --IE5eqqjihpXp6xEoUSdoF6G8Rf4c1iWLi Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/29/17 6:21 PM, Mark Millard wrote: > [I found where the tools are listed that are copied, > the list that is missing head.] >=20 > On 2017-Jun-29, at 3:33 PM, Mark Millard wrote: >=20 >> [This is a clang targetting powerpc64 context from my >> experimentation efforts, not the normal gcc 4.2.1 context >> for powerpc64.] >> >> I break out the PATH into lines below to make it easier to scan. >> See the later "sh: head: not found" line and the even later ls >> of the directory with the x86-64 program directory in use: no >> "head" is present to find. >> >> --- install32 --- >> cd /usr/src/lib; MACHINE=3Dpowerpc MACHINE_ARCH=3Dpowerpc MAKEOBJDIRPR= EFIX=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src= /world32 >> PATH=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/= src/tmp/legacy/usr/sbin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/legacy/usr/bin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/legacy/bin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/usr/sbin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/usr/bin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/legacy/usr/sbin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/legacy/usr/bin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/legacy/bin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/usr/sbin >> :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tm= p/usr/bin >> :/tmp/install.7ljKosWa >> SYSROOT=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/u= sr/src/lib32 LIBDIR=3D/usr/lib32 SHLIBDIR=3D/usr/lib32 DTRACE=3D"dtrace" = make LD=3D"/usr/local/powerpc64-freebsd/bin/ld -m elf32ppc_fbsd" OBJCOPY=3D= "/usr/local/powerpc64-freebsd/bin/objcopy" NM=3D"/usr/local/powerpc64-fre= ebsd/bin/nm" -DCOMPAT_32BIT CC=3D"cc -target powerpc64-unknown-freebsd12.= 0 --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/= usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -DCOMPAT_32BIT -mcpu=3Dpo= werpc -m32 -L/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/= usr/src/lib32/usr/lib32 --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinu= tils/powerpc.powerpc64/usr/src/lib32 -B/usr/local/powerpc64-freebsd/bin/= -B/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib= 32/usr/lib32" CXX=3D"c++ -target powerpc64-unknown-freebsd12.0 --sysroot= =3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp= -B/usr/local/powerpc64-freebsd/bin/ -DCOMPAT_32BIT -mcpu=3Dpowerpc -m32= -L/ >> usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib3= 2/usr/lib32 --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc= =2Epowerpc64/usr/src/lib32 -B/usr/local/powerpc64-freebsd/bin/ -B/usr/ob= j/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib= 32" CPP=3D"cpp -target powerpc64-unknown-freebsd12.0 --sysroot=3D/usr/obj= /powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp -B/usr/loc= al/powerpc64-freebsd/bin/ -DCOMPAT_32BIT -mcpu=3Dpowerpc -m32 -L/usr/obj= /powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib3= 2 --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64= /usr/src/lib32 -B/usr/local/powerpc64-freebsd/bin/ -B/usr/obj/powerpc64v= tsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/usr/lib32" -DNO_CPU= _CFLAGS MK_CTF=3Dno -DNO_LINT MK_TESTS=3Dno MK_MAN=3Dno MK_HTML=3Dno MK_= TOOLCHAIN=3Dno -DLIBRARIES_ONLY install >> sh: head: not found >> make[4]: "/usr/src/share/mk/bsd.linker.mk" line 47: Unable to determin= e linker type from XLD=3D/usr/local/powerpc64-freebsd/bin/ld >> *** [install32] Error code 1 >> >> # ls -lT /tmp/install.7ljKosWa/ >> total 6151 >> -r-xr-xr-x 1 root wheel 12592 Jun 29 14:02:46 2017 [ >> -r-xr-xr-x 1 root wheel 207320 Jun 29 14:02:46 2017 awk >> -r-xr-xr-x 1 root wheel 8456 Jun 29 14:02:46 2017 cap_mkdb >> -r-xr-xr-x 1 root wheel 13272 Jun 29 14:02:46 2017 cat >> . . . >> -r-xr-xr-x 1 root wheel 57632 Jun 29 14:02:46 2017 find >> -r-xr-xr-x 1 root wheel 99064 Jun 29 14:02:46 2017 grep >> -r-xr-xr-x 1 root wheel 13360 Jun 29 14:02:46 2017 id >> . . . >> >> So there is no "head" to find. Below uses "find" instead >> to confirm the x86-64 ELF status: >> >> # file /tmp/install.7ljKosWa/find >> /tmp/install.7ljKosWa/find: ELF 64-bit LSB executable, x86-64, version= 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for F= reeBSD 12.0 (1200036), FreeBSD-style, stripped >> >> >> >> From /usr/src/share/mk/bsd.linker.mk : >> >> .if ${ld} =3D=3D "LD" || (${ld} =3D=3D "XLD" && ${XLD} !=3D ${LD}) >> .if !defined(${X_}LINKER_TYPE) || !defined(${X_}LINKER_VERSION) >> _ld_version!=3D ${${ld}} --version 2>/dev/null | head -n 1 || echo n= one >> .if ${_ld_version} =3D=3D "none" >> .error Unable to determine linker type from ${ld}=3D${${ld}} >> .endif >> >> >> Trying the failing line interactively (no PATH >> like above though): >> >> # /usr/local/powerpc64-freebsd/bin/ld --version 2>/dev/null | head -n = 1 || echo none >> GNU ld (GNU Binutils) 2.28 >> >> So /tmp/install.7ljKosWa/ just needed a copy of head >> in addition to what it already had. >=20 > In /usr/src/Makefile.inc1 : >=20 > ITOOLS=3D [ awk cap_mkdb cat chflags chmod chown cmp cp \ > date echo egrep find grep id install ${_install-info} \ > ln make mkdir mtree mv pwd_mkdb \ > rm sed services_mkdb sh strip sysctl test true uname wc ${_zone= info} \ > ${LOCAL_ITOOLS} >=20 > does not list "head" as a tool. >=20 > But I can externally add it via LOCAL_ITOOLS use. >=20 This change should not be needed. We don't want to be running 'ld' during installworld. The changes I made around this time should already cover the problem. Is it still occurring on a more recent buildworld+installworld, without the ITOOLS change? >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 --=20 Regards, Bryan Drewery --IE5eqqjihpXp6xEoUSdoF6G8Rf4c1iWLi-- --tRAFk1842448Qbna1EXMCDiGJhW1W5n2x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZXT+kAAoJEDXXcbtuRpfP308H/1hmVq9c1gMbTuV9nGjqzvtE 6/OdahqnpwUe+KPUriWxy5jk48s3Cl94UhE9r3tG/vxjTxSTb6QgIBsGF+6ei2yy mrSiXYZxkaVIW3VAKV8BmuMHX9zlMdoVMZtGDp+Hj0lc51LekSXvsgONrcQ1IVao MYmhjlv4FZebGuOKdGKx36Hzx1Tz1sbXv+ZbdRN3b4Mx28Pv2v2d1qPv/bzT6K6D V+TyrimxwP/y0ZNLEyGLLEJXnlrIrEWJ918wgytInRIyNdMEXnDawyK8psw4sMkI OD1PPe1i3S80hR8nVUkuTv5Eeb/EVKaxPX5AnIAkyM5cs4S2QnvZCthrulGSVko= =htt7 -----END PGP SIGNATURE----- --tRAFk1842448Qbna1EXMCDiGJhW1W5n2x-- From owner-freebsd-ppc@freebsd.org Wed Jul 5 20:42:24 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 714EFD91689 for ; Wed, 5 Jul 2017 20:42:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-4.reflexion.net [208.70.210.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36DCE700C1 for ; Wed, 5 Jul 2017 20:42:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4182 invoked from network); 5 Jul 2017 20:35:42 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 5 Jul 2017 20:35:42 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Wed, 05 Jul 2017 16:35:42 -0400 (EDT) Received: (qmail 1960 invoked from network); 5 Jul 2017 20:35:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Jul 2017 20:35:42 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 66E85EC7B2C; Wed, 5 Jul 2017 13:35:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing) From: Mark Millard In-Reply-To: Date: Wed, 5 Jul 2017 13:35:40 -0700 Cc: Ed Maste , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <8E16AF37-4D8B-4099-B366-2BA95632ECA7@dsl-only.net> References: <0E42D991-D350-4DC1-A683-CEA506167520@dsl-only.net> To: Bryan Drewery X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 20:42:24 -0000 On 2017-Jul-5, at 12:36 PM, Bryan Drewery wrote: > On 6/29/17 6:21 PM, Mark Millard wrote: >> [I found where the tools are listed that are copied, >> the list that is missing head.] >>=20 >> . . . >> In /usr/src/Makefile.inc1 : >>=20 >> ITOOLS=3D [ awk cap_mkdb cat chflags chmod chown cmp cp \ >> date echo egrep find grep id install ${_install-info} \ >> ln make mkdir mtree mv pwd_mkdb \ >> rm sed services_mkdb sh strip sysctl test true uname wc = ${_zoneinfo} \ >> ${LOCAL_ITOOLS} >>=20 >> does not list "head" as a tool. >>=20 >> But I can externally add it via LOCAL_ITOOLS use. >>=20 >=20 > This change should not be needed. We don't want to be running 'ld' > during installworld. The changes I made around this time should = already > cover the problem. Is it still occurring on a more recent > buildworld+installworld, without the ITOOLS change? ld was still in use last I checked. I've been using LOCAL_ITOOLS to avoid the problem for powerpc64's world32 activity where the problem was happening for me. See Ed Maste's -r320502 check in which I expect is a alternate workaround for the lack of "head" in that I get the same message that is being avoided unless I cause "head" to be in the ITOOLS: Author: emaste Date: Fri Jun 30 16:34:17 2017 New Revision: 320502 URL:=20 https://svnweb.freebsd.org/changeset/base/320502 Log: bsd.linker.mk: add band-aid for linker invocation failure =20 In some cases bsd.linker.mk reports an error like: =20 make[4]: ".../share/mk/bsd.linker.mk" line 56: Unknown linker from LD=3Dld -m elf32ppc_fbsd:" =20 For now change this to a .warning, and then assume GNU ld 2.17.50. At present the linker type detection is used only for enabling = build-id, and we can carry on without it when type detection fails. =20 Also, show errors from ${LD} --version to aid in failure diagnosis. Successful invocations of ${LD} --version produce no output on stderr so this will not create any spam in non-failing builds. =20 Tested by: swills Sponsored by: The FreeBSD Foundation Differential Revision:=09 https://reviews.freebsd.org/D11424 Modified: head/share/mk/bsd.linker.mk Modified: head/share/mk/bsd.linker.mk = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/share/mk/bsd.linker.mk Fri Jun 30 16:16:21 2017 = (r320501) +++ head/share/mk/bsd.linker.mk Fri Jun 30 16:34:17 2017 = (r320502) @@ -47,9 +47,9 @@ ${var}=3D ${${var}.${${X_}_ld_hash}} =20 .if ${ld} =3D=3D "LD" || (${ld} =3D=3D "XLD" && ${XLD} !=3D ${LD}) .if !defined(${X_}LINKER_TYPE) || !defined(${X_}LINKER_VERSION) -_ld_version!=3D ${${ld}} --version 2>/dev/null | head -n 1 || = echo none +_ld_version!=3D (${${ld}} --version || echo none) | head -n 1 .if ${_ld_version} =3D=3D "none" -.error Unable to determine linker type from ${ld}=3D${${ld}} +.warning Unable to determine linker type from ${ld}=3D${${ld}} .endif .if ${_ld_version:[1..2]} =3D=3D "GNU ld" ${X_}LINKER_TYPE=3D bfd @@ -58,7 +58,9 @@ _v=3D ${_ld_version:M[1-9].[0-9]*:[1]} ${X_}LINKER_TYPE=3D lld _v=3D ${_ld_version:[2]} .else -.error Unknown linker from ${ld}=3D${${ld}}: ${_ld_version} +.warning Unknown linker from ${ld}=3D${${ld}}: ${_ld_version}, = defaulting to bfd +${X_}LINKER_TYPE=3D bfd +_v=3D 2.17.50 .endif ${X_}LINKER_VERSION!=3D echo "${_v:M[1-9].[0-9]*}" | \ awk -F. '{print $$1 * 10000 + $$2 * 100 + = $$3;}' The actual error is from the piping through head when head is missing, at least in my context. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Wed Jul 5 20:54:28 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97E16D919D4; Wed, 5 Jul 2017 20:54:28 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 57BB7705D4; Wed, 5 Jul 2017 20:54:28 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 689B3130A7; Wed, 5 Jul 2017 20:54:27 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 665205A39; Wed, 5 Jul 2017 20:54:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id fqeIemkLryHy; Wed, 5 Jul 2017 20:54:23 +0000 (UTC) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing) DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com CE2735A34 To: Mark Millard Cc: Ed Maste , FreeBSD Toolchain , FreeBSD PowerPC ML References: <0E42D991-D350-4DC1-A683-CEA506167520@dsl-only.net> <8E16AF37-4D8B-4099-B366-2BA95632ECA7@dsl-only.net> From: Bryan Drewery Organization: FreeBSD Message-ID: <3bda313e-aac0-4558-6346-2d95170d2dbc@FreeBSD.org> Date: Wed, 5 Jul 2017 13:54:17 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8E16AF37-4D8B-4099-B366-2BA95632ECA7@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qWI30b2J9VMEGvwhh9RtDMRmndnIiWcrI" X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 20:54:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qWI30b2J9VMEGvwhh9RtDMRmndnIiWcrI Content-Type: multipart/mixed; boundary="jelPJTx6o6sONBobjlwg2LkD9EI7QdxGO"; protected-headers="v1" From: Bryan Drewery To: Mark Millard Cc: Ed Maste , FreeBSD Toolchain , FreeBSD PowerPC ML Message-ID: <3bda313e-aac0-4558-6346-2d95170d2dbc@FreeBSD.org> Subject: Re: head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing) References: <0E42D991-D350-4DC1-A683-CEA506167520@dsl-only.net> <8E16AF37-4D8B-4099-B366-2BA95632ECA7@dsl-only.net> In-Reply-To: <8E16AF37-4D8B-4099-B366-2BA95632ECA7@dsl-only.net> --jelPJTx6o6sONBobjlwg2LkD9EI7QdxGO Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 7/5/17 1:35 PM, Mark Millard wrote: > On 2017-Jul-5, at 12:36 PM, Bryan Drewery wrote:= >=20 >> On 6/29/17 6:21 PM, Mark Millard wrote: >>> [I found where the tools are listed that are copied, >>> the list that is missing head.] >>> >>> . . . >>> In /usr/src/Makefile.inc1 : >>> >>> ITOOLS=3D [ awk cap_mkdb cat chflags chmod chown cmp cp \ >>> date echo egrep find grep id install ${_install-info} \ >>> ln make mkdir mtree mv pwd_mkdb \ >>> rm sed services_mkdb sh strip sysctl test true uname wc ${_zon= einfo} \ >>> ${LOCAL_ITOOLS} >>> >>> does not list "head" as a tool. >>> >>> But I can externally add it via LOCAL_ITOOLS use. >>> >> >> This change should not be needed. We don't want to be running 'ld' >> during installworld. The changes I made around this time should alrea= dy >> cover the problem. Is it still occurring on a more recent >> buildworld+installworld, without the ITOOLS change? >=20 > ld was still in use last I checked. I've been using LOCAL_ITOOLS > to avoid the problem for powerpc64's world32 activity where the > problem was happening for me. >=20 > See Ed Maste's -r320502 check in which I expect is a alternate > workaround for the lack of "head" in that I get the same message > that is being avoided unless I cause "head" to be in the ITOOLS: >=20 >=20 > Author: emaste > Date: Fri Jun 30 16:34:17 2017 > New Revision: 320502 > URL:=20 > https://svnweb.freebsd.org/changeset/base/320502 >=20 >=20 > Log: > bsd.linker.mk: add band-aid for linker invocation failure > =20 > In some cases bsd.linker.mk reports an error like: > =20 > make[4]: ".../share/mk/bsd.linker.mk" line 56: > Unknown linker from LD=3Dld -m elf32ppc_fbsd:" > =20 > For now change this to a .warning, and then assume GNU ld 2.17.50. > At present the linker type detection is used only for enabling build-= id, > and we can carry on without it when type detection fails. > =20 > Also, show errors from ${LD} --version to aid in failure diagnosis. > Successful invocations of ${LD} --version produce no output on stderr= > so this will not create any spam in non-failing builds. > =20 > Tested by: swills > Sponsored by: The FreeBSD Foundation > Differential Revision:=09 > https://reviews.freebsd.org/D11424 >=20 >=20 > Modified: > head/share/mk/bsd.linker.mk >=20 > Modified: head/share/mk/bsd.linker.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- head/share/mk/bsd.linker.mk Fri Jun 30 16:16:21 2017 (r320501) > +++ head/share/mk/bsd.linker.mk Fri Jun 30 16:34:17 2017 (r320502) > @@ -47,9 +47,9 @@ ${var}=3D ${${var}.${${X_}_ld_hash}} > =20 > .if ${ld} =3D=3D "LD" || (${ld} =3D=3D "XLD" && ${XLD} !=3D ${LD}) > .if !defined(${X_}LINKER_TYPE) || !defined(${X_}LINKER_VERSION) > -_ld_version!=3D ${${ld}} --version 2>/dev/null | head -n 1 || echo non= e > +_ld_version!=3D (${${ld}} --version || echo none) | head -n 1 > .if ${_ld_version} =3D=3D "none" > -.error Unable to determine linker type from ${ld}=3D${${ld}} > +.warning Unable to determine linker type from ${ld}=3D${${ld}} > .endif > .if ${_ld_version:[1..2]} =3D=3D "GNU ld" > ${X_}LINKER_TYPE=3D bfd > @@ -58,7 +58,9 @@ _v=3D ${_ld_version:M[1-9].[0-9]*:[1]} > ${X_}LINKER_TYPE=3D lld > _v=3D ${_ld_version:[2]} > .else > -.error Unknown linker from ${ld}=3D${${ld}}: ${_ld_version} > +.warning Unknown linker from ${ld}=3D${${ld}}: ${_ld_version}, default= ing to bfd > +${X_}LINKER_TYPE=3D bfd > +_v=3D 2.17.50 > .endif > ${X_}LINKER_VERSION!=3D echo "${_v:M[1-9].[0-9]*}" | \ > awk -F. '{print $$1 * 10000 + $$2 * 100 + $$3;}' >=20 >=20 >=20 > The actual error is from the piping through head > when head is missing, at least in my context. Right, neither that commit nor adding head to [LOCAL_]ITOOLS should be needed. I wasn't able to recreate any of the problems when I tried last. I will look again. --=20 Regards, Bryan Drewery --jelPJTx6o6sONBobjlwg2LkD9EI7QdxGO-- --qWI30b2J9VMEGvwhh9RtDMRmndnIiWcrI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZXVH6AAoJEDXXcbtuRpfPpOEIAL83WZ4C5xN72VhNhG7iKF9/ mzHHd3WhBd0PGfQS3a1CjttGYb+cFULO9L0ku9yrI90Top9Sq4tBtdqjIqwJNRmz LdWTH5Ks5CoFYRkOXUK1iZd+OYmtmaXC8k/ajzy/M9TRnocB/g9jW2aTeTgXw6lo h40hzvIM7FbHqMQByKX3FmKMMB1IWiqeclVQFNJ7/BF4lCEmez8acVUysfESj9k/ 556zZ9AJEV02ZpwvA6OIB57PQEOq4X+3QJwxOZzU6QhuUyEA9PbVSghKz3vpIQpO QKOZU7tSxfzui4Gp6k4eJFA25xJZxjtxxfocUUBvjsAD3QSP3hsDPf9XnjiZKuU= =3LZh -----END PGP SIGNATURE----- --qWI30b2J9VMEGvwhh9RtDMRmndnIiWcrI-- From owner-freebsd-ppc@freebsd.org Wed Jul 5 21:41:28 2017 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 316ABD92CC6 for ; Wed, 5 Jul 2017 21:41:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-4.reflexion.net [208.70.210.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E470672200 for ; Wed, 5 Jul 2017 21:41:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9389 invoked from network); 5 Jul 2017 21:41:26 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 5 Jul 2017 21:41:26 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Wed, 05 Jul 2017 17:41:26 -0400 (EDT) Received: (qmail 29770 invoked from network); 5 Jul 2017 21:41:26 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Jul 2017 21:41:26 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6CC45EC8678; Wed, 5 Jul 2017 14:41:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing) From: Mark Millard In-Reply-To: <3bda313e-aac0-4558-6346-2d95170d2dbc@FreeBSD.org> Date: Wed, 5 Jul 2017 14:41:24 -0700 Cc: Ed Maste , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E42D991-D350-4DC1-A683-CEA506167520@dsl-only.net> <8E16AF37-4D8B-4099-B366-2BA95632ECA7@dsl-only.net> <3bda313e-aac0-4558-6346-2d95170d2dbc@FreeBSD.org> To: Bryan Drewery X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 21:41:28 -0000 [I show the specifics for how I normally build powerpc64 with world32/lib32 involved. Ed Maste's submittal also mentions "elf32ppc_fbsd". The issue's context may be powerpc64 specific.] On 2017-Jul-5, at 1:54 PM, Bryan Drewery wrote: > On 7/5/17 1:35 PM, Mark Millard wrote: >> On 2017-Jul-5, at 12:36 PM, Bryan Drewery = wrote: >>=20 >>> On 6/29/17 6:21 PM, Mark Millard wrote: >>>> [I found where the tools are listed that are copied, >>>> the list that is missing head.] >>>>=20 >>>> . . . >>>> In /usr/src/Makefile.inc1 : >>>>=20 >>>> ITOOLS=3D [ awk cap_mkdb cat chflags chmod chown cmp cp \ >>>> date echo egrep find grep id install ${_install-info} \ >>>> ln make mkdir mtree mv pwd_mkdb \ >>>> rm sed services_mkdb sh strip sysctl test true uname wc = ${_zoneinfo} \ >>>> ${LOCAL_ITOOLS} >>>>=20 >>>> does not list "head" as a tool. >>>>=20 >>>> But I can externally add it via LOCAL_ITOOLS use. >>>>=20 >>>=20 >>> This change should not be needed. We don't want to be running 'ld' >>> during installworld. The changes I made around this time should = already >>> cover the problem. Is it still occurring on a more recent >>> buildworld+installworld, without the ITOOLS change? >>=20 >> ld was still in use last I checked. I've been using LOCAL_ITOOLS >> to avoid the problem for powerpc64's world32 activity where the >> problem was happening for me. >>=20 >> See Ed Maste's -r320502 check in which I expect is a alternate >> workaround for the lack of "head" in that I get the same message >> that is being avoided unless I cause "head" to be in the ITOOLS: >>=20 >>=20 >> Author: emaste >> Date: Fri Jun 30 16:34:17 2017 >> New Revision: 320502 >> URL:=20 >> https://svnweb.freebsd.org/changeset/base/320502 >>=20 >>=20 >> Log: >> bsd.linker.mk: add band-aid for linker invocation failure >>=20 >> In some cases bsd.linker.mk reports an error like: >>=20 >> make[4]: ".../share/mk/bsd.linker.mk" line 56: >> Unknown linker from LD=3Dld -m elf32ppc_fbsd:" >>=20 >> For now change this to a .warning, and then assume GNU ld 2.17.50. >> At present the linker type detection is used only for enabling = build-id, >> and we can carry on without it when type detection fails. >>=20 >> Also, show errors from ${LD} --version to aid in failure diagnosis. >> Successful invocations of ${LD} --version produce no output on = stderr >> so this will not create any spam in non-failing builds. >>=20 >> Tested by: swills >> Sponsored by: The FreeBSD Foundation >> Differential Revision:=09 >> https://reviews.freebsd.org/D11424 >>=20 >>=20 >> Modified: >> head/share/mk/bsd.linker.mk >>=20 >> Modified: head/share/mk/bsd.linker.mk >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- head/share/mk/bsd.linker.mk Fri Jun 30 16:16:21 2017 = (r320501) >> +++ head/share/mk/bsd.linker.mk Fri Jun 30 16:34:17 2017 = (r320502) >> @@ -47,9 +47,9 @@ ${var}=3D ${${var}.${${X_}_ld_hash}} >>=20 >> .if ${ld} =3D=3D "LD" || (${ld} =3D=3D "XLD" && ${XLD} !=3D ${LD}) >> .if !defined(${X_}LINKER_TYPE) || !defined(${X_}LINKER_VERSION) >> -_ld_version!=3D ${${ld}} --version 2>/dev/null | head -n 1 || = echo none >> +_ld_version!=3D (${${ld}} --version || echo none) | head -n 1 >> .if ${_ld_version} =3D=3D "none" >> -.error Unable to determine linker type from ${ld}=3D${${ld}} >> +.warning Unable to determine linker type from ${ld}=3D${${ld}} >> .endif >> .if ${_ld_version:[1..2]} =3D=3D "GNU ld" >> ${X_}LINKER_TYPE=3D bfd >> @@ -58,7 +58,9 @@ _v=3D ${_ld_version:M[1-9].[0-9]*:[1]} >> ${X_}LINKER_TYPE=3D lld >> _v=3D ${_ld_version:[2]} >> .else >> -.error Unknown linker from ${ld}=3D${${ld}}: ${_ld_version} >> +.warning Unknown linker from ${ld}=3D${${ld}}: ${_ld_version}, = defaulting to bfd >> +${X_}LINKER_TYPE=3D bfd >> +_v=3D 2.17.50 >> .endif >> ${X_}LINKER_VERSION!=3D echo "${_v:M[1-9].[0-9]*}" | \ >> awk -F. '{print $$1 * 10000 + $$2 * 100 + = $$3;}' >>=20 >>=20 >>=20 >> The actual error is from the piping through head >> when head is missing, at least in my context. >=20 > Right, neither that commit nor adding head to [LOCAL_]ITOOLS should be > needed. I wasn't able to recreate any of the problems when I tried > last. I will look again. Note that Ed Maste's submittal mentions "elf32ppc_fbsd" and the only context I've seen the issue is for powerpc64 with world32/lib32 involved as well. In my case this is with an external binutils because the system binutils fail last I tried and the llvm one do not work either. It is also the case that for me the compiler is the system's clang in my normal use. My normal powerpc64 build context in more detail, first the script that in turn binds SRC_ENV_CONF and then the bound file: # more = ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutil= s-amd64-host.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils-= amd64-host-$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc64-clang_altbinutils-boo= tstrap.amd64-host" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/powerpc64vtsc_clang_altbinutils" \ make $* # more = /root/src.configs/src.conf.powerpc64-clang_altbinutils-bootstrap.amd64-hos= t TO_TYPE=3Dpowerpc64 TOOLS_TO_TYPE=3D${TO_TYPE} VERSION_CONTEXT=3D12.0 # KERNCONF=3DGENERIC64vtsc-NODBG TARGET=3Dpowerpc .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITHOUT_LLD_BOOTSTRAP=3D WITH_LLD=3D WITHOUT_LLD_IS_LD=3D WITH_LLDB=3D # WITH_BOOT=3D WITH_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D MALLOC_PRODUCTION=3D # # Avoid converts between pointers to integer types with different sign = [-Werror,-Wpointer-sign] # and such from blocking the build. WERROR=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # # # For TO (so-called "cross") stages . . . # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . . # CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 # # Note: The WITH_CROSS_COMPILER picks up the CROSS_BINUTILS_PREFIX # binding automatically. # XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld .export XLD .endif =3D=3D=3D Mark Millard markmi at dsl-only.net