From owner-freebsd-arm@freebsd.org Sun Feb 11 02:46:49 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1344FF12245 for ; Sun, 11 Feb 2018 02:46:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83D697F66E for ; Sun, 11 Feb 2018 02:46:48 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id B56D02FB9C for ; Sun, 11 Feb 2018 02:46:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w1B2kldU034340 for ; Sun, 11 Feb 2018 02:46:47 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w1B2klP2034338 for freebsd-arm@FreeBSD.org; Sun, 11 Feb 2018 02:46:47 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 225816] ipfw crashing on Raspberry Pi 3 Date: Sun, 11 Feb 2018 02:46:47 +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: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jlduran@gmail.com 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 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, 11 Feb 2018 02:46:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225816 Bug ID: 225816 Summary: ipfw crashing on Raspberry Pi 3 Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: jlduran@gmail.com ipfw crashes upon start on FreeBSD 12.0-CURRENT r329009 on a Raspberry Pi 3: root@raspberrypi:~ # service ipfw onestart ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to accept, logging disabled Flushed all rules. 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 00400 deny ip from any to ::1 00500 deny ip from ::1 to any 00600 allow ipv6-icmp from :: to ff02::/16 00700 allow ipv6-icmp from fe80::/10 to fe80::/10 00800 allow ipv6-icmp from fe80::/10 to ff02::/16 00900 allow ipv6-icmp from any to any ip6 icmp6types 1 01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 Firewall rules loaded. Firewall logging enabled. root@raspberrypi:~ # Fatal data abort: x0: 0 x1: 8 x2: ffff0000006d69ec x3: 2b3 x4: 0 x5: ffff000051368810 x6: 0 x7: 0 x8: ffff000000b540d0 x9: 1 x10: ffff000000b54108 x11: ffff000000b53da0 x12: ffff0000531ad900 x13: 0 x14: ffff000053a14100 x15: 1 x16: 2af8 x17: 283c x18: ffff0000513686d0 x19: ffff0000531cc238 x20: 0 x21: 0 x22: ffff0000531cc000 x23: 0 x24: 0 x25: 94 x26: ffff000000b4aa00 x27: ffff0000008e9000 x28: 0 x29: ffff000051368750 sp: ffff0000513686d0 lr: ffff00000036bcc8 elr: ffff000053194ee4 spsr: 5 far: ffff000053a14100 esr: 96000006 [ thread pid 12 tid 100013 ] Stopped at dyn_tick+0x7c: ldr x14, [x14] db> bt Tracing pid 12 tid 100013 td 0xfffffd00014c7a80 db_trace_self() at db_stack_trace+0xec pc =3D 0xffff00000062ea04 lr =3D 0xffff0000000bda34 sp =3D 0xffff000051368020 fp =3D 0xffff000051368050 db_stack_trace() at db_command+0x220 pc =3D 0xffff0000000bda34 lr =3D 0xffff0000000bd6bc sp =3D 0xffff000051368060 fp =3D 0xffff000051368140 db_command() at db_command_loop+0x60 pc =3D 0xffff0000000bd6bc lr =3D 0xffff0000000bd480 sp =3D 0xffff000051368150 fp =3D 0xffff000051368170 db_command_loop() at db_trap+0xf4 pc =3D 0xffff0000000bd480 lr =3D 0xffff0000000c0594 sp =3D 0xffff000051368180 fp =3D 0xffff0000513683a0 db_trap() at kdb_trap+0x1b8 pc =3D 0xffff0000000c0594 lr =3D 0xffff000000395a70 sp =3D 0xffff0000513683b0 fp =3D 0xffff000051368420 kdb_trap() at data_abort+0x1c0 pc =3D 0xffff000000395a70 lr =3D 0xffff0000006494fc sp =3D 0xffff000051368430 fp =3D 0xffff0000513684e0 data_abort() at do_el1h_sync+0x11c pc =3D 0xffff0000006494fc lr =3D 0xffff000000649238 sp =3D 0xffff0000513684f0 fp =3D 0xffff000051368520 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff000000649238 lr =3D 0xffff000000631074 sp =3D 0xffff000051368530 fp =3D 0xffff000051368640 handle_el1h_sync() at softclock_call_cc+0x174 pc =3D 0xffff000000631074 lr =3D 0xffff00000036bcc4 sp =3D 0xffff000051368650 fp =3D 0xffff000051368750 softclock_call_cc() at softclock_call_cc+0x174 pc =3D 0xffff00000036bcc4 lr =3D 0xffff00000036bcc4 sp =3D 0xffff000051368760 fp =3D 0xffff000051368810 softclock_call_cc() at softclock+0x84 pc =3D 0xffff00000036bcc4 lr =3D 0xffff00000036c024 sp =3D 0xffff000051368820 fp =3D 0xffff000051368840 softclock() at intr_event_execute_handlers+0xac pc =3D 0xffff00000036c024 lr =3D 0xffff00000031a664 sp =3D 0xffff000051368850 fp =3D 0xffff0000513688a0 intr_event_execute_handlers() at ithread_loop+0xb0 pc =3D 0xffff00000031a664 lr =3D 0xffff00000031ad0c sp =3D 0xffff0000513688b0 fp =3D 0xffff000051368910 ithread_loop() at fork_exit+0x7c pc =3D 0xffff00000031ad0c lr =3D 0xffff00000031795c sp =3D 0xffff000051368920 fp =3D 0xffff000051368950 fork_exit() at fork_trampoline+0x10 pc =3D 0xffff00000031795c lr =3D 0xffff000000648f8c sp =3D 0xffff000051368960 fp =3D 0x0000000000000000 db> continue local_intc0: local_intc0: local_intc0: Stray irq 2 detected Stray irq 2 detected Stray irq 2 detected Fatal data abort: x0: 0 x1: 8 x2: ffff0000006d69ec x3: 2b3 x4: 0 x5: ffff000051368810 x6: 0 x7: 0 x8: ffff000000b540d0 x9: 1 x10: ffff000000b54108 x11: ffff000000b53da0 x12: ffff0000531ad900 x13: 0 x14: ffff000053a14100 x15: 1 x16: 2af8 x17: 283c x18: ffff0000513686d0 x19: ffff0000531cc238 x20: 0 x21: 0 x22: ffff0000531cc000 x23: 0 x24: 0 x25: 94 x26: ffff000000b4aa00 x27: ffff0000008e9000 x28: 0 x29: ffff000051368750 sp: ffff0000513686d0 lr: ffff00000036bcc8 elr: ffff000053194ee4 spsr: 5 far: ffff000053a14100 esr: 96000006 timeout stopping cpus [ thread pid 12 tid 100013 ] Stopped at dyn_tick+0x7c: ldr x14, [x14] db> timeout stopping cpus panic: acquiring blockable sleep lock with spinlock or critical section held (sleep mutex) pmap @ /usr/src/sys/arm64/arm64/pmap.c:4791 cpuid =3D 1 time =3D 1518316508 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff00000062ea04 lr =3D 0xffff0000000c042c sp =3D 0xffff0000403c8260 fp =3D 0xffff0000403c8470 db_trace_self_wrapper() at vpanic+0x184 pc =3D 0xffff0000000c042c lr =3D 0xffff00000035421c sp =3D 0xffff0000403c8480 fp =3D 0xffff0000403c8500 vpanic() at kassert_panic+0x158 pc =3D 0xffff00000035421c lr =3D 0xffff000000354094 sp =3D 0xffff0000403c8510 fp =3D 0xffff0000403c85d0 kassert_panic() at witness_checkorder+0x140 pc =3D 0xffff000000354094 lr =3D 0xffff0000003b3300 sp =3D 0xffff0000403c85e0 fp =3D 0xffff0000403c8650 witness_checkorder() at __mtx_lock_flags+0xb0 pc =3D 0xffff0000003b3300 lr =3D 0xffff000000334b80 sp =3D 0xffff0000403c8660 fp =3D 0xffff0000403c86a0 __mtx_lock_flags() at pmap_fault+0x58 pc =3D 0xffff000000334b80 lr =3D 0xffff000000647314 sp =3D 0xffff0000403c86b0 fp =3D 0xffff0000403c86d0 pmap_fault() at data_abort+0xb8 pc =3D 0xffff000000647314 lr =3D 0xffff0000006493f4 sp =3D 0xffff0000403c86e0 fp =3D 0xffff0000403c8790 data_abort() at do_el1h_sync+0x11c pc =3D 0xffff0000006493f4 lr =3D 0xffff000000649238 sp =3D 0xffff0000403c87a0 fp =3D 0xffff0000403c87d0 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff000000649238 lr =3D 0xffff000000631074 sp =3D 0xffff0000403c87e0 fp =3D 0xffff0000403c88f0 handle_el1h_sync() at vfp_save_state+0x4c pc =3D 0xffff000000631074 lr =3D 0xffff00000064a6bc sp =3D 0xffff0000403c8900 fp =3D 0xffff0000403c8990 vfp_save_state() at savectx+0x50 pc =3D 0xffff00000064a6bc lr =3D 0xffff000000649040 sp =3D 0xffff0000403c89a0 fp =3D 0xffff0000403c89b0 savectx() at bcm_lintc_intr+0xf4 pc =3D 0xffff000000649040 lr =3D 0xffff00000062b5a8 sp =3D 0xffff0000403c89c0 fp =3D 0xffff0000403c8a40 bcm_lintc_intr() at intr_irq_handler+0x68 pc =3D 0xffff00000062b5a8 lr =3D 0xffff000000672400 sp =3D 0xffff0000403c8a50 fp =3D 0xffff0000403c8a70 intr_irq_handler() at handle_el0_irq+0x6c pc =3D 0xffff000000672400 lr =3D 0xffff0000006312ec sp =3D 0xffff0000403c8a80 fp =3D 0xffff0000403c8b90 handle_el0_irq() at 0x40050ffc pc =3D 0xffff0000006312ec lr =3D 0x0000000040050ffc sp =3D 0xffff0000403c8ba0 fp =3D 0x0000ffffffffece0 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sun Feb 11 10:35:04 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF994F0A4EB for ; Sun, 11 Feb 2018 10:35:03 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 468A471808 for ; Sun, 11 Feb 2018 10:35:02 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id w1BAYjdK028448 (version=TLSv1.2 cipher=DHE-RSA-CHACHA20-POLY1305 bits=256 verify=OK) for ; Sun, 11 Feb 2018 21:34:52 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id w1BAYcei069357 (version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256 verify=NO) for ; Sun, 11 Feb 2018 21:34:38 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id w1BAYceZ069356 for freebsd-arm@freebsd.org; Sun, 11 Feb 2018 21:34:38 +1100 (AEDT) (envelope-from peter) Date: Sun, 11 Feb 2018 21:34:38 +1100 From: Peter Jeremy To: freebsd-arm@freebsd.org Subject: Difficulties updating RPi on 11-stable Message-ID: <20180211103438.GB3353@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6sX45UoQRIJXqkqR" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.9.2 (2017-12-15) 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, 11 Feb 2018 10:35:04 -0000 --6sX45UoQRIJXqkqR Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've been trying to update my RPi model B from 11-stable r324674 to r328837 and ran into a number of gotcha's along the way. Some I've resolved but I'm still working on the final two. 1) Initially (somewhat prior to r328837), the new kernel would load and then report: Can't load file '/boot/kernel/kernel': input/output error Searching the web didn't turn up any reports of this so I tried a from- scratch kernel build, as well as updating (to r328837) in case I'd picked a bad commit. When that didn't work, I noticed that I was running 3-year old firmware (January 2015) so I thought I'd try updating that... 2) After installing rpi-firmware-1.20171029, the GPU boot failed, displaying the 4-pixel GPU spash screen and flashing the green LED 7 times (which means kernel.img not found). After some digging, I discovered that the expected name of the third-stage bootloader had changed from uboot.img to u-boot.bin (neither file is included in the firmware image). After additionally installing u-boot.bin from u-boot-rpi-2017.09.00_1 I can now boot either r324674 or r328837 but I would have saved a lot of wasted time if the changed requirements had been documented. There's nothing mentioned in UPDATING. I've gone through all the stable/11 arm commits in the period in question and can't see any mention of a firmware incompatibility. I'm now left with 2 regressions that I haven't resolved: 3) 128MB of RAM has disappeared (losing =BC of the available RAM is annoyin= g). With "gpu_mem=3D32", U-Boot loader reports "DRAM: 480MB" (which is unchanged =66rom before) but the dmesg output has changed from (r324674 kernel): real memory =3D 536866816 (511 MB) avail memory =3D 482013184 (459 MB) Physical memory chunk(s): 0x00001000 - 0x1fffffff, 511 MB ( 131071 pages) Excluded memory regions: 0x00100000 - 0x00a44fff, 9 MB ( 2373 pages) NoAlloc=20 0x1e000000 - 0x1fffffff, 32 MB ( 8192 pages) NoAlloc NoDump Static device mappings: 0x20000000 - 0x20ffffff mapped at VA 0xfef00000 to (r328837 kernel): real memory =3D 503312384 (479 MB) avail memory =3D 350699520 (334 MB) Physical memory chunk(s): 0x00001000 - 0x1dffffff, 479 MB ( 122879 pages) Excluded memory regions: 0x01200000 - 0x01b44fff, 9 MB ( 2373 pages) NoAlloc=20 0x08000000 - 0x0fffffff, 128 MB ( 32768 pages) NoAlloc NoDump Static device mappings: 0x20000000 - 0x20ffffff mapped at VA 0xfef00000 I think the problem here is that the kernel is the new line: Preloaded dtb "/boot/dtb/bcm2835-rpi-b-rev2.dtb" at 0xc0806888. This file compiled from sys/boot/fdt/dts/arm/rpi.dts which explicitly reserves 128MB for the VideoCore. The commit comment in r252439 (when the memreserve was committed) was that the VideoCore binary patches it during boot. Whilst that may have been true in the past, it doesn't appear to be true any longer (instead the memory reserved by the VideoCore is excluded =66rom the memory map passed to the CPU). I suspect the correct fix is to just remove the memreserve completely (though I haven't tried that yet). 4) The primary console is redirected to the UART instead of video. Whilst low-level output is directed to the video output, writes to /dev/console don't go to the video, which is also annoying. So far as the FreeBSD loader is concerned, the only console device is "uboot". I've tried building a new boot.scr with stdout and stderr preferentially set to vidconsole to no avai= l. Poking around in the kernel, ttyv0 is a potential console but has a priority of CN_DEAD and it's not clear how to get the loader to tell the kernel to preferentially use it. --=20 Peter Jeremy --6sX45UoQRIJXqkqR Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAlqAHD5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzTiBw//cnXLf0N0fPvTD7NA8VI042HGtFN3yX9c6CUz5SzUP584CPUGvXXVQLne wqH5y4c4UTh+BnMksgazKixPCBVxXFDANRlTbmtWdeZwAspH8RN4qlArJM0tFcyy x20gieCCQX99EtnlcSwXUq5URXUfaZ+8E4e/VbM3P6FYtlAcqn47ZWaUoCdPmLUr KF9o+9oGVSOR5MyQSvR9hPg6MlKuWebFJa9IoGrGsWUbg/ZPrzXRJUuhN9dQ327T PMn1H6HkYWALVj1dSScX3dVGWn51a3me7A3qK6QFyE2XtVZnc+Bv8ftImRalQdnN v0i6BXsAQLV0XMHr78A8IUEF1EwSfQwBM/phhBMH8TPx9sKqdE5BSTGkGHGv0tQY nTAlbPd/fqo1fHEGCvBM3wJ/Kdf7VxJOu4Yrm44mAsv5/pswzF4hJY12GTdZFyCN dYeGzQZC5acG4WEag0CR4rT4pWgOZxxdWFftnQy3ynmlKZiT8tTpJ2/W4fCFGUKH RCwjVxVmPkDrfH4fojoFTicFseLwBaAFrRkzf9VgTH+HxCABKPR78BJiLfxeU6/y 1hxR9NlTIdu2E568JGAtuZsM9aBrxextvnau3f+kO02iPbA+WX4qbUGIjEcK2h9G uoxD2/nl7Ch7g3SnQ2sOc7Jrrl2a/gqkPtWdQpd7lkAjRlOAGq0= =h3g9 -----END PGP SIGNATURE----- --6sX45UoQRIJXqkqR-- From owner-freebsd-arm@freebsd.org Sun Feb 11 11:35:20 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FBCBF0F25B for ; Sun, 11 Feb 2018 11:35:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DFDB5740B8 for ; Sun, 11 Feb 2018 11:35:19 +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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 2A91A4AD0 for ; Sun, 11 Feb 2018 11:35:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w1BBZJIH032608 for ; Sun, 11 Feb 2018 11:35:19 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w1BBZJwM032605 for freebsd-arm@FreeBSD.org; Sun, 11 Feb 2018 11:35:19 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 225819] base/head is currently unusable on arm64 Date: Sun, 11 Feb 2018 11:35:19 +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: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: antoine@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 bug_severity priority component assigned_to reporter 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, 11 Feb 2018 11:35:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225819 Bug ID: 225819 Summary: base/head is currently unusable on arm64 Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: antoine@FreeBSD.org base/head is currently unusable on arm64 with several panics a day. We had to downgrade thunderx1 to base/head@325426 to be able to produce packages. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Feb 12 18:11:52 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 721F4F0E435 for ; Mon, 12 Feb 2018 18:11:52 +0000 (UTC) (envelope-from timur@codeaurora.org) Received: from smtp.codeaurora.org (smtp.codeaurora.org [198.145.29.96]) (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 09F2D82F1A; Mon, 12 Feb 2018 18:11:51 +0000 (UTC) (envelope-from timur@codeaurora.org) Received: by smtp.codeaurora.org (Postfix, from userid 1000) id CEA5460F8D; Mon, 12 Feb 2018 18:11:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1518459104; bh=rVKeg1LnPb/tKnGFvlpUwwCHt8eDs3nAkz7TuhhLqDY=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=AfQCvXmVvSZpDfk4F3zC9zkB3QdF429maWRLWAvAu0pch7YsfptKBnSmp5+Lhxd5Q ZXGlkmZ9Z13hn+zPOaE9PggTFmjt8vH2aTBMfN8W15SgSAgbap23zn96d6E8hXrKMy W128og0ehp2/uo1IHc31m8lTvOMmZtbwJBxH1uD4= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: timur@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id A2BE260F6B; Mon, 12 Feb 2018 18:11:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1518459103; bh=rVKeg1LnPb/tKnGFvlpUwwCHt8eDs3nAkz7TuhhLqDY=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=o5YXvGrWKiy/alI7wF6ZyyiLaXUDlrDV2O0j6nmFYb9kKZI2UAHbP2VjPTrT3v0fN /IIu0371zH7Q+YcOyzhxly3d2g9YEgja8SKbdp/+Qg0E5qKTaL2muglJTAWvpOmTG8 U3oHEKp0HxfdhY/y6EtRGlpxaxvC6erIR/tHG4So= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org A2BE260F6B Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=timur@codeaurora.org Received: by mail-oi0-f51.google.com with SMTP id t78so11870993oih.4; Mon, 12 Feb 2018 10:11:43 -0800 (PST) X-Gm-Message-State: APf1xPBl+qMVca6wnpu+zWUI8Ott3MFZmi0Ed38Bm01JnCBc+KtiEgiH SPK6aLH6wyzHR6qKIHcX3OuOuxjXOSp0p0ZJGc0= X-Google-Smtp-Source: AH8x225pSbxI2eZqmxncV2VZTqO3AbUrXOyXJ3025z/bzOi1X+2MDS1He1Djt4dbkJU2+6Sa5mQgRp1Vc+mz0xbP14E= X-Received: by 10.202.229.206 with SMTP id c197mr8076678oih.214.1518459102948; Mon, 12 Feb 2018 10:11:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.112.131 with HTTP; Mon, 12 Feb 2018 10:11:42 -0800 (PST) In-Reply-To: <1518137096.32585.128.camel@freebsd.org> References: <1518137096.32585.128.camel@freebsd.org> From: Timur Tabi Date: Mon, 12 Feb 2018 12:11:42 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Confused about ARM64 cross-compilation To: Ian Lepore Cc: Timur Tabi , freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" 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, 12 Feb 2018 18:11:52 -0000 On Thu, Feb 8, 2018 at 6:44 PM, Ian Lepore wrote: > Nope, the freebsd build process is completely self-contained. It > starts by building whatever cross-compiler it needs if crossbuilding is > involved. Thanks. What is the svn command to download just the latest-and-greatest kernel source code? I see a lot of examples in google searches, but most of them appear to download the entire FreeBSD source code. Also, does the arm64_build.sh script require the full BSD source, or can it work with just the kernel? -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. From owner-freebsd-arm@freebsd.org Mon Feb 12 18:34:41 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB2C5F10194 for ; Mon, 12 Feb 2018 18:34:41 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 50EFF841A2 for ; Mon, 12 Feb 2018 18:34:40 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w1CIWu5b075495 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Feb 2018 10:32:57 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w1CIWuJF075494; Mon, 12 Feb 2018 10:32:56 -0800 (PST) (envelope-from fbsd) Date: Mon, 12 Feb 2018 10:32:56 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: RPI3 can't build kernel-toolchain Message-ID: <20180212183256.GA75467@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) 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, 12 Feb 2018 18:34:42 -0000 On a Pi3 running r328935 trying to build sources at 329171 a make -j2 kernel-toolchain fails with /usr/bin/ld: error: duplicate symbol: >>> defined at ASTImporter.o:() in archive /usr/obj/usr/src/arm64.aarch64/tmp/obj-tools/lib/clang/libclang/libclang.a Tried updating the source tree and didn't seen any relevant changes, no luck using the -DNO_CLEAN option. The machine can't seem to get very far with j > 2, so cleaning will slow things by days. I'll try cleaning by degrees, but am unclear on the order. Is the sequence from least-to-most-thorough something like: make clean make cleandir 2nd make cleandir rm -rf /usr/obj/usr/ The make logfile is at http://www.zefox.net/~fbsd/rpi3/crashes/20180212/toolchain.log Thanks for reading, and any guidance! bob prohaska From owner-freebsd-arm@freebsd.org Tue Feb 13 19:22:38 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7437DF1C9B8 for ; Tue, 13 Feb 2018 19:22:38 +0000 (UTC) (envelope-from timur@codeaurora.org) Received: from smtp.codeaurora.org (smtp.codeaurora.org [198.145.29.96]) (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 105946BB97 for ; Tue, 13 Feb 2018 19:22:37 +0000 (UTC) (envelope-from timur@codeaurora.org) Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 15A7260F72; Tue, 13 Feb 2018 19:22:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1518549751; bh=t9SvPjonKskP2BJmC4LLWu1ufE8UHXYqOLoyTdquUAs=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=PP8pt6fH19joq4rvO+gV6vW2CiXRA8xhZUGjhex5GLcud245IDJBxcqpJdR0KSMJv Y53PyvmczJlUNziJ5wMlh7Vd8vzLGJOcveIR/dLkzpzziKRVB+0E7rXSZt0NMt+acF Y2VlvTYjQCLpqmbbuwMCuljYdBaqJZI1clrrrJqQ= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: timur@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 2172A60F71 for ; Tue, 13 Feb 2018 19:22:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1518549750; bh=t9SvPjonKskP2BJmC4LLWu1ufE8UHXYqOLoyTdquUAs=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=nZcJPjVci3xvL8iEic2VHpc40xRMCx16y7ddS1geEMnGh+e+MXXEXyWAY0m67+gEW zTOctC0Hq7zzNgI5oqMjVPQb+JujlODnYcyTFm70iiuH0JN3pWvT8zNoKJjTfJ3w0a OEv5x6LmvQwlqJ07qGiwctxx6XqkIGt1vAu3j+64= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 2172A60F71 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=timur@codeaurora.org Received: by mail-oi0-f51.google.com with SMTP id 4so14696668ois.10 for ; Tue, 13 Feb 2018 11:22:30 -0800 (PST) X-Gm-Message-State: APf1xPBdcveTGeufMER8f8+XXuYBJ2PSxOsWbVbMZXFy7dYYp4BNUisP W/fT9TpmfzK+iAocNvv2dUWZ9hb4084uDj4wZ3s= X-Google-Smtp-Source: AH8x224iGc1oSaDp8iBED0/+tn0eKy4qs+v9ypP6xOJcEs9aB07IoH6v8JB4fHgPvfU50QRplxwbPi11G40UOBYe1Fc= X-Received: by 10.202.79.214 with SMTP id d205mr1639021oib.308.1518549749412; Tue, 13 Feb 2018 11:22:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.112.131 with HTTP; Tue, 13 Feb 2018 11:22:28 -0800 (PST) In-Reply-To: <20180209172005.0b787bca.freebsd.ed.lists@sumeritec.com> References: <20180209172005.0b787bca.freebsd.ed.lists@sumeritec.com> From: Timur Tabi Date: Tue, 13 Feb 2018 13:22:28 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Confused about ARM64 cross-compilation To: Erich Dollansky Cc: Timur Tabi , freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" 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: Tue, 13 Feb 2018 19:22:38 -0000 On Fri, Feb 9, 2018 at 3:20 AM, Erich Dollansky wrote: > when I did arm64 compilations, I used CURRENT as certain things did not > work in older versions. You might also try 12.0 or CURRENT. > > FreeBSD cross compiles out of the box. Of course, only for supported > targets. arm64_build.sh produces several errors when it tries to setup the rootfs for QEMU, which I'm not using. KERNEL=kernel install thiskernel=`sysctl -n kern.bootfile` ; if [ ! "`dirname "$thiskernel"`" -ef /usr/home/ubuntu/arm64-workspace/rootfs/boot/kernel ] ; then chflags -R noschg /usr/home/ubuntu/arm64-workspace/rootfs/boot/kernel ; rm -rf /usr/home/ubuntu/arm64-workspace/rootfs/boot/kernel ; rm -rf /usr/home/ubuntu/arm64-workspace/rootfs/usr/lib/debug/boot/kernel ; else if [ -d /usr/home/ubuntu/arm64-workspace/rootfs/boot/kernel.old ] ; then chflags -R noschg /usr/home/ubuntu/arm64-workspace/rootfs/boot/kernel.old ; rm -rf /usr/home/ubuntu/arm64-workspace/rootfs/boot/kernel.old ; fi ; mv /usr/home/ubuntu/arm64-workspace/rootfs/boot/kernel /usr/home/ubuntu/arm64-workspace/rootfs/boot/kernel.old ; if [ -n "/usr/lib/debug" -a -d /usr/home/ubuntu/arm64-workspace/rootfs/usr/lib/debug/boot/kernel ]; then rm -rf /usr/home/ubuntu/arm64-workspace/rootfs/usr/lib/debug/boot/kernel.old ; mv /usr/home/ubuntu/arm64-workspace/rootfs/usr/lib/debug/boot/kernel /usr/home/ubuntu/arm64-workspace/rootfs/usr/lib/debug/boot/kernel.old ; fi ; sysctl kern.bootfile=/usr/home/ubuntu/arm64-workspace/rootfs/boot/kernel.old/"`basename "$thiskernel"`" ; fi mkdir -p /usr/home/ubuntu/arm64-workspace/rootfs/boot/kernel install -U -M /usr/home/ubuntu/arm64-workspace/rootfs//METALOG -D /usr/home/ubuntu/arm64-workspace/rootfs -p -m 555 -o root -g wheel kernel /usr/home/ubuntu/arm64-workspace/rootfs/boot/kernel/ mkdir -p /usr/home/ubuntu/arm64-workspace/rootfs/usr/lib/debug/boot/kernel install -U -M /usr/home/ubuntu/arm64-workspace/rootfs//METALOG -D /usr/home/ubuntu/arm64-workspace/rootfs -p -m 555 -o root -g wheel kernel.debug /usr/home/ubuntu/arm64-workspace/rootfs/usr/lib/debug/boot/kernel/ -------------------------------------------------------------- >>> Installing kernel GENERIC completed on Tue Feb 13 12:47:40 CST 2018 -------------------------------------------------------------- METALOG:10: warning: tags: unsupported keyword METALOG:56: warning: duplicate definition of var METALOG:59: warning: tags: unsupported keyword METALOG:60: warning: tags: unsupported keyword The METALOG errors continue for another 22,000 lines. Should I just edit the script to abort before it starts doing this, or is it failing because I don't have QEMU installed? Also, why is that every time I run arm64_build.sh, it rebuilds almost everything, even when I haven't changed any files? -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. From owner-freebsd-arm@freebsd.org Wed Feb 14 17:18:27 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B661CF0FD7D for ; Wed, 14 Feb 2018 17:18:27 +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 473B582FF8 for ; Wed, 14 Feb 2018 17:18:26 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 025cecf5-11ab-11e8-b951-f99fef315fd9 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 025cecf5-11ab-11e8-b951-f99fef315fd9; Wed, 14 Feb 2018 17:18:01 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w1EHIOss040983; Wed, 14 Feb 2018 10:18:24 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1518628704.72050.49.camel@freebsd.org> Subject: Re: Confused about ARM64 cross-compilation From: Ian Lepore To: Timur Tabi Cc: freebsd-arm@freebsd.org Date: Wed, 14 Feb 2018 10:18:24 -0700 In-Reply-To: References: <1518137096.32585.128.camel@freebsd.org> 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, 14 Feb 2018 17:18:27 -0000 On Mon, 2018-02-12 at 12:11 -0600, Timur Tabi wrote: > On Thu, Feb 8, 2018 at 6:44 PM, Ian Lepore wrote: > > > > Nope, the freebsd build process is completely self-contained.  It > > starts by building whatever cross-compiler it needs if > > crossbuilding is > > involved. > Thanks. > > What is the svn command to download just the latest-and-greatest > kernel source code?  I see a lot of examples in google searches, but > most of them appear to download the entire FreeBSD source code. > > Also, does the arm64_build.sh script require the full BSD source, or > can it work with just the kernel? > You can't really do much with "just the kernel source" other than browse or grep the code.  This isn't linux; freebsd is more than just a kernel, it's a complete system, and you need all the source to do a build. -- Ian From owner-freebsd-arm@freebsd.org Wed Feb 14 21:33:36 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B695F224D3 for ; Wed, 14 Feb 2018 21:33:36 +0000 (UTC) (envelope-from freebsd.ed.lists@sumeritec.com) Received: from mx6-out12.antispamcloud.com (mx6-out12.antispamcloud.com [95.211.2.203]) (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 0EFC56EB82 for ; Wed, 14 Feb 2018 21:33:35 +0000 (UTC) (envelope-from freebsd.ed.lists@sumeritec.com) Received: from [153.92.8.106] (helo=srv31.niagahoster.com) by mx5.antispamcloud.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1elwjk-0001uI-Ay for freebsd-arm@freebsd.org; Wed, 14 Feb 2018 14:04:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sumeritec.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VpqKgaBPcF0q2W1IlmYon+dTLlgg/+zy9/hRYxzAsk8=; b=ObbTYS/FLP9dkRorqB2oj5IFbH jw9MuazDrzGT8XLLW+BPLNWxtPsElMnNt6RVVxExB+ydM4o2VYYBVBVOP1yWNX2HxVK/v3QN3KQDI hHY/RT1YhXpoBwoa+0vqGW8Cz1oZXAYDGuXzVPZvE2WX2VLCsWrjoD5IsOk0mxib+6Pmjgr27LnIL SIqI4mCDisQGMxBIEX1G08wKrrJxK8WuZkd7+gzLo85n0W8ti/vAOVYqQSu9jrP46QzNalnPzZAzG mSy8RRYXdlyJ/QDJ1rMn+TqTAumXs+34bZUXUoyeywFgPAOx3XGx8IQsHLoQJelF4p2lbyRb07J3/ H0DoqE7A==; Received: from [114.125.73.149] (port=62274 helo=X220.sumeritec.com) by srv31.niagahoster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1elwit-0004s2-Cx; Wed, 14 Feb 2018 20:03:45 +0700 Date: Wed, 14 Feb 2018 21:03:39 +0800 From: Erich Dollansky To: Timur Tabi Cc: Ian Lepore , freebsd-arm@freebsd.org Subject: Re: Confused about ARM64 cross-compilation Message-ID: <20180214210339.42456cb6.freebsd.ed.lists@sumeritec.com> In-Reply-To: References: <1518137096.32585.128.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-1.0 X-AuthUser: freebsd.ed.lists@sumeritec.com X-Originating-IP: 153.92.8.106 X-AntiSpamCloud-Domain: out.niagahoster.com X-AntiSpamCloud-Username: niaga Authentication-Results: antispamcloud.com; auth=pass (login) smtp.auth=niaga@out.niagahoster.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5gzQHrmDPYQjs7qpx6pDnzB602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO66IuR3phNgiaHRXX+weUTfAZxalSlNXXUOuKKBq5Gfvvpf3JjS9poTbC9IODXxixg0e YUjpSnWqR0+c/hzTxldy0vKNdJMHZ2K0qgciRU0qKXs7EEez5XNPqrqg4cq+E1YFvf25LVONYbYi fH5OzZBcL+MdujCjU5iV47di8pZymqZ9l5BbLgn5uBWKsF5sXv6uW3BB9i/rD4I2O09txq7iTzj+ /BOqg7SFB7Og72Wa0TyXe6jsMXnTy/o9BuCfMaAR5uUPB6mtrJV0LEXPEPmJAdf0eGq9QmFYBSjq CQ9eZauD/370vtRSMDyLPX5obz/G4hlWh8XSISaV9khf360/06UMvJE30aO2JcVUuLdWiPvH7cxX tl8i6aTMYJPb+7yoV5Yhu/MPaSnZTpo2q7gCD20eohdCKNiEenBVC0y5aZSc3K2+FO70Srhh/To6 5eidX4Ts4xdG+C13IyWeZaKv9mD9LTcOLRzhziT99JtxwLqoA86IzuM71MF69smHgwREwXolAMQU yYr0IR07HqgAfxaAUQMVXRqeobdAuFwFTjKmLMMihIj02KY5dN0vDtM+m4WpRRDP6YzwkAPgQJZ9 KLDiFBJK5W2CoEntAZRH1Y4FXbs8l8QxYrL+ivPygsg4qOMbothvrc+hNWztholei8cMeZhu5JSB O1JeN5nU0GP2oVOpbb36FWA3/9VlG8lLtrKwC59itvOMbJhphsmlHA16mjJ0S2N6v15623Gu/VN2 4WBnFIwGGA+7woeoRdF/YEUlI632Y+AsqmNxJPRknRDjH7QY7Fm+gQ0M40rBwAFGgqVic6iP9J13 9zzItHlPYLLT2G4hKTUYgcGOpC/ukxQYR3spRy5URw7CeURB X-Report-Abuse-To: spam@quarantine1.antispamcloud.com 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, 14 Feb 2018 21:33:36 -0000 Hi, On Mon, 12 Feb 2018 12:11:42 -0600 Timur Tabi wrote: > On Thu, Feb 8, 2018 at 6:44 PM, Ian Lepore wrote: > > Nope, the freebsd build process is completely self-contained. It > > starts by building whatever cross-compiler it needs if > > crossbuilding is involved. > > Thanks. > > What is the svn command to download just the latest-and-greatest > kernel source code? I see a lot of examples in google searches, but > most of them appear to download the entire FreeBSD source code. > > Also, does the arm64_build.sh script require the full BSD source, or > can it work with just the kernel? > the first checkout is something like this: svnlite checkout svn://svn.freebsd.org/base/stable/11 /usr/src or svnlite checkout svn://svn.freebsd.org/base/base/head /usr/src You update your sources later with svnlite update usr/src Yes, it will download the full source tree as the make file decides during the building process what source files have to be used. Erich From owner-freebsd-arm@freebsd.org Thu Feb 15 17:05:00 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D73CF08334 for ; Thu, 15 Feb 2018 17:05:00 +0000 (UTC) (envelope-from qroxana@mail.ru) Received: from fallback.mail.ru (fallback10.m.smailru.net [94.100.178.50]) (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 846AA82986 for ; Thu, 15 Feb 2018 17:04:59 +0000 (UTC) (envelope-from qroxana@mail.ru) Received: from [10.161.64.49] (port=48532 helo=smtp41.i.mail.ru) by fallback10.m.smailru.net with esmtp (envelope-from ) id 1emMxm-0006K5-EJ for freebsd-arm@freebsd.org; Thu, 15 Feb 2018 20:04:50 +0300 Received: by smtp41.i.mail.ru with esmtpa (envelope-from ) id 1emMxd-0006Zd-GL for freebsd-arm@freebsd.org; Thu, 15 Feb 2018 20:04:42 +0300 Date: Thu, 15 Feb 2018 17:04:27 +0000 From: qroxana To: freebsd-arm@freebsd.org Subject: BananaPi M1 boot freeze with Linux 4.15 dtb MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: X-7FA49CB5: 0D63561A33F958A5C74BA3841285CB5069ABFA7D2890AAFFA15F3C7CB51F8E65725E5C173C3A84C3CC50ADF9F1B763C6E8C1090BA57C5FD4473DB2713789FF2EC4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F2EF91E2201DEA5EC574AF45C6390F7469DAA53EE0834AAEE X-Mailru-Sender: 544401ABD712F7D381A4427181ECA755CC00078BB818C245219C08B62D00B2756449A062D1B9818C60D6D505C5898BD5FF8C365A9CCAA137082AC48A80CE5D4D490AD6122F96B7B99DAF8AF4E272FCB55FAD6D05200F5AE3B84DA3FFC0930502EAB4BC95F72C04283CDA0F3B3F5B9367 X-Mras: OK X-7FA49CB5: 0D63561A33F958A5490DEDD01B1C73F6D8C385CD7BE883F819F0E9C3E726EDF3462275124DF8B9C934F12F0C005D1A85E5BFE6E7EFDEDCD789D4C264860C145E X-Mailru-Sender: A5480F10D64C900516D1E9AB9D42D95132AB566ACFC274AC717F32202C4103201C741AFE0338E1220156B81B246454EF3DCCF50608321A3FD25304A6A6F47388AA160FAF502953B818F04948669CC44F7607C59202B705AEFA3F01713B8852AFB4A721A3011E896F X-Mras: OK 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, 15 Feb 2018 17:05:00 -0000 Hi, ohci1: mem 0x1c1c400-0x1c1c4ff irq 26 on simplebus0 usbus3 on ohci1 gpio0: mem 0x1c20800-0x1c20bff irq 28 on simplebus0 gpio0: Could not find clock at offset 0 (19) device_attach: gpio0 attach returned 6 aw_wdog0: mem 0x1c20c90-0x1c20c9f on simplebus0 aw_ir0: mem 0x1c21800-0x1c2183f irq 37 on simplebus0 aw_ir0: Cannot get gate clock device_attach: aw_ir0 attach returned 6 aw_ts0: mem 0x1c25000-0x1c250ff irq 44 on simplebus0 --- freeze --- I have tried to load the old sun7i-a20-bananapi.dtb at the boot prompt, it worked again. From owner-freebsd-arm@freebsd.org Thu Feb 15 18:30:20 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD339F0F0B7 for ; Thu, 15 Feb 2018 18:30:20 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4AED868040 for ; Thu, 15 Feb 2018 18:30:20 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [IPv6:2003:cd:6bf1:8000:e82f:e091:a7e8:2544] (p200300CD6BF18000E82FE091A7E82544.dip0.t-ipconnect.de [IPv6:2003:cd:6bf1:8000:e82f:e091:a7e8:2544]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 0A5CC721E280C for ; Thu, 15 Feb 2018 19:30:11 +0100 (CET) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: ThunderX2 support Message-Id: <31CD451B-DD39-4F20-91CD-FD60A857A8A3@freebsd.org> Date: Thu, 15 Feb 2018 19:30:08 +0100 To: freebsd-arm X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de 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, 15 Feb 2018 18:30:20 -0000 Dear all, I know that ThunderX is supported by FreeBSD, but I'm wondering what the = status is regarding ThunderX2? Anyone running FreeBSD on a ThunderX2 board? Best regards Michael= From owner-freebsd-arm@freebsd.org Fri Feb 16 06:03:38 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2DF9F1884E for ; Fri, 16 Feb 2018 06:03:38 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 42CD5870B9 for ; Fri, 16 Feb 2018 06:03:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w1G63cEX088272 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Feb 2018 22:03:39 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w1G63cWM088271; Thu, 15 Feb 2018 22:03:38 -0800 (PST) (envelope-from fbsd) Date: Thu, 15 Feb 2018 22:03:38 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: RPI3 can't build kernel-toolchain Message-ID: <20180216060337.GA88230@www.zefox.net> References: <20180212183256.GA75467@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180212183256.GA75467@www.zefox.net> User-Agent: Mutt/1.5.24 (2015-08-30) 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, 16 Feb 2018 06:03:38 -0000 On Mon, Feb 12, 2018 at 10:32:56AM -0800, bob prohaska wrote: > On a Pi3 running r328935 trying to build sources at 329171 a > make -j2 kernel-toolchain fails with > /usr/bin/ld: error: duplicate symbol: > >>> defined at ASTImporter.o:() in archive /usr/obj/usr/src/arm64.aarch64/tmp/obj-tools/lib/clang/libclang/libclang.a > Updating sources eventually allowed make kernel-toolchain to build without errors. However, make buildkernel still stops, reporting In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: /usr/obj/usr/src/arm64.aarch64/tmp/usr/lib/clang/6.0.0/include/arm_neon.h:31:10: fatal error: 'stdint.h' file not found #include ^~~~~~~~~~ 1 error generated. *** [armv8_crypto_wrap.o] Error code 1 This seems rather odd, since find reports files with that name in several locations within /usr/src: root@www:/usr/src # find . -name stdint.h -depth -print ./sys/sys/stdint.h ./sys/contrib/zstd/lib/freebsd/stdint.h ./contrib/llvm/tools/clang/lib/Headers/stdint.h ./contrib/libc++/include/stdint.h ./contrib/libstdc++/include/tr1/stdint.h To the best of my ability the source tree is unmolested, svnlite info reports: root@www:/usr/src # svnlite status . ? buildkernel.log ? buildscript ? installscript ? kernelscript ? toolchain.log ? toolchainscript root@www:/usr/src # The source tree is presently at r329360. Thanks for reading, and any help! bob prohaska From owner-freebsd-arm@freebsd.org Fri Feb 16 14:19:28 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E51C3F17C33 for ; Fri, 16 Feb 2018 14:19:27 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic311-21.consmr.mail.gq1.yahoo.com (sonic311-21.consmr.mail.gq1.yahoo.com [98.137.65.202]) (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 67AD07BE26 for ; Fri, 16 Feb 2018 14:19:27 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: KmOBGZoVM1l3yRdMRhMxjiErvIdyW2GgibFvSUH07nNapT7bp2B4gRJAi7llFo6 X5.NJJW8N8hdxqwqXYtWLkslNFEbF4vNlzLo5vvoGes2uJkdH_sG4RHCSTDfUQ31RMosS5mrQDQ1 9C2eNB_Fm5u4Gyqlk.V9Bqsj29IA9n1CIXr4nK4LAR2xdLaJH8mn06Bw9t9zKNYNQ2043C1sOV92 5woappJ_BsenInNk2mj041Fg8xiP_pY6P6MYY2HWy_YDv7c76QhiRs4eOK9SbTXzTPwph7a9FJmh HzIZllW1gutCMR5N9Q0efDk7IY9022jfNf2DiK3Sd6NmYwFkFel8rv2Kt36QzvMLjD37lofKY0.1 KjYijnSrqZWCgKLb5_fcECC_d9S4iqNHAQeHzuaf3ONU7GwiNl8Y07ScjXlakwWTxLnf6rnOt8MD _fZunQpmBXMn5SKCs2MQ4AkhEN1fdW6LoSO7euc0qodKNWwwIsbSqfSqgQgPP66_bWGq.E8ytg5s QNuJ0PxjJl3IBwKx09g-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 16 Feb 2018 14:19:20 +0000 Received: from smtp102.rhel.mail.gq1.yahoo.com (EHLO [192.168.1.25]) ([216.39.57.211]) by smtp404.mail.gq1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 9889ff7fc9afd1646b3d4cfd9e387434; Fri, 16 Feb 2018 14:19:16 +0000 (UTC) From: Mark Millard Message-Id: <11F7E450-097C-41B3-B494-73106C710AE7@yahoo.com> Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: RPI3 can't build kernel-toolchain Date: Fri, 16 Feb 2018 06:19:15 -0800 In-Reply-To: <20180216060337.GA88230@www.zefox.net> Cc: freebsd-arm@freebsd.org To: bob prohaska References: <20180212183256.GA75467@www.zefox.net> <20180216060337.GA88230@www.zefox.net> X-Mailer: Apple Mail (2.3445.5.20) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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, 16 Feb 2018 14:19:28 -0000 On 2018-Feb-15, at 10:03 PM, bob prohaska wrote: > On Mon, Feb 12, 2018 at 10:32:56AM -0800, bob prohaska wrote: >> On a Pi3 running r328935 trying to build sources at 329171 a=20 >> make -j2 kernel-toolchain fails with >> /usr/bin/ld: error: duplicate symbol:=20 >>>>> defined at ASTImporter.o:() in archive = /usr/obj/usr/src/arm64.aarch64/tmp/obj-tools/lib/clang/libclang/libclang.a= >>=20 >=20 > Updating sources eventually allowed make kernel-toolchain to build = without > errors. However, make buildkernel still stops, reporting >=20 > In file included from = /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: > = /usr/obj/usr/src/arm64.aarch64/tmp/usr/lib/clang/6.0.0/include/arm_neon.h:= 31:10: fatal error: 'stdint.h' file not found > #include > ^~~~~~~~~~ > 1 error generated. > *** [armv8_crypto_wrap.o] Error code 1 >=20 > This seems rather odd, since find reports files with that name in > several locations within /usr/src: >=20 > root@www:/usr/src # find . -name stdint.h -depth -print > ./sys/sys/stdint.h > ./sys/contrib/zstd/lib/freebsd/stdint.h > ./contrib/llvm/tools/clang/lib/Headers/stdint.h > ./contrib/libc++/include/stdint.h > ./contrib/libstdc++/include/tr1/stdint.h >=20 > To the best of my ability the source tree is unmolested, svnlite info = reports: > root@www:/usr/src # svnlite status . > ? buildkernel.log > ? buildscript > ? installscript > ? kernelscript > ? toolchain.log > ? toolchainscript > root@www:/usr/src #=20 >=20 > The source tree is presently at r329360. See FreeBSD bugzilla 220125: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220125 = You can hand patch the tree (similar to comment 3 but for the clang version in use). Later comments have notes about various places the file might go. If you can get buildworld to work, it will put stdint.h in the right = place. The places that you list are not the places the compiles actively look = in. See comment 9 for the difference between buildworld and kernel-toolchain for where the file is placed. kernel-toolchain does not do the right thing for arm_neon.h to work; arm-neon.h presumes that header, which is not normally part of a FreeBSD kernel build. Your report tells me that this is currently unresolved. =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-arm@freebsd.org Fri Feb 16 17:09:24 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28BDEF00A37 for ; Fri, 16 Feb 2018 17:09:24 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 97290864A2 for ; Fri, 16 Feb 2018 17:09:23 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w1GH9RbX090277 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Feb 2018 09:09:29 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w1GH9RPQ090276; Fri, 16 Feb 2018 09:09:27 -0800 (PST) (envelope-from fbsd) Date: Fri, 16 Feb 2018 09:09:27 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 can't build kernel-toolchain Message-ID: <20180216170927.GA88394@www.zefox.net> References: <20180212183256.GA75467@www.zefox.net> <20180216060337.GA88230@www.zefox.net> <11F7E450-097C-41B3-B494-73106C710AE7@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11F7E450-097C-41B3-B494-73106C710AE7@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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, 16 Feb 2018 17:09:24 -0000 On Fri, Feb 16, 2018 at 06:19:15AM -0800, Mark Millard wrote: > > On 2018-Feb-15, at 10:03 PM, bob prohaska wrote: > > > On Mon, Feb 12, 2018 at 10:32:56AM -0800, bob prohaska wrote: > > > > Updating sources eventually allowed make kernel-toolchain to build without > > errors. However, make buildkernel still stops, reporting > > > > In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: > > /usr/obj/usr/src/arm64.aarch64/tmp/usr/lib/clang/6.0.0/include/arm_neon.h:31:10: fatal error: 'stdint.h' file not found > > #include > > ^~~~~~~~~~ > > 1 error generated. > > *** [armv8_crypto_wrap.o] Error code 1 > > > > See FreeBSD bugzilla 220125: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220125 > > You can hand patch the tree (similar to comment 3 but for > the clang version in use). Later comments have notes about > various places the file might go. > Running cp ./contrib/llvm/tools/clang/lib/Headers/stdint.h /usr/lib/clang/6.0.0/include didn't solve the problem. Using cp /usr/lib/include/stdint.h /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/ does seem to be working. Since this is a self-hosted compile there's hope the resulting kernel will be more stable than r328935. Am I correct in thinking that arm does not correctly recognize when it's self-hosting? Doubtless I'm being naive, but shouldn't that be a fairly straightforward determination? Armv7 gave hints of the same problem, asking that TARGET_ARCH be set in a self-hosting buildworld. That's seemingly fixed, now. Thanks very much! bob prohaska From owner-freebsd-arm@freebsd.org Fri Feb 16 19:18:08 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87AF8F0A247 for ; Fri, 16 Feb 2018 19:18:08 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (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 EBDD86D5E8 for ; Fri, 16 Feb 2018 19:18:07 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: vOOC9ngVM1nOoIHndIbyXQzsY9GJ265A6wUHZ9HK3Jk1IQoo4enn6C35eeRFN7N bZ3o6kSFRJloQIaLuOVvbenP6MrW3TiHywjy8L3A9FxjMECQ0ipdv90kk1A7vrkXP4mak_30NR4Q hNKYkVmY0heBee_tYK6uCC_BbN146_QNBgyg1ix1P3Xxbo_unGkc2FZ7bjTGoQiJOpI2u5hIlXfQ Xh7sBbAVce9MGW2dCeOS5Eaq1ff3TPq2xBCxWbfMQ4jVdBDzoY4oEcsh4FI3GakcyFP.cWxUh432 xRIw7e2WYf9N93hSiqkZSYrNUFM8WkfBDypxl3SJuvfnHIQA9dn3xAiVIaUd0Sn1J7OvNwleJbAA o6HYFMr798gJfpvW7eYqkevjx2RHtZ1fcP8B_bPxj8z7k.pjtJ3PsN8hwbJf7OlulpvxUij.Odzq nMOeCdtpSgLA4CCCv7lQsGCxVoWNq4qbUN8Yg7xFdkZl.WlcfhNA24RGhNQWjPuxnxpPOghc4BQ2 2LXaUWypwNvTknKlfVw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 16 Feb 2018 19:18:00 +0000 Received: from smtp107.rhel.mail.gq1.yahoo.com (EHLO [192.168.1.25]) ([10.211.35.149]) by smtp413.mail.gq1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 90efe63cffcfa20e7f042288e9ec1f03; Fri, 16 Feb 2018 18:57:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: RPI3 can't build kernel-toolchain From: Mark Millard In-Reply-To: <20180216170927.GA88394@www.zefox.net> Date: Fri, 16 Feb 2018 10:57:40 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3F0B778A-E33E-474B-B4AF-73A167F27E36@yahoo.com> References: <20180212183256.GA75467@www.zefox.net> <20180216060337.GA88230@www.zefox.net> <11F7E450-097C-41B3-B494-73106C710AE7@yahoo.com> <20180216170927.GA88394@www.zefox.net> To: bob prohaska 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: Fri, 16 Feb 2018 19:18:08 -0000 On 2018-Feb-16, at 9:09 AM, bob prohaska wrote: > On Fri, Feb 16, 2018 at 06:19:15AM -0800, Mark Millard wrote: >>=20 >> On 2018-Feb-15, at 10:03 PM, bob prohaska wrote: >>=20 >>> On Mon, Feb 12, 2018 at 10:32:56AM -0800, bob prohaska wrote: >>>=20 >>> Updating sources eventually allowed make kernel-toolchain to build = without >>> errors. However, make buildkernel still stops, reporting >>>=20 >>> In file included from = /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: >>> = /usr/obj/usr/src/arm64.aarch64/tmp/usr/lib/clang/6.0.0/include/arm_neon.h:= 31:10: fatal error: 'stdint.h' file not found >>> #include >>> ^~~~~~~~~~ >>> 1 error generated. >>> *** [armv8_crypto_wrap.o] Error code 1 >>>=20 >>=20 >> See FreeBSD bugzilla 220125: >>=20 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220125 = >>=20 >> You can hand patch the tree (similar to comment 3 but for >> the clang version in use). Later comments have notes about >> various places the file might go. >>=20 > Running > cp ./contrib/llvm/tools/clang/lib/Headers/stdint.h = /usr/lib/clang/6.0.0/include > didn't solve the problem.=20 >=20 > Using > cp /usr/lib/include/stdint.h = /usr/obj/usr/src/arm64.aarch64/tmp/usr/include/ > does seem to be working. Since this is a self-hosted compile there's = hope the > resulting kernel will be more stable than r328935. >=20 > Am I correct in thinking that arm does not correctly recognize when = it's=20 > self-hosting? Doubtless I'm being naive, but shouldn't that be a = fairly > straightforward determination? Armv7 gave hints of the same problem, = asking > that TARGET_ARCH be set in a self-hosting buildworld. That's seemingly = fixed,=20 > now. amd64 -> aarch64 cross-builds using kernel-toolchain also failed the same way for buildkernel. In order to cross-build I used buildworld instead (after the build failed the other way). (My FreeBSD time is greatly limited compared to when I was doing that. So I've not synchronized in some time and do not directly know the current status. It has been even longer since I've done a self-hosted build for armv7, aarch64, powerpc, or powerpc64.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-arm@freebsd.org Sat Feb 17 16:27:33 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7302EF1D8EC for ; Sat, 17 Feb 2018 16:27:33 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E681987E5B for ; Sat, 17 Feb 2018 16:27:32 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w1HGRXif093787 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Feb 2018 08:27:33 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w1HGRW8k093786; Sat, 17 Feb 2018 08:27:32 -0800 (PST) (envelope-from fbsd) Date: Sat, 17 Feb 2018 08:27:32 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Pi3 out of swap at < 50% Message-ID: <20180217162732.GA93736@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) 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: Sat, 17 Feb 2018 16:27:33 -0000 Running make -j4 buildworld on a Pi3 at r329360 tends to result in messages similar to: pid 33492 (llvm-tblgen), uid 0, was killed: out of swap space swap_pager: indefinite wait buffer: bufobj: 0, blkno: 11764, size: 28672 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 16080, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 15721, size: 20480 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28139, size: 65536 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 40544, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 58384, size: 65536 pid 49735 (c++), uid 0, was killed: out of swap space swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28470, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 24889, size: 8192 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28736, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 29736, size: 4096 even though swap usage appears to be less than one GB out of two available. So far it's been possible to use the -DNO_CLEAN option with make to pick up where things left off and I've backed down to -j3 to see if that helps. There are two 1 GB swap partitions, one on USB flash and one on the microSD card and both appear to be in use according to swapinfo. There are no warnings in the boot messages and no explicit changes have been made to configuration files apart from adding the swap entries to /etc/fstab. World and kernel are about two weeks out of sync, so top isn't perfectly up-to-date with this kernel; could that account for the mismatch between apparent swap usage and the "out of swap" messages? Thanks for reading, and any ideas! bob prohaska From owner-freebsd-arm@freebsd.org Sat Feb 17 17:34:09 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34D43F2284F for ; Sat, 17 Feb 2018 17:34:09 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A5DC78AA6E; Sat, 17 Feb 2018 17:34:08 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w1HHYEeg093986 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Feb 2018 09:34:15 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w1HHYE0w093985; Sat, 17 Feb 2018 09:34:14 -0800 (PST) (envelope-from fbsd) Date: Sat, 17 Feb 2018 09:34:14 -0800 From: bob prohaska To: Ian Lepore Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Pi3 out of swap at < 50% Message-ID: <20180217173414.GB93736@www.zefox.net> References: <20180217162732.GA93736@www.zefox.net> <1518885801.91697.2.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1518885801.91697.2.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Sat, 17 Feb 2018 17:34:09 -0000 On Sat, Feb 17, 2018 at 09:43:21AM -0700, Ian Lepore wrote: > On Sat, 2018-02-17 at 08:27 -0800, bob prohaska wrote: > > Running make -j4 buildworld on a Pi3 at r329360 tends to result > > in??messages similar to: > > > > pid 33492 (llvm-tblgen), uid 0, was killed: out of swap space > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 11764, size: 28672 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 16080, size: 4096 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 15721, size: 20480 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28139, size: 65536 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 40544, size: 4096 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 58384, size: 65536 > > pid 49735 (c++), uid 0, was killed: out of swap space > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28470, size: 4096 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 24889, size: 8192 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28736, size: 4096 > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 29736, size: 4096 > > > > even though swap usage appears to be less than one GB out of two available. > > > > So far it's been possible to use the -DNO_CLEAN option with make to pick > > up where things left off and I've backed down to -j3 to see if that helps. > > > > There are two 1 GB swap partitions, one on USB flash and one on the microSD > > card and both appear to be in use according to swapinfo. There are no warnings > > in the boot messages and no explicit changes have been made to configuration > > files apart from adding the swap entries to /etc/fstab. > > > > World and kernel are about two weeks out of sync, so top isn't perfectly > > up-to-date with this kernel; could that account for the mismatch between > > apparent swap usage and the "out of swap" messages? > > > > Thanks for reading, and any ideas! > > > > bob prohaska > > I suspect your swap devices are too slow to keep up with instantaneous > demands. ?An sdcard can easily have read and write latencies as big as > 30 seconds; they make pretty poor swap devices (have gstat running in > another window during the build to see what I mean, look at the ms/r > and ms/w columns). ?USB flash drives may not be much better. > I'm watching gstat now. With make -j3 running and three cc processes in the top of top the usual value of ms/r and ms/w is less than 5 ms. An eyeball average is probably less than 10 ms. Before cc got going (make dominant in top) there were very brief excursions to 2000 ms, as you posit, but they didn't last and didn't put any errors on the console. The experiment ended when make stopped with: /usr/src/lib/libc/rpc/auth_time.c:115:10: error: unknown type name 'endpoint' free_eps(endpoint eps[], int num) ^ /usr/src/lib/libc/rpc/auth_time.c:143:8: error: unknown type name 'nis_server' static nis_server * ^ /usr/src/lib/libc/rpc/auth_time.c:144:49: error: unknown type name 'nis_server' get_server(struct sockaddr_in *sin, char *host, nis_server *srv, ^ /usr/src/lib/libc/rpc/auth_time.c:145:5: error: unknown type name 'endpoint' endpoint eps[], int maxep) among others. I'll update sources and restart buildworld with -j4, watching gstat more carefully. Thanks very much for the hint! bob prohaska From owner-freebsd-arm@freebsd.org Sat Feb 17 17:49:49 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0855F2395C for ; Sat, 17 Feb 2018 17:49:49 +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 2DBCB8B440 for ; Sat, 17 Feb 2018 17:49:48 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: de1b5e24-140a-11e8-b951-f99fef315fd9 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id de1b5e24-140a-11e8-b951-f99fef315fd9; Sat, 17 Feb 2018 17:49:14 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w1HHnfVx049827; Sat, 17 Feb 2018 10:49:41 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1518889781.91697.3.camel@freebsd.org> Subject: Re: Pi3 out of swap at < 50% From: Ian Lepore To: bob prohaska Cc: freebsd-arm@freebsd.org Date: Sat, 17 Feb 2018 10:49:41 -0700 In-Reply-To: <20180217173414.GB93736@www.zefox.net> References: <20180217162732.GA93736@www.zefox.net> <1518885801.91697.2.camel@freebsd.org> <20180217173414.GB93736@www.zefox.net> 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: Sat, 17 Feb 2018 17:49:49 -0000 On Sat, 2018-02-17 at 09:34 -0800, bob prohaska wrote: > On Sat, Feb 17, 2018 at 09:43:21AM -0700, Ian Lepore wrote: > > > > On Sat, 2018-02-17 at 08:27 -0800, bob prohaska wrote: > > > > > > Running make -j4 buildworld on a Pi3 at r329360 tends to result > > > in??messages similar to: > > > > > > pid 33492 (llvm-tblgen), uid 0, was killed: out of swap space > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 11764, size: 28672 > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 16080, size: 4096 > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 15721, size: 20480 > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28139, size: 65536 > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 40544, size: 4096 > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 58384, size: 65536 > > > pid 49735 (c++), uid 0, was killed: out of swap space > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28470, size: 4096 > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 24889, size: 8192 > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28736, size: 4096 > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 29736, size: 4096 > > > > > > even though swap usage appears to be less than one GB out of two available. > > > > > > So far it's been possible to use the -DNO_CLEAN option with make to pick > > > up where things left off and I've backed down to -j3 to see if that helps. > > > > > > There are two 1 GB swap partitions, one on USB flash and one on the microSD > > > card and both appear to be in use according to swapinfo. There are no warnings > > > in the boot messages and no explicit changes have been made to configuration > > > files apart from adding the swap entries to /etc/fstab. > > > > > > World and kernel are about two weeks out of sync, so top isn't perfectly > > > up-to-date with this kernel; could that account for the mismatch between > > > apparent swap usage and the "out of swap" messages? > > > > > > Thanks for reading, and any ideas! > > > > > > bob prohaska > > I suspect your swap devices are too slow to keep up with instantaneous > > demands. ?An sdcard can easily have read and write latencies as big as > > 30 seconds; they make pretty poor swap devices (have gstat running in > > another window during the build to see what I mean, look at the ms/r > > and ms/w columns). ?USB flash drives may not be much better. > > > I'm watching gstat now. With make -j3 running and three cc processes in > the top of top the usual value of ms/r and ms/w is less than 5 ms. An > eyeball average is probably less than 10 ms. Before cc got going (make > dominant in top) there were very brief excursions to 2000 ms, as you posit, > but they didn't last and didn't put any errors on the console.  > > The experiment ended when make stopped with: > > /usr/src/lib/libc/rpc/auth_time.c:115:10: error: unknown type name 'endpoint' > free_eps(endpoint eps[], int num) >          ^ > /usr/src/lib/libc/rpc/auth_time.c:143:8: error: unknown type name 'nis_server' > static nis_server * >        ^ > /usr/src/lib/libc/rpc/auth_time.c:144:49: error: unknown type name 'nis_server' > get_server(struct sockaddr_in *sin, char *host, nis_server *srv, >                                                 ^ > /usr/src/lib/libc/rpc/auth_time.c:145:5: error: unknown type name 'endpoint' >     endpoint eps[], int maxep)  > > among others. > > I'll update sources and restart buildworld with -j4, watching gstat more > carefully.  > > Thanks very much for the hint! > > bob prohaska Part of the problem is clang-tblgen, which requires HUGE amounts of ram; if you've gotten beyond that in the build, you may not see any more problems. -- Ian From owner-freebsd-arm@freebsd.org Sat Feb 17 18:26:38 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6428F0185B for ; Sat, 17 Feb 2018 18:26:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 424F28D308; Sat, 17 Feb 2018 18:26:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w1HIQhoD094097 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Feb 2018 10:26:44 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w1HIQhrc094096; Sat, 17 Feb 2018 10:26:43 -0800 (PST) (envelope-from fbsd) Date: Sat, 17 Feb 2018 10:26:43 -0800 From: bob prohaska To: Ian Lepore Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Pi3 out of swap at < 50% Message-ID: <20180217182643.GC93736@www.zefox.net> References: <20180217162732.GA93736@www.zefox.net> <1518885801.91697.2.camel@freebsd.org> <20180217173414.GB93736@www.zefox.net> <1518889781.91697.3.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1518889781.91697.3.camel@freebsd.org> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Sat, 17 Feb 2018 18:26:38 -0000 On Sat, Feb 17, 2018 at 10:49:41AM -0700, Ian Lepore wrote: > On Sat, 2018-02-17 at 09:34 -0800, bob prohaska wrote: > > On Sat, Feb 17, 2018 at 09:43:21AM -0700, Ian Lepore wrote: > > > > > > On Sat, 2018-02-17 at 08:27 -0800, bob prohaska wrote: > > > > > > > > Running make -j4 buildworld on a Pi3 at r329360 tends to result > > > > in??messages similar to: > > > > > > > > pid 33492 (llvm-tblgen), uid 0, was killed: out of swap space > > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 11764, size: 28672 > > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 16080, size: 4096 > > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 15721, size: 20480 > > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28139, size: 65536 > > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 40544, size: 4096 > > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 58384, size: 65536 > > > > pid 49735 (c++), uid 0, was killed: out of swap space > > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28470, size: 4096 > > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 24889, size: 8192 > > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28736, size: 4096 > > > > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 29736, size: 4096 > > > > > > > > even though swap usage appears to be less than one GB out of two available. > > > > > > > > So far it's been possible to use the -DNO_CLEAN option with make to pick > > > > up where things left off and I've backed down to -j3 to see if that helps. > > > > > > > > There are two 1 GB swap partitions, one on USB flash and one on the microSD > > > > card and both appear to be in use according to swapinfo. There are no warnings > > > > in the boot messages and no explicit changes have been made to configuration > > > > files apart from adding the swap entries to /etc/fstab. > > > > > > > > World and kernel are about two weeks out of sync, so top isn't perfectly > > > > up-to-date with this kernel; could that account for the mismatch between > > > > apparent swap usage and the "out of swap" messages? > > > > > > > > Thanks for reading, and any ideas! > > > > > > > > bob prohaska > > > I suspect your swap devices are too slow to keep up with instantaneous > > > demands. ?An sdcard can easily have read and write latencies as big as > > > 30 seconds; they make pretty poor swap devices (have gstat running in > > > another window during the build to see what I mean, look at the ms/r > > > and ms/w columns). ?USB flash drives may not be much better. > > > > > I'm watching gstat now. With make -j3 running and three cc processes in > > the top of top the usual value of ms/r and ms/w is less than 5 ms. An > > eyeball average is probably less than 10 ms. Before cc got going (make > > dominant in top) there were very brief excursions to 2000 ms, as you posit, > > but they didn't last and didn't put any errors on the console.? > > > > The experiment ended when make stopped with: > > > > /usr/src/lib/libc/rpc/auth_time.c:115:10: error: unknown type name 'endpoint' > > free_eps(endpoint eps[], int num) > > ?????????^ > > /usr/src/lib/libc/rpc/auth_time.c:143:8: error: unknown type name 'nis_server' > > static nis_server * > > ???????^ > > /usr/src/lib/libc/rpc/auth_time.c:144:49: error: unknown type name 'nis_server' > > get_server(struct sockaddr_in *sin, char *host, nis_server *srv, > > ????????????????????????????????????????????????^ > > /usr/src/lib/libc/rpc/auth_time.c:145:5: error: unknown type name 'endpoint' > > ????endpoint eps[], int maxep)? > > > > among others. > > > > I'll update sources and restart buildworld with -j4, watching gstat more > > carefully.? > > > > Thanks very much for the hint! > > > > bob prohaska > > Part of the problem is clang-tblgen, which requires HUGE amounts of > ram; if you've gotten beyond that in the build, you may not see any > more problems. > A Pi2 with 2 GB of swap on a usb flash drive got all the way into building libraries before running out of swap with a little over 1.5 GB in use, which is the actual limit. I realize that's armv7, not arm64, but it makes me wonder if perhaps swap isn't being freed when no longer needed. I've restarted buildworld with -DNO_CLEAN and am simply hoping for further progress. Meanwhile, restarting buildworld at j6 on the Pi3 with sources at 329462 didn't clear the compiler error. Can you hazard a guess whether 329462 should compile correctly? If so I'll clean manually and start over, if not I'll wait for an update or a pointer to a self-consistent revision. Thanks very much! bob prohaska From owner-freebsd-arm@freebsd.org Sat Feb 17 18:38:26 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A11EF026C3 for ; Sat, 17 Feb 2018 18:38:26 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from cow.apple.relay.mailchannels.net (cow.apple.relay.mailchannels.net [23.83.208.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 870DB8DB29 for ; Sat, 17 Feb 2018 18:38:25 +0000 (UTC) (envelope-from ian@freebsd.org) X-Sender-Id: _forwarded-from|67.177.211.60 Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 7C2A23E101B for ; Sat, 17 Feb 2018 16:43:29 +0000 (UTC) Received: from outbound1a.eu.mailhop.org (unknown [100.96.30.35]) (Authenticated sender: duocircle) by relay.mailchannels.net (Postfix) with ESMTPA id DC16E3E1225 for ; Sat, 17 Feb 2018 16:43:28 +0000 (UTC) X-Sender-Id: _forwarded-from|67.177.211.60 Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [172.18.55.173]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.13.1); Sat, 17 Feb 2018 16:43:29 +0000 X-MC-Relay: Forwarding X-MailChannels-SenderId: _forwarded-from|67.177.211.60 X-MailChannels-Auth-Id: duocircle X-Relation-Abiding: 5c6ef04150164e6a_1518885809284_2497903115 X-MC-Loop-Signature: 1518885809284:722261833 X-MC-Ingress-Time: 1518885809283 X-MHO-User: ab47e7ec-1401-11e8-91c6-33ffc249f3e8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id ab47e7ec-1401-11e8-91c6-33ffc249f3e8; Sat, 17 Feb 2018 16:43:24 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w1HGhL7C049721; Sat, 17 Feb 2018 09:43:21 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1518885801.91697.2.camel@freebsd.org> Subject: Re: Pi3 out of swap at < 50% From: Ian Lepore To: bob prohaska , freebsd-arm@freebsd.org Date: Sat, 17 Feb 2018 09:43:21 -0700 In-Reply-To: <20180217162732.GA93736@www.zefox.net> References: <20180217162732.GA93736@www.zefox.net> 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: Sat, 17 Feb 2018 18:38:26 -0000 On Sat, 2018-02-17 at 08:27 -0800, bob prohaska wrote: > Running make -j4 buildworld on a Pi3 at r329360 tends to result > in  messages similar to: > > pid 33492 (llvm-tblgen), uid 0, was killed: out of swap space > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 11764, size: 28672 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 16080, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 15721, size: 20480 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28139, size: 65536 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 40544, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 58384, size: 65536 > pid 49735 (c++), uid 0, was killed: out of swap space > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28470, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 24889, size: 8192 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 28736, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 29736, size: 4096 > > even though swap usage appears to be less than one GB out of two available. > > So far it's been possible to use the -DNO_CLEAN option with make to pick > up where things left off and I've backed down to -j3 to see if that helps. > > There are two 1 GB swap partitions, one on USB flash and one on the microSD > card and both appear to be in use according to swapinfo. There are no warnings > in the boot messages and no explicit changes have been made to configuration > files apart from adding the swap entries to /etc/fstab. > > World and kernel are about two weeks out of sync, so top isn't perfectly > up-to-date with this kernel; could that account for the mismatch between > apparent swap usage and the "out of swap" messages? > > Thanks for reading, and any ideas! > > bob prohaska I suspect your swap devices are too slow to keep up with instantaneous demands.  An sdcard can easily have read and write latencies as big as 30 seconds; they make pretty poor swap devices (have gstat running in another window during the build to see what I mean, look at the ms/r and ms/w columns).  USB flash drives may not be much better. -- Ian From owner-freebsd-arm@freebsd.org Sat Feb 17 20:18:30 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B02E6F0B1A8 for ; Sat, 17 Feb 2018 20:18:30 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orthanc.ca", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33E8E6A40E; Sat, 17 Feb 2018 20:18:30 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from localhost (l6 [IPv6:0:0:0:0:0:0:0:1]) by orthanc.ca (8.15.2/8.15.2) with ESMTPS id w1HKISoP063707 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Feb 2018 12:18:28 -0800 (PST) (envelope-from lyndon@orthanc.ca) Date: Sat, 17 Feb 2018 12:18:28 -0800 (PST) From: Lyndon Nerenberg To: Ian Lepore cc: bob prohaska , freebsd-arm@freebsd.org Subject: Re: Pi3 out of swap at < 50% In-Reply-To: <1518885801.91697.2.camel@freebsd.org> Message-ID: References: <20180217162732.GA93736@www.zefox.net> <1518885801.91697.2.camel@freebsd.org> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: The Frobozz Magic Homing Pigeon Company MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, MISSING_DATE,MISSING_MID,NO_RECEIVED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on orthanc.ca 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: Sat, 17 Feb 2018 20:18:30 -0000 > I suspect your swap devices are too slow to keep up with instantaneous > demands. ?An sdcard can easily have read and write latencies as big as > 30 seconds; they make pretty poor swap devices (have gstat running in > another window during the build to see what I mean, look at the ms/r > and ms/w columns). ?USB flash drives may not be much better. If it's an option, mount your swap partition over NFS from another server, and configure the mount settings to be as asynchronous as possible. From owner-freebsd-arm@freebsd.org Sat Feb 17 22:57:34 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A21DF1895A for ; Sat, 17 Feb 2018 22:57:34 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 BE8DA71A7B for ; Sat, 17 Feb 2018 22:57:33 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8AC3220D3D for ; Sat, 17 Feb 2018 17:57:27 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Sat, 17 Feb 2018 17:57:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=Bjy6JIbnxc0quZSe4ZTZQ6JMWadmI 6KL9a5kd/nFzJ8=; b=qEX4WcNCyxirXAQ2e0h5QlWxAXqiUSlIsBlDo5dm/oHxu bNn53c6aqPdxIHBFi+UtcL1C7V5Ng7Yw7vHimTe8hioH6Y47V51CPG1f2J6MwyR2 AcWOlG2H9PdxPcBEPGaNbum4H7JnEcvhn1990pnpFSTBfN1jHFUo7FtrOv7yGAsC xpRfnWVRK7jiG6lbtfEp1aZwNXOxHVAayuLvzE7iikQgra6DaBwa1pf8zkn6bJXz ++ChXzyU3Aw9wltG2DC28NBsgtV5Ul3UQXaCUOpamFYrTFnzCe58TUIh6159pdu5 98itgFPWM/SGyCKgJn6leE+uP/2YNBjdZ6VjLYpIg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Bjy6JI bnxc0quZSe4ZTZQ6JMWadmI6KL9a5kd/nFzJ8=; b=nAnqIsBPYmKrC+UkhU4aMh Q9FfjCCsd2YysmBn4L7rGA+/8fJjVWSYHkxuRsv/tHHmabalDCWqlLgpSvl1A8zM 7J+H/8M/dblRDVDY/j8UcK2+i2krGM0MR3BPMWJinNcM+VNBPdA6pKUm7ETDMbBI yM7br4cZPiMgvg3mTmGYkBheZfHETcP8KYQGAW/wewmh7qnF5QWp+4V6d3qIaCiI /jUWDN8PJrG8s3s9bDvb/7fcEFIr9O05AioQZwCDBiYsdHAmDAjboe/LihsBvLDY gDXTK8PbMEgfxtlkIqNTUA17LJsgIZRqMzcC+y4w2BFIe0jupnhWKR4RQMI0rT0Q == X-ME-Sender: Received: from desktop.parsley.growveg.org (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id 1303E24547 for ; Sat, 17 Feb 2018 17:57:26 -0500 (EST) Subject: Re: Pi3 out of swap at < 50% To: freebsd-arm@freebsd.org References: <20180217162732.GA93736@www.zefox.net> <1518885801.91697.2.camel@freebsd.org> From: tech-lists Message-ID: <9bf0ca6e-1916-3f4d-71fe-0515fe6a717f@zyxst.net> Date: Sat, 17 Feb 2018 22:57:25 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1518885801.91697.2.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 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: Sat, 17 Feb 2018 22:57:34 -0000 On 17/02/2018 16:43, Ian Lepore wrote: > I suspect your swap devices are too slow to keep up with instantaneous > demands.  An sdcard can easily have read and write latencies as big as > 30 seconds; they make pretty poor swap devices (have gstat running in > another window during the build to see what I mean, look at the ms/r > and ms/w columns).  USB flash drives may not be much better. I have a portable 1TB HD plugged into one of the USB ports with 2GB configured as swap.. and things like /tmp and /var/tmp are mounted on the ufs filesystem on the HD in order to reduce I/O on the sd card. Seems to work. Also have GPU memory set to 32 iirc as it's running headless. -- J. From owner-freebsd-arm@freebsd.org Sat Feb 17 23:51:05 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6461F1D10F for ; Sat, 17 Feb 2018 23:51:05 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from sonic314-14.consmr.mail.bf2.yahoo.com (sonic314-14.consmr.mail.bf2.yahoo.com [74.6.132.124]) (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 6171773C47 for ; Sat, 17 Feb 2018 23:51:05 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) X-YMail-OSG: 1_HaCZgVM1kFmlnsCO6QL1KC9SwdT423wOrpojxAZligS2.GjLuNOZ3X.r6tuDS LlT2Oh7KXpoDHLk5rFaeYN1lCGgEgeNSxC_1IsHJVlZ6X9kh.kXLnhWBmFmimq5I4nK7kaxoRXx7 l5An.5efWy3ZSjBsKlaSRWwLC8iYjLrj84Kod0KcejFz4rgAicVD60wNcrytyy26W2.0N72wGIY. DkQ2JUZPpc.u3uQy.HgcmaxjquvnwUIGpFJl0uDM2hGf6UFKZGq_LjN65bnAckpruIvlWqiOrqZ. lWjedu1oANlzs22yZbX7.j0o8lYLoEHm.faTtNjOKMOkBHQrlH15URT8xtbzUa8AGblPJOx9DTcv awAAKITvF__zyJsgsrmLTh2pkWMMk2O4YKe11tj5wCisi_GBd0qVd8XlsjgZ3DeB9dzVoglWD1Ph S3ZuFATZzCTb.5QWEEsmC7uU7ciJ_.kZdf8f0.nHs99blk2TVfmhfDTDzIvAsiDgsJzV4Jj_exil lj8zupz9jmv5Jn5qBZdlddYJqyeQg9GPvP1ZQrQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Sat, 17 Feb 2018 23:50:59 +0000 Received: from smtp105.rhel.mail.bf1.yahoo.com (EHLO [192.168.1.21]) ([98.139.231.38]) by smtp404.mail.bf1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 9a97f0721b4a70d01ebbefbec660782f for ; Sat, 17 Feb 2018 23:50:57 +0000 (UTC) From: Thomas Skibo Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Entering kdb in early boot Message-Id: Date: Sat, 17 Feb 2018 15:50:55 -0800 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Sat, 17 Feb 2018 23:51:05 -0000 Hello: I noticed that ARM machdep.c doesn=E2=80=99t support entering kdb on = boot (boot -d from the loader). I looked to see how other architectures = implement it and came up with an easy patch. While trying to get this to work, I discovered that machdep_boot.c = doesn=E2=80=99t include opt_ddb.h and so the kernel symbols weren=E2=80=99= t getting loaded into the debugger early in the boot (see the call to = db_fetch_ksymtab() in freebsd_parse_boot_param()). I have never noticed = any problems with symbols in kdb before. I wonder how those symbols = eventually get loaded and wonder if now I'm calling it twice. In any case, I=E2=80=99d be happy to put this up on phabricator if you = like. =E2=80=94Thomas=20 =E2=80=94=E2=80=94 Thomas Skibo ThomasSkibo@yahoo.com