From owner-freebsd-arm@freebsd.org Sun Sep 16 09:25:45 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 07D18109C3B7; Sun, 16 Sep 2018 09:25:45 +0000 (UTC) (envelope-from pstef@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A883F84A70; Sun, 16 Sep 2018 09:25:44 +0000 (UTC) (envelope-from pstef@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1403) id 8595B15A8D; Sun, 16 Sep 2018 09:25:44 +0000 (UTC) Date: Sun, 16 Sep 2018 11:25:44 +0200 From: "Piotr P. Stefaniak" To: Mark Millard Cc: freebsd-arm , FreeBSD Current Subject: Re: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context Message-ID: <20180916092544.GK53055@freefall.freebsd.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) 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, 16 Sep 2018 09:25:45 -0000 On 2018-09-11 02:44:49, Mark Millard wrote: >usr.bin/indent/functional_test:nsac -> failed: atf-check failed; see the output of the test for details [0.151s] >usr.bin/indent/functional_test:sac -> failed: atf-check failed; see the output of the test for details [0.150s] Those were predictable since r334944 and before r336601, so I don't know how it happens that you're getting them with r338518. From owner-freebsd-arm@freebsd.org Sun Sep 16 12:06: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 3120610A03ED for ; Sun, 16 Sep 2018 12:06:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-20.consmr.mail.bf2.yahoo.com (sonic312-20.consmr.mail.bf2.yahoo.com [74.6.128.82]) (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 B0F9589A08 for ; Sun, 16 Sep 2018 12:06:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: te6dNIsVM1kF2C8gmql.v4016t0xF3SJPfkKAASisuru8ROlyypc43MJzLd7C0U uXNJgnVgXSkxjiJGRKiaADFjMc2ZaY8zdAUoFDzmkWaH13FSFgGCPsiMyX.8HeLBv9U7fnIkorQO Yqbi7PusRaPTxQ.8_uf6Sxi1e9iW3PwxHOZrDl1kr6g8fBBNB331Y2Nv.exaKfunWUjx6lcT9Ppa q7ZeLhlep7beY4MTMcNUXaW6C25FTbH01jmsyzI0JKA2RkGPdsrBV9vwSyVdgsAN_1W0Mfd4jHjv TFAjoGDDh8xctsF8QrYtFW.MNGac1CqVRGyTBQcHZLwT5uCOVz5frGlDgxzUIRrMjtVwLbN9IfYb siONGD1PhrOgcINiBi6HMKW2WftTP1ZmbDNFJWD98u9uY.jUBkPzKWnioeRDlc_YmZuMWu1mONoL iDPuPBl_hw07DRhGCZgSlqD1SUnf880.s.v5k4LvDcECQQYcwBTul_wkVlagtd9vR_bAb1ZJOEeh RWqsFsbhE8FOpPoA47f02e_py0.3inNW5yDLN0RVbpcbNQ9YEB0qDlbB6Y0ORAYw5hezW9BQWGO9 _7fq.KtxHod8oUnajqzsgvcH.FyAyGzUSgk8SbHcd4iTiwweqoeXEiF_rcuKoa40SjEWXsD6mabB XbpF3bUanlvijLnCVdZxXOHEeHNGaN0x5uaDMQsK04hYn1yAcQ0OIsVoS8DvaGs3ReAmxxyjkSri tiewzyoC7vM1ztqzwq6atAyvpKmN19WEw1JKKT2FWGabWVu267XeyNOiZzAnXJqeFUW0knporYF8 coatl0PFIZzvGZIUVN5TOlYy0soDMWZLMnreBjsxMHrLGTATUJkQZYCXqSYquzSaRGdIrKXwUWl3 .gnFFKJ_rtVhE7jONNXk.LGPVqCoKQ9jys763JoiFOw9.OS5VAdCa.p5gTfXZgSD2Z9uQGr8QMqM bCAbCwT0wk.yRcFeRUqNr88FWRUWPrY2GiAqESSl_O2vqol9TXUogbAw.yf6W_g1RwU02sLKB.wm ARTbbONdvow-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Sun, 16 Sep 2018 12:06:29 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp423.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID eaec93886b593d4509947a2f775b6ce9; Sun, 16 Sep 2018 12:06:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context From: Mark Millard In-Reply-To: <20180916092544.GK53055@freefall.freebsd.org> Date: Sun, 16 Sep 2018 05:06:23 -0700 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180916092544.GK53055@freefall.freebsd.org> To: "Piotr P. Stefaniak" 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, 16 Sep 2018 12:06:36 -0000 On 2018-Sep-16, at 2:25 AM, Piotr P. Stefaniak = wrote: > On 2018-09-11 02:44:49, Mark Millard wrote: >> usr.bin/indent/functional_test:nsac -> failed: atf-check failed; = see the output of the test for details [0.151s] >> usr.bin/indent/functional_test:sac -> failed: atf-check failed; see = the output of the test for details [0.150s] >=20 > Those were predictable since r334944 and before r336601, so I don't = know > how it happens that you're getting them with r338518. >=20 Hmm: # ls -lTdt /usr/tests/usr.bin/indent/* -r--r--r-- 1 root wheel 121 Sep 13 22:53:30 2018 = /usr/tests/usr.bin/indent/Kyuafile . . . -r--r--r-- 1 root wheel 295 Sep 13 22:53:29 2018 = /usr/tests/usr.bin/indent/binary.0 -r--r--r-- 1 root wheel 92 May 1 19:35:24 2018 = /usr/tests/usr.bin/indent/sac.0.pro -r--r--r-- 1 root wheel 130 May 1 19:35:24 2018 = /usr/tests/usr.bin/indent/sac.0.stdout -r--r--r-- 1 root wheel 122 May 1 19:35:24 2018 = /usr/tests/usr.bin/indent/sac.0 -r--r--r-- 1 root wheel 94 May 1 19:35:24 2018 = /usr/tests/usr.bin/indent/nsac.0.pro -r--r--r-- 1 root wheel 130 May 1 19:35:24 2018 = /usr/tests/usr.bin/indent/nsac.0.stdout -r--r--r-- 1 root wheel 123 May 1 19:35:24 2018 = /usr/tests/usr.bin/indent/nsac.0 vs. ( note: usr.bin vs usr/bin ): Modified: head/ObsoleteFiles.inc = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D --- head/ObsoleteFiles.inc Sun Jul 22 12:04:21 2018 = (r336600) +++ head/ObsoleteFiles.inc Sun Jul 22 12:45:02 2018 = (r336601) @@ -38,6 +38,13 @@ # xargs -n1 | sort | uniq -d; # done =20 +# 20180722: indent(1) option renamed, test files follow +OLD_FILES+=3Dusr/bin/indent/tests/nsac.0 +OLD_FILES+=3Dusr/bin/indent/tests/nsac.0.pro +OLD_FILES+=3Dusr/bin/indent/tests/nsac.0.stdout +OLD_FILES+=3Dusr/bin/indent/tests/sac.0 +OLD_FILES+=3Dusr/bin/indent/tests/sac.0.pro +OLD_FILES+=3Dusr/bin/indent/tests/sac.0.stdout # 20180721: move of libmlx5.so.1 and libibverbs.so.1 OLD_LIBS+=3Dusr/lib/libmlx5.so.1 OLD_LIBS+=3Dusr/lib/libibverbs.so.1 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Sep 16 17:50:40 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 2EDC610A6AEF; Sun, 16 Sep 2018 17:50:40 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mailout.stack.nl (mailout05.stack.nl [IPv6:2001:610:1108:5010::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.stack.nl", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C6BA171C92; Sun, 16 Sep 2018 17:50:39 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from toad2.stack.nl (toad2.stack.nl [IPv6:2001:610:1108:5010::161]) by mailout.stack.nl (Postfix) with ESMTP id C27B44B; Sun, 16 Sep 2018 19:50:29 +0200 (CEST) Received: by toad2.stack.nl (Postfix, from userid 1677) id BB603892CD; Sun, 16 Sep 2018 19:50:29 +0200 (CEST) Date: Sun, 16 Sep 2018 19:50:29 +0200 From: Jilles Tjoelker To: Mark Millard Cc: freebsd-arm , FreeBSD Current Subject: Re: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context Message-ID: <20180916175029.GA55717@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) 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, 16 Sep 2018 17:50:40 -0000 On Tue, Sep 11, 2018 at 08:48:03AM -0700, Mark Millard wrote: > [Adding listing broken tests, but ignoring sys/cddl/zfs/ ones. > lib/libc/string/memcmp_test:diff is one of them.] > ===> Broken tests > lib/libc/string/memcmp_test:diff -> broken: Premature exit; test case received signal 6 (core dumped) [3.962s] The problem here is that our definition of memcmp() is tighter than the one in the standards and glibc. We define the return value to be the difference between the first differing bytes, while the standards and glibc only define the sign (negative, zero or positive). Looking at contrib/cortex-strings/src/aarch64/memcmp.S, a bic pos, pos, #7 after the clz may help. On another note, the comment just below that, /* But we need to zero-extend (char is unsigned) the value and then perform a signed 32-bit subtraction. */ shows a wrong reason for doing the right thing since memcmp (as well as strcmp and strncmp) are defined to compare based on unsigned chars, regardless of the signedness of char. -- Jilles Tjoelker From owner-freebsd-arm@freebsd.org Sun Sep 16 18: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 732BF10A7C8A for ; Sun, 16 Sep 2018 18:47:15 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vtr.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A510C7C912 for ; Sun, 16 Sep 2018 18:47:14 +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 vtr.rulingia.com (8.15.2/8.15.2) with ESMTPS id w8GIl4Y4070518 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 17 Sep 2018 04:47:10 +1000 (AEST) (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 w8GIkvoL043548 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 17 Sep 2018 04:46:57 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id w8GIkvs9043547 for freebsd-arm@freebsd.org; Mon, 17 Sep 2018 04:46:57 +1000 (AEST) (envelope-from peter) Date: Mon, 17 Sep 2018 04:46:57 +1000 From: Peter Jeremy To: freebsd-arm@freebsd.org Subject: Poor virtio performance on Scaleway ARM systems Message-ID: <20180916184657.GB24416@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.10.0 (2018-05-17) 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, 16 Sep 2018 18:47:15 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=3D/dev/{vda|vtbd0} of=3D/dev/null bs=3D256k count=3D4096", I g= et 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 "+"). I've done some searching and have only found general FUD ("FreeBSD virtio isn't any good") and nothing specifically related to Scaleway. Can anyone suggest where to look for a solution? --=20 Peter Jeremy --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAluepSFfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzQbeQ/+MhJX+N2kake7NTA8ReIMqKwMOZWqCjCrtEi4R2xkBxhocR/fUddXfewS 4DOqLgjQnLTkpEJGn0aksE2PEhmDr3cdj8J6wSPVun02/OxGKbWCbGutLayioMHe LUQPbyV3o/nqehsUq4gmxgdx1SXk//OTE4cxSffXqVHZmv1eF8G2EaVNh/N6lmyd lkMmnLPnvgdhFUqjc+oMMYvsNUKo8aTo+dsjS/w/G0TaZ0VQz4RlX1dKnbn9Xhq3 LZfMYItwME9XvrtFbMel8/yP1CEp0PF7GdLOSeiwhCzLrBRAbWk22wNGrTMQsUu5 tgNU3yV2TrCmRZrPzqGsFwlkWfjiw+BlZmipkWn3NcKetW7mgNp1OcHIR0dA3XJK 7dKRI/ccqXvmWYbB97yKO5IwEim4XAZ2s4BNfi5MAM79urz1n+oDry8LWMFoo7cv 1gZ2LB8lL8yg7iqefdkk4F4qmXgkzxcNbzFhTcfOOu40LUmmOS/N9MVD6+axHBbn wPlS020yfGapwObnH9c2N9qysVHZBPXiGbX0cHTPZELJF743m7XWxjXHGKc456Nh GUnq4sT70cwrFcWm6StuMIF5H15m2FUaqNcik5so8mfbmriMFwtbvFsLhOk5LPoX WCWUa3wJonMxKDKcsQl6i2+/ytgpNF5hFFYK9dtV/d4Fb30lmEw= =M/U+ -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-arm@freebsd.org Sun Sep 16 20:21:45 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 E45B010A9735 for ; Sun, 16 Sep 2018 20:21:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-4.consmr.mail.bf2.yahoo.com (sonic303-4.consmr.mail.bf2.yahoo.com [74.6.131.43]) (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 8DA2C7EAA2 for ; Sun, 16 Sep 2018 20:21:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: JSOFQo4VM1mYQcBz.40qWfs251XMRE0ME4h1gaAt.KnD1kpEn36wMCwmlZj7blv qIliHFSA6Baernz4IMSOLFiS3RxS.HMRGE6GXnF8zy7s0X9amV7Krggminoxtq74IljZXnDBvCZW 46BM2SH26OUxfHWOC_KgX8BtZzcKfD8q_IulXafdZO_sHFVzFRYU5plrY9KvRzDjGD22uPaVWE8P OISLMrng2lxiv5WSYdh.1iIWtbXQw.tIl_gFXaDHbpCfxUlaFZWmGa9KXpymjqD8PJC8_O2b5n6d sFUdqgpAEa6jrrX0pEFdYyDCpSxw0eEBJHhpZ786.p0COVMej9s7umBWCuOzzjGSR3YKkJkzPnWH iT8LHBODza7PqG2tm9GG83XGILjJc4H9JbYt17JzeQMLuTK2efZKpy2arYqQ7sDrmKJVAdBP4k7d 92_DJ5WdrE0Jzjz8gMGVwas_w5Oc7qtgqclHXiR1IEcAJDLkDQa48nyROz8EtbzOHWn2F0CR7H2y 3eyVUqiLZAVp_7h4nlj1pNEvyO40pXfnax4U2lO4y9OVmcj2Y8rRLNBcLoaR0H92n.w2yutskU2u YZc_l7qX9R9HdgJnMsNUm_xz9AURFSstwESy3g1epxxxHvs_9n08N0.v9U7cdTLCWlOxSd4a7i7P j_DMc.eZN35iizgIIYEO6_oA5_Jx5b2nR3Q5npSRrdBpnspGlGh1.4KN0ddV7NLT.M5.PdOLMXNn OFkfmY84vG6BKV_WfiBnEGeNrAahVA9mrKXb3dlVmmQnto2BXpj1r6L6L6pszym5hWq9Rive6KGX bWI8hN9FF9fckho_dRpo9EanvWdTXFefrpo4JcwsXYdum7.qyJnqc8bW.EI.gherKENtov6Lt8N2 zLTvdpwkvNLLa5ixpSUTZKg8aQPi.HtcISjn4sGHl4FKpif4fQIbZb80z6ZKZRVRM0P4bpCmYDQw D9Uqxdb8VxpnYn8QXAjbopn7ZimhWEtPRcw_xGnOBY7LhJMp7LKebzPF9l68OPtS6dUM7Ko79u2G sJzrN0RITexM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Sun, 16 Sep 2018 20:21:38 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp428.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 52cbd135864599ae043a5a6370b2329a; Sun, 16 Sep 2018 20:21:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context From: Mark Millard In-Reply-To: <20180916175029.GA55717@stack.nl> Date: Sun, 16 Sep 2018 13:21:33 -0700 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180916175029.GA55717@stack.nl> To: Jilles Tjoelker 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, 16 Sep 2018 20:21:45 -0000 On 2018-Sep-16, at 10:50 AM, Jilles Tjoelker wrote: > On Tue, Sep 11, 2018 at 08:48:03AM -0700, Mark Millard wrote: >> [Adding listing broken tests, but ignoring sys/cddl/zfs/ ones. >> lib/libc/string/memcmp_test:diff is one of them.] >=20 >> =3D=3D=3D> Broken tests >> lib/libc/string/memcmp_test:diff -> broken: Premature exit; test = case received signal 6 (core dumped) [3.962s] >=20 > The problem here is that our definition of memcmp() is tighter than = the > one in the standards and glibc. We define the return value to be the > difference between the first differing bytes, while the standards and > glibc only define the sign (negative, zero or positive). >=20 > Looking at contrib/cortex-strings/src/aarch64/memcmp.S, a > bic pos, pos, #7 after the clz may help. >=20 > On another note, the comment just below that, >=20 > /* But we need to zero-extend (char is unsigned) the value and = then > perform a signed 32-bit subtraction. */ >=20 > shows a wrong reason for doing the right thing since memcmp (as well = as > strcmp and strncmp) are defined to compare based on unsigned chars, > regardless of the signedness of char. Ahh, standard are so much fun: there are so many to choose from. I looked up ISO/IEC 9899:2011 (E) and its 7.24.4.1 "The memcmp = function". It makes no such explicit claim about using using unsigned chars for the comparison standard: QUOTE of the Description part: The memcmp function compares the first n characters of the object = pointed by s1 to the first n characters of the object pointed by s2. END QUOTE QUOTE of the Returns part: The memcmp function returns an integer greater than, equal to, or less = than zero, accordingly as the object pointed to by s1 is greater than, equal to, or = less than the object pointed to by s2. END QUOTE If I had to guess the intent of "characters" would be based on the char = type for C11. I did not find anything about the issue in the C99 rationale = that I also happen to have available to look at. For all I know, POSIX or other standards may be more explicit and not agree. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Sep 16 20:50:32 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 0104410AA0CC; Sun, 16 Sep 2018 20:50:32 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mailout.stack.nl (mailout05.stack.nl [131.155.140.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.stack.nl", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9536E7FC6B; Sun, 16 Sep 2018 20:50:31 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from toad2.stack.nl (toad2.stack.nl [IPv6:2001:610:1108:5010::161]) by mailout.stack.nl (Postfix) with ESMTP id B65E54B; Sun, 16 Sep 2018 22:50:29 +0200 (CEST) Received: by toad2.stack.nl (Postfix, from userid 1677) id AEC86892D3; Sun, 16 Sep 2018 22:50:29 +0200 (CEST) Date: Sun, 16 Sep 2018 22:50:29 +0200 From: Jilles Tjoelker To: Mark Millard Cc: freebsd-arm , FreeBSD Current Subject: Re: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context Message-ID: <20180916205029.GB55717@stack.nl> References: <20180916175029.GA55717@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) 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, 16 Sep 2018 20:50:32 -0000 On Sun, Sep 16, 2018 at 01:21:33PM -0700, Mark Millard wrote: > On 2018-Sep-16, at 10:50 AM, Jilles Tjoelker wrote: > > On another note, the comment just below that, > > /* But we need to zero-extend (char is unsigned) the value and then > > perform a signed 32-bit subtraction. */ > > shows a wrong reason for doing the right thing since memcmp (as well as > > strcmp and strncmp) are defined to compare based on unsigned chars, > > regardless of the signedness of char. > Ahh, standard are so much fun: there are so many to choose from. > I looked up ISO/IEC 9899:2011 (E) and its 7.24.4.1 "The memcmp function". > It makes no such explicit claim about using using unsigned chars for > the comparison standard: > QUOTE of the Description part: > The memcmp function compares the first n characters of the object pointed > by s1 to the first n characters of the object pointed by s2. > END QUOTE > QUOTE of the Returns part: > The memcmp function returns an integer greater than, equal to, or less > than zero, accordingly as the object pointed to by s1 is greater than, > equal to, or less than the object pointed to by s2. > END QUOTE > If I had to guess the intent of "characters" would be based on the > char type for C11. I did not find anything about the issue in the C99 > rationale that I also happen to have available to look at. In C99, C11 and C17, the text about using unsigned chars is under "Comparison functions" and it applies to memcmp, strcmp and strncmp (which are documented together in the section). > For all I know, POSIX or other standards may be more explicit and not > agree. POSIX does not document memcmp, strcmp and strncmp close together and copies the text about using unsigned chars to each of them. This means that it agrees with the C standards. -- Jilles Tjoelker From owner-freebsd-arm@freebsd.org Sun Sep 16 21:18: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 970CE1080C43 for ; Sun, 16 Sep 2018 21:18:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-22.consmr.mail.gq1.yahoo.com (sonic311-22.consmr.mail.gq1.yahoo.com [98.137.65.203]) (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 44123819C9 for ; Sun, 16 Sep 2018 21:18:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: aBOTvt4VM1lOU_VaJz55xDv4BQPkvbWowWnPwNVfyFWcl.b2e7TsLQmfDxoK6MB XXiclXZIosmO9XDy5O0kG5m5lv3d9Dl9ihbLgmWddNz85HMT2PCC.OL_B8nHoOYlfRmFt4uJUSWI _rTMGsZAPlJT0qqe21uIOhH5Qp4Rsxv3yvDzFEgS51BQOIE3zO17N_IWp0ceUn6jo7ho55Kmb3pa Q.QMevQEE8Zumsqs7Id5KK4Hd_BBdLz963FUozagwESR.D33aiSOrw16AAIHlgmu6eLJVwgZJoOh JoaJDEG7.rACViSrh8UIyWAt2h8aFLGqzphiq5YXfTEbDKvlZAqEyjModv4gMUGtyZi_MVblI5zP M.d9k.8qUvz9Mk0nKsIbumgPzTKzAF4tztvdmrU.ngH3BcxQx2yWaFrakjVJdzvD8lGX6EClH_ed V5Cd6zKHzetdbt6MswYOcRyI0Vz6t.wMakXwDLPr1VWSb7wkOfgHgaL8dtCan23Dx24vTiED03zo TkQWWUDEdpCBJriO7EELPrPPuMTiPnXJMgdKly_dXaq59n4_RuSM2edZFZluUv49FIiKvqF61nZk IlWB21Bmvbco.d0q.8SMNGMihU5h.eUklAr79kP0nNXOOfJ33A6srmrtrV1ptMyDH2pmAffBx0ls wQgSRx4Ya8xqujKdgTdBBt4T7VzOQOEX158kxKFydYRdTtXAzZXh5KS2Vmnp4NbghGppQwmloSfL 2nJImixxO2T9Zu8pu9GAesewhnWiEXiFQQBx573fRtj2.q.f7Vp_WZYm93mIjryDlAglBruSfIZr uvLry6KV7xSxTWYrTXjZvwhXHNVxqN9iPsfkl4kZy4orgCvqjTABUNIw.q.xtIva0lUz.9QtufC_ A4XZO5b0MJ2mbqmuf17p2xuZpPI17mq8vrHgsNHNB747OF8oK4Yl25MfmBfyR8yBtGPeczPhjqBf TibBDZBlbVnIiNlOWA2SbgtXq4H95NS3om56UXE.DWRjwViA2CEUxxcQPwlbj0KIzkf5rw5BMbJ8 5PIWdXFR2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 16 Sep 2018 21:18:21 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp420.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID eb64288a0ca7d1d2582ace146573d790; Sun, 16 Sep 2018 20:58:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: FYI: devel/kyua 14 failures for head -r338518M based build in a Pine64+ 2GB (aarch64 / cortexA53 / A64) context From: Mark Millard In-Reply-To: <20180916205029.GB55717@stack.nl> Date: Sun, 16 Sep 2018 13:58:04 -0700 Cc: freebsd-arm , FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: <8FD86880-11E4-49E3-848E-B05FF23A37B5@yahoo.com> References: <20180916175029.GA55717@stack.nl> <20180916205029.GB55717@stack.nl> To: Jilles Tjoelker 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, 16 Sep 2018 21:18:23 -0000 On 2018-Sep-16, at 1:50 PM, Jilles Tjoelker wrote: > On Sun, Sep 16, 2018 at 01:21:33PM -0700, Mark Millard wrote: >> On 2018-Sep-16, at 10:50 AM, Jilles Tjoelker wrote: > >>> On another note, the comment just below that, > >>> /* But we need to zero-extend (char is unsigned) the value and then >>> perform a signed 32-bit subtraction. */ > >>> shows a wrong reason for doing the right thing since memcmp (as well as >>> strcmp and strncmp) are defined to compare based on unsigned chars, >>> regardless of the signedness of char. > >> Ahh, standard are so much fun: there are so many to choose from. > >> I looked up ISO/IEC 9899:2011 (E) and its 7.24.4.1 "The memcmp function". >> It makes no such explicit claim about using using unsigned chars for >> the comparison standard: > >> QUOTE of the Description part: >> The memcmp function compares the first n characters of the object pointed >> by s1 to the first n characters of the object pointed by s2. >> END QUOTE > >> QUOTE of the Returns part: >> The memcmp function returns an integer greater than, equal to, or less >> than zero, accordingly as the object pointed to by s1 is greater than, >> equal to, or less than the object pointed to by s2. >> END QUOTE > >> If I had to guess the intent of "characters" would be based on the >> char type for C11. I did not find anything about the issue in the C99 >> rationale that I also happen to have available to look at. > > In C99, C11 and C17, the text about using unsigned chars is under > "Comparison functions" and it applies to memcmp, strcmp and strncmp > (which are documented together in the section). > >> For all I know, POSIX or other standards may be more explicit and not >> agree. > > POSIX does not document memcmp, strcmp and strncmp close together and > copies the text about using unsigned chars to each of them. This means > that it agrees with the C standards. > Thanks for noting the factored-out material in the C11 standard. Sorry for the noise of missing that factorization when I looked up memcmp. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Sep 17 16:13:14 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 05CD810A169C for ; Mon, 17 Sep 2018 16:13:14 +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 5148082907 for ; Mon, 17 Sep 2018 16:13:13 +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 w8HGD4iw076503 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Sep 2018 09:13:05 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w8HGD4hr076502; Mon, 17 Sep 2018 09:13:04 -0700 (PDT) (envelope-from fbsd) Date: Mon, 17 Sep 2018 09:13:04 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Camcontrol reprobe da0 causes kernel panic Message-ID: <20180917161304.GA76451@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: Mon, 17 Sep 2018 16:13:14 -0000 Trying to run, in single-user on a pi3 at FreeBSD 12.0-ALPHA6 r338691 arm64 # camcontrol reprobe da0 instigated panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ /usr/src/sys/cam/scsi/scsi_da.c:2123 cpuid = 0 time = 1537199321 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc = 0xffff00000069b2ec lr = 0xffff0000000d952c sp = 0xffff0000517c8410 fp = 0xffff0000517c8620 db_trace_self_wrapper() at vpanic+0x1a8 pc = 0xffff0000000d952c lr = 0xffff000000388a18 sp = 0xffff0000517c8630 fp = 0xffff0000517c86e0 vpanic() at panic+0x44 pc = 0xffff000000388a18 lr = 0xffff0000003887c4 sp = 0xffff0000517c86f0 fp = 0xffff0000517c8770 panic() at __mtx_lock_sleep+0x3f8 pc = 0xffff0000003887c4 lr = 0xffff000000369924 sp = 0xffff0000517c8780 fp = 0xffff0000517c87f0 __mtx_lock_sleep() at __mtx_lock_flags+0xe0 pc = 0xffff000000369924 lr = 0xffff000000369440 sp = 0xffff0000517c8800 fp = 0xffff0000517c8840 __mtx_lock_flags() at daasync+0x64 pc = 0xffff000000369440 lr = 0xffff0000000364e8 sp = 0xffff0000517c8850 fp = 0xffff0000517c88a0 daasync() at xpt_async_process_dev+0x204 pc = 0xffff0000000364e8 lr = 0xffff00000001f5cc sp = 0xffff0000517c88b0 fp = 0xffff0000517c8900 xpt_async_process_dev() at xptdevicetraverse+0x9c pc = 0xffff00000001f5cc lr = 0xffff00000001e5b4 sp = 0xffff0000517c8910 fp = 0xffff0000517c8950 xptdevicetraverse() at xpttargettraverse+0x78 pc = 0xffff00000001e5b4 lr = 0xffff00000001e320 sp = 0xffff0000517c8960 fp = 0xffff0000517c89a0 xpttargettraverse() at xpt_async_process+0x130 pc = 0xffff00000001e320 lr = 0xffff00000001b2ec sp = 0xffff0000517c89b0 fp = 0xffff0000517c8ac0 xpt_async_process() at xpt_done_process+0x358 pc = 0xffff00000001b2ec lr = 0xffff00000001bcb8 sp = 0xffff0000517c8ad0 fp = 0xffff0000517c8af0 xpt_done_process() at xpt_done_td+0x104 pc = 0xffff00000001bcb8 lr = 0xffff00000001dac0 sp = 0xffff0000517c8b00 fp = 0xffff0000517c8b50 xpt_done_td() at fork_exit+0x7c pc = 0xffff00000001dac0 lr = 0xffff00000034b0d4 sp = 0xffff0000517c8b60 fp = 0xffff0000517c8b90 fork_exit() at fork_trampoline+0x10 pc = 0xffff00000034b0d4 lr = 0xffff0000006b572c sp = 0xffff0000517c8ba0 fp = 0x0000000000000000 KDB: enter: panic [ thread pid 7 tid 100033 ] Stopped at 0 db> The circumstance was a desire to enlarge a partition, da0p7, mounted on /usr/ports, which turned out to be too small. The man page for growfs suggests using for my predicament camcontrol reprobe da0 gpart recover da0 gpart resize -i 7 da0 growfs /dev/da0p7 There's nothing irreplaceable on the system, I just wanted to see if www/chromium will build and run. The root filesystem is on mmcsd0. Thanks for reading, and any workarounds. bob prohaska From owner-freebsd-arm@freebsd.org Mon Sep 17 20:35:19 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 8F9FB10A6CC3 for ; Mon, 17 Sep 2018 20:35:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.ne1.yahoo.com (sonic309-21.consmr.mail.ne1.yahoo.com [66.163.184.147]) (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 300738C2AB for ; Mon, 17 Sep 2018 20:35:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: zsDuwxwVM1kbVPBRKhdnz_aX_b43Bv_givosqtwWjT3Rt9UrQXRalwgyUeWnpHK jQmDJQvRyZMhClRMi_fRv2RzIGqEHmDMP5Rk8yM.LbBeVImMsyKw8jQEZEQCdFq.5ir5oofclwPP 16H.ZRqzGpxhKoke_5mN1I_wDZ.un9KW.lbk2uwSYUP8QahYXU8_nuOPhmtKqJQx4mLtU54pmY3P kDskhLUbpgJDcX4Vic1Q8BMfNpPil__YshJUaQnNL9H3Wh9K4cFlhY_ER_e_hEuIqZRWxsrpjEke nt8S3ko7TuNgSGid82ZEwIUPEUkUcy_HsN7JD.AkiPhKxErX27hesXxOCHNVPvKc2q0NRAM.oOLC B.eJnpX3RGwugCHFO3Kfx2ebsYmUJKPfDiKMEnVN5p6qCjLwW5oYcw8xMmL99H9q_byRk_nZ4icn TQmK6cCXPI8wNVEYcwiPW2BGZ1EP36dGBxn_QHS0SUW0jWifV6ysPhrD7714AiDh0RhEVVf.LMmH C2TwFxJQyDDXL8w5QKSo.3av.Um0wlmhpmw1Jgf4AD6u5bIeGN1Xou1pXh1yU_fE_ExIVUtNYiWE rLD7e0ZZ8LlYQeduAubaj9hqctgJIp4VI93fyMNOfOPOjGmrB6_X_UeBQSfy29E4Q9KLoYbEJIHB wv.aWhUn1ool_Mbj3mFvOhZwn6iX9PfF7xAoKmH3w1lkjWFZ_JWj1MEw7iD4qrtJiI5aNVp9VDH6 SPGJMftgYYMVgq9CKJUFqpClgqRniiQv13e3twcOx3oJLTJIt_EDoRS8an1IQ.K_FbmCFqC1GTGl QiJ6NnpV5m2PFC898x4hiNk1njdM5lGy_yAHw7vTF6C1wnm6Gq4h4foUSSqTKAfuoh_Sw5VY8YW9 smYtNJWJTANZw2XxnMb0BnrLm4U5s2JZVOPyLT9xuv4o3wHKguGtGodAKID_0c.VINygKq32l7XU Se1ilGDCYg0hZG0YooBCzCpe6u..d9CZZoIhbIFnzQxUNlaTz.Mv4CW_D9WXIn1_4Fuh9qPKgXQW XHmVPl4wHEtuE Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Mon, 17 Sep 2018 20:35:17 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp406.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 25a4b4b42780b2c31cc8ffe067ddea17; Mon, 17 Sep 2018 20:35:15 +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: An experiment in enabling discard with e.MMC trim on a Pine64+ 2GB (based on head -r338675) Message-Id: <670AF48A-77BF-4246-BD80-9D067CB05DE3@yahoo.com> Date: Mon, 17 Sep 2018 13:35:14 -0700 To: freebsd-hackers@freebsd.org, 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: Mon, 17 Sep 2018 20:35:19 -0000 As stands this is just investigatory material. Also, I first had to enable using an e.MMC on a microsd card adapter on the Pine64+ 2GB, so those changes are listed too. The goal was for e.MMC 4.5+ to enable the discard bit with the trim bit to allow an e.MMC to not necessarily force the trim'ed data to become all zeros or all ones: the performance command trim variant that does not require data removal (but allows it). (I did nothing about discard from the modern sd card material. I doubt that I have any test context for that.) Unfortunately I have a very narrow range as far as test environments go currently: just Pine64+ 2GB and just one type of e.MMC in use. But for the context that I have it seems to be working. The discard-enabling related changes are in: /usr/src/sys/dev/mmc/mmcreg.h (an additional #define) /usr/src/sys/dev/mmc/mmcsd.c As stands I have nothing for overriding e.MMC 4.5+ using discard with trim (when trim is enabled via the historical criteria). If trim without discard worked but with discard did not for some device this could be a problem. Also: if trim without discard is desired for security reasons it would be a problem. But what I have here is sufficient for my basic testing. The Pine64+ 2GB e.MMC-on-adapter enabling changes are in: /usr/src/sys/dev/mmc/mmcreg.h (a renamed #define as a form of = commentary) /usr/src/sys/dev/mmc/mmc.c (not really Pine64+ 2GB or A64 specific) /usr/src/sys/arm/allwinner/aw_mmc.c (MMC_CAP_SIGNALING_180 part: Pine64+ = 2GB or A64 specific) (So mmcreg.h has something for each part.) I expect the mmc.c change is a generic correction to more accurately follow the e.MMC DDR52 definition as far as voltage requirements go. But it was driven by the Pine64+ 2GB properties leading to wanting the change. The changes for discard ( and mmcreg.h ) are: Index: /usr/src/sys/dev/mmc/mmcreg.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/dev/mmc/mmcreg.h (revision 338675) +++ /usr/src/sys/dev/mmc/mmcreg.h (working copy) @@ -463,7 +463,7 @@ =20 #define EXT_CSD_CARD_TYPE_HS_26 0x0001 #define EXT_CSD_CARD_TYPE_HS_52 0x0002 -#define EXT_CSD_CARD_TYPE_DDR_52_1_8V 0x0004 +#define EXT_CSD_CARD_TYPE_DDR_52_3V_OR_1_8V 0x0004 #define EXT_CSD_CARD_TYPE_DDR_52_1_2V 0x0008 #define EXT_CSD_CARD_TYPE_HS200_1_8V 0x0010 #define EXT_CSD_CARD_TYPE_HS200_1_2V 0x0020 @@ -493,6 +493,7 @@ #define EXT_CSD_INAND_CMD38 113 #define EXT_CSD_INAND_CMD38_ERASE 0x00 #define EXT_CSD_INAND_CMD38_TRIM 0x01 +#define EXT_CSD_INAND_CMD38_DISCARD_WITH_MMC_TRIM = 0x03 #define EXT_CSD_INAND_CMD38_SECURE_ERASE 0x80 #define EXT_CSD_INAND_CMD38_SECURE_TRIM1 0x81 #define EXT_CSD_INAND_CMD38_SECURE_TRIM2 0x82 Index: /usr/src/sys/dev/mmc/mmcsd.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/dev/mmc/mmcsd.c (revision 338675) +++ /usr/src/sys/dev/mmc/mmcsd.c (working copy) @@ -136,6 +136,7 @@ #define MMCSD_USE_TRIM 0x0002 #define MMCSD_FLUSH_CACHE 0x0004 #define MMCSD_DIRTY 0x0008 +#define MMCSD_USE_DISCARD_WITH_MMC_TRIM 0x0010 uint32_t cmd6_time; /* Generic switch timeout [us] */ uint32_t part_time; /* Partition switch timeout [us] */ off_t enh_base; /* Enhanced user data area slice base = ... */ @@ -297,6 +298,8 @@ device_printf(dev, "taking advantage of = TRIM\n"); sc->flags |=3D MMCSD_USE_TRIM; sc->erase_sector =3D 1; + if (6 <=3D ext_csd[EXT_CSD_REV]) // e.MMC 4.5 or later + sc->flags |=3D MMCSD_USE_DISCARD_WITH_MMC_TRIM; } else sc->erase_sector =3D mmc_get_erase_sector(dev); =20 @@ -1251,7 +1254,7 @@ device_t dev, mmcbus; u_int erase_sector, sz; int err; - bool use_trim; + bool use_trim, use_discard_with_mmc_trim; =20 sc =3D part->sc; dev =3D sc->dev; @@ -1261,6 +1264,7 @@ sz =3D part->disk->d_sectorsize; end =3D bp->bio_pblkno + (bp->bio_bcount / sz); use_trim =3D sc->flags & MMCSD_USE_TRIM; + use_discard_with_mmc_trim =3D sc->flags & = MMCSD_USE_DISCARD_WITH_MMC_TRIM; if (use_trim =3D=3D true) { start =3D block; stop =3D end; @@ -1289,8 +1293,10 @@ =20 if ((sc->flags & MMCSD_INAND_CMD38) !=3D 0) { err =3D mmc_switch(mmcbus, dev, sc->rca, = EXT_CSD_CMD_SET_NORMAL, - EXT_CSD_INAND_CMD38, use_trim =3D=3D true ? - EXT_CSD_INAND_CMD38_TRIM : = EXT_CSD_INAND_CMD38_ERASE, + EXT_CSD_INAND_CMD38, + use_discard_with_mmc_trim ? = EXT_CSD_INAND_CMD38_DISCARD_WITH_MMC_TRIM + : use_trim ? EXT_CSD_INAND_CMD38_TRIM + : EXT_CSD_INAND_CMD38_ERASE, sc->cmd6_time, true); if (err !=3D MMC_ERR_NONE) { device_printf(dev, As for enabling the Pine64+ 2GB e.MMC use (parts of which may be more general): Index: /usr/src/sys/dev/mmc/mmc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/dev/mmc/mmc.c (revision 338675) +++ /usr/src/sys/dev/mmc/mmc.c (working copy) @@ -1814,10 +1814,10 @@ setbit(&ivar->timings, = bus_timing_mmc_ddr52); setbit(&ivar->vccq_120, = bus_timing_mmc_ddr52); } - if ((card_type & EXT_CSD_CARD_TYPE_DDR_52_1_8V) = !=3D 0 && - (host_caps & MMC_CAP_SIGNALING_180) !=3D 0) = { + if ((card_type & = EXT_CSD_CARD_TYPE_DDR_52_3V_OR_1_8V) !=3D 0) { setbit(&ivar->timings, = bus_timing_mmc_ddr52); - setbit(&ivar->vccq_180, = bus_timing_mmc_ddr52); + if ((host_caps & MMC_CAP_SIGNALING_180) = !=3D 0) + setbit(&ivar->vccq_180, = bus_timing_mmc_ddr52); } if ((card_type & EXT_CSD_CARD_TYPE_HS200_1_2V) = !=3D 0 && (host_caps & MMC_CAP_SIGNALING_120) !=3D 0) = { Index: /usr/src/sys/arm/allwinner/aw_mmc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/arm/allwinner/aw_mmc.c (revision 338675) +++ /usr/src/sys/arm/allwinner/aw_mmc.c (working copy) @@ -509,7 +509,7 @@ MMC_CAP_UHS_SDR25 | MMC_CAP_UHS_SDR50 | MMC_CAP_UHS_DDR50 | MMC_CAP_MMC_DDR52; =20 - sc->aw_host.caps |=3D MMC_CAP_SIGNALING_330 | = MMC_CAP_SIGNALING_180; + sc->aw_host.caps |=3D MMC_CAP_SIGNALING_330; // | = MMC_CAP_SIGNALING_180; not used on Pine64+ 2GB =20 if (bus_width >=3D 4) sc->aw_host.caps |=3D MMC_CAP_4_BIT_DATA; @@ -1308,17 +1308,20 @@ =20 sc =3D device_get_softc(bus); =20 - if (sc->aw_reg_vqmmc =3D=3D NULL) - return EOPNOTSUPP; - switch (sc->aw_host.ios.vccq) { case vccq_180: + if (sc->aw_reg_vqmmc =3D=3D NULL) + return EOPNOTSUPP; uvolt =3D 1800000; break; case vccq_330: + if (sc->aw_reg_vqmmc =3D=3D NULL) // implicitly already = stuck at vccq_330 + return 0; // avoid calling code treating the = assignment attempt as an error uvolt =3D 3300000; break; default: + if (sc->aw_reg_vqmmc =3D=3D NULL) + return EOPNOTSUPP; return EINVAL; } =20 I wonder if the sc->aw_reg_vqmmc =3D=3D NULL handling change may be more general than the Pine64+ 2GB (A64) context. Anyway that is what I have so far. See any problems? Would FreeBSD even want to support e.MMC 4.5+'s discard with trim (probably with more control over if it was used)? If yes, I'd presume not until 13.0 . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Sep 17 21:59:35 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 D49A410A85EE for ; Mon, 17 Sep 2018 21:59:35 +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 52D358E8CE for ; Mon, 17 Sep 2018 21:59:34 +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 w8HLxXvF077383 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Sep 2018 14:59:33 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w8HLxWm9077382; Mon, 17 Sep 2018 14:59:32 -0700 (PDT) (envelope-from fbsd) Date: Mon, 17 Sep 2018 14:59:32 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024" and 6 GB swap) Message-ID: <20180917215932.GA77323@www.zefox.net> References: <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <20180906003829.GC818@www.zefox.net> <20180906051520.GB3482@www.zefox.net> <059D2FED-6E7C-4FEF-8807-8D4A0D0B3E26@yahoo.com> <20180906155858.GA5980@www.zefox.net> <075BD4BB-CAFB-4C9B-809A-10901522D1ED@yahoo.com> <20180915050842.GA65045@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Mon, 17 Sep 2018 21:59:36 -0000 On Sat, Sep 15, 2018 at 01:08:22AM -0700, Mark Millard wrote: > > > > But I do not find "out of swap". > > I do not see examples of I/O error reports. > Brevity triumphed over clarity. The "out of swap" messages appeared in the (discarded) case where both swap and everything else were on the same microSD card. 16 GB wasn't quite enough to let buildworld/buildkernel finish. The failure was lack of storage space, the "out of swap" a side effect. The logfiles presented were subsequent to that failure, with extra space for /usr/src provided on a USB flash drive. Apologies for the ambiguity, and thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Wed Sep 19 00:48: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 A069010AD243 for ; Wed, 19 Sep 2018 00:48:23 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.cyclaero.com (ec2-18-195-62-44.eu-central-1.compute.amazonaws.com [18.195.62.44]) (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 38FC18B029 for ; Wed, 19 Sep 2018 00:48:22 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [191.182.171.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cyclaero.com (Postfix) with ESMTPSA id C96EE62 for ; Wed, 19 Sep 2018 02:48:13 +0200 (CEST) Received: from [192.168.222.5] (unknown [192.168.222.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id B22D81350FC66 for ; Tue, 18 Sep 2018 21:48:09 -0300 (BRT) From: "Dr. Rolf Jansen" 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: Letting start sshd in an early stage on ARM devices Message-Id: <1E186CA2-F1F7-4340-9E72-C93F0BC5DB37@obsigna.com> Date: Tue, 18 Sep 2018 21:48:08 -0300 To: freebsd-arm@freebsd.org 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: Wed, 19 Sep 2018 00:48:23 -0000 Last week I had the first official presentation of my ADC/DAC-project = with a BeagleBone Black running FreeBSD 12.0-ALPHA5. I experienced a problem with the NFS client, which was sort of home made = problem, because in the hurry I forgot to deactivate the mount-directive = of a nfs share in fstab, and when I started the BBB before the = presentation, it was not connected to it's home-network and it hang at = that point. I built it into a very tight box and there was no place = anymore for the FTDI serial connector, and since sshd is usually loaded = as one of the last services, I was effectively locked out of the BBB. = Fortunately, I overcame the problem by simulating the nfs share with my = notebook and after restart, I was able to fix the fstab right before the = actual presentation began, so nobody saw that I had a problem - anyway, = I would prefer to never become that nervous again.=20 My question is now, why is sshd set to start so very late in the booting = process? If we want to put autonomous ARM devices somewhere into the = field, then any hick-up in the startup sequence would leave us = out-locked. For testing purposes, I changed the sshd rc script by replacing the line = starting with # REQUIRE: ... by: # REQUIRE: ipfw # BEFORE: mountcritremote Now, sshd starts right after ipfw has been set up, and in case the BBB = hangs, e.g. in the course of mounting a nfs share, I am still able to = login via ssh and fix most of the issues. I would like to leave it like this (at least on the headless ARM = devices). Are there any risks or hidden problems which I might = experience, when having sshd running very early in the boot sequence? Of = course after any FreeBSD update, I would need to check the sshd rc = script. Best regards Rolf= From owner-freebsd-arm@freebsd.org Wed Sep 19 04:43:43 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 613F6108F675 for ; Wed, 19 Sep 2018 04:43:43 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE44770CAD for ; Wed, 19 Sep 2018 04:43:42 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from pi by home.opsec.eu with local (Exim 4.91 (FreeBSD)) (envelope-from ) id 1g2UKy-000PP6-DB; Wed, 19 Sep 2018 06:43:40 +0200 Date: Wed, 19 Sep 2018 06:43:40 +0200 From: Kurt Jaeger To: "Dr. Rolf Jansen" Cc: freebsd-arm@freebsd.org Subject: Re: Letting start sshd in an early stage on ARM devices Message-ID: <20180919044340.GI2118@home.opsec.eu> References: <1E186CA2-F1F7-4340-9E72-C93F0BC5DB37@obsigna.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1E186CA2-F1F7-4340-9E72-C93F0BC5DB37@obsigna.com> 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, 19 Sep 2018 04:43:43 -0000 Hi! > My question is now, why is sshd set to start so very late in the > booting process? There's a PR asking the same question. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190447 As it's part of base, someone has to approve that change. -- pi@FreeBSD.org +49 171 3101372 2 years to go ! From owner-freebsd-arm@freebsd.org Wed Sep 19 09:43:51 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 8853D1095552 for ; Wed, 19 Sep 2018 09:43:51 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A87479EEE for ; Wed, 19 Sep 2018 09:43:51 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: brd/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 162A2129D6 for ; Wed, 19 Sep 2018 09:43:51 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 9547221B35 for ; Wed, 19 Sep 2018 05:43:50 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute5.internal (MEProxy); Wed, 19 Sep 2018 05:43:50 -0400 X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 269844204; Wed, 19 Sep 2018 05:43:50 -0400 (EDT) Message-Id: <1537350230.279314.1513235480.66B5E703@webmail.messagingengine.com> From: Brad Davis To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e556cd15 Subject: Re: Letting start sshd in an early stage on ARM devices Date: Wed, 19 Sep 2018 03:43:50 -0600 References: <1E186CA2-F1F7-4340-9E72-C93F0BC5DB37@obsigna.com> In-Reply-To: <1E186CA2-F1F7-4340-9E72-C93F0BC5DB37@obsigna.com> 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, 19 Sep 2018 09:43:51 -0000 On Tue, Sep 18, 2018, at 6:48 PM, Dr. Rolf Jansen wrote: > Last week I had the first official presentation of my ADC/DAC-project > with a BeagleBone Black running FreeBSD 12.0-ALPHA5. > > I experienced a problem with the NFS client, which was sort of home made > problem, because in the hurry I forgot to deactivate the mount-directive > of a nfs share in fstab, and when I started the BBB before the > presentation, it was not connected to it's home-network and it hang at > that point. I built it into a very tight box and there was no place > anymore for the FTDI serial connector, and since sshd is usually loaded > as one of the last services, I was effectively locked out of the BBB. > Fortunately, I overcame the problem by simulating the nfs share with my > notebook and after restart, I was able to fix the fstab right before the > actual presentation began, so nobody saw that I had a problem - anyway, > I would prefer to never become that nervous again. > > My question is now, why is sshd set to start so very late in the booting > process? If we want to put autonomous ARM devices somewhere into the > field, then any hick-up in the startup sequence would leave us out- > locked. > > For testing purposes, I changed the sshd rc script by replacing the line > starting with # REQUIRE: ... by: > > # REQUIRE: ipfw > # BEFORE: mountcritremote > > Now, sshd starts right after ipfw has been set up, and in case the BBB > hangs, e.g. in the course of mounting a nfs share, I am still able to > login via ssh and fix most of the issues. > > I would like to leave it like this (at least on the headless ARM > devices). Are there any risks or hidden problems which I might > experience, when having sshd running very early in the boot sequence? Of > course after any FreeBSD update, I would need to check the sshd rc > script. I have had this pain before as well. My case was apache starting before sshd with a passphrase on the cert hanging the rc script. It seems like this will be solved by the import of OpenRC as that will allow for parallel start up. Regards, Brad Davis From owner-freebsd-arm@freebsd.org Wed Sep 19 09:46: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 6799D109563A for ; Wed, 19 Sep 2018 09:46:33 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EED1A79FC0; Wed, 19 Sep 2018 09:46:32 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from pi by home.opsec.eu with local (Exim 4.91 (FreeBSD)) (envelope-from ) id 1g2Z44-000Ppk-Il; Wed, 19 Sep 2018 11:46:32 +0200 Date: Wed, 19 Sep 2018 11:46:32 +0200 From: Kurt Jaeger To: Brad Davis Cc: freebsd-arm@freebsd.org Subject: Re: Letting start sshd in an early stage on ARM devices Message-ID: <20180919094632.GJ2118@home.opsec.eu> References: <1E186CA2-F1F7-4340-9E72-C93F0BC5DB37@obsigna.com> <1537350230.279314.1513235480.66B5E703@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1537350230.279314.1513235480.66B5E703@webmail.messagingengine.com> 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, 19 Sep 2018 09:46:33 -0000 Hi! > It seems like this will be solved by the import of OpenRC as that > will allow for parallel start up. Is there a PR or review for this OpenRC import somewhere ? Who's working on that ? -- pi@FreeBSD.org +49 171 3101372 2 years to go ! From owner-freebsd-arm@freebsd.org Wed Sep 19 12:17: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 375521099461 for ; Wed, 19 Sep 2018 12:17:27 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.cyclaero.com (ec2-18-195-62-44.eu-central-1.compute.amazonaws.com [18.195.62.44]) (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 C45657E291; Wed, 19 Sep 2018 12:17:25 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [191.182.171.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cyclaero.com (Postfix) with ESMTPSA id DDAAF71; Wed, 19 Sep 2018 14:17:23 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 0658D1350F947; Wed, 19 Sep 2018 09:17:18 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Serial console of 12.0-ALPHA3 fiddles with the terminal colors From: "Dr. Rolf Jansen" In-Reply-To: Date: Wed, 19 Sep 2018 09:17:18 -0300 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7A707C18-2A11-4519-9FEC-522A37CB5708@obsigna.com> References: <3C3F2C68-81C2-40F0-8DA0-95D1C55C9938@obsigna.com> To: Kyle Evans 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: Wed, 19 Sep 2018 12:17:27 -0000 > Am 27.08.2018 um 21:56 schrieb Kyle Evans : >=20 > On Mon, Aug 27, 2018 at 7:34 PM Dr. Rolf Jansen = wrote: >>=20 >>> Am 27.08.2018 um 20:22 schrieb Kyle Evans : >>>=20 >>> On Mon, Aug 27, 2018 at 6:09 PM Dr. Rolf Jansen = wrote: >>>>=20 >>>> Hello, >>>>=20 >>>> I updated my BeagleBone Black to 12.0-ALPHA3, and now, when = booting, the serial console behaves differently (I use cu from a Mac = Terminal via a FDTI/USB adapter). >>>>=20 >>>> When it comes to "Loading kernel...", the terminal color is = inverted, instead of maintaining the usual black on white, all over the = sudden everything is displayed in white on black. And more seriously, = the logging before loading the kernel, is deleted, which means I cannot = see the diagnostics of the u-boot loader. >>>>=20 >>>> Is there any setting, to prevent the serial console manipulates = color and content of a terminal session? >>>>=20 >>>=20 >>> Hi, >>>=20 >>> You want loader_color in your loader.conf(5), which should = (hopefully) >>> disable all color while still being usable. We force the color = scheme >>> to white on black if colors are displayed because we can't = necessarily >>> sample or Q/A our color choice on all possible configurations. >>>=20 >>> I'll double check on the screen clearing... I don't recall adding = any >>> extra clears except for password prompts and (re-)drawing the menu. >>>=20 >>> Thanks, >>>=20 >>> Kyle Evans >>=20 >> Thank you for the quick reply. >>=20 >> I added loader_color=3D"NO" and this didn't change anything. The = u-boot loader diagnostics is shown in black on white, then the FreeBSD = boot loader takes over, and the first thing, which it does is deleting = the u-boot loader diagnostics and then it switches the background to = black and the following is all white on black. >=20 > Hmm... I'll take a look at this shortly. If colors are disabled, I > think we should be leaving colors alone (full stop), to include the > background reset. This must be a bug that I introduced. =3D( >=20 >> What again is the purpose of setting the color scheme in the serial = console? I understand that something shall be set on the real screen, = now in a terminal window? Think about the poor people who like it green = on pink, and you change it to white on black, come on :-) >=20 > I blame imp@. =3D) In reality, though, I don't think we had a good > reason for not allowing it by default and moving to a world where we > just respect loader_color simplified quite a bit that was originally > written to check if we're writing to a serial console. Please excuse me responding late. I was on a tight schedule. In the meantime, I updated the BBB to FreeBSD 12.0-ALPHA6 and the issue = with the terminal color changing from black on white to white on black = when the kernel starts loading has gone. I only need to set = loader_color=3DNO in /boot/loader.conf, and that's absolutely OK for me. However, the other issue, that the kernel loader flushes the diagnostic = output of the U-Boot loader is not solved. Each time the kernel loads, = exactly 24 lines are flushed in the serial console above of the initial = notice "Loading kernel..." So, in case we want to see the U-Boot diagnostics, we need to have a = high speed cam by hand, like in the old days when capturing quickly = flowing diagnostics on the tube terminals. OK, in the moment, I got no = boot problems, but occasions may come. Best regards Rolf= From owner-freebsd-arm@freebsd.org Wed Sep 19 13:23:55 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 6C50C109B0F5 for ; Wed, 19 Sep 2018 13:23:55 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2r.ore.mailhop.org (outbound2r.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 EBD1B809DD for ; Wed, 19 Sep 2018 13:23:54 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: fe323303-bc0c-11e8-a70c-1d534e3451d5 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 fe323303-bc0c-11e8-a70c-1d534e3451d5; Wed, 19 Sep 2018 13:07:44 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w8JD7gjR063247; Wed, 19 Sep 2018 07:07:42 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1537362462.90006.53.camel@freebsd.org> Subject: Re: Letting start sshd in an early stage on ARM devices From: Ian Lepore To: "Dr. Rolf Jansen" , freebsd-arm@freebsd.org Date: Wed, 19 Sep 2018 07:07:42 -0600 In-Reply-To: <1E186CA2-F1F7-4340-9E72-C93F0BC5DB37@obsigna.com> References: <1E186CA2-F1F7-4340-9E72-C93F0BC5DB37@obsigna.com> 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.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, 19 Sep 2018 13:23:55 -0000 On Tue, 2018-09-18 at 21:48 -0300, Dr. Rolf Jansen wrote: > Last week I had the first official presentation of my ADC/DAC-project > with a BeagleBone Black running FreeBSD 12.0-ALPHA5. > > I experienced a problem with the NFS client, which was sort of home > made problem, because in the hurry I forgot to deactivate the mount- > directive of a nfs share in fstab, and when I started the BBB before > the presentation, it was not connected to it's home-network and it > hang at that point. I built it into a very tight box and there was no > place anymore for the FTDI serial connector, and since sshd is > usually loaded as one of the last services, I was effectively locked > out of the BBB. Fortunately, I overcame the problem by simulating the > nfs share with my notebook and after restart, I was able to fix the > fstab right before the actual presentation began, so nobody saw that > I had a problem - anyway, I would prefer to never become that nervous > again.  > > My question is now, why is sshd set to start so very late in the > booting process? If we want to put autonomous ARM devices somewhere > into the field, then any hick-up in the startup sequence would leave > us out-locked. > > For testing purposes, I changed the sshd rc script by replacing the > line starting with # REQUIRE: ... by: > >    # REQUIRE: ipfw >    # BEFORE: mountcritremote > > Now, sshd starts right after ipfw has been set up, and in case the > BBB hangs, e.g. in the course of mounting a nfs share, I am still > able to login via ssh and fix most of the issues. > > I would like to leave it like this (at least on the headless ARM > devices). Are there any risks or hidden problems which I might > experience, when having sshd running very early in the boot sequence? > Of course after any FreeBSD update, I would need to check the sshd rc > script. > > Best regards > > Rolf I suspect you'd get better answers to this on a more generic mailing list such as -hackers or -current, because it's not really arm specific. Here's what I can figure out just looking at the scripts involved... The sshd script requires FILESYSTEMS and LOGIN.  The FILESYSTEMS requirement seems pretty important... people can't log in until things like /usr and /home are available. Using mountcritlocal instead would leave out ZFS, and that won't work for a lot of people.  The LOGIN requirement is explained like this in the script:  # This is a dummy dependency to ensure user services such as xdm,  # inetd, cron and kerberos are started after everything else, in case  # the administrator has increased the system security level and  # wants to delay user logins until the system is (almost) fully  # operational. That is probably important to some people. Other things that come before sshd because of LOGINS also seem important... things like syslogd and ntpd (must have valid timestamps on files and in logs before allowing users to do things).  Just in general, if you run "rcorder /etc/rc.d/* /usr/local/etc/rc.d/*" and look at everything that shows up between FILESYSTEMS and LOGIN, you can see that in a general- purpose-computer setup, you want most of those things to happen before users are allowed onto the system. init(8) allows logins as the last thing that happens in system startup, after all rc.d scripts are done. Sshd (and similar things such as inetd and xdm/slim) are also ways of allowing logins, and it makes sense to me that they are also almost the very last thing that happens in rc processing. So it seems unlikely that this will ever change on the freebsd side. Sometimes embedded systems have needs that are completely different than general-purpose-computer and it's appropriate to do things like start sshd very early, but that's always going to end up being a custom modification that has to be made by the creator of the embedded system. -- Ian From owner-freebsd-arm@freebsd.org Wed Sep 19 13:58:56 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 37210109BD86 for ; Wed, 19 Sep 2018 13:58:56 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.cyclaero.com (ec2-18-195-62-44.eu-central-1.compute.amazonaws.com [18.195.62.44]) (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 ACAA7819CC; Wed, 19 Sep 2018 13:58:54 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [191.182.171.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cyclaero.com (Postfix) with ESMTPSA id 6B02773; Wed, 19 Sep 2018 15:58:53 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 2B1C21350F947; Wed, 19 Sep 2018 10:58:49 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Letting start sshd in an early stage on ARM devices From: "Dr. Rolf Jansen" In-Reply-To: <1537362462.90006.53.camel@freebsd.org> Date: Wed, 19 Sep 2018 10:58:48 -0300 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <26263F22-B714-4992-B900-3BAC0A841A3C@obsigna.com> References: <1E186CA2-F1F7-4340-9E72-C93F0BC5DB37@obsigna.com> <1537362462.90006.53.camel@freebsd.org> To: Ian Lepore 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: Wed, 19 Sep 2018 13:58:56 -0000 > Am 19.09.2018 um 10:07 schrieb Ian Lepore : >=20 > On Tue, 2018-09-18 at 21:48 -0300, Dr. Rolf Jansen wrote: >> Last week I had the first official presentation of my ADC/DAC-project=20= >> with a BeagleBone Black running FreeBSD 12.0-ALPHA5. >>=20 >> I experienced a problem with the NFS client, which was sort of home >> made problem, because in the hurry I forgot to deactivate the mount- >> directive of a nfs share in fstab, and when I started the BBB before >> the presentation, it was not connected to it's home-network and it >> hang at that point. I built it into a very tight box and there was no >> place anymore for the FTDI serial connector, and since sshd is >> usually loaded as one of the last services, I was effectively locked >> out of the BBB. Fortunately, I overcame the problem by simulating the >> nfs share with my notebook and after restart, I was able to fix the >> fstab right before the actual presentation began, so nobody saw that >> I had a problem - anyway, I would prefer to never become that nervous >> again.=20 >>=20 >> My question is now, why is sshd set to start so very late in the >> booting process? If we want to put autonomous ARM devices somewhere >> into the field, then any hick-up in the startup sequence would leave >> us out-locked. >>=20 >> For testing purposes, I changed the sshd rc script by replacing the >> line starting with # REQUIRE: ... by: >>=20 >> # REQUIRE: ipfw >> # BEFORE: mountcritremote >>=20 >> Now, sshd starts right after ipfw has been set up, and in case the >> BBB hangs, e.g. in the course of mounting a nfs share, I am still >> able to login via ssh and fix most of the issues. >>=20 >> I would like to leave it like this (at least on the headless ARM >> devices). Are there any risks or hidden problems which I might >> experience, when having sshd running very early in the boot sequence? >> Of course after any FreeBSD update, I would need to check the sshd rc >> script. >>=20 >> Best regards >>=20 >> Rolf >=20 > I suspect you'd get better answers to this on a more generic mailing > list such as -hackers or -current, because it's not really arm > specific. Here's what I can figure out just looking at the scripts > involved... >=20 > The sshd script requires FILESYSTEMS and LOGIN. The FILESYSTEMS > requirement seems pretty important... people can't log in until things > like /usr and /home are available. Using mountcritlocal instead would > leave out ZFS, and that won't work for a lot of people. The LOGIN > requirement is explained like this in the script: >=20 > # This is a dummy dependency to ensure user services such as xdm, > # inetd, cron and kerberos are started after everything else, in case > # the administrator has increased the system security level and > # wants to delay user logins until the system is (almost) fully > # operational. >=20 > That is probably important to some people. Other things that come > before sshd because of LOGINS also seem important... things like > syslogd and ntpd (must have valid timestamps on files and in logs > before allowing users to do things). Just in general, if you run > "rcorder /etc/rc.d/* /usr/local/etc/rc.d/*" and look at everything = that > shows up between FILESYSTEMS and LOGIN, you can see that in a general- > purpose-computer setup, you want most of those things to happen before > users are allowed onto the system. >=20 > init(8) allows logins as the last thing that happens in system = startup, > after all rc.d scripts are done. Sshd (and similar things such as = inetd > and xdm/slim) are also ways of allowing logins, and it makes sense to > me that they are also almost the very last thing that happens in rc > processing. So it seems unlikely that this will ever change on the > freebsd side. >=20 > Sometimes embedded systems have needs that are completely different > than general-purpose-computer and it's appropriate to do things like > start sshd very early, but that's always going to end up being a = custom > modification that has to be made by the creator of the embedded = system. Ian, I appreciate your insights and your response. I completely agree = with your final comment, and actually that's the reason why I did not = raise a general PR, and I even don't want to ask for a general change in = the rc order. My embedded systems come with a number of other = customizations, and in the meantime I already put said changes to = /etc/rc.d/sshd into the list of sed commands to be applied when = setting-up a new system from the scratch.=20 That I did not care to much for a general case, you might see from that = I put ipfw as the requirement. The desktop folks seem to prefer pf = nowadays. So basically, I am fine with the need of customization. My = question was more about possible adverse implications in respect to the = given embedded use case - one filesystem, two users root/rolf, with home = directories on the root fs - in the given respect, opinions of FreeBSD = desktop users would withdraw the focus, and therefore I raised the issue = on this list.=20 You listed the general reasons on why sshd starts almost last. I will = not dispute that. However, I see that the ssh daemon which is launched = by the rc script is the mother daemon, i.e. the listener and initial = first responder on the ssh port, which spawns sshd childs on each login = request. My take on this is, that FILESYSTEM and LOGIN need not to be = for the mother but must be present for the spawned childs in order = somebody with home on late file systems could actually login. If the = mother sshd is up and running already but cannot spawn childs because = other pre-requisites are not yet ready, so what? The user can't login = unless NFS, ZFS, etc. is up and running, and in the current situation he = can't either. Anyway, once again, all this is more from the point of view of headless = systems (my FreeBSD servers, and the BBB - I don't have much experience = with FreeBSD desktop systems). I will keep my changes for the time being, if I experience some bad = effects, I will report back. Many thanks best regards Rolf= From owner-freebsd-arm@freebsd.org Wed Sep 19 15:35:31 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 38440109F23A for ; Wed, 19 Sep 2018 15:35:31 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CD68D85DE4; Wed, 19 Sep 2018 15:35:30 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.51.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id F2811568; Wed, 19 Sep 2018 11:35:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Letting start sshd in an early stage on ARM devices From: Paul Mather In-Reply-To: <1537362462.90006.53.camel@freebsd.org> Date: Wed, 19 Sep 2018 11:35:23 -0400 Cc: "Dr. Rolf Jansen" , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8762DFEB-5DF1-4096-ABA8-43DE4E592934@gromit.dlib.vt.edu> References: <1E186CA2-F1F7-4340-9E72-C93F0BC5DB37@obsigna.com> <1537362462.90006.53.camel@freebsd.org> To: Ian Lepore 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: Wed, 19 Sep 2018 15:35:31 -0000 On Sep 19, 2018, at 9:07 AM, Ian Lepore wrote: > I suspect you'd get better answers to this on a more generic mailing > list such as -hackers or -current, because it's not really arm > specific. Here's what I can figure out just looking at the scripts > involved... >=20 > The sshd script requires FILESYSTEMS and LOGIN. The FILESYSTEMS > requirement seems pretty important... people can't log in until things > like /usr and /home are available. Using mountcritlocal instead would > leave out ZFS, and that won't work for a lot of people. The LOGIN > requirement is explained like this in the script: >=20 > # This is a dummy dependency to ensure user services such as xdm, > # inetd, cron and kerberos are started after everything else, in case > # the administrator has increased the system security level and > # wants to delay user logins until the system is (almost) fully > # operational. >=20 > That is probably important to some people. Other things that come > before sshd because of LOGINS also seem important... things like > syslogd and ntpd (must have valid timestamps on files and in logs > before allowing users to do things). Just in general, if you run > "rcorder /etc/rc.d/* /usr/local/etc/rc.d/*" and look at everything = that > shows up between FILESYSTEMS and LOGIN, you can see that in a general- > purpose-computer setup, you want most of those things to happen before > users are allowed onto the system. >=20 > init(8) allows logins as the last thing that happens in system = startup, > after all rc.d scripts are done. Sshd (and similar things such as = inetd > and xdm/slim) are also ways of allowing logins, and it makes sense to > me that they are also almost the very last thing that happens in rc > processing. So it seems unlikely that this will ever change on the > freebsd side. I agree with the above rationale. Unfortunately, the ordering produced = by rcorder wrt. things run after $early_late_divider (FILESYSTEMS) is = quite loose. Here is the output I get from "rcorder /etc/rc.d/* = /usr/local/etc/rc.d/*" on a regular 12-CURRENT system I have: /etc/rc.d/growfs /etc/rc.d/sysctl /etc/rc.d/hostid /etc/rc.d/zvol /etc/rc.d/dumpon /etc/rc.d/ddb /etc/rc.d/geli /etc/rc.d/gbde /etc/rc.d/ccd /etc/rc.d/swap /etc/rc.d/fsck /etc/rc.d/root /etc/rc.d/mdconfig /etc/rc.d/hostid_save /etc/rc.d/mountcritlocal /etc/rc.d/zfsbe /etc/rc.d/zfs /etc/rc.d/var /etc/rc.d/cleanvar /etc/rc.d/FILESYSTEMS /etc/rc.d/ldconfig /etc/rc.d/kldxref /etc/rc.d/kld /etc/rc.d/addswap /etc/rc.d/adjkerntz /etc/rc.d/hostname /etc/rc.d/ip6addrctl /etc/rc.d/netoptions /etc/rc.d/opensm /etc/rc.d/random /etc/rc.d/sppp /etc/rc.d/ipfilter /etc/rc.d/ipnat /etc/rc.d/ipfs /etc/rc.d/serial /etc/rc.d/iovctl /etc/rc.d/netif /etc/rc.d/devd /etc/rc.d/ipsec /etc/rc.d/pfsync /etc/rc.d/pflog /etc/rc.d/pf /etc/rc.d/stf /etc/rc.d/ppp /etc/rc.d/routing /etc/rc.d/ipfw /etc/rc.d/netwait /etc/rc.d/resolv /etc/rc.d/local_unbound /etc/rc.d/nsswitch /etc/rc.d/routed /etc/rc.d/rtsold /etc/rc.d/static_ndp /etc/rc.d/static_arp /etc/rc.d/bridge /etc/rc.d/route6d /etc/rc.d/defaultroute /etc/rc.d/NETWORKING /etc/rc.d/mountcritremote /etc/rc.d/dmesg /etc/rc.d/devfs /etc/rc.d/ipmon /etc/rc.d/kdc /etc/rc.d/mdconfig2 /etc/rc.d/newsyslog /etc/rc.d/syslogd /usr/local/etc/rc.d/microcode_update /etc/rc.d/watchdogd /etc/rc.d/savecore /etc/rc.d/archdep /etc/rc.d/abi /etc/rc.d/SERVERS /usr/local/etc/rc.d/vm /usr/local/etc/rc.d/uuidd /etc/rc.d/accounting /etc/rc.d/ntpdate /etc/rc.d/rpcbind /etc/rc.d/nfsclient /etc/rc.d/nisdomain /etc/rc.d/ypserv /etc/rc.d/ypbind /etc/rc.d/ypset /etc/rc.d/amd /etc/rc.d/auditd /etc/rc.d/auditdistd /etc/rc.d/automountd /etc/rc.d/automount /etc/rc.d/autounmountd /etc/rc.d/tmp /etc/rc.d/cleartmp /etc/rc.d/ctld /usr/local/etc/rc.d/tpmd /usr/local/etc/rc.d/tcsd /etc/rc.d/hastd /etc/rc.d/iscsid /etc/rc.d/iscsictl /etc/rc.d/keyserv /etc/rc.d/nfsuserd /etc/rc.d/gssd /etc/rc.d/quota /etc/rc.d/mountd /etc/rc.d/nfsd /etc/rc.d/statd /etc/rc.d/lockd /etc/rc.d/pppoed /etc/rc.d/pwcheck /etc/rc.d/virecover /etc/rc.d/ypldap /usr/local/etc/rc.d/apcupsd /etc/rc.d/DAEMON /usr/local/etc/rc.d/transmission /usr/local/etc/rc.d/tftpd /etc/rc.d/apm /etc/rc.d/bootparams /etc/rc.d/hcsecd /etc/rc.d/bthidd /etc/rc.d/local /etc/rc.d/lpd /etc/rc.d/motd /etc/rc.d/mountlate /etc/rc.d/nscd /etc/rc.d/ntpd /etc/rc.d/powerd /etc/rc.d/rarpd /etc/rc.d/rctl /etc/rc.d/sdpd /etc/rc.d/rfcomm_pppd_server /etc/rc.d/rtadvd /etc/rc.d/rwho /etc/rc.d/timed /etc/rc.d/ugidfw /etc/rc.d/utx /etc/rc.d/yppasswdd /usr/local/etc/rc.d/qbittorrent-nox /etc/rc.d/LOGIN <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D /usr/local/etc/rc.d/smartd /usr/local/etc/rc.d/salt_syndic /usr/local/etc/rc.d/salt_proxy /usr/local/etc/rc.d/salt_minion /usr/local/etc/rc.d/salt_master /usr/local/etc/rc.d/salt_api /usr/local/etc/rc.d/rsyncd /usr/local/etc/rc.d/poudriered /usr/local/etc/rc.d/dovecot /usr/local/etc/rc.d/postfix /usr/local/etc/rc.d/nginx /usr/local/etc/rc.d/miniupnpc /usr/local/etc/rc.d/ktrace.out /etc/rc.d/sshd <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D /usr/local/etc/rc.d/iocage /usr/local/etc/rc.d/inadyn-mt /usr/local/etc/rc.d/inadyn /usr/local/etc/rc.d/git_daemon /usr/local/etc/rc.d/couchpotato /usr/local/etc/rc.d/armv6hf /etc/rc.d/zfsd /etc/rc.d/ypxfrd /etc/rc.d/ypupdated /etc/rc.d/wpa_supplicant /etc/rc.d/ubthidhci /etc/rc.d/syscons /etc/rc.d/swaplate /etc/rc.d/sendmail /etc/rc.d/cron /etc/rc.d/jail /etc/rc.d/localpkg /etc/rc.d/securelevel /etc/rc.d/power_profile /etc/rc.d/othermta /etc/rc.d/nfscbd /etc/rc.d/natd /etc/rc.d/msgs /etc/rc.d/moused /etc/rc.d/mixer /etc/rc.d/kpasswdd /etc/rc.d/kfd /etc/rc.d/kadmind /etc/rc.d/ipropd_slave /etc/rc.d/ipropd_master /etc/rc.d/ipfw_netflow /etc/rc.d/inetd /etc/rc.d/hostapd /etc/rc.d/gptboot /etc/rc.d/geli2 /etc/rc.d/ftpd /etc/rc.d/ftp-proxy /etc/rc.d/dhclient /etc/rc.d/devmatch /etc/rc.d/cfumass /etc/rc.d/bsnmpd /etc/rc.d/bluetooth /etc/rc.d/blacklistd /etc/rc.d/bgfsck Although /etc/rc.d/sshd has "REQUIRE: LOGIN FILESYSTEMS", it ends up a = while past LOGIN in the execution, presumably because a lot of the other = services also just "REQUIRE: LOGIN FILESYSTEMS". I'm not saying what = rcorder is doing is wrong, as presumably the ordering criteria are all = being correctly fulfilled. But, the granularity is loose enough that it = results in a lot of services being given equal priority in the startup = ordering. (It's odd that it isn't refined to prioritise base OS = services above local services in the case of ties.) There are some other oddities I noticed. For example, /etc/rc.d/zfsd = ends up being run rather late in the day, despite only having "REQUIRE: = devd zfs". In the ordering, /etc/rc.d/zfs is listed shortly before = /etc/rc.d/FILESYSTEMS, and /etc/rc.d/devd comes before = /etc/rc.d/NETWORKING. That is before the other big milestones of = /etc/rc.d/SERVERS, /etc/rc.d/DAEMON, and /etc/rc.d/LOGIN, so it's = puzzling why /etc/rc.d/zfsd only ends up appearing after = /etc/rc.d/LOGIN, when it could be listed any time after /etc/rc.d/devd. = As I said, it is correct: it could be listed last and still fulfil its = requirements. I presume this is tied up in the way rcorder implements = its dependency sorting algorithm. Perhaps the lack of granularity is why /etc/rc.d/sshd doesn't start up = ASAP. (In the above case it has to wait until services such as Salt, = Dovecot, Postfix, and Nginx start up.) Maybe the previously-mentioned = OpenRC may not only address the granularity problem but also render it = moot by allowing parallel startup of dependency "ties". I agree with = the OP, though, that it would be nice to have SSHD start ASAP. Cheers, Paul.= From owner-freebsd-arm@freebsd.org Thu Sep 20 13:01:53 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 1DDD8109BFE8 for ; Thu, 20 Sep 2018 13:01:53 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (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 B59AC8C31C for ; Thu, 20 Sep 2018 13:01:52 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1g2yaW-00068X-Bg for freebsd-arm@freebsd.org; Thu, 20 Sep 2018 15:01:44 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-arm@freebsd.org Date: Thu, 20 Sep 2018 15:01:43 +0200 Subject: https://wiki.freebsd.org/FreeBSD/arm/Kirkwood MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 63767ed6f001c63471f2cde26909bd9c 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: Thu, 20 Sep 2018 13:01:53 -0000 Hi, On this page https://wiki.freebsd.org/FreeBSD/arm/Kirkwood: Sheevaplug is misspelled as shivaplug multiple times. And the following mentioned ports are all nonexisting: sysutils/u-boot-dreamplug sysutils/u-boot-guruplug sysutils/u-boot-pogoplug sysutils/u-boot-shivaplug I don't have the rights to edit the page. Regards, Ronald. From owner-freebsd-arm@freebsd.org Thu Sep 20 14:05:16 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 98396109DE6D for ; Thu, 20 Sep 2018 14:05:16 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 26D718E749 for ; Thu, 20 Sep 2018 14:05:16 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from pi by home.opsec.eu with local (Exim 4.91 (FreeBSD)) (envelope-from ) id 1g2zZx-0002j4-Hy; Thu, 20 Sep 2018 16:05:13 +0200 Date: Thu, 20 Sep 2018 16:05:13 +0200 From: Kurt Jaeger To: Ronald Klop Cc: freebsd-arm@freebsd.org Subject: Re: https://wiki.freebsd.org/FreeBSD/arm/Kirkwood Message-ID: <20180920140513.GL2118@home.opsec.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Thu, 20 Sep 2018 14:05:16 -0000 Hi! > On this page https://wiki.freebsd.org/FreeBSD/arm/Kirkwood: Sheevaplug is > misspelled as shivaplug multiple times. I fixed one occurance. > And the following mentioned ports > are all nonexisting: > sysutils/u-boot-dreamplug > sysutils/u-boot-guruplug > sysutils/u-boot-pogoplug > sysutils/u-boot-shivaplug Thanks for the pointer. I have no idea which u-boot port is needed to boot a sheeva- or any other *plug. Any ideas what we should write there ? -- pi@FreeBSD.org +49 171 3101372 2 years to go ! From owner-freebsd-arm@freebsd.org Thu Sep 20 15:07:25 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 02512109F91A for ; Thu, 20 Sep 2018 15:07:25 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2r.ore.mailhop.org (outbound2r.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 844DA71024 for ; Thu, 20 Sep 2018 15:07:24 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: d9a60c1f-bce6-11e8-a70c-1d534e3451d5 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 d9a60c1f-bce6-11e8-a70c-1d534e3451d5; Thu, 20 Sep 2018 15:07:13 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w8KF7AXH066106; Thu, 20 Sep 2018 09:07:10 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1537456030.90006.69.camel@freebsd.org> Subject: Re: https://wiki.freebsd.org/FreeBSD/arm/Kirkwood From: Ian Lepore To: Kurt Jaeger , Ronald Klop Cc: freebsd-arm@freebsd.org Date: Thu, 20 Sep 2018 09:07:10 -0600 In-Reply-To: <20180920140513.GL2118@home.opsec.eu> References: <20180920140513.GL2118@home.opsec.eu> 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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 15:07:25 -0000 On Thu, 2018-09-20 at 16:05 +0200, Kurt Jaeger wrote: > Hi! > > > > > On this page https://wiki.freebsd.org/FreeBSD/arm/Kirkwood: > > Sheevaplug is   > > misspelled as shivaplug multiple times. > I fixed one occurance. > > > > > And the following mentioned ports   > > are all nonexisting: > > sysutils/u-boot-dreamplug > > sysutils/u-boot-guruplug > > sysutils/u-boot-pogoplug > > sysutils/u-boot-shivaplug > Thanks for the pointer. I have no idea which u-boot port is needed to > boot a sheeva- or any other *plug. Any ideas what we should write > there ? > That likely refers to these changes that haven't been committed yet... https://reviews.freebsd.org/D16504 -- Ian From owner-freebsd-arm@freebsd.org Thu Sep 20 16:23:40 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 5F7AB10A186F for ; Thu, 20 Sep 2018 16:23:40 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E6B8873BBB; Thu, 20 Sep 2018 16:23:39 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from pi by home.opsec.eu with local (Exim 4.91 (FreeBSD)) (envelope-from ) id 1g31jy-0003HM-IC; Thu, 20 Sep 2018 18:23:42 +0200 Date: Thu, 20 Sep 2018 18:23:42 +0200 From: Kurt Jaeger To: Ian Lepore Cc: freebsd-arm@freebsd.org Subject: Re: https://wiki.freebsd.org/FreeBSD/arm/Kirkwood Message-ID: <20180920162342.GM2118@home.opsec.eu> References: <20180920140513.GL2118@home.opsec.eu> <1537456030.90006.69.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1537456030.90006.69.camel@freebsd.org> 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: Thu, 20 Sep 2018 16:23:40 -0000 Hi! > > > And the following mentioned ports   > > > are all nonexisting: > > > sysutils/u-boot-dreamplug > > > sysutils/u-boot-guruplug > > > sysutils/u-boot-pogoplug > > > sysutils/u-boot-shivaplug > > Thanks for the pointer. I have no idea which u-boot port is needed to > > boot a sheeva- or any other *plug. Any ideas what we should write > > there ? > That likely refers to these changes that haven't been committed yet... > > https://reviews.freebsd.org/D16504 You are one of the reviewers, can you describe what's holding this up ? -- pi@FreeBSD.org +49 171 3101372 2 years to go ! From owner-freebsd-arm@freebsd.org Thu Sep 20 16:35:32 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 2333910A2018 for ; Thu, 20 Sep 2018 16:35:32 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 A5F88742F6 for ; Thu, 20 Sep 2018 16:35:31 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 2b0b3de4-bcf3-11e8-aed8-99744f00ac98 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.ore.mailhop.org (Halon) with ESMTPSA id 2b0b3de4-bcf3-11e8-aed8-99744f00ac98; Thu, 20 Sep 2018 16:35:22 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w8KGZLCQ066261; Thu, 20 Sep 2018 10:35:21 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1537461321.90006.74.camel@freebsd.org> Subject: Re: https://wiki.freebsd.org/FreeBSD/arm/Kirkwood From: Ian Lepore To: Kurt Jaeger Cc: freebsd-arm@freebsd.org Date: Thu, 20 Sep 2018 10:35:21 -0600 In-Reply-To: <20180920162342.GM2118@home.opsec.eu> References: <20180920140513.GL2118@home.opsec.eu> <1537456030.90006.69.camel@freebsd.org> <20180920162342.GM2118@home.opsec.eu> 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.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 16:35:32 -0000 On Thu, 2018-09-20 at 18:23 +0200, Kurt Jaeger wrote: > Hi! > > > > > > > > > > > > > > And the following mentioned ports   > > > > are all nonexisting: > > > > sysutils/u-boot-dreamplug > > > > sysutils/u-boot-guruplug > > > > sysutils/u-boot-pogoplug > > > > sysutils/u-boot-shivaplug > > > Thanks for the pointer. I have no idea which u-boot port is > > > needed to > > > boot a sheeva- or any other *plug. Any ideas what we should write > > > there ? > > > > That likely refers to these changes that haven't been committed > > yet... > > > > https://reviews.freebsd.org/D16504 > You are one of the reviewers, can you describe what's holding this up > ? > Lack of available time and lack of motivation to work on anything related to ports, because doing so almost always just ends up with me being pissed off and nothing getting committed. -- Ian From owner-freebsd-arm@freebsd.org Thu Sep 20 18:10:56 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 1ABCC10A435E for ; Thu, 20 Sep 2018 18:10:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA55F77677 for ; Thu, 20 Sep 2018 18:10:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io1-xd34.google.com with SMTP id l14-v6so8710656iob.7 for ; Thu, 20 Sep 2018 11:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NFCc0FrJpS+MM70tyFhTyhHHgb8n1sx1rUF252mCarM=; b=sVfbnWNO0RMOiO19GveqjubNiLxei37YXgopHMKTtEO1jSkuvJAdkhyUD0qY4DYss7 oFtTPT5pZSqJW1VpACSuxH2pEr2EnfIDVUJPBpKC0HpBllv78b4dwbt5Z46CH6kJQGky GR3Gsod4c9DRbyy2fxhENf9PygTRdTA7Z8FStvubFiOx8SVRA8GSlEf0G1Pfmih9y+cg sr2yatlW3akvKrzCo7xAw077LcWVFGU7MIZ1KAE+DBZS95gb3SchDTFxxYJlpf1f308Y 01gnWHTQJQgY4Fg3pwVCzpUyFpf5j21qqTVimrjekjziS2JXfMrU2bd07C/b+zB2Yz9r +FfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NFCc0FrJpS+MM70tyFhTyhHHgb8n1sx1rUF252mCarM=; b=XZEz5+PBTCejIWiEk8S0yLmOnlhaxfli0+Oyc/59ozZGUZB0pmoAqbYttRDthU15KY gBDK9liCq8TGF5t5uyrAlST1QjCcaOV5C8pyHr4UwrRfXkzF/OSyJ4aV9jZ4wn+Q8RZy X1rf341/tk67D857Up/iFyC7r9mSXtBjlK5pVrrWnDLK0XoPTIuJIk9/KkqMR0WdnwSk eB2sysloNsT7kBJyB96rzHLJLMmZo4aBQO80Gycn3EMaQbUNqwo5tl+cmg/Tm/m6W1HE AeSddXxkhAeLqX9bPCBAiZMqi8G7LmOxY71yjwR0uuw/uEeL2GPZSrb/BwOMnME3Yvd9 jfig== X-Gm-Message-State: APzg51Dd88U9Jn5iMczGWbF4WRlmnqVwmk9VIPf7tO2AM2rymD3R/F/w IKFmSB1ef+u5YO0x03wzfc5pbH8BA2O4XJ7HUxA5MQ== X-Google-Smtp-Source: ANB0VdZPe0bnLPuJsTVZY4JAv/NbxJ280au8h+3SXcg1hDqh/+zxf/SeTONphTwp5DR5obHxNc8bT9EAuMLQKApl5bA= X-Received: by 2002:a6b:3902:: with SMTP id g2-v6mr34088368ioa.168.1537467054699; Thu, 20 Sep 2018 11:10:54 -0700 (PDT) MIME-Version: 1.0 References: <20180920140513.GL2118@home.opsec.eu> <1537456030.90006.69.camel@freebsd.org> <20180920162342.GM2118@home.opsec.eu> <1537461321.90006.74.camel@freebsd.org> In-Reply-To: <1537461321.90006.74.camel@freebsd.org> From: Warner Losh Date: Thu, 20 Sep 2018 11:10:43 -0700 Message-ID: Subject: Re: https://wiki.freebsd.org/FreeBSD/arm/Kirkwood To: Ian Lepore Cc: Kurt Jaeger , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" 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: Thu, 20 Sep 2018 18:10:56 -0000 On Thu, Sep 20, 2018 at 9:36 AM Ian Lepore wrote: > On Thu, 2018-09-20 at 18:23 +0200, Kurt Jaeger wrote: > > Hi! > > > > > > > > > > > > > > > > > > > And the following mentioned ports > > > > > are all nonexisting: > > > > > sysutils/u-boot-dreamplug > > > > > sysutils/u-boot-guruplug > > > > > sysutils/u-boot-pogoplug > > > > > sysutils/u-boot-shivaplug > > > > Thanks for the pointer. I have no idea which u-boot port is > > > > needed to > > > > boot a sheeva- or any other *plug. Any ideas what we should write > > > > there ? > > > > > > That likely refers to these changes that haven't been committed > > > yet... > > > > > > https://reviews.freebsd.org/D16504 > > You are one of the reviewers, can you describe what's holding this up > > ? > > > > Lack of available time and lack of motivation to work on anything > related to ports, because doing so almost always just ends up with me > being pissed off and nothing getting committed. > I've updated these, but haven't had time to test them before committing. Warner From owner-freebsd-arm@freebsd.org Fri Sep 21 08:29:35 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 A94591092F93 for ; Fri, 21 Sep 2018 08:29:35 +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 38738745AF for ; Fri, 21 Sep 2018 08:29:35 +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 659691EFD8 for ; Fri, 21 Sep 2018 08:29:34 +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 w8L8TYN0071942 for ; Fri, 21 Sep 2018 08:29:34 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w8L8TY5s071941 for freebsd-arm@FreeBSD.org; Fri, 21 Sep 2018 08:29:34 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 231536] banana pi 12.0-ALPHA4 build 20180831-r338410 won't boot Date: Fri, 21 Sep 2018 08:29:34 +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: bennybroz105@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 attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 21 Sep 2018 08:29:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231536 Bug ID: 231536 Summary: banana pi 12.0-ALPHA4 build 20180831-r338410 won't boot Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: bennybroz105@gmail.com Created attachment 197296 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D197296&action= =3Dedit bootlog i have banana pi M1. recently burn 12.0-ALPHA4 20180831-r338410. it won't b= oot, stuck at ehci0: mem 0x1c14000-0x1c140ff irq 19 on simplebus0 bootlog is provided. is this a bug or just me? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Sep 22 03:31: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 F3F8310AF345 for ; Sat, 22 Sep 2018 03:31:29 +0000 (UTC) (envelope-from omar.ubilla@berkeley.edu) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 85D667E18C for ; Sat, 22 Sep 2018 03:31:29 +0000 (UTC) (envelope-from omar.ubilla@berkeley.edu) Received: by mail-ed1-x52f.google.com with SMTP id k14-v6so12167450edr.13 for ; Fri, 21 Sep 2018 20:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berkeley-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=1bNEH4R7nw3Mv95ZF5YfokFqKGjhZOEdntI7XDS6ewo=; b=lWJIIHiXgWb+5yD2bGpUUd0W3xlrJDZLY7rff5vOi9DiypEjdBcwvEWArYSsE/qbjJ cRVRRXQyTOLnoAwsrYEdvhBhVNRWj3emfJzoy6DeZoSTTvFRWIN4ROPleThzcjYShaEp wvBv6S9xqV3QPSnnqKd4e+Io9hKtsv/q3220fJJIiJAUQif7ddTUQg7CEwce25QKWml+ ++B1tt4fF42ApIPlDMA3vU/r7ckMUpTQsQGEgMK0LUB28p8klNQYlW7gsT0ZCW/ijw+n 4PAumom10sVtPrKvBPrpVbzG6T5tNTaSai+k4wK5jPROR21Uf9lBI8guLdyWvf5CYiNT UMlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1bNEH4R7nw3Mv95ZF5YfokFqKGjhZOEdntI7XDS6ewo=; b=hqumwYr/5j+adx67z3OiV7XV5j5GFxW2JefMSQIm8SxYsCodPkhV4n70ObXQkJPKjD dwLZbAix82R2ysDT7uC5K2+eNYB+8veJzXYQa3PwDaAbAgFPW8b6PYHR63s+dJjqJMp5 x5um+Ajv+U3I994j1SII836LK+xtV2o2YSZIzqm4BIqOquamSJiBl08Mv+VENBP9XRDr /gvkMthqbyhQ4PAtdFf+yZObrm9/OeD6juHalXJ63NNbClUi2kWpV4F8b/NIDXPBMh4D 3O15AqkmcWT/NsuAaXJEdJZInXb/NFAXQPrhfxe4PbWWQ+j3olglO8gb1wqGo5rKBSD2 hi/A== X-Gm-Message-State: ABuFfojXbixOsl8zxFem+CRR0zRAGM9lRDZfL1qAXhnn9+rF7Ks0dccv bg8FFI9k/zqKTx+YHvNO96wnDO6o/vwoX1108VJlPo7y X-Google-Smtp-Source: ACcGV60MH+25HK5zl3Joc/eZf+EwBp9RBWBQS7vceQLpPPekJn7q43qc8zEipV0qegwrIliaY4MNazfsb8rUaV03/2s= X-Received: by 2002:aa7:da19:: with SMTP id r25-v6mr1090526eds.54.1537587087788; Fri, 21 Sep 2018 20:31:27 -0700 (PDT) MIME-Version: 1.0 From: Kevin Ubilla Date: Fri, 21 Sep 2018 20:31:16 -0700 Message-ID: Subject: FreeBSD 4 Next Computer Revolution To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" 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: Sat, 22 Sep 2018 03:31:30 -0000 Hi, Regarding ports for new computer hardware, may I please be directed towards the appropriate committer? Thanks! -- Cheers, Kevin www.omniab.us From owner-freebsd-arm@freebsd.org Sat Sep 22 16:31:01 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 51AFD109CA40 for ; Sat, 22 Sep 2018 16:31:01 +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 BF80E791CE for ; Sat, 22 Sep 2018 16:31:00 +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 04CAB10364 for ; Sat, 22 Sep 2018 16:31:00 +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 w8MGUxAo079795 for ; Sat, 22 Sep 2018 16:30:59 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w8MGUxJX079774 for freebsd-arm@FreeBSD.org; Sat, 22 Sep 2018 16:30:59 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 194635] Speed optimisation for framebuffer console driver on Raspberry Pi Date: Sat, 22 Sep 2018 16:30:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: stefan.berndt@imoriath.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 22 Sep 2018 16:31:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194635 Stefan Berndt changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Overcome By Events Status|Open |Closed --=20 You are receiving this mail because: You are the assignee for the bug.=