From owner-freebsd-arm@freebsd.org Sun Sep 23 23:20: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 03DC0109CFDB for ; Sun, 23 Sep 2018 23:20:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-15.consmr.mail.bf2.yahoo.com (sonic310-15.consmr.mail.bf2.yahoo.com [74.6.135.125]) (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 95786872B0 for ; Sun, 23 Sep 2018 23:20:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: egZBz8kVM1kWzsI4SjydlXtTkybsIpFZnpZau_BQtG2uvVyqCzK3BUoabMBbDxA o6m8kjuPEiWn1ijvlbFu.Q5JFKJhFlNmgjjxr72CaDSbWLAvKUrjqlx6yaQqP0tC2ZWDFGVotSnm f5.zfBQgYDWgUyGSjlZaz95BrpOr2j60snf7fSl6qpWO1iI.7TJa9wsA9JQ0caDUZhmiNCoZZKMz tSi1EDFjVGh.pQ.hXp2cYdOGvaADRwLcw3nmWG08xuiNxKE41A2plKJoHFQfKNohZSqEEWOQov2e x7EXLSg3hiIG2Juq_HVYgkwcJHBVtDE2Ck9W4o7fJyAsP4vA7Y_5vnj.PIMRbeV01dB8qOVYce2q EMShLm3bUBGsG_rffEokecK322pr5o7BVYKk5rmvjO6Vyc0GtOrdQtmzWiXoHtF8aio8WAqCsE_r 3n2AqTw5Eq2aMVBhFxUCM5LKl97LFLwR5Oq6sAKiAk5096_74Su2hVPF2DVGW98DK.yyX6iTMnnc pkgsv4mlJyjU9KGkw65MydEXRH6eaTSGZ3IerLoUkwXL_6mODLCrwuvwNEpkNj1Mg33Q95vr2z3G PI21E3sB47SDogJJpIb0pb_WXIaXz.hjhodCqfopWK6rJAuCcfMJJMxaNJg4SNDET0b9ZMoHc0DV yiOPGS8EBl9nqRXUoKe_a0CUlPH.2u_DkiyVZyfrJOuH65qyuoeLkpWAOF89TnRToK346dvbGnCS oV7SLXVaG_bUDlQ39hbEMmQSsNgJFsTlHBNf6G6Yi2ajcsNTB5ctzWNEHH7zYezBgtIIcp.t3HVj mM4hc8GDmp9uHnLmkiieYXZV_r26GnODMdmqknsnfh9OEEE7kvCc7UVQej.hWFwVDnMu8Ocsy_Vd x3hNBlcbrb7pqWUqFujt_pYjoNSIGQFCN.6nrB0QekcAs3YX8PwaH1FY10DTT_0ifXo0u3vRU.L3 imVfUJMkgakjxWa8JsliuN78Wn3icyjQtQObbJwgx60kJM6YlCJt37kUualp90UXexOZq29CPdDX JhVUiqErhR2g- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Sun, 23 Sep 2018 23:19:57 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp413.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2fbebe06943e6c6ff8d2a31290691be3; Sun, 23 Sep 2018 23:19:53 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: For comparison, head -r338860 based -j4 buildworld buildkernel time and swap usage on Pine64+ 2GB Message-Id: <94BB0AF9-6B81-430F-9897-26382B201F85@yahoo.com> Date: Sun, 23 Sep 2018 16:19:50 -0700 Cc: freebsd-arm To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2018 23:20:04 -0000 As I remember Bob Prohaska's fastest -j4 buildworld buildkernel full-builds on his rpi3 in his recent experiments were somewhat over 22 hours and had fairly extensive swapping. This report allows comparison to a particular Pine64+ 2GB based -j4 buildworld buildkernel, although I give details Bob P. did not. I also was not running any monitoring other than a modified top, not logged to a file. /usr/obj/cortexA53_clang_alt did not exist when this started, so this is for a from-scratch build. (The below avoids some >>> prefix line text.) QUOTE Script started on Sun Sep 23 00:28:14 2018 Command: env __MAKE_CONF=3D/root/src.configs/make.conf SRCCONF=3D/dev/null= = SRC_ENV_CONF=3D/root/src.configs/src.conf.cortexA53-clang-bootstrap.aarch6= 4-host WITH_META_MODE=3Dyes = MAKEOBJDIRPREFIX=3D/usr/obj/cortexA53_clang_alt/arm64.aarch64 make -j4 = buildworld buildkernel [Creating objdir = /usr/obj/cortexA53_clang_alt/arm64.aarch64/usr/src/arm64.aarch64...] --- buildworld --- make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined = that CC=3Dcc matches the source tree. Not bootstrapping a = cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined = that LD=3Dld matches the source tree. Not bootstrapping a cross-linker. --- buildworld_prologue --- -------------------------------------------------------------- World build started on Sun Sep 23 00:28:16 PDT 2018 -------------------------------------------------------------- . . . -------------------------------------------------------------- Kernel build for GENERIC-NODBG completed on Sun Sep 23 14:11:05 PDT = 2018 -------------------------------------------------------------- Command exit status: 0 Script done on Sun Sep 23 14:11:05 2018 END QUOTE So somewhat under 13 hours 45 minutes when the bootstrap avoided the cross-compiler and cross-linker builds when I'm building -r338860 via selecting: #WITH_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D WITH_SYSTEM_LINKER=3D # #CPUTYPE=3Dsoft WITH_LIBCPLUSPLUS=3D #WITH_LLD_BOOTSTRAP=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D #WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D WITH_LLD_IS_LD=3D WITHOUT_BINUTILS=3D WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D When I build for cortex-A53's I use: CFLAGS.clang+=3D -mcpu=3Dcortex-a53 CXXFLAGS.clang+=3D -mcpu=3Dcortex-a53 CPPFLAGS.clang+=3D -mcpu=3Dcortex-a53 ACFLAGS.arm64cpuid.S+=3D -mcpu=3Dcortex-a53+crypto ACFLAGS.aesv8-armx.S+=3D -mcpu=3Dcortex-a53+crypto ACFLAGS.ghashv8-armx.S+=3D -mcpu=3Dcortex-a53+crypto The environment that did the build had been built that way as well. Similarly for the GENERIC-NODBG used: # more /usr/src/sys/arm64/conf/GENERIC-NODBG # # GENERIC -- Custom configuration for the arm64/aarch64 # include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: #options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones nooptions BUF_TRACKING nooptions FULL_BUF_TRACKING I've modified top in my active environments to report: Maximum Observed Mem Active (reported: 1501M) Maximum Observed Swap Used (reported: 198M) Minimum Observed Mem Free (reported: 33M) After the buildworld buildkernel completed top was showing: Mem: 79M Active, 1501M MaxObsActive, 1352M Inact, 1056K Laundry, 347M = Wired, 201M Buf, 194M Free, 33M MinObsFree Swap: 3584M Total, 19M Used, 198M MaxObsUsed, 3565M Free I had enabled using and used an e.MMC in DDR52 mode on a microsd adapter, using TRIM on the UFS file system (with the DISCARD bit set). I also had to enable DISCARD. "Enable(d)" here means source code changes in both cases. No other types of storage devices were connected so swap was on the same device as the UFS file system partition. After the build: # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/label/PINE64P2Groot 109101 50910 49462 51% / devfs 0 0 0 100% /dev /dev/label/PINE642GAboot 63 8 55 13% /boot/efi I have in /boot/loader.conf : vfs.ffs.dotrimcons=3D1 and in /etc/sysctl.conf : vm.pageout_oom_seq=3D120 vfs.ffs.dotrimcons=3D1 (But vfs.ffs.dotrimcons defaults to 1 now as I remember. As I understand vm.pageout_oom_seq still defaults to 12. 120 might not be sufficient for a rpi3 to buildworld buildkernel in some contexts, or even for the Pine64+ 2GB if the storage I/O is sufficiently problematical for latencies that occur.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Sep 25 06:06:23 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 1AC0910A6FB5 for ; Tue, 25 Sep 2018 06:06:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-20.consmr.mail.ne1.yahoo.com (sonic304-20.consmr.mail.ne1.yahoo.com [66.163.191.146]) (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 3DE528353B for ; Tue, 25 Sep 2018 06:06:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: VTejUakVM1mCmGDAsLMr4BV5RuT0vnAnPaeNPs1u4n1c7W8u.q_TlUGi0PuHBFM v8aXufxaKGOjT5VeGkpz8Sz8YUtG3wAeDzgvVMAn8Wscx9gxiFlDxqz5AiI_9hQb7fLo2GHQqtQk CF7rS9esSTg9UK043BkwnmQZHqLggvzYqanYabGy4n40KnUW2uzia9b7Y75f.OiAiCD3dmRp7yLg Wrt26fjwOWBigdDhJFXxQdIod05kvat.Ws2VxvL7oJ_HxSFm3lHA7eYBTTe3vLEgmC.TOuHE9hix 14QQpfr5EhK76Hql01P.yLnxAEaw2iU0scTkCfBndbtsz6do9XLy.fL.Xf..PGepZSmYKI_CM42B w4ypHgLknc5_1SbVhGMCN0X1BMzg942fpzGZyMpVaw1Eiu5Gd8pZorgxPWnMM8_14ZkYmruz4pGF 2fETb2GIAU9RpdN83nN3d7Ccn0rFsxhapYj.x1a2wMGmnhxlKrjelfDqJK2.0rUxcPXqssWGhktn Lpp73cTT3ldx5uS6yIDkI.03cfu8KlH55wL5lFeSMif6Y0TdTY31AtRRvxh_avLCj7Z64QwEQ_51 3wIYxaBYvY.C9dX5Dud_IaSswmUlzIHPc2320GErm7V3.uCl1kofyaNPScz2f_7Y68_8TERDun4O D1Dy1b1LxtZXH00Ybe7L_MNxDj4uuK6MpyEQrHIl5CnkVL8h8QEhAdz98VyX8kTu8UVKyRWmvmKB AGpkQeuqsOlH.JdRsX6B0LZp5pDYt4nNXYnQKULP8l8fsHmFgYgPfzptvOrB4Fbuxnf2QQk4Uq3u Tz1azu8KCZqhslUZonVoFJohQK3plFDwb9juTCF6Vb194W82gzcyvWtk7GqHuYT8jomiH9.D3qyx GjTQgRLnUN6XtfuzO6RqR0sQMpcEUJxkdRZY2wfS6WsTKycevdj4537EVCYMOHx7Jlv70.q56nDJ 2CapulI_iAtduYVnALFi1JLZg6.kh1KgrXWby7JlT1TfSKmvzl8AeTLTEGl9ofNFkFnuRdEKqQr_ 7guaYKSD78_Yn2jKyRUq3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Tue, 25 Sep 2018 06:06:14 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp424.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 0fed609f0ea4a33f79ee49c30d780788; Tue, 25 Sep 2018 06:06:14 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: aarch64 head -r338921 vs. man ld vs. ld -v : man ld describes GNU when ld is lld Message-Id: Date: Mon, 24 Sep 2018 23:06:12 -0700 To: FreeBSD Toolchain , FreeBSD Current , freebsd-arm X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 06:06:23 -0000 [This is based on buildworld buildkernel and installing.] I've updated to: # uname -apKU FreeBSD pine64 12.0-ALPHA7 FreeBSD 12.0-ALPHA7 #17 r338921M: Mon Sep 24 = 19:19:08 PDT 2018 = markmi@pine64:/usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64= /sys/GENERIC-NODBG arm64 aarch64 1200084 1200084 For which: # ld -v LLD 6.0.1 (FreeBSD 335540-1200004) (compatible with GNU linkers) But man ld reports GNU/BFD material: # man ld LD(1) GNU Development Tools = LD(1) NAME ld - The GNU linker SYNOPSIS ld [options] objfile ... DESCRIPTION . . . This man page does not describe the command language; see the ld = entry in "info" for full details on the command language and on other = aspects of the GNU linker. This version of ld uses the general purpose BFD libraries to = operate on object files. . . . Aside from its flexibility, the GNU linker is more helpful than = other linkers in providing diagnostic information. . . . The GNU linker ld is meant to cover a broad range of situations, = and to be as compatible as possible with other linkers. As a result, = you have many choices to control its behavior. . . . (I do not see such in my amd64 builds.) I'm not claiming this is new: I just noticed. For reference on the Pine64+ 2GB aarch64 system being used for this (avoiding >>> prefixes on lines): # = ~/sys_build_scripts.aarch64-host/make_cortexA53_nodebug_clang_bootstrap-aa= rch64-host.sh check-old Script started, output file is = /root/sys_typescripts/typescript_make_cortexA53_nodebug_clang_bootstrap-aa= rch64-host-2018-09-24:22:53:10 ... Checking for old files ... Checking for old libraries ... Checking for old directories To remove old files and directories run 'make delete-old'. To remove old libraries run 'make delete-old-libs'. Script done, output file is = /root/sys_typescripts/typescript_make_cortexA53_nodebug_clang_bootstrap-aa= rch64-host-2018-09-24:22:53:10 (So I'd run delete-old before this.) # more = ~/sys_build_scripts.aarch64-host/make_cortexA53_nodebug_clang_bootstrap-aa= rch64-host.sh kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_cortexA53_nodebug_clang_bootstrap-aarch6= 4-host-$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" \ SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.cortexA53-clang-bootstrap.aarch= 64-host" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/cortexA53_clang/arm64.aarch64" \ make $* # more ~/src.configs/src.conf.cortexA53-clang-bootstrap.aarch64-host=20 TO_TYPE=3Daarch64 # KERNCONF=3DGENERIC-NODBG TARGET=3Darm64 .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # #WITH_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D WITH_SYSTEM_LINKER=3D # #CPUTYPE=3Dsoft WITH_LIBCPLUSPLUS=3D #WITH_LLD_BOOTSTRAP=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D #WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D WITH_LLD_IS_LD=3D WITHOUT_BINUTILS=3D WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # # Use of the .clang 's here avoids # interfering with other CFLAGS # usage, such as ?=3D usage. CFLAGS.clang+=3D -mcpu=3Dcortex-a53 CXXFLAGS.clang+=3D -mcpu=3Dcortex-a53 CPPFLAGS.clang+=3D -mcpu=3Dcortex-a53 ACFLAGS.arm64cpuid.S+=3D -mcpu=3Dcortex-a53+crypto ACFLAGS.aesv8-armx.S+=3D -mcpu=3Dcortex-a53+crypto ACFLAGS.ghashv8-armx.S+=3D -mcpu=3Dcortex-a53+crypto # more ~/src.configs/make.conf CFLAGS.gcc+=3D -v LDFLAGS.lld+=3D -Wl,--no-threads =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Sep 25 23:03:06 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 0DB051092B2F for ; Tue, 25 Sep 2018 23:03:06 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out.migadu.com (out.migadu.com [91.121.113.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.migadu.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F96E84FC8 for ; Tue, 25 Sep 2018 23:03:04 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: (Migadu outbound); Wed, 26 Sep 2018 01:01:52 +0200 Authentication-Results: out.migadu.com; auth=pass (plain) Received: from [192.168.1.141] ([62.122.208.146]) by out.migadu.com (Haraka/2.8.16) with ESMTPSA id 115BAA36-C480-403F-8867-DFA8BC29FF14.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 verify=FAIL); Wed, 26 Sep 2018 01:01:51 +0200 Date: Wed, 26 Sep 2018 02:01:49 +0300 From: Greg V Subject: Re: Poor virtio performance on Scaleway ARM systems To: Peter Jeremy Cc: freebsd-arm@freebsd.org Message-Id: <1537916509.1915.0@smtp.migadu.com> In-Reply-To: <20180916184657.GB24416@server.rulingia.com> References: <20180916184657.GB24416@server.rulingia.com> X-Mailer: geary/0.12.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed DKIM-Signature: v=1; a=rsa-sha256; bh=/JrXlWGSlH8EfRp46QtzT1s0TjNkDnIFQq5TE8anpGQ=; c=relaxed/simple; d=unrelenting.technology; h=from:subject:date:to; s=default; b=ivHKxyd9UVXvrS5F/6LId/z1sJVhqSfMXBojnjjYiuH9pZcF6iLWxO4ArnmeoOCnAghPQap6+AZlRHUtTz+3GT3YFfzDK8+sSkwSBfSBJDrXn7knNKh4uwu+6mULRqpnssUY9laCFah3nvxIRHCYIZS+54jewxsVFll7eRHCK1U= X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 23:03:06 -0000 On Sun, Sep 16, 2018 at 9:46 PM, Peter Jeremy wrote: > I have been playing with the 4-core ARM64 VPSs on > https://www.scaleway.com > and notice that the disk I/O performance (using virtio_blk) is > abyssmal. > Using "dd if=/dev/{vda|vtbd0} of=/dev/null bs=256k count=4096", I get > 400-500MBps, whilst under FreeBSD-12, I get about 5MBps. I've > checked on a > couple of instances and both Linux & FreeBSD on the same instance and > get > similar results. Linux & FreeBSD are both using a virtio block device > attached to the PCI bus. Rebuilding FreeBSD to turn off all the > debugging > has no effect. > > The only oddity I've found is that FreeBSD is reporting very high > interrupt > rates on gic0,p11, gic0,s4 and gic0,s5 whilst disk I/O is occurring. > Unfortunately, I can't tell what is attached to those interrupts (it's > not obvious from the dmesg and reported as "+"). Hmm, about the only interesting thing I saw in dmesg: its0: mem 0x8080000-0x809ffff on gic0 its0: GITS_BASER0: unable to be updated: a9070000afe80607 != a907000040ec0607 device_attach: its0 attach returned 6 its0: mem 0x8080000-0x809ffff on gic0 its0: Could not allocate memory device_attach: its0 attach returned 6 [some repeated attach attempts] But it's not deterministic, I managed to reboot without the error. From owner-freebsd-arm@freebsd.org Wed Sep 26 11:54:17 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 9F1BE10AA240 for ; Wed, 26 Sep 2018 11:54:17 +0000 (UTC) (envelope-from locke@airmail.cc) Received: from cock.li (cock.li [185.100.85.212]) (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 3D70B7A163 for ; Wed, 26 Sep 2018 11:54:17 +0000 (UTC) (envelope-from locke@airmail.cc) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on cock.li X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,NO_RECEIVED,NO_RELAYS shortcircuit=_SCTYPE_ autolearn=disabled version=3.4.1 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=airmail.cc; s=mail; t=1537962848; bh=+gzDHKnna0uG4kutL5oL3NnbEV8qBEOtZ6hY1grJ49Q=; h=Date:From:To:Subject:From; b=xkOlJMEt4nWF0J5926ZR/Jte78JIIash87gPlB/1dq+iZxMIdrquEnOqSGrPWqxY8 hgSS4OeTXuEJDTKw9DPxXFXuTZht3bi+1PGeQo0a54KHTcZvNwMbIZb6AqpPSFf0aF bfJEKU3a5N1DiN8HEnVMz9RGUQmxromiDaKyiPtu7qFDq1VvCzF2uKs/Pp0ZFTO1RO m2EIjIoCwcvpOMB750ySeL59ehX/wgrr+TxdvJDzRy5SuZtxexpu7BPaN/lHJvioQM cpzcMrgvZfEHMSrnbNJ8k0U2Cvw5EUB3BPdkGfZ61rAvtUa0tImK41eeUJjynKWya1 vq534Q8WO2hDw== Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 26 Sep 2018 11:54:08 +0000 From: locke@airmail.cc To: freebsd-arm@freebsd.org Subject: dwc ethernet Rock64 on 100mbit Message-ID: X-Sender: locke@airmail.cc User-Agent: Roundcube Webmail/1.3.6 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 11:54:17 -0000 When I use the ethernet adapter on the Rock64 I don't get any connection when I connect it to some 100Base TX network. I see packages on the ethernet interface but they never seem to make it on the wire. Netbooting as well as ethernet works when the other end is also Gbit. Can anyone confirm this issue? From owner-freebsd-arm@freebsd.org Fri Sep 28 16:47:15 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 97FEF10B4ACD for ; Fri, 28 Sep 2018 16:47:15 +0000 (UTC) (envelope-from pygr@sonic.net) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 36C7E79D39 for ; Fri, 28 Sep 2018 16:47:15 +0000 (UTC) (envelope-from pygr@sonic.net) Received: from [10.137.113.129] (108-169-4-40.dynamic.dsl.sonic.net [108.169.4.40] (may be forged)) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id w8SGa5n9012415 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 28 Sep 2018 09:36:05 -0700 From: glenn Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: ClearFog Base -- "status: no carrier" for mvneta1 Message-Id: <03261C47-F7E5-46D6-9A91-B8FFDD96FDE3@sonic.net> Date: Fri, 28 Sep 2018 09:36:04 -0700 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-Sonic-CAuth: UmFuZG9tSVbNWPMGbm5X0HchG7aR+SfMTR54Nb+Rdh5iJ3giC4lsQVUfHyBwwVOPtm9S7LeBBahNaQARPwjxW/B4a+mWZ/9F X-Sonic-ID: C;Vt0DmDzD6BGyPILirVfHYg== M;sIdFmDzD6BGyPILirVfHYg== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2018 16:47:15 -0000 With a recent build from source (FreeBSD 12.0-ALPHA7 FreeBSD = 12.0-ALPHA7 7fe1a714461(master) ARMADA38X arm) the ethernet port on a = ClearFog Base near the USB sockets works well, but the port near the SFP = cage doesn=E2=80=99t. ifconfig shows "mvneta1: status: no carrier=E2=80=9D= .=20 Both ports are connected to a gigabit switch. The green link LED on the = ClearFog Base for mvneta0 is on most of the time, but flickering; the = green link LED for mvneta1 is on without flickering. On the switch, the = corresponding link LED for mvneta0 is on constantly, the LED for mvneta1 = is off.=20 I don=E2=80=99t believe it=E2=80=99s a hardware issue, because, if the = patch cables are swapped at the board, mvneta1 still shows no carrier = and which LED on the switch is illuminated swaps. Also, without touching = the cables or switch, Debian can be booted up using a different SD card, = and both ethernet ports are functional with no special action taken. The device tree file being used is compiled from = armada-388-clearfog-base.dts in the FreeBSD source, but edited to allow = the serial console to work. What might it take to get that second ethernet port to work? A = modification of the device tree file? A modification of the mvneta or = miibus driver? A modification of u-boot? Or, perhaps, just a simple = configuration step? Glenn= From owner-freebsd-arm@freebsd.org Sat Sep 29 18:52: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 440BE10A8774 for ; Sat, 29 Sep 2018 18:52:24 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 B652283664 for ; Sat, 29 Sep 2018 18:52: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 w8TIqErv058436 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 29 Sep 2018 11:52:16 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w8TIqDVk058435; Sat, 29 Sep 2018 11:52:13 -0700 (PDT) (envelope-from fbsd) Date: Sat, 29 Sep 2018 11:52:13 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Timeout poll on interrupt endpoint for RPI3 with keyboard and mouse Message-ID: <20180929185213.GA58381@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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2018 18:52:24 -0000 For the first time in a few months I connected a monitor, Dell keyboard and mouse to my Pi3, presently running 12.0-ALPHA7 r338964 GENERIC arm64 which have all worked well since I got the Pi3 around six months ago. With the peripherals connected, the serial console spews Timeout poll on interrupt endpoint and does not seem to accept normal inputs, so it isn't possible to get into the debugger, boot an old kernel or otherwise try to sort out what's going on. disconnecting the monitor had no effect. Removing the keyboard/mouse restores normal behavior. Anybody got a hint what might be wrong? FWIW, this OS/kernel pair were compiled and installed with neither mouse/keyboard nor monitor connected. I wouldn't expect that to matter, but... Thanks for reading, bob prohaska