From owner-freebsd-arm@freebsd.org Sun Apr 9 01:02:08 2017 Return-Path: Delivered-To: freebsd-arm@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 9455DD337B2 for ; Sun, 9 Apr 2017 01:02:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-5.reflexion.net [208.70.210.5]) (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 59413C28 for ; Sun, 9 Apr 2017 01:02:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9048 invoked from network); 9 Apr 2017 01:02:01 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 9 Apr 2017 01:02:01 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 08 Apr 2017 21:02:01 -0400 (EDT) Received: (qmail 10694 invoked from network); 9 Apr 2017 01:02:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Apr 2017 01:02:01 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id BEB76EC8172; Sat, 8 Apr 2017 18:02:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them From: Mark Millard In-Reply-To: <163B37B0-55D6-498E-8F52-9A95C036CDFA@dsl-only.net> Date: Sat, 8 Apr 2017 18:02:00 -0700 Cc: andrew@freebsd.org, Konstantin Belousov Content-Transfer-Encoding: quoted-printable Message-Id: <08E7A5B0-8707-4479-9D7A-272C427FF643@dsl-only.net> References: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> <163B37B0-55D6-498E-8F52-9A95C036CDFA@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 01:02:08 -0000 [I've identified the code path involved is the arm64 small allocations turning into zeros for later fork-then-swapout-then-back-in, specifically the ongoing RES(ident memory) size decrease that "top -PCwaopid" shows before the fork/swap sequence. Hopefully I've also exposed enough related information for someone that knows what they are doing to get started with a specific investigation, looking for a fix. I'd like for a pine64+ 2GB to have buildworld complete despite the forking and swapping involved (yep: for a time zero RES(ident memory) for some processes involved in the build).] On 2017-Apr-7, at 1:16 AM, Mark Millard wrote: > [I now can: (A) crudely control the number of allocated > pages that get zeros (that should not). (B) Watch a > "top -PCwaopid" display and predict if the > test-architecture will fail or not before the fork() > or swap-out happens.] >=20 > On 2017-Apr-4, at 8:00 PM, Mark Millard wrote: >=20 >> Uncommenting/commenting parts of the below program allows >> exploring the problems with fork-then-swap-out-then-in on >> arm64. >>=20 >> Note: By swap-out I mean that zero RES(ident memory) results, >> for the process(s) of interest, as shown by >> "top -PCwaopid" . >>=20 >> I discovered recently that swapping-out just before the >> fork() prevents the failure from the swapping after the >> fork(). >>=20 >> Note: >> Without the fork() no problem happens. Without the later >> swap-out no problem happens. Both are required. But some >> activities before the fork() or between fork() and the >> swap-out prevent the failures. >>=20 >> Some of the comments are based on a pine64+ 2GB context. >> I use stress to force swap-outs during some sleeps in >> the program. See also Buzilla 217239 and 217138. (I now >> expect that they have the same cause.) >>=20 >> In my environment I've seen the fork-then-swap-out/swap-in >> failures on a pine64+ 2GB and a rpi3. They are repeatable >> on both. I do not have access to server-class machines, or >> any other arm64 machines. >>=20 >>=20 >> // swap_testing5.c >>=20 >> // Built via (cc was clang 4.0 in my case): >> // >> // cc -g -std=3Dc11 -Wpedantic -o swaptesting5 swap_testing5.c >> // -O0 and -O2 also gets the problem. >>=20 >> // Note: jemalloc's tcache needs to be enabled to get the failure. >> // But FreeBSD can get into a state were /etc/malloc.conf >> // -> 'tcache:false' is ineffective. Also: the allocation >> // size needs to by sufficiently small (<=3D SMALL_MAXCLASS) >> // to see the problem. Other comments are based on a specific >> // context (pine64+ 2GB). >>=20 >> #include // for raise(.), SIGABRT (induce core dump) >> #include // for fork(), sleep(.) >> #include // for pid_t >> #include // for wait(.) >>=20 >> extern void test_setup(void); // Sets up the memory byte = patterns. >> extern void test_check(void); // Tests the memory byte = patterns. >> extern void memory_willneed(void); // For seeing if >> // = posix_madvise(.,.,POSIX_MADV_WILLNEED) >> // makes a difference. >>=20 >> int main(void) { >> sleep(30); // Potentialy force swap-out here. >> // [Swap-out here does not avoid later failures.] >>=20 >> test_setup(); >> test_check(); // Before potential sleep(.)/swap-out or fork(.) = [passes] >>=20 >> sleep(30); // Potentialy force swap-out here. >> // [Everything below passes if swapped-out here, >> // no matter if there are later swap-outs >> // or not.] >>=20 >> pid_t pid =3D fork(); // To test no-fork use: =3D 0; no-fork does = not fail. >> int wait_status =3D 0; >>=20 >> // HERE: After fork; before sleep/swap-out/wait. >>=20 >> // if (0 < pid) memory_willneed(); // Does not prevent either = parent or >> // child failure if enabled. >>=20 >> // if (0 =3D=3D pid) memory_willneed(); // Prevents both the parent = and the >> // child failure. Disable to see >> // failure of both parent and = child. >> // [Presuming no prior swap-out: = that >> // would make everything pass.] >>=20 >> // During sleep/wait: manually force this process to >> // swap out. I use something like: >> // stress -m 1 --vm-bytes 1800M >> // in another shell and ^C'ing it after top shows the >> // swapped status desired. 1800M just happened to work >> // on the Pine64+ 2GB that I was using. I watch with >> // top -PCwaopid [checking for zero RES(ident memory)]. >>=20 >> if (0 < pid) { >> sleep(30); // Intend to swap-out during sleep. >> // test_check(); // Test in parent before child runs (longer = sleep). >> // This test fails if run for a failing = region_size >> // unless earlier preventing-activity happened. >> wait(&wait_status); // Only if test_check above passes or is >> // disabled above. >> } >> if (-1 !=3D wait_status && 0 <=3D pid) { >> if (0 =3D=3D pid) { sleep(90); } // Intend to swap-out during = sleep. >> test_check(); // Fails for small-enough region_size, both >> // parent and child processes, unless earlier >> // preventing-activty happened. >> } >> } >>=20 >> // The memory and test code follows. >>=20 >> #include // for size_t, NULL >> #include // for malloc(.), free(.) >> #include // for POSIX_MADV_WILLNEED, = posix_madvise(.,.,.) >>=20 >> #define region_size (14u*1024u) >> // Bad dyn_region pattern, parent and child processes examples: >> // 256u, 2u*1024u, 4u*1024u, 8u*1024u, 9u*1024u, 12u*1024u, = 14u*1024u >> // No failure examples: >> // 14u*1024u+1u, 15u*1024u, 16u*1024u, 32u*1024u, = 256u*1024u*1024u >> #define num_regions (256u*1024u*1024u/region_size) >>=20 >> typedef volatile unsigned char value_type; >> struct region_struct { value_type array[region_size]; }; >> typedef struct region_struct region; >> static region * volatile dyn_regions[num_regions] =3D {NULL,}; >>=20 >> static value_type value(size_t v) { return = (value_type)((v&0xFEu)|0x1u); } >> // value avoids zero values: the bad values are = zeros. >>=20 >> void test_setup(void) { >> for(size_t i=3D0u; i> dyn_regions[i] =3D malloc(sizeof(region)); >> if (!dyn_regions[i]) raise(SIGABRT); >>=20 >> for(size_t j=3D0u; j> (*dyn_regions[i]).array[j] =3D value(j); >> } >> } >> } >>=20 >> void memory_willneed(void) { >> for(size_t i=3D0u; i> (void) posix_madvise(dyn_regions[i], region_size, = POSIX_MADV_WILLNEED); >> } >> } >>=20 >> static volatile size_t first_failure_idx =3D 0u; // dyn_regions index >> static volatile size_t first_failure_pos =3D 0u; // sub-array index >> static volatile size_t after_bad_idx =3D 0u; // dyn_regions index >> static volatile size_t after_bad_pos =3D 0u; // sub-array index >> static volatile size_t after_good_idx =3D 0u; // dyn_regions index >> static volatile size_t after_good_pos =3D 0u; // sub-array index >>=20 >> // Note: Some failing cases get (conjunctive notation): >> // >> // 0 =3D=3D first_failure_idx < after_bad_idx < after_good_idx =3D=3D= num_regions >> // && 0 =3D=3D first_failure_pos && 0<=3Dafter_bad_pos<=3Dregion_size = && after_good_idx=3D=3D0 >> // && (after_bad_pos is a multiple of the page size in Bytes, here: >> // after_bad_pos=3D=3DN*4096 for some non-negative integral value = N) >> // >> // other failing cases instead fail with: >> // >> // 0 =3D=3D first_failure && num_regions =3D=3D after_bad_idx =3D=3D= after_good_idx >> // && 0 =3D=3D first_failure_pos =3D=3D after_bad_pos =3D=3D = after_good_idx >> // >> // after_bad_idx strongly tends to vary from failing run to failing = run >> // as does after_bad_pos. >>=20 >> // Note: The working cases get: >> // >> // num_regions =3D=3D first_failure =3D=3D after_bad_idx =3D=3D = after_good_idx >> // && 0 =3D=3D first_failure_pos =3D=3D after_bad_pos =3D=3D = after_good_idx >>=20 >> void test_check(void) { >> first_failure_idx =3D first_failure_pos =3D 0u; >>=20 >> while (first_failure_idx < num_regions) { >> while ( first_failure_pos < region_size >> && ( value(first_failure_pos) >> =3D=3D = (*dyn_regions[first_failure_idx]).array[first_failure_pos] >> ) >> ) { >> first_failure_pos++; >> } >>=20 >> if (region_size !=3D first_failure_pos) break; >>=20 >> first_failure_idx++; >> first_failure_pos =3D 0u; >> } >>=20 >> after_bad_idx =3D first_failure_idx; >> after_bad_pos =3D first_failure_pos; >>=20 >> while (after_bad_idx < num_regions) { >> while ( after_bad_pos < region_size >> && ( value(after_bad_pos) >> !=3D = (*dyn_regions[after_bad_idx]).array[after_bad_pos] >> ) >> ) { >> after_bad_pos++; >> } >>=20 >> if(region_size !=3D after_bad_pos) break; >>=20 >> after_bad_idx++; >> after_bad_pos =3D 0u; >> } >>=20 >> after_good_idx =3D after_bad_idx; >> after_good_pos =3D after_bad_pos; >>=20 >> while (after_good_idx < num_regions) { >> while ( after_good_pos < region_size >> && ( value(after_good_pos) >> =3D=3D = (*dyn_regions[after_good_idx]).array[after_good_pos] >> ) >> ) { >> after_good_pos++; >> } >>=20 >> if(region_size !=3D after_good_pos) break; >>=20 >> after_good_idx++; >> after_good_pos =3D 0u; >> } >>=20 >> if (num_regions !=3D first_failure_idx) raise(SIGABRT); >> } >=20 >=20 > I've found that for the above swap_testing5.c > I can make variations that change how much of the > allocated region prefix ends up zero vs. stays good. >=20 > I vary the sleep time between testing the initialized > allocations and doing the fork. The longer the sleep > the more zero pages show up (be sure to read the > comments): >=20 > # diff swap_testing[56].c = = 1c1 > < // swap_testing5.c > --- >> // swap_testing6.c > 5c5 > < // cc -g -std=3Dc11 -Wpedantic -o swaptesting5 swap_testing5.c > --- >> // cc -g -std=3Dc11 -Wpedantic -o swaptesting5 swap_testing6.c > 33c33 > < sleep(30); // Potentialy force swap-out here. > --- >> sleep(150); // Potentialy force swap-out here. > 37a38,48 >> // For no-swap-out here cases: >> // >> // The longer the sleep here the more allocations >> // that end up as zero. >> // >> // top's Mem Active, Inact, Wired, Bug, Free and >> // Swap Total, Used, and Free stay unchanged. >> // What does change is the process RES decreases >> // while the process SIZE and SWAP stay unchanged >> // during this sleep. >>=20 >=20 > NOTE: On other architectures that I've tried (such as armv6/v7) > RES does not decrease during the sleep --and the problem > does not happen even for as long of sleeps as I've tried. >=20 > (I use "stress -m 2 --vm-bytes 900M" on armv6/v7 instead > of -m 1 --vm-bytes 1800M because that large in one > process is not allowed.) >=20 > So watching top's RES during the sleep (longer than a few > seconds) just before the fork() predicts the later > fails-vs.-not status: If RES decreases (while other things > associated with the process status stay the same) then > there will be a failure. >=20 > At this point I've no clue why the sleeping process has > a decreasing RES(ident memory) size. >=20 > I infer that without the sleep there still is a small > amount of loss of RES but on too short of a timescale > to observe in a "top -PCwaopid" or other such: in other > words that the same behavior is causing the failure then > as well, possibly for a loss of only one page of RES. I've been able to identify what code sequence is gradually removing the "small_mappings" via some breakpointing in the kernel after reaching the "should be just sleeping" status. Specifically I started with breakpointing when pmap_resident_count_dec was on the call stack in order to see the call chain(s) that lead to it being called while RES(ident memory) is gradually decreasing during the sleep that is just before forking. (tid 100067 is [pagedaemon{pagedaemon}], which is in vm_pageout_worker. bt does not show inlined layers.) [ thread pid 17 tid 100067 ] Breakpoint at $x.1: undefined d65f03c0 db> bt Tracing pid 17 tid 100067 td 0xfffffd0001c4aa00 . . . handle_el1h_sync() at pmap_remove_l3+0xdc pc =3D 0xffff000000604870 lr =3D 0xffff000000611158 sp =3D 0xffff000083a49980 fp =3D 0xffff000083a49a40 pmap_remove_l3() at pmap_ts_referenced+0x580 pc =3D 0xffff000000611158 lr =3D 0xffff000000615c50 sp =3D 0xffff000083a49a50 fp =3D 0xffff000083a49ac0 pmap_ts_referenced() at vm_pageout+0xe60 pc =3D 0xffff000000615c50 lr =3D 0xffff0000005d1f74 sp =3D 0xffff000083a49ad0 fp =3D 0xffff000083a49b50 vm_pageout() at fork_exit+0x94 pc =3D 0xffff0000005d1f74 lr =3D 0xffff0000002e01c0 sp =3D 0xffff000083a49b60 fp =3D 0xffff000083a49b90 fork_exit() at fork_trampoline+0x10 pc =3D 0xffff0000002e01c0 lr =3D 0xffff0000006177b4 sp =3D 0xffff000083a49ba0 fp =3D 0x0000000000000000 It turns out that pmap_ts_referenced is on its: small_mappings: . . . path for the above so the pmap_remove_l3 call is the one from that execution path. (Found by more breakpointing after enabling such on the paths.) So this is the path with: (breakpoint hook not shown) /* * Wired pages cannot be paged out so * doing accessed bit emulation for * them is wasted effort. We do the * hard work for unwired pages only. */ pmap_remove_l3(pmap, pte, pv->pv_va, = tpde, &free, &lock); pmap_invalidate_page(pmap, pv->pv_va); cleared++; if (pvf =3D=3D pv) pvf =3D NULL; pv =3D NULL; . . . pmap_remove_l3 decrements the resident_count in this sequence. =46rom what I can tell this code is eliminating the content of pages that in the failing tests, ones with no backing store yet (not swapped-out yet by test design). The observed behavior is that the pages that have the above happen end up as zero pages after the later fork-then-swapout-then-back-in . I do not see anything putting the pages that this happens to into any other lists to keep track of the contents of the page content. The swap-out and swap-in seem to have ignored these pages and to have been based on automatically zeroed pages instead. Note that the (or a) question might be if these pages should have ever gotten to this code at all. (I'm no expert overall.) But that might get into why POSIX_MADV_WILLNEED spanning each page is sufficient to avoid the zeros issue for work-then-swapout-and-back-in. I'll only write here about what the backtrace code seems to be doing if I'm interpreting correctly. One oddity here is that pmap_remove_l3 does its own pmap_invalidate_page to invalidate the same tlb entry as the above pmap_invalidate_page, so a double-invalidate. (I've no clue if such is just suboptimal vs. a form of error.) pmap_remove_l3 here does things that the analogous sys/arm/arm/pmap-v6.c's pmap_ts_referenced does not do and pmap-v6 does something this code does not. arm64's pmap_remove_l3 does (in summary): pmap_invalidate_page decrements the resident_count pmap_unwire_l3 (then pmap_ts_referenced's small_mappings code does another pmap_invalidate_page for the same argument values) arm pmap-v6's pmap_ts_referenced's small_mappings code does: conditional vm_page_dirty pte2_clear_bit for PTE2_A pmap_tlb_flush There is, for example, no decrement of the resident_count involved (that I found anyway).=20 But I've no clue just what should be analogous vs. what should not between pmap-v6 and arm64's pmap code in this area. I'll also note that the code before the arm64 small_mappings code also uses pmap_remove_l3 but does not do the decrement nor the extra pmap_invalidate_page (for example). But again I do not know how analogous the two paths should be. Only the small_mappings path seems to have the end-up-with-zeros problem for the later fork-then-swap-out and then swap-back-in context. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Apr 9 12:27:25 2017 Return-Path: Delivered-To: freebsd-arm@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 6CA0DD2AC9F; Sun, 9 Apr 2017 12:27:25 +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 D253DF49; Sun, 9 Apr 2017 12:27:24 +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 v39CRF34047280 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 9 Apr 2017 15:27:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v39CRF34047280 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v39CRFNJ047279; Sun, 9 Apr 2017 15:27:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 9 Apr 2017 15:27:15 +0300 From: Konstantin Belousov To: Mark Millard Cc: freebsd-arm , freebsd-hackers@freebsd.org, andrew@freebsd.org Subject: Re: The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them Message-ID: <20170409122715.GF1788@kib.kiev.ua> References: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> <163B37B0-55D6-498E-8F52-9A95C036CDFA@dsl-only.net> <08E7A5B0-8707-4479-9D7A-272C427FF643@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <08E7A5B0-8707-4479-9D7A-272C427FF643@dsl-only.net> User-Agent: Mutt/1.8.0 (2017-02-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-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 12:27:25 -0000 On Sat, Apr 08, 2017 at 06:02:00PM -0700, Mark Millard wrote: > [I've identified the code path involved is the arm64 small allocations > turning into zeros for later fork-then-swapout-then-back-in, > specifically the ongoing RES(ident memory) size decrease that > "top -PCwaopid" shows before the fork/swap sequence. Hopefully > I've also exposed enough related information for someone that > knows what they are doing to get started with a specific > investigation, looking for a fix. I'd like for a pine64+ > 2GB to have buildworld complete despite the forking and > swapping involved (yep: for a time zero RES(ident memory) for > some processes involved in the build).] I was not able to follow the walls of text, but do not think that I pmap_ts_reference() is the real culprit there. Is my impression right that the issue occurs on fork, and looks as a memory corruption, where some page suddently becomes zero-filled ? And swapping seems to be involved ? It is somewhat interesting to see if the problem is reproducable on non-arm64 machines, e.g. armv7 or amd64. If answers to my two questions are yes, there is probably some bug with arm64 pmap handling of the dirty bit emulation. ARMv8.0 does not provide hardware dirty bit, and pmap interprets an accessed writeable page as unconditionally dirty. More, accessed bit is also not maintained by hardware, instead if should be set by pmap. And arm64 pmap sets the AF bit unconditionally when creating valid pte. Hmm, could you try the following patch, I did not even compiled it. diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c index 3d5756ba891..55aa402eb1c 100644 --- a/sys/arm64/arm64/pmap.c +++ b/sys/arm64/arm64/pmap.c @@ -2481,6 +2481,11 @@ pmap_protect(pmap_t pmap, vm_offset_t sva, vm_offset_t eva, vm_prot_t prot) sva += L3_SIZE) { l3 = pmap_load(l3p); if (pmap_l3_valid(l3)) { + if ((l3 & ATTR_SW_MANAGED) && + pmap_page_dirty(l3)) { + vm_page_dirty(PHYS_TO_VM_PAGE(l3 & + ~ATTR_MASK)); + } pmap_set(l3p, ATTR_AP(ATTR_AP_RO)); PTE_SYNC(l3p); /* XXX: Use pmap_invalidate_range */ From owner-freebsd-arm@freebsd.org Sun Apr 9 17:24:33 2017 Return-Path: Delivered-To: freebsd-arm@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 36D74D3640D for ; Sun, 9 Apr 2017 17:24:33 +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 F113FAF for ; Sun, 9 Apr 2017 17:24:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29826 invoked from network); 9 Apr 2017 17:24:31 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 9 Apr 2017 17:24:31 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sun, 09 Apr 2017 13:24:31 -0400 (EDT) Received: (qmail 20454 invoked from network); 9 Apr 2017 17:24:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Apr 2017 17:24:31 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5CF31EC8630; Sun, 9 Apr 2017 10:24:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them From: Mark Millard In-Reply-To: <20170409122715.GF1788@kib.kiev.ua> Date: Sun, 9 Apr 2017 10:24:29 -0700 Cc: andrew@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <9D152170-5F19-47A2-A06A-66F83CA88A09@dsl-only.net> References: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> <163B37B0-55D6-498E-8F52-9A95C036CDFA@dsl-only.net> <08E7A5B0-8707-4479-9D7A-272C427FF643@dsl-only.net> <20170409122715.GF1788@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 17:24:33 -0000 On 2017-Apr-9, at 5:27 AM, Konstantin Belousov = wrote: > On Sat, Apr 08, 2017 at 06:02:00PM -0700, Mark Millard wrote: >> [I've identified the code path involved is the arm64 small = allocations >> turning into zeros for later fork-then-swapout-then-back-in, >> specifically the ongoing RES(ident memory) size decrease that >> "top -PCwaopid" shows before the fork/swap sequence. Hopefully >> I've also exposed enough related information for someone that >> knows what they are doing to get started with a specific >> investigation, looking for a fix. I'd like for a pine64+ >> 2GB to have buildworld complete despite the forking and >> swapping involved (yep: for a time zero RES(ident memory) for >> some processes involved in the build).] >=20 > I was not able to follow the walls of text, but do not think that > I pmap_ts_reference() is the real culprit there. >=20 > Is my impression right that the issue occurs on fork, and looks as > a memory corruption, where some page suddently becomes zero-filled ? > And swapping seems to be involved ? It is somewhat interesting to see > if the problem is reproducable on non-arm64 machines, e.g. armv7 or = amd64. Yes, yes, non-arm64 that I've tried works. But I think that the following extra detail my be of use: what top shows for RES over time is also odd on arm64 (only) and the amount of pages that are zeroed is proportional to the decrease in RES. In the test sequence: A) Allocate lots of 14 KiByte allocations and initialize the content of = each to non-zero. The example ends up with RES of about 265M. B) sleep some amount of time, I've been using well over 30 seconds here. C) fork D) sleep again (parent and child), also forcing swapping during the = sleep (I used stress, manually run.) E) Test the memory pattern in the parent and child process, passing over all the bytes, failed and good. Both the parent and the child in (E) see the first pages allocated as = zero, with the number of pages being zero increasing as the sleep time in (B) increases (as long as the sleep is over 30 sec or so). The parent and = child match for which pages are zero vs. not. It fails with (B) being a no-op as well. But the proportionality with the time for the sleep is interesting. During (B) "top -PCwaopid" shows RES decreasing, starting after 30 sec or so. The fork in (C) produces a child that does not have the same RES as the parent but instead a tiny RES (80K as I remember). During (E) the child's RES increases to full size. My powerpc64, armv7, and amd64 tests of such do not fail, nor does RES decrease during (B). The child process gets the same RES as the parent as well, unlike for arm64. In the failing context (arm64) RES in the parent decreases during (D) before the swap-out as well. > If answers to my two questions are yes, there is probably some bug = with > arm64 pmap handling of the dirty bit emulation. ARMv8.0 does not = provide > hardware dirty bit, and pmap interprets an accessed writeable page as > unconditionally dirty. More, accessed bit is also not maintained by > hardware, instead if should be set by pmap. And arm64 pmap sets the > AF bit unconditionally when creating valid pte. fork-then-swap-out/in is required to see the problem. Neither fork by itself nor swapping (zero RES as shown in top) by itself have shown the problem so far. > Hmm, could you try the following patch, I did not even compiled it. I'll try it later today. > diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c > index 3d5756ba891..55aa402eb1c 100644 > --- a/sys/arm64/arm64/pmap.c > +++ b/sys/arm64/arm64/pmap.c > @@ -2481,6 +2481,11 @@ pmap_protect(pmap_t pmap, vm_offset_t sva, = vm_offset_t eva, vm_prot_t prot) > sva +=3D L3_SIZE) { > l3 =3D pmap_load(l3p); > if (pmap_l3_valid(l3)) { > + if ((l3 & ATTR_SW_MANAGED) && > + pmap_page_dirty(l3)) { > + vm_page_dirty(PHYS_TO_VM_PAGE(l3 = & > + ~ATTR_MASK)); > + } > pmap_set(l3p, ATTR_AP(ATTR_AP_RO)); > PTE_SYNC(l3p); > /* XXX: Use pmap_invalidate_range */ =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Apr 9 18:25:03 2017 Return-Path: Delivered-To: freebsd-arm@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 009ACD36B0A for ; Sun, 9 Apr 2017 18:25:03 +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 B9CFBACE for ; Sun, 9 Apr 2017 18:25:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6825 invoked from network); 9 Apr 2017 18:27:55 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 9 Apr 2017 18:27:55 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sun, 09 Apr 2017 14:25:01 -0400 (EDT) Received: (qmail 6531 invoked from network); 9 Apr 2017 18:25:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Apr 2017 18:25:00 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2747CEC8630; Sun, 9 Apr 2017 11:25:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them From: Mark Millard In-Reply-To: <9D152170-5F19-47A2-A06A-66F83CA88A09@dsl-only.net> Date: Sun, 9 Apr 2017 11:24:59 -0700 Cc: andrew@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <9DCAF95B-39A5-4346-88FC-6AFDEE8CF9BB@dsl-only.net> References: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> <163B37B0-55D6-498E-8F52-9A95C036CDFA@dsl-only.net> <08E7A5B0-8707-4479-9D7A-272C427FF643@dsl-only.net> <20170409122715.GF1788@kib.kiev.ua> <9D152170-5F19-47A2-A06A-66F83CA88A09@dsl-only.net> To: Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 18:25:03 -0000 On 2017-Apr-9, at 10:24 AM, Mark Millard wrote: > On 2017-Apr-9, at 5:27 AM, Konstantin Belousov = wrote: >=20 >> On Sat, Apr 08, 2017 at 06:02:00PM -0700, Mark Millard wrote: >>> [I've identified the code path involved is the arm64 small = allocations >>> turning into zeros for later fork-then-swapout-then-back-in, >>> specifically the ongoing RES(ident memory) size decrease that >>> "top -PCwaopid" shows before the fork/swap sequence. Hopefully >>> I've also exposed enough related information for someone that >>> knows what they are doing to get started with a specific >>> investigation, looking for a fix. I'd like for a pine64+ >>> 2GB to have buildworld complete despite the forking and >>> swapping involved (yep: for a time zero RES(ident memory) for >>> some processes involved in the build).] >>=20 >> I was not able to follow the walls of text, but do not think that >> I pmap_ts_reference() is the real culprit there. >>=20 >> Is my impression right that the issue occurs on fork, and looks as >> a memory corruption, where some page suddently becomes zero-filled ? >> And swapping seems to be involved ? It is somewhat interesting to = see >> if the problem is reproducable on non-arm64 machines, e.g. armv7 or = amd64. >=20 > Yes, yes, non-arm64 that I've tried works. >=20 > But I think that the following extra detail my be of use: what top > shows for RES over time is also odd on arm64 (only) and the amount > of pages that are zeroed is proportional to the decrease in RES. >=20 > In the test sequence: >=20 > A) Allocate lots of 14 KiByte allocations and initialize the content = of each > to non-zero. The example ends up with RES of about 265M. I did forget to list one important property: why I picked 14 KiBytes. A) Any allocation sizes <=3D 14 KiBytes that I've tried gets the zero's problem in my arm64 contexts (bpim3 and rip3). B) Any allocation size >=3D 14 KiBYtes + 1 Byte that I've tried works in those contexts. For the arm64 contexts that I use this happens to match with the jemalloc SMALL_MAXCLASS size boundary. When I looked it appeared that 14 Ki was the smallest SMALL_MAXCLASS value in jemalloc so it would always fit the category. > B) sleep some amount of time, I've been using well over 30 seconds = here. >=20 > C) fork >=20 > D) sleep again (parent and child), also forcing swapping during the = sleep > (I used stress, manually run.) >=20 > E) Test the memory pattern in the parent and child process, passing = over > all the bytes, failed and good. >=20 > Both the parent and the child in (E) see the first pages allocated as = zero, > with the number of pages being zero increasing as the sleep time in = (B) > increases (as long as the sleep is over 30 sec or so). The parent and = child > match for which pages are zero vs. not. >=20 > It fails with (B) being a no-op as well. But the proportionality with > the time for the sleep is interesting. >=20 > During (B) "top -PCwaopid" shows RES decreasing, starting after 30 sec > or so. The fork in (C) produces a child that does not have the same = RES > as the parent but instead a tiny RES (80K as I remember). During (E) > the child's RES increases to full size. >=20 > My powerpc64, armv7, and amd64 tests of such do not fail, nor does RES > decrease during (B). The child process gets the same RES as the parent > as well, unlike for arm64. >=20 > In the failing context (arm64) RES in the parent decreases during (D) > before the swap-out as well. >=20 >> If answers to my two questions are yes, there is probably some bug = with >> arm64 pmap handling of the dirty bit emulation. ARMv8.0 does not = provide >> hardware dirty bit, and pmap interprets an accessed writeable page as >> unconditionally dirty. More, accessed bit is also not maintained by >> hardware, instead if should be set by pmap. And arm64 pmap sets the >> AF bit unconditionally when creating valid pte. >=20 > fork-then-swap-out/in is required to see the problem. Neither fork > by itself nor swapping (zero RES as shown in top) by itself have > shown the problem so far. >=20 >> Hmm, could you try the following patch, I did not even compiled it. >=20 > I'll try it later today. >=20 >> diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c >> index 3d5756ba891..55aa402eb1c 100644 >> --- a/sys/arm64/arm64/pmap.c >> +++ b/sys/arm64/arm64/pmap.c >> @@ -2481,6 +2481,11 @@ pmap_protect(pmap_t pmap, vm_offset_t sva, = vm_offset_t eva, vm_prot_t prot) >> sva +=3D L3_SIZE) { >> l3 =3D pmap_load(l3p); >> if (pmap_l3_valid(l3)) { >> + if ((l3 & ATTR_SW_MANAGED) && >> + pmap_page_dirty(l3)) { >> + vm_page_dirty(PHYS_TO_VM_PAGE(l3 = & >> + ~ATTR_MASK)); >> + } >> pmap_set(l3p, ATTR_AP(ATTR_AP_RO)); >> PTE_SYNC(l3p); >> /* XXX: Use pmap_invalidate_range */ =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Apr 9 20:25:20 2017 Return-Path: Delivered-To: freebsd-arm@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 93CBCD3634A for ; Sun, 9 Apr 2017 20:25:20 +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 4B5B6839 for ; Sun, 9 Apr 2017 20:25:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20552 invoked from network); 9 Apr 2017 20:25:18 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 9 Apr 2017 20:25:18 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sun, 09 Apr 2017 16:25:18 -0400 (EDT) Received: (qmail 21557 invoked from network); 9 Apr 2017 20:25:17 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 9 Apr 2017 20:25:17 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 28AD4EC8630; Sun, 9 Apr 2017 13:25:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them From: Mark Millard In-Reply-To: <9DCAF95B-39A5-4346-88FC-6AFDEE8CF9BB@dsl-only.net> Date: Sun, 9 Apr 2017 13:25:16 -0700 Cc: andrew@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <8FFE95AA-DB40-4D1E-A103-4BA9FCC6EDEE@dsl-only.net> References: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> <163B37B0-55D6-498E-8F52-9A95C036CDFA@dsl-only.net> <08E7A5B0-8707-4479-9D7A-272C427FF643@dsl-only.net> <20170409122715.GF1788@kib.kiev.ua> <9D152170-5F19-47A2-A06A-66F83CA88A09@dsl-only.net> <9DCAF95B-39A5-4346-88FC-6AFDEE8CF9BB@dsl-only.net> To: Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 20:25:20 -0000 [I've not tried building the kernel with your patch yet.] Top post of new, independent information. Jordan Gordeev made a testing suggestion that got me to look at kdumps of runs with jemalloc allocations sizes that fail (14*1024) vs. work (14*1024+1). Example comparison: 2258 swaptesting6 0.000169 CALL = mmap(0,0x200000,0x3,0x1002,0xf= fffffff,0) 2258 swaptesting6 0.000047 RET mmap 1080033280/0x40600000 vs. 2325 swaptesting7 0.000091 CALL = mmap(0,0x200000,0x3,0x1002,0xf= fffffff,0) 2325 swaptesting7 0.000024 RET mmap 1080033280/0x40600000 No difference. And so it goes. What varies is the number of mmap's: the larger jemalloc allocation size gets more mmap's for the same number of jemalloc allocations. (All the mmap's from my program's explicit allocations are together, = back-to-back, with no other traced activity between.) But varying the number of jemalloc allocations in the program varies the = number of mmap calls, yet the size of the individual jemalloc allocations still = makes the difference between failure (zeroed pages after fork-then-swap) and = success. This problem is a complicated one to classify/isolate. After the allocations there is not much activity visible in kdump output. I traced with "-t +" and so avoided page fault tracing but got most everything else. I may have to ktrace the page faults for the two jemalloc allocation sizes and see if anything stands out. On 2017-Apr-9, at 11:24 AM, Mark Millard wrote: > On 2017-Apr-9, at 10:24 AM, Mark Millard = wrote: >=20 >> On 2017-Apr-9, at 5:27 AM, Konstantin Belousov = wrote: >>=20 >>> On Sat, Apr 08, 2017 at 06:02:00PM -0700, Mark Millard wrote: >>>> [I've identified the code path involved is the arm64 small = allocations >>>> turning into zeros for later fork-then-swapout-then-back-in, >>>> specifically the ongoing RES(ident memory) size decrease that >>>> "top -PCwaopid" shows before the fork/swap sequence. Hopefully >>>> I've also exposed enough related information for someone that >>>> knows what they are doing to get started with a specific >>>> investigation, looking for a fix. I'd like for a pine64+ >>>> 2GB to have buildworld complete despite the forking and >>>> swapping involved (yep: for a time zero RES(ident memory) for >>>> some processes involved in the build).] >>>=20 >>> I was not able to follow the walls of text, but do not think that >>> I pmap_ts_reference() is the real culprit there. >>>=20 >>> Is my impression right that the issue occurs on fork, and looks as >>> a memory corruption, where some page suddently becomes zero-filled ? >>> And swapping seems to be involved ? It is somewhat interesting to = see >>> if the problem is reproducable on non-arm64 machines, e.g. armv7 or = amd64. >>=20 >> Yes, yes, non-arm64 that I've tried works. >>=20 >> But I think that the following extra detail my be of use: what top >> shows for RES over time is also odd on arm64 (only) and the amount >> of pages that are zeroed is proportional to the decrease in RES. >>=20 >> In the test sequence: >>=20 >> A) Allocate lots of 14 KiByte allocations and initialize the content = of each >> to non-zero. The example ends up with RES of about 265M. >=20 > I did forget to list one important property: why I picked 14 KiBytes. >=20 > A) Any allocation sizes <=3D 14 KiBytes that I've tried > gets the zero's problem in my arm64 contexts (bpim3 and rip3). >=20 > B) Any allocation size >=3D 14 KiBYtes + 1 Byte that I've > tried works in those contexts. >=20 > For the arm64 contexts that I use this happens to match with > the jemalloc SMALL_MAXCLASS size boundary. When I looked it > appeared that 14 Ki was the smallest SMALL_MAXCLASS value > in jemalloc so it would always fit the category. >=20 >> B) sleep some amount of time, I've been using well over 30 seconds = here. >>=20 >> C) fork >>=20 >> D) sleep again (parent and child), also forcing swapping during the = sleep >> (I used stress, manually run.) >>=20 >> E) Test the memory pattern in the parent and child process, passing = over >> all the bytes, failed and good. >>=20 >> Both the parent and the child in (E) see the first pages allocated as = zero, >> with the number of pages being zero increasing as the sleep time in = (B) >> increases (as long as the sleep is over 30 sec or so). The parent and = child >> match for which pages are zero vs. not. >>=20 >> It fails with (B) being a no-op as well. But the proportionality with >> the time for the sleep is interesting. >>=20 >> During (B) "top -PCwaopid" shows RES decreasing, starting after 30 = sec >> or so. The fork in (C) produces a child that does not have the same = RES >> as the parent but instead a tiny RES (80K as I remember). During (E) >> the child's RES increases to full size. >>=20 >> My powerpc64, armv7, and amd64 tests of such do not fail, nor does = RES >> decrease during (B). The child process gets the same RES as the = parent >> as well, unlike for arm64. >>=20 >> In the failing context (arm64) RES in the parent decreases during (D) >> before the swap-out as well. >>=20 >>> If answers to my two questions are yes, there is probably some bug = with >>> arm64 pmap handling of the dirty bit emulation. ARMv8.0 does not = provide >>> hardware dirty bit, and pmap interprets an accessed writeable page = as >>> unconditionally dirty. More, accessed bit is also not maintained by >>> hardware, instead if should be set by pmap. And arm64 pmap sets the >>> AF bit unconditionally when creating valid pte. >>=20 >> fork-then-swap-out/in is required to see the problem. Neither fork >> by itself nor swapping (zero RES as shown in top) by itself have >> shown the problem so far. >>=20 >>> Hmm, could you try the following patch, I did not even compiled it. >>=20 >> I'll try it later today. >>=20 >>> diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c >>> index 3d5756ba891..55aa402eb1c 100644 >>> --- a/sys/arm64/arm64/pmap.c >>> +++ b/sys/arm64/arm64/pmap.c >>> @@ -2481,6 +2481,11 @@ pmap_protect(pmap_t pmap, vm_offset_t sva, = vm_offset_t eva, vm_prot_t prot) >>> sva +=3D L3_SIZE) { >>> l3 =3D pmap_load(l3p); >>> if (pmap_l3_valid(l3)) { >>> + if ((l3 & ATTR_SW_MANAGED) && >>> + pmap_page_dirty(l3)) { >>> + vm_page_dirty(PHYS_TO_VM_PAGE(l3 = & >>> + ~ATTR_MASK)); >>> + } >>> pmap_set(l3p, ATTR_AP(ATTR_AP_RO)); >>> PTE_SYNC(l3p); >>> /* XXX: Use pmap_invalidate_range */ =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Apr 10 00:10:13 2017 Return-Path: Delivered-To: freebsd-arm@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 A3712D36D84 for ; Mon, 10 Apr 2017 00:10:13 +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 49245AA7 for ; Mon, 10 Apr 2017 00:10:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21417 invoked from network); 10 Apr 2017 00:11:11 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 10 Apr 2017 00:11:11 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sun, 09 Apr 2017 20:10:11 -0400 (EDT) Received: (qmail 24322 invoked from network); 10 Apr 2017 00:10:10 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Apr 2017 00:10:10 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 46C38EC7901; Sun, 9 Apr 2017 17:10:10 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them From: Mark Millard In-Reply-To: <8FFE95AA-DB40-4D1E-A103-4BA9FCC6EDEE@dsl-only.net> Date: Sun, 9 Apr 2017 17:10:09 -0700 Cc: andrew@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <89D6D677-3BE2-45E2-A902-CC6A0305F3F9@dsl-only.net> References: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> <163B37B0-55D6-498E-8F52-9A95C036CDFA@dsl-only.net> <08E7A5B0-8707-4479-9D7A-272C427FF643@dsl-only.net> <20170409122715.GF1788@kib.kiev.ua> <9D152170-5F19-47A2-A06A-66F83CA88A09@dsl-only.net> <9DCAF95B-39A5-4346-88FC-6AFDEE8CF9BB@dsl-only.net> <8FFE95AA-DB40-4D1E-A103-4BA9FCC6EDEE@dsl-only.net> To: Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 00:10:13 -0000 On 2017-Apr-9, at 10:24 AM, Mark Millard wrote: > On 2017-Apr-9, at 5:27 AM, Konstantin Belousov = wrote: >=20 >> Hmm, could you try the following patch, I did not even compiled it. >=20 > I'll try it later today. >=20 >> diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c >> index 3d5756ba891..55aa402eb1c 100644 >> --- a/sys/arm64/arm64/pmap.c >> +++ b/sys/arm64/arm64/pmap.c >> @@ -2481,6 +2481,11 @@ pmap_protect(pmap_t pmap, vm_offset_t sva, = vm_offset_t eva, vm_prot_t prot) >> sva +=3D L3_SIZE) { >> l3 =3D pmap_load(l3p); >> if (pmap_l3_valid(l3)) { >> + if ((l3 & ATTR_SW_MANAGED) && >> + pmap_page_dirty(l3)) { >> + vm_page_dirty(PHYS_TO_VM_PAGE(l3 = & >> + ~ATTR_MASK)); >> + } >> pmap_set(l3p, ATTR_AP(ATTR_AP_RO)); >> PTE_SYNC(l3p); >> /* XXX: Use pmap_invalidate_range */ Preliminary testing indicates that this fixes the some-pages-become-zero problem for fork-then-swapout/in. Thanks! I'll see if a buildworld can go through without being stopped by the type of issue. But that will take a while. (It is how I originally ran into the problem(s) that others had been reporting on the lists.) Side notes: The decreasing-RES(ident memory) behavior was unchanged. The "child gets only 80K RES initially" behavior was also unchanged. (These are as shown by "top -PCwaopid" . These are just differences with what I see for other TARGET_ARCH's.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Apr 10 02:01:53 2017 Return-Path: Delivered-To: freebsd-arm@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 50B2CD32010; Mon, 10 Apr 2017 02:01:53 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 157446E7; Mon, 10 Apr 2017 02:01:53 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: by mail-io0-x22e.google.com with SMTP id l7so79076932ioe.3; Sun, 09 Apr 2017 19:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=z6n7AHYe/CeqWlfBZJM8VcXFSXQNpkIfC+ppK2DMQPo=; b=nXg6GCeXhiclxm7DtE3Y6Vbp6HgKF2WMa6ylfbPHzpi3uz+7fsP0VGz7iZwW/+2M4c B6OlsIym84KwZbSOtXVKYdcWfF+zquLbTzrStecnhDeVh4UG0Y2tUt3YFsMu7aGF61fH ygCS/E1EUxLgWsQFXmRBfYhCR5x8AOjvTGBTWFSDcaJEYNmG1gqTOT12gx/C6bMTrXKF ZUMtrLRMMEPxZ+ZGcrWRibX8LfsaFGP+uGReTHzRhTJJifRgG+HR8jB/oSTLChOqsdfW OwsVLx2Gy0e5DeES1N+43LzSIHTsO5lBZviBAAXxCLOQKo38EPc5Ej1JayOfHOavRSNk yO5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=z6n7AHYe/CeqWlfBZJM8VcXFSXQNpkIfC+ppK2DMQPo=; b=GMt/FUcJb3P0Vv7RGSMLLXK47LZkHqgculVM3w1h6XuhsIUZIElE+iFHv0yY6P3UiS yA8/sxc+iOcSoCYP1TTqqMz79UIBvVpeINhjQWmuERDdQTFhiGLPOiljWT2WWTptubOp r3qaXxK/Hi6lf9z/Twv84CFt/ZfRMYYszi1rKiFbPBA5niG2+ASvA85lFynrOUzn8GjY tOn6c2Mn7GQ51uv0tbsLek9FCY6n3OUekQkS0NbEaE6b3q5t3OMiegSg+zDaPU4U7dZB uQMIQf7bHuh1sWWLZ7NmPRnjtL99MS2jY0cP8ebOo421Uh69uW9vuBfX/7ioKz+zqAqx vdig== X-Gm-Message-State: AN3rC/5Xiet9lwe3Yexe2t4qbzEqeKjWGf4w4ZjDplCRVYnZ0TfWk40K /62Qx34QWrLvvbQEfBp1PuAgZHeQrg== X-Received: by 10.36.36.131 with SMTP id f125mr10145622ita.45.1491789712474; Sun, 09 Apr 2017 19:01:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.15.130 with HTTP; Sun, 9 Apr 2017 19:01:51 -0700 (PDT) Reply-To: alc@freebsd.org In-Reply-To: <89D6D677-3BE2-45E2-A902-CC6A0305F3F9@dsl-only.net> References: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> <163B37B0-55D6-498E-8F52-9A95C036CDFA@dsl-only.net> <08E7A5B0-8707-4479-9D7A-272C427FF643@dsl-only.net> <20170409122715.GF1788@kib.kiev.ua> <9D152170-5F19-47A2-A06A-66F83CA88A09@dsl-only.net> <9DCAF95B-39A5-4346-88FC-6AFDEE8CF9BB@dsl-only.net> <8FFE95AA-DB40-4D1E-A103-4BA9FCC6EDEE@dsl-only.net> <89D6D677-3BE2-45E2-A902-CC6A0305F3F9@dsl-only.net> From: Alan Cox Date: Sun, 9 Apr 2017 21:01:51 -0500 Message-ID: Subject: Re: The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them To: Mark Millard Cc: Konstantin Belousov , andrew@freebsd.org, freebsd-hackers , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 02:01:53 -0000 On Sun, Apr 9, 2017 at 7:10 PM, Mark Millard wrote: > On 2017-Apr-9, at 10:24 AM, Mark Millard wrote: > > > On 2017-Apr-9, at 5:27 AM, Konstantin Belousov > wrote: > > > > >> Hmm, could you try the following patch, I did not even compiled it. > > > > I'll try it later today. > > > >> diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c > >> index 3d5756ba891..55aa402eb1c 100644 > >> --- a/sys/arm64/arm64/pmap.c > >> +++ b/sys/arm64/arm64/pmap.c > >> @@ -2481,6 +2481,11 @@ pmap_protect(pmap_t pmap, vm_offset_t sva, > vm_offset_t eva, vm_prot_t prot) > >> sva += L3_SIZE) { > >> l3 = pmap_load(l3p); > >> if (pmap_l3_valid(l3)) { > >> + if ((l3 & ATTR_SW_MANAGED) && > >> + pmap_page_dirty(l3)) { > >> + vm_page_dirty(PHYS_TO_VM_PAGE(l3 & > >> + ~ATTR_MASK)); > >> + } > >> pmap_set(l3p, ATTR_AP(ATTR_AP_RO)); > >> PTE_SYNC(l3p); > >> /* XXX: Use pmap_invalidate_range */ > > > Preliminary testing indicates that this fixes the > some-pages-become-zero problem for fork-then-swapout/in. > > Thanks! > > I'll see if a buildworld can go through without being stopped > by the type of issue. But that will take a while. (It is how > I originally ran into the problem(s) that others had been > reporting on the lists.) > > > Side notes: > > The decreasing-RES(ident memory) behavior was unchanged. > > The "child gets only 80K RES initially" behavior was also > unchanged. > > That is because the arm64 pmap doesn't implement pmap_copy(). > (These are as shown by "top -PCwaopid" . These are just > differences with what I see for other TARGET_ARCH's.) > > === > Mark Millard > markmi at dsl-only.net > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Mon Apr 10 09:51:49 2017 Return-Path: Delivered-To: freebsd-arm@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 0BEC4D34101 for ; Mon, 10 Apr 2017 09:51:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-6.reflexion.net [208.70.210.6]) (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 ABA7DC98 for ; Mon, 10 Apr 2017 09:51:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32594 invoked from network); 10 Apr 2017 09:54:36 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 10 Apr 2017 09:54:36 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 10 Apr 2017 05:51:41 -0400 (EDT) Received: (qmail 29193 invoked from network); 10 Apr 2017 09:51:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Apr 2017 09:51:41 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 85F66EC8630; Mon, 10 Apr 2017 02:51:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them From: Mark Millard In-Reply-To: <89D6D677-3BE2-45E2-A902-CC6A0305F3F9@dsl-only.net> Date: Mon, 10 Apr 2017 02:51:39 -0700 Cc: andrew@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <585B43F7-D4C8-431A-BFFE-68B48C3214AE@dsl-only.net> References: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> <163B37B0-55D6-498E-8F52-9A95C036CDFA@dsl-only.net> <08E7A5B0-8707-4479-9D7A-272C427FF643@dsl-only.net> <20170409122715.GF1788@kib.kiev.ua> <9D152170-5F19-47A2-A06A-66F83CA88A09@dsl-only.net> <9DCAF95B-39A5-4346-88FC-6AFDEE8CF9BB@dsl-only.net> <8FFE95AA-DB40-4D1E-A103-4BA9FCC6EDEE@dsl-only.net> <89D6D677-3BE2-45E2-A902-CC6A0305F3F9@dsl-only.net> To: Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 09:51:49 -0000 On 2017-Apr-9, at 5:10 PM, Mark Millard wrote: > On 2017-Apr-9, at 10:24 AM, Mark Millard = wrote: >=20 >> On 2017-Apr-9, at 5:27 AM, Konstantin Belousov = wrote: >=20 >>=20 >>> Hmm, could you try the following patch, I did not even compiled it. >>=20 >> I'll try it later today. >>=20 >>> diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c >>> index 3d5756ba891..55aa402eb1c 100644 >>> --- a/sys/arm64/arm64/pmap.c >>> +++ b/sys/arm64/arm64/pmap.c >>> @@ -2481,6 +2481,11 @@ pmap_protect(pmap_t pmap, vm_offset_t sva, = vm_offset_t eva, vm_prot_t prot) >>> sva +=3D L3_SIZE) { >>> l3 =3D pmap_load(l3p); >>> if (pmap_l3_valid(l3)) { >>> + if ((l3 & ATTR_SW_MANAGED) && >>> + pmap_page_dirty(l3)) { >>> + vm_page_dirty(PHYS_TO_VM_PAGE(l3 = & >>> + ~ATTR_MASK)); >>> + } >>> pmap_set(l3p, ATTR_AP(ATTR_AP_RO)); >>> PTE_SYNC(l3p); >>> /* XXX: Use pmap_invalidate_range */ >=20 >=20 > Preliminary testing indicates that this fixes the > some-pages-become-zero problem for fork-then-swapout/in. >=20 > Thanks! >=20 > I'll see if a buildworld can go through without being stopped > by the type of issue. But that will take a while. (It is how > I originally ran into the problem(s) that others had been > reporting on the lists.) buildworld buildkernel completed non-stop for the first time on a BPI-M3 board. Looks good for a check-in to svn to me (head and stable/11). This combined with 2017-Feb-15's -r313772's fix to the fork trampline code's updating of sp_el0 makes arm64 far more stable for my purposes. -r313772 was never MFC'd to stable/11. In my view it should be. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Apr 10 10:11:36 2017 Return-Path: Delivered-To: freebsd-arm@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 47A60D3480B for ; Mon, 10 Apr 2017 10:11:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 3620B8FC for ; Mon, 10 Apr 2017 10:11:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3AABZeb000791 for ; Mon, 10 Apr 2017 10:11:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 217239] head (e.g.:) -r315870 arm64 vs. jemalloc without MALLOC_PRODUCTION: various examples of tbin->avail being zero lead to SIGSEGV's Date: Mon, 10 Apr 2017 10:11:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: Closed X-Bugzilla-Resolution: DUPLICATE X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 10:11:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217239 Mark Millard changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|New |Closed --- Comment #34 from Mark Millard --- The same for this (217239) also fixes bugzilla 217138 so I'm marking this as a duplicate. *** This bug has been marked as a duplicate of bug 217138 *** --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Apr 10 15:24:11 2017 Return-Path: Delivered-To: freebsd-arm@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 56295D37920 for ; Mon, 10 Apr 2017 15:24:11 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 116739BC for ; Mon, 10 Apr 2017 15:24:11 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-qk0-x22a.google.com with SMTP id h67so116088407qke.0 for ; Mon, 10 Apr 2017 08:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=JKg3Bz/EoLLC1IXT08wnjqUmdpKqHO5+H46KZ89ZXlE=; b=gp6Vg/vbwdQxeISFjCogGP6zWGNg3QjJfXkdU8z8RuMJkWxPsVwYjsOunWHvYd+xBr CwzsfFXyVpsmBzkCBOpFK/RvnTrD59VMvUd2dLJrmge2vWz4b2ynlXadOtfFVFMmq/Ag oRfh+o3S/IHHUZKVgjNnRqKiSPhyrZ8Y3xcbl8VxJaTzp1YX+Jmk9v6shupktE63wKTu gCto1HnQP6V0InWda7cQ6UtNXxdP2sxkQTfwyyToi/hU07Zo+H3yL15j09BJNwRU6lhE pYlS1ik8mQx7+xs+x3Tw43Jj03gcSCYqI5R/tPgxShPVi8JKOGyf7PoP8kl8oihJaIOD k9ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=JKg3Bz/EoLLC1IXT08wnjqUmdpKqHO5+H46KZ89ZXlE=; b=jsE6sRSb6g6gqKFZLkCvdA6+OM4M8toYkEC3wW58nLb9gXRxUr5EslqChsvBoDeqAx Xd0SSsisspGUE0w7cOtu4t3x8G4nYPKUcJDF4U2B2H1cMNXWVMs+4/rOWJnFah60R3iV xAqsWngApVlztEKu0UYkUO4ZXcgtHu1vXjuv9xUaviayDcxnPFOU0iqfZP0wsf6Va+/S 4efjQRmQmDKabZeozBozDN5+0Iu8ZPFWDM0Z2ax/E7XwWAzCxLOXLHRfLTYGYKR6c2dX 1T2l8al2C2/GwaH10VudEE81rKYGbbtSKYfZ9Cw6F5Pv1XlezMIyA8ee5oR5rsCJLxbu 7drw== X-Gm-Message-State: AFeK/H2+KsAoRWpuBQyg5wrrJ+VxyfQ0rztSMLhFN9wYzizE97Yekhcp7lzMEbK2mvXXltDGVU+KYe06U4LgYw== X-Received: by 10.13.251.67 with SMTP id l64mr36230032ywf.36.1491837850040; Mon, 10 Apr 2017 08:24:10 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.20.214 with HTTP; Mon, 10 Apr 2017 08:24:09 -0700 (PDT) In-Reply-To: References: From: Alan Somers Date: Mon, 10 Apr 2017 09:24:09 -0600 X-Google-Sender-Auth: 6QrXMWGT2HTi-s5-KGuQsA9yjSE Message-ID: Subject: Re: OT: 96-core 1U ARM server To: Jim Thompson Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 15:24:11 -0000 No need, Jim. This is just idle curiosity, not serious interest. Thanks for letting me know who makes it, though. On Fri, Apr 7, 2017 at 11:35 AM, Jim Thompson wrote: > > ThunderX, best application right now is "scale out" web loads. > They start at a single socket for under $3,000 > http://www.nextwarehouse.com/item/?2465022_g10e > > You could try to buy it directly from Gigabyte: > http://b2b.gigabyte.com/Rack-Server/ARM-SoC > > If you can't get inside, lmk, and I'll put you in touch with our mfg rep for > them. > > Jim > > > On Fri, Apr 7, 2017 at 12:26 PM, Alan Somers wrote: >> >> System76 is selling a 1U server with 96 Cavium ARMv8 cores and builtin >> 40GbE. It starts at about $6,000, which isn't bad for something this >> unusual. Does anybody have any idea what kinds of applications would >> be good for a system like this? Do any of those applications involve >> FreeBSD? >> >> https://system76.com/servers/starling >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > From owner-freebsd-arm@freebsd.org Mon Apr 10 18:58:23 2017 Return-Path: Delivered-To: freebsd-arm@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 6DC12D37EF9 for ; Mon, 10 Apr 2017 18:58:23 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37B87BF3 for ; Mon, 10 Apr 2017 18:58:22 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cxeW4-00051h-AU for freebsd-arm@freebsd.org; Mon, 10 Apr 2017 20:58:20 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: top shows more than 100% of CPU usage References: <20170407142818.GJ59737@e-new.0x20.net> <984dd842-5673-3a13-ce53-db27465bc39b@bsd.com.br> Date: Mon, 10 Apr 2017 20:58:19 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Ronald Klop" Message-ID: In-Reply-To: <984dd842-5673-3a13-ce53-db27465bc39b@bsd.com.br> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 9090f8a1960d7f777b94d17b6f36e747 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 18:58:23 -0000 On Fri, 07 Apr 2017 16:30:37 +0200, Otac=C3=ADlio = wrote: > Em 07/04/2017 11:28, Lars Engels escreveu: >> On Fri, Apr 07, 2017 at 11:25:22AM -0300, Otac=C3=ADlio wrote: >>> Dears >>> >>> Why top on arm sometimes shows more than 100% of CPU usage? >>> >> That's because 100% means 100% utilization for one CPU / CPU core. >> If you have 4 cores, then utilization can go up to 400%. > > But I'm getting these results in a beaglebone and as far as I know it = = > only has one core. My arm/SHEEVAPLUG also gives 100+% now and then. Don't know why. Ronald. > > > regards > > -Otacilio > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"= From owner-freebsd-arm@freebsd.org Mon Apr 10 20:19:58 2017 Return-Path: Delivered-To: freebsd-arm@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 E44D3D388D5 for ; Mon, 10 Apr 2017 20:19:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-12.reflexion.net [208.70.210.12]) (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 7FD0E6C0 for ; Mon, 10 Apr 2017 20:19:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14937 invoked from network); 10 Apr 2017 20:19:56 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 10 Apr 2017 20:19:56 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 10 Apr 2017 16:19:56 -0400 (EDT) Received: (qmail 14458 invoked from network); 10 Apr 2017 20:19:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Apr 2017 20:19:56 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id AF968EC8FBA; Mon, 10 Apr 2017 13:19:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Is a83t development still active? (My context: BPI-M3) From: Mark Millard In-Reply-To: Date: Mon, 10 Apr 2017 13:19:55 -0700 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <9ABA1C78-1568-4362-BDD8-EA906C167DD6@dsl-only.net> References: <20170114143326.5c99aeee0283d86fec722412@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 20:19:59 -0000 On 2017-Jan-14, at 5:33 AM, Emmanuel Vadot wrote: > On Fri, 13 Jan 2017 14:40:26 -0800 > Mark Millard wrote: > >> I notice looking in: >> >> https://svnweb.freebsd.org/base/head/sys/arm/allwinner/ >> >> that, while a10, a13/, a20/, a31/, a33/, a64/, and h3/ have been >> getting updates, a83t/ has not had one since 2016-Oct-3 >> (306646) --and that was only to remove std.* files. The only >> other vintage of a83t/ goes back to 2016-May-5 (299113). >> >> Is a83t no longer being updated? >> >> === >> Mark Millard >> markmi at dsl-only.net >> > . . . > But I admit that when I've added information on the pin interrupts I > forgot to do a83t, I'll do that soon. Did this get taken care of? === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Apr 10 20:22:39 2017 Return-Path: Delivered-To: freebsd-arm@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 6245CD38AF6 for ; Mon, 10 Apr 2017 20:22:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-11.reflexion.net [208.70.210.11]) (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 123D6B09 for ; Mon, 10 Apr 2017 20:22:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13018 invoked from network); 10 Apr 2017 20:18:53 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 10 Apr 2017 20:18:53 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 10 Apr 2017 16:15:58 -0400 (EDT) Received: (qmail 31433 invoked from network); 10 Apr 2017 20:15:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Apr 2017 20:15:58 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 96DBBEC7C08; Mon, 10 Apr 2017 13:15:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them From: Mark Millard In-Reply-To: <585B43F7-D4C8-431A-BFFE-68B48C3214AE@dsl-only.net> Date: Mon, 10 Apr 2017 13:15:57 -0700 Cc: andrew@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <876EA1E4-E5A9-411C-AFFD-989713037C19@dsl-only.net> References: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> <163B37B0-55D6-498E-8F52-9A95C036CDFA@dsl-only.net> <08E7A5B0-8707-4479-9D7A-272C427FF643@dsl-only.net> <20170409122715.GF1788@kib.kiev.ua> <9D152170-5F19-47A2-A06A-66F83CA88A09@dsl-only.net> <9DCAF95B-39A5-4346-88FC-6AFDEE8CF9BB@dsl-only.net> <8FFE95AA-DB40-4D1E-A103-4BA9FCC6EDEE@dsl-only.net> <89D6D677-3BE2-45E2-A902-CC6A0305F3F9@dsl-only.net> <585B43F7-D4C8-431A-BFFE-68B48C3214AE@dsl-only.net> To: Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 20:22:39 -0000 On 2017-Apr-10, at 2:51 AM, Mark Millard wrote: > On 2017-Apr-9, at 5:10 PM, Mark Millard = wrote: >=20 >> On 2017-Apr-9, at 10:24 AM, Mark Millard = wrote: >>=20 >>> On 2017-Apr-9, at 5:27 AM, Konstantin Belousov = wrote: >>=20 >>>=20 >>>> Hmm, could you try the following patch, I did not even compiled it. >>>=20 >>> I'll try it later today. >>>=20 >>>> diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c >>>> index 3d5756ba891..55aa402eb1c 100644 >>>> --- a/sys/arm64/arm64/pmap.c >>>> +++ b/sys/arm64/arm64/pmap.c >>>> @@ -2481,6 +2481,11 @@ pmap_protect(pmap_t pmap, vm_offset_t sva, = vm_offset_t eva, vm_prot_t prot) >>>> sva +=3D L3_SIZE) { >>>> l3 =3D pmap_load(l3p); >>>> if (pmap_l3_valid(l3)) { >>>> + if ((l3 & ATTR_SW_MANAGED) && >>>> + pmap_page_dirty(l3)) { >>>> + vm_page_dirty(PHYS_TO_VM_PAGE(l3 = & >>>> + ~ATTR_MASK)); >>>> + } >>>> pmap_set(l3p, ATTR_AP(ATTR_AP_RO)); >>>> PTE_SYNC(l3p); >>>> /* XXX: Use pmap_invalidate_range */ >>=20 >>=20 >> Preliminary testing indicates that this fixes the >> some-pages-become-zero problem for fork-then-swapout/in. >>=20 >> Thanks! >>=20 >> I'll see if a buildworld can go through without being stopped >> by the type of issue. But that will take a while. (It is how >> I originally ran into the problem(s) that others had been >> reporting on the lists.) >=20 > buildworld buildkernel completed non-stop for the first time > on a BPI-M3 board. I had been thinking of the BPI-M3 for other reasons and typed that instead of the correct: Pine64+ 2GB. (True elsewhere as well.) I do really mean arm64 here, not armv7. > Looks good for a check-in to svn to me (head and stable/11). >=20 > This combined with 2017-Feb-15's -r313772's fix to the fork > trampline code's updating of sp_el0 makes arm64 far more stable > for my purposes. >=20 > -r313772 was never MFC'd to stable/11. In my view it should be. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Apr 12 00:55:47 2017 Return-Path: Delivered-To: freebsd-arm@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 88770D37598 for ; Wed, 12 Apr 2017 00:55:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 206DC27F for ; Wed, 12 Apr 2017 00:55:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wr0-x231.google.com with SMTP id c55so7769312wrc.3 for ; Tue, 11 Apr 2017 17:55:47 -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=CxFrgsGEII+R0Tti3zKo9lizDlR2JTjWq+AfGYoCKto=; b=eutrinoI6ssL/y/4GAyPBqOs/+w76w22Yudp1tLHGpJUrLG1E31TsQ2svgbKws348D d5O4Ogao9KawiNk1krcpY9b2iK+DpRNDQY3zyFJauwzneQwX1Nm0WWqDijDF+8oYGgZF V2Hak4v4r2OeH4FO9EKTUXqGD+5V651nz1K3+m+I/8aV2Agbq4YcoFImm6Tk7AxQ0Ftw X1dbjZaIDBfbTqp025224G0NrTqN6+Oq/7ZSuFvyGCykMECRWkI6+pmN77WG+xP93yKI 1MoINExQD9hroRIaK+1IiD8Esv7cpTfoxF7mqYbXAi3QhKyUsVKH0RrJcCPjDIQm4fjh crKA== 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=CxFrgsGEII+R0Tti3zKo9lizDlR2JTjWq+AfGYoCKto=; b=VKlptDj6EQcrEhJks3d5TRm9xqFLd0RopEBKb4XHJ08Eb1e5h7sDao4gz3NmWw1/Yy rQlCnigscDkDJQygRlLh9PfUDFgZlgM1iMEC87kyD307tFpBEjQ4GtOb/PIHrA345L+4 4ribKm9ARJACR4y5qv7N/tNMquGpNhC+FLr6FYwfXj7ankJJHLbhS1XAGKX+Z/bWE9hb Nx6Xez53EqBpGYtGn6MfMcTTxj0rKm/uDNh1XJdAyqJj8vsYv6q784Pq/9bySBu6iwfd /w/SSCsPMpGQ1QOjdkNyAEx+JmI78noDti3Nzsp7u2Iju/gHNIyNnIqzgJNiYzOlDfBO dCvw== X-Gm-Message-State: AN3rC/6iVz3QmiciIK2XylL9o4o0yA0XvpqAaHdiU7kiyk9ndPw90kK5BZQ1TvCcq7lML2OHHqf/NL+57kwzUg== X-Received: by 10.223.130.150 with SMTP id 22mr347014wrc.89.1491958544337; Tue, 11 Apr 2017 17:55:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.185.66 with HTTP; Tue, 11 Apr 2017 17:55:43 -0700 (PDT) In-Reply-To: <622336.93399.qm@web101714.mail.ssk.yahoo.co.jp> References: <622336.93399.qm@web101714.mail.ssk.yahoo.co.jp> From: Adrian Chadd Date: Tue, 11 Apr 2017 17:55:43 -0700 Message-ID: Subject: Re: Can't use mge on 88F5181 To: Mori Hiroki Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 00:55:47 -0000 hiya, did you figure it out? Is there something like CRC, etc packet errors or something on RX? -adrian On 4 April 2017 at 04:42, Mori Hiroki wrote: > Hi. > > I try to use Buffalo WZR-AMPG300NH. This module have 88F5181 and 88E6131. > I modify dev/mge and dev/etherswitch/e600sw/e6000sw.c. > > Network interface mge is detect but not work. Switch port is work by > port vlan. But CPU connected port3 is nothing trans and receive packet. > > I check marvell code but not fix this problem. > > If you have advice, please let me know. > > > This is dmesg. > > https://gist.github.com/yamori813/ecd5df1b314053a73f310c1122775540 > > > Thanks. > > Hiroki Mori > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Apr 12 18:25:44 2017 Return-Path: Delivered-To: freebsd-arm@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 0C337D3BD81; Wed, 12 Apr 2017 18:25:44 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB20229; Wed, 12 Apr 2017 18:25:43 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cyMxS-0004DC-G0; Wed, 12 Apr 2017 20:25:35 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-arm@freebsd.org, "freebsd-fs@freebsd.org" Subject: Re: newfs_nandfs compile error 11-STABLE References: Date: Wed, 12 Apr 2017 20:25:33 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: d40e2d9e04d28df092fb73f3743f8c9c X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 18:25:44 -0000 On Wed, 05 Apr 2017 12:46:01 +0200, Ronald Klop wrote: > Hi, > > I'm building 11-STABLE for SHEEVAPLUG on a 12-CURRENT/amd64. > I get this compile error. > How can I resolve this without a clean build? I would like to prevent > recompiling llvm for 12 hours. > > --- newfs_nandfs.o --- > cc -O -pipe -g -MD -MF.depend.newfs_nandfs.o -MTnewfs_nandfs.o > -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch > -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline > -Wnested-externs -Wredundant-decls -Wold-style-definition > -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety > -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable > -Qunused-arguments -c /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c -o > newfs_nandfs.o > /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking > address of packed member 'f_uuid' of class or structure 'nandfs_fsdata' > may result in an unaligned pointer value > [-Werror,-Waddress-of-packed-member] > uuidgen(&fsdata.f_uuid, 1); > ^~~~~~~~~~~~~ > 1 error generated. > *** [newfs_nandfs.o] Error code 1 > > make[4]: stopped in /usr/src-arm/sbin/newfs_nandfs > 1 error > > make[4]: stopped in /usr/src-arm/sbin/newfs_nandfs > *** [all_subdir_sbin/newfs_nandfs] Error code 2 > > > Do I have to clean and rebuild some specific library? > Or something else? > > Regards, > Ronald. I cleaned, did rm -r /usr/obj-arm/*, waited for half a day compiling llvm and got the same error. This is while compiling 11-STABLE/arm on 12-CURRENT/amd64. ===> sbin/newfs_nandfs (all) echo newfs_nandfs.full: /usr/obj-arm/arm.arm/usr/src-arm/tmp/usr/lib/libc.a /usr /obj-arm/arm.arm/usr/src-arm/tmp/usr/lib/libgeom.a >> .depend cc -O -pipe -g -MD -MF.depend.newfs_nandfs.o -MTnewfs_nandfs.o -std=gnu99 -W system-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-p rototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite -strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wi nline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sig n -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-pl us-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src-arm/sbin/newf s_nandfs/newfs_nandfs.c -o newfs_nandfs.o /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking address of p acked member 'f_uuid' of class or structure 'nandfs_fsdata' may result in an una ligned pointer value [-Werror,-Waddress-of-packed-member] uuidgen(&fsdata.f_uuid, 1); ^~~~~~~~~~~~~ 1 error generated. *** Error code 1 Any ideas? Ronald. From owner-freebsd-arm@freebsd.org Wed Apr 12 18:32:14 2017 Return-Path: Delivered-To: freebsd-arm@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 578E6D3B324 for ; Wed, 12 Apr 2017 18:32:14 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 1A029B6E for ; Wed, 12 Apr 2017 18:32:13 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qk0-x22f.google.com with SMTP id f133so30643549qke.2 for ; Wed, 12 Apr 2017 11:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=dwFrYbCHNeRJJtrNud0IpC3qa+rN345by62GhwAIE7A=; b=aqU6fmoLuTB/fUXcQTaY/EugYCIHitS6+kR3feKFt4ZXGsfVav1fNFgsj7A0mvnPMq ZZIggKjRpm+BudGw5tfcm6vgTAvuCkMc7Iy0KZQ+bhDQM1RNHHmfMPv2YyisA5S+XNxb Qi8XLY/E3Yh4LLVghBfy1n6X4m9JG/DC+41xY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=dwFrYbCHNeRJJtrNud0IpC3qa+rN345by62GhwAIE7A=; b=JpXPDlv7POidNa+B4+98/sKGtZWiNX44eppWPBeAKuzQhaG/rjJr/xg0IQ7gP9PqxZ pctORzuSejr85wsoQBNSc5dx064qFL3diRCnLQBeH700T261qVG8yPg0UY1t6OXqwxJH EYw/2J4KiAC9C5wkF2KXDYVfIbcWsM0wfq7NwidosO7Je8O+66Yf5eo1vkZqve4IJip+ IcYZx6b+QQon7JCCqGaqZ+gZjuvMuNpKL2YCTMFKhDaPFYgTSi1EKiDlq18dekgBwsmE DdIMVccwR2twgLguDdegOeznkBBc3VN9hu75UjPONvfeGTQg5skaQyWg1HVMCm/gOZaW 9pfg== X-Gm-Message-State: AFeK/H172cbFdi7+3RCWXL/AZTDLGOJk1fIqV9JjepIPPlYk260puMvGbRXZ+yoXytGDIg== X-Received: by 10.55.203.155 with SMTP id u27mr54770850qkl.54.1492021932719; Wed, 12 Apr 2017 11:32:12 -0700 (PDT) Received: from [192.168.43.219] (179-240-180-30.3g.claro.net.br. [179.240.180.30]) by smtp.googlemail.com with ESMTPSA id f56sm13985296qta.14.2017.04.12.11.32.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 11:32:12 -0700 (PDT) Subject: Re: newfs_nandfs compile error 11-STABLE To: freebsd-arm@freebsd.org References: From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: <87a7b063-f464-192f-8df4-a9cb1a3adeb4@bsd.com.br> Date: Wed, 12 Apr 2017 15:31:52 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 18:32:14 -0000 Em 12/04/2017 15:25, Ronald Klop escreveu: > On Wed, 05 Apr 2017 12:46:01 +0200, Ronald Klop > wrote: > >> Hi, >> >> I'm building 11-STABLE for SHEEVAPLUG on a 12-CURRENT/amd64. >> I get this compile error. >> How can I resolve this without a clean build? I would like to prevent >> recompiling llvm for 12 hours. >> >> --- newfs_nandfs.o --- >> cc -O -pipe -g -MD -MF.depend.newfs_nandfs.o -MTnewfs_nandfs.o >> -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W >> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch >> -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline >> -Wnested-externs -Wredundant-decls -Wold-style-definition >> -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety >> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable >> -Qunused-arguments -c /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c >> -o newfs_nandfs.o >> /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking >> address of packed member 'f_uuid' of class or structure >> 'nandfs_fsdata' may result in an unaligned pointer value >> [-Werror,-Waddress-of-packed-member] >> uuidgen(&fsdata.f_uuid, 1); >> ^~~~~~~~~~~~~ >> 1 error generated. >> *** [newfs_nandfs.o] Error code 1 >> >> make[4]: stopped in /usr/src-arm/sbin/newfs_nandfs >> 1 error >> >> make[4]: stopped in /usr/src-arm/sbin/newfs_nandfs >> *** [all_subdir_sbin/newfs_nandfs] Error code 2 >> >> >> Do I have to clean and rebuild some specific library? >> Or something else? >> >> Regards, >> Ronald. > > I cleaned, did rm -r /usr/obj-arm/*, waited for half a day compiling > llvm and got the same error. > This is while compiling 11-STABLE/arm on 12-CURRENT/amd64. > > ===> sbin/newfs_nandfs (all) > echo newfs_nandfs.full: > /usr/obj-arm/arm.arm/usr/src-arm/tmp/usr/lib/libc.a /usr > /obj-arm/arm.arm/usr/src-arm/tmp/usr/lib/libgeom.a >> .depend > cc -O -pipe -g -MD -MF.depend.newfs_nandfs.o -MTnewfs_nandfs.o > -std=gnu99 -W > system-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wstrict-p > rototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type > -Wcast-qual -Wwrite > -strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align > -Wchar-subscripts -Wi > nline -Wnested-externs -Wredundant-decls -Wold-style-definition > -Wno-pointer-sig > n -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body > -Wno-string-pl > us-int -Wno-unused-const-variable -Qunused-arguments -c > /usr/src-arm/sbin/newf > s_nandfs/newfs_nandfs.c -o newfs_nandfs.o > /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking > address of p > acked member 'f_uuid' of class or structure 'nandfs_fsdata' may result > in an una > ligned pointer value [-Werror,-Waddress-of-packed-member] > uuidgen(&fsdata.f_uuid, 1); > ^~~~~~~~~~~~~ > 1 error generated. > *** Error code 1 > > > Any ideas? > > Ronald. What is the revision of HEAD that you are using? I did a full buildworld/buildkernel using a beaglebone black with HEAD revision 316378 (It took 3,5 days to finish.). []'s -Otacilio From owner-freebsd-arm@freebsd.org Wed Apr 12 18:37:23 2017 Return-Path: Delivered-To: freebsd-arm@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 AF2ADD3B506 for ; Wed, 12 Apr 2017 18:37:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 7D0B7E16 for ; Wed, 12 Apr 2017 18:37:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x234.google.com with SMTP id r16so50737523ioi.2 for ; Wed, 12 Apr 2017 11:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=owmRW5VUpCYi8w5MhRWm10N6tXfxwHh/3oQxqhKbVO0=; b=yCsbId/NkpGBe17U+b/Dk4JatDz+jeVEIrLej/nahSGraiaS91B7J8oggfaxvtGyX2 0yyqIpy0kpeIhR7Vu0b0LRPBqxdmmXhtAGMkq4U9OR98AMMniDvvghJbNcfQQI6uXs+k 7rG7m6vNoBtQ5hFVXL612SfxqWYxQoUXsCO5nAvzN1WxBL2R/RlkpQNubotb+kbBKOvA wVCynIKckDHOP4gxWKVTOHz6E5ZGlKcxJ2feP3e+6BPHPcQzsydUa8Ere8n49FIGegR4 yieRls2g6CKXNgzn2fMGVc0xeTj2E1CTBpbcrc8xX+oAwFam2iX5WDXbg9IZsddngCr5 VnKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=owmRW5VUpCYi8w5MhRWm10N6tXfxwHh/3oQxqhKbVO0=; b=Gmj3+/9JnjXIOXNq65jHAqka8u4gR8d/LMPkx0+V0428lOHks477yvuO9ROD3z0fjU wA4dFPqy5wKmpd7zE9OE7FrZ1Mc/arxBJ5Aso02TZ9uk1lSvuS4PxJ2MDeoqEYcKpmLB /iPllcc5eC/J8Tb1h0ff0covGKfRLBjouxpG4vjRKqatIpbnopuPX8kHXLjTN3Y6hARn S6LVvW8bay2YsDyReLWjZA+q/AZv/oj/Z7Aget/o9CRZN5OmPXtBlwGoNllwfn+b4Zug 1YlT+x6k7XXKOiplwFJ+7maOPFX/tTcq/6YfkFOWCV3SpUJ/VlmsUHj6fITZ4UkVE1FM yzPg== X-Gm-Message-State: AN3rC/7sz7KjE/pVKUYALr2hHNqsuf/jTNd8ChI1kIO/QcY9RANLLHbw hqRKNU9vQ+es8MyMj8bxI7XbgIF4Kg== X-Received: by 10.36.199.197 with SMTP id t188mr24143047itg.85.1492022242650; Wed, 12 Apr 2017 11:37:22 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.146.24 with HTTP; Wed, 12 Apr 2017 11:37:22 -0700 (PDT) X-Originating-IP: [2607:fb10:7021:1::d0fc] In-Reply-To: <87a7b063-f464-192f-8df4-a9cb1a3adeb4@bsd.com.br> References: <87a7b063-f464-192f-8df4-a9cb1a3adeb4@bsd.com.br> From: Warner Losh Date: Wed, 12 Apr 2017 12:37:22 -0600 X-Google-Sender-Auth: rBhMHbDjTMvybZwqtsw3_P9fmaI Message-ID: Subject: Re: newfs_nandfs compile error 11-STABLE To: =?UTF-8?B?T3RhY8OtbGlv?= Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 18:37:23 -0000 Try building WITHOUT_NAND rather than WITH_NAND. nandfs is super broken wrt to VFS locking and is data corruption waiting to happen. Warner On Wed, Apr 12, 2017 at 12:31 PM, Otac=C3=ADlio = wrote: > Em 12/04/2017 15:25, Ronald Klop escreveu: >> >> On Wed, 05 Apr 2017 12:46:01 +0200, Ronald Klop >> wrote: >> >>> Hi, >>> >>> I'm building 11-STABLE for SHEEVAPLUG on a 12-CURRENT/amd64. >>> I get this compile error. >>> How can I resolve this without a clean build? I would like to prevent >>> recompiling llvm for 12 hours. >>> >>> --- newfs_nandfs.o --- >>> cc -O -pipe -g -MD -MF.depend.newfs_nandfs.o -MTnewfs_nandfs.o >>> -std=3Dgnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W >>> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes >>> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wsh= adow >>> -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-ext= erns >>> -Wredundant-decls -Wold-style-definition -Wno-pointer-sign >>> -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body >>> -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c >>> /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c -o newfs_nandfs.o >>> /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking >>> address of packed member 'f_uuid' of class or structure 'nandfs_fsdata'= may >>> result in an unaligned pointer value [-Werror,-Waddress-of-packed-membe= r] >>> uuidgen(&fsdata.f_uuid, 1); >>> ^~~~~~~~~~~~~ >>> 1 error generated. >>> *** [newfs_nandfs.o] Error code 1 >>> >>> make[4]: stopped in /usr/src-arm/sbin/newfs_nandfs >>> 1 error >>> >>> make[4]: stopped in /usr/src-arm/sbin/newfs_nandfs >>> *** [all_subdir_sbin/newfs_nandfs] Error code 2 >>> >>> >>> Do I have to clean and rebuild some specific library? >>> Or something else? >>> >>> Regards, >>> Ronald. >> >> >> I cleaned, did rm -r /usr/obj-arm/*, waited for half a day compiling llv= m >> and got the same error. >> This is while compiling 11-STABLE/arm on 12-CURRENT/amd64. >> >> =3D=3D=3D> sbin/newfs_nandfs (all) >> echo newfs_nandfs.full: >> /usr/obj-arm/arm.arm/usr/src-arm/tmp/usr/lib/libc.a /usr >> /obj-arm/arm.arm/usr/src-arm/tmp/usr/lib/libgeom.a >> .depend >> cc -O -pipe -g -MD -MF.depend.newfs_nandfs.o -MTnewfs_nandfs.o >> -std=3Dgnu99 -W >> system-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter >> -Wstrict-p >> rototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual >> -Wwrite >> -strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align >> -Wchar-subscripts -Wi >> nline -Wnested-externs -Wredundant-decls -Wold-style-definition >> -Wno-pointer-sig >> n -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body >> -Wno-string-pl >> us-int -Wno-unused-const-variable -Qunused-arguments -c >> /usr/src-arm/sbin/newf >> s_nandfs/newfs_nandfs.c -o newfs_nandfs.o >> /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking >> address of p >> acked member 'f_uuid' of class or structure 'nandfs_fsdata' may result i= n >> an una >> ligned pointer value [-Werror,-Waddress-of-packed-member] >> uuidgen(&fsdata.f_uuid, 1); >> ^~~~~~~~~~~~~ >> 1 error generated. >> *** Error code 1 >> >> >> Any ideas? >> >> Ronald. > > > What is the revision of HEAD that you are using? I did a full > buildworld/buildkernel using a beaglebone black with HEAD revision 316378 > (It took 3,5 days to finish.). > > []'s > -Otacilio > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Wed Apr 12 18:51:49 2017 Return-Path: Delivered-To: freebsd-arm@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 47814D3B909 for ; Wed, 12 Apr 2017 18:51:49 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 124F47C2 for ; Wed, 12 Apr 2017 18:51:48 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cyNMo-0001dE-2p for freebsd-arm@freebsd.org; Wed, 12 Apr 2017 20:51:46 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: newfs_nandfs compile error 11-STABLE References: <87a7b063-f464-192f-8df4-a9cb1a3adeb4@bsd.com.br> Date: Wed, 12 Apr 2017 20:51:45 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Ronald Klop" Message-ID: In-Reply-To: <87a7b063-f464-192f-8df4-a9cb1a3adeb4@bsd.com.br> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: fe741e38e2a2daf11bd87aa0c4b7285b X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 18:51:49 -0000 On Wed, 12 Apr 2017 20:31:52 +0200, Otac=C3=ADlio = wrote: > Em 12/04/2017 15:25, Ronald Klop escreveu: >> On Wed, 05 Apr 2017 12:46:01 +0200, Ronald Klop = >> wrote: >> >>> Hi, >>> >>> I'm building 11-STABLE for SHEEVAPLUG on a 12-CURRENT/amd64. >>> I get this compile error. >>> How can I resolve this without a clean build? I would like to preven= t = >>> recompiling llvm for 12 hours. >>> >>> --- newfs_nandfs.o --- >>> cc -O -pipe -g -MD -MF.depend.newfs_nandfs.o -MTnewfs_nandfs.o = >>> -std=3Dgnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W = >>> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = >>> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch = >>> -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline = = >>> -Wnested-externs -Wredundant-decls -Wold-style-definition = >>> -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety = >>> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = >>> -Qunused-arguments -c /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c= = >>> -o newfs_nandfs.o >>> /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking = = >>> address of packed member 'f_uuid' of class or structure = >>> 'nandfs_fsdata' may result in an unaligned pointer value = >>> [-Werror,-Waddress-of-packed-member] >>> uuidgen(&fsdata.f_uuid, 1); >>> ^~~~~~~~~~~~~ >>> 1 error generated. >>> *** [newfs_nandfs.o] Error code 1 >>> >>> make[4]: stopped in /usr/src-arm/sbin/newfs_nandfs >>> 1 error >>> >>> make[4]: stopped in /usr/src-arm/sbin/newfs_nandfs >>> *** [all_subdir_sbin/newfs_nandfs] Error code 2 >>> >>> >>> Do I have to clean and rebuild some specific library? >>> Or something else? >>> >>> Regards, >>> Ronald. >> >> I cleaned, did rm -r /usr/obj-arm/*, waited for half a day compiling = = >> llvm and got the same error. >> This is while compiling 11-STABLE/arm on 12-CURRENT/amd64. >> >> =3D=3D=3D> sbin/newfs_nandfs (all) >> echo newfs_nandfs.full: = >> /usr/obj-arm/arm.arm/usr/src-arm/tmp/usr/lib/libc.a /usr >> /obj-arm/arm.arm/usr/src-arm/tmp/usr/lib/libgeom.a >> .depend >> cc -O -pipe -g -MD -MF.depend.newfs_nandfs.o -MTnewfs_nandfs.o = >> -std=3Dgnu99 -W >> system-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter= = >> -Wstrict-p >> rototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type = >> -Wcast-qual -Wwrite >> -strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align = >> -Wchar-subscripts -Wi >> nline -Wnested-externs -Wredundant-decls -Wold-style-definition = >> -Wno-pointer-sig >> n -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body = >> -Wno-string-pl >> us-int -Wno-unused-const-variable -Qunused-arguments -c = >> /usr/src-arm/sbin/newf >> s_nandfs/newfs_nandfs.c -o newfs_nandfs.o >> /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking = >> address of p >> acked member 'f_uuid' of class or structure 'nandfs_fsdata' may resul= t = >> in an una >> ligned pointer value [-Werror,-Waddress-of-packed-member] >> uuidgen(&fsdata.f_uuid, 1); >> ^~~~~~~~~~~~~ >> 1 error generated. >> *** Error code 1 >> >> >> Any ideas? >> >> Ronald. > > What is the revision of HEAD that you are using? I did a full = > buildworld/buildkernel using a beaglebone black with HEAD revision = > 316378 (It took 3,5 days to finish.). > This is the host OS (amd64) which I'm building on. FreeBSD 12.0-CURRENT #33 r316684M: Mon Apr 10 23:08:07 CEST 2017 > []'s > -Otacilio > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"= From owner-freebsd-arm@freebsd.org Wed Apr 12 18:57:41 2017 Return-Path: Delivered-To: freebsd-arm@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 A6463D3BD1E for ; Wed, 12 Apr 2017 18:57:41 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 71466EB3 for ; Wed, 12 Apr 2017 18:57:41 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cyNSU-0002sq-Tt for freebsd-arm@freebsd.org; Wed, 12 Apr 2017 20:57:39 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Subject: Re: newfs_nandfs compile error 11-STABLE References: <87a7b063-f464-192f-8df4-a9cb1a3adeb4@bsd.com.br> Date: Wed, 12 Apr 2017 20:57:38 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: acce7ce4444675d86ac1a19c5a5a969d X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 18:57:41 -0000 On Wed, 12 Apr 2017 20:37:22 +0200, Warner Losh wrote: > Try building WITHOUT_NAND rather than WITH_NAND. nandfs is super > broken wrt to VFS locking and is data corruption waiting to happen. > I understand that that helps. Does that still build nandtool? I use that= = to erase the nand memory before I dd a new kernel on it. NB: I stopped using nandfs a while ago, because it doesn't work reliable= = indeed. Ronald. > Warner > > On Wed, Apr 12, 2017 at 12:31 PM, Otac=C3=ADlio = > wrote: >> Em 12/04/2017 15:25, Ronald Klop escreveu: >>> >>> On Wed, 05 Apr 2017 12:46:01 +0200, Ronald Klop >>> wrote: >>> >>>> Hi, >>>> >>>> I'm building 11-STABLE for SHEEVAPLUG on a 12-CURRENT/amd64. >>>> I get this compile error. >>>> How can I resolve this without a clean build? I would like to preve= nt >>>> recompiling llvm for 12 hours. >>>> >>>> --- newfs_nandfs.o --- >>>> cc -O -pipe -g -MD -MF.depend.newfs_nandfs.o -MTnewfs_nandfs.o >>>> -std=3Dgnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W >>>> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes >>>> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch = = >>>> -Wshadow >>>> -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline = >>>> -Wnested-externs >>>> -Wredundant-decls -Wold-style-definition -Wno-pointer-sign >>>> -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body >>>> -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments = -c >>>> /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c -o newfs_nandfs.o >>>> /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking= >>>> address of packed member 'f_uuid' of class or structure = >>>> 'nandfs_fsdata' may >>>> result in an unaligned pointer value = >>>> [-Werror,-Waddress-of-packed-member] >>>> uuidgen(&fsdata.f_uuid, 1); >>>> ^~~~~~~~~~~~~ >>>> 1 error generated. >>>> *** [newfs_nandfs.o] Error code 1 >>>> >>>> make[4]: stopped in /usr/src-arm/sbin/newfs_nandfs >>>> 1 error >>>> >>>> make[4]: stopped in /usr/src-arm/sbin/newfs_nandfs >>>> *** [all_subdir_sbin/newfs_nandfs] Error code 2 >>>> >>>> >>>> Do I have to clean and rebuild some specific library? >>>> Or something else? >>>> >>>> Regards, >>>> Ronald. >>> >>> >>> I cleaned, did rm -r /usr/obj-arm/*, waited for half a day compiling= = >>> llvm >>> and got the same error. >>> This is while compiling 11-STABLE/arm on 12-CURRENT/amd64. >>> >>> =3D=3D=3D> sbin/newfs_nandfs (all) >>> echo newfs_nandfs.full: >>> /usr/obj-arm/arm.arm/usr/src-arm/tmp/usr/lib/libc.a /usr >>> /obj-arm/arm.arm/usr/src-arm/tmp/usr/lib/libgeom.a >> .depend >>> cc -O -pipe -g -MD -MF.depend.newfs_nandfs.o -MTnewfs_nandfs.o >>> -std=3Dgnu99 -W >>> system-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-paramete= r >>> -Wstrict-p >>> rototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type = >>> -Wcast-qual >>> -Wwrite >>> -strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align >>> -Wchar-subscripts -Wi >>> nline -Wnested-externs -Wredundant-decls -Wold-style-definition >>> -Wno-pointer-sig >>> n -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body >>> -Wno-string-pl >>> us-int -Wno-unused-const-variable -Qunused-arguments -c >>> /usr/src-arm/sbin/newf >>> s_nandfs/newfs_nandfs.c -o newfs_nandfs.o >>> /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking >>> address of p >>> acked member 'f_uuid' of class or structure 'nandfs_fsdata' may resu= lt = >>> in >>> an una >>> ligned pointer value [-Werror,-Waddress-of-packed-member] >>> uuidgen(&fsdata.f_uuid, 1); >>> ^~~~~~~~~~~~~ >>> 1 error generated. >>> *** Error code 1 >>> >>> >>> Any ideas? >>> >>> Ronald. >> >> >> What is the revision of HEAD that you are using? I did a full >> buildworld/buildkernel using a beaglebone black with HEAD revision = >> 316378 >> (It took 3,5 days to finish.). >> >> []'s >> -Otacilio >> >> >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org= " > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"= From owner-freebsd-arm@freebsd.org Wed Apr 12 19:22:33 2017 Return-Path: Delivered-To: freebsd-arm@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 16463D3B658; Wed, 12 Apr 2017 19:22:33 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CE54D17D; Wed, 12 Apr 2017 19:22:32 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::11dd:a3c9:6e43:3dce] (unknown [IPv6:2001:470:7a58:0:11dd:a3c9:6e43:3dce]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id ADDFE240B7; Wed, 12 Apr 2017 21:22:22 +0200 (CEST) From: Dimitry Andric Message-Id: <1F217A73-A90C-4F82-8726-88B57FC221C9@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_58F000DB-E6A1-4CA2-9D1F-9A3CDC83A58A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: newfs_nandfs compile error 11-STABLE Date: Wed, 12 Apr 2017 21:22:13 +0200 In-Reply-To: Cc: freebsd-arm@freebsd.org, "freebsd-fs@freebsd.org" To: Ronald Klop References: X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:22:33 -0000 --Apple-Mail=_58F000DB-E6A1-4CA2-9D1F-9A3CDC83A58A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12 Apr 2017, at 20:25, Ronald Klop wrote: >=20 > On Wed, 05 Apr 2017 12:46:01 +0200, Ronald Klop = wrote: ... > /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking = address of p > acked member 'f_uuid' of class or structure 'nandfs_fsdata' may result = in an una > ligned pointer value [-Werror,-Waddress-of-packed-member] > uuidgen(&fsdata.f_uuid, 1); > ^~~~~~~~~~~~~ > 1 error generated. > *** Error code 1 >=20 >=20 > Any ideas? Either use NO_WERROR, or ensure you have at least r314671, where this warning was fixed. -Dimitry --Apple-Mail=_58F000DB-E6A1-4CA2-9D1F-9A3CDC83A58A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljufm4ACgkQsF6jCi4glqPCOACdE1D8F0LcuTmFXZ/v2zbejOvu uUkAnj1dyvNCY9v8qBHq6xqTLdWfKdTI =Fk3a -----END PGP SIGNATURE----- --Apple-Mail=_58F000DB-E6A1-4CA2-9D1F-9A3CDC83A58A-- From owner-freebsd-arm@freebsd.org Wed Apr 12 19:33:00 2017 Return-Path: Delivered-To: freebsd-arm@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 DC0F1D3BC39; Wed, 12 Apr 2017 19:33:00 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A64EADA7; Wed, 12 Apr 2017 19:32:59 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cyO0e-0001k4-UN; Wed, 12 Apr 2017 21:32:57 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Dimitry Andric" , "Conrad E. Meyer" Cc: freebsd-arm@freebsd.org, "freebsd-fs@freebsd.org" Subject: Re: newfs_nandfs compile error 11-STABLE References: <1F217A73-A90C-4F82-8726-88B57FC221C9@FreeBSD.org> Date: Wed, 12 Apr 2017 21:32:56 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <1F217A73-A90C-4F82-8726-88B57FC221C9@FreeBSD.org> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 0ccaee305be983877c9e38c09cbf8ec4 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 19:33:01 -0000 On Wed, 12 Apr 2017 21:22:13 +0200, Dimitry Andric wrote: > On 12 Apr 2017, at 20:25, Ronald Klop wrote: >> >> On Wed, 05 Apr 2017 12:46:01 +0200, Ronald Klop >> wrote: > ... >> /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking >> address of p >> acked member 'f_uuid' of class or structure 'nandfs_fsdata' may result >> in an una >> ligned pointer value [-Werror,-Waddress-of-packed-member] >> uuidgen(&fsdata.f_uuid, 1); >> ^~~~~~~~~~~~~ >> 1 error generated. >> *** Error code 1 >> >> >> Any ideas? > > Either use NO_WERROR, or ensure you have at least r314671, where this > warning was fixed. > > -Dimitry > I cc the original committer cem@freebsd. Is it possible to merge r314671 to 11-CURRENT? Regards, Ronald. From owner-freebsd-arm@freebsd.org Wed Apr 12 20:53:59 2017 Return-Path: Delivered-To: freebsd-arm@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 A54EBD3B4D5; Wed, 12 Apr 2017 20:53:59 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) (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 444F03D8; Wed, 12 Apr 2017 20:53:58 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-wm0-f45.google.com with SMTP id t189so33220169wmt.1; Wed, 12 Apr 2017 13:53:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=PO3RR7I9euUBPoqLLDwuE5W/5au9/pkT7JXIN8jKwK8=; b=MbfavXRY8AtC2OC8UWd72KTECnalXOCpDcuv9WwDowqUP9zwvbsiSbc5O8zwP2jufO +3MY8M9S7i/y5Nyp0OkuwO055SWvhe5w4s5cQCngOdhBTuRTaMu0J0ErjR0+ve+A9LJE BlqebHWmRZzKUdxfvSTzwCwMb0gVzpHuUC03fh5SyQSduiEaIV1guMHmIsVwmDN1Bycq tN6sM9dr2iFp3iKvkA1E5cgKVy3glF0FolKIcO2ZMmc3kC/IdFGiasPxtb6tXWvRlm7j L2jdpvr6lKkGMdZJUceVWHa6d/UFeLgfvdiGYaAjrJ7b+2fQoo1XLC0WYHtVkFeKxDlo IfXQ== X-Gm-Message-State: AN3rC/4LDRy5TWK3kRdYBUgTM+eSmCt50yc8LgrT009KUeprvHnIUR4L L2Ver8sDuOkjvJmSWlc= X-Received: by 10.28.14.138 with SMTP id 132mr53308wmo.141.1492028901228; Wed, 12 Apr 2017 13:28:21 -0700 (PDT) Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com. [209.85.128.174]) by smtp.gmail.com with ESMTPSA id 33sm26688822wrd.40.2017.04.12.13.28.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 13:28:20 -0700 (PDT) Received: by mail-wr0-f174.google.com with SMTP id c55so24333649wrc.3; Wed, 12 Apr 2017 13:28:20 -0700 (PDT) X-Received: by 10.223.131.67 with SMTP id 61mr4729383wrd.57.1492028900741; Wed, 12 Apr 2017 13:28:20 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.80.169.4 with HTTP; Wed, 12 Apr 2017 13:28:20 -0700 (PDT) In-Reply-To: References: <1F217A73-A90C-4F82-8726-88B57FC221C9@FreeBSD.org> From: Conrad Meyer Date: Wed, 12 Apr 2017 13:28:20 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: newfs_nandfs compile error 11-STABLE To: Ronald Klop Cc: Dimitry Andric , freebsd-arm , "freebsd-fs@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 20:53:59 -0000 I don't do MFCs. Someone else is free to do so. On Wed, Apr 12, 2017 at 12:32 PM, Ronald Klop wrote: > On Wed, 12 Apr 2017 21:22:13 +0200, Dimitry Andric wrote: > >> On 12 Apr 2017, at 20:25, Ronald Klop wrote: >>> >>> >>> On Wed, 05 Apr 2017 12:46:01 +0200, Ronald Klop >>> wrote: >> >> ... >>> >>> /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking >>> address of p >>> acked member 'f_uuid' of class or structure 'nandfs_fsdata' may result in >>> an una >>> ligned pointer value [-Werror,-Waddress-of-packed-member] >>> uuidgen(&fsdata.f_uuid, 1); >>> ^~~~~~~~~~~~~ >>> 1 error generated. >>> *** Error code 1 >>> >>> >>> Any ideas? >> >> >> Either use NO_WERROR, or ensure you have at least r314671, where this >> warning was fixed. >> >> -Dimitry >> > > > I cc the original committer cem@freebsd. Is it possible to merge r314671 to > 11-CURRENT? > > Regards, > Ronald. From owner-freebsd-arm@freebsd.org Thu Apr 13 05:40:21 2017 Return-Path: Delivered-To: freebsd-arm@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 76732D3B55E for ; Thu, 13 Apr 2017 05:40:21 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh605-vm12.bullet.mail.ssk.yahoo.co.jp (nh605-vm12.bullet.mail.ssk.yahoo.co.jp [182.22.90.85]) by mx1.freebsd.org (Postfix) with SMTP id 0FD288CA for ; Thu, 13 Apr 2017 05:40:20 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [182.22.66.105] by nh605.bullet.mail.ssk.yahoo.co.jp with NNFMP; 13 Apr 2017 05:26:33 -0000 Received: from [182.22.91.132] by t603.bullet.mail.ssk.yahoo.co.jp with NNFMP; 13 Apr 2017 05:26:33 -0000 Received: from [127.0.0.1] by omp605.mail.ssk.yahoo.co.jp with NNFMP; 13 Apr 2017 05:26:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 241628.59317.bm@omp605.mail.ssk.yahoo.co.jp Received: (qmail 62144 invoked by uid 60001); 13 Apr 2017 05:26:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1492061193; bh=qARxWv0smk67NbrC7ye3J8zpIegjK3Gkr3WT2LOCCxQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bA0OIcBIrgXAO6RHChHqidds2n+MfBAdniVaUFsvOFGfMOOTxUNO5wHDXcIsU6NyFu8+dl1SRk32JEwYvzk+Gt13ck4Aeq+b/7B6k0zJQnoHP/sUlfe4E6E0fF1nE3lEvaroYTXVse4g/e9pArYpewGx0Nt1ihAEzZEBOMwCA5g= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mEE0KJTxnxkpfENXLuM0wjgr5f7koZ7Z6eoZHGUqYkAGs31bN7qeI8Umx2nYpo+W6OMx7RsdN78ccm0URwB9MVCL9vwlj1dM+rhFWp3hlnXWtflZ3c/Ksv2yTb3sKpwmklqv7se5ew1/g8mxokvBL0YAKRPRWhqRHuqshSniKHE=; Message-ID: <107064.50750.qm@web101717.mail.ssk.yahoo.co.jp> X-YMail-OSG: cpxpeW8VM1mLS6NW7r1Db0KX5e09vKd5sxgxZtOBrzlJACGXH_fTw_0dJNcDYGYTqqFV0ZrjFKrX8rT02wpoWK17_81bYn6fr10XZKB.UdkpB1_pDB.30FFJk6qCdLclFzNI82iVMBAdvZ6ePjsyfjaamT4a8p5sGLKqgfX5kMC4wbA6rVj6YtKS21JnxjrNLtxR941QH_g2wj.E0.eRLp2UaxpfBac9wXTGQCf22cU7kAteq2bZmzvpOPB5VOmu2pMETaIC2reDvsEbv04stPSYWfFll3UfRKNlS87uHgOuimnRynhx2099beVcysDEwreT4LYUzzK1EZG9FDgIkOA3qb4oqV0J.c.ybx7OAm6HtavFzBCWMa5i49ZinH7CUnmOoPXKKIFuWCtfGHURJ1hkh6HuZ61vECJ8hFNUB0WiGGRciOXE6zx7OF5pOZVRaWRCyBsK3_eL36v3FGC61IQOqWhlxMFWJ_4Th5Ho7VpPbsByH_MKjlynEtw_kylVh4T1Nxp.lWAUw4FcMbHBX._2qWnqihq4NH024FmcCDeYLF0NOILZ7U.h3DghM.3hpmQQDka6fiv1uI8Ni7lWTBm_a_iNqBgZO4AI26m1fXT3fg-- Received: from [210.20.198.8] by web101717.mail.ssk.yahoo.co.jp via HTTP; Thu, 13 Apr 2017 14:26:32 JST X-Mailer: YahooMailWebService/0.8.111_71 X-YMail-JAS: LJ_XzEwVM1kb80maUBYvF87lATpYwUmaUs0TaatLF2Ys8.E8MxeXCNPOgpPP3gKNekIgJ1_qd1E4ctXY2MnqXDSR_AqeSseuWvUItvMGfv5GwBMkHzIPZrfscJ2iLe65q3ZI References: <622336.93399.qm@web101714.mail.ssk.yahoo.co.jp> Date: Thu, 13 Apr 2017 14:26:32 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: Re: Can't use mge on 88F5181 To: Adrian Chadd Cc: "freebsd-arm@freebsd.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 05:40:21 -0000 Hi.=0A=0ANo arp and unicast packet receive mge checked by tcpdump command= =0Aon this target.=A0Also no pacet trans=A0checked by tcpdump command on=0A= other machine.=A0netstat -i have trans packet count without error.=0ABut no= receive=A0other=A0machine.=A0MIDO switch control is work fine.=0AGiga swit= ch=A0physical port to=A0physical=A0port is receive and trans=0Ais fine.=A0B= ut cpu port nothing.=0A=0AMy e6060sw.c code have dot1q support by VTU acces= s code. e6000sw=0Adon't have it.=A0I want add dot1q code to e6000sw too. Bu= t It is=0Avery=A0hard=A0no data sheet.=0A=0AI found ml topics is this type = target at 2011. That subject is=A0=0A"Embedded switch instead of stadard PH= Y". I seem this is origin=0Aof=A0etherswitch.=0A=0AThanks=0A=0AHiroki Mori= =0A=0A=0A----- Original Message -----=0A> From: Adrian Chadd =0A> To: Mori Hiroki =0A> Cc: "freebsd-arm= @freebsd.org" =0A> Date: 2017/4/12, Wed 09:55=0A> = Subject: Re: Can't use mge on 88F5181=0A> =0A> hiya,=0A> =0A> did you figur= e it out?=0A> =0A> Is there something like CRC, etc packet errors or someth= ing on RX?=0A> =0A> =0A> =0A> -adrian=0A> =0A> =0A> On 4 April 2017 at 04:4= 2, Mori Hiroki wrote:=0A>> Hi.=0A>> =0A>> I try t= o use Buffalo WZR-AMPG300NH. This module have 88F5181 and 88E6131.=0A>> I = modify dev/mge and dev/etherswitch/e600sw/e6000sw.c.=0A>> =0A>> Network in= terface mge is detect but not work. Switch port is work by=0A>> port vlan.= But CPU connected port3 is nothing trans and receive packet.=0A>> =0A>> I= check marvell code but not fix this problem.=0A>> =0A>> If you have advic= e, please let me know.=0A>> =0A>> =0A>> This is dmesg.=0A>> =0A>> https:/= /gist.github.com/yamori813/ecd5df1b314053a73f310c1122775540=0A>> =0A>> =0A>= > Thanks.=0A>> =0A>> Hiroki Mori=0A>> __________________________________= _____________=0A>> freebsd-arm@freebsd.org mailing list=0A>> https://list= s.freebsd.org/mailman/listinfo/freebsd-arm=0A>> To unsubscribe, send any m= ail to =0A> "freebsd-arm-unsubscribe@freebsd.org"=0A> From owner-freebsd-arm@freebsd.org Thu Apr 13 17:13:19 2017 Return-Path: Delivered-To: freebsd-arm@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 2222AD3B4F8; Thu, 13 Apr 2017 17:13:19 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DFD2E86E; Thu, 13 Apr 2017 17:13:18 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::21d5:18c1:7aec:de4a] (unknown [IPv6:2001:470:7a58:0:21d5:18c1:7aec:de4a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 83F9C2414C; Thu, 13 Apr 2017 19:13:16 +0200 (CEST) From: Dimitry Andric Message-Id: <54B86FBF-1108-40D4-B699-AC6E8366DBE6@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_26A1F3FA-7614-4859-A5F8-674B7B7DD651"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: newfs_nandfs compile error 11-STABLE Date: Thu, 13 Apr 2017 19:13:07 +0200 In-Reply-To: Cc: "freebsd-fs@freebsd.org" , freebsd-arm To: Ronald Klop References: <1F217A73-A90C-4F82-8726-88B57FC221C9@FreeBSD.org> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 17:13:19 -0000 --Apple-Mail=_26A1F3FA-7614-4859-A5F8-674B7B7DD651 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12 Apr 2017, at 22:28, Conrad Meyer wrote: >=20 > I don't do MFCs. Someone else is free to do so. > On Wed, Apr 12, 2017 at 12:32 PM, Ronald Klop = wrote: >> On Wed, 12 Apr 2017 21:22:13 +0200, Dimitry Andric = wrote: ... >>>> /usr/src-arm/sbin/newfs_nandfs/newfs_nandfs.c:543:11: error: taking >>>> address of p >>>> acked member 'f_uuid' of class or structure 'nandfs_fsdata' may = result in >>>> an una >>>> ligned pointer value [-Werror,-Waddress-of-packed-member] >>>> uuidgen(&fsdata.f_uuid, 1); >>>> ^~~~~~~~~~~~~ ... >> I cc the original committer cem@freebsd. Is it possible to merge = r314671 to >> 11-CURRENT? Merged to stable/11 and stable/10 in r316772. -Dimitry --Apple-Mail=_26A1F3FA-7614-4859-A5F8-674B7B7DD651 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljvsasACgkQsF6jCi4glqPUiQCg2qlurWWln3E4JtqQsmbI9fuV A5MAoPRZAPWK0sUIZCIBmnVY+XAur7qe =tH8J -----END PGP SIGNATURE----- --Apple-Mail=_26A1F3FA-7614-4859-A5F8-674B7B7DD651-- From owner-freebsd-arm@freebsd.org Thu Apr 13 21:00:57 2017 Return-Path: Delivered-To: freebsd-arm@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 83E9DD1029D for ; Thu, 13 Apr 2017 21:00:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 1A977617 for ; Thu, 13 Apr 2017 21:00:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wr0-x229.google.com with SMTP id c55so42381675wrc.3 for ; Thu, 13 Apr 2017 14:00:57 -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=6qouzZ4hF/fTyQTf5HQM8Z6QcyqGih8VelyXgQAo/eQ=; b=E1FwLHxME5AWCw7ysQ16V+ARaANI0yHOIvOWuZoMjgml3xUuirhhKIQTp3k5YxhycV 2a+XeYQ5jhUfLTcD0gFX2ml//9L3bMZHzCENXSsJd5ZDoiPlxfTAwdl8S6UgJ4Jgk0pp ZcWPSG8eAcsHYXdnUU1AGRtwxedrffruFEH8bRv13dLe9/jw+EnH3y7kVVOwMVnS8VsZ Z32o6v692Nr45qoLcDUyN1Gmnj5hD9vMnoXl2IrXb5/hljYWOD2qMQtc8RiNbYlFXShb kjrE6YtKu8xA9AUPU/XgZ/01Tz+ssEcLtodAIAdJKsILQ+02qmYMaduqgvblNtZXiKjt Ea5w== 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=6qouzZ4hF/fTyQTf5HQM8Z6QcyqGih8VelyXgQAo/eQ=; b=QMOinURYzeO+GqVTyzW8ea7fdyhIsCvW2Laheipb1x9Cg5IoOCX7i654y7S+ITVnYj ldj9UK2GaenD+v5fiJ2dc5IhlFzCyIb7h7yKO11sXdfaW+pp/iEA8WGHFmT6B5EejZXi 6lzNAagA6ht80VKaj0AQ0gNbTbUS0Srf2j12zFRNssSPsqlbp03B5ehDvX5g/kATURgW g4EMo8afYKVIf9ZHqZ9i3x8MkR0avS0rTvAUju+eIxfqJh30Jxc6L6vrhifU/HZoekIG nrPq+OZ6cS8MQYFK9bFCujYmXKVnEsTSVDosydFmIoV5idTqCfCWDpeBMOIycfUInkiM EJ9A== X-Gm-Message-State: AN3rC/5HKvPAKCRRmTxIy00iM6Fo57xt3mDUm+0JGXQmF4kWlG3y8tSz 9qzdeStciNxMQu45eux1z7WRiWJhivwX X-Received: by 10.223.129.4 with SMTP id 4mr5021039wrm.62.1492117255432; Thu, 13 Apr 2017 14:00:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.185.66 with HTTP; Thu, 13 Apr 2017 14:00:54 -0700 (PDT) In-Reply-To: <107064.50750.qm@web101717.mail.ssk.yahoo.co.jp> References: <622336.93399.qm@web101714.mail.ssk.yahoo.co.jp> <107064.50750.qm@web101717.mail.ssk.yahoo.co.jp> From: Adrian Chadd Date: Thu, 13 Apr 2017 14:00:54 -0700 Message-ID: Subject: Re: Can't use mge on 88F5181 To: Mori Hiroki Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 21:00:57 -0000 hi, I'd have to go dig through the datasheets of everything to see what the deal is. :( it could be ethernet switch side, it could be interface config mismatch (MII, RMII, RGMII, SGMII, PSGMII, etc.); it could be clock configuration (if it's MII, the clock is changed based on 10/100; later interfaces run at a constant speed and just bitstuff), etc, etc. Can you get per-switch-port counters on the switch? Is the CPU port on the switch seeing traffic? -adrian On 12 April 2017 at 22:26, Mori Hiroki wrote: > Hi. > > No arp and unicast packet receive mge checked by tcpdump command > on this target. Also no pacet trans checked by tcpdump command on > other machine. netstat -i have trans packet count without error. > But no receive other machine. MIDO switch control is work fine. > Giga switch physical port to physical port is receive and trans > is fine. But cpu port nothing. > > My e6060sw.c code have dot1q support by VTU access code. e6000sw > don't have it. I want add dot1q code to e6000sw too. But It is > very hard no data sheet. > > I found ml topics is this type target at 2011. That subject is > "Embedded switch instead of stadard PHY". I seem this is origin > of etherswitch. > > Thanks > > Hiroki Mori > > > ----- Original Message ----- >> From: Adrian Chadd >> To: Mori Hiroki >> Cc: "freebsd-arm@freebsd.org" >> Date: 2017/4/12, Wed 09:55 >> Subject: Re: Can't use mge on 88F5181 >> >> hiya, >> >> did you figure it out? >> >> Is there something like CRC, etc packet errors or something on RX? >> >> >> >> -adrian >> >> >> On 4 April 2017 at 04:42, Mori Hiroki wrote: >>> Hi. >>> >>> I try to use Buffalo WZR-AMPG300NH. This module have 88F5181 and 88E6131. >>> I modify dev/mge and dev/etherswitch/e600sw/e6000sw.c. >>> >>> Network interface mge is detect but not work. Switch port is work by >>> port vlan. But CPU connected port3 is nothing trans and receive packet. >>> >>> I check marvell code but not fix this problem. >>> >>> If you have advice, please let me know. >>> >>> >>> This is dmesg. >>> >>> https://gist.github.com/yamori813/ecd5df1b314053a73f310c1122775540 >>> >>> >>> Thanks. >>> >>> Hiroki Mori >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to >> "freebsd-arm-unsubscribe@freebsd.org" >> From owner-freebsd-arm@freebsd.org Fri Apr 14 01:04:27 2017 Return-Path: Delivered-To: freebsd-arm@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 9A435D3AFDF for ; Fri, 14 Apr 2017 01:04:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-41.reflexion.net [208.70.210.41]) (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 4F89F69 for ; Fri, 14 Apr 2017 01:04:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15869 invoked from network); 14 Apr 2017 01:04:25 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 14 Apr 2017 01:04:25 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 13 Apr 2017 21:04:25 -0400 (EDT) Received: (qmail 24309 invoked from network); 14 Apr 2017 01:04:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Apr 2017 01:04:25 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 661D7EC7901; Thu, 13 Apr 2017 18:04:24 -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: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) Message-Id: Date: Thu, 13 Apr 2017 18:04:23 -0700 Cc: freebsd-arm , freebsd-toolchain-owner@freebsd.org, ericturgeon.bsd@gmail.com To: Gerald Pfeifer , Pedro Giffuni , FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 01:04:27 -0000 As means of investigating if lang/gcc6-aux has other problems building on aarch64 than just __nonnull and __nonull_all I did: # svnlite diff /usr/src/sys/sys/ Index: /usr/src/sys/sys/cdefs.h =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 --- /usr/src/sys/sys/cdefs.h (revision 315914) +++ /usr/src/sys/sys/cdefs.h (working copy) @@ -376,6 +376,10 @@ #define __noinline #endif =20 +// HACK to enable older source that did not track. +#define __nonnull(x) +#define __nonnull_all + #if __GNUC_PREREQ__(3, 4) #define __fastcall __attribute__((__fastcall__)) #define __result_use_check = __attribute__((__warn_unused_result__)) and so such similarly shows up in /usr/include/sys/cdefs.h . The attempt to build lang/gcc6-aux (as part of attempting to build ports-mgmt/synth) resulted in: In file included from = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/f= dmatch.c:45:0: ./config.h:556:15: error: two or more data types in declaration = specifiers #define pid_t int ^ In file included from = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/f= dmatch.c:49:0: = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-= aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:266:9: error: unknown = type name '__vm_ooffset_t' typedef __vm_ooffset_t vm_ooffset_t; ^~~~~~~~~~~~~~ = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-= aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:268:9: error: unknown = type name '__vm_pindex_t' typedef __vm_pindex_t vm_pindex_t; ^~~~~~~~~~~~~ gmake[4]: *** [Makefile:732: fdmatch.o] Error 1 gmake[4]: Leaving directory = '/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/build/libiberty' gmake[3]: *** [Makefile:7458: all-libiberty] Error 2 gmake[3]: *** Waiting for unfinished jobs.... vm_ooffset_t and vm_pindex_t has 2017-Feb-4 changes: Revision 313194 - (view) (download) (annotate) - [select for diffs]=20 Modified Sat Feb 4 12:26:38 2017 UTC (2 months, 1 week ago) by kib=20 File length: 10733 byte(s)=20 Diff to previous 299571 Define the vm_ooffset_t and vm_pindex_t types as machine-independend. The types are for the byte offset and page index in vm object. They are similar to off_t, which is defined as 64bit MI integer. Using MI definitions will allow to provide consistent MD values of vm object-related maximum sizes. Reviewed by: alc Sponsored by: The FreeBSD Foundation MFC after: 1 week The "#define pid_t int" in the local: /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/build/libiberty/config.h likely messes up some later "typedef . . . pid_t;", such as: = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-= aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:typedef __pid_t = pid_t; /* process id */ resulting in: typedef __pid_t int; So lang/gcc6-aux bootstrapping has more problems than just __nonnull and __nonnull_all issues, at least for aarch64 head. lang/gcc6-aux might not be the only thing with such issues. I stopped with this. There could be more issues for lang/gcc6-aux . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Apr 14 01:39:01 2017 Return-Path: Delivered-To: freebsd-arm@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 A4E12D3D782 for ; Fri, 14 Apr 2017 01:39:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-43.reflexion.net [208.70.210.43]) (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 6AFDAE8A for ; Fri, 14 Apr 2017 01:39:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25759 invoked from network); 14 Apr 2017 01:41:57 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Apr 2017 01:41:57 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 13 Apr 2017 21:38:59 -0400 (EDT) Received: (qmail 15639 invoked from network); 14 Apr 2017 01:38:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Apr 2017 01:38:59 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7E3A5EC7901; Thu, 13 Apr 2017 18:38:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) From: Mark Millard In-Reply-To: Date: Thu, 13 Apr 2017 18:38:57 -0700 Cc: freebsd-arm , freebsd-head@freebsd.org, ericturgeon.bsd@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> References: To: Gerald Pfeifer , Pedro Giffuni , FreeBSD Ports , FreeBSD Toolchain X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 01:39:01 -0000 [I accidentally sent the original of the "on . . . wrote" below to the wrong toolchain list. This just corrects that.] [I'll also note that lang/gcc6-aux was indirectly attempted when I tried to build ports-mgmt/synth on a Pine64+ 2GB (an aarch64 context). I had noticed the recent update claiming native aarch64 support for synth and tried to build it. I've no direct interest in lang/gcc6-aux . I just ended up with FYI information about lang/gcc6-aux .] =3D=3D=3D Mark Millard markmi at dsl-only.net (I've added a missing "n" in the first "__nonnull_all" below.) On 2017-Apr-13, at 6:04 PM, Mark Millard wrote: > As means of investigating if lang/gcc6-aux has other problems > building on aarch64 than just __nonnull and __nonnull_all I did: >=20 > # svnlite diff /usr/src/sys/sys/ > Index: /usr/src/sys/sys/cdefs.h > =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 > --- /usr/src/sys/sys/cdefs.h (revision 315914) > +++ /usr/src/sys/sys/cdefs.h (working copy) > @@ -376,6 +376,10 @@ > #define __noinline > #endif >=20 > +// HACK to enable older source that did not track. > +#define __nonnull(x) > +#define __nonnull_all > + > #if __GNUC_PREREQ__(3, 4) > #define __fastcall __attribute__((__fastcall__)) > #define __result_use_check = __attribute__((__warn_unused_result__)) >=20 > and so such similarly shows up in /usr/include/sys/cdefs.h . >=20 > The attempt to build lang/gcc6-aux (as part of attempting > to build ports-mgmt/synth) resulted in: >=20 >=20 > In file included from = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/f= dmatch.c:45:0: > ./config.h:556:15: error: two or more data types in declaration = specifiers > #define pid_t int > ^ > In file included from = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/f= dmatch.c:49:0: > = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-= aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:266:9: error: unknown = type name '__vm_ooffset_t' > typedef __vm_ooffset_t vm_ooffset_t; > ^~~~~~~~~~~~~~ > = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-= aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:268:9: error: unknown = type name '__vm_pindex_t' > typedef __vm_pindex_t vm_pindex_t; > ^~~~~~~~~~~~~ > gmake[4]: *** [Makefile:732: fdmatch.o] Error 1 > gmake[4]: Leaving directory = '/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/build/libiberty' > gmake[3]: *** [Makefile:7458: all-libiberty] Error 2 > gmake[3]: *** Waiting for unfinished jobs.... >=20 >=20 > vm_ooffset_t and vm_pindex_t has 2017-Feb-4 changes: >=20 > Revision 313194 - (view) (download) (annotate) - [select for diffs]=20 > Modified Sat Feb 4 12:26:38 2017 UTC (2 months, 1 week ago) by kib=20 > File length: 10733 byte(s)=20 > Diff to previous 299571 > Define the vm_ooffset_t and vm_pindex_t types as machine-independend. >=20 > The types are for the byte offset and page index in vm object. They > are similar to off_t, which is defined as 64bit MI integer. Using MI > definitions will allow to provide consistent MD values of vm > object-related maximum sizes. >=20 > Reviewed by: alc > Sponsored by: The FreeBSD Foundation > MFC after: 1 week >=20 >=20 > The "#define pid_t int" in the local: >=20 > = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/build/libiberty/config.h >=20 > likely messes up some later "typedef . . . pid_t;", such as: >=20 > = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-= aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:typedef __pid_t = pid_t; /* process id */ >=20 > resulting in: >=20 > typedef __pid_t int; >=20 >=20 >=20 > So lang/gcc6-aux bootstrapping has more problems than just __nonnull > and __nonnull_all issues, at least for aarch64 head. >=20 > lang/gcc6-aux might not be the only thing with such issues. >=20 >=20 > I stopped with this. There could be more issues for lang/gcc6-aux . From owner-freebsd-arm@freebsd.org Fri Apr 14 02:30:51 2017 Return-Path: Delivered-To: freebsd-arm@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 0230AD3D580 for ; Fri, 14 Apr 2017 02:30:51 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1.freebsd.org (Postfix) with SMTP id D3A4CAEB for ; Fri, 14 Apr 2017 02:30:50 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: (qmail 83439 invoked by uid 99); 14 Apr 2017 02:30:49 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Apr 2017 02:30:49 +0000 Received: from [192.168.0.104] (unknown [190.157.139.67]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 0171A1A002E; Fri, 14 Apr 2017 02:30:47 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) From: Pedro Giffuni In-Reply-To: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> Date: Thu, 13 Apr 2017 21:32:14 -0500 Cc: Gerald Pfeifer , FreeBSD Ports , FreeBSD Toolchain , freebsd-arm , freebsd-head@freebsd.org, ericturgeon.bsd@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 02:30:51 -0000 > On Apr 13, 2017, at 20:38, Mark Millard wrote: >=20 > [I accidentally sent the original of the "on . . . wrote" > below to the wrong toolchain list. This just corrects that.] >=20 > [I'll also note that lang/gcc6-aux was indirectly attempted > when I tried to build ports-mgmt/synth on a Pine64+ 2GB > (an aarch64 context). I had noticed the recent update claiming > native aarch64 support for synth and tried to build it. I've > no direct interest in lang/gcc6-aux . I just ended up with > FYI information about lang/gcc6-aux .] >=20 I didn=E2=80=99t want to get into this but the problem is that as part = of it's build/bootstrapping process, GCC historically takes system headers and attempts to =E2=80=9Cfix=E2=80=9D them. I am unsure the fixes do = anything at all nowadays but the effect is that the compiler tends to take snapshots of the system headers when it is built. cdefs.h is used by all the system headers so changes in cdefs.h have good chances affecting such builds but any change are likely to cause similar trouble. In the case of gcc-aux, it appears the compilation is based on a bootstrap compiler which already carries outdated headers. A workaround, suggested by gerald@ the last time a similar issue happened was to run for install-tools/fixinc.sh. I think that may regenerate the headers and let the build use updated headers. Ultimately gcc-aux needs maintainer intervention and using outdated headers will break sooner or later: especially on -current. Hope that helps, Pedro. > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > (I've added a missing "n" in the first "__nonnull_all" below.) > On 2017-Apr-13, at 6:04 PM, Mark Millard = wrote: >=20 >> As means of investigating if lang/gcc6-aux has other problems >> building on aarch64 than just __nonnull and __nonnull_all I did: >>=20 >> # svnlite diff /usr/src/sys/sys/ >> Index: /usr/src/sys/sys/cdefs.h >> =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 >> --- /usr/src/sys/sys/cdefs.h (revision 315914) >> +++ /usr/src/sys/sys/cdefs.h (working copy) >> @@ -376,6 +376,10 @@ >> #define __noinline >> #endif >>=20 >> +// HACK to enable older source that did not track. >> +#define __nonnull(x) >> +#define __nonnull_all >> + >> #if __GNUC_PREREQ__(3, 4) >> #define __fastcall __attribute__((__fastcall__)) >> #define __result_use_check = __attribute__((__warn_unused_result__)) >>=20 >> and so such similarly shows up in /usr/include/sys/cdefs.h . >>=20 >> The attempt to build lang/gcc6-aux (as part of attempting >> to build ports-mgmt/synth) resulted in: >>=20 >>=20 >> In file included from = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/f= dmatch.c:45:0: >> ./config.h:556:15: error: two or more data types in declaration = specifiers >> #define pid_t int >> ^ >> In file included from = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/f= dmatch.c:49:0: >> = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-= aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:266:9: error: unknown = type name '__vm_ooffset_t' >> typedef __vm_ooffset_t vm_ooffset_t; >> ^~~~~~~~~~~~~~ >> = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-= aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:268:9: error: unknown = type name '__vm_pindex_t' >> typedef __vm_pindex_t vm_pindex_t; >> ^~~~~~~~~~~~~ >> gmake[4]: *** [Makefile:732: fdmatch.o] Error 1 >> gmake[4]: Leaving directory = '/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/build/libiberty' >> gmake[3]: *** [Makefile:7458: all-libiberty] Error 2 >> gmake[3]: *** Waiting for unfinished jobs.... >>=20 >>=20 >> vm_ooffset_t and vm_pindex_t has 2017-Feb-4 changes: >>=20 >> Revision 313194 - (view) (download) (annotate) - [select for diffs]=20= >> Modified Sat Feb 4 12:26:38 2017 UTC (2 months, 1 week ago) by kib=20 >> File length: 10733 byte(s)=20 >> Diff to previous 299571 >> Define the vm_ooffset_t and vm_pindex_t types as machine-independend. >>=20 >> The types are for the byte offset and page index in vm object. They >> are similar to off_t, which is defined as 64bit MI integer. Using MI >> definitions will allow to provide consistent MD values of vm >> object-related maximum sizes. >>=20 >> Reviewed by: alc >> Sponsored by: The FreeBSD Foundation >> MFC after: 1 week >>=20 >>=20 >> The "#define pid_t int" in the local: >>=20 >> = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/build/libiberty/config.h >>=20 >> likely messes up some later "typedef . . . pid_t;", such as: >>=20 >> = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-= aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:typedef __pid_t = pid_t; /* process id */ >>=20 >> resulting in: >>=20 >> typedef __pid_t int; >>=20 >>=20 >>=20 >> So lang/gcc6-aux bootstrapping has more problems than just __nonnull >> and __nonnull_all issues, at least for aarch64 head. >>=20 >> lang/gcc6-aux might not be the only thing with such issues. >>=20 >>=20 >> I stopped with this. There could be more issues for lang/gcc6-aux . >=20 From owner-freebsd-arm@freebsd.org Fri Apr 14 23:30:58 2017 Return-Path: Delivered-To: freebsd-arm@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 E1B36D3E62D; Fri, 14 Apr 2017 23:30:58 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) (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 BAFAA8B8; Fri, 14 Apr 2017 23:30:58 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from anthias.catalysis.at (mail.catalysis.at [101.187.5.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ainaz.pair.com (Postfix) with ESMTPSA id 25DC03F530; Fri, 14 Apr 2017 19:30:52 -0400 (EDT) Date: Sat, 15 Apr 2017 09:30:49 +1000 (AEST) From: Gerald Pfeifer To: Pedro Giffuni , freebsd.contact@marino.st cc: Mark Millard , freebsd-ports@freebsd.org, freebsd-toolchain@freebsd.org, freebsd-arm@freebsd.org, freebsd-head@freebsd.org, ericturgeon.bsd@gmail.com Subject: Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) In-Reply-To: Message-ID: References: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 23:30:59 -0000 On Thu, 13 Apr 2017, Pedro Giffuni wrote: > I didn’t want to get into this but the problem is that as part of it's > build/bootstrapping process, GCC historically takes system headers > and attempts to “fix” them. I am unsure the fixes do anything at all > nowadays but the effect is that the compiler tends to take snapshots > of the system headers when it is built. cdefs.h is used by all the > system headers so changes in cdefs.h have good chances affecting > such builds but any change are likely to cause similar trouble. > > In the case of gcc-aux, it appears the compilation is based on a > bootstrap compiler which already carries outdated headers. > A workaround, suggested by gerald@ the last time a similar issue > happened was to run for install-tools/fixinc.sh. I think that may > regenerate the headers and let the build use updated headers. > Ultimately gcc-aux needs maintainer intervention and using > outdated headers will break sooner or later: especially on -current. Indeed, thanks for the analysis/background, Pedro! I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6, and perhaps John (as the maintainer of that port) has plans to update it? Let me copy him. Gerald PS: John, if you have an update, happy to help and apply that for you. From owner-freebsd-arm@freebsd.org Sat Apr 15 02:53:49 2017 Return-Path: Delivered-To: freebsd-arm@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 07C78D3E1D6 for ; Sat, 15 Apr 2017 02:53:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-41.reflexion.net [208.70.210.41]) (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 C1FD110D9 for ; Sat, 15 Apr 2017 02:53:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1088 invoked from network); 15 Apr 2017 02:53:46 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 15 Apr 2017 02:53:46 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 14 Apr 2017 22:53:46 -0400 (EDT) Received: (qmail 24506 invoked from network); 15 Apr 2017 02:53:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Apr 2017 02:53:46 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5D889EC78CC; Fri, 14 Apr 2017 19:53:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) From: Mark Millard In-Reply-To: Date: Fri, 14 Apr 2017 19:53:44 -0700 Cc: Pedro Giffuni , FreeBSD Ports , FreeBSD Toolchain , freebsd-arm , ericturgeon.bsd@gmail.com, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> To: Gerald Pfeifer X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 02:53:49 -0000 On 2017-Apr-14, at 4:30 PM, Gerald Pfeifer wrote: > On Thu, 13 Apr 2017, Pedro Giffuni wrote: >> I didn=E2=80=99t want to get into this but the problem is that as = part of it's >> build/bootstrapping process, GCC historically takes system headers >> and attempts to =E2=80=9Cfix=E2=80=9D them. I am unsure the fixes do = anything at all >> nowadays but the effect is that the compiler tends to take snapshots >> of the system headers when it is built. cdefs.h is used by all the >> system headers so changes in cdefs.h have good chances affecting >> such builds but any change are likely to cause similar trouble. >>=20 >> In the case of gcc-aux, it appears the compilation is based on a >> bootstrap compiler which already carries outdated headers. >> A workaround, suggested by gerald@ the last time a similar issue >> happened was to run for install-tools/fixinc.sh. I think that may >> regenerate the headers and let the build use updated headers. >> Ultimately gcc-aux needs maintainer intervention and using >> outdated headers will break sooner or later: especially on -current. >=20 > Indeed, thanks for the analysis/background, Pedro! >=20 > I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6,=20= > and perhaps John (as the maintainer of that port) has plans to update=20= > it? Let me copy him. [As I have a prior E-mail exchange with John M. indicating that he was not intending to be the lang/gcc6-aux maintainer, I avoid spamming him with this material: I've removed him from the CC list in this reply. I can send the material to him if I see evidence of his wanting it.] Just FYI: [Previously: temporarily adding __nonnull and __nonnull_all back into into my local head FreeBSD variant got problems with: __vm_ooffset_t and __vm_pindex_t no longer existing and also the same pid_t issue indicated below.] I tried using [on a Pine64+ 2GB aarch64 system]: # = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/libexec/gcc/aarc= h64-aux-freebsd12.0/6.3.1/install-tools/mkheaders = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap to deal with __nonnull, __nonnull_all, __vm_ooffset_t, and = __vm_pindex_t. I then built via portmaster -CDK usage. Various header issues did go away but the build of lang/gcc6-aux still stopped with: In file included from = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c:20:0: ./config.h:556:15: error: two or more data types in declaration = specifiers #define pid_t int ^ I'm guessing that the define for pid_t in config.h resulted in something like: typedef ??? pid_t; that turned into something like a: typedef ??? int; for the error listed above. There were also implicit-declaration warnings: = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c: In function 'simple_object_internal_read': = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c:75:21: warning: implicit declaration of function 'read' = [-Wimplicit-function-declaration] ssize_t got =3D read (descriptor, buffer, size); ^~~~ = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c: In function 'simple_object_internal_write': = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c:119:23: warning: implicit declaration of function 'write' = [-Wimplicit-function-declaration] ssize_t wrote =3D write (descriptor, buffer, size); ^~~~~ The implicit-declaration warnings for read and write may well also not be expected/desirable. It may be that more than a script run is needed to make things be appropriate. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sat Apr 15 03:07:40 2017 Return-Path: Delivered-To: freebsd-arm@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 B44A7D3E955; Sat, 15 Apr 2017 03:07:40 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (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 7D5FC20B; Sat, 15 Apr 2017 03:07:40 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg0-x243.google.com with SMTP id o123so18618139pga.1; Fri, 14 Apr 2017 20:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=F45sLgS5DdNiaxYMSXZhbG240fLI5g2HYPhd0FSj0DA=; b=nvK5lMBRg8px5VCy2+gGAAbqDXNbJZfsQtYQHaBvXyiL7NLa/2/70HtuposuUILZD5 JG6a7JT8TplH1kC9tw1N67kV1Zpv6aiqWGCEs7l59lYhoWlyp+XrKRNkf7p3YkQgBDKl Yn7PfchnZC03mMg3s7g5nT2lVWtvT5fl58BjVoBNlEwwqOv3J4LKwPL9Kxt5l+0dswSO RnJjd/Fwi5wOUkucq8/C8dE0fgwd9EHzkqDpuC/jiZp/JjolNsn66BZkBmz//masP69c MkWEGQcD/kUE2vIPite9aghZ6shWYaPr6kovxIC1/CMx0fhAT0mXxdQU9u6PRJAzV4f2 QWLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=F45sLgS5DdNiaxYMSXZhbG240fLI5g2HYPhd0FSj0DA=; b=d1TMCd87fLbloRdPHLhxZblgAgs0N02sngn8HFlKrRMvgBn1aJ6xZWlAs/cDFWYNZr tV1zsBSYgOaxzi6PmBgvzh2AF5BsMvpczJ++p4PNTeWlc3qXinWfW0M8QCDlu3+LXDM0 0oiOgKzi1iQQUsQ8CmlEBQiUDpkZoAUO9iQX4APFk1cpYXjdejYwukmbkZUL4LBV86RD Kr6KLrPIVptb7czZfbDCDCqddpQeit3hRfCwbtpICS6DV9eVAK+G9jtjMIyLhBmNdxHj Br+chtKNUAmD8BtZDuVQGMC8+Ly1eX8eaYjcbtbFPY5pfDOeoDI6K44R0BNn/wkYvhss SS8A== X-Gm-Message-State: AN3rC/47Q8RWGBBmIvwr946W/+YPwsJkGNkDTfpa5LEgltuI2/wkJ8iy nkKi+CUOzia+VA== X-Received: by 10.84.169.67 with SMTP id g61mr939580plb.51.1492225660005; Fri, 14 Apr 2017 20:07:40 -0700 (PDT) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id l127sm5468287pga.7.2017.04.14.20.07.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 14 Apr 2017 20:07:39 -0700 (PDT) Subject: Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_534C68CC-3A27-411C-AB28-2AACB66F40B1"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: Date: Fri, 14 Apr 2017 20:07:37 -0700 Cc: Gerald Pfeifer , Pedro Giffuni , FreeBSD Ports , FreeBSD Toolchain , freebsd-arm , ericturgeon.bsd@gmail.com, FreeBSD Current Message-Id: <7606F976-20B7-4FB8-BE80-C27773F5529A@gmail.com> References: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 03:07:40 -0000 --Apple-Mail=_534C68CC-3A27-411C-AB28-2AACB66F40B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 14, 2017, at 19:53, Mark Millard wrote: >=20 > On 2017-Apr-14, at 4:30 PM, Gerald Pfeifer wrote: >=20 >> On Thu, 13 Apr 2017, Pedro Giffuni wrote: >>> I didn=E2=80=99t want to get into this but the problem is that as = part of it's >>> build/bootstrapping process, GCC historically takes system headers >>> and attempts to =E2=80=9Cfix=E2=80=9D them. I am unsure the fixes do = anything at all >>> nowadays but the effect is that the compiler tends to take snapshots >>> of the system headers when it is built. cdefs.h is used by all the >>> system headers so changes in cdefs.h have good chances affecting >>> such builds but any change are likely to cause similar trouble. >>>=20 >>> In the case of gcc-aux, it appears the compilation is based on a >>> bootstrap compiler which already carries outdated headers. >>> A workaround, suggested by gerald@ the last time a similar issue >>> happened was to run for install-tools/fixinc.sh. I think that may >>> regenerate the headers and let the build use updated headers. >>> Ultimately gcc-aux needs maintainer intervention and using >>> outdated headers will break sooner or later: especially on -current. >>=20 >> Indeed, thanks for the analysis/background, Pedro! >>=20 >> I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6, >> and perhaps John (as the maintainer of that port) has plans to update >> it? Let me copy him. >=20 > [As I have a prior E-mail exchange with John M. indicating that > he was not intending to be the lang/gcc6-aux maintainer, I > avoid spamming him with this material: I've removed him from > the CC list in this reply. I can send the material to him if I > see evidence of his wanting it.] >=20 > Just FYI: >=20 > [Previously: temporarily adding __nonnull and __nonnull_all > back into into my local head FreeBSD variant got problems > with: __vm_ooffset_t and __vm_pindex_t no longer existing and > also the same pid_t issue indicated below.] >=20 >=20 > I tried using [on a Pine64+ 2GB aarch64 system]: >=20 > # = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/libexec/gcc/aarc= h64-aux-freebsd12.0/6.3.1/install-tools/mkheaders = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap >=20 > to deal with __nonnull, __nonnull_all, __vm_ooffset_t, and = __vm_pindex_t. >=20 > I then built via portmaster -CDK usage. Various header issues > did go away but the build of lang/gcc6-aux still stopped with: >=20 > In file included from = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c:20:0: > ./config.h:556:15: error: two or more data types in declaration = specifiers > #define pid_t int > ^ >=20 > I'm guessing that the define for pid_t in config.h resulted > in something like: >=20 > typedef ??? pid_t; >=20 > that turned into something like a: >=20 > typedef ??? int; >=20 > for the error listed above. >=20 > There were also implicit-declaration warnings: >=20 > = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c: In function 'simple_object_internal_read': > = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c:75:21: warning: implicit declaration of function 'read' = [-Wimplicit-function-declaration] > ssize_t got =3D read (descriptor, buffer, size); > ^~~~ > = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c: In function 'simple_object_internal_write': > = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c:119:23: warning: implicit declaration of function 'write' = [-Wimplicit-function-declaration] > ssize_t wrote =3D write (descriptor, buffer, size); > ^~~~~ >=20 > The implicit-declaration warnings for read and write may well > also not be expected/desirable. >=20 > It may be that more than a script run is needed to make > things be appropriate. Is there a reason why you need ada support (that seems to be the = only real reason for installing gcc6 vs gcc6-aux)? gcc6-aux uses a = snapshot of gcc6 with custom options. Thanks! -Ngie --Apple-Mail=_534C68CC-3A27-411C-AB28-2AACB66F40B1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY8Y56AAoJEPWDqSZpMIYVCqUQAJ3/RIVZHjUlbjtlq+eCNLiZ fk4l21s7AFvgMtRsqSulnEjPQywT+kcq/BIZUr7r+J9KRqIWu8uBIeZQ3znciXbS zH8LEfJFl/2Xy1ixCE3nJ1e4v/kP4CgeKLtiNVz4PgxA0rcqgucQLqWApC4QaRPl xe7/lLOTn1j9As4YaNErasU55JSzmlvGEQQb4HAKIR+/CX9qofekwj8cqtsdy7Bt dQ93H3HPVsJRHSbPDYt4zWfbGC//PZM28nEWVNguVKI21XIz68oToB9mWPdF7QVM qWCB7OfDoVHclKk4dmdNJe3Qz/qhDdYJQQd2T8i6q9qHE4xxuuTLlKx5J8KAxohd oM7ZEbqBMtddJA35g1nGwhBnIqcOITho+aDMaANYo7ykEUNpY2LFOtuxuBeSJpZ5 LgVXuRz4kopf4UHZ+XoNCI4EFWIFl/VpJd/rjpMkBgbn/Olu+6tNIyy6tZUB5BPn Cchu+5lmRaqTVtjjFbc0QS/SdXlRnoz2MA+xd+CvI2TDFXdoDS+amUU2keOPvkS+ nOb0h5exvPecvlnhhVQPgmLRnl6SJ4+N6MBt5l7Zfp5nc9lUMMK+1xo48guPd4E8 mLgozotLhXZIcRECl++g5dCm7x+7pYN/4+VHM9jd4YiRvZnnABj4+XaNlovukQAR yVjX49cZnKiT2FVMK3d5 =jZS8 -----END PGP SIGNATURE----- --Apple-Mail=_534C68CC-3A27-411C-AB28-2AACB66F40B1-- From owner-freebsd-arm@freebsd.org Sat Apr 15 03:27:32 2017 Return-Path: Delivered-To: freebsd-arm@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 77B0AD3E3FB for ; Sat, 15 Apr 2017 03:27:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-43.reflexion.net [208.70.210.43]) (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 260BBA43 for ; Sat, 15 Apr 2017 03:27:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13827 invoked from network); 15 Apr 2017 03:27:30 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Apr 2017 03:27:30 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 14 Apr 2017 23:27:30 -0400 (EDT) Received: (qmail 20674 invoked from network); 15 Apr 2017 03:27:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Apr 2017 03:27:30 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7AFFEEC8B57; Fri, 14 Apr 2017 20:27:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) From: Mark Millard In-Reply-To: <7606F976-20B7-4FB8-BE80-C27773F5529A@gmail.com> Date: Fri, 14 Apr 2017 20:27:29 -0700 Cc: Gerald Pfeifer , Pedro Giffuni , FreeBSD Ports , FreeBSD Toolchain , freebsd-arm , ericturgeon.bsd@gmail.com, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> <7606F976-20B7-4FB8-BE80-C27773F5529A@gmail.com> To: "Ngie Cooper (yaneurabeya)" X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 03:27:32 -0000 On 2017-Apr-14, at 8:07 PM, Ngie Cooper (yaneurabeya) wrote: > Is there a reason why you need ada support (that seems to be the = only real reason for installing gcc6 vs gcc6-aux)? gcc6-aux uses a = snapshot of gcc6 with custom options. > Thanks! > -Ngie I got to lang/gcc6-aux indirectly: I saw the ports checkin notice and github information for ports-mgmt/synth indicating that native aarch64 support was now in place/possible. When I looked at what pkg would provide it was older. So on a Pine64+ 2GB [an aarch64 context] I did an svnlite update for /usr/ports and then tried to build ports-mgmt/synth . Synth is written in ada and so indirectly then attempts a lang/gcc6-aux build if it is not already in place. [gcc5-aux likely would not support aarch64.] I've no direct interest in lang/gcc6-aux or ada as stands. But indirectly such is involved in what I wanted to explore. I've seen material quoted from a exp-run that reported that about 54(?) ports were then blocked by lang/gcc6-aux not building. (So some problems might not be aarch64 specific despite my example context: the "54" material was likely not for an aarch64 context.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sat Apr 15 09:30:20 2017 Return-Path: Delivered-To: freebsd-arm@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 351F7D3F996; Sat, 15 Apr 2017 09:30:20 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "StartCom Class 2 IV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 08FB71A5; Sat, 15 Apr 2017 09:30:19 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 030211F81; Sat, 15 Apr 2017 04:30:12 -0500 (CDT) Date: Sat, 15 Apr 2017 04:30:10 -0500 From: Mark Linimon To: Mark Millard Cc: "Ngie Cooper (yaneurabeya)" , Gerald Pfeifer , FreeBSD Ports , FreeBSD Current , FreeBSD Toolchain , freebsd-arm , Pedro Giffuni , ericturgeon.bsd@gmail.com Subject: Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) Message-ID: <20170415093010.GA4104@lonesome.com> References: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> <7606F976-20B7-4FB8-BE80-C27773F5529A@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 09:30:20 -0000 On Fri, Apr 14, 2017 at 08:27:29PM -0700, Mark Millard wrote: > I've seen material quoted from a exp-run that reported > that about 54(?) ports were then blocked by lang/gcc6-aux > not building. Although the first is an older run (the last complete run IIUC), there were 50 and 51 respectively as of: http://thunderx1.nyi.freebsd.org/build.html?mastername=110arm64-default&build=423029 http://beefy8.nyi.freebsd.org/build.html?mastername=head-armv6-default&build=p437390_s316341 I think you're fairly deep into unexplored territory here. mcl