From owner-freebsd-arm@freebsd.org Sun Dec 3 10:15:26 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 9EA9EDF68D1 for ; Sun, 3 Dec 2017 10:15:26 +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 8D712738A3 for ; Sun, 3 Dec 2017 10:15:26 +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 vB3AFQCr085672 for ; Sun, 3 Dec 2017 10:15:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 224050] RPI-B: 11-STABLE cannot mount root Date: Sun, 03 Dec 2017 10:15:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: freebsd@oldach.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: 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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 10:15:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224050 Bug ID: 224050 Summary: RPI-B: 11-STABLE cannot mount root Product: Base System Version: 11.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: freebsd@oldach.net Created attachment 188488 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D188488&action= =3Dedit 11-STABLE boot log With the latest FreeBSD-11.1-STABLE-arm-armv6-RPI-B-20171130-r326381.img, mountroot /dev/ufs/rootfs fails. See attached log. With FreeBSD-11.1-RELEASE-arm-armv6-RPI-B.img it works fine. It seems the recent changes to the u-boot-rpi2 / rpi-firmware infrastructure broke things? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Dec 4 03:31:05 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 9F88CDEB9DF for ; Mon, 4 Dec 2017 03:31:05 +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 8D7D7760A9 for ; Mon, 4 Dec 2017 03:31:05 +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 vB43V55C043619 for ; Mon, 4 Dec 2017 03:31:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 224070] [patch] workaround boot-time panic on Orange Pi + 2E Date: Mon, 04 Dec 2017 03:31:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords bug_severity priority component assigned_to reporter attachments.created Message-ID: 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.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 03:31:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224070 Bug ID: 224070 Summary: [patch] workaround boot-time panic on Orange Pi + 2E Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Keywords: patch Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: linimon@FreeBSD.org Keywords: patch Created attachment 188509 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D188509&action= =3Dedit patch to a10_codec.c This hack allows me to bring the Orange Pi + 2E up to multiuser. This is a workaround for what is probably an error in the dtb. Note: you still don't get Ethernet with this patch; that's a separate probl= em and apparently common to our Orange Pi support. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Dec 4 11:26: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 47EA3DF913F; Mon, 4 Dec 2017 11:26:51 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 18AFD63DCF; Mon, 4 Dec 2017 11:26:50 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [10.0.0.69] (host81-149-102-120.in-addr.btopenworld.com [81.149.102.120]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 850424EBD3; Mon, 4 Dec 2017 11:26:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Booting UEFI ZFS is broken on arm64 From: Andrew Turner In-Reply-To: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> Date: Mon, 4 Dec 2017 11:26:42 +0000 Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <87F57386-EE82-4DA4-AFB4-9D90ED1FA1BC@fubar.geek.nz> References: <20171130002135.q7p27hh6qkog4slr@mutt-hbsd> To: Shawn Webb X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 11:26:51 -0000 > On 30 Nov 2017, at 00:21, Shawn Webb wrote: > > It appears that in the latest FreeBSD 12-CURRENT/arm64 snapshot, > booting UEFI GPT ZFS on my OverDrive 1000 is broken. It boots up to > this line: > > Using DTB provided by EFI at 0x801fe00000. > > Then all output stops. I'm in the process of building a custom install > ISO that has DEBUG turned on in the fdt code. I hope to report back > soon-ish, unless anyone else has any ideas as to what could be wrong. This should be fixed in r326525. Andrew From owner-freebsd-arm@freebsd.org Wed Dec 6 05:58:04 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 E8D2EE930DC for ; Wed, 6 Dec 2017 05:58:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-140.reflexion.net [208.70.210.140]) (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 AB5156493B for ; Wed, 6 Dec 2017 05:58:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14130 invoked from network); 6 Dec 2017 05:57:57 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 6 Dec 2017 05:57:57 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Wed, 06 Dec 2017 00:57:57 -0500 (EST) Received: (qmail 18392 invoked from network); 6 Dec 2017 05:57:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Dec 2017 05:57:57 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A135AEC8B7B; Tue, 5 Dec 2017 21:57:56 -0800 (PST) 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: rpi2 hangup during poudriere build: lots of pfault wmseg status Message-Id: <05BEA04B-249B-4E7D-855A-46DA1A0DEA16@dsl-only.net> Date: Tue, 5 Dec 2017 21:57:56 -0800 To: Freebsd-arm , freebsd-hackers , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 05:58:05 -0000 I tried to build some ports on a rpi2 (via poudriere) but it hung up: Ethernet and normal console use. (Note: the root file system is on a USB SSD and the swap partition is also on that USB SSD.) But ~^b worked for getting to the db> prompt on the console. =46rom there a ps suggests that it got hung up in pfault activity. (Possibly insufficient RAM+swap-partition space?) But it is not clear to me that it should end up hung up vs. killing processes or other such. db> ps pid ppid pgrp uid state wmesg wchan cmd 36369 36770 36588 0 D+ pfault 0xc0832880 sh 36368 36770 36588 0 D+ pfault 0xc0832880 awk 36367 36770 36588 0 D+ pfault 0xc0832880 awk 36353 88873 36588 0 D+J pfault 0xc0832880 gmake 35115 35107 36588 0 D+J pfault 0xc0832880 ld 35107 76552 36588 0 SW+J wait 0xc4a52398 c++ 35071 35066 36588 0 D+J pfault 0xc0832880 ld 35066 76552 36588 0 SW+J wait 0xc64d6730 c++ 35047 35036 36588 0 D+J pfault 0xc0832880 ld 35036 76552 36588 0 SW+J wait 0xc5efc000 c++ 88873 88868 36588 0 S+J select 0xc5ea0b24 gmake 88868 88867 36588 0 SW+J wait 0xc3da1ac8 sh 88867 88674 36588 0 SW+J wait 0xc5904398 gmake 88674 28839 36588 0 SW+J wait 0xc66e4730 gmake 76552 76450 36588 0 SW+J wait 0xc5eb5ac8 gmake 76450 76438 36588 0 SW+J wait 0xc3aa2730 sh 76438 76380 36588 0 SW+J wait 0xc64d6000 gmake 76380 28839 36588 0 SW+J wait 0xc66e4ac8 gmake 28839 28828 36588 0 SW+J wait 0xc5f78ac8 gmake 28828 28826 36588 0 SW+J wait 0xc4a52000 sh 28826 28825 36588 0 SW+J wait 0xc5eb5398 gmake 28825 28793 36588 0 SW+J wait 0xc5c5d730 sh 28793 28792 36588 0 SW+J wait 0xc4262ac8 make 28792 23997 36588 0 SW+ wait 0xc56fb000 sh 23997 36588 36588 0 D+ pfault 0xc0832880 sh 40786 36588 36588 0 S+ piperd 0xc422c5b8 sh 36770 36588 36588 0 S+ wait 0xc5f78000 sh 36588 748 36588 0 D+ pfault 0xc0832880 sh 36387 748 36387 0 TW+ vi 748 747 748 0 SW+ wait 0xc4205000 sh 747 741 747 1001 SW+ wait 0xc4261398 su 741 740 741 1001 SWs+ wait 0xc3da0000 sh 740 737 737 1001 S select 0xc4227524 sshd 737 670 737 0 Ss select 0xc42275a4 sshd 723 722 723 0 D+ pfault 0xc0832880 sh 722 1 722 0 SWs+ wait 0xc4260398 login 721 1 721 0 Ss+ ttyin 0xc39d9474 getty 674 1 674 0 ?Ws cron 670 1 670 0 Ds pfault 0xc0832880 sshd 639 1 639 0 Ss select 0xc4227724 powerd 636 1 636 0 Ss (threaded) ntpd 100106 S select 0xc4227764 ntpd 588 587 587 0 S (threaded) nfsd 100098 S rpcsvc 0xc42ecc50 nfsd: master 100110 S rpcsvc 0xc3995250 nfsd: service 100111 S rpcsvc 0xc41721d0 nfsd: service 100112 S rpcsvc 0xc4171d50 nfsd: service 100113 S rpcsvc 0xc39952d0 nfsd: service 100114 S rpcsvc 0xc41725d0 nfsd: service 100115 S rpcsvc 0xc4171dd0 nfsd: service 100116 S rpcsvc 0xc39956d0 nfsd: service 100117 S rpcsvc 0xc3995350 nfsd: service 100118 S rpcsvc 0xc4172550 nfsd: service 100119 S rpcsvc 0xc3995750 nfsd: service 100120 S rpcsvc 0xc41726d0 nfsd: service 100121 S rpcsvc 0xc39953d0 nfsd: service 100122 S rpcsvc 0xc4172650 nfsd: service 100123 S rpcsvc 0xc41723d0 nfsd: service 100124 S rpcsvc 0xc4172450 nfsd: service 100125 S rpcsvc 0xc3995450 nfsd: service 100126 S rpcsvc 0xc4171cd0 nfsd: service 100127 S rpcsvc 0xc4172350 nfsd: service 100128 S rpcsvc 0xc41724d0 nfsd: service 100129 S rpcsvc 0xc39954d0 nfsd: service 100130 S rpcsvc 0xc4172250 nfsd: service 100131 S rpcsvc 0xc41720d0 nfsd: service 100132 S rpcsvc 0xc41722d0 nfsd: service 100133 S rpcsvc 0xc3995550 nfsd: service 100134 S rpcsvc 0xc4172050 nfsd: service 100135 S rpcsvc 0xc4171e50 nfsd: service 100136 S rpcsvc 0xc4172150 nfsd: service 100137 S rpcsvc 0xc39955d0 nfsd: service 100138 S rpcsvc 0xc4171f50 nfsd: service 100139 S rpcsvc 0xc4171ed0 nfsd: service 100140 S rpcsvc 0xc3995650 nfsd: service 587 1 587 0 Ss select 0xc42277a4 nfsd 585 1 585 0 Ss select 0xc4227624 mountd 455 1 455 0 Ss select 0xc4103d64 rpcbind 446 1 446 0 Ds pfault 0xc0832880 syslogd 375 1 375 0 Ss select 0xc4103fa4 devd 374 1 374 65 Ds pfault 0xc0832880 dhclient 328 1 328 0 Ss select 0xc4227f64 dhclient 325 1 325 0 Ss select 0xc3dec4e4 dhclient 31 0 0 0 DL vlruwt 0xc3da0730 [vnlru] 30 0 0 0 DL syncer 0xc095a6dc [syncer] 29 0 0 0 DL - 0xc095a0c8 [bufspacedaemon] 28 0 0 0 DL (threaded) [bufdaemon] 100070 D psleep 0xc0959fc0 [bufdaemon] 100092 D sdflush 0xc42ae884 [/ worker] 27 0 0 0 DL psleep 0xc095ecb4 [vmdaemon] 26 0 0 0 RL (threaded) [pagedaemon] 100068 RunQ [pagedaemon] 100074 D launds 0xc095ebb4 [laundry: dom0] 100075 D umarcl 0xc095e8fc [uma] 25 0 0 0 SL worker_ 0xc3757a90 = [bcm2835_audio_worke] 24 0 0 0 SL VCHI co 0xc3a9980c [VCHIQka-0] 23 0 0 0 DL mmcsd d 0xc3fe4800 [mmcsd0boot1: = mmc/sd] 22 0 0 0 DL mmcsd d 0xc3fe4a00 [mmcsd0boot0: = mmc/sd] 21 0 0 0 DL mmcsd d 0xc3fe4c00 [mmcsd0: mmc/sd = card] 20 0 0 0 DL - 0xc0959c34 [soaiod4] 19 0 0 0 DL - 0xc0959c34 [soaiod3] 18 0 0 0 DL - 0xc0959c34 [soaiod2] 17 0 0 0 DL - 0xc0959c34 [soaiod1] 16 0 0 0 DL - 0xc0841298 [rand_harvestq] 15 0 0 0 DL waiting 0xc0968ef0 [sctp_iterator] 14 0 0 0 DL (threaded) [usb] 100049 D - 0xc3a9f02c [usbus0] 100050 D - 0xc3a9f05c [usbus0] 100051 D - 0xc3a9f08c [usbus0] 100052 D - 0xc3a9f0bc [usbus0] 100053 D - 0xc3a9f0ec [usbus0] 100067 D - 0xc3a5d428 [smsc0] 13 0 0 0 SL sema cv 0xc0980d80 [VCHIQs-0] 9 0 0 0 SL sema cv 0xc0980d5c [VCHIQr-0] 8 0 0 0 SL sema cv 0xc0980d38 [VCHIQ-0] 7 0 0 0 DL (threaded) [cam] 100031 D - 0xc083e140 [doneq0] 100057 D - 0xc083e06c [scanner] 6 0 0 0 DL crypto_ 0xc39b50c4 [crypto returns 3] 5 0 0 0 DL crypto_ 0xc39b508c [crypto returns 2] 4 0 0 0 DL crypto_ 0xc39b5054 [crypto returns 1] 3 0 0 0 DL crypto_ 0xc39b501c [crypto returns 0] 2 0 0 0 DL crypto_ 0xc095e23c [crypto] 12 0 0 0 DL (threaded) [geom] 100018 D - 0xc0967758 [g_event] 100019 D - 0xc096775c [g_up] 100020 D - 0xc0967760 [g_down] 11 0 0 0 WL (threaded) [intr] 100006 I [swi6: Giant taskq] 100009 I [swi5: fast taskq] 100011 I [swi6: task queue] 100012 I [swi4: clock (0)] 100013 I [swi4: clock (1)] 100014 I [swi4: clock (2)] 100015 I [swi4: clock (3)] 100016 I [swi3: vm] 100017 I [swi1: netisr 0] 100032 I [intc0,69: bcmrng0] 100033 I [intc0,61: iichb0+] 100034 I [intc0,62: spi0] 100035 I [intc0,28: = bcm_dma0] 100036 I [intc0,29: = bcm_dma0] 100037 I [intc0,32: = bcm_dma0] 100038 I [intc0,33: = bcm_dma0] 100039 I [intc0,34: = bcm_dma0] 100040 I [intc0,35: = bcm_dma0] 100041 I [intc0,1: mbox0] 100042 I [intc0,70: +] 100043 I [swi0: uart] 100044 I [intc0,2: vchiq0] 100048 I [intc0,17: +] 10 0 0 0 RL (threaded) [idle] 100002 Run CPU 0 [idle: cpu0] 100003 Run CPU 1 [idle: cpu1] 100004 CanRun [idle: cpu2] 100005 Run CPU 3 [idle: cpu3] 1 0 1 0 SLs wait 0xc38b5000 [init] 0 0 0 0 RLs (threaded) [kernel] 100000 D vmwait 0xc0832880 [swapper] 100007 D - 0xc38ada00 [thread taskq] 100008 D - 0xc38ad980 [aiod_kick taskq] 100010 D - 0xc38ad880 [kqueue_ctx taskq] 100021 D - 0xc38ad780 [firmware taskq] 100022 D - 0xc38ad700 [crypto_0] 100023 D - 0xc38ad700 [crypto_1] 100024 D - 0xc38ad700 [crypto_2] 100025 D - 0xc38ad700 [crypto_3] 100056 D - 0xc38ad680 [CAM taskq] 100076 D - 0xc3fa1f00 [if_config_tqg_0] 100077 D - 0xc40c4100 [softirq_0] 100078 D - 0xc40c4080 [softirq_1] 100079 RunQ [softirq_2] 100080 D - 0xc40c3f00 [softirq_3] 100081 D - 0xc3fa1e00 [if_io_tqg_0] 100082 D - 0xc3fa1d80 [if_io_tqg_1] 100083 RunQ [if_io_tqg_2] 100084 D - 0xc3fa1c80 [if_io_tqg_3] Exploring some commands. . . db> show pageq pq_free 599 dom 0 page_cnt 205724 free 599 pq_act 160929 pq_inact 3178 pq_laund 0 = pq_unsw 0 db> show page vm_cnt.v_free_count: 599 vm_cnt.v_inactive_count: 3178 vm_cnt.v_active_count: 160929 vm_cnt.v_laundry_count: 0 vm_cnt.v_wire_count: 41018 vm_cnt.v_free_reserved: 333 vm_cnt.v_free_min: 1360 vm_cnt.v_free_target: 4441 vm_cnt.v_inactive_target: 6661 db> show freepages DOMAIN: 0 FREE LIST 0: ORDER (SIZE) | NUMBER | POOL 0 -- -- -- -- 08 (001024K) | 000000 07 (000512K) | 000000 06 (000256K) | 000000 05 (000128K) | 000002 04 (000064K) | 000000 03 (000032K) | 000000 02 (000016K) | 000001 01 (000008K) | 000001 00 (000004K) | 000002 db> show allpcpu Current CPU: 0 cpuid =3D 0 dynamic pcpu =3D 0x3d3f00 curthread =3D 0xc38b8ae0: pid 10 tid 100002 "idle: cpu0" curpcb =3D 0xe4c6de98 fpcurthread =3D 0xc4267ae0: pid 639 "powerd" idlethread =3D 0xc38b8ae0: tid 100002 "idle: cpu0" curpmap =3D 0xc0967fa4 curvnet =3D 0 cpuid =3D 1 dynamic pcpu =3D 0x13accf00 curthread =3D 0xc38b8740: pid 10 tid 100003 "idle: cpu1" curpcb =3D 0xe4c70e98 fpcurthread =3D 0xc4028740: pid 636 "ntpd" idlethread =3D 0xc38b8740: tid 100003 "idle: cpu1" curpmap =3D 0xc0967fa4 curvnet =3D 0 cpuid =3D 2 dynamic pcpu =3D 0x13acdf00 curthread =3D 0xc38b83a0: pid 10 tid 100004 "idle: cpu2" curpcb =3D 0xe4c73e98 fpcurthread =3D none idlethread =3D 0xc38b83a0: tid 100004 "idle: cpu2" curpmap =3D 0 curvnet =3D 0 cpuid =3D 3 dynamic pcpu =3D 0x24426f00 curthread =3D 0xc38b8000: pid 10 tid 100005 "idle: cpu3" curpcb =3D 0xe4c76e98 fpcurthread =3D 0xc4267ae0: pid 639 "powerd" idlethread =3D 0xc38b8000: tid 100005 "idle: cpu3" curpmap =3D 0xc0967fa4 curvnet =3D 0 db>=20 At one point before the hangup top -CawPores showed: Mem: 8308K Active, 363M Inact, 11M Laundry, 168M Wired, 88M Buf, 253M = Free Swap: 1536M Total, 1244K Used, 1535M Free Sometime before it hung up there was: # poudriere status SET PORTS JAIL BUILD STATUS QUEUE BUILT = FAIL SKIP IGNORE REMAIN TIME LOGS - default FBSDjailRPI2 2017-12-03_20h38m29s parallel_build 87 32 = 0 0 0 55 04:32:21 = /usr/local/poudriere/data/logs/bulk/FBSDjailRPI2-default/2017-12-03_20h38m= 29s The end of the poudriere output looked like: . . . [07:59:07] [01] [00:00:00] Building sysutils/dtc | dtc-1.4.5 [08:00:12] [01] [00:01:05] Saved sysutils/dtc | dtc-1.4.5 wrkdir to: = /usr/local/poudriere/data/wrkdirs/FBSDjailRPI2-default/default/dtc-1.4.5.t= bz [08:00:14] [01] [00:01:07] Finished sysutils/dtc | dtc-1.4.5: Failed: = build [08:00:14] [01] [00:01:07] Skipping sysutils/u-boot-rpi2 | = u-boot-rpi2-2017.09.00: Dependent port sysutils/dtc | dtc-1.4.5 failed [08:00:15] [01] [00:00:00] Building devel/binutils | binutils-2.28,1 (It looks like a rpi2 does not build its own sysutils/u-boot-rpi2 .) The world and kernel were head -r326192: FreeBSD 12.0-CURRENT r326192M arm FreeBSD clang vers 5.0.0svn) (M is mostly from some powerpc64 and powerpc material: I build the same source for everything generally.) /usr/ports for the ports build was at -r455204 (last before FLAVORS being enabled). I historically have not built ports on a rpi2. So this is not a comparison with past results. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Dec 6 09:45:06 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 93A29E9AB9A for ; Wed, 6 Dec 2017 09:45:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-95.reflexion.net [208.70.210.95]) (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 524AC6ABE9 for ; Wed, 6 Dec 2017 09:45:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23736 invoked from network); 6 Dec 2017 09:45:04 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 6 Dec 2017 09:45:04 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Wed, 06 Dec 2017 04:45:04 -0500 (EST) Received: (qmail 24470 invoked from network); 6 Dec 2017 09:45:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Dec 2017 09:45:04 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3677BEC8675; Wed, 6 Dec 2017 01:45:03 -0800 (PST) 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: For armv7 (cross build target): multimedia/libvpx depends on the GNU C library function getauxval and so fails to build; so, disable its expectation? Message-Id: Date: Wed, 6 Dec 2017 01:45:02 -0800 To: Freebsd-arm , FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 09:45:06 -0000 For armv7 attempting to build multimedia/libvpx (via an indirect dependency) leads to: cp libvpx_g.a libvpx.a vpx_ports/arm_cpudetect.c.o: In function `arm_cpu_caps': = /wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.6.1/vpx_ports/arm_cpude= tect.c:198: undefined reference to `getauxval' c++: error: linker command failed with exit code 1 (use -v to see = invocation) gmake[2]: *** [Makefile:384: libvpx.so.4.1.0] Error 1 gmake[1]: *** [Makefile:17: .DEFAULT] Error 2 gmake[1]: Leaving directory = '/wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.6.1' =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to the maintainer. *** Error code 1 The arm_cpudetect.c code looks like it expects for FreeBSD to define getauxval (but it does not) and has alternate code it uses if is not available: . . . #elif defined(__FreeBSD__) =20 #if __has_include() #include #else #include #include #include #include #include =20 static unsigned long getauxval(unsigned long type) { Elf_Auxinfo auxv[AT_COUNT]; size_t len =3D sizeof(auxv); int mib[] =3D { CTL_KERN, KERN_PROC, KERN_PROC_AUXV, getpid(), }; if (sysctl(mib, nitems(mib), auxv, &len, NULL, 0) !=3D -1) { for (size_t i =3D 0; i < nitems(auxv); i++) if ((unsigned long)auxv[i].a_type =3D=3D type) return auxv[i].a_un.a_val; errno =3D ENOENT; } return 0; } #endif #ifndef AT_HWCAP #define AT_HWCAP 25 /* 16 on Linux */ #endif =20 #ifndef HWCAP_NEON #define HWCAP_NEON (1 << 12) #endif =20 int arm_cpu_caps(void) { int flags; int mask; unsigned long hwcaps; if (!arm_cpu_env_flags(&flags)) { return flags; } mask =3D arm_cpu_env_mask(); hwcaps =3D getauxval(AT_HWCAP); #if HAVE_NEON || HAVE_NEON_ASM if (hwcaps & HWCAP_NEON) flags |=3D HAS_NEON; #endif return flags & mask; } . . . has: # more /usr/include/sys/auxv.h=20 . . . #ifndef _SYS_AUXV_H_ #define _SYS_AUXV_H_ #include #include __BEGIN_DECLS int elf_aux_info(int aux, void *buf, int buflen); __END_DECLS #endif /* !_SYS_AUXV_H_ */ # grep -r getauxval /usr/src/* | more /usr/src/contrib/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc: = return getauxval(AT_PAGESZ); /usr/src/contrib/compiler-rt/lib/scudo/scudo_utils.cpp: uptr HWCap =3D = getauxval(AT_HWCAP); = /usr/src/contrib/compiler-rt/lib/dfsan/libc_ubuntu1404_abilist.txt:fun:__g= etauxval=3Duninstrumented = /usr/src/contrib/compiler-rt/lib/dfsan/libc_ubuntu1404_abilist.txt:fun:get= auxval=3Duninstrumented /usr/src/contrib/unbound/compat/getentropy_linux.c: p =3D = (char *) getauxval(AT_RANDOM); /usr/src/contrib/unbound/compat/getentropy_linux.c: p =3D = (char *) getauxval(AT_SYSINFO_EHDR); /usr/src/contrib/unbound/compat/getentropy_linux.c: p =3D = (char *) getauxval(AT_BASE); /usr/src/contrib/unbound/config.h.in:/* Define to 1 if you have the = `getauxval' function. */ /usr/src/contrib/unbound/configure.ac: = AC_CHECK_FUNCS([getauxval]) /usr/src/contrib/unbound/doc/Changelog: - getauxval test for ppc64 linux = compatibility. /usr/src/contrib/unbound/configure: for = ac_func in getauxval /usr/src/contrib/unbound/configure: ac_fn_c_check_func "$LINENO" = "getauxval" "ac_cv_func_getauxval" /usr/src/contrib/unbound/configure:if test "x$ac_cv_func_getauxval" =3D = xyes; then : /usr/src/contrib/unbound/config.h:/* Define to 1 if you have the = `getauxval' function. */ /usr/src/crypto/openssl/crypto/armcap.c: * Use a weak reference to = getauxval() so we can use it if it is available but /usr/src/crypto/openssl/crypto/armcap.c:extern unsigned long = getauxval(unsigned long type) __attribute__ ((weak)); /usr/src/crypto/openssl/crypto/armcap.c:static unsigned long = (*getauxval) (unsigned long) =3D NULL; /usr/src/crypto/openssl/crypto/armcap.c: if (getauxval !=3D NULL) { /usr/src/crypto/openssl/crypto/armcap.c: if (getauxval(HWCAP) & = HWCAP_NEON) { /usr/src/crypto/openssl/crypto/armcap.c: unsigned long hwcap = =3D getauxval(HWCAP_CE); =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Wed Dec 6 17:37:29 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 F3701E865F9; Wed, 6 Dec 2017 17:37:28 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CEEAA7AEFE; Wed, 6 Dec 2017 17:37:28 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 0C7B3E59F; Wed, 6 Dec 2017 17:37:28 +0000 (UTC) From: Jan Beich To: Mark Millard Cc: Freebsd-arm , FreeBSD Ports Subject: Re: For armv7 (cross build target): multimedia/libvpx depends on the GNU C library function getauxval and so fails to build; so, disable its expectation? References: Date: Wed, 06 Dec 2017 18:37:10 +0100 In-Reply-To: (Mark Millard's message of "Wed, 6 Dec 2017 01:45:02 -0800") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 17:37:29 -0000 Mark Millard writes: > For armv7 attempting to build multimedia/libvpx > (via an indirect dependency) leads to: > > cp libvpx_g.a libvpx.a > vpx_ports/arm_cpudetect.c.o: In function `arm_cpu_caps': > /wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.6.1/vpx_ports/arm_cpudetect.c:198: undefined reference to `getauxval' > c++: error: linker command failed with exit code 1 (use -v to see invocation) > gmake[2]: *** [Makefile:384: libvpx.so.4.1.0] Error 1 > gmake[1]: *** [Makefile:17: .DEFAULT] Error 2 > gmake[1]: Leaving directory '/wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.6.1' > ===> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > the maintainer. > *** Error code 1 > > > > The arm_cpudetect.c code looks like it expects > for FreeBSD to define getauxval (but it does not) and > has alternate code it uses if is not > available: Correct. I've expected FreeBSD to either implement its own helper and put it somewhere like or mimic GNU. What actually happened is something in-between which tends to break existing code e.g., AC_CHECK_HEADERS([sys/auxv.h]) #ifdef HAVE_SYS_AUXV_H unsigned long hwcap = getauxval(AT_HWCAP); ... #endif in https://github.com/mono/mono/blob/9ba3fa0ba37c/mono/utils/mono-hwcap-arm.c#L41 base r324815 has questionable rationale for not using getauxval() because if AT_FOO is not supported or doesn't make sense on FreeBSD one can just #ifdef it out. As you've noticed Linux folks rarely use getauxval() outside of AT_HWCAP. Some AT_* are compatible, some have different name, some are specific to Linux or FreeBSD. Now we have elf_aux_info() which is not documented. Go figure how to use it properly and avoid introducing bugs specific to FreeBSD. Makes one wonder why FreeBSD didn't choose sysctl to expose ARM capabilities like hw.cpu_features (on powerpc*) if portability was out of scope. From owner-freebsd-arm@freebsd.org Wed Dec 6 18:08: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 CA5BBE87BD4 for ; Wed, 6 Dec 2017 18:08:36 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 AB81C7C4F5 for ; Wed, 6 Dec 2017 18:08:36 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 5efd214d-dab0-11e7-b1c3-712f93d8ba90 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 5efd214d-dab0-11e7-b1c3-712f93d8ba90; Wed, 06 Dec 2017 18:07:50 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vB6I8T2L006547; Wed, 6 Dec 2017 11:08:29 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1512583709.58601.49.camel@freebsd.org> Subject: Re: For armv7 (cross build target): multimedia/libvpx depends on the GNU C library function getauxval and so fails to build; so, disable its expectation? From: Ian Lepore To: Jan Beich , Mark Millard Cc: Freebsd-arm , FreeBSD Ports Date: Wed, 06 Dec 2017 11:08:29 -0700 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 18:08:36 -0000 On Wed, 2017-12-06 at 18:37 +0100, Jan Beich wrote: > Mark Millard writes: > > > > > For armv7 attempting to build multimedia/libvpx > > (via an indirect dependency) leads to: > > > > cp libvpx_g.a libvpx.a > > vpx_ports/arm_cpudetect.c.o: In function `arm_cpu_caps': > > /wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.6.1/vpx_ports/arm_cpudetect.c:198: undefined reference to `getauxval' > > c++: error: linker command failed with exit code 1 (use -v to see invocation) > > gmake[2]: *** [Makefile:384: libvpx.so.4.1.0] Error 1 > > gmake[1]: *** [Makefile:17: .DEFAULT] Error 2 > > gmake[1]: Leaving directory '/wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.6.1' > > ===> Compilation failed unexpectedly. > > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > > the maintainer. > > *** Error code 1 > > > > > > > > The arm_cpudetect.c code looks like it expects > > for FreeBSD to define getauxval (but it does not) and > > has alternate code it uses if is not > > available: > Correct. I've expected FreeBSD to either implement its own helper and > put it somewhere like or mimic GNU. What actually happened > is something in-between which tends to break existing code e.g., > >   AC_CHECK_HEADERS([sys/auxv.h]) > >   #ifdef HAVE_SYS_AUXV_H >          unsigned long hwcap = getauxval(AT_HWCAP); >   ... >   #endif > > in https://github.com/mono/mono/blob/9ba3fa0ba37c/mono/utils/mono-hwcap-arm.c#L41 > > base r324815 has questionable rationale for not using getauxval() > because if AT_FOO is not supported or doesn't make sense on FreeBSD one > can just #ifdef it out. As you've noticed Linux folks rarely use > getauxval() outside of AT_HWCAP. Some AT_* are compatible, some have > different name, some are specific to Linux or FreeBSD. > > Now we have elf_aux_info() which is not documented. Go figure how to use > it properly and avoid introducing bugs specific to FreeBSD. > > Makes one wonder why FreeBSD didn't choose sysctl to expose ARM > capabilities like hw.cpu_features (on powerpc*) if portability was out > of scope. It's my fault elf_aux_info() isn't documented yet. I agreed to write the manpage, then I got sick (for weeks) and haven't gotten anything much done in that time. I tend to agree about not providing a reasonably-compatible getauxval() function being a bad thing.  I think it would be fine to support a subset of the AT_* values linux supports, and we can add additional support as needs arise. -- Ian From owner-freebsd-arm@freebsd.org Wed Dec 6 22:04:26 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 CFC9FE8D44A; Wed, 6 Dec 2017 22:04:26 +0000 (UTC) (envelope-from laurent@nuxi.ca) Received: from mail.nuxi.ca (nuxi.ca [142.44.162.10]) by mx1.freebsd.org (Postfix) with ESMTP id AD4EC64455; Wed, 6 Dec 2017 22:04:26 +0000 (UTC) (envelope-from laurent@nuxi.ca) Received: from [192.168.0.174] (modemcable058.143-202-24.mc.videotron.ca [24.202.143.58]) (Authenticated sender: laurent) by mail.nuxi.ca (Postfix) with ESMTPSA id 87FD320967; Wed, 6 Dec 2017 16:54:37 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: rpi2 hangup during poudriere build: lots of pfault wmseg status From: Laurent Cimon In-Reply-To: <05BEA04B-249B-4E7D-855A-46DA1A0DEA16@dsl-only.net> Date: Wed, 6 Dec 2017 16:54:36 -0500 Cc: freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <05BEA04B-249B-4E7D-855A-46DA1A0DEA16@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 22:04:26 -0000 > On Dec 6, 2017, at 00:57, Mark Millard wrote: >=20 > I tried to build some ports on a rpi2 > (via poudriere) but it hung up: > Ethernet and normal console use. (Note: > the root file system is on a USB SSD > and the swap partition is also on that > USB SSD.) >=20 > But ~^b worked for getting to the db> > prompt on the console. >=20 > =46rom there a ps suggests that it got hung > up in pfault activity. (Possibly insufficient > RAM+swap-partition space?) But it is not > clear to me that it should end up hung up > vs. killing processes or other such. Hi, =46rom what I know the raspberry pis use the same controller for = ethernet and the USB hub on which you=E2=80=99re hosting an SSD. It seems like you = make very heavy use of the USB ports, and all of the resources used by poudriere except = for the CPU and the (very limited) memory that=E2=80=99s not in swap is attached = to them. If you really didn=E2=80=99t have enough memory and swap, the linkers = would=E2=80=99ve been stopped. I think it might just be a swap death. Poudriere compiles and fetches in = parallel a lot, ethernet and disk I/O is slow because it=E2=80=99s very limited, = so linking takes longer. You end up linking a few very big binaries at the same time, and = they all fight for the memory, to get out of swap through page faults, but = there are too many page faults, all too big, requesting for more CPU time = that=E2=80=99s allowed to them. This would explain why you have 3 linkers waiting on a page fault out of = the 4 CPUs poudriere allows builds on, on top of the awk processes. It would = also explain why you had easy access to the debugger: it was in memory = already with the kernel. I=E2=80=99d advise you to disable parallel builds and see if it happens = again, but it would make building much slower. Using makejobs would help if you can afford watching the build. Otherwise be patient, it should resolve = itself eventually, but it will take a while and it will happen again. Good luck, Laurent= From owner-freebsd-arm@freebsd.org Thu Dec 7 01:01:45 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 BC0E1E92F46 for ; Thu, 7 Dec 2017 01:01:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-100.reflexion.net [208.70.210.100]) (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 7B5246BF3A for ; Thu, 7 Dec 2017 01:01:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1764 invoked from network); 7 Dec 2017 01:01:38 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 7 Dec 2017 01:01:38 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Wed, 06 Dec 2017 20:01:38 -0500 (EST) Received: (qmail 11093 invoked from network); 7 Dec 2017 01:01:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Dec 2017 01:01:38 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D0409EC861A; Wed, 6 Dec 2017 17:01:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: rpi2 hangup during poudriere build: lots of pfault wmseg status From: Mark Millard In-Reply-To: Date: Wed, 6 Dec 2017 17:01:36 -0800 Cc: freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <36A8BDCC-4ECE-4187-8705-54A9E38E8AD5@dsl-only.net> References: <05BEA04B-249B-4E7D-855A-46DA1A0DEA16@dsl-only.net> To: Laurent Cimon X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 01:01:45 -0000 On 2017-Dec-6, at 1:54 PM, Laurent Cimon wrote: >> On Dec 6, 2017, at 00:57, Mark Millard = wrote: >>=20 >> I tried to build some ports on a rpi2 >> (via poudriere) but it hung up: >> Ethernet and normal console use. (Note: >> the root file system is on a USB SSD >> and the swap partition is also on that >> USB SSD.) >>=20 >> But ~^b worked for getting to the db> >> prompt on the console. >>=20 >> =46rom there a ps suggests that it got hung >> up in pfault activity. (Possibly insufficient >> RAM+swap-partition space?) But it is not >> clear to me that it should end up hung up >> vs. killing processes or other such. >=20 > Hi, >=20 > =46rom what I know the raspberry pis use the same controller for = ethernet and > the USB hub on which you=E2=80=99re hosting an SSD. It seems like you = make very heavy > use of the USB ports, and all of the resources used by poudriere = except for the > CPU and the (very limited) memory that=E2=80=99s not in swap is = attached to them. If you > really didn=E2=80=99t have enough memory and swap, the linkers = would=E2=80=99ve been stopped. >=20 > I think it might just be a swap death. Poudriere compiles and fetches = in parallel > a lot, ethernet and disk I/O is slow because it=E2=80=99s very = limited, so linking takes > longer. You end up linking a few very big binaries at the same time, = and they > all fight for the memory, to get out of swap through page faults, but = there > are too many page faults, all too big, requesting for more CPU time = that=E2=80=99s > allowed to them. >=20 > This would explain why you have 3 linkers waiting on a page fault out = of the 4 > CPUs poudriere allows builds on, on top of the awk processes. It would = also > explain why you had easy access to the debugger: it was in memory = already with > the kernel. >=20 > I=E2=80=99d advise you to disable parallel builds and see if it = happens again, > but it would make building much slower. Using makejobs would help if = you > can afford watching the build. Otherwise be patient, it should resolve = itself > eventually, but it will take a while and it will happen again. My post was more about how FreeBSD handled the heavy-use context and less about getting the builds to finish: it managed to to get to a state of no-progress for processes and a loss of normal control as far as I could tell. I did a "c" to ddb and left it until just before this note then did ~ ^B again. Things looked the same. [I've finally rebooted the rpi2.] PARALLEL_JOBS=3D1 was already in use but ALLOW_MAKE_JOBS=3Dyes was also in use. USE_TMPFS=3Dno was already in use. While an ssh session was monitoring the build, Ethernet was not in heavy use. (No nfs mounts to its disks, for example.) I may try without ALLOW_MAKE_JOBS=3Dyes and with ALLOW_MAKE_JOBS_PACKAGES empty/undefined to see if it can complete for such a context without having the same sort of problem. Ultimately I can cross-build and install from those materials when I really want updates. I have the context for such. This was more about seeing how well the rpi2 did for self-hosted. Classically I've used a BPI-M3 with 2 GiBytes of RAM and a proportionally bigger swap partition instead (approximately). FYI (rpi2 after rebooting): # swapinfo Device 1K-blocks Used Avail Capacity /dev/label/RPI2swap 1572860 0 1572860 0% # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/ufs/RPI2rootfs 195378 30791 148957 17% / devfs 0 0 0 100% /dev /dev/label/RPI2Aboot 49 12 37 25% /boot/msdos An rpi3 (aarch64) with the same amount of RAM, same type of USB SSD, etc., but well more swap completed building basically the same set of ports for the same poudriere settings just fine. Interestingly for the default kern.maxswzone: (Just to show the reported recommended maximum figures for swap.) rpi2: . . . exceeds maximum recommended amount (411488 pages). rpi3: . . . exceeds maximum recommended amount (925680 pages). (I was running with somewhat under those maximums for the tests.) # swapinfo Device 1K-blocks Used Avail Capacity /dev/gpt/RPI3swap 3702784 0 3702784 0% # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/ufs/RPI3rootfs 195378 14937 164811 8% / devfs 0 0 0 100% /dev /dev/label/RPI3Aboot 49 7 42 15% /boot/efi If I restricted the rpi3 to somewhat under what the rpi2 allows for swap, I do not know if it would also hang up vs. not. If having more swap makes the difference, then it would not seem to be being I/O-bound that would explain the hangup. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Dec 7 01:47:16 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 80ACDE95830; Thu, 7 Dec 2017 01:47:16 +0000 (UTC) (envelope-from laurent@nuxi.ca) Received: from mail.nuxi.ca (nuxi.ca [142.44.162.10]) by mx1.freebsd.org (Postfix) with ESMTP id 322B06E422; Thu, 7 Dec 2017 01:47:15 +0000 (UTC) (envelope-from laurent@nuxi.ca) Received: from [192.168.0.174] (modemcable058.143-202-24.mc.videotron.ca [24.202.143.58]) (Authenticated sender: laurent) by mail.nuxi.ca (Postfix) with ESMTPSA id 24575209E2; Wed, 6 Dec 2017 20:47:14 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: rpi2 hangup during poudriere build: lots of pfault wmseg status From: Laurent Cimon In-Reply-To: <36A8BDCC-4ECE-4187-8705-54A9E38E8AD5@dsl-only.net> Date: Wed, 6 Dec 2017 20:47:12 -0500 Cc: freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5014B6E6-68BA-4499-8728-EF80237F3269@nuxi.ca> References: <05BEA04B-249B-4E7D-855A-46DA1A0DEA16@dsl-only.net> <36A8BDCC-4ECE-4187-8705-54A9E38E8AD5@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 01:47:16 -0000 > On Dec 6, 2017, at 20:01, Mark Millard wrote: >=20 > On 2017-Dec-6, at 1:54 PM, Laurent Cimon wrote: >=20 >>> On Dec 6, 2017, at 00:57, Mark Millard = wrote: >>>=20 >>> I tried to build some ports on a rpi2 >>> (via poudriere) but it hung up: >>> Ethernet and normal console use. (Note: >>> the root file system is on a USB SSD >>> and the swap partition is also on that >>> USB SSD.) >>>=20 >>> But ~^b worked for getting to the db> >>> prompt on the console. >>>=20 >>> =46rom there a ps suggests that it got hung >>> up in pfault activity. (Possibly insufficient >>> RAM+swap-partition space?) But it is not >>> clear to me that it should end up hung up >>> vs. killing processes or other such. >>=20 >> Hi, >>=20 >> =46rom what I know the raspberry pis use the same controller for = ethernet and >> the USB hub on which you=E2=80=99re hosting an SSD. It seems like you = make very heavy >> use of the USB ports, and all of the resources used by poudriere = except for the >> CPU and the (very limited) memory that=E2=80=99s not in swap is = attached to them. If you >> really didn=E2=80=99t have enough memory and swap, the linkers = would=E2=80=99ve been stopped. >>=20 >> I think it might just be a swap death. Poudriere compiles and fetches = in parallel >> a lot, ethernet and disk I/O is slow because it=E2=80=99s very = limited, so linking takes >> longer. You end up linking a few very big binaries at the same time, = and they >> all fight for the memory, to get out of swap through page faults, but = there >> are too many page faults, all too big, requesting for more CPU time = that=E2=80=99s >> allowed to them. >>=20 >> This would explain why you have 3 linkers waiting on a page fault out = of the 4 >> CPUs poudriere allows builds on, on top of the awk processes. It = would also >> explain why you had easy access to the debugger: it was in memory = already with >> the kernel. >>=20 >> I=E2=80=99d advise you to disable parallel builds and see if it = happens again, >> but it would make building much slower. Using makejobs would help if = you >> can afford watching the build. Otherwise be patient, it should = resolve itself >> eventually, but it will take a while and it will happen again. >=20 > My post was more about how FreeBSD handled the > heavy-use context and less about getting the > builds to finish: it managed to to get to a > state of no-progress for processes and a loss > of normal control as far as I could tell. >=20 > I did a "c" to ddb and left it until just before > this note then did ~ ^B again. Things looked the > same. [I've finally rebooted the rpi2.] >=20 > PARALLEL_JOBS=3D1 was already in use but > ALLOW_MAKE_JOBS=3Dyes was also in use. > USE_TMPFS=3Dno was already in use. >=20 > While an ssh session was monitoring the > build, Ethernet was not in heavy use. > (No nfs mounts to its disks, for example.) >=20 > I may try without ALLOW_MAKE_JOBS=3Dyes and > with ALLOW_MAKE_JOBS_PACKAGES empty/undefined > to see if it can complete for such a context > without having the same sort of problem. >=20 > Ultimately I can cross-build and install from > those materials when I really want updates. I > have the context for such. This was more about > seeing how well the rpi2 did for self-hosted. > Classically I've used a BPI-M3 with 2 GiBytes > of RAM and a proportionally bigger swap partition > instead (approximately). >=20 >=20 > FYI (rpi2 after rebooting): >=20 > # swapinfo > Device 1K-blocks Used Avail Capacity > /dev/label/RPI2swap 1572860 0 1572860 0% >=20 > # df -m > Filesystem 1M-blocks Used Avail Capacity Mounted on > /dev/ufs/RPI2rootfs 195378 30791 148957 17% / > devfs 0 0 0 100% /dev > /dev/label/RPI2Aboot 49 12 37 25% /boot/msdos >=20 >=20 > An rpi3 (aarch64) with the same amount of RAM, > same type of USB SSD, etc., but well more swap > completed building basically the same set of > ports for the same poudriere settings just > fine. >=20 > Interestingly for the default kern.maxswzone: > (Just to show the reported recommended maximum > figures for swap.) >=20 > rpi2: . . . exceeds maximum recommended amount (411488 pages). > rpi3: . . . exceeds maximum recommended amount (925680 pages). >=20 > (I was running with somewhat under those maximums for > the tests.) >=20 > # swapinfo > Device 1K-blocks Used Avail Capacity > /dev/gpt/RPI3swap 3702784 0 3702784 0% >=20 > # df -m > Filesystem 1M-blocks Used Avail Capacity Mounted on > /dev/ufs/RPI3rootfs 195378 14937 164811 8% / > devfs 0 0 0 100% /dev > /dev/label/RPI3Aboot 49 7 42 15% /boot/efi >=20 > If I restricted the rpi3 to somewhat under what the > rpi2 allows for swap, I do not know if it would also > hang up vs. not. >=20 > If having more swap makes the difference, then it > would not seem to be being I/O-bound that would > explain the hangup. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net There are a few factors that could have prevented this on your raspberry = pi 3. It has a faster, 64 bit CPU instead of the raspberry pi 2=E2=80=99s 32 = bit CPU and the RAM is twice as fast. These make it less likely for this to happen, = because it makes both building and linking faster, which reduces the odds of = linking 2 binaries at once, let alone 3. There are many things that could have = gone differently in the build that didn=E2=80=99t make it end up linking 3 = big binaries at the same time to cause the same behaviour. What I think happened on your raspberry pi 2 is just likely bad luck = that could also happen on your raspberry pi 3. The odds of 3 parallel builds = needing so much ram to link at the exact same time are still very low, just less = low on faster hardware. Keep in mind that this is still entirely theoretical, I don=E2=80=99t = present it as an absolute explanation. It=E2=80=99s simply what I understand from this. I=E2=80=99d be curious seeing how a different operating system using a = system similar to poudriere where builds are done on one CPU but in parallel would be = handled on the rpi2. My understanding is that this is simply a mix of hardware = limitation and conceptual flaws with the swap. And by flaws I mean, your operating = system cannot save you when you try to do something that your hardware cannot = possibly do. Laurent= From owner-freebsd-arm@freebsd.org Thu Dec 7 02:59:31 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 CB4C9E98F16 for ; Thu, 7 Dec 2017 02:59:31 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from onager.schwarzes.net (onager.schwarzes.net [IPv6:2a03:4000:8:2bb::5d22]) (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 6F59471B18 for ; Thu, 7 Dec 2017 02:59:31 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from [172.30.250.35] (x4e33b0ae.dyn.telefonica.de [78.51.176.174]) (authenticated bits=0) by onager.schwarzes.net (8.15.2/8.15.2) with ESMTPA id vB72xRf0026329 for ; Thu, 7 Dec 2017 03:59:28 +0100 (CET) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Thu, 07 Dec 2017 03:59:26 +0100 (CET) Message-ID: <4b1c7d84525.837804f@mail.schwarzes.net> User-Agent: YAM/2.9p1 (MorphOS; PPC; rv:20140418r7798) Subject: arm64 kernel complile fail with nooption KDB MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (onager.schwarzes.net [37.221.194.76]); Thu, 07 Dec 2017 03:59:28 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 02:59:31 -0000 Building arm64 kernel fails, when KDB is undefined. This is caused by a commit 10 days ago, kdb_trap() is used outside of a "#ifdef KDB" condition. Have a look at: https://svnweb.freebsd.org/base/head/sys/arm64/arm64/trap.c?r1=326227&r2=326312 --- trap.o --- /usr/src/sys/arm64/arm64/trap.c:326:3: error: implicit declaration of function 'kdb_trap' is invalid in C99 [-Werror,-Wimplicit-function-declaration] kdb_trap(exception, 0, ^ /usr/src/sys/arm64/arm64/trap.c:326:3: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes] 2 errors generated. *** [trap.o] Error code 1 make[2]: stopped in /usr/obj/usr/src/arm64.aarch64/sys/PINE64-ASC 1 error make[2]: stopped in /usr/obj/usr/src/arm64.aarch64/sys/PINE64-ASC *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src -asc From owner-freebsd-arm@freebsd.org Thu Dec 7 05:00: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 96DBBE9CDEB for ; Thu, 7 Dec 2017 05:00:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-170.reflexion.net [208.70.210.170]) (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 593C27605A for ; Thu, 7 Dec 2017 05:00:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4466 invoked from network); 7 Dec 2017 05:00:13 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 7 Dec 2017 05:00:13 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 07 Dec 2017 00:00:13 -0500 (EST) Received: (qmail 2504 invoked from network); 7 Dec 2017 05:00:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Dec 2017 05:00:13 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7F00BEC932D; Wed, 6 Dec 2017 21:00:12 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: rpi2 hangup during poudriere build: lots of pfault wmseg status From: Mark Millard In-Reply-To: <5014B6E6-68BA-4499-8728-EF80237F3269@nuxi.ca> Date: Wed, 6 Dec 2017 21:00:11 -0800 Cc: freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <05BEA04B-249B-4E7D-855A-46DA1A0DEA16@dsl-only.net> <36A8BDCC-4ECE-4187-8705-54A9E38E8AD5@dsl-only.net> <5014B6E6-68BA-4499-8728-EF80237F3269@nuxi.ca> To: Laurent Cimon X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 05:00:20 -0000 > On 2017-Dec-6, at 5:47 PM, Laurent Cimon wrote: >=20 >> On Dec 6, 2017, at 20:01, Mark Millard = wrote: >>=20 >> On 2017-Dec-6, at 1:54 PM, Laurent Cimon wrote: >>=20 >>>> On Dec 6, 2017, at 00:57, Mark Millard = wrote: >>>>=20 >>>> I tried to build some ports on a rpi2 >>>> (via poudriere) but it hung up: >>>> Ethernet and normal console use. (Note: >>>> the root file system is on a USB SSD >>>> and the swap partition is also on that >>>> USB SSD.) >>>>=20 >>>> But ~^b worked for getting to the db> >>>> prompt on the console. >>>>=20 >>>> =46rom there a ps suggests that it got hung >>>> up in pfault activity. (Possibly insufficient >>>> RAM+swap-partition space?) But it is not >>>> clear to me that it should end up hung up >>>> vs. killing processes or other such. >>>=20 >>> Hi, >>>=20 >>> =46rom what I know the raspberry pis use the same controller for = ethernet and >>> the USB hub on which you=E2=80=99re hosting an SSD. It seems like = you make very heavy >>> use of the USB ports, and all of the resources used by poudriere = except for the >>> CPU and the (very limited) memory that=E2=80=99s not in swap is = attached to them. If you >>> really didn=E2=80=99t have enough memory and swap, the linkers = would=E2=80=99ve been stopped. >>>=20 >>> I think it might just be a swap death. Poudriere compiles and = fetches in parallel >>> a lot, ethernet and disk I/O is slow because it=E2=80=99s very = limited, so linking takes >>> longer. You end up linking a few very big binaries at the same time, = and they >>> all fight for the memory, to get out of swap through page faults, = but there >>> are too many page faults, all too big, requesting for more CPU time = that=E2=80=99s >>> allowed to them. >>>=20 >>> This would explain why you have 3 linkers waiting on a page fault = out of the 4 >>> CPUs poudriere allows builds on, on top of the awk processes. It = would also >>> explain why you had easy access to the debugger: it was in memory = already with >>> the kernel. >>>=20 >>> I=E2=80=99d advise you to disable parallel builds and see if it = happens again, >>> but it would make building much slower. Using makejobs would help if = you >>> can afford watching the build. Otherwise be patient, it should = resolve itself >>> eventually, but it will take a while and it will happen again. >>=20 >> My post was more about how FreeBSD handled the >> heavy-use context and less about getting the >> builds to finish: it managed to to get to a >> state of no-progress for processes and a loss >> of normal control as far as I could tell. >>=20 >> I did a "c" to ddb and left it until just before >> this note then did ~ ^B again. Things looked the >> same. [I've finally rebooted the rpi2.] >>=20 >> PARALLEL_JOBS=3D1 was already in use but >> ALLOW_MAKE_JOBS=3Dyes was also in use. >> USE_TMPFS=3Dno was already in use. >>=20 >> While an ssh session was monitoring the >> build, Ethernet was not in heavy use. >> (No nfs mounts to its disks, for example.) >>=20 >> I may try without ALLOW_MAKE_JOBS=3Dyes and >> with ALLOW_MAKE_JOBS_PACKAGES empty/undefined >> to see if it can complete for such a context >> without having the same sort of problem. >>=20 >> Ultimately I can cross-build and install from >> those materials when I really want updates. I >> have the context for such. This was more about >> seeing how well the rpi2 did for self-hosted. >> Classically I've used a BPI-M3 with 2 GiBytes >> of RAM and a proportionally bigger swap partition >> instead (approximately). >>=20 >>=20 >> FYI (rpi2 after rebooting): >>=20 >> # swapinfo >> Device 1K-blocks Used Avail Capacity >> /dev/label/RPI2swap 1572860 0 1572860 0% >>=20 >> # df -m >> Filesystem 1M-blocks Used Avail Capacity Mounted on >> /dev/ufs/RPI2rootfs 195378 30791 148957 17% / >> devfs 0 0 0 100% /dev >> /dev/label/RPI2Aboot 49 12 37 25% /boot/msdos >>=20 >>=20 >> An rpi3 (aarch64) with the same amount of RAM, >> same type of USB SSD, etc., but well more swap >> completed building basically the same set of >> ports for the same poudriere settings just >> fine. >>=20 >> Interestingly for the default kern.maxswzone: >> (Just to show the reported recommended maximum >> figures for swap.) >>=20 >> rpi2: . . . exceeds maximum recommended amount (411488 pages). >> rpi3: . . . exceeds maximum recommended amount (925680 pages). >>=20 >> (I was running with somewhat under those maximums for >> the tests.) >>=20 >> # swapinfo >> Device 1K-blocks Used Avail Capacity >> /dev/gpt/RPI3swap 3702784 0 3702784 0% >>=20 >> # df -m >> Filesystem 1M-blocks Used Avail Capacity Mounted on >> /dev/ufs/RPI3rootfs 195378 14937 164811 8% / >> devfs 0 0 0 100% /dev >> /dev/label/RPI3Aboot 49 7 42 15% /boot/efi >>=20 >> If I restricted the rpi3 to somewhat under what the >> rpi2 allows for swap, I do not know if it would also >> hang up vs. not. >>=20 >> If having more swap makes the difference, then it >> would not seem to be being I/O-bound that would >> explain the hangup. >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > There are a few factors that could have prevented this on your = raspberry pi 3. >=20 > It has a faster, 64 bit CPU instead of the raspberry pi 2=E2=80=99s 32 = bit CPU and the > RAM is twice as fast. These make it less likely for this to happen, = because it > makes both building and linking faster, which reduces the odds of = linking 2 > binaries at once, let alone 3. There are many things that could have = gone > differently in the build that didn=E2=80=99t make it end up linking 3 = big binaries at > the same time to cause the same behaviour. >=20 > What I think happened on your raspberry pi 2 is just likely bad luck = that could > also happen on your raspberry pi 3. The odds of 3 parallel builds = needing so > much ram to link at the exact same time are still very low, just less = low on > faster hardware. >=20 > Keep in mind that this is still entirely theoretical, I don=E2=80=99t = present it as an > absolute explanation. It=E2=80=99s simply what I understand from this. >=20 > I=E2=80=99d be curious seeing how a different operating system using a = system similar to > poudriere where builds are done on one CPU but in parallel would be = handled on > the rpi2. My understanding is that this is simply a mix of hardware = limitation > and conceptual flaws with the swap. And by flaws I mean, your = operating system > cannot save you when you try to do something that your hardware cannot = possibly > do. For reference: The rpi2 hung up during: [08:00:15] [01] [00:00:00] Building devel/binutils | binutils-2.28,1 (Only one builder, no prior builds should matter. All 4 cores allowed.) On the rpi3 this was: [08:13:38] [01] [00:00:00] Building devel/binutils | binutils-2.28,1 [10:17:12] [01] [02:03:34] Finished devel/binutils | binutils-2.28,1: = Success (Only one builder, no prior or following builds should matter. All 4 cores allowed.) Comparing a couple of examples that both completed: rpi2: [00:43:40] [01] [00:00:00] Building lang/perl5.24 | perl5-5.24.3 [01:38:37] [01] [00:54:57] Finished lang/perl5.24 | perl5-5.24.3: = Success vs. rpi3: [00:26:35] [01] [00:00:00] Building lang/perl5.24 | perl5-5.24.3 [00:56:14] [01] [00:29:39] Finished lang/perl5.24 | perl5-5.24.3: = Success rpi2: [07:12:51] [01] [00:00:00] Building databases/sqlite3 | sqlite3-3.21.0_1 [07:59:04] [01] [00:46:13] Finished databases/sqlite3 | = sqlite3-3.21.0_1: Success vs. rpi3: [07:43:31] [01] [00:00:00] Building databases/sqlite3 | sqlite3-3.21.0_1 [08:13:35] [01] [00:30:04] Finished databases/sqlite3 | = sqlite3-3.21.0_1: Success The rpi2 lasting days longer than the rpi3 2hr figure for devel/binutils is likely out of scale for processor and RAM differences in speed. (The USB-tied performance likely is not all that different.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Dec 8 11:46:15 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 497D1E8110B; Fri, 8 Dec 2017 11:46:15 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 CA2B96F08E; Fri, 8 Dec 2017 11:46:14 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id y82so4234272wmg.1; Fri, 08 Dec 2017 03:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=89eJbFrl6iufM30k2sQ+5DUQz0CzPbQ9zOjHymQnFAs=; b=rGdQW2rMA8jWSRauGS8FIPTp22N794CCEytYL0uOvOF6QxXTKqnbRtK45kP3enZb3f jpsfvdkBllsDfZRCCOQTCIOe7GGixYa7KFba7O/5r4OwnadBpIG7J+OwmraJbF+iLqYx UOvNobfmpIwwxKZyTuIJcuwbe2IK7T2Bihy4GkSyAc/dtud62Y76E9UHwXFOMkFdhihX EB389v3MCPWU0LZy1Zc1FMhDAWh77qt5/thCgMaNHs/zkn6XpzuVzPDmAhpYsreAIjUw UAOYw1oY/WM/bGQYiOK/K8G2svGMN9EHGGp0RVQYKRrrkbgMUG0tS+rUkOpFPsHzpTzP PaSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:cc:references :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=89eJbFrl6iufM30k2sQ+5DUQz0CzPbQ9zOjHymQnFAs=; b=NlJ3vrbRIlikcWNAPTapgKIaYi6XBNvcRV2oticXBKQ6qJQt1e91WccwAwvJkwS0R5 SQxoCW94pCykkCMDcgO3BYFLuS6KXRaRTunPNJLDPq2wzdybxMclCBK7qZMu0rbL+qEJ DLNYmHO24/yX9hF//lDH3N9UomsJ9jgKznXzeUX9qUswkaYk7Z5uoFpA1OvlOnla+rtT CJv40WBE0NM7qrKWmzlMvYSSWU6+/MJTv0J18oP192l6xMJga/RXBDYwVBmUAvXxTK2P EJ9hESR/T+phexpViAmWs2hBuc1PBIUsJAS+UUSJH7eMcOyyIC9eLnaBUICMPrXKcwcn BWJA== X-Gm-Message-State: AKGB3mJFeR25sGJnMqQcUlQ4ToXahXiJfVco/cDPT/6IwDUbdSm7y+7Q JDcvlq3MJMTGCKmM1+RkllISFbQX59g= X-Google-Smtp-Source: AGs4zMYIX8squjxruku1rtTYqbPxogIkFCHQbc9Uj1oaD1c9tGGHV4YdW7Yf7+XkB7dsnvya+7KmRg== X-Received: by 10.28.35.4 with SMTP id j4mr3549284wmj.55.1512733572378; Fri, 08 Dec 2017 03:46:12 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id 128sm1444260wmi.28.2017.12.08.03.46.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Dec 2017 03:46:11 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: mmel@freebsd.org Subject: Re: For armv7 (cross build target): multimedia/libvpx depends on the GNU C library function getauxval and so fails to build; so, disable its expectation? To: Ian Lepore , Jan Beich , Mark Millard Cc: Freebsd-arm , FreeBSD Ports References: <1512583709.58601.49.camel@freebsd.org> Message-ID: <03a31eff-34e8-be4c-c008-528824fea261@freebsd.org> Date: Fri, 8 Dec 2017 12:46:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1512583709.58601.49.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 11:46:15 -0000 On 06.12.2017 19:08, Ian Lepore wrote: > On Wed, 2017-12-06 at 18:37 +0100, Jan Beich wrote: >> Mark Millard writes: >> >>> >>> For armv7 attempting to build multimedia/libvpx >>> (via an indirect dependency) leads to: >>> >>> cp libvpx_g.a libvpx.a >>> vpx_ports/arm_cpudetect.c.o: In function `arm_cpu_caps': >>> /wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.6.1/vpx_ports/arm_cpudetect.c:198: undefined reference to `getauxval' >>> c++: error: linker command failed with exit code 1 (use -v to see invocation) >>> gmake[2]: *** [Makefile:384: libvpx.so.4.1.0] Error 1 >>> gmake[1]: *** [Makefile:17: .DEFAULT] Error 2 >>> gmake[1]: Leaving directory '/wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.6.1' >>> ===> Compilation failed unexpectedly. >>> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to >>> the maintainer. >>> *** Error code 1 >>> >>> >>> >>> The arm_cpudetect.c code looks like it expects >>> for FreeBSD to define getauxval (but it does not) and >>> has alternate code it uses if is not >>> available: >> Correct. I've expected FreeBSD to either implement its own helper and >> put it somewhere like or mimic GNU. What actually happened >> is something in-between which tends to break existing code e.g., >> >>   AC_CHECK_HEADERS([sys/auxv.h]) >> >>   #ifdef HAVE_SYS_AUXV_H >>          unsigned long hwcap = getauxval(AT_HWCAP); >>   ... >>   #endif >> >> in https://github.com/mono/mono/blob/9ba3fa0ba37c/mono/utils/mono-hwcap-arm.c#L41 >> >> base r324815 has questionable rationale for not using getauxval() >> because if AT_FOO is not supported or doesn't make sense on FreeBSD one >> can just #ifdef it out. As you've noticed Linux folks rarely use >> getauxval() outside of AT_HWCAP. Some AT_* are compatible, some have >> different name, some are specific to Linux or FreeBSD. >> >> Now we have elf_aux_info() which is not documented. Go figure how to use >> it properly and avoid introducing bugs specific to FreeBSD. >> >> Makes one wonder why FreeBSD didn't choose sysctl to expose ARM >> capabilities like hw.cpu_features (on powerpc*) if portability was out >> of scope. > > It's my fault elf_aux_info() isn't documented yet. I agreed to write > the manpage, then I got sick (for weeks) and haven't gotten anything > much done in that time. > > I tend to agree about not providing a reasonably-compatible getauxval() > function being a bad thing.  I think it would be fine to support a > subset of the AT_* values linux supports, and we can add additional > support as needs arise. > Having linux compatible getauxval() was my original plan. But during testing, I found that some ports autodetect getauxval() presence and if exists, then full linux implementation is required. My bad is that I didn't realize that the presence of "sys/auxv/h" causes the same troubles. I don't think that full emulation of getauxval() is best - the port wants (from memory, incomplete) at least, additionally to AT_HWCAPS(2) : AT_PLATFORM AT_SECURE AT_RANDOM AT_CLKTCK I don't think that we want to implement linux compatible platform strings, nor generate random vector for each program. So, by my best, I think that FreeBSD specific version of original CPU/feature/platform function is easier and most robust solution. And, maybe, upstream will accept it at one day... The updated patch for multimedia/libvpx is here: http://build.humusoft.cz/patches/multimedia/libvpx/libvpx.diff Michal From owner-freebsd-arm@freebsd.org Fri Dec 8 14:21:18 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 1AA6AE8490E; Fri, 8 Dec 2017 14:21:18 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED5A173A86; Fri, 8 Dec 2017 14:21:17 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 2FE0F1671E; Fri, 8 Dec 2017 14:21:17 +0000 (UTC) From: Jan Beich To: Michal Meloun Cc: Ian Lepore , Mark Millard , mmel@freebsd.org, Freebsd-arm , FreeBSD Ports Subject: Re: For armv7 (cross build target): multimedia/libvpx depends on the GNU C library function getauxval and so fails to build; so, disable its expectation? References: <1512583709.58601.49.camel@freebsd.org> <03a31eff-34e8-be4c-c008-528824fea261@freebsd.org> Date: Fri, 08 Dec 2017 15:21:10 +0100 In-Reply-To: <03a31eff-34e8-be4c-c008-528824fea261@freebsd.org> (Michal Meloun's message of "Fri, 8 Dec 2017 12:46:12 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 14:21:18 -0000 Michal Meloun writes: > Having linux compatible getauxval() was my original plan. > But during testing, I found that some ports autodetect getauxval() > presence and if exists, then full linux implementation is required. > My bad is that I didn't realize that the presence of "sys/auxv/h" > causes the same troubles. Why auxv.h lives under sys/ despite not having any consumers there? Maybe rename to . > The updated patch for multimedia/libvpx is here: > http://build.humusoft.cz/patches/multimedia/libvpx/libvpx.diff Looks OK but > + unsigned long hwcaps; Maybe initialize to 0 to save typing on simple error handling below. elf_aux_info() seems to be sane enough to not touch the buffer on error. > +#if __has_include() > + if (elf_aux_info(AT_HWCAP, &hwcaps, sizeof(hwcaps)) != 0) > + hwcaps = 0; > +#else > + hwcaps = 0; > +#endif For example: unsigned long hwcaps = 0; [...] #if __has_include() elf_aux_info(AT_HWCAP, &hwcaps, sizeof(hwcaps) #endif From owner-freebsd-arm@freebsd.org Fri Dec 8 14:37:09 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 DF07DE85047; Fri, 8 Dec 2017 14:37:09 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BD274744F4; Fri, 8 Dec 2017 14:37:09 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 0010F16AB1; Fri, 8 Dec 2017 14:37:08 +0000 (UTC) From: Jan Beich To: Michal Meloun Cc: Ian Lepore , Mark Millard , mmel@freebsd.org, Freebsd-arm , FreeBSD Ports Subject: Re: For armv7 (cross build target): multimedia/libvpx depends on the GNU C library function getauxval and so fails to build; so, disable its expectation? References: <1512583709.58601.49.camel@freebsd.org> <03a31eff-34e8-be4c-c008-528824fea261@freebsd.org> Date: Fri, 08 Dec 2017 15:37:04 +0100 In-Reply-To: <03a31eff-34e8-be4c-c008-528824fea261@freebsd.org> (Michal Meloun's message of "Fri, 8 Dec 2017 12:46:12 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 14:37:10 -0000 Michal Meloun writes: > I don't think that full emulation of getauxval() is best - > the port wants (from memory, incomplete) at least, additionally to > AT_HWCAPS(2) : > > AT_PLATFORM > AT_SECURE > AT_RANDOM > AT_CLKTCK > > I don't think that we want to implement linux compatible platform > strings, nor generate random vector for each program. elf_aux_info() is neither here nor there. I can't use it even for all FreeBSD AT_* values unlike pass-through getauxval() e.g., #if !defined(AT_EXECFN) && defined(AT_EXECPATH) #define AT_EXECFN AT_EXECPATH #endif printf("%s\n", (char *)getauxval(AT_EXECFN));