From owner-freebsd-arm@freebsd.org Sun Aug 19 12:15: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 AC908108B6E6 for ; Sun, 19 Aug 2018 12:15:55 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2828C73A5E for ; Sun, 19 Aug 2018 12:15:54 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([92.226.221.188]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MFgxF-1ff08i1adx-00EfHS for ; Sun, 19 Aug 2018 14:15:45 +0200 Date: Sun, 19 Aug 2018 14:15:11 +0200 From: "O. Hartmann" To: "freebsd-arm@freebsd.org" Subject: [PINE64] mmcsd0: aw_mmc0: Error indicated Message-ID: <20180819141538.1eb442ef@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:naGZJ974lAxwiVlI3QGromTMGEsCAAKK/1FyBRGZGrwbJFVzQBz v7tWklkVFyKTWesO3Fe3eyoCfCssZMNTeWZuFU9IY2jArHRcIR09OVUQLyfWGN8WmUdrz0u mT5ZDjyKrDvLlJVrAhrv8ew372PSSMMCzDAwOOQNKPOhfgAQGucelC5jGzkr19wYkE225YZ vx50oTkR8Beoa7hA/Qx1Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:LH74EX7WyO0=:TqzVOPZSHUU+INMikX9XMB NSRIM7I4mUjhnld6VEar1jM0jyy2rnjE+Oh3Xr5BnihAjpqTNzLNcBme1izmods12qORacHCt nhtMN7UD7ZOQA4ho7YgEaPPi4CgKPDHGwZONOEeAWFKf7tcqUnJ5/FpMp77MeUpizmxnNmXHp thPOBOMfD6Q9GCeeDJOV+CzqG31Dm/an1823up0QHIUrgxjbqORy4FFNgrAbEkglS5Yg2nlXq qBTnKldLJO5UDskr4C4JaAJozBoCTxW8OlANsAMZ0idGPAw13UcF8ntc0N8xWOBKuM3qzRe9M adnJ5iQMWSRKbDxs+h3iWilbdUNqb0VeyfsZdybuMliXSxjFAs1h1cXqkae1EqDhlhShAmKWg dNuigarMfyTCqv6eZ/l52apYLkGN89KDHySi5ilk8z5+EV0Bpf/lBwbUlnxfZYcO/WXV0r9HV EjjCNV1L+qTbOHktRRgSwakoZd6AgFq9ufa5EYqPoBiPC/AV0St/E61PUKp1v7M7othkbwJ09 cB4Fh1ViJVKVWzNB21k08YJf0XN0MiGCDRa+wKBGXQTY6fiozHfSxZaXWWn1t37uV19feabR4 hAJ82jCm/3rQEXEGLsqi/3rQbFcqAysdFZ5jIUv0BWRJZrq90eysthspCGpDperaI3ir5pL06 ado+iPyBIrS/PAderZQy9P6mRGtdpxnbXeMw9uOMBchKXK/99LUw9LqmPbiP3894xnFZ8EBcr CgpVrETafBzPEih+wWjDERBFwUql/jqPdo2+15zktrQowoQN8qVJJ5Hu+LzU4vlfD/CKBINdf zkT11zp 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, 19 Aug 2018 12:15:55 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBNTEyDQoNClJ1bm5p bmcgMTItQ1VSUkVOVCBmb3IgYSB3aGlsZSBub3cgb24gYSBQSU5FNjQrLCAyR0IgUkFNIGZyb20g U0QsIEkgZmFjZSBzaW5jZSBtb250aHMNCnRob3NlIGVycm9ycyByZWdhcmRpbmcgdGhlIGF3X21t YyBjb250cm9sbGVyOg0KDQpbLi4uXQ0KDQphd19tbWMwOiBjb250cm9sbGVyIHRpbWVvdXQNCmF3 X21tYzA6IHRpbWVvdXQgdXBkYXRpbmcgY2xvY2sNCm1tY3NkMDogRXJyb3IgaW5kaWNhdGVkOiAx IFRpbWVvdXQNCmdfdmZzX2RvbmUoKTp1ZnMvcm9vdGZzW1dSSVRFKG9mZnNldD0zMjgxNTUxMzYw LCBsZW5ndGg9NDA5NildZXJyb3IgPSA1DQphd19tbWMwOiBjb250cm9sbGVyIHRpbWVvdXQNCmF3 X21tYzA6IHRpbWVvdXQgdXBkYXRpbmcgY2xvY2sNCm1tY3NkMDogRXJyb3IgaW5kaWNhdGVkOiAx IFRpbWVvdXQNCmdfdmZzX2RvbmUoKTp1ZnMvcm9vdGZzW1dSSVRFKG9mZnNldD0zMjgyNzg4MzUy LCBsZW5ndGg9NDA5NildZXJyb3IgPSA1DQphd19tbWMwOiBjb250cm9sbGVyIHRpbWVvdXQNCmF3 X21tYzA6IHRpbWVvdXQgdXBkYXRpbmcgY2xvY2sNCm1tY3NkMDogRXJyb3IgaW5kaWNhdGVkOiAx IFRpbWVvdXQNCmdfdmZzX2RvbmUoKTp1ZnMvcm9vdGZzW1dSSVRFKG9mZnNldD0zMjgzNjgxMjgw LCBsZW5ndGg9MzI3NjgpXWVycm9yID0gNQ0KDQpbLi4uXQ0KDQouLi4gYW5kIGEgd2hpbGUsIHRo ZSBzeXN0ZW0gaWMgY29tcGxldGVseSBzdHVjayBhbmQgbmVlZHMgaGFyZCByZXNldC4NCg0KSSBj YW4gcmVtZW1iZXIgdGhpcyBlcnJvciBzaW5jZSBJIHBsYXllZCBhcm91bmQgd2l0aCAxMi1DVVJS RU5UIG9uIHRoZSBQSU5FNjQgYW5kIHRoYXQgaXMNCm9uIHZhcmlvdXMgcmV2aXNpb25zIHNpbmNl IERlY2VtYmVyIDIwMTcuDQoNCklzIHRoaXMgcmVsYXRlZCB0byBzb21lIGtub3duIGlzc3VlcyBv ciBjb3VsZCB0aGlzIGJlIHJlbGF0ZWQgdG8gbXkgaGFyZHdhcmU/DQoNClN5c3RlbSBpczoNCg0K RnJlZUJTRCAxMi4wLUNVUlJFTlQgIzEzIHIzMzY3NTM6IEZyaSBKdWwgMjcgMDY6MDI6MzAgQ0VT VCAyMDE4IGFybTY0DQoNCkkgaGF2ZSBhIGN1c3RvbS1idWlsdCBrZXJuZWwgd2l0aCBzb21lIGFk ZC1vbnMgbGlrZSBJUEZXLg0KDQpSZWdhcmRzLA0KDQpvaA0KDQoNCg0KLSAtLSANCk8uIEhhcnRt YW5uDQoNCkljaCB3aWRlcnNwcmVjaGUgZGVyIE51dHp1bmcgb2RlciDDnGJlcm1pdHRsdW5nIG1l aW5lciBEYXRlbiBmw7xyDQpXZXJiZXp3ZWNrZSBvZGVyIGbDvHIgZGllIE1hcmt0LSBvZGVyIE1l aW51bmdzZm9yc2NodW5nICjCpyAyOCBBYnMuIDQgQkRTRykuDQotLS0tLUJFR0lOIFBHUCBTSUdO QVRVUkUtLS0tLQ0KDQppTFVFQVJNS0FCMFdJUVFaVlpNekF0d0MyVC84NlRyUzUyOGZ5RmhZbEFV Q1czbGZhd0FLQ1JEUzUyOGZ5RmhZDQpsQXBwQWYwU0FkTXo1T3FoQWEwYkl2UnhqM1V4OFVSSXJi S1BEN21aMzh1Mi80RFFlWUFFNGtFOWY0eTM5L0VpDQpNNXlYQzZDR3BrRTlWOWk0TDRDcG5QTGIx cVVpQWY5SWlUaXl4UU9PT3BJd1dGRVk3OHdycmNxQU44V0ZnaW8vDQo1M1NsWS81WEdrdFhGdlNH aHZNcmRxMkZzUHpNTGp2TlErbVpKNmJ2NU5xNHl6Z0pOa1NxDQo9R3U2VA0KLS0tLS1FTkQgUEdQ IFNJR05BVFVSRS0tLS0tDQo= From owner-freebsd-arm@freebsd.org Sun Aug 19 12:39:39 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 3A06A108BF1A for ; Sun, 19 Aug 2018 12:39:39 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B146F742A2 for ; Sun, 19 Aug 2018 12:39:38 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 14e06fcd; Sun, 19 Aug 2018 14:39:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=mMfazMMQtRFJO5FnsFd/t/+fyWE=; b=IEUtEC7z7xYgee5UOnck6euI7W4K 7pQu+H8Arn56E5eBZ+w/CM7VlYwciQpEXZ9LuBu6E0XdZDWqXNsO5YfP5V7Er3JT 6JqXjRSZhQIPT5zAeYEyrpR6I3cGmKoBdUkSmquD2IhKKHscASnKpv9p9dlDjDzK KZf7Vi7Im3rD7FI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=dHRWJB0DQcvoylyu0n4P6YC2nU7AapYeRWBr59D0r3m62q9gp7HXg29q AryeRocGfWB42MthdvkCQx/4izg1VVvrlkLzlwNClayBNJC14CuAMQB3u8KLjKeD g9cpNjtSOFZiU3oI1S3TcRGYbvn5NciYCKK42ZPQnygV0J4DM2w= Received: from knuckles.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 62862f90 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sun, 19 Aug 2018 14:39:36 +0200 (CEST) Date: Sun, 19 Aug 2018 14:39:33 +0200 From: Emmanuel Vadot To: "O. Hartmann" Cc: "freebsd-arm@freebsd.org" Subject: Re: [PINE64] mmcsd0: aw_mmc0: Error indicated Message-Id: <20180819143933.ce9bc2e3853552810db3e181@bidouilliste.com> In-Reply-To: <20180819141538.1eb442ef@thor.intern.walstatt.dynvpn.de> References: <20180819141538.1eb442ef@thor.intern.walstatt.dynvpn.de> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 19 Aug 2018 12:39:39 -0000 On Sun, 19 Aug 2018 14:15:11 +0200 "O. Hartmann" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Running 12-CURRENT for a while now on a PINE64+, 2GB RAM from SD, I face = since months > those errors regarding the aw_mmc controller: >=20 > [...] >=20 > aw_mmc0: controller timeout > aw_mmc0: timeout updating clock > mmcsd0: Error indicated: 1 Timeout > g_vfs_done():ufs/rootfs[WRITE(offset=3D3281551360, length=3D4096)]error = =3D 5 > aw_mmc0: controller timeout > aw_mmc0: timeout updating clock > mmcsd0: Error indicated: 1 Timeout > g_vfs_done():ufs/rootfs[WRITE(offset=3D3282788352, length=3D4096)]error = =3D 5 > aw_mmc0: controller timeout > aw_mmc0: timeout updating clock > mmcsd0: Error indicated: 1 Timeout > g_vfs_done():ufs/rootfs[WRITE(offset=3D3283681280, length=3D32768)]error = =3D 5 >=20 > [...] >=20 > ... and a while, the system ic completely stuck and needs hard reset. >=20 > I can remember this error since I played around with 12-CURRENT on the PI= NE64 and that is > on various revisions since December 2017. >=20 > Is this related to some known issues or could this be related to my hardw= are? >=20 > System is: >=20 > FreeBSD 12.0-CURRENT #13 r336753: Fri Jul 27 06:02:30 CEST 2018 arm64 >=20 > I have a custom-built kernel with some add-ons like IPFW. >=20 > Regards, >=20 > oh >=20 >=20 >=20 > - --=20 > O. Hartmann >=20 > Ich widerspreche der Nutzung oder =DCbermittlung meiner Daten f=FCr > Werbezwecke oder f=FCr die Markt- oder Meinungsforschung (=A7 28 Abs. 4 B= DSG). > -----BEGIN PGP SIGNATURE----- >=20 > iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW3lfawAKCRDS528fyFhY > lAppAf0SAdMz5OqhAa0bIvRxj3Ux8URIrbKPD7mZ38u2/4DQeYAE4kE9f4y39/Ei > M5yXC6CGpkE9V9i4L4CpnPLb1qUiAf9IiTiyxQOOOpIwWFEY78wrrcqAN8WFgio/ > 53SlY/5XGktXFvSGhvMrdq2FsPzMLjvNQ+mZJ6bv5Nq4yzgJNkSq > =3DGu6T > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" Can you please provide a full bootlog (booting with boot -v) Also does those errors happens at boot ? after a while ? during something specific ? Thanks, --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sun Aug 19 13:25: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 B5239108C971 for ; Sun, 19 Aug 2018 13:25:25 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A3EA75855 for ; Sun, 19 Aug 2018 13:25:25 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: BafFRMoVM1lc5n784nr710ssEzVpDxyxkIIjmnLoYzRWh_kVL7ImM_6TLhvcEp6 vC8rcIJR3HKJTqgNBA1EmGEr73LKFK4lloNSjOUstQZIQ_QsKDC.kRwqV2uEcLnlJ5rsgpbbDLhR _m.biOIBfkAlWygiwhFVKsQqUw99YIiDyynT2WRZuJMObrrKormehrtxLT7YzvKWisnFZorYkRh. gKT3Ok74VgEgtoG2d3OEOhloGAWQ.riss4T.Sj7ZL0cvixk3wxw6vVr2te58yoxuBXrSJtvLZZfO lKDw52JeVsY.oVYWeva7z4xzcrJv2Rb.LACkPxp61jkXJOCi6PJgp5s.nLL5ok2oDaOZxPSEe5Z4 8.zPyfXU2PQjenux4J7AoDT2.l1bpmztaB2DLaSqXF7qm_rRIQ0b_cxYP_kl9oNELSLqM9FIKmk4 fYSCsHG5gWLzcZe9RxIA_Jtxl7XhpjI8SgjvnDV.zrO._rBF65lvSfACXRatPW81PQ0MZc7vwxF5 rZoNHIuSzhUR_7.Ci2scEyog.dxYaotBDMaWVfj4F.HTSQxdcziNZyQtH8bteDJZZHpjE68yhV9h .HdxC_ZuuqDzT04zx3DZ8jzfxCPCsSirN3DZAdSiOOCI5ojUrLLk5sn2Dzq3aRdXFWWrM6MjJpLB Le2fDSfi3FzcfMm1nznJ0lpCXbN.RGsTeMjRiL4WEMjtYYsB_XNJ6QvTZhWJBClf6RZ9cmoLv55O kbbFU0pNq_WYkqvzQ.2tP6lmg73ez7mPADz6APCAAScLNOfTuOy6Tv4jD4m6sUYAjQiORPYHfWBC EYrTCoLbMXH01bYqpbIpS.dpSp1A9ujJdScTNRpDzAgXSZztT1CJ6fMYwOl0K9FhPXmgQ1oSPtDx kvbZPXql97qhvbRZLmJ6_SKl7sSQF8e26gu7_DIxxuYyyyJqtmkcgy6mWvnqgIJhBmPprEiHigzA cN5dk.s2WHBBx0zjVmlIaM9ITsjtyKTf.pFbzOg7xUxzUnOAMqGfl8DcjgunDjTg9o_9r.QQAexT YUfbM_nh1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 19 Aug 2018 13:25:22 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp422.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 633137caaf37996875aa90789cbcca87; Sun, 19 Aug 2018 13:15:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [PINE64] mmcsd0: aw_mmc0: Error indicated From: Mark Millard In-Reply-To: <20180819141538.1eb442ef@thor.intern.walstatt.dynvpn.de> Date: Sun, 19 Aug 2018 06:15:11 -0700 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180819141538.1eb442ef@thor.intern.walstatt.dynvpn.de> To: "O. Hartmann" 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, 19 Aug 2018 13:25:25 -0000 On 2018-Aug-19, at 5:15 AM, O. Hartmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Running 12-CURRENT for a while now on a PINE64+, 2GB RAM from SD, I = face since months > those errors regarding the aw_mmc controller: >=20 > [...] >=20 > aw_mmc0: controller timeout > aw_mmc0: timeout updating clock > mmcsd0: Error indicated: 1 Timeout > g_vfs_done():ufs/rootfs[WRITE(offset=3D3281551360, length=3D4096)]error = =3D 5 > aw_mmc0: controller timeout > aw_mmc0: timeout updating clock > mmcsd0: Error indicated: 1 Timeout > g_vfs_done():ufs/rootfs[WRITE(offset=3D3282788352, length=3D4096)]error = =3D 5 > aw_mmc0: controller timeout > aw_mmc0: timeout updating clock > mmcsd0: Error indicated: 1 Timeout > g_vfs_done():ufs/rootfs[WRITE(offset=3D3283681280, length=3D32768)]error= =3D 5 >=20 > [...] >=20 > ... and a while, the system ic completely stuck and needs hard reset. >=20 > I can remember this error since I played around with 12-CURRENT on the = PINE64 and that is > on various revisions since December 2017. >=20 > Is this related to some known issues or could this be related to my = hardware? >=20 > System is: >=20 > FreeBSD 12.0-CURRENT #13 r336753: Fri Jul 27 06:02:30 CEST 2018 arm64 >=20 > I have a custom-built kernel with some add-ons like IPFW. >=20 [These notes are based on a normal sdcard, not my historical e.MCC on an adapter. The e.MMC context no longer directly boots.] I've been running head -r337400 with then-modern: A) /boot/efi/dtb/ (/boot/efi being a mount of the msdosfs, dtb/ being copy of target media's UFS /boot/dtb/ ) B) /boot/efi/EFI/BOOT/bootaa64.efi (copy of . . ./stand/efi/loader/loader.efi from the build tree) and with -r476715 /usr/port 's: C) sysutils/u-boot-pine64 (via /usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin = dd'd) My boot sdcard has a full installworld installkernel but I normally have its /etc/fstab edited to redirect the root file system (and swap = partition) to a USB drive. But I've had no operational troubles so far when booted to the sdcard = (via an edit if its /etc.fstab file to self-reference the root file system). For reference: mmcsd0: 32GB MFG 07/2017 by 3 SD> at mmc0 = 50.0MHz/4bit/32768-block The kernel is from: # more /usr/src/sys/arm64/conf/GENERIC-NODBG=20 # # GENERIC -- Custom configuration for the arm64/aarch64 # include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: #options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones nooptions BUF_TRACKING nooptions FULL_BUF_TRACKING Notes: I do get the two messages during boot: mmc0: ACMD42 failed, RESULT: 4 mmc0: Card at relative address 43690 failed to set bus width but things seem to be operating fine. Because of my use of WITHOUT_BINTUTILS for buildworld buildkernel I added: BUILD_DEPENDS+=3D objdump:devel/binutils to: /usr/ports/sysutils/u-boot-master/Makefile in order for sysutils/u-boot-pine64 to build under poudriere-devel . =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 Aug 19 14:00:21 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 9EA471069201 for ; Sun, 19 Aug 2018 14:00:21 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1931877534 for ; Sun, 19 Aug 2018 14:00:20 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([92.226.221.188]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LbPza-1gGFOq3LII-00kvkz; Sun, 19 Aug 2018 16:00:10 +0200 Date: Sun, 19 Aug 2018 15:59:37 +0200 From: "O. Hartmann" To: Emmanuel Vadot Cc: "O. Hartmann" , "freebsd-arm@freebsd.org" Subject: Re: [PINE64] mmcsd0: aw_mmc0: Error indicated Message-ID: <20180819160004.37874fd0@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20180819143933.ce9bc2e3853552810db3e181@bidouilliste.com> References: <20180819141538.1eb442ef@thor.intern.walstatt.dynvpn.de> <20180819143933.ce9bc2e3853552810db3e181@bidouilliste.com> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:zuDDvMNWnNfzwL5RF/s+haeyxr2H0oh8BwL35JSo4+72v4yOfbR gQ9iQ4yJC1btMImIogIS8yIrYRXlqbQ2hNFBCC5cmrneQctF0gVR/d6iTXzh1klQmHmyOQn LWLZb8X7mIRKWm4NViFVwPz56rhtEy4EZd/ROhaZcrt5jJ3EqFFOk4ucHO6pyioYPW8pAw9 LxzahoI5bdS8lgG6AZyWg== X-UI-Out-Filterresults: notjunk:1;V01:K0:6dltaajZtrg=:5wejuNFFyEjfDlsSJxRa5/ D7dKwtIQMa6Hk8VtjvtX18nDCeJptxiRiAT9n7eYdWEHFYAkTjMpkVQCiwZYxxqmYd/Y+ZgEV bbbTw2ETxDQXKzpRnhYv8p63FIqX3nxXPHsoFpSZsuAgiKgquwGqXpkxaOYW2+uyrkdt38zz/ bvofRIrVL7BACalBZkw5omrhUHHl+tGey9UNbnoSUgzKN+XOIvU6DyDBA+NAGOaEDPyi0F9Fi DLz/2aOtA8BYqjuF+SjsAcV3QUfjxB2ioMyMdL/VsybNl63uol9UPq/394fMpc0yzNnYtur9g /vdnud0ypwddDbuiQAp2mOyrMaRv5Kp8KbPsdTYOKzCJ0rpizcoJbBOKfDkPtexhzrVxDSfMk xNsYZT4QpThaogb57WctVv+0LdHho8JrLDi5OX8d/hyYDW9PV8X035eNtcWXP1U/axLTnTVbz Ust5SgsChnNsEEKNq/g03cDT1ZzU8V9vWNgHxyyBQjUJZtirB+6BWys+1WN16iCn7RcUZrWu7 r4DgwXyjEwzHoFojc8LmhDLf88Z8fitMWsDyry4ImAAHPFOX6QylASFDTaIodXRv93jytKQwS mHUBtIEaOBTYdNq59D2TWk+8sNl3HUUo0o5JjCLfwarIrgvswIWdbbbh9101psT6aDVB4+ZNX 7G4p/5PWweB6uyDZHBL/64dDH4DdNjT8m+dYAxs0rgcHJRmNXyRGyOcb8tZCPLQVuKv1sB0q4 sqAcPuu0UVS+tHokFiylkXv7gjCtfIiCQq1WnYvzKDIFTV5qXppxh4t3ig0KUDlY4V8UxMmOa udCtpUM 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, 19 Aug 2018 14:00:21 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBNTEyDQoNCkFtIFN1 biwgMTkgQXVnIDIwMTggMTQ6Mzk6MzMgKzAyMDANCkVtbWFudWVsIFZhZG90IDxtYW51QGJpZG91 aWxsaXN0ZS5jb20+IHNjaHJpZWI6DQoNCj4gT24gU3VuLCAxOSBBdWcgMjAxOCAxNDoxNToxMSAr MDIwMA0KPiAiTy4gSGFydG1hbm4iIDxvaGFydG1hbm5Ad2Fsc3RhdHQub3JnPiB3cm90ZToNCj4g DQo+ID4gLS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KPiA+IEhhc2g6IFNIQTUx Mg0KPiA+IA0KPiA+IFJ1bm5pbmcgMTItQ1VSUkVOVCBmb3IgYSB3aGlsZSBub3cgb24gYSBQSU5F NjQrLCAyR0IgUkFNIGZyb20gU0QsIEkgZmFjZSBzaW5jZSBtb250aHMNCj4gPiB0aG9zZSBlcnJv cnMgcmVnYXJkaW5nIHRoZSBhd19tbWMgY29udHJvbGxlcjoNCj4gPiANCj4gPiBbLi4uXQ0KPiA+ IA0KPiA+IGF3X21tYzA6IGNvbnRyb2xsZXIgdGltZW91dA0KPiA+IGF3X21tYzA6IHRpbWVvdXQg dXBkYXRpbmcgY2xvY2sNCj4gPiBtbWNzZDA6IEVycm9yIGluZGljYXRlZDogMSBUaW1lb3V0DQo+ ID4gZ192ZnNfZG9uZSgpOnVmcy9yb290ZnNbV1JJVEUob2Zmc2V0PTMyODE1NTEzNjAsIGxlbmd0 aD00MDk2KV1lcnJvciA9IDUNCj4gPiBhd19tbWMwOiBjb250cm9sbGVyIHRpbWVvdXQNCj4gPiBh d19tbWMwOiB0aW1lb3V0IHVwZGF0aW5nIGNsb2NrDQo+ID4gbW1jc2QwOiBFcnJvciBpbmRpY2F0 ZWQ6IDEgVGltZW91dA0KPiA+IGdfdmZzX2RvbmUoKTp1ZnMvcm9vdGZzW1dSSVRFKG9mZnNldD0z MjgyNzg4MzUyLCBsZW5ndGg9NDA5NildZXJyb3IgPSA1DQo+ID4gYXdfbW1jMDogY29udHJvbGxl ciB0aW1lb3V0DQo+ID4gYXdfbW1jMDogdGltZW91dCB1cGRhdGluZyBjbG9jaw0KPiA+IG1tY3Nk MDogRXJyb3IgaW5kaWNhdGVkOiAxIFRpbWVvdXQNCj4gPiBnX3Zmc19kb25lKCk6dWZzL3Jvb3Rm c1tXUklURShvZmZzZXQ9MzI4MzY4MTI4MCwgbGVuZ3RoPTMyNzY4KV1lcnJvciA9IDUNCj4gPiAN Cj4gPiBbLi4uXQ0KPiA+IA0KPiA+IC4uLiBhbmQgYSB3aGlsZSwgdGhlIHN5c3RlbSBpYyBjb21w bGV0ZWx5IHN0dWNrIGFuZCBuZWVkcyBoYXJkIHJlc2V0Lg0KPiA+IA0KPiA+IEkgY2FuIHJlbWVt YmVyIHRoaXMgZXJyb3Igc2luY2UgSSBwbGF5ZWQgYXJvdW5kIHdpdGggMTItQ1VSUkVOVCBvbiB0 aGUgUElORTY0IGFuZA0KPiA+IHRoYXQgaXMgb24gdmFyaW91cyByZXZpc2lvbnMgc2luY2UgRGVj ZW1iZXIgMjAxNy4NCj4gPiANCj4gPiBJcyB0aGlzIHJlbGF0ZWQgdG8gc29tZSBrbm93biBpc3N1 ZXMgb3IgY291bGQgdGhpcyBiZSByZWxhdGVkIHRvIG15IGhhcmR3YXJlPw0KPiA+IA0KPiA+IFN5 c3RlbSBpczoNCj4gPiANCj4gPiBGcmVlQlNEIDEyLjAtQ1VSUkVOVCAjMTMgcjMzNjc1MzogRnJp IEp1bCAyNyAwNjowMjozMCBDRVNUIDIwMTggYXJtNjQNCj4gPiANCj4gPiBJIGhhdmUgYSBjdXN0 b20tYnVpbHQga2VybmVsIHdpdGggc29tZSBhZGQtb25zIGxpa2UgSVBGVy4NCj4gPiANCj4gPiBS ZWdhcmRzLA0KPiA+IA0KPiA+IG9oDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gLSAtLSANCj4gPiBP LiBIYXJ0bWFubg0KPiA+IA0KPiA+IEljaCB3aWRlcnNwcmVjaGUgZGVyIE51dHp1bmcgb2RlciDc YmVybWl0dGx1bmcgbWVpbmVyIERhdGVuIGb8cg0KPiA+IFdlcmJlendlY2tlIG9kZXIgZvxyIGRp ZSBNYXJrdC0gb2RlciBNZWludW5nc2ZvcnNjaHVuZyAopyAyOCBBYnMuIDQgQkRTRykuDQo+ID4g LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCj4gPiANCj4gPiBpTFVFQVJNS0FCMFdJUVFa VlpNekF0d0MyVC84NlRyUzUyOGZ5RmhZbEFVQ1czbGZhd0FLQ1JEUzUyOGZ5RmhZDQo+ID4gbEFw cEFmMFNBZE16NU9xaEFhMGJJdlJ4ajNVeDhVUklyYktQRDdtWjM4dTIvNERRZVlBRTRrRTlmNHkz OS9FaQ0KPiA+IE01eVhDNkNHcGtFOVY5aTRMNENwblBMYjFxVWlBZjlJaVRpeXhRT09PcEl3V0ZF WTc4d3JyY3FBTjhXRmdpby8NCj4gPiA1M1NsWS81WEdrdFhGdlNHaHZNcmRxMkZzUHpNTGp2TlEr bVpKNmJ2NU5xNHl6Z0pOa1NxDQo+ID4gPUd1NlQNCj4gPiAtLS0tLUVORCBQR1AgU0lHTkFUVVJF LS0tLS0NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+IGZyZWVic2QtYXJtQGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KPiA+IGh0dHBzOi8v bGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWFybQ0KPiA+IFRvIHVu c3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLWFybS11bnN1YnNjcmliZUBmcmVl YnNkLm9yZyIgIA0KPiANCj4gDQo+ICBDYW4geW91IHBsZWFzZSBwcm92aWRlIGEgZnVsbCBib290 bG9nIChib290aW5nIHdpdGggYm9vdCAtdikNCj4gDQo+ICBBbHNvIGRvZXMgdGhvc2UgZXJyb3Jz IGhhcHBlbnMgYXQgYm9vdCA/IGFmdGVyIGEgd2hpbGUgPyBkdXJpbmcNCj4gc29tZXRoaW5nIHNw ZWNpZmljID8NCj4gDQo+ICBUaGFua3MsDQo+IA0KDQpIZWxsbyBFbW1hbnVlbCBWYWRvdCwNCg0K SSBoYXZlIGp1c3Qgd3JhcHBlZCB0aGUgUElORTY0IGF3YXkgc2luY2UgaXQgZGllZCBhZ2FpbiB3 aGlsZSB1cGRhdGluZyB0aGUgT1MgdmlhDQpwa2ctYmFzZS4NCg0KVGhlIHByb2JsZW1zIHNob3du IG9jY3VyZSBhZnRlciBhIHdoaWxlOyBub3Qgd2hpbGUgYm9vdGluZyBhcyBmYXIgYXMgSSByZW1l bWJlci4gVGhlDQpsYXJnZXIgdGhlIGZpbGUgdG8gZXh0cmFjdCAoZm9yIGluc3RhbmNlLCBGcmVl QlNELXJ1bnRpbWUgcGtnKSwgdGhlIG1vcmUgcHJvYmFibGUgc2VlbXMNCnRoZSBmYWlsdXJlLiBC dXQgdGhpcyBpcyBhICJ3aWxkIGd1ZXNzIGJhc2VkIG9uIGEgaHVuY2giLg0KDQpJIGhhdmVuJ3Qg b2JzZXJ2ZWQgc3dhcHBpbmcgc28gZmFyLiBJJ2xsIHN0YXJ0IGEgbmV3IHJ1biB3aGVuIEkndmUg cHVyY2hhc2VkIHNvbWUgU2FuRGlzYw0KaGlnaCBxdWFsaXR5IFNEIGNhcmRzLCBzaW5jZSB0aGUg b25lcyBJJ20gdXNpbmcgYXJlIGEgYml0IHNsb3cuDQoNCkl0IHNlZW1zIHRoZSBwcm9ibGVtIG9j Y3VycyB3aGlsZSBoZWF2eSBJL08gaXMgYXQgd29yay4NCg0KSSdsbCBwcm92aWRlIHRoZSByZXF1 ZXN0ZWQgZnVsbCBib290bG9nIGxhdGVyLg0KDQpLaW5kIHJlZ2FyZHMsDQoNCk8uIEhhcnRtYW5u DQoNCi0gLS0gDQpPLiBIYXJ0bWFubg0KDQpJY2ggd2lkZXJzcHJlY2hlIGRlciBOdXR6dW5nIG9k ZXIg3GJlcm1pdHRsdW5nIG1laW5lciBEYXRlbiBm/HINCldlcmJlendlY2tlIG9kZXIgZvxyIGRp ZSBNYXJrdC0gb2RlciBNZWludW5nc2ZvcnNjaHVuZyAopyAyOCBBYnMuIDQgQkRTRykuDQotLS0t LUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KDQppTFVFQVJNS0FCMFdJUVFaVlpNekF0d0MyVC84 NlRyUzUyOGZ5RmhZbEFVQ1czbDM1QUFLQ1JEUzUyOGZ5RmhZDQpsUEI1QWY5cDRqZEdrTkNrU3NY Mkc2YlFwSU5mWUljRnJTOU1vbjBFL0J1OUp2YUszUGVnejNUYUJ5Ty9oMUZ3DQpoVlI4SHpoYml1 VmhkSlZDWmZka1BzT0lxZFc5QWdDcU54S2N2Ni9KdkxQcmIvODRlK1VNR2s1U3FXY0l6eXRjDQpU KzhEZ09xQmVwaG5YazVXeloxMzFia1FZSjZhRHNpSEFtUGJyazhyY1BpbVFiUzRxOVhKDQo9TTZW SA0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQo= From owner-freebsd-arm@freebsd.org Sun Aug 19 16:23:49 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C511E106EBBA for ; Sun, 19 Aug 2018 16:23:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 60B5E7DEAD for ; Sun, 19 Aug 2018 16:23:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ICvqYUUVM1ngl5ouFiTAXwlLZacxkD2Ph4k0Lidp8nWe3Rw667jBvswr9dAebkf eXd1IDlPYF...yWk482KrFR.YHoYa2DskuGBjjEvNgQhTWT6Uf9PQq0VXD5Mn6oULyuDGI703yAd QvzIYcJnrhBiQC2rrk0Ijhp3PyJlkX4azpmEx_oOxRyz3h2h4MH5a6xO93imWLkaySdSQxIDi52M fM41zTdlIriyJVtNJaJCDNApbcBMORPkFBzoU4ipjTT.E8FuPRa3p5dojsI3zQKuuFaIuoxLX7jF XOVKoLMurIsV2_r.Pb4g_dUFPbbIYYpm9XV4E87XeiD2V2Mdk6v8s1LYXKBsErhQ9Gs0PKAsnxUY lOpjFnX.pm_A22UkKDggLAQMnMR_Fcqey00p2hcVoYIn6nmjaTz4_9GqJrLkTCttcAJNPmog1Amf _LmFaJPlKe87sQ21kqXiPMRlhJVDW_ZEIPc4ysWIr_VETmUKS325evDyGrbQGlCLilSggU4Nmrph SQBQHe3ieTref76Kj7GTjMK1Q_kfr1igQx4JnAZm.OPquKzGF2wbvZzmQrGl2UHuV465WvCvKBSg aXqnModYwi7pf8xzsAR_vWPLWSKbJorkx5pn1D1GE38rn6Idy.UIiYfkNDGze1ANMveZEmDWUd3a nTmAsUhI.xL9zFEHkGyW43_e8zcYuHE_.QphJgj7u1lJ0UW.szfBBmAJPkL.uuJvJa9n1HimGxZG wIBVJn8WkjMCgJeY.gcuc_M9wiSvuJNP.2MZqAky1I2iU54WdlELTb3dN2x4.YMAja0XcsMLOnlO CkzPjvX_vxsD7jigHMp1uNMcSTxjxCspkxZmfZ._vlqe4ndCW9q76O60tJa4GycZqaep6TthOxhg qNM_pMxWiqLZQfDpWsmhhyJYo4PiKUWHUG3ugTyb0dzr6tLs4Kf2DjS6u.hSuBwE7fhbkuyNnJkE c91xe.PV_a089w_Ex2AutmmuArCfbLgJ_c16uOu3uhzT508coPSR2yKSRIGzqBKxiJQlwmPKBppZ KCp9_eUuJV0DU7hKoHryjd0a3rywLOK6FhDEJ Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Sun, 19 Aug 2018 16:23:48 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp404.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 14aaa3784568106322cd05f63ab7df5e; Sun, 19 Aug 2018 16:23:47 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [PINE64] mmcsd0: aw_mmc0: Error indicated From: Mark Millard In-Reply-To: Date: Sun, 19 Aug 2018 09:23:45 -0700 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <23F43EA1-3741-47BD-97D9-2BA816692492@yahoo.com> References: <20180819141538.1eb442ef@thor.intern.walstatt.dynvpn.de> To: "O. Hartmann" 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, 19 Aug 2018 16:23:50 -0000 [Just clarifying my wording where it was incomplete. Not tied to your problem but reading what I wrote in one area would be confusing.] On 2018-Aug-19, at 6:15 AM, Mark Millard = wrote: > On 2018-Aug-19, at 5:15 AM, O. Hartmann = wrote: >=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >>=20 >> Running 12-CURRENT for a while now on a PINE64+, 2GB RAM from SD, I = face since months >> those errors regarding the aw_mmc controller: >>=20 >> [...] >>=20 >> aw_mmc0: controller timeout >> aw_mmc0: timeout updating clock >> mmcsd0: Error indicated: 1 Timeout >> g_vfs_done():ufs/rootfs[WRITE(offset=3D3281551360, length=3D4096)]error= =3D 5 >> aw_mmc0: controller timeout >> aw_mmc0: timeout updating clock >> mmcsd0: Error indicated: 1 Timeout >> g_vfs_done():ufs/rootfs[WRITE(offset=3D3282788352, length=3D4096)]error= =3D 5 >> aw_mmc0: controller timeout >> aw_mmc0: timeout updating clock >> mmcsd0: Error indicated: 1 Timeout >> g_vfs_done():ufs/rootfs[WRITE(offset=3D3283681280, = length=3D32768)]error =3D 5 >>=20 >> [...] >>=20 >> ... and a while, the system ic completely stuck and needs hard reset. >>=20 >> I can remember this error since I played around with 12-CURRENT on = the PINE64 and that is >> on various revisions since December 2017. >>=20 >> Is this related to some known issues or could this be related to my = hardware? >>=20 >> System is: >>=20 >> FreeBSD 12.0-CURRENT #13 r336753: Fri Jul 27 06:02:30 CEST 2018 arm64 >>=20 >> I have a custom-built kernel with some add-ons like IPFW. >>=20 >=20 > [These notes are based on a normal sdcard, not my historical > e.MCC on an adapter. The e.MMC context no longer directly > boots.] >=20 > I've been running head -r337400 with then-modern: >=20 > A) /boot/efi/dtb/ > (/boot/efi being a mount of the msdosfs, > dtb/ being copy of target media's UFS /boot/dtb/ ) > B) /boot/efi/EFI/BOOT/bootaa64.efi > (copy of . . ./stand/efi/loader/loader.efi from the build tree) > and with -r476715 /usr/port 's: > C) sysutils/u-boot-pine64 > (via /usr/local/share/u-boot/u-boot-pine64/u-boot-sunxi-with-spl.bin = dd'd) >=20 > My boot sdcard has a full installworld installkernel but I normally = have > its /etc/fstab edited to redirect the root file system (and swap = partition) > to a USB drive. >=20 > But I've had no operational troubles so far when booted to the sdcard = (via > an edit if its /etc.fstab file to self-reference the root file = system). >=20 > For reference: >=20 > mmcsd0: 32GB MFG 07/2017 by 3 SD> at = mmc0 50.0MHz/4bit/32768-block >=20 > The kernel is from: >=20 > # more /usr/src/sys/arm64/conf/GENERIC-NODBG=20 > # > # GENERIC -- Custom configuration for the arm64/aarch64 > # >=20 > include "GENERIC" >=20 > ident GENERIC-NODBG >=20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >=20 > options ALT_BREAK_TO_DEBUGGER >=20 > options KDB # Enable kernel debugger = support >=20 > # For minimum debugger support (stable branch) use: > #options KDB_TRACE # Print a stack trace for a = panic > options DDB # Enable the kernel debugger >=20 > # Extra stuff: > #options VERBOSE_SYSINIT # Enable verbose sysinit = messages > #options BOOTVERBOSE=3D1 > #options BOOTHOWTO=3DRB_VERBOSE > #options KTR > #options KTR_MASK=3DKTR_TRAP > ##options KTR_CPUMASK=3D0xF > #options KTR_VERBOSE >=20 > # Disable any extra checking for. . . > nooptions DEADLKRES # Enable the deadlock resolver > nooptions INVARIANTS # Enable calls of extra sanity = checking > nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS > nooptions WITNESS # Enable checks to detect = deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed > nooptions DIAGNOSTIC > nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones > nooptions BUF_TRACKING > nooptions FULL_BUF_TRACKING >=20 >=20 >=20 > Notes: >=20 > I do get the two messages during boot: >=20 > mmc0: ACMD42 failed, RESULT: 4 > mmc0: Card at relative address 43690 failed to set bus width >=20 > but things seem to be operating fine. The context for the below was probably unclear via my incomplete statement of context: > Because of my use of WITHOUT_BINTUTILS for buildworld buildkernel > I added: >=20 > BUILD_DEPENDS+=3D objdump:devel/binutils >=20 > to: >=20 > /usr/ports/sysutils/u-boot-master/Makefile >=20 > in order for sysutils/u-boot-pine64 to build under > poudriere-devel . I should have started with: "Because of my use of WITHOUT_BINTUTILS for buildworld buildkernel for my amd64 environment that I did the cross build to aarch64 from . . ." I built via an amd64 -> aarch64 cross build overall. The sysutils/u-boot-pine64 build tried to use the amd64 (or other host) objdump during its activity for cross builds and its absence in the *host* environment for the cross changed the result of the build before this change to the Makefile. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230288 is about that (starting from before I figured out what was going on). [I also also used WITHOUT_BINTUTILS for the aarch64 TARGET_ARCH in the cross build.] =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 Aug 19 16:53:06 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7651A106FC8D for ; Sun, 19 Aug 2018 16:53:06 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DF3807F99A for ; Sun, 19 Aug 2018 16:53:05 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 48a5998b; Sun, 19 Aug 2018 18:53:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=5/x/jD2e4CN9W2B3RStelZHRxMw=; b=ExwahQ+GUFpM0F3vGSpZ/4+3sn7l AHEIWbSFqqNfKQTay7mKaqIDh7iTCgnm/E1DuBD4Fl3heHS1HK68XfEqoXD4chMb Li/E3XthtmO1BOBeoyiMTZKcAsxV3T8PIGG1TGBtKSdnarBO1SLh9EOb9p1zWpTx hje9oablRh4v8Ok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=sKadti6eXxP4/zb4Inft8zR+yxQPP/Vqxpjg2Q01CQnM/eCocZ9TMtKa DoHmUXL/AFautSwFsr2Trr86dde+mU70U8iYjzQHnc7WxoBJnZVNxEBakLigh39W 2yLZe+DzbD8FwfI1TwTVZ0NwKTmBe8GDGpekkGKzGOeH60u9waI= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 871c9d33 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sun, 19 Aug 2018 18:53:03 +0200 (CEST) Date: Sun, 19 Aug 2018 18:53:03 +0200 From: Emmanuel Vadot To: "O. Hartmann" Cc: "freebsd-arm@freebsd.org" Subject: Re: [PINE64] mmcsd0: aw_mmc0: Error indicated Message-Id: <20180819185303.4130b0b7f78ee3df774f48e6@bidouilliste.com> In-Reply-To: <20180819160004.37874fd0@thor.intern.walstatt.dynvpn.de> References: <20180819141538.1eb442ef@thor.intern.walstatt.dynvpn.de> <20180819143933.ce9bc2e3853552810db3e181@bidouilliste.com> <20180819160004.37874fd0@thor.intern.walstatt.dynvpn.de> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 19 Aug 2018 16:53:06 -0000 On Sun, 19 Aug 2018 15:59:37 +0200 "O. Hartmann" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 >=20 > Am Sun, 19 Aug 2018 14:39:33 +0200 > Emmanuel Vadot schrieb: >=20 > > On Sun, 19 Aug 2018 14:15:11 +0200 > > "O. Hartmann" wrote: > >=20 > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA512 > > >=20 > > > Running 12-CURRENT for a while now on a PINE64+, 2GB RAM from SD, I f= ace since months > > > those errors regarding the aw_mmc controller: > > >=20 > > > [...] > > >=20 > > > aw_mmc0: controller timeout > > > aw_mmc0: timeout updating clock > > > mmcsd0: Error indicated: 1 Timeout > > > g_vfs_done():ufs/rootfs[WRITE(offset=3D3281551360, length=3D4096)]err= or =3D 5 > > > aw_mmc0: controller timeout > > > aw_mmc0: timeout updating clock > > > mmcsd0: Error indicated: 1 Timeout > > > g_vfs_done():ufs/rootfs[WRITE(offset=3D3282788352, length=3D4096)]err= or =3D 5 > > > aw_mmc0: controller timeout > > > aw_mmc0: timeout updating clock > > > mmcsd0: Error indicated: 1 Timeout > > > g_vfs_done():ufs/rootfs[WRITE(offset=3D3283681280, length=3D32768)]er= ror =3D 5 > > >=20 > > > [...] > > >=20 > > > ... and a while, the system ic completely stuck and needs hard reset. > > >=20 > > > I can remember this error since I played around with 12-CURRENT on th= e PINE64 and > > > that is on various revisions since December 2017. > > >=20 > > > Is this related to some known issues or could this be related to my h= ardware? > > >=20 > > > System is: > > >=20 > > > FreeBSD 12.0-CURRENT #13 r336753: Fri Jul 27 06:02:30 CEST 2018 arm64 > > >=20 > > > I have a custom-built kernel with some add-ons like IPFW. > > >=20 > > > Regards, > > >=20 > > > oh > > >=20 > > >=20 > > >=20 > > > - --=20 > > > O. Hartmann > > >=20 > > > Ich widerspreche der Nutzung oder =DCbermittlung meiner Daten f=FCr > > > Werbezwecke oder f=FCr die Markt- oder Meinungsforschung (=A7 28 Abs.= 4 BDSG). > > > -----BEGIN PGP SIGNATURE----- > > >=20 > > > iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW3lfawAKCRDS528fyFhY > > > lAppAf0SAdMz5OqhAa0bIvRxj3Ux8URIrbKPD7mZ38u2/4DQeYAE4kE9f4y39/Ei > > > M5yXC6CGpkE9V9i4L4CpnPLb1qUiAf9IiTiyxQOOOpIwWFEY78wrrcqAN8WFgio/ > > > 53SlY/5XGktXFvSGhvMrdq2FsPzMLjvNQ+mZJ6bv5Nq4yzgJNkSq > > > =3DGu6T > > > -----END PGP SIGNATURE----- > > > _______________________________________________ > > > freebsd-arm@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org= " =20 > >=20 > >=20 > > Can you please provide a full bootlog (booting with boot -v) > >=20 > > Also does those errors happens at boot ? after a while ? during > > something specific ? > >=20 > > Thanks, > >=20 >=20 > Hello Emmanuel Vadot, >=20 > I have just wrapped the PINE64 away since it died again while updating th= e OS via > pkg-base. >=20 > The problems shown occure after a while; not while booting as far as I re= member. The > larger the file to extract (for instance, FreeBSD-runtime pkg), the more = probable seems > the failure. But this is a "wild guess based on a hunch". >=20 > I haven't observed swapping so far. I'll start a new run when I've purcha= sed some SanDisc > high quality SD cards, since the ones I'm using are a bit slow. >=20 > It seems the problem occurs while heavy I/O is at work. >=20 > I'll provide the requested full bootlog later. >=20 > Kind regards, >=20 > O. Hartmann Okay so I've already seen this issue but I never could reproduce in a reliable way. If you can find a way to reproduce it with 100% success rate that could help me. > - --=20 > O. Hartmann >=20 > Ich widerspreche der Nutzung oder =DCbermittlung meiner Daten f=FCr > Werbezwecke oder f=FCr die Markt- oder Meinungsforschung (=A7 28 Abs. 4 B= DSG). > -----BEGIN PGP SIGNATURE----- >=20 > iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW3l35AAKCRDS528fyFhY > lPB5Af9p4jdGkNCkSsX2G6bQpINfYIcFrS9Mon0E/Bu9JvaK3Pegz3TaByO/h1Fw > hVR8HzhbiuVhdJVCZfdkPsOIqdW9AgCqNxKcv6/JvLPrb/84e+UMGk5SqWcIzytc > T+8DgOqBephnXk5WzZ131bkQYJ6aDsiHAmPbrk8rcPimQbS4q9XJ > =3DM6VH > -----END PGP SIGNATURE----- --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sun Aug 19 18:42:37 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 56BAC107401D for ; Sun, 19 Aug 2018 18:42:37 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C5CF084E53 for ; Sun, 19 Aug 2018 18:42:36 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([2.245.53.38]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LgIWi-1gENLi1OM8-00nhEd; Sun, 19 Aug 2018 20:42:34 +0200 Date: Sun, 19 Aug 2018 20:42:00 +0200 From: "O. Hartmann" To: Emmanuel Vadot Cc: "O. Hartmann" , "freebsd-arm@freebsd.org" Subject: Re: [PINE64] mmcsd0: aw_mmc0: Error indicated Message-ID: <20180819204227.562dbf11@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20180819185303.4130b0b7f78ee3df774f48e6@bidouilliste.com> References: <20180819141538.1eb442ef@thor.intern.walstatt.dynvpn.de> <20180819143933.ce9bc2e3853552810db3e181@bidouilliste.com> <20180819160004.37874fd0@thor.intern.walstatt.dynvpn.de> <20180819185303.4130b0b7f78ee3df774f48e6@bidouilliste.com> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:8wJv66D2jxsyITIzvBFUB7+XjknbW/qRYh516+dG66pziNhFt4w qV9BfXhxr7UB5Gyd0Iqm0qpy6X3hDGHKi/85V2T6MRwB/L+GSo1jyNqhFHynS8SaaEOZVkw JK4BxuFBQ/Ltmt7SbKLjDhuAx1qPBkYKU/v6OP+vT/TULi2W5Lqjdqz6e304n6g8pF4VuKg MMD04lZPhoAF2keDWY4Xw== X-UI-Out-Filterresults: notjunk:1;V01:K0:6bnlMjHYPeg=:k68RL/QIjCnF4CmN9tXJ9g z6AGRN7vZw6jsAOBAG0jXZZ3uv68BjJSi6F/4vXCKnqqyYAcv3W1bLXHwiyOpEcSZUexmq33l UbdNAXYsl4VlLPQ9Lp6Z8WtCsPeFpBssIDOiDS4+FfEXpVlu5de1bWXtU5B5qn/lfKHSxFDYk jR4IZ6MM1IaacQRb41hO2wMu+JdCvcs90K1Oe/gQRRAGJZCqyoAl86/x7v/4o2dd7JuIarrhA k7/CYj0Up7CwBMsUhZcgSQhxVJ51Rf/L4UR5jI0sAsQNYll/OltnPI7rGiMeKxbHXnbwD6Y1w Z5PKgOKMABnHIvyaZO8146T3PMp4NpSb3Ks10WL80JZZvz9rnAeoaeruMDI8u0QNjJDPHJNS7 dZ1ouAo0kvQqK642Cdr7mGPczRIgEXiJN4FP4YZmYcCQRHm73u/0/nKgaHa1EdKOIktApzBiU yzwdJIK2fxgvI/ZxLzsz63q+8ziFKuFYB9y6/oN+SCMloZdn1/Fpk1NptS66hXsUJKTV45/dv Xlbjtm9/fGhwsxSF+8R53YZM842MVPOiyGVlZeoYU38IkxbrR7nKYeefeGiyUMXS1YOtPOa6b gJjVMFmftVWlZEjCL58UxWwaSWvhiX8Q8qN2Pvo75ZMbKge1x24invYbnAkFXe/ivasAcZv19 6+DkABNRLx/8vMnRBbqxRmUr2Y2xtdTH8j33L4/qPetewl/Tfwh3Mkr5DQfrhHJlxPdEXSxOS I7DtNLkAAuHlt0fVie48JxTNscBDFl1dBBmjXlpD/HL9B2tfHOWhCfSAGuuH39yoqpGvP7WCH vDoeukG 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, 19 Aug 2018 18:42:37 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBNTEyDQoNCkFtIFN1 biwgMTkgQXVnIDIwMTggMTg6NTM6MDMgKzAyMDANCkVtbWFudWVsIFZhZG90IDxtYW51QGJpZG91 aWxsaXN0ZS5jb20+IHNjaHJpZWI6DQoNCj4gT24gU3VuLCAxOSBBdWcgMjAxOCAxNTo1OTozNyAr MDIwMA0KPiAiTy4gSGFydG1hbm4iIDxvaGFydG1hbm5Ad2Fsc3RhdHQub3JnPiB3cm90ZToNCj4g DQo+ID4gLS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KPiA+IEhhc2g6IFNIQTUx Mg0KPiA+IA0KPiA+IEFtIFN1biwgMTkgQXVnIDIwMTggMTQ6Mzk6MzMgKzAyMDANCj4gPiBFbW1h bnVlbCBWYWRvdCA8bWFudUBiaWRvdWlsbGlzdGUuY29tPiBzY2hyaWViOg0KPiA+ICAgDQo+ID4g PiBPbiBTdW4sIDE5IEF1ZyAyMDE4IDE0OjE1OjExICswMjAwDQo+ID4gPiAiTy4gSGFydG1hbm4i IDxvaGFydG1hbm5Ad2Fsc3RhdHQub3JnPiB3cm90ZToNCj4gPiA+ICAgDQo+ID4gPiA+IC0tLS0t QkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS0NCj4gPiA+ID4gSGFzaDogU0hBNTEyDQo+ID4g PiA+IA0KPiA+ID4gPiBSdW5uaW5nIDEyLUNVUlJFTlQgZm9yIGEgd2hpbGUgbm93IG9uIGEgUElO RTY0KywgMkdCIFJBTSBmcm9tIFNELCBJIGZhY2Ugc2luY2UNCj4gPiA+ID4gbW9udGhzIHRob3Nl IGVycm9ycyByZWdhcmRpbmcgdGhlIGF3X21tYyBjb250cm9sbGVyOg0KPiA+ID4gPiANCj4gPiA+ ID4gWy4uLl0NCj4gPiA+ID4gDQo+ID4gPiA+IGF3X21tYzA6IGNvbnRyb2xsZXIgdGltZW91dA0K PiA+ID4gPiBhd19tbWMwOiB0aW1lb3V0IHVwZGF0aW5nIGNsb2NrDQo+ID4gPiA+IG1tY3NkMDog RXJyb3IgaW5kaWNhdGVkOiAxIFRpbWVvdXQNCj4gPiA+ID4gZ192ZnNfZG9uZSgpOnVmcy9yb290 ZnNbV1JJVEUob2Zmc2V0PTMyODE1NTEzNjAsIGxlbmd0aD00MDk2KV1lcnJvciA9IDUNCj4gPiA+ ID4gYXdfbW1jMDogY29udHJvbGxlciB0aW1lb3V0DQo+ID4gPiA+IGF3X21tYzA6IHRpbWVvdXQg dXBkYXRpbmcgY2xvY2sNCj4gPiA+ID4gbW1jc2QwOiBFcnJvciBpbmRpY2F0ZWQ6IDEgVGltZW91 dA0KPiA+ID4gPiBnX3Zmc19kb25lKCk6dWZzL3Jvb3Rmc1tXUklURShvZmZzZXQ9MzI4Mjc4ODM1 MiwgbGVuZ3RoPTQwOTYpXWVycm9yID0gNQ0KPiA+ID4gPiBhd19tbWMwOiBjb250cm9sbGVyIHRp bWVvdXQNCj4gPiA+ID4gYXdfbW1jMDogdGltZW91dCB1cGRhdGluZyBjbG9jaw0KPiA+ID4gPiBt bWNzZDA6IEVycm9yIGluZGljYXRlZDogMSBUaW1lb3V0DQo+ID4gPiA+IGdfdmZzX2RvbmUoKTp1 ZnMvcm9vdGZzW1dSSVRFKG9mZnNldD0zMjgzNjgxMjgwLCBsZW5ndGg9MzI3NjgpXWVycm9yID0g NQ0KPiA+ID4gPiANCj4gPiA+ID4gWy4uLl0NCj4gPiA+ID4gDQo+ID4gPiA+IC4uLiBhbmQgYSB3 aGlsZSwgdGhlIHN5c3RlbSBpYyBjb21wbGV0ZWx5IHN0dWNrIGFuZCBuZWVkcyBoYXJkIHJlc2V0 Lg0KPiA+ID4gPiANCj4gPiA+ID4gSSBjYW4gcmVtZW1iZXIgdGhpcyBlcnJvciBzaW5jZSBJIHBs YXllZCBhcm91bmQgd2l0aCAxMi1DVVJSRU5UIG9uIHRoZSBQSU5FNjQgYW5kDQo+ID4gPiA+IHRo YXQgaXMgb24gdmFyaW91cyByZXZpc2lvbnMgc2luY2UgRGVjZW1iZXIgMjAxNy4NCj4gPiA+ID4g DQo+ID4gPiA+IElzIHRoaXMgcmVsYXRlZCB0byBzb21lIGtub3duIGlzc3VlcyBvciBjb3VsZCB0 aGlzIGJlIHJlbGF0ZWQgdG8gbXkgaGFyZHdhcmU/DQo+ID4gPiA+IA0KPiA+ID4gPiBTeXN0ZW0g aXM6DQo+ID4gPiA+IA0KPiA+ID4gPiBGcmVlQlNEIDEyLjAtQ1VSUkVOVCAjMTMgcjMzNjc1Mzog RnJpIEp1bCAyNyAwNjowMjozMCBDRVNUIDIwMTggYXJtNjQNCj4gPiA+ID4gDQo+ID4gPiA+IEkg aGF2ZSBhIGN1c3RvbS1idWlsdCBrZXJuZWwgd2l0aCBzb21lIGFkZC1vbnMgbGlrZSBJUEZXLg0K PiA+ID4gPiANCj4gPiA+ID4gUmVnYXJkcywNCj4gPiA+ID4gDQo+ID4gPiA+IG9oDQo+ID4gPiA+ IA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+IC0gLS0gDQo+ID4gPiA+IE8uIEhhcnRtYW5u DQo+ID4gPiA+IA0KPiA+ID4gPiBJY2ggd2lkZXJzcHJlY2hlIGRlciBOdXR6dW5nIG9kZXIg3GJl cm1pdHRsdW5nIG1laW5lciBEYXRlbiBm/HINCj4gPiA+ID4gV2VyYmV6d2Vja2Ugb2RlciBm/HIg ZGllIE1hcmt0LSBvZGVyIE1laW51bmdzZm9yc2NodW5nICinIDI4IEFicy4gNCBCRFNHKS4NCj4g PiA+ID4gLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NCj4gPiA+ID4gDQo+ID4gPiA+IGlM VUVBUk1LQUIwV0lRUVpWWk16QXR3QzJULzg2VHJTNTI4ZnlGaFlsQVVDVzNsZmF3QUtDUkRTNTI4 ZnlGaFkNCj4gPiA+ID4gbEFwcEFmMFNBZE16NU9xaEFhMGJJdlJ4ajNVeDhVUklyYktQRDdtWjM4 dTIvNERRZVlBRTRrRTlmNHkzOS9FaQ0KPiA+ID4gPiBNNXlYQzZDR3BrRTlWOWk0TDRDcG5QTGIx cVVpQWY5SWlUaXl4UU9PT3BJd1dGRVk3OHdycmNxQU44V0ZnaW8vDQo+ID4gPiA+IDUzU2xZLzVY R2t0WEZ2U0dodk1yZHEyRnNQek1ManZOUSttWko2YnY1TnE0eXpnSk5rU3ENCj4gPiA+ID4gPUd1 NlQNCj4gPiA+ID4gLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQo+ID4gPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IGZyZWVic2Qt YXJtQGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KPiA+ID4gPiBodHRwczovL2xpc3RzLmZyZWVi c2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1hcm0NCj4gPiA+ID4gVG8gdW5zdWJzY3Jp YmUsIHNlbmQgYW55IG1haWwgdG8gImZyZWVic2QtYXJtLXVuc3Vic2NyaWJlQGZyZWVic2Qub3Jn IiAgICANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiAgQ2FuIHlvdSBwbGVhc2UgcHJvdmlkZSBhIGZ1 bGwgYm9vdGxvZyAoYm9vdGluZyB3aXRoIGJvb3QgLXYpDQo+ID4gPiANCj4gPiA+ICBBbHNvIGRv ZXMgdGhvc2UgZXJyb3JzIGhhcHBlbnMgYXQgYm9vdCA/IGFmdGVyIGEgd2hpbGUgPyBkdXJpbmcN Cj4gPiA+IHNvbWV0aGluZyBzcGVjaWZpYyA/DQo+ID4gPiANCj4gPiA+ICBUaGFua3MsDQo+ID4g PiAgIA0KPiA+IA0KPiA+IEhlbGxvIEVtbWFudWVsIFZhZG90LA0KPiA+IA0KPiA+IEkgaGF2ZSBq dXN0IHdyYXBwZWQgdGhlIFBJTkU2NCBhd2F5IHNpbmNlIGl0IGRpZWQgYWdhaW4gd2hpbGUgdXBk YXRpbmcgdGhlIE9TIHZpYQ0KPiA+IHBrZy1iYXNlLg0KPiA+IA0KPiA+IFRoZSBwcm9ibGVtcyBz aG93biBvY2N1cmUgYWZ0ZXIgYSB3aGlsZTsgbm90IHdoaWxlIGJvb3RpbmcgYXMgZmFyIGFzIEkg cmVtZW1iZXIuIFRoZQ0KPiA+IGxhcmdlciB0aGUgZmlsZSB0byBleHRyYWN0IChmb3IgaW5zdGFu Y2UsIEZyZWVCU0QtcnVudGltZSBwa2cpLCB0aGUgbW9yZSBwcm9iYWJsZQ0KPiA+IHNlZW1zIHRo ZSBmYWlsdXJlLiBCdXQgdGhpcyBpcyBhICJ3aWxkIGd1ZXNzIGJhc2VkIG9uIGEgaHVuY2giLg0K PiA+IA0KPiA+IEkgaGF2ZW4ndCBvYnNlcnZlZCBzd2FwcGluZyBzbyBmYXIuIEknbGwgc3RhcnQg YSBuZXcgcnVuIHdoZW4gSSd2ZSBwdXJjaGFzZWQgc29tZQ0KPiA+IFNhbkRpc2MgaGlnaCBxdWFs aXR5IFNEIGNhcmRzLCBzaW5jZSB0aGUgb25lcyBJJ20gdXNpbmcgYXJlIGEgYml0IHNsb3cuDQo+ ID4gDQo+ID4gSXQgc2VlbXMgdGhlIHByb2JsZW0gb2NjdXJzIHdoaWxlIGhlYXZ5IEkvTyBpcyBh dCB3b3JrLg0KPiA+IA0KPiA+IEknbGwgcHJvdmlkZSB0aGUgcmVxdWVzdGVkIGZ1bGwgYm9vdGxv ZyBsYXRlci4NCj4gPiANCj4gPiBLaW5kIHJlZ2FyZHMsDQo+ID4gDQo+ID4gTy4gSGFydG1hbm4g IA0KPiANCj4gIE9rYXkgc28gSSd2ZSBhbHJlYWR5IHNlZW4gdGhpcyBpc3N1ZSBidXQgSSBuZXZl ciBjb3VsZCByZXByb2R1Y2UgaW4gYQ0KPiByZWxpYWJsZSB3YXkuDQo+ICBJZiB5b3UgY2FuIGZp bmQgYSB3YXkgdG8gcmVwcm9kdWNlIGl0IHdpdGggMTAwJSBzdWNjZXNzIHJhdGUgdGhhdA0KPiBj b3VsZCBoZWxwIG1lLg0KDQpbLi4uXQ0KDQpNYXliZSA5MCUgc3VjY2VzcyByYXRlOg0KDQpVc2Ug YSBrZXJuZWwgd2l0aCBkZWJ1ZyBkaXNhYmxlZCghKSBhbmQgdXBkYXRlIHBrZy1iYXNlIHJlbW90 ZWx5IHdoaWxlIHJ1bm5pbmcgdGhlDQpjdXN0b21pc2VkIGtlcm5lbC4gSW4gbXkgY2FzZSwgdGhp cyBpcyBhIDEwMCUgY3Jhc2ggc28gZmFyLiBJIGFsc28gc2VlIHRoZSBwcm9ibGVtDQpvY2N1cmlu ZyB3aXRoIHRoZSB2YW5pbGxhIEdFTkVSSUMga2VybmVsLCBidXQgZGlzYWJsaW5nIG1vc3Qgb2Yg dGhlIGR1YnVnZ2luZyBvcHRpb25zDQphbmQgZGlzYWJsaW5nIG1vc3Qgb2YgdGhlIGRyaXZlciBu b24tYXBwbGljYWJsZSB0byBQSU5FNjQrIGluIGEgY3VzdG9tIGtlcm5lbCB0cmlnZ2VyDQp0aGUg cHJvYmxlbSByZWFsbHkgcmFwaWRseS4NCg0Kb2ggDQoNCg0KLSAtLSANCk8uIEhhcnRtYW5uDQoN CkljaCB3aWRlcnNwcmVjaGUgZGVyIE51dHp1bmcgb2RlciDcYmVybWl0dGx1bmcgbWVpbmVyIERh dGVuIGb8cg0KV2VyYmV6d2Vja2Ugb2RlciBm/HIgZGllIE1hcmt0LSBvZGVyIE1laW51bmdzZm9y c2NodW5nICinIDI4IEFicy4gNCBCRFNHKS4NCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0t DQoNCmlMVUVBUk1LQUIwV0lRUVpWWk16QXR3QzJULzg2VHJTNTI4ZnlGaFlsQVVDVzNtNkZBQUtD UkRTNTI4ZnlGaFkNCmxPUnBBZ0Noc1huQ1RPc1BTc0M2bjk3SGo1YWU5N21teVBod2N1cENGUzhU K3ZIK0ZKZVRoMkg3NittY25laUgNCmpmZVV6UHlMRFJHOTFlbjQzVFhvRWVMd1hTQ1BBZjRtZ2hx eEZndWxPaXNKbHdsOFBibHRZSkx3VGNWMGEySDINCmpDNldwdWJrejRHRHdQTTV2dmlZMVZERGVm VVlBMGZXTHBOQ092dFpxakpBbkFkTkdYYWUNCj1ZN2JHDQotLS0tLUVORCBQR1AgU0lHTkFUVVJF LS0tLS0NCg== From owner-freebsd-arm@freebsd.org Sun Aug 19 18:56:11 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 B5DCF10747EE for ; Sun, 19 Aug 2018 18:56:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-14.consmr.mail.bf2.yahoo.com (sonic311-14.consmr.mail.bf2.yahoo.com [74.6.131.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5DC2585B59 for ; Sun, 19 Aug 2018 18:56:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: v1heoBoVM1nv85RnZ1tcB2ZnF1cIPRRRy5bp4uP0dnCbyk9lCjBN8wA6Xg6uIUH _wPT9O7G6Khg_rvIwDLVhVAG7WKkYflr2F5FePshP3Icki.ZpLs.wJPmYEIEZ1fsg2ZNcnM5MeZA gSpprRwb_zu_ADkrL2Oq6FdPfzpfs68EwfWyzBN6SaOlsbBvb7vGYXPYLryWfD8tAY6PSHu_WC1M F_sP_Urqcom.VoTlEmpDADZopjHAnEytVcJZx6a.j8CgJ8shEu2O_T0cLxWZotXMl_VyRB5brYHO WhFuo2qmt4o8N0bpuvMNP3_JUFdI80Vz7HcG99LleoznFSFNf7C5pZWhv3x0yfflJhNU8H8uyrzr 4SB.vo3LgwK2MrGM4bnqZ3nBRZNyJtFMqQUEzRsR9wvNITNpxxR.JmJQsMJwuxw2Ke55PeFi7lP_ _48j0CJT3c46x_xOzW0qxyujJRlr3ll2xKehlKA7YEEysPGDEA4eEmiP5urGAaxt5kb158zov_nc vwRNnYYDiJtwq_IkkFTv2n3vjUkn11aWKl2wQNsnyvWRLAREtL_VNT4Ob2lOrsZxIyb.GutTVH1S T3n4sr_zmOTuP9NfX.1xnFmxp7FV3Ek.XT9BirlNflOb99mINkcnl0y_UlpQFFbDeoJTCXohssn. wTvjieEYsLgni9CuIhpp4SM9Y4aQSHH35IfLN6c6EaTqRMe.VywWcpBTIRReLkYKgFYaX4ch6PLM S5PfxP9HmSJLnfwmpOuBD.L9zK2Uj4xIx91L_eN0fRE5ZQEADNzUkdLrFfgRbi8EpnKie5NbD7yw fflKY058nbl5nqtV6ffQJjqda1gO_qdEkv8RsF6MquJYgDPjkSrvyEqUWHj6_Nqnr5JP_e0jYmxC AJBTkil.jLVLtTmiiNia9BGKmuD29QlaFq_zFWw5d0BFJi8Fjs7Fy6SKpKMbEHRuTh8m6ZRIczjZ u91UieTa2ieR.Wl3IX_6RzsC4a9TbHeH92w8vLYufo4xv2vQrR8tCNbNJne4p0qVTntjC_y6L.g- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Sun, 19 Aug 2018 18:56:05 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp425.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 3333fc28a50a5e5cfab4cbee3cbb6a57; Sun, 19 Aug 2018 18:56:03 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: An odd example of the Pine64+ 2GB time jump? Or an interesting one? From: Mark Millard In-Reply-To: Date: Sun, 19 Aug 2018 11:56:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <16742A08-A315-422E-9869-E484D47AD8EB@yahoo.com> References: To: 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: Sun, 19 Aug 2018 18:56:11 -0000 [No examples during a 44 hr monitoring during a poudriere-devel run.] On 2018-Aug-17, at 9:41 AM, Mark Millard wrote: > The oddity is the timing of that 1st no_sys_peer reported > at 17 Aug 07:24:09 (before the time is adjusted) in what > is later reported below: timing relative to other things > going on that had not been going on just before. >=20 > The sequence establishing context follows . . . >=20 > Henri Hennebert asked me to > do some time monitoring during the long running > poudriere-devel involving, for example, building > lang/gcc8 with a full bootstrap. >=20 > This was started during that lang/gcc8 build the > 2nd /var/log/ntp.log content below was discovered > during the package stage of what turned out to be > a 12:32:45 or so for lang/gcc8 overall. Earlier > was during the build stage. >=20 > Notes: The laptop has 2 ssh sessions in to the > Pine64+ 2GB, including the one with material > below and the one running poudriere-devel. The > laptop is also what is monitoring the serial > console. I've not applied any patches for the > time issue. >=20 >=20 > (Note: there were prior instances of the date ; more > command sequence that are not shown.) >=20 > # date ; more /var/log/ntp.log > Fri Aug 17 03:04:12 PDT 2018 > 17 Aug 01:02:20 ntpd[49765]: Listen and drop on 0 v6wildcard [::]:123 > 17 Aug 01:02:20 ntpd[49765]: Listen and drop on 1 v4wildcard = 0.0.0.0:123 > 17 Aug 01:02:20 ntpd[49765]: Listen normally on 2 awg0 = 192.168.0.100:123 > 17 Aug 01:02:20 ntpd[49765]: Listen normally on 3 lo0 [::1]:123 > 17 Aug 01:02:20 ntpd[49765]: Listen normally on 4 lo0 [fe80::1%2]:123 > 17 Aug 01:02:20 ntpd[49765]: Listen normally on 5 lo0 127.0.0.1:123 > 17 Aug 01:02:20 ntpd[49765]: Listening on routing socket on fd #26 for = interface updates > 17 Aug 01:02:20 ntpd[49765]: 0.0.0.0 c01d 0d kern kernel time sync = enabled > 17 Aug 01:02:20 ntpd[49765]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM > 17 Aug 01:02:20 ntpd[49765]: 0.0.0.0 c011 01 freq_not_set > 17 Aug 01:02:20 ntpd[49765]: 0.0.0.0 c016 06 restart > 17 Aug 01:02:21 ntpd[49765]: Soliciting pool server 103.105.51.156 > 17 Aug 01:02:22 ntpd[49765]: Soliciting pool server 45.77.78.241 > 17 Aug 01:02:23 ntpd[49765]: Soliciting pool server 198.98.57.16 > 17 Aug 01:02:24 ntpd[49765]: Soliciting pool server 173.230.152.251 > 17 Aug 01:02:30 ntpd[49765]: 0.0.0.0 c614 04 freq_mode > 17 Aug 01:05:46 ntpd[49765]: Soliciting pool server 74.207.240.206 > 17 Aug 01:07:58 ntpd[49765]: 0.0.0.0 0612 02 freq_set kernel 36.141 = PPM > 17 Aug 01:07:58 ntpd[49765]: 0.0.0.0 0615 05 clock_sync > pine64# fg > top -CawSores > . . . (I go to bed during this time; the laptop screen locks) . . . > . . . (when I get back in I read an Email from Henri H. before the = below) . . . > [1] + Suspended top -CawSores > # date ; more /var/log/ntp.log > Fri Aug 17 07:23:04 PDT 2018 > 17 Aug 01:02:20 ntpd[49765]: Listen and drop on 0 v6wildcard [::]:123 > 17 Aug 01:02:20 ntpd[49765]: Listen and drop on 1 v4wildcard = 0.0.0.0:123 > 17 Aug 01:02:20 ntpd[49765]: Listen normally on 2 awg0 = 192.168.0.100:123 > 17 Aug 01:02:20 ntpd[49765]: Listen normally on 3 lo0 [::1]:123 > 17 Aug 01:02:20 ntpd[49765]: Listen normally on 4 lo0 [fe80::1%2]:123 > 17 Aug 01:02:20 ntpd[49765]: Listen normally on 5 lo0 127.0.0.1:123 > 17 Aug 01:02:20 ntpd[49765]: Listening on routing socket on fd #26 for = interface updates > 17 Aug 01:02:20 ntpd[49765]: 0.0.0.0 c01d 0d kern kernel time sync = enabled > 17 Aug 01:02:20 ntpd[49765]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM > 17 Aug 01:02:20 ntpd[49765]: 0.0.0.0 c011 01 freq_not_set > 17 Aug 01:02:20 ntpd[49765]: 0.0.0.0 c016 06 restart > 17 Aug 01:02:21 ntpd[49765]: Soliciting pool server 103.105.51.156 > 17 Aug 01:02:22 ntpd[49765]: Soliciting pool server 45.77.78.241 > 17 Aug 01:02:23 ntpd[49765]: Soliciting pool server 198.98.57.16 > 17 Aug 01:02:24 ntpd[49765]: Soliciting pool server 173.230.152.251 > 17 Aug 01:02:30 ntpd[49765]: 0.0.0.0 c614 04 freq_mode > 17 Aug 01:05:46 ntpd[49765]: Soliciting pool server 74.207.240.206 > 17 Aug 01:07:58 ntpd[49765]: 0.0.0.0 0612 02 freq_set kernel 36.141 = PPM > 17 Aug 01:07:58 ntpd[49765]: 0.0.0.0 0615 05 clock_sync > 17 Aug 07:24:09 ntpd[49765]: 0.0.0.0 0618 08 no_sys_peer > 17 Aug 07:24:42 ntpd[49765]: Soliciting pool server 162.254.66.243 > 17 Aug 07:24:43 ntpd[49765]: Soliciting pool server 129.250.35.251 > 17 Aug 07:24:44 ntpd[49765]: Soliciting pool server 173.255.206.154 > 17 Aug 07:24:45 ntpd[49765]: Soliciting pool server 74.6.168.72 > 17 Aug 07:24:46 ntpd[49765]: Soliciting pool server 45.79.111.114 > 17 Aug 07:24:47 ntpd[49765]: Soliciting pool server 69.195.159.158 > 17 Aug 07:24:48 ntpd[49765]: Soliciting pool server 199.223.248.98 > 17 Aug 07:25:53 ntpd[49765]: 0.0.0.0 0613 03 spike_detect -178.954593 = s > 17 Aug 07:25:56 ntpd[49765]: 0.0.0.0 061c 0c clock_step -178.956586 s > 17 Aug 07:22:57 ntpd[49765]: 0.0.0.0 0615 05 clock_sync > 17 Aug 07:22:58 ntpd[49765]: 0.0.0.0 c618 08 no_sys_peer > 17 Aug 07:22:58 ntpd[49765]: 198.98.57.16 local addr 192.168.0.100 -> = >=20 > The oddity is the timing of that 1st no_sys_peer reported > at 17 Aug 07:24:09 (before the time is adjusted): it appears > to be very closely timed with activity near my logging in > on the laptop and starting to do things before the 2nd > "date" above. >=20 > It is almost like my new activity "kicked" the Pine64+ > 2GB and ended up with the 1st no_sys_peer as a result. >=20 >=20 > Looking around about no_sys_peer: >=20 > "Indicates that there is no server that satisfies ntpd=E2=80=99s = stability criteria" >=20 > So it might be tied ntpd noticing the time being odd and the > later activity is ntpd gaining independent evidence of the > from a set of servers and finally accepting the error is > likely real and adjusting for it. >=20 > [This suggests that the "no_sys_peer" is the best indicator > of when the time difference was noted.] >=20 > The second no_sys_peer could fit with this based on its > having adjusted the clock and needing to re-certify. >=20 >=20 > It appears that either I was very lucky in the > timing of waking up and taking a look at the status > or that activity somehow contributed to the timing > of the no_sys_peer and related activity. >=20 >=20 > I wonder if these notes should be referenced in: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229644 >=20 > (The "Affects Only Me" status there could be updated > as well, not that I could do that.) >=20 >=20 > For reference: >=20 > head -r337400 is in use on the Pine64+ 2GB. >=20 > I've not applied any patches for the time issue. >=20 > The Pine64+ 2GB has a case, heat sinks, and a fan. > UFS, not ZFS is in use. >=20 > Ethernet is in use. >=20 > Other than the serial console connection, nothing > else is connected. >=20 > As stands I'm using an e.MMC for the root file > system and swap partition. But it is on a microsd > adapter, plugged into a USB 3.0 capable reader, that > in turn is plugged in to the bottom USB port on the > Pine64+ 2GB. (I've used other USB media before. > (Most types are more reliable with a powered hub > but the e.MMC/USB combination has never shown evidence > of needing such.) >=20 > (It used to be the Pine64+ 2GB would boot from the > e.MMC on the microsd adpater. But that is not true > now based on what FreeBSD tries to do with the e.MCC > that the Pine64+ 2GB can not actually do: a voltage > change. Thus the USB involvement these days.) I disabled the laptop from doing a blank-screen/partial-sleep and used a different root file system device (more capacity) that involved using a powered hub. I then did a poudriere-devel run that lasted 47 hours, including building devel/gcc8 (a little under 12.5 hours and late in the overall time). I was interrupted before starting the ntp.log file and so the tracking spans the last 44 or so hrs instead of the full 47 hours: # date ; more /var/log/ntp.log Sun Aug 19 10:50:48 PDT 2018 17 Aug 14:28:51 ntpd[20620]: Listen and drop on 0 v6wildcard [::]:123 17 Aug 14:28:51 ntpd[20620]: Listen and drop on 1 v4wildcard 0.0.0.0:123 17 Aug 14:28:51 ntpd[20620]: Listen normally on 2 awg0 192.168.0.100:123 17 Aug 14:28:51 ntpd[20620]: Listen normally on 3 lo0 [::1]:123 17 Aug 14:28:51 ntpd[20620]: Listen normally on 4 lo0 [fe80::1%2]:123 17 Aug 14:28:51 ntpd[20620]: Listen normally on 5 lo0 127.0.0.1:123 17 Aug 14:28:51 ntpd[20620]: Listening on routing socket on fd #26 for = interface updates 17 Aug 14:28:51 ntpd[20620]: 0.0.0.0 c01d 0d kern kernel time sync = enabled 17 Aug 14:28:51 ntpd[20620]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM 17 Aug 14:28:51 ntpd[20620]: 0.0.0.0 c011 01 freq_not_set 17 Aug 14:28:51 ntpd[20620]: 0.0.0.0 c016 06 restart 17 Aug 14:28:52 ntpd[20620]: Soliciting pool server 199.223.248.99 17 Aug 14:28:53 ntpd[20620]: Soliciting pool server 204.9.54.119 17 Aug 14:28:54 ntpd[20620]: Soliciting pool server 128.2.1.22 17 Aug 14:28:55 ntpd[20620]: Soliciting pool server 74.6.168.73 17 Aug 14:28:59 ntpd[20620]: 0.0.0.0 c614 04 freq_mode 17 Aug 14:32:19 ntpd[20620]: Soliciting pool server 72.30.35.88 17 Aug 14:34:39 ntpd[20620]: 0.0.0.0 0612 02 freq_set kernel 59.409 PPM 17 Aug 14:34:39 ntpd[20620]: 0.0.0.0 0615 05 clock_sync (This also spans the pkg update and pkg upgrade and a few package installs after the poudriere-devel run.) This makes the one observed "spike_detect -178.954593 s" example and its timing relative to my activity seemingly somewhat more special. =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 Aug 19 19:00: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 267231074A00 for ; Sun, 19 Aug 2018 19:00:53 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D36585DAD for ; Sun, 19 Aug 2018 19:00:50 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id c25bbf1e; Sun, 19 Aug 2018 21:00:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=B6sp0X0IwoBf6XtyPQrAQpI2uCI=; b=ZsDp70HPHIZymgr/93Lbh4SJyWsJ Qk7cbLfPXPZ+/B4MsNeDXfyrMI98/U2a9w0WT9iR03LKcFn4BoRG140iYdyCYVpb qEBZO6kGEG4FqMwmUTj32XYbvk4PxTQ+I05mfP6yJxdPWz4qtCJCFq8RDHIsDobB OVaWZY9duUQLG1g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=OXfHk0d0bO6GfQ8nwvUPB3mzIzQN/p7SbtXWcI8Rh6RtN805jdUli4W4 193m/zzx/o7tLbw8a2XLbgh3dpnmFwDW8JLdbDM79Wfv5XjiLSMDw31fD3lv02Oz TUH2X9A4d8g8xHM1LqL+Olk/VLoWixlXKtiR57a8G/IzPOD+oM0= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 387386ea TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sun, 19 Aug 2018 21:00:47 +0200 (CEST) Date: Sun, 19 Aug 2018 21:00:47 +0200 From: Emmanuel Vadot To: John-Mark Gurney Cc: freebsd-arm@FreeBSD.org Subject: Re: attempted to get A64-LTS thermal working Message-Id: <20180819210047.2421f482b29457025b27643d@bidouilliste.com> In-Reply-To: <20180813173220.GL97145@funkthat.com> References: <20180813173220.GL97145@funkthat.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 19 Aug 2018 19:00:53 -0000 Hi John-Mark, On Mon, 13 Aug 2018 10:32:20 -0700 John-Mark Gurney wrote: > So, w/ a pointer from manu: https://twitter.com/manuvadot/status/1029002683892609026 > > I'm working from the July 9th snapshot, FreeBSD-12.0-CURRENT-arm64-aarch64-PINE64-20180709-r336134.img > > I tried to put the dtb on the FAT partition, but u-boot doesn't seem to > load it: > [freebsd@generic ~]$ ls /boot/msdos/dtb/allwinner/sun50i-a64-sopine-baseboard.dtb > /boot/msdos/dtb/allwinner/sun50i-a64-sopine-baseboard.dtb > > So, I decided to manually load the dtb w/ loader: > OK set currdev=disk0p1: > OK load -t dtb dtb/allwinner/sun50i-a64-sopine-baseboard.dtb > dtb/allwinner/sun50i-a64-sopine-baseboard.dtb size=0x5c63 > > and w/ it loaded, I can see the thermal device: > aw_thermal0: mem 0x1c25000-0x1c250ff irq 8 on simplebus0 > > and: > root@generic:~ # sysctl -a | grep therm > dev.aw_thermal.0.gpu2: 24C > dev.aw_thermal.0.gpu1: 23C > dev.aw_thermal.0.cpu: 24C > dev.aw_thermal.0.%parent: simplebus0 > dev.aw_thermal.0.%pnpinfo: name=thermal_sensor@1c25000 compat=allwinner,sun50i-a64-ths > dev.aw_thermal.0.%location: > dev.aw_thermal.0.%driver: aw_thermal > dev.aw_thermal.0.%desc: Allwinner Thermal Sensor Controller > dev.aw_thermal.%parent: > > but then the ethernet does not work: > awg0: mem 0x1c30000-0x1c3ffff irq 30 on simplebus0 > awg0: Failed to find syscon node > awg0: cannot get syscon driver handle > miibus0: on awg0 > rgephy0: PHY 0 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > rgephy1: PHY 1 on miibus0 > rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow > awg0: Ethernet address: 02:ba:1a:xx:xx:xx > > and it never gets link: > Waiting 30s for the default route interface: .....(no carrier) > > I've put the broken boot at: > https://www.funkthat.com/~jmg/FreeBSD/arm/a64-lts.broken.20180813.txt > > I've put the working boot at: > https://www.funkthat.com/~jmg/FreeBSD/arm/a64-lts.working.20180813.txt > > took me a few seconds to realize that the reason they are about the > same length is that the broken has additional other drivers like the > mx2510 flash driver and spi. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" This is now fixed with r338070 Thanks for reporting. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Aug 20 02:01:58 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 18619107FC3D for ; Mon, 20 Aug 2018 02:01:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.ne1.yahoo.com (sonic302-20.consmr.mail.ne1.yahoo.com [66.163.186.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A40D97515B for ; Mon, 20 Aug 2018 02:01:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: pyGL9U8VM1kel8XOe9_eUogAuzeyOJYwUE1Gu5bB3HIkfSjPQoLvfS.x9fvf_y0 iLPOOIKiNa7sAKQ8.Mm8nn9aWdqvpFHH72uJcG.yjmVWxEoKCePIRAMRDmJMvfpVwG4DfUvj1U_s 4B0y7lSDM3CvtH2EH8Wsh_tMAKW717TcutbXqrEexD41c1BjjKP9ZkdD3mIz8vNp4YfuoeHL6R9u n0UzyRH0XSdXbyWaMStd3x0cdzPLJ3s19AncqqMGuSinRTikFgweDzYuAzZvpf5zcH7.tOBXGm6y uWEV7dfmlvA6zNdpLxioeIx82y9PwYAUDtyZqRk0ogbTLkJBRgRBkz5yTaTo7Qze8dcWkp5gSp80 vtmIqrN06fkvW5SNjIgnKJAXGCdXBjBVEmpZ_t9lX_XwFIH00T5a2UP_6FmbYYRZ_r2W24YTTx4F DFwQDKzrKHkhYpTk7B0xSxlo5aPqki1YVezuwG_b1jhfmr.fXiRKMB_Ca1.nA.YBTfOUf1D48dW6 1IipElhknCAlikwymvB1n8kdZ40mBs.VSU_N1hVbcXRVb5oyAmhcJIVO93APS4gDOCBjslQDDiYF AwVZLepcenvs4sR5XGEp0l_c62mKePcmRWolSJSZhhi36FdXL.4NUzr8BUeNda9yWh_.WQvWhMLg efqRzXSlfSQIl7kunA5Ut7Qb6cCdP7m9YhjE4vwBfOI0sTExkDvN.qKmkeD1fLHoOE2J_mQgMHTk IeGFTwzVeWXbEe0aroFE1rA5nFxE0fYrvwcjm8iq8s5sfKFKaIRj1m5p8ViCuKPGkUBcVbCgIlKs JNh.wQ.czD3qBz_RGB8CWgMJymX5vox1O9hG7FKcNVH.ZNiO7dmc5WTce4VwV1ya1qFsOMXzJpbv ooTIFjfrT16e.brNjaRiO6x8SVHYL5c8sx3hdX895jwlo5CtzfUwREs8oj2na17flz8LjJ8v8MSV n5RzwEOxqiKnzfM1E1GWAqnI.74RC_qReY_l3vExCaU9xHI_snziWRW0YzZKuHNEhBCo5yBH_Xlu c3btAD3KlGj4p0vsElRa1OmYBwRpny4j5CWcOQ7MkYyP4_QHAjRVgQ_GG.tHxBAaH Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Mon, 20 Aug 2018 02:01:51 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp404.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 692bb5a3356159167badf07f79769be0; Mon, 20 Aug 2018 01:41:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Attempted large jump to head -r337347 for pine64+ 2GB did not finish the boot: eventual MMC handling problems before root file system is mounted From: Mark Millard In-Reply-To: <33AFF697-FB1E-4349-93C7-888C184CBBD4@yahoo.com> Date: Sun, 19 Aug 2018 18:41:32 -0700 Cc: Mark Millard via freebsd-arm , Marius Strobl Content-Transfer-Encoding: quoted-printable Message-Id: <75CA8B85-3EB8-4C03-AADC-3560B600B99F@yahoo.com> References: <0918383D-5A5A-40A0-ADCB-08C500153BE1@yahoo.com> <20180806124421.0b622761272370d2946cac29@bidouilliste.com> <0FF066AF-D9F3-4523-8203-B9405091F10A@yahoo.com> <20180806193755.8c4e9a63bcd0870d55fe3969@bidouilliste.com> <05447ED6-3E61-4D67-B300-3182CB07079A@yahoo.com> <93D377C9-9123-40AF-AF5F-B3437831A91D@yahoo.com> <5A44C1CC-DB88-4C07-8F31-FD4348BBA6C6@yahoo.com> <20180809220012.GU21523@alchemy.franken.de> <22CDDB1E-48D5-4F60-9345-78992867299F@yahoo.com> <2BB6ADC9-FA89-4C49-90B8-27CD6B1842AF@yahoo.com> <20180810085932.248050e3383151efb41c967c@bidouilliste.com> <0A01DBA9-557A-435D-9CB4-35A7BFA1BAC1@yahoo.com> <33AFF697-FB1E-4349-93C7-888C184CBBD4@yahoo.com> To: Emmanuel Vadot 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, 20 Aug 2018 02:01:58 -0000 [Add a note about High Speed on both USB connectors under that modern linux.] On 2018-Aug-10, at 4:45 AM, Mark Millard wrote: > [A note about CARD_TYPE/DEVICE_TYPE is added.] >=20 > On 2018-Aug-10, at 3:53 AM, Mark Millard wrote: >=20 >> [A note about linux booting is added.] >>=20 >> On 2018-Aug-10, at 1:10 AM, Mark Millard = wrote: >>=20 >>> . . . >>=20 >>=20 >> Just to see what a modern linux with a modern kernel >> might do I downloaded: >>=20 >> https://dl.armbian.com/pine64/Ubuntu_bionic_dev_nightly.7z >>=20 >> which is: >>=20 >> nightly mainline kernel master branch 4.17.y or 4.18.y >>=20 >> # uname -ap >> Linux pine64 4.18.0-rc4-sunxi64 #220 SMP Sun Jul 15 14:16:31 UTC 2018 = aarch64 aarch64 aarch64 GNU/Linux >>=20 >> I put it on an e.MMC and used it to boot the pine64+ 2GB >> via the e.MMC adapter and it booted fine. >>=20 >> # cat /sys/kernel/debug/mmc0/ios >> clock: 52000000 Hz >> actual clock: 50000000 Hz >> vdd: 21 (3.3 ~ 3.4 V) >> bus mode: 2 (push-pull) >> chip select: 0 (don't care) >> power mode: 2 (on) >> bus width: 2 (4 bits) >> timing spec: 8 (mmc DDR52) >> signal voltage: 0 (3.30 V) >> driver type: 0 (driver type B) >>=20 >> # hdparm -t /dev/mmcblk0 >>=20 >> /dev/mmcblk0: >> Timing buffered disk reads: 134 MB in 3.04 seconds =3D 44.03 MB/sec >>=20 >> # hdparm -T /dev/mmcblk0 >>=20 >> /dev/mmcblk0: >> Timing cached reads: 1298 MB in 2.00 seconds =3D 649.15 MB/sec >>=20 >> For interpreting those (-t vs. -T): >>=20 >> QUOTE >> -t Perform timings of device reads for benchmark and = comparison purposes. For meaningful results, this operation should be = repeated 2-3 times on an otherwise inactive system (no other >> active processes) with at least a couple of megabytes = of free memory. This displays the speed of reading through the buffer = cache to the disk without any prior caching of data. >> This measurement is an indication of how fast the drive = can sustain sequential data reads under Linux, without any filesystem = overhead. To ensure accurate measurements, the buffer >> cache is flushed during the processing of -t using the = BLKFLSBUF ioctl. >>=20 >> -T Perform timings of cache reads for benchmark and = comparison purposes. For meaningful results, this operation should be = repeated 2-3 times on an otherwise inactive system (no other >> active processes) with at least a couple of megabytes of = free memory. This displays the speed of reading directly from the Linux = buffer cache without disk access. This measurement >> is essentially an indication of the throughput of the = processor, cache, and memory of the system under test. >> END QUOTE >>=20 >> So it appears to me that the DDR52 over 4 data bits is real, >> despite the apparent 3.3V usage for VCCQ (and so VCC as well). >>=20 >> In other words: they are using e.MCC CARD_TYPE/DEVICE_TYPE bit 2: >>=20 >> Bit 2: High-speed DDR MultimediaCard @ (at most) 52 MHz - 1.8aV or 3V = I/O >>=20 >> and were not restricted to just the microSDHC speed and I/O voltage >> combinations by the Pine64+ 2GB. >=20 > I discovered another command: >=20 > # mmc extcsd read /dev/mmcblk0 | more > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Extended CSD rev 1.8 (MMC 5.1) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > . . . > Card Type [CARD_TYPE: 0x57] > HS200 Single Data Rate eMMC @200MHz 1.8VI/O > HS Dual Data Rate eMMC @52MHz 1.8V or 3VI/O > HS eMMC @52MHz - at rated device voltage(s) > HS eMMC @26MHz - at rated device voltage(s) > . . . >=20 > Which is interesting by having 5 bits set in 0x57 > but only listing 4 of the alternatives. The missing > one would be for: >=20 > HS400 DDR e.MMC @ 200 MHz - 1.8V I/O >=20 > (In essence, no 1.2V alternative is supported.) >=20 > It did not pick to attempt a 1.8V-only mode but > instead to pick the fastest of the 3V-compatibile > modes (in e.MCC terms). Just an FYI . . . I booted that modern linux again again and plugged in 2 USB 3.0 capable contexts that allow for USB 2.0 as well, one in the upper USB connector and one in the lower one. Then using lsusb -v I found: For the card reader (with multiple ports) and plugged into the lower USB connector: Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 4 wHubCharacteristic 0x00e9 Per-port power switching Per-port overcurrent protection TT think time 32 FS bits Port indicators bPwrOn2PwrGood 50 * 2 milli seconds bHubContrCurrent 100 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0503 highspeed power enable connect Port 2: 0000.0100 power Port 3: 0000.0100 power Port 4: 0000.0507 highspeed power suspend enable connect For the powered hub with a USB stick plugged into the upper USB connector: Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 1 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 10 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0503 highspeed power enable connect Device Status: 0x0001 Self Powered So both USB ports are selecting high-speed at the same time on the Pine64+ 2GB. It is definitely seeing both storage devices, one per USB connector, which I can tell from: # ls /dev/disk/*label/* | more /dev/disk/by-label/BFAT /dev/disk/by-label/PINE642Grootfs /dev/disk/by-label/PINE64P2Grootfs /dev/disk/by-partlabel/PINE642Gboot /dev/disk/by-partlabel/PINE642Groot /dev/disk/by-partlabel/PINE642Gswap /dev/disk/by-partlabel/PINE642Gswp2 (Personally I do fine with one highspeed port connection on the Pine64+ 2GB --unless I forgot my powered hub that I use.) =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 Aug 20 14:00:57 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 B45EE106E938 for ; Mon, 20 Aug 2018 14:00:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-11.consmr.mail.bf2.yahoo.com (sonic304-11.consmr.mail.bf2.yahoo.com [74.6.128.34]) (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 57B368E2CE for ; Mon, 20 Aug 2018 14:00:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: urqYPiYVM1kolQrSpgtaXw8ymhauOQzyMCXtUGuDxe_O92H.RUqZdzXlGlpvfmS NwY3UAnfMjgEJOFAYUmrdxezAr53H0OVdLXv3D9L2kp.UbPDAeXmqhwPA29qHNhun_xp9m0HV0ah MIl9l4hpu_O4nmPMjCtXVae.Xn2knJUZTVCFPpg_gcKSGIbgECVQn3d5mTUxyHYSMkZqB.1ElZqw NE3FLPHqwPFQjAaMg3aj_ugajD32m6rEvBzgZmSNdpg0IjC5GvlqoTvmPgyB1hkQKt.opHvw19Q8 m7gnyuu3FzOuNY8DHN3ckV5atORSRserm7.IvLehxZr0X89BA770ipQN3yq3MnJRV0lUVX.VWMo0 fNr_fUldZBnaidy7u5yngCiilb4jwPcNCQ9X5mxFN4w.evddQTY9v4H0kqQ5wR1LwAExUrCcr9fL QC1rTd2QhXyFUMTtQXv39OIkydyzZYFXnaizvj6UAmsRtTXwr72A4_En_y0uzEGgJYkDxwwgZId8 mLUgyG9c5_TlejCT_sM7HVyY92jFPHtXKiFL8KvVGp64j3SWj5jkWxdCDxwcg93Vc9qPyB871C6i IyhQ5Vn8vTMLh3_rm5Q3F10kIl6azrK9BxF6Gl_kYbJtWgHMbuxAJs.RgnEq3_1n9ZfPXKkclxX6 IHnHRToiGtGSa8CYpIeBHvoKr7KVy_EzYy7if7WqHF6T9HyLEPweaHcR8sbuzn2VaCXzRFG7EWTe cgjOLK4uJw7uFIjdSU5CmhbqUFKvtpqUAu.DcY7OwGhjd7jl9jsBQv_EZ0_NZUVoqRBjupKrJXRO XR854EgcwPaOpKtAw.iro.hSqGwlryJAeGtIMu9zpuHoQ4zUqWvh9wgupT_uHEKk4q4_KkN6RS7t PNdX7Pk4nHl59flPihQHV6iVpIZabLNsJmyF8hjL4EPO02Fx4TTjSSr6oFj97Ihht1Ufb7frhw8q dsC4.KZJTfUzTjhmfv2Ylq879Mtiesd7M38NfHl3S4TVNpPTethZfxW5wb7PN58trhFcqmC6MLrL 1AUzNmeOaOm8X Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Mon, 20 Aug 2018 14:00:51 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp408.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 644fa8ea4d4f672076193c7f579efec3; Mon, 20 Aug 2018 14:00:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: <9EA5D75D-A03F-4B25-B65E-03E93DE30130@yahoo.com> Date: Mon, 20 Aug 2018 07:00:48 -0700 Cc: Mark Johnston , John Kennedy , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180815221728.GA59074@www.zefox.net> <9EA5D75D-A03F-4B25-B65E-03E93DE30130@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2018 14:00:57 -0000 There is a way to explore Mark Johnston's swap information reports (from his patches for such). Taking a Pine64+ 2GB as an example (4 cores with 1 HW-thread per core, 2 GiBytes of RAM, USB device for root file system and swap partition): In one login: # nice -20 gstat -pd In another login: # stress -d 2 -m 4 --vm-keep --vm-bytes 536870912 That "4" and "536870912" total to the 2 GiBytes so swapping is induced for the context in question. (Scale --vm-bytes appropriately to context.) [stress is from sysutils/stress .] gstat tends to show things such as: dT: 1.006s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| mmcsd0 56 312 0 0 0.0 312 19985 142.6 0 0 = 0.0 99.6| da0 where the ms/w and kBps are fairly stable but the Length of the queue length is widely variable. For the above it makes the likes of 56 writes queued * 142.6 ms/write (mean) [as an estimate] a rather large total time for the last of the queued writes to complete. (If I understand how to interpret the above.) It appears to me that, compared to a observed capacity of roughly around 20 MiBytes/sec for writes, large amounts of bytes are being queued up to be written in a short time, for which it just takes a while for the backlog to be finished. The following is from multiple such runs, several manually stopped but some killed because of sustained low free memory. I had left vm.pageout_oom_seq=3D12 in place for this, making the kills easier to get than the 120 figure would. It does not take very long generally for some sort of message to show up. waited 9s for async swap write waited 9s for swap buffer waited 9s for async swap write waited 9s for async swap write waited 9s for async swap write v_free_count: 1357, v_inactive_count: 1 Aug 20 06:04:27 pine64 kernel: pid 1010 (stress), uid 0, was killed: out = of swap space waited 5s for async swap write waited 5s for swap buffer waited 5s for async swap write waited 5s for async swap write waited 5s for async swap write waited 13s for async swap write waited 12s for swap buffer waited 13s for async swap write waited 12s for async swap write waited 12s for async swap write swap_pager: indefinite wait buffer: bufobj: 0, blkno: 161177, size: = 131072 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164766, size: = 65536 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164064, size: = 12288 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 161630, size: = 131072 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 161177, size: = 131072 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164766, size: = 65536 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 161630, size: = 131072 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164064, size: = 12288 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 161177, size: = 131072 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164766, size: = 65536 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 161630, size: = 131072 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164064, size: = 12288 waited 65s for async swap write waited 65s for swap buffer waited 65s for async swap write waited 65s for async swap write waited 65s for async swap write v_free_count: 955, v_inactive_count: 1 Aug 20 06:11:49 pine64 kernel: pid 1047 (stress), uid 0, was killed: out = of swap space waited 5s for async swap write waited 5s for swap buffer waited 5s for async swap write waited 5s for async swap write waited 5s for async swap write swap_pager: indefinite wait buffer: bufobj: 0, blkno: 314021, size: = 12288 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 314084, size: = 32768 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 314856, size: = 32768 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 314638, size: = 131072 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 312518, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 312416, size: = 16384 waited 39s for async swap write waited 39s for swap buffer waited 39s for async swap write waited 39s for async swap write waited 39s for async swap write swap_pager: indefinite wait buffer: bufobj: 0, blkno: 314802, size: = 24576 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 314934, size: = 40960 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 315617, size: = 32768 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 312484, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 328616, size: = 131072 waited 31s for async swap write waited 31s for swap buffer waited 31s for async swap write waited 31s for async swap write waited 31s for async swap write waited 5s for async swap write waited 5s for swap buffer waited 5s for async swap write waited 5s for async swap write waited 5s for async swap write =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 Aug 20 14:59: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 697241070BBB for ; Mon, 20 Aug 2018 14:59:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 EDFBC71069 for ; Mon, 20 Aug 2018 14:59:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x235.google.com with SMTP id 139-v6so20811386itf.0 for ; Mon, 20 Aug 2018 07:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CCZxh7KvEyiPdwpyBSRbby2e5pkrZ18AuaUvbdUQ0m8=; b=kOcLa6kCeXej53E3VlI5UlMi9lpKV9jJwl9mJVaGQXmGrLV3ZcWC1tX8sSj7JNIrjR YaQnqts5NBs1NUzTtyGzuQUlOzOEAeTpAXtFNGWqQRuBG8lkPBzIntbbBPAhvP6Cs9SK q+4DB0p0SBfqjQF6h40PBpqJLqWOcFqCyNWPEtnMjAwevk8KcYMKnrRp5G+myKPSm1Yd +cXeEMcwReh+cP2pkIfUxPUZEwddxSKiJD1tB8ZryZ83uIuZU/SxuZlEnAgeS88kYWg+ JRrTLJxYFQoK6HwN6GDaZdCwQCRQjTrhi9bgvt/DfQ0h4HWyACbOzn47ha73XEsDtP0e 1WJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CCZxh7KvEyiPdwpyBSRbby2e5pkrZ18AuaUvbdUQ0m8=; b=FColv5grG1cx7cefkR6yLCuI274s4er2ZYa6L3lfKaABkMllMDAJuGl1BNmocccZuc c1II+xcbQNF3xbQvuITGJVvYRWkJ7lpdpfXp2Km0RZqo0AEIpO1SrnYeCzz5mpJAyNmL NJ+Q9aYEhDGcV08DkqJEis14kBUKCUj8llvGa+p/s2CNkk5AvjmHDHLjWjxIOvJDG/ps weIVaO1lD81vzxmYvKnnQ7UYAoNAWj8xQP6t27diAzCruQ7qkm2qPfxmzKs4q4WEGKbB kLaoptrx9hK2Wc9m85uftxzbJRJN21PoV1U9AAd0csrO2b21pkBxu12qlCvN5g5hSrJ/ 59Xw== X-Gm-Message-State: AOUpUlHfdGbg2uSEGTKYDf5Xo3HwFWoIxqjd/r0Cni67eyYkob+Vpi2k Zv4MZK7X+EOzubmhbTx4K7RYx8uBprK2DRch/dTJSw== X-Google-Smtp-Source: AA+uWPw5JEEj5gpX4/aiOZ0sQ0DQQWHgXuRHIRQi9TWSAh+5QN61MezOopHhnXLGpZAA4MX5t4j2tMFYv5gzw5b2Xj4= X-Received: by 2002:a24:83c6:: with SMTP id d189-v6mr13320728ite.75.1534777182157; Mon, 20 Aug 2018 07:59:42 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:2806:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 07:59:41 -0700 (PDT) X-Originating-IP: [50.227.106.226] In-Reply-To: References: <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180815221728.GA59074@www.zefox.net> <9EA5D75D-A03F-4B25-B65E-03E93DE30130@yahoo.com> From: Warner Losh Date: Mon, 20 Aug 2018 08:59:41 -0600 X-Google-Sender-Auth: toV0oagydjYiolBmeuvEDRzNupo Message-ID: Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] To: Mark Millard Cc: bob prohaska , freebsd-arm , Mark Johnston 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: Mon, 20 Aug 2018 14:59:43 -0000 On Mon, Aug 20, 2018 at 8:00 AM, Mark Millard via freebsd-arm < freebsd-arm@freebsd.org> wrote: > There is a way to explore Mark Johnston's swap information > reports (from his patches for such). > > Taking a Pine64+ 2GB as an example (4 cores with 1 > HW-thread per core, 2 GiBytes of RAM, USB device for > root file system and swap partition): > > In one login: > # nice -20 gstat -pd > > In another login: > # stress -d 2 -m 4 --vm-keep --vm-bytes 536870912 > > That "4" and "536870912" total to the 2 GiBytes so > swapping is induced for the context in question. > (Scale --vm-bytes appropriately to context.) > > [stress is from sysutils/stress .] > > gstat tends to show things such as: > > dT: 1.006s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| mmcsd0 > 56 312 0 0 0.0 312 19985 142.6 0 0 > 0.0 99.6| da0 > > where the ms/w and kBps are fairly stable but the Length > of the queue length is widely variable. For the above it > makes the likes of 56 writes queued * 142.6 ms/write (mean) > [as an estimate] a rather large total time for the last > of the queued writes to complete. (If I understand how > to interpret the above.) > No. 142.6ms/write is the average of the time that the operations that completed during the polling interval took to complete. There's no estimating here. So, at 6 or 7 per second for the operation to complete, coupled with a parallel factor of 1 (typical for low end junk flash), we wind up with 56 operations in the queue taking 8-10s to complete. > It appears to me that, compared to a observed capacity of > roughly around 20 MiBytes/sec for writes, large amounts of > bytes are being queued up to be written in a short time, > for which it just takes a while for the backlog to be > finished. > Yes. That matches my expectation as well. In other devices, I've found that I needed to rate-limit things to more like 50-75% of the max value to keep variance in performance low. It's the whole reason I wrote the CAM I/O scheduler. > The following is from multiple such runs, several manually > stopped but some killed because of sustained low free > memory. I had left vm.pageout_oom_seq=12 in place for this, > making the kills easier to get than the 120 figure would. It > does not take very long generally for some sort of message to > show up. > > > > waited 9s for async swap write > waited 9s for swap buffer > waited 9s for async swap write > waited 9s for async swap write > waited 9s for async swap write > v_free_count: 1357, v_inactive_count: 1 > Aug 20 06:04:27 pine64 kernel: pid 1010 (stress), uid 0, was killed: out > of swap space > waited 5s for async swap write > waited 5s for swap buffer > waited 5s for async swap write > waited 5s for async swap write > waited 5s for async swap write > waited 13s for async swap write > waited 12s for swap buffer > waited 13s for async swap write > waited 12s for async swap write > waited 12s for async swap write > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 161177, size: 131072 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164766, size: 65536 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164064, size: 12288 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 161630, size: 131072 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 161177, size: 131072 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164766, size: 65536 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 161630, size: 131072 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164064, size: 12288 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 161177, size: 131072 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164766, size: 65536 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 161630, size: 131072 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164064, size: 12288 > waited 65s for async swap write > waited 65s for swap buffer > waited 65s for async swap write > waited 65s for async swap write > waited 65s for async swap write > v_free_count: 955, v_inactive_count: 1 > Aug 20 06:11:49 pine64 kernel: pid 1047 (stress), uid 0, was killed: out > of swap space > waited 5s for async swap write > waited 5s for swap buffer > waited 5s for async swap write > waited 5s for async swap write > waited 5s for async swap write > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 314021, size: 12288 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 314084, size: 32768 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 314856, size: 32768 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 314638, size: 131072 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 312518, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 312416, size: 16384 > waited 39s for async swap write > waited 39s for swap buffer > waited 39s for async swap write > waited 39s for async swap write > waited 39s for async swap write > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 314802, size: 24576 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 314934, size: 40960 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 315617, size: 32768 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 312484, size: 4096 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 328616, size: 131072 > waited 31s for async swap write > waited 31s for swap buffer > waited 31s for async swap write > waited 31s for async swap write > waited 31s for async swap write > waited 5s for async swap write > waited 5s for swap buffer > waited 5s for async swap write > waited 5s for async swap write > waited 5s for async swap write These numbers are consistent with the theory that the swap device becomes overwhelmed, spiking latency and causing crappy down-stream effects. You can use the I/O scheduler to limit the write rates at the low end. You might also be able to schedule a lower write queue depth at the top end as well, but I've not seen good ways to do that. Warner From owner-freebsd-arm@freebsd.org Mon Aug 20 15:11:54 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 B51521071989 for ; Mon, 20 Aug 2018 15:11:54 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3B6E471FEA for ; Mon, 20 Aug 2018 15:11:54 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id 00F691071985; Mon, 20 Aug 2018 15:11:54 +0000 (UTC) Delivered-To: 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 D354F1071984 for ; Mon, 20 Aug 2018 15:11:53 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D44171FC0 for ; Mon, 20 Aug 2018 15:11:52 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id e81094bf for ; Mon, 20 Aug 2018 17:11:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:subject:message-id:mime-version:content-type :content-transfer-encoding; s=mail; bh=UfS0/8D1K7Oy2zKkSvuH+9XpS Cc=; b=bGk0gX952nC/aaxEafLlkJTj381qIB4sO0DSEl4vzA4+smK/ms7sWiTw3 CfrssgNW2ww2MpFXgWst4uGBIfH0UXSWtkNTW5MEBnxbVugajItM9xk5DUcdp0RY lYlLufZmtKDR5bMeIs0hKRNNPZS1GgGM5kfUhNtCiSWObrWlTk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:subject:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=mail; b=hwVW9klgTmAq5pUY6+k gDA2RvS4gw6s8xrJCzkWwM5MrV2UX2kYiVxkROFyBvvVlU+3WMFQykNR0EMo2Dy2 j5CGX7Q/x/q0LbZsmjBOoaxd5GRF9VabpGnPClcrXqU7BL78+FsbA/l11xj4udfZ 7v/+OUDhAwH2MZTCWZMz7GE8= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 95f01c3e TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO for ; Mon, 20 Aug 2018 17:11:51 +0200 (CEST) Date: Mon, 20 Aug 2018 17:11:50 +0200 From: Emmanuel Vadot To: "freebsd-arm@freebsd.org" Subject: Importing DTS for arm64 Message-Id: <20180820171150.cc8e08114a1d9553da6056f9@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 20 Aug 2018 15:11:54 -0000 Hello arm@ I would like to import the DTS for arm64 in the tree and use them like we do for the arm ones. We currently rely on the bootloader/firmware to give us a DTB to work with, this works nicely until it doesn't. Here is why I want to import the DTS : - Most of the boards are using U-Boot, u-boot embed a DTB that isn't compiled with -@ (overlay ready) so we cannot use overlays. We want overlays, overlays are nice. - The DTS life is going to linux, then sometimes it's imported in U-Boot but it depend on the SoC family, U-Boot doesn't batch import every DTS like we do. So sometimes to U-Boot DTS are very old. Or when an interesting patch in commited upstream it is in Linux X+2 (roughly 4 months from now), we then have to wait for U-Boot to catch up, that give us between 4 and 6 months to have an update. - Some boards like the Marvell ones have 3 DTS, the one in the vendor U-Boot made by Marvell themselves, the one in u-boot mainline and the one in Linux. I found that the DTS in the Marvell U-Boot have some problem with FreeBSD (especially the macchiatobin that declare node with the same address but not the same size, that is not something that the rman code can handle, it could be modified, I don't know the code well enough). Also some compatible are used when they shouldn't, for example they declare the gpio being orion-gpio while this binding requires interrupts supports, which the node doesn't have. - The above situation is mostly the same with RockChip SoCs (possibly others, those are the only SoCs I work on that have this problem). Note that importing the DTS doesn't mean that every board will use them, I don't intend to copy the DTB to the GENERIC memstick image for the Overdrive 1000/3000 for example, the ones provided by the firmware works fine. RPI3 will still stay an exception as we use the DTB provided by the rpi-firmware package, so they come from the rpi foundation linux fork. I would love to do that for 12 even if we are approching code freeze, this will allow FreeBSD 12 to be more than awesome on arm64. Cheers, -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Aug 20 15:46: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 98E541072E5E for ; Mon, 20 Aug 2018 15:46:14 +0000 (UTC) (envelope-from alexandru.elisei@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2D853734F8 for ; Mon, 20 Aug 2018 15:46:14 +0000 (UTC) (envelope-from alexandru.elisei@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id E353A1072E5C; Mon, 20 Aug 2018 15:46:13 +0000 (UTC) Delivered-To: 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 A87A81072E5B for ; Mon, 20 Aug 2018 15:46:13 +0000 (UTC) (envelope-from alexandru.elisei@gmail.com) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 3C511734F7 for ; Mon, 20 Aug 2018 15:46:13 +0000 (UTC) (envelope-from alexandru.elisei@gmail.com) Received: by mail-qt0-x22d.google.com with SMTP id e19-v6so16678252qtp.8 for ; Mon, 20 Aug 2018 08:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0mljFFeTFlVekvx45rYpUiAc6CRg84EPLfMJDARzxQc=; b=sG3Alc3HoymgGVdzMywjxLu/7FRnje5BjLREgBiNO2pR9IWj8Vo6p+j/peunlFD5Si km5WX0Jc1cEVnba65nfwHhygo2Aa85jUDJeVaqCbC/iH8ikXpJg7bpMBLDVMu1RB61/7 CHtNcg3hdn6G/BHmgGC+xCGsPLiR1P/BCdACDLB0Yg9B6qbVCN+uHvpj9cdyLE6MWo0U e9M87ai6RVuQ0TFyLbgO/mO7ZW8zmDwgaWwV6h1LmrqicvXFbmFaX6rCTv4Ljop/QI/m rxS6oWyBbyZf8FvCf0F69An/g1Axq2cQgrT3PL+1eQUFX/IZzNnq7xZiu6kQGqaK1AH9 aFkQ== 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=0mljFFeTFlVekvx45rYpUiAc6CRg84EPLfMJDARzxQc=; b=D/myegMw+dNef0VfbPUXdA1R+Em8m71t51rkaPOzWD7fn4NQbURDioPF2X+j2Hg7Wx 1ANcAkjqfrNZ61w2W16u5g8NUXqOO7Cdi4yK5++FEr/n/qpeKmLY6ZSId93iBbTluqJx SumrejOrOvgyAp5n5Ir4FitFPe7ccpuEb68IHluP9HsxYKWHnkmisefKWF5GobSwLDOb VPJ+2kcvbwPWsrKAptPSYRODz93h5uffwz9WOaVkyH8AbcQUqtWsmw0LHGBmVQCSofNo qM0e4KdvCXRUu8JRlYd66zDcStRU11boMfymUSl1ZooUpc/+LM+Xwji7aGF+2I1pd7u3 +5tQ== X-Gm-Message-State: AOUpUlEtEkpj3jpqRyGLbXS+jLT/93D3puZexQ63DU20tJemg+FfMpFO dWbp0mjTmal3i1DAiUuUGqR1//J3damw2aDy6VKzgv7e X-Google-Smtp-Source: ANB0VdYfdIcqF1ziQjkn0BA/MSsOFxyBD3EN91XADJw2J2U+pZBDLV5i0yF8RPoPGQk8DejLAKPwLorzqab3hTzIow4= X-Received: by 2002:aed:3084:: with SMTP id 4-v6mr3718172qtf.424.1534779972467; Mon, 20 Aug 2018 08:46:12 -0700 (PDT) MIME-Version: 1.0 References: <20180820171150.cc8e08114a1d9553da6056f9@bidouilliste.com> In-Reply-To: <20180820171150.cc8e08114a1d9553da6056f9@bidouilliste.com> From: Alexandru Elisei Date: Mon, 20 Aug 2018 16:46:01 +0100 Message-ID: Subject: Re: Importing DTS for arm64 To: Emmanuel Vadot Cc: 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: Mon, 20 Aug 2018 15:46:14 -0000 Hello, Where do you plan to put the DTS files? In sys/dts/arm64? I am using a custom DTS for bhyve guest (in that location), I think having a standard directory for arm64 DTS files is a good idea. Regards, Alex On Mon, Aug 20, 2018 at 4:12 PM Emmanuel Vadot wrote: > > Hello arm@ > > I would like to import the DTS for arm64 in the tree and use them like > we do for the arm ones. We currently rely on the bootloader/firmware to > give us a DTB to work with, this works nicely until it doesn't. Here is > why I want to import the DTS : > > - Most of the boards are using U-Boot, u-boot embed a DTB that isn't > compiled with -@ (overlay ready) so we cannot use overlays. We want > overlays, overlays are nice. > - The DTS life is going to linux, then sometimes it's imported in > U-Boot but it depend on the SoC family, U-Boot doesn't batch import > every DTS like we do. So sometimes to U-Boot DTS are very old. Or when > an interesting patch in commited upstream it is in Linux X+2 (roughly 4 > months from now), we then have to wait for U-Boot to catch up, that > give us between 4 and 6 months to have an update. > - Some boards like the Marvell ones have 3 DTS, the one in the > vendor U-Boot made by Marvell themselves, the one in u-boot mainline > and the one in Linux. I found that the DTS in the Marvell U-Boot have > some problem with FreeBSD (especially the macchiatobin that declare > node with the same address but not the same size, that is not something > that the rman code can handle, it could be modified, I don't know the > code well enough). Also some compatible are used when they shouldn't, > for example they declare the gpio being orion-gpio while this binding > requires interrupts supports, which the node doesn't have. > - The above situation is mostly the same with RockChip SoCs (possibly > others, those are the only SoCs I work on that have this problem). > > Note that importing the DTS doesn't mean that every board will use > them, I don't intend to copy the DTB to the GENERIC memstick image for > the Overdrive 1000/3000 for example, the ones provided by the firmware > works fine. > RPI3 will still stay an exception as we use the DTB provided by the > rpi-firmware package, so they come from the rpi foundation linux fork. > > I would love to do that for 12 even if we are approching code freeze, > this will allow FreeBSD 12 to be more than awesome on arm64. > > Cheers, > > -- > Emmanuel Vadot > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Mon Aug 20 15:53:22 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 79DE81073172 for ; Mon, 20 Aug 2018 15:53:22 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0B837738DF for ; Mon, 20 Aug 2018 15:53:22 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id C48371073170; Mon, 20 Aug 2018 15:53:21 +0000 (UTC) Delivered-To: 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 A291B107316F for ; Mon, 20 Aug 2018 15:53:21 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 198EF738DE for ; Mon, 20 Aug 2018 15:53:20 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 37e631ee; Mon, 20 Aug 2018 17:53:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=05DzX2eVbv5Yvh5ITRn+yuXpRFI=; b=XDXhgJUYfzSOH5gfHV+zkSuEgjMh g9nz6eZJQyjXVqPvcwNlvfLnW611v2NRa1uaCPUDkoMANB8sJvrTgr//fHK9khyE Ue5QyKHAhPzFDZFkcgBkRWUoB2H0sUTFPFg1hIwIc09LkeKlm/CBjcYHlDKppeWU zffeMpdO8pZ7ZqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=JG1hE+1CcU80PkObwYieujtdyhYbGJfvcZ+sWP8C7OOPHZDiD2252Mr8 VNtVcn3+dyiRJvubZz3BpmKlvBDiyYAiUn+ZVZcGAPA1TnRk413a+5g2cICgfICq TrJXGAIp2RcP1jKrKqrhoQgtvA1zLYFsw9NsoWe3wm8Upse8xfo= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 03fa7f49 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 20 Aug 2018 17:53:19 +0200 (CEST) Date: Mon, 20 Aug 2018 17:53:19 +0200 From: Emmanuel Vadot To: Alexandru Elisei Cc: arm@freebsd.org Subject: Re: Importing DTS for arm64 Message-Id: <20180820175319.e3c4ebbc8b805da931d2239c@bidouilliste.com> In-Reply-To: References: <20180820171150.cc8e08114a1d9553da6056f9@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 20 Aug 2018 15:53:22 -0000 On Mon, 20 Aug 2018 16:46:01 +0100 Alexandru Elisei wrote: > Hello, > > Where do you plan to put the DTS files? In sys/dts/arm64? No sys/gnu/dts/arm64 > I am using a custom DTS for bhyve guest (in that location), I think having > a standard directory for arm64 DTS files is a good idea. I plan to make overlays in sys/dts/arm64, we could put the bhyve DTS here, or if you plan to generate one based on bhyve option having the base one in share/ would be better I think. > Regards, > Alex > > On Mon, Aug 20, 2018 at 4:12 PM Emmanuel Vadot > wrote: > > > > > Hello arm@ > > > > I would like to import the DTS for arm64 in the tree and use them like > > we do for the arm ones. We currently rely on the bootloader/firmware to > > give us a DTB to work with, this works nicely until it doesn't. Here is > > why I want to import the DTS : > > > > - Most of the boards are using U-Boot, u-boot embed a DTB that isn't > > compiled with -@ (overlay ready) so we cannot use overlays. We want > > overlays, overlays are nice. > > - The DTS life is going to linux, then sometimes it's imported in > > U-Boot but it depend on the SoC family, U-Boot doesn't batch import > > every DTS like we do. So sometimes to U-Boot DTS are very old. Or when > > an interesting patch in commited upstream it is in Linux X+2 (roughly 4 > > months from now), we then have to wait for U-Boot to catch up, that > > give us between 4 and 6 months to have an update. > > - Some boards like the Marvell ones have 3 DTS, the one in the > > vendor U-Boot made by Marvell themselves, the one in u-boot mainline > > and the one in Linux. I found that the DTS in the Marvell U-Boot have > > some problem with FreeBSD (especially the macchiatobin that declare > > node with the same address but not the same size, that is not something > > that the rman code can handle, it could be modified, I don't know the > > code well enough). Also some compatible are used when they shouldn't, > > for example they declare the gpio being orion-gpio while this binding > > requires interrupts supports, which the node doesn't have. > > - The above situation is mostly the same with RockChip SoCs (possibly > > others, those are the only SoCs I work on that have this problem). > > > > Note that importing the DTS doesn't mean that every board will use > > them, I don't intend to copy the DTB to the GENERIC memstick image for > > the Overdrive 1000/3000 for example, the ones provided by the firmware > > works fine. > > RPI3 will still stay an exception as we use the DTB provided by the > > rpi-firmware package, so they come from the rpi foundation linux fork. > > > > I would love to do that for 12 even if we are approching code freeze, > > this will allow FreeBSD 12 to be more than awesome on arm64. > > > > Cheers, > > > > -- > > Emmanuel Vadot > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Aug 20 15:57:41 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1166D10732D5 for ; Mon, 20 Aug 2018 15:57:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-20.consmr.mail.ne1.yahoo.com (sonic316-20.consmr.mail.ne1.yahoo.com [66.163.187.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC09973AE9 for ; Mon, 20 Aug 2018 15:57:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: tdRqOfYVM1lX90XDpfFOxQfzMwj6rXOesuib77ZWg_Q0vXAa0BrWMUJpKLPmVg. aKxzUlOapTTyLt_FCO7JzYSPAuMyB8DVMcpnAxBGHR17NFc2P6VMZTcBidx0nQ3llEM1.g_n5Ot1 k1yO23525_STyK3mJu0ANwtL0C1NUGCo8esHbNL7H7wmgRbHbrraHpn4lmo4NjUBn3ZK6Dj2iHfv 08wF1pxHHndYUkgs99Vk.8vYsznwuQeVmJVw5l_rL7DfQmgJAcMXvoQhl7emUSC0zrxICUtBpfrl FnF9qzt_n17yxajwADq6Ay5gR6F84cNh2DfbKRL4CyXmPx.3.wQ7ENYr_5.rf3G5nvhAYu66bGly 6RjJufMVKyzmhGT4I7hHxY3S28yDaJaPB4fbKO4BEi8NZSQvHO4w.ntnkhpnkNNl2sG7PU7Llksr VrRf1DMY.EyvqFMkztWH5xtgMYpdiIryjGlE7yFb6uyzYOhoF6sAh9GVKTyPZQxjsnusHGK4MFI9 Ss4U6rJecEKc0XEpT7GTZtLqPr.Pm.z4Lm6YAIwaU_xBZrZ322E_i7uPTogcUMcVWnhUndUvkzS_ bUJazyBfU2yNBSRhYiB2pQ97U7IjXzhLq.DBK_rKDRoVEP5CVrJEMZoSjbW5xsNilatKu4wVA2LA vdYxky6ogUEyh.z6awc3pQpjTbLQOuUAYhNLuASkdeCK6qekdM.tCKa9zuXaRQhwUg.9NdYy5XwK 6hJGQALRmOJkC39XTT3vtaggThYOb8lGXaTeu5ZwavjlMRaeidWCCUsnA.f97LUIx_6bkzvMcYzI P0XTuEXZk13MwiBMkVH3vghRY_nOnCSiSrooE3jyvFEjXk1q_cPMyDuRNSUsXaQTMJWASfM4m4jQ MbDvFJSHtQV97VMmbX2S6Y3H9JBd6vx.5rKiX4Ufe_X1C6mnGrXy9fXJ_1e2cZla3VptoD0th5LT ZVanIFj1GbX_GSymUTmcrkZGNqisyJligtrdtNlvO.ppRa0g7t.wAwcgzrmxdU.dmX9xLEs6BvZu 4x39_nf7yZoZ. Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Mon, 20 Aug 2018 15:57:32 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp409.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 6e44455c968ec062bba250d417564ee4; Mon, 20 Aug 2018 15:57:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: Date: Mon, 20 Aug 2018 08:57:26 -0700 Cc: bob prohaska , freebsd-arm , Mark Johnston Content-Transfer-Encoding: quoted-printable Message-Id: <6CF1F2FD-104E-4296-AB9C-74009C3ACA4B@yahoo.com> References: <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180815221728.GA59074@www.zefox.net> <9EA5D75D-A03F-4B25-B65E-03E93DE30130@yahoo.com> To: Warner Losh 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, 20 Aug 2018 15:57:41 -0000 On 2018-Aug-20, at 7:59 AM, Warner Losh wrote: > On Mon, Aug 20, 2018 at 8:00 AM, Mark Millard via freebsd-arm = wrote: >> . . . >> gstat tends to show things such as: >>=20 >> dT: 1.006s w: 1.000s >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name >> 0 0 0 0 0.0 0 0 0.0 0 0 = 0.0 0.0| mmcsd0 >> 56 312 0 0 0.0 312 19985 142.6 0 0 = 0.0 99.6| da0 >>=20 >> where the ms/w and kBps are fairly stable but the Length >> of the queue length is widely variable. For the above it >> makes the likes of 56 writes queued * 142.6 ms/write (mean) >> [as an estimate] a rather large total time for the last >> of the queued writes to complete. (If I understand how >> to interpret the above.) >=20 > No. 142.6ms/write is the average of the time that the operations that = completed during the polling interval took to complete. There's no = estimating here. >=20 > So, at 6 or 7 per second for the operation to complete, coupled with a = parallel factor of 1 (typical for low end junk flash), we wind up with = 56 operations in the queue taking 8-10s to complete. 56 * 142.6 ms/w =3D 7985.6 ms =3D 7.985.6 s, near the low end of your = range. I do not see how my proposed multiplication is inappropriate as an = estimate of your range. I do not know that gstat gets the 56 and the 142.6 ms/w from the exact = same time frame/context. (It might well for all I know.) So I did not want to claim too much. > . . . > These numbers are consistent with the theory that the swap device = becomes overwhelmed, spiking latency and causing crappy down-stream = effects. If over the whole test gstat -pd never shows more than, say, 200 ms/w for its about 1 second intervals, how can there be large spiking of latency to beyond, say, 1 second? I supposed that if the USB device has multiple writes active at once and some complete quickly but others do not, then such could be the case. But this would not be "parallel factor of 1 (typical for low end junk flash)". For the below, I realize that the device is in use in a USB 2.0 environment, which means 3.0 specific features would not be in use. Still, it gives some context about the device. The USB device is USB 3.0 capable that can sustain around 400 MiByte/sec sequential writes when connected to a USB 3.0 capable connection. I even over-provisioned it by leaving a free-space partition. I think the controller might be a Silicon Motion SM2258XT flash controller and Asmedia 1153e for USB. I've had the device for some time but I looked up the current "specs" for the brand/model it was sold under. I can not claim things were the same back then. The specs indicate UASP compliant, NCQ support, as well as S.M.A.R.T support. As I remember that was true back then as well. =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 Aug 20 17:13: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 95A1910760D6 for ; Mon, 20 Aug 2018 17:13:31 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3174A77C81 for ; Mon, 20 Aug 2018 17:13:31 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mailman.ysv.freebsd.org (Postfix) id EA59F10760D5; Mon, 20 Aug 2018 17:13:30 +0000 (UTC) Delivered-To: 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 C856610760D3 for ; Mon, 20 Aug 2018 17:13:30 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 6901277C80 for ; Mon, 20 Aug 2018 17:13:30 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-io0-x22a.google.com with SMTP id l8-v6so2628249ioj.11 for ; Mon, 20 Aug 2018 10:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=r3RjYi2tBD7vUA8zE3yDGSDrIl8tYLvKI6MEbpDcrxU=; b=BbMQWDiTCSbkyW6xXlxlLGN4JdFyV0WMWAfDzZPOUjJGav5pG9r0ekRwm3W8d8bGg4 dsCJ0U6vO/A1l7r5/of/NxJSBsk74Dl14GAvHS8HEYlixxTTLncbfwQIXMt1feb3mkRv IULISSTPY7Ji/mekXuyWSU6hN6C/s0VvLFbu1AzB6BQjQ5SXfiPEBBtlo3rPqVMvUIDv SCaEQIq1gIoQbVFQXszcXRzueKAzY1hyNhXrW4mKgwltuxjcs3pJW2MZVtUBPYvTOKcH UB2/NzYcz+9NTkv7OlkiddHrsUZ884qtC2an+ACTLfeD8BZTyrnPhpK0pGjdiEXG1ncQ 8NKw== 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:content-transfer-encoding; bh=r3RjYi2tBD7vUA8zE3yDGSDrIl8tYLvKI6MEbpDcrxU=; b=OM+DzZsMDZfWmK1BFcgBnLppMxRfdv7GpxrcKHq0mhugiwVSpw+5hyZJ/4XTiniBhv CraX9a40SV3olGLhPs4ENueoE3hshOIT7Rvdnz1U2YN70++gl0NlS1PNWySqnb0OEzR4 Ko/89rtXQ6lJqzEMEecc3CSwrOaDakcAuM9n65DiGfNw3jtpbVdnMKdm3+VdcTNHybbA 88TzqO95A7RDobb3sVW0tQlHhXhk4b+z+KNvm0ULSNWD5MmJpMFaF15uFSH5OGetO0iY L/dhGwEr5yb4vcDJ0aem2+fqa5SZ5VwkZ2pvlEWyRiDFHYKutEc+nvbvkicE81wxtx9i Ni9g== X-Gm-Message-State: APzg51Ahr1pNiyVsURekutqjU3oSjNZT96MKEsj05HBGgoaHLquc377o EP6/lv6MISG80lJeeoNf+lD7bY0VsGw8GoG7mTJtlZNv X-Google-Smtp-Source: ANB0VdY713aRUsU/INHGcpiutVEIziAkNh24NMc8GSykRhGpJyydr5uu0SE3p/lFJVxmphP5HHtdGNPNy5C3bYy0fTI= X-Received: by 2002:a6b:198e:: with SMTP id 136-v6mr9319539ioz.248.1534785209760; Mon, 20 Aug 2018 10:13:29 -0700 (PDT) MIME-Version: 1.0 References: <20180820171150.cc8e08114a1d9553da6056f9@bidouilliste.com> In-Reply-To: <20180820171150.cc8e08114a1d9553da6056f9@bidouilliste.com> From: Marcin Wojtas Date: Mon, 20 Aug 2018 19:13:16 +0200 Message-ID: Subject: Re: Importing DTS for arm64 To: Emmanuel Vadot Cc: arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 20 Aug 2018 17:13:31 -0000 Hi Manu, +1 to the idea. It gives more options to the users. pon., 20 sie 2018 o 17:12 Emmanuel Vadot napisa=C5= =82(a): > > > Hello arm@ > > I would like to import the DTS for arm64 in the tree and use them like > we do for the arm ones. We currently rely on the bootloader/firmware to > give us a DTB to work with, this works nicely until it doesn't. Here is > why I want to import the DTS : > > - Most of the boards are using U-Boot, u-boot embed a DTB that isn't > compiled with -@ (overlay ready) so we cannot use overlays. We want > overlays, overlays are nice. > - The DTS life is going to linux, then sometimes it's imported in > U-Boot but it depend on the SoC family, U-Boot doesn't batch import > every DTS like we do. So sometimes to U-Boot DTS are very old. Or when > an interesting patch in commited upstream it is in Linux X+2 (roughly 4 > months from now), we then have to wait for U-Boot to catch up, that > give us between 4 and 6 months to have an update. > - Some boards like the Marvell ones have 3 DTS, the one in the > vendor U-Boot made by Marvell themselves, the one in u-boot mainline > and the one in Linux. There is 4th - UEFI, but it's aligned with most recent Linux + some minimal improvements (e.g. big PCIE windows). I recommend using Macchiato with this kind of firmware instead of U-Boot. Best regards, Marcin > I found that the DTS in the Marvell U-Boot have > some problem with FreeBSD (especially the macchiatobin that declare > node with the same address but not the same size, that is not something > that the rman code can handle, it could be modified, I don't know the > code well enough). Also some compatible are used when they shouldn't, > for example they declare the gpio being orion-gpio while this binding > requires interrupts supports, which the node doesn't have. > - The above situation is mostly the same with RockChip SoCs (possibly > others, those are the only SoCs I work on that have this problem). > > Note that importing the DTS doesn't mean that every board will use > them, I don't intend to copy the DTB to the GENERIC memstick image for > the Overdrive 1000/3000 for example, the ones provided by the firmware > works fine. > RPI3 will still stay an exception as we use the DTB provided by the > rpi-firmware package, so they come from the rpi foundation linux fork. > > I would love to do that for 12 even if we are approching code freeze, > this will allow FreeBSD 12 to be more than awesome on arm64. > > Cheers, > > -- > Emmanuel Vadot > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Mon Aug 20 17:22:39 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 58CA310763E7 for ; Mon, 20 Aug 2018 17:22:39 +0000 (UTC) (envelope-from alexandru.elisei@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D336978232 for ; Mon, 20 Aug 2018 17:22:38 +0000 (UTC) (envelope-from alexandru.elisei@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 97AED10763E6; Mon, 20 Aug 2018 17:22:38 +0000 (UTC) Delivered-To: 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 75B0D10763E5 for ; Mon, 20 Aug 2018 17:22:38 +0000 (UTC) (envelope-from alexandru.elisei@gmail.com) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 13D8678231 for ; Mon, 20 Aug 2018 17:22:38 +0000 (UTC) (envelope-from alexandru.elisei@gmail.com) Received: by mail-qk0-x22b.google.com with SMTP id f17-v6so4098388qkh.4 for ; Mon, 20 Aug 2018 10:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4pptPLg6BIis2BBjok4yJsssklhWpRVhOj1hjgbajQE=; b=XTOoC8/NWKlbBX5FxyrIhWlfyPbhCOE14b+9ABYJniFyyZ9yLo+5Sn3/8EeloFoQU5 wWowg22Xe49sncx1H8qLmiqUwJlz7vzOIBaVQR5g5l05sjle8DI/adsPjs2fZCHAUeQS pPwvhzkIMks3xPuaRNOM8gwW99e2aPbuAgtWZkKeXfBufZ11jgSRT+SpkIXER2MoWZZE wjUSJBOBEm505tGDaAZbq4ZnfIDZ8NKRwm850VOLjiZYAH57k8mmr9aLz/VpB8VPD8PP RLKtuqtDsB9bTpmzcSJiHDsG/kSX/yHdrJTTmrSLUaZdMrencbIaZ7M1+d7ZEXksnsTj JQqA== 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=4pptPLg6BIis2BBjok4yJsssklhWpRVhOj1hjgbajQE=; b=LsPt4+opng59iEEPpeHzBQVgsTj4YQH4E/4rf7CRZ6o4Omnql2z1suWUFZL5w/UBx3 4fznaqWx0SYRF8b9cyLn0j1IAz1M+PpdYnQBs6ltwTZWKd6+psR1AeK2KtA4TAADHNrM RfjbaScDbQwpjiECxXdG2OM7GNrkqV/0sHYWIg3NxrU3ABZydrdiYINID4nmQFx7p7/g WLiFHsBqpJLyvich2bRO7PVdmrTuKkUJwFhwbY2VfH/LTooHmce0C7fQr+1uVYeO/URu njw9cRjrhtmUwSQc/cxkPkaBPyNOHyIBk9aHZzDcXbbLnGu8be0d/MFchdo6w1Wxv6U/ C2ww== X-Gm-Message-State: AOUpUlHHg5+0GCdAUh4fDe+UQpcIP0bb4A45GGsNPhvJ7QBPTRj/I0KF UjAao8wWeggt3YUspwgoRQXw0eOuJWkIGPmAyo5KMRom X-Google-Smtp-Source: AA+uWPwoulqcD12ITIHpenKt/TMbXYCAB40JTJeuNe/DcUsJcFAfoUKFgR24kIY5oYc+e2s2WI+iT33yRN8ChdOTY8w= X-Received: by 2002:a37:5744:: with SMTP id l65-v6mr42273406qkb.216.1534785757261; Mon, 20 Aug 2018 10:22:37 -0700 (PDT) MIME-Version: 1.0 References: <20180820171150.cc8e08114a1d9553da6056f9@bidouilliste.com> <20180820175319.e3c4ebbc8b805da931d2239c@bidouilliste.com> In-Reply-To: <20180820175319.e3c4ebbc8b805da931d2239c@bidouilliste.com> From: Alexandru Elisei Date: Mon, 20 Aug 2018 18:22:26 +0100 Message-ID: Subject: Re: Importing DTS for arm64 To: Emmanuel Vadot Cc: 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: Mon, 20 Aug 2018 17:22:39 -0000 On Mon, Aug 20, 2018 at 4:53 PM Emmanuel Vadot wrote: > > I plan to make overlays in sys/dts/arm64, we could put the bhyve DTS > here, or if you plan to generate one based on bhyve option having the > base one in share/ would be better I think. > > Sure, I don't have a preference for a particular location, I just think having a standard directory for arm64 DTS files is a good idea. From owner-freebsd-arm@freebsd.org Mon Aug 20 18:20:39 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 AA8A310780D6 for ; Mon, 20 Aug 2018 18:20:39 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 2B5347A94D for ; Mon, 20 Aug 2018 18:20:39 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: by mail-wm0-x236.google.com with SMTP id y2-v6so462899wma.1 for ; Mon, 20 Aug 2018 11:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=chbA3WUsSBUTCQ/rUuf2xm6pzp3OAzk/fzplyKOPoxk=; b=O7Nggxpe3sQQII8LfpWyUs+thEXdVdoxpeeXyLFIYJdV4zisG4klpSCqyv4BOZD4ZK ljO8xDBD2FR+mXq4SeYcohViRZcmCiFyHX+TLOuvXAZCuL2NukD00VWRpDH83wIssoJJ qJst7r9RpeAtYFkxqPhElGf7qY9tBP8oA4H034wZAoFAa7a3gMc0tGDLQ4ZKoIHoBEuM D/8oFS9k8WpqsDzTIVazaAKiejHHXvSlfY9W2DDmZ7GDWXn2+5jYK2hSklw6y4AY0+Hj lpZnfmdNvNKAqJT8+kzzsBuNTiF9xgcjbcvY42xnqCdo0p/zHnuE7kOA0PSLR8V9xKm6 rkBA== 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=chbA3WUsSBUTCQ/rUuf2xm6pzp3OAzk/fzplyKOPoxk=; b=UvIQwfHWPRxLpMUcPo9E339jZiz0hs5aIrZaZFVOM20N/wZ5DKRXOVmTXYdC+br1uo 1x9IIvcZclcP9VaIbHT5wf8DIcU+8vezMVSGMKbPdcexONp3IfssObRgB2K8docPN5cG CBElsxWndCWUay3mV3feN1HiuwMUsY44Z6irlh7sWY/EMRWi8CGXVGfDcwitfepCIdv/ enVJ0chE2qfAMge5+EvjUsyynWnz8EE32q7wrjviXRJCx7M/wUjca/YfZnYKaZATfMii 4LgMyzEiDEHwY3CmLSiQ9qUGd87LSzpJDMrs2uBghxfLwEV/QPy8n9pIGMcFkrKHAfXt yR5w== X-Gm-Message-State: AOUpUlG8btV2w5P1kr3o/Dhtf4a6M9hpU9Zjajx7J4rzysKQuMfnIbdm Jh7vbtJZUmYTZThgPpp4QN1oEAnKmGSd7s1aaqpRow== X-Google-Smtp-Source: AA+uWPz/nYvgI/zDQhekvIRnPckta0Ydn+kbq0uEs/zAtgT9Eh1Pkchmtob9XqwFBR3zaHBJ39fPyPupe0NN4afu6ec= X-Received: by 2002:a1c:1805:: with SMTP id 5-v6mr25213560wmy.25.1534789238089; Mon, 20 Aug 2018 11:20:38 -0700 (PDT) MIME-Version: 1.0 From: Rajesh Kumar Date: Mon, 20 Aug 2018 23:50:26 +0530 Message-ID: Subject: Can we use INTRNG with amd64 platforms? 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: Mon, 20 Aug 2018 18:20:39 -0000 Hi, I am writing a GPIO driver for a amd64 platform. I see an option INTRNG for GPIO interrupt handling in arm platforms. Can we use INTRNG in amd64 platform? I tried compiling freebsd with "options INTRNG" in amd64 platform, but it says "Unknown option INTRNG". So, Just wanted to clarify whether INTRNG is supported in amd64? If not, is there any equivalent available for amd64? Also, Is there any available document which explains about INTRNG features? From owner-freebsd-arm@freebsd.org Mon Aug 20 18:53:12 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 7F3B71078F83 for ; Mon, 20 Aug 2018 18:53:12 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13B0F7C2F6; Mon, 20 Aug 2018 18:53:11 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w7KIr3uG073157 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Aug 2018 11:53:03 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w7KIr3Vm073156; Mon, 20 Aug 2018 11:53:03 -0700 (PDT) (envelope-from jmg) Date: Mon, 20 Aug 2018 11:53:03 -0700 From: John-Mark Gurney To: Ian Lepore , freebsd-arm@FreeBSD.org Cc: manu@FreeBSD.org Subject: Re: sx_sleep not waking up when timo expires Message-ID: <20180820185303.GH97145@funkthat.com> Mail-Followup-To: Ian Lepore , freebsd-arm@FreeBSD.org, manu@FreeBSD.org References: <20180729010157.GC2884@funkthat.com> <1532874944.61594.110.camel@freebsd.org> <20180811020136.GD97145@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180811020136.GD97145@funkthat.com> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 20 Aug 2018 11:53:04 -0700 (PDT) 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, 20 Aug 2018 18:53:12 -0000 John-Mark Gurney wrote this message on Fri, Aug 10, 2018 at 19:01 -0700: > Also, I've had the shell command sleep hang as well.. I figure that's > expected, but made me realized that a good test program could be to > fire up a bunch of threads and sleep in them, to make finding the > problem more quickly.... > > Anything I can do to help debug/fix it? > > I have a couple spare LTS boards specifically to do stuff like this. I wrote a program to trigger the issue. It triggered the issue in only an hour or two on both the A64-LTS boards that I've tried it on. Hopefully this can help others debug it. On my firewall board, that does a lot of interrupts, it happens a lot more frequently. In the last 4 hours or so of running the program, I've had 6 threads hang in sleep. # vmstat -i interrupt total rate gic0,p11: + 664239597 676 gic0,s0: uart0 10659 0 gic0,s60: aw_mmc0 70294 0 gic0,s82: awg0 452027133 460 cpu0:ast 511 0 cpu1:ast 48 0 cpu2:ast 34 0 cpu3:ast 35 0 cpu0:preempt 15682717 16 cpu1:preempt 14384242 15 cpu2:preempt 16722306 17 cpu3:preempt 16798837 17 cpu0:rendezvous 300161 0 cpu1:rendezvous 8545 0 cpu2:rendezvous 300183 0 cpu3:rendezvous 300115 0 cpu0:hardclock 35093 0 Total 1180880510 1201 # uptime 11:50AM up 11 days, 9:03, 8 users, load averages: 0.68, 0.83, 0.93 The other box that has only two threads freeze has a total rate of 77.. ---- sleeptest.py ---- import Queue import threading import time import random def sleepfun(q, lngth, extlst, idobj): while not extlst: #factor = (random.random() + 1) * 4 factor = 1 factor = (random.random() * .5 + 1) time.sleep(lngth * factor) q.put((idobj, time.time())) def run(): sleeplength = .5 exitlist = [] nthreads = 20 q = Queue.Queue() thds = {} lastcheck = {} for i in xrange(nthreads): obj = object() thr = threading.Thread(target=sleepfun, args=(q, sleeplength, exitlist, obj)) thds[obj] = thr lastcheck[obj] = time.time() thr.start() try: while True: for i in xrange(nthreads*3): obj, tm = q.get() lastcheck[obj] = tm cur = time.time() for i in lastcheck.keys(): if not thds[i].isAlive(): print 'thread died.' del thds[i] del lastcheck[i] continue print 'last checkin:', cur - lastcheck[i] if cur - lastcheck[i] > 2 * sleeplength: print 'thread is stuck:', `obj`, 'since:', time.ctime(lastcheck[i]) except KeyboardInterrupt: print 'trying to exit...' print time.ctime(time.time()) exitlist.append(True) for i in thds: thds[i].join() if __name__ == '__main__': run() ---- sleeptest.py ---- -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@freebsd.org Tue Aug 21 08:16: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 6C7B5108D270 for ; Tue, 21 Aug 2018 08:16: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 0E2CB7877A for ; Tue, 21 Aug 2018 08:16:01 +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 5616B2E05F for ; Tue, 21 Aug 2018 08:16: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 w7L8G0dx051935 for ; Tue, 21 Aug 2018 08:16:00 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w7L8G09T051933 for freebsd-arm@FreeBSD.org; Tue, 21 Aug 2018 08:16:00 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 219436] awg Ethernet soft reset timeout on PINE64+ 2GB Date: Tue, 21 Aug 2018 08:15: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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: manu@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 08:16:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219436 Emmanuel Vadot changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Tue Aug 21 08:21:02 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 5B4BD108D3FA for ; Tue, 21 Aug 2018 08:21:02 +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 F0DEF7892E for ; Tue, 21 Aug 2018 08:21:01 +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 4B2732E088 for ; Tue, 21 Aug 2018 08:21:01 +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 w7L8L16P060616 for ; Tue, 21 Aug 2018 08:21:01 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w7L8L1Q2060608 for freebsd-arm@FreeBSD.org; Tue, 21 Aug 2018 08:21:01 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 221719] Realtek Gbit NIC bug on Pine64s Date: Tue, 21 Aug 2018 08:21:00 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: manu@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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: Tue, 21 Aug 2018 08:21:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221719 Emmanuel Vadot changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |manu@freebsd.org Resolution|--- |FIXED Status|New |Closed --- Comment #1 from Emmanuel Vadot --- Fixed with u-boot patch that was upstream by kevans@ --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Tue Aug 21 17:42:10 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 01A3F107A16B for ; Tue, 21 Aug 2018 17:42:10 +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 95DAD8E38E for ; Tue, 21 Aug 2018 17:42:09 +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 CBB19AFCB for ; Tue, 21 Aug 2018 17:42:08 +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 w7LHg86d081699 for ; Tue, 21 Aug 2018 17:42:08 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w7LHg8f0081697 for freebsd-arm@FreeBSD.org; Tue, 21 Aug 2018 17:42:08 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 230804] [loader] dtb overlays seems to corrupt the kernel env Date: Tue, 21 Aug 2018 17:42:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: manu@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 17:42:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230804 Bug ID: 230804 Summary: [loader] dtb overlays seems to corrupt the kernel env Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: manu@freebsd.org When using multiple overlays it seems that it corrupts the kenv. Using the latest pine64 image with a dtb loaded by u-boot from the FAT partition (otherwise we can't use the overlays) and some overlays I got : Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by EFI at 0x47ff9000. Loading DTB overlays: 'sun50i-a64-sid,sun50i-a64-ths,sun50i-a64-timer' /boot/dtb/overlays/sun50i-a64-sid.dtbo size=3D0x1fd /boot/dtb/overlays/sun50i-a64-ths.dtbo size=3D0x3e8 /boot/dtb/overlays/sun50i-a64-timer.dtbo size=3D0x175 applying DTB overlay '/boot/dtb/overlays/sun50i-a64-sid.dtbo' applying DTB overlay '/boot/dtb/overlays/sun50i-a64-ths.dtbo' applying DTB overlay '/boot/dtb/overlays/sun50i-a64-timer.dtbo' EHCI failed to shut down host controller. ---<>--- KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-ALPHA2 #1291 r338074+327bec90b971(aw_timer)-dirty: Tue Aug 21 18:42:59 CEST 2018 =20=20=20 manu@skull.home.blih.net:/usr/home/manu/Work/freebsd/obj/usr/home/manu/Work= /freebsd/freebsd.git/arm64.aarch64/sys/GENERIC arm64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. WARNING: malformed static env value, ignoring interrupts WARNING: malformed static env value, ignoring clocks WARNING: malformed static env value, ignoring clock-names WARNING: malformed static env value, ignoring resets WARNING: malformed static env value, ignoring reset-names WARNING: malformed static env value, ignoring #thermal-sensor-cells WARNING: malformed static env value, ignoring status WARNING: malformed static env value, ignoring nvmem-cells WARNING: malformed static env value, ignoring nvmem-cell-names WARNING: malformed static env value, ignoring phandle WARNING: malformed static env value, ignoring ths WARNING: malformed static env value, ignoring ccu WARNING: malformed static env value, ignoring ths_calib WARNING: malformed static env value, ignoring KLD file umodem.ko is missing dependencies kenv doesn't show anything and the kernel doesn't know the root filesystem, resulting in prompting to mountroot. The dtb : https://people.freebsd.org/~manu/sun50i-a64-pine64-plus.dtb The overlays :=20 https://people.freebsd.org/~manu/sun50i-a64-sid.dtbo https://people.freebsd.org/~manu/sun50i-a64-ths.dtbo https://people.freebsd.org/~manu/sun50i-a64-timer.dtbo loader.conf: # Configure USB OTG; see usb_template(4). hw.usb.template=3D3 umodem_load=3D"YES" # Multiple console (serial+efi gop) enabled. boot_multicons=3D"YES" boot_serial=3D"YES" fdt_overlays=3D"sun50i-a64-sid,sun50i-a64-ths,sun50i-a64-timer" If I remove sun50i-a64-timer kenv doesn't looks corrupts but still : Booting [/boot/kernel/kernel]... Using DTB provided by EFI at 0x47ff9000. Loading DTB overlays: 'sun50i-a64-sid,sun50i-a64-ths' /boot/dtb/overlays/sun50i-a64-sid.dtbo size=3D0x1fd /boot/dtb/overlays/sun50i-a64-ths.dtbo size=3D0x3e8 applying DTB overlay '/boot/dtb/overlays/sun50i-a64-sid.dtbo' applying DTB overlay '/boot/dtb/overlays/sun50i-a64-ths.dtbo' EHCI failed to shut down host controller. ---<>--- KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-ALPHA2 #1291 r338074+327bec90b971(aw_timer)-dirty: Tue Aug 21 18:42:59 CEST 2018 =20=20=20 manu@skull.home.blih.net:/usr/home/manu/Work/freebsd/obj/usr/home/manu/Work= /freebsd/freebsd.git/arm64.aarch64/sys/GENERIC arm64 FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. WARNING: malformed static env value, ignoring interrupts WARNING: malformed static env value, ignoring clocks WARNING: malformed static env value, ignoring clock-names WARNING: malformed static env value, ignoring resets WARNING: malformed static env value, ignoring reset-names WARNING: malformed static env value, ignoring #thermal-sensor-cells WARNING: malformed static env value, ignoring status WARNING: malformed static env value, ignoring nvmem-cells WARNING: malformed static env value, ignoring nvmem-cell-names WARNING: malformed static env value, ignoring phandle WARNING: malformed static env value, ignoring ths WARNING: malformed static env value, ignoring ccu WARNING: malformed static env value, ignoring ths_calib KLD file umodem.ko is missing dependencies --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Wed Aug 22 01:07:18 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 984B910859D0 for ; Wed, 22 Aug 2018 01:07:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (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 0885E77D80 for ; Wed, 22 Aug 2018 01:07:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: lXNL38IVM1lgQ5colpu8Pn6V2qN7ewW3F9jrWjxHdIT9ZJ8chEBwmhjmt15BMuo tITMRBzmsYdB.x2HTlfQuU919fovz4GaLdy8VVe_DB2TwDVSoC07.5hyfaZYtJk6CrDNyQI9Uxgb _Xx4QxG4trrFnmoF1PlqVoUDeyxefZgN0bL6b2rDEaPM9AXew9xVFBMWd9lEVvhl05aBFr01ksrQ 6GqzAYXVxQizmOHyseq61bNcptdgbWswsiu7NGk9qzAa2MYvZO2rwjSGmQ4Ph4g1Hh7CyOA19S3i yIa6zXLgr2gIpXZOyaKPHZ_NmPnWaTXqzLV9I_egGFchx8haKvbXM.9vzO.sy8rDCgQCmUTh5VsN D9MQxnV8Ms1jffU_4hkiNKvz38sdeRMjvRNK0Rmsda6M9gO93ZwsAEzteAlcbhkdNbzBd1j1dhHp 8oBthg4syiZ.CU6Bpbyt8LW4D9_JsKBFcv5MtqN.JDxzfMijFNmIHXc2ziksXcyHSfyuyWOEXepj 5V2Nl18NWZkYsVDF1FjoA0XpAAxW0d73EoQuuK07YnfUgClrF09aIf6zCntgYobiBs8yfQkMcTsT gmpNyMZ3xiNUUtw.S3UcV1BTl9oF9Lrc99PG841lMJ2nl56tv9l50PUa9aDnWYP3wKjsQjsTqeLG YoWrSI3wrHYlEX8my3U3vGDYSARUhd3ojkBn8fWmgSJBRH8WGZRPwAkiJma7dDFkvrVdeX0iH9tR oP61netnWa_qOtqBZCpZqAE3l_fqwYShYUEpagB_mbJg2TEhbyLzGuHNCOY8Uaz3w4ReMC8GFuCH lNzhsa.qXKxWy8XD4StT6sO58mSXGKhRnnr16WSoh2jupT6FQjIXAhNFhZ0oZW8ayW6kFUesLxuX EPEINb0e0gmFIaT_bhlU.RWgzKe9XAvi9nmuC_2jZ18CTUj18pfIMVa_nF58B06usp86dDDWao.k sTJijzNx76oLg56d0EmPMZR8Jb_55bqIE8Rtrc045I0ZVYeQ0YgROoLny.8fqoIMUxCGZqiG8.PZ 3xShRnIKw Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 22 Aug 2018 01:07:10 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp417.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 34762e4dd4a1ca2183c70ba380f0178f; Wed, 22 Aug 2018 01:07:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: RPI3 swap experiments ["was killed: out of swap space" with: "v_free_count: 5439, v_inactive_count: 1"] From: Mark Millard In-Reply-To: Date: Tue, 21 Aug 2018 18:07:06 -0700 Cc: John Kennedy , freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <73D58E0D-B6A2-45D3-B8AF-4FE7EE0962A1@yahoo.com> References: <20180808153800.GF26133@www.zefox.net> <20180808204841.GA19379@raichu> <2DC1A479-92A0-48E6-9245-3FF5CFD89DEF@yahoo.com> <20180809033735.GJ30738@phouka1.phouka.net> <20180809175802.GA32974@www.zefox.net> <20180812173248.GA81324@phouka1.phouka.net> <20180812224021.GA46372@www.zefox.net> <20180813021226.GA46750@www.zefox.net> <0D8B9A29-DD95-4FA3-8F7D-4B85A3BB54D7@yahoo.com> <20180815221728.GA59074@www.zefox.net> <9EA5D75D-A03F-4B25-B65E-03E93DE30130@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 01:07:18 -0000 Just an FYI about lld being multi-threaded . . . Mark Johnston pointed out to me something that I'd not noticed about lld: by default it is multi-threaded ( --threads ) instead of not ( --no-threads ). This apparently goes back to llvm40. (I've been more compiler focused for powerpc family in my experiments, where lld does not be work. So I'd not been monitoring lld's details.) I tried an example and it seems to create about 5 threads in the context I tested it in. With a -j4 buildworld buildkernel already keeping 4 cores busy, I've decided to experiment with /etc/make.conf like files having: LDFLAGS.lld+= -Wl,--no-threads where so few cores (hw threads) are available. I my do so more generally. (If an lld was done in isolation, this likely would be slower than with multiple threads.) Also, I'm told that the threaded operation can require more RAM. (I've no independent knowledge of such and my quick experiments did not produce any stand-out results.) It is possible that, for some contexts, --no-threads might leave a little more free RAM and/or may cut down on context-switching during some stages of buildworld or kernel-toolchain or buildkernel or building ports. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Aug 23 09:31: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 18F3C1087759 for ; Thu, 23 Aug 2018 09:31:14 +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 AC9CE8A01F for ; Thu, 23 Aug 2018 09:31:13 +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 154151FB94 for ; Thu, 23 Aug 2018 09:31:13 +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 w7N9VCQ4050502 for ; Thu, 23 Aug 2018 09:31:12 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w7N9VCxc050485 for freebsd-arm@FreeBSD.org; Thu, 23 Aug 2018 09:31:12 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 228802] [aarch64] network throughput regression in 12.0-CURRENT Date: Thu, 23 Aug 2018 09:31:12 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: bug_status see_also resolution 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: Thu, 23 Aug 2018 09:31:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D228802 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |Closed See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=3D2= 296 | |44 Resolution|--- |FIXED --- Comment #27 from Eugene Grosbein --- Closed at submitter's request. Thank you for notification. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Thu Aug 23 15:20:39 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 DB7D110903E6 for ; Thu, 23 Aug 2018 15:20:39 +0000 (UTC) (envelope-from the.lists@mgm51.com) Received: from oneyou.mgm51.net (oneyou.mgm51.net [IPv6:2607:f2f8:af30::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oneyou.mgm51.net", Issuer "RapidSSL RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8012A763F4 for ; Thu, 23 Aug 2018 15:20:39 +0000 (UTC) (envelope-from the.lists@mgm51.com) Received: from sentry.24cl.com (sentry.24cl.com [IPv6:2001:558:6017:94:c582:1d99:a986:7609]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mgm51.net (Postfix) with ESMTPS id 41x7QY3Kg8zZF2G for ; Thu, 23 Aug 2018 11:20:37 -0400 (EDT) Received: from [IPv6:fdcf:b715:2f4d:1:240a:d6e6:2dce:ed2b] (unknown [IPv6:fdcf:b715:2f4d:1:240a:d6e6:2dce:ed2b]) by sentry.24cl.com (Postfix) with ESMTP id 41x7QX2RVtzP7wP for ; Thu, 23 Aug 2018 11:20:36 -0400 (EDT) To: freebsd-arm@FreeBSD.org From: Mike Subject: 12.0 Alpha2 - RPi3 support? Message-ID: <72519fea-db8f-f60e-9ad0-3df738b29a5e@mgm51.com> Date: Thu, 23 Aug 2018 11:20:28 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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, 23 Aug 2018 15:20:40 -0000 Did I miss a memo? :) On this ISO download page: https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/12.0/ Prior to Alpha2, there was an image file for RPi3. For example: FreeBSD-12.0-ALPHA1-arm64-aarch64-RPI3-20180810-r337557.img.xz With Alpha2, all I see is a memstick file: FreeBSD-12.0-ALPHA2-arm64-aarch64-20180816-r337934-memstick.img.xz and nothing specifically for RPi3. I looked around in google but I saw nothing pointing me to a place where I can learn how to use the memstick file on my RPi3. What am I missing? Or has RPi3 support been dropped for 12.0? thx. From owner-freebsd-arm@freebsd.org Thu Aug 23 15:30: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 19F71109075A for ; Thu, 23 Aug 2018 15:30:25 +0000 (UTC) (envelope-from gjb@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 C65BB76941; Thu, 23 Aug 2018 15:30:24 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from 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 did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 9155A5D9B; Thu, 23 Aug 2018 15:30:24 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Thu, 23 Aug 2018 15:30:22 +0000 From: Glen Barber To: Mike Cc: freebsd-arm@freebsd.org Subject: Re: 12.0 Alpha2 - RPi3 support? Message-ID: <20180823153022.GB48215@FreeBSD.org> References: <72519fea-db8f-f60e-9ad0-3df738b29a5e@mgm51.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ADZbWkCsHQ7r3kzd" Content-Disposition: inline In-Reply-To: <72519fea-db8f-f60e-9ad0-3df738b29a5e@mgm51.com> User-Agent: Mutt/1.10.1 (2018-07-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: Thu, 23 Aug 2018 15:30:25 -0000 --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 23, 2018 at 11:20:28AM -0400, Mike via freebsd-arm wrote: >=20 > Did I miss a memo? :) >=20 > On this ISO download page: > https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/12.0/ >=20 >=20 > Prior to Alpha2, there was an image file for RPi3. For example: >=20 > FreeBSD-12.0-ALPHA1-arm64-aarch64-RPI3-20180810-r337557.img.xz >=20 >=20 > With Alpha2, all I see is a memstick file: >=20 > FreeBSD-12.0-ALPHA2-arm64-aarch64-20180816-r337934-memstick.img.xz >=20 >=20 > and nothing specifically for RPi3. >=20 > I looked around in google but I saw nothing pointing me to a place where > I can learn how to use the memstick file on my RPi3. >=20 > What am I missing? Or has RPi3 support been dropped for 12.0? >=20 The build failed. It was fixed after ALPHA2, and should be available for ALPHA3. Glen --ADZbWkCsHQ7r3kzd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAlt+0w4ACgkQAxRYpUeP 4pOAGA/+OVuzib1Nuctm0wY1BDpYF70hSCcTX6Lw1B1oAfNLF1oRON0IuNS2LhUS bqdyDZTTE/qtfYPJbc6iKyjcO1r6OTjUJe90Lt2esSx1tCUlKOpATZNmw8m5I0tV /VTjX7n72GvvqF57Er6DlWkKmcHAsx8PQLu4rhhq9S2y/V2O0QOqZrOVzBZJxNhS 1X/NapWamkD0e3fgQ/mg5F/SzWoC1yJXU20fd26LlMN3Fp3EafiCAfHctBheJvw8 Be6LdceOO21POoTipsv7bvma5j9sHxXvx7ktelxka2Pn+AKAsSBZ2Yx+N+ImfbBf YCt6oUf7YDiYCLa6nHcN8qGMIaLRzc5d9Zy1DJ6pwmcZzqAfH38UMe4+gZiCf1/Q KKEY1yel9tleQJDBbCEZ1fJAOp6x/zAl1l5dKGoRuc0OVSFDHKzwSU/ic0h84brH TRDgozKosUXZrL9FIrac/zkffixrZQY4Xs6SdwbvFbPZlM2Ws4r/LwL921CU4qNF NabEvBuz0EVLfNoz2K4EvT5tkUCwiROWUaWBNN9d+YCWrT9m95NdBDgc69b28JVO NH1mZrHacZLw6oR8qeram+/mof5hVJzUOwNiPFsSs1vE9lCjR5QJA3zWwo/gzkkE sL1JKCoDpg1YvIfGcoza5AMSVOKY+ipr+xViDPfdpOszc1t7/hc= =oPmA -----END PGP SIGNATURE----- --ADZbWkCsHQ7r3kzd-- From owner-freebsd-arm@freebsd.org Thu Aug 23 16:14:50 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 AB11B10919B0 for ; Thu, 23 Aug 2018 16:14:50 +0000 (UTC) (envelope-from the.lists@mgm51.com) Received: from oneyou.mgm51.net (oneyou.mgm51.net [IPv6:2607:f2f8:af30::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oneyou.mgm51.net", Issuer "RapidSSL RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48D4678505; Thu, 23 Aug 2018 16:14:50 +0000 (UTC) (envelope-from the.lists@mgm51.com) Received: from sentry.24cl.com (sentry.24cl.com [IPv6:2001:558:6017:94:c582:1d99:a986:7609]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mgm51.net (Postfix) with ESMTPS id 41x8d46wdKzZF2G; Thu, 23 Aug 2018 12:14:48 -0400 (EDT) Received: from [IPv6:fdcf:b715:2f4d:1:240a:d6e6:2dce:ed2b] (unknown [IPv6:fdcf:b715:2f4d:1:240a:d6e6:2dce:ed2b]) by sentry.24cl.com (Postfix) with ESMTP id 41x8d40D1rzP7wP; Thu, 23 Aug 2018 12:14:48 -0400 (EDT) Subject: Re: 12.0 Alpha2 - RPi3 support? To: Glen Barber Cc: freebsd-arm@freebsd.org References: <72519fea-db8f-f60e-9ad0-3df738b29a5e@mgm51.com> <20180823153022.GB48215@FreeBSD.org> From: Mike Message-ID: Date: Thu, 23 Aug 2018 12:14:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180823153022.GB48215@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit 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, 23 Aug 2018 16:14:50 -0000 On 8/23/2018 11:30 AM, Glen Barber wrote: > On Thu, Aug 23, 2018 at 11:20:28AM -0400, Mike via freebsd-arm wrote: >> >> Did I miss a memo? :) >> >> On this ISO download page: >> https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/12.0/ >> >> >> Prior to Alpha2, there was an image file for RPi3. For example: >> >> FreeBSD-12.0-ALPHA1-arm64-aarch64-RPI3-20180810-r337557.img.xz >> >> >> With Alpha2, all I see is a memstick file: >> >> FreeBSD-12.0-ALPHA2-arm64-aarch64-20180816-r337934-memstick.img.xz >> >> >> and nothing specifically for RPi3. >> >> I looked around in google but I saw nothing pointing me to a place where >> I can learn how to use the memstick file on my RPi3. >> >> What am I missing? Or has RPi3 support been dropped for 12.0? >> > > The build failed. It was fixed after ALPHA2, and should be available > for ALPHA3. OK, thanks for the quick reply. From owner-freebsd-arm@freebsd.org Thu Aug 23 19:30:24 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9996F109599A for ; Thu, 23 Aug 2018 19:30:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 2531883838 for ; Thu, 23 Aug 2018 19:30:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x231.google.com with SMTP id t69-v6so8368794itb.4 for ; Thu, 23 Aug 2018 12:30:24 -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=8gxzcaBk4EtLGwhJm6DzHOKu3/xtbMUdF2EXDVilLo4=; b=ZF44vUjEtISsKRWJLWTcrQRTlFTfc9pgKAR67XdNNStkJqmTYiPmXMMSTKN9UdWUT6 3okn5JzOv05FJpwe/Whx6qm1G4KKnveuQt+zJ84NAnIv44nPjN21IUQHcKaapCn+i4pP iVulebByMk67n6Jm1pGGfuRlKcQ6u4JFyz1tmNEPma/l01MZyNmSFpTiKiBE4pA9KaZQ qRRLXcp5XZJbeTpbm0GjXf9nUVapHaZntOUA7+qazd2/e9q9BpusHFj0XrCW+TvSeFSh wxwh0KIKOLHXeF8tUNW/zqXEyuX0nH+AdGai387C+54iKFeancwwFW894eSG3QAB2y21 yTyQ== 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=8gxzcaBk4EtLGwhJm6DzHOKu3/xtbMUdF2EXDVilLo4=; b=YJaN39WzxIwn/A9HJ5kaNlx1N53YDCRdQmxCV2NboAS+o85J9MC+TZuEgUqe+bu/ep NC4l2Jl9zb7cZnjSV2DD4IJjSdcdoeOhrYk1bTqYGETEhKpLjCTCrYGGxOZtHqv1zdIl CZQRWGvbOwk/BCarrEdaJ5mwSG7BjTgAYOlEAR/PavKHQ8hTsxtXj/8W4nomnTt5FX9Z XHZ6rtQ6q5D1V5Jzbpm44TW8cnO70BHqD/GXrGiKYqDec3vsMh6PXlUmMZ1lHT8R78iT LW7In+TnPW9TkemtWon8P2SCrgodBcJXBstC8d5H0aNVsmiX4Qot17g7fdQm6185KQcn Eb7g== X-Gm-Message-State: APzg51CabSUqbKAnphUMUnCG0cCDCK/NBg5UVBHztPECDhw+GQEG3QTl OQH9gK33h7j/f6Q/gyZv23WfJ5UIaXQqe/8iTA/+DQ== X-Google-Smtp-Source: ANB0Vdby7mhZJJWTT35dI+JNMFFj6bvb7b1QkZdGPAJVQZe94W6rZuObZ9Q1poFgzJmd6Rlxn4CPDTC7SiWrE6E2QKQ= X-Received: by 2002:a24:c902:: with SMTP id h2-v6mr2913692itg.75.1535052623487; Thu, 23 Aug 2018 12:30:23 -0700 (PDT) MIME-Version: 1.0 References: <72519fea-db8f-f60e-9ad0-3df738b29a5e@mgm51.com> <20180823153022.GB48215@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Thu, 23 Aug 2018 13:30:12 -0600 Message-ID: Subject: Re: 12.0 Alpha2 - RPi3 support? To: Mike Cc: Glen Barber , "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, 23 Aug 2018 19:30:24 -0000 On Thu, Aug 23, 2018 at 10:52 AM Mike via freebsd-arm < freebsd-arm@freebsd.org> wrote: > On 8/23/2018 11:30 AM, Glen Barber wrote: > > On Thu, Aug 23, 2018 at 11:20:28AM -0400, Mike via freebsd-arm wrote: > >> > >> Did I miss a memo? :) > >> > >> On this ISO download page: > >> > https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/12.0/ > >> > >> > >> Prior to Alpha2, there was an image file for RPi3. For example: > >> > >> FreeBSD-12.0-ALPHA1-arm64-aarch64-RPI3-20180810-r337557.img.xz > >> > >> > >> With Alpha2, all I see is a memstick file: > >> > >> FreeBSD-12.0-ALPHA2-arm64-aarch64-20180816-r337934-memstick.img.xz > >> > >> > >> and nothing specifically for RPi3. > >> > >> I looked around in google but I saw nothing pointing me to a place where > >> I can learn how to use the memstick file on my RPi3. > >> > >> What am I missing? Or has RPi3 support been dropped for 12.0? > >> > > > > The build failed. It was fixed after ALPHA2, and should be available > > for ALPHA3. > > OK, thanks for the quick reply. > Yea, it was my fault. One detail I neglected to check after I made some changes to the boot loader took out the build. I accept responsibility for it. sorry that it gave you a scare. Warner From owner-freebsd-arm@freebsd.org Fri Aug 24 00:06:22 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 48A2A109BB85; Fri, 24 Aug 2018 00:06:22 +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 966D18DE71; Fri, 24 Aug 2018 00:06:21 +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 w7O06bLd002974 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Aug 2018 17:06:38 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w7O06b7P002973; Thu, 23 Aug 2018 17:06:37 -0700 (PDT) (envelope-from fbsd) Date: Thu, 23 Aug 2018 17:06:37 -0700 From: bob prohaska To: Kirk McKusick Cc: FreeBSD Filesystems , freebsd-arm@freebsd.org, bob prohaska Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems Message-ID: <20180824000637.GA2157@www.zefox.net> References: <20180822004843.GA84687@www.zefox.net> <201808230557.w7N5vvjj038580@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201808230557.w7N5vvjj038580@chez.mckusick.com> 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: Fri, 24 Aug 2018 00:06:22 -0000 On Wed, Aug 22, 2018 at 10:57:57PM -0700, Kirk McKusick wrote: > > Date: Tue, 21 Aug 2018 17:48:43 -0700 > > From: bob prohaska > > To: Kirk McKusick > > Cc: FreeBSD Current , > > FreeBSD Filesystems , > > bob prohaska > > Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems > > X-ASK-Info: Message Queued (2018/08/21 17:55:39) > > X-ASK-Info: Confirmed by User (2018/08/21 18:47:17) > > > > > > Will the new feature be active on a Raspberry Pi 3 using flash > > on microSD and USB for file systems and swap? > > When you create the filesystem (using newfs) you need to specify > the -t option to request that it send TRIM commands to the underlying > media. If you have an existing filesystem, you can use the command > `tunefs -t enable ' to set the TRIM-request > flag. When you mount a fiesystem that has been told to send TRIM > commands, it will send an ioctl to the device asking if it supports > TRIM. If it replies that it does, then the TRIM commands will be > sent. If it does not then the kernel will print an error message > ``WARNING: : TRIM flag on fs but disk does not > support TRIM'' or ``WARNING: : TRIM flag on fs but > disk does not confirm that it supports TRIM''. If you get no message > when you mount, then the drive will accept TRIM commands. Now whether > it will do anything with them is not clear based on your quote below. > Using FreeBSD 12.0-ALPHA2 #12 r338122: Tue Aug 21 14:26:18 PDT 2018 Alas, no luck. On mount TRIM isn't supported: WARNING: /usr: TRIM flag on fs but disk does not support TRIM Using tunefs on the microSD produced a different refusal: # tunefs -t enable /dev/mmcsd0s2a tunefs: issue TRIM to the disk set tunefs: /dev/mmcsd0s2a: failed to open disk for writing I tried with the device both ro and rw, same error. I expected "not supported", rather than "failed to open". If there's a mistake please tell me. Not sure if this is true of all possible storage devices, but the Sandisk Ultra microSD and Sandisk Extreme USB appear to be non-starters. Thanks very much for your help! bob prohaska From owner-freebsd-arm@freebsd.org Fri Aug 24 00:57:07 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 2B704109CD59 for ; Fri, 24 Aug 2018 00:57:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-22.consmr.mail.ne1.yahoo.com (sonic305-22.consmr.mail.ne1.yahoo.com [66.163.185.148]) (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 AC3FF8FC74 for ; Fri, 24 Aug 2018 00:57:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: _OBaDFUVM1memAeiNljsTI7C2B1CmAXgkK.UQCwnpqiyt_BlMhYOJvS5fhozKR. vTA.UbSPR8TWjXEgpmVPYoZ6_vv46cRSuVJ2.Rgfn_Z4gZRztU0y5CfHKjbr39sxxPZdU8zQU9oz nnQf6SSlfABn0qNqir2ZwiE91FVUSihD3GZ5NQ1o2.ZuKU.0TLhPHtHiEwXrom32eyhndXEDxU1B zd29sNedXSJGcWkv0KZAdyNyiOX4jWi9mF3ELbADywuCBxbKcvovJPLy9v30ukmxclvFc2jQxQ2U D5HxKodsjT_SZK6TvdAP36hl7nt6Kv.NoQK0Uv5HDobG4g1lba_nh6zpKgXTb5PeOhe9y7tUqvtH najYozYUPx17HPbfbU5rCpotflExjaNnF6fqKxBZiqDQQNp7fJfFNIXWt9rIxeF43uDfeF3lvXJN 34UrXgsciIRwNQJvEaRXnAcYPIhyu3eRZrBtk6W0Ni0ZGAGxbsmS847oESieRzhG3gGjIokdX0Bv .qmLF_zPblMSx4T3nErJcVnZW78IPnXd4Ok0dS0z.aEEseJPnj6ykm26PeTTq5YKHGgEOj6PFSf_ 0xX4UOS1L3dJQD0PmHxg.JEIQzurlirQTQbtRYdkKDHSgkXCxfIh_Fx_P1RBKMqEDUT9RPZTAzmF mWFAZUJ5LhfAKQ4Vmv4rsCA6pGCqYCLICLyiFJhTsQvcXQCOqT7jG5I9z5oXkvRO.JlwWFrnRRUg Dz1x1IGfklbnp.WXBlOgDzyga1oG8X6GoU8m.MEdaMCOrNUvRrCQzbrV1Q4BTPv_5Z.gk4H5QXX. yH8TDZ7xdBOCHQmm5Rd91QoGKJLQsczNU5hhQgqW3cZER1wfqZ0OkkxtpHzuU5o6dNlntv8fkG_3 20ht2WRZLIoIORmk6phS9KLcAGc_gj1fp5qznhrTTObS__hynroT0MJ_Jm3qQwOgQeE6DRqYRcJe n6vsqgSivxfV1XcuyzaFelm2xFHJQwMTgLD0YX079rMefDVaeOt3Ac2ZPrNWki0ajO5Or8QKVcSU Nu_3fHy4sK1eF Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Fri, 24 Aug 2018 00:57:00 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp414.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 5a8e29ccb534af955f7706ed61837f3d; Fri, 24 Aug 2018 00:56:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems From: Mark Millard In-Reply-To: <20180824000637.GA2157@www.zefox.net> Date: Thu, 23 Aug 2018 17:56:56 -0700 Cc: Kirk McKusick , FreeBSD Filesystems , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1F534D6D-3CA3-4E28-AF24-7AABAB0EDBD3@yahoo.com> References: <20180822004843.GA84687@www.zefox.net> <201808230557.w7N5vvjj038580@chez.mckusick.com> <20180824000637.GA2157@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2018 00:57:07 -0000 On 2018-Aug-23, at 5:06 PM, bob prohaska wrote: > On Wed, Aug 22, 2018 at 10:57:57PM -0700, Kirk McKusick wrote: >>> Date: Tue, 21 Aug 2018 17:48:43 -0700 >>> From: bob prohaska >>> To: Kirk McKusick >>> Cc: FreeBSD Current , >>> FreeBSD Filesystems , >>> bob prohaska >>> Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems >>> X-ASK-Info: Message Queued (2018/08/21 17:55:39) >>> X-ASK-Info: Confirmed by User (2018/08/21 18:47:17) >>>=20 >>>=20 >>> Will the new feature be active on a Raspberry Pi 3 using flash=20 >>> on microSD and USB for file systems and swap?=20 >>=20 >> When you create the filesystem (using newfs) you need to specify >> the -t option to request that it send TRIM commands to the underlying >> media. If you have an existing filesystem, you can use the command >> `tunefs -t enable ' to set the = TRIM-request >> flag. When you mount a fiesystem that has been told to send TRIM >> commands, it will send an ioctl to the device asking if it supports >> TRIM. If it replies that it does, then the TRIM commands will be >> sent. If it does not then the kernel will print an error message >> ``WARNING: : TRIM flag on fs but disk does not >> support TRIM'' or ``WARNING: : TRIM flag on fs but >> disk does not confirm that it supports TRIM''. If you get no message >> when you mount, then the drive will accept TRIM commands. Now whether >> it will do anything with them is not clear based on your quote below. >>=20 >=20 > Using > FreeBSD 12.0-ALPHA2 #12 r338122: Tue Aug 21 14:26:18 PDT 2018 >=20 > Alas, no luck. On mount TRIM isn't supported: >=20 > WARNING: /usr: TRIM flag on fs but disk does not support TRIM >=20 > Using tunefs on the microSD produced a different refusal: > # tunefs -t enable /dev/mmcsd0s2a > tunefs: issue TRIM to the disk set > tunefs: /dev/mmcsd0s2a: failed to open disk for writing > I tried with the device both ro and rw, same error. I > expected "not supported", rather than "failed to open". > If there's a mistake please tell me. For a UFS example: # umount /mnt pine64# tunefs -tenable /dev/mmcsd0s2a tunefs: issue TRIM to the disk set # mount -o noatime /dev/mmcsd0s2a /mnt # tunefs -p /mnt tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) enabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) disabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) enabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 6408 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) PINE642GBroot Then during a svnupdate -r477847 /usr/ports : dT: 1.006s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 1265 144 1 32 3064 105 2597 2114 38 326 = 32.2 104.2| mmcsd0 Note the "d/s kBps ms/d" figures: it is actively in use. Context: This is from head -r337400 before the changes for how things work. The root file system and swap partition are on a USB SSD (on a powered hub). But: mmcsd0: 32GB MFG 07/2017 by 3 SD> at mmc0 = 50.0MHz/4bit/32768-block It is a SanDisk microsdhc card that I did the test with. > Not sure if this is true of all possible storage devices, but > the Sandisk Ultra microSD and Sandisk Extreme USB appear to be > non-starters. >=20 USB of various vintages has its own issues for the commands allowed. But microsd cards that support it should allow TRIM. (If some work worse with TRIM enabled is another matter. For the old way TRIM was handled by FreeBSD may be nearly certain that such works worse for such media.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Aug 24 06:35:04 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5CFC210812DC for ; Fri, 24 Aug 2018 06:35:04 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EE2C679B0D for ; Fri, 24 Aug 2018 06:35:03 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id AF6DB10812DB; Fri, 24 Aug 2018 06:35:03 +0000 (UTC) Delivered-To: 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 9DFC210812DA for ; Fri, 24 Aug 2018 06:35:03 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 32DBF79B0C for ; Fri, 24 Aug 2018 06:35:03 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1ft5gE-0008TF-Os for arm@freebsd.org; Fri, 24 Aug 2018 09:34:46 +0300 From: Daniel Braniss 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: allwinner/nanopi neo boot issues Message-Id: <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> Date: Fri, 24 Aug 2018 09:34:46 +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: Fri, 24 Aug 2018 06:35:04 -0000 hi, with the latest current r338243 no longer boots via ubldr, efi does but with overlays I have to manually enter the root partition. this is where it hangs via ubldr: Autoboot in 8 seconds, hit [Enter] to boot or any other key to stop =20= Loading kernel... /boot/kernel/kernel text=3D0x8a0950 data=3D0xae160+0x184520 = syms=3D[0x4+0xa6d70+0x4+0x109f17] Loading configured modules... /boot/entropy size=3D0x1000 /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x601b Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. Kernel entry at 0x42400180... Kernel args: (null) older - r337232 - boots fine, any ideas where to look?=20= From owner-freebsd-arm@freebsd.org Fri Aug 24 08:03:05 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 623591082E3E for ; Fri, 24 Aug 2018 08:03:05 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EE7DD7C32C for ; Fri, 24 Aug 2018 08:03:04 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id B272F1082E3D; Fri, 24 Aug 2018 08:03:04 +0000 (UTC) Delivered-To: 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 A11A01082E3C for ; Fri, 24 Aug 2018 08:03:04 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2BA357C32B for ; Fri, 24 Aug 2018 08:03:04 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1ft73Z-000FPU-2o for arm@freebsd.org; Fri, 24 Aug 2018 11:02:57 +0300 From: Daniel Braniss 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: Re: allwinner/nanopi neo boot issues Date: Fri, 24 Aug 2018 11:02:56 +0300 References: <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> To: "freebsd-arm@freebsd.org" In-Reply-To: <42AA3AE2-E101-4B7B-B373-BEC178321671@cs.huji.ac.il> Message-Id: 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: Fri, 24 Aug 2018 08:03:05 -0000 > On 24 Aug 2018, at 09:34, Daniel Braniss wrote: >=20 > hi, > with the latest current r338243 no longer boots via ubldr, efi does > but with overlays I have to manually enter the root partition. >=20 > this is where it hangs via ubldr: >=20 > Autoboot in 8 seconds, hit [Enter] to boot or any other key to stop = =20 >=20 > Loading kernel... > /boot/kernel/kernel text=3D0x8a0950 data=3D0xae160+0x184520 = syms=3D[0x4+0xa6d70+0x4+0x109f17] > Loading configured modules... > /boot/entropy size=3D0x1000 > /boot/dtb/sun8i-h3-nanopi-neo.dtb size=3D0x601b > Loaded DTB from file 'sun8i-h3-nanopi-neo.dtb'. > Kernel entry at 0x42400180... > Kernel args: (null) >=20 > older - r337232 - boots fine, >=20 > any ideas where to look?=20 should have done an update before writing! with the latest (and greatest) all is back to normal! so now on to test orange pi one(h3), nanopi neo 2 (h5) and nanopi neo = a64 thanks, danny > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Fri Aug 24 13:45: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 A0BD2108AAFC for ; Fri, 24 Aug 2018 13:45:16 +0000 (UTC) (envelope-from the.lists@mgm51.com) Received: from oneyou.mgm51.net (oneyou.mgm51.net [IPv6:2607:f2f8:af30::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "oneyou.mgm51.net", Issuer "RapidSSL RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3181B869D6; Fri, 24 Aug 2018 13:45:16 +0000 (UTC) (envelope-from the.lists@mgm51.com) Received: from sentry.24cl.com (sentry.24cl.com [IPv6:2001:558:6017:94:c582:1d99:a986:7609]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mgm51.net (Postfix) with ESMTPS id 41xjFv6nD6zZDxj; Fri, 24 Aug 2018 09:45:07 -0400 (EDT) Received: from [IPv6:fdcf:b715:2f4d:1:fc2f:9bf4:4f7c:de09] (unknown [IPv6:fdcf:b715:2f4d:1:fc2f:9bf4:4f7c:de09]) by sentry.24cl.com (Postfix) with ESMTP id 41xjFt6tV0zP7wP; Fri, 24 Aug 2018 09:45:06 -0400 (EDT) Subject: Re: 12.0 Alpha2 - RPi3 support? To: Warner Losh Cc: Glen Barber , "freebsd-arm@freebsd.org" References: <72519fea-db8f-f60e-9ad0-3df738b29a5e@mgm51.com> <20180823153022.GB48215@FreeBSD.org> From: Mike Message-ID: <0f33a3c9-ea7b-2e06-5424-20a0c69b23f2@mgm51.com> Date: Fri, 24 Aug 2018 09:44:56 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 24 Aug 2018 13:45:16 -0000 On 8/23/2018 3:30 PM, Warner Losh wrote: > > > On Thu, Aug 23, 2018 at 10:52 AM Mike via freebsd-arm > > wrote: > > On 8/23/2018 11:30 AM, Glen Barber wrote: > > On Thu, Aug 23, 2018 at 11:20:28AM -0400, Mike via freebsd-arm wrote: > >> > >> Did I miss a memo?  :) > >> > >> On this ISO download page: > >> > https://download.freebsd.org/ftp/snapshots/arm64/aarch64/ISO-IMAGES/12.0/ > >> > >> > >> Prior to Alpha2, there was an image file for RPi3.  For example: > >> > >> FreeBSD-12.0-ALPHA1-arm64-aarch64-RPI3-20180810-r337557.img.xz > >> > >> > >> With Alpha2, all I see is a memstick file: > >> > >> FreeBSD-12.0-ALPHA2-arm64-aarch64-20180816-r337934-memstick.img.xz > >> > >> > >> and nothing specifically for RPi3. > >> > >> I looked around in google but I saw nothing pointing me to a > place where > >> I can learn how to use the memstick file on my RPi3. > >> > >> What am I missing?  Or has RPi3 support been dropped for 12.0? > >> > > > > The build failed.  It was fixed after ALPHA2, and should be available > > for ALPHA3. > > OK, thanks for the quick reply. > > > Yea, it was my fault. One detail I neglected to check after I made some > changes to the boot loader took out the build. I accept responsibility > for it. sorry that it gave you a scare. No big deal here. So long as support continues, I'm happy. I've got other things to play with until the next image is available. Many thanks! From owner-freebsd-arm@freebsd.org Fri Aug 24 16:14: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 4C176108E20D; Fri, 24 Aug 2018 16:14:33 +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 B04FC8C981; Fri, 24 Aug 2018 16:14:32 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w7OGEiuL006433 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Aug 2018 09:14:45 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w7OGEh2s006432; Fri, 24 Aug 2018 09:14:43 -0700 (PDT) (envelope-from fbsd) Date: Fri, 24 Aug 2018 09:14:43 -0700 From: bob prohaska To: Kirk McKusick Cc: FreeBSD Filesystems , freebsd-arm@freebsd.org, bob prohaska Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems Message-ID: <20180824161443.GB2157@www.zefox.net> References: <20180824000637.GA2157@www.zefox.net> <201808240027.w7O0Rh7f062555@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201808240027.w7O0Rh7f062555@chez.mckusick.com> 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: Fri, 24 Aug 2018 16:14:33 -0000 On Thu, Aug 23, 2018 at 05:27:43PM -0700, Kirk McKusick wrote: > > Assuming that /dev/mmcsd0s2a is your /usr then when the filesystem Sorry, the mistake was mine. /dev/mmcsd0s2a was / in that attempt, which obviously can't work. Moving a bootable August 2nd snapshot microSD card to a USB adapter allowed root@www:/ # tunefs -t enable /dev/da2s2a tunefs: issue TRIM to the disk set When I remount the device with mount -o rw /dev/da2s2a /mnt the console reports WARNING: /mnt: TRIM flag on fs but disk does not support TRIM I hope that's a consequence of the intervening USB interface. I'll swap boot devices when the present buildworld completes and see if the tunefs command really worked. If it did, then it'll make sense to update and rebuild to a TRIM-enabled revision. That'll take a couple of days, even if I don't make any mistakes.. Sandisk has yet to clarify whether TRIM is supported on microSD. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Fri Aug 24 16:26:06 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E35B2108E5A6 for ; Fri, 24 Aug 2018 16:26:05 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 6A2388CF93 for ; Fri, 24 Aug 2018 16:26:05 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 61f7920b-a7ba-11e8-aff6-0b9b8210da61 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 61f7920b-a7ba-11e8-aff6-0b9b8210da61; Fri, 24 Aug 2018 16:26:00 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w7OGPwMW000923; Fri, 24 Aug 2018 10:25:58 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1535127958.1488.31.camel@freebsd.org> Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems From: Ian Lepore To: bob prohaska , Kirk McKusick Cc: FreeBSD Filesystems , freebsd-arm@freebsd.org Date: Fri, 24 Aug 2018 10:25:58 -0600 In-Reply-To: <20180824161443.GB2157@www.zefox.net> References: <20180824000637.GA2157@www.zefox.net> <201808240027.w7O0Rh7f062555@chez.mckusick.com> <20180824161443.GB2157@www.zefox.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 24 Aug 2018 16:26:06 -0000 On Fri, 2018-08-24 at 09:14 -0700, bob prohaska wrote: > On Thu, Aug 23, 2018 at 05:27:43PM -0700, Kirk McKusick wrote: > > > > > > Assuming that /dev/mmcsd0s2a is your /usr then when the filesystem > Sorry, the mistake was mine. /dev/mmcsd0s2a was / in that attempt, > which obviously can't work. > > Moving a bootable August 2nd snapshot microSD card to a USB adapter > allowed > root@www:/ # tunefs -t enable /dev/da2s2a > tunefs: issue TRIM to the disk set > > When I remount the device with >  mount -o rw /dev/da2s2a /mnt > the console reports >  WARNING: /mnt: TRIM flag on fs but disk does not support TRIM > I hope that's a consequence of the intervening USB interface. > > I'll swap boot devices when the present buildworld completes and > see if the tunefs command really worked. If it did, then it'll > make sense to update and rebuild to a TRIM-enabled revision.  > > That'll take a couple of days, even if I don't make any mistakes.. > > Sandisk has yet to clarify whether TRIM is supported on microSD. > > Thanks for reading, A usb sdcard reader/writer will definitely mask the trim capability of an sdcard. Aside from that, ALL sdcards support trim on freebsd, regardless of what any support folks at sandisk might tell you. The trim operation is supported in the mmcsd driver by issuing sd erase commands (CMD32/33/38 sequence) which has been in the sd spec from the beginning. That said, it's my experience that different cards implement CMD38 different ways. Some cards treat it like a TRIM -- it's a hint that tells the card "the data in these sectors need not be preserved during future updates to the erase block they're embedded in", and thus they happen very fast and improve efficiency. Other cards treat it as a more synchronous operation, physically erasing the blocks involved while- you-wait, which can be *horrible* for performance on ufs (although potentially it might get better with the consolidation of BIO_DELETEs). -- Ian From owner-freebsd-arm@freebsd.org Sat Aug 25 08:34:26 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 241F51082560 for ; Sat, 25 Aug 2018 08:34:26 +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 BA4318EF91 for ; Sat, 25 Aug 2018 08:34:25 +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 1430F18FE6 for ; Sat, 25 Aug 2018 08:34:25 +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 w7P8YOjs085489 for ; Sat, 25 Aug 2018 08:34:24 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w7P8YOin085488 for freebsd-arm@FreeBSD.org; Sat, 25 Aug 2018 08:34:24 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 230886] 12-ALPHA3 r338309: nooptions INET6 causes kernel build error in al_eth.c Date: Sat, 25 Aug 2018 08:34:24 +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 Many People X-Bugzilla-Who: ohartmann@walstatt.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 25 Aug 2018 08:34:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230886 Bug ID: 230886 Summary: 12-ALPHA3 r338309: nooptions INET6 causes kernel build error in al_eth.c Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: ohartmann@walstatt.org I'm trying to build a kernel for PINE64 (aarch64) and I run into this error while building a customised kernel: [...] al_eth.c:1262:14: error: invalid application of 'sizeof' to an incomplete type 'struct ip6_hdr' ip_hlen =3D sizeof(struct ip6_hdr) when "nooptions INET6" is given in the kernel config file. Leaving "options INET6" as it is from GENERIC or disabling al_eth via nodevice al_eth in the kernel config solves the problem. Build system is FreeBSD 12.0-ALPHA3 #455 r338309: Sat Aug 25 07:10:45 CEST = 2018 amd64, sources are at r338309. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Aug 25 10:04: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 86DC510850C5 for ; Sat, 25 Aug 2018 10:04:31 +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 27FCF91E00 for ; Sat, 25 Aug 2018 10:04:31 +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 75E4619C86 for ; Sat, 25 Aug 2018 10:04:30 +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 w7PA4USP056612 for ; Sat, 25 Aug 2018 10:04:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w7PA4UMQ056611 for freebsd-arm@FreeBSD.org; Sat, 25 Aug 2018 10:04:30 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 230887] Connection to strongswan 5.6.3 produce Fatal data abort Date: Sat, 25 Aug 2018 10:04:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hlh@restart.be X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 25 Aug 2018 10:04:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230887 Bug ID: 230887 Summary: Connection to strongswan 5.6.3 produce Fatal data abort Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: hlh@restart.be Running FreeBSD norquay.restart.bel 12.0-ALPHA3 FreeBSD 12.0-ALPHA3 #0 r338= 288 on pine64+ 2GB. When I establish a VPN from my phone to strongswan 5.6.3 the system encount= er Fatal data abort: x0: 0 x1: 1c x2: ffff0000406e6000 x3: c0000006 x4: 3f x5: 801 x6: ffff000058961e10 x7: ffff000058961e0c x8: 0 x9: ffff000000ac6000 x10: 1 x11: deadbeef x12: f7 x13: 369 x14: 0 x15: 1 x16: ffff0000605552c0 x17: ffff0000003a2c9c x18: ffff0000589626f0 x19: fffffd00684b5a00 x20: 0 x21: 0 x22: 0 x23: 0 x24: 0 x25: ffff0000008b5000 x26: fffffd0009e3702c x27: fffffd0042ac2200 x28: ffff0000008b5000 x29: 0 sp: ffff0000589626f0 lr: ffff0000003e660c elr: ffff0000003e5f98 spsr: 60000005 far: ffffffffffffffa8 Fatal data abort: x0: 0 x1: 1c x2: ffff0000406e6000 x3: c0000006 x4: 3f x5: 801 x6: ffff000058961e10 x7: ffff000058961e0c x8: 0 x9: ffff000000ac6000 x10: 1 x11: deadbeef x12: f7 x13: 369 x14: 0 x15: 1 x16: ffff0000605552c0 x17: ffff0000003a2c9c x18: ffff0000589626f0 x19: fffffd00684b5a00 x20: 0 x21: 0 x22: 0 x23: 0 x24: 0 x25: ffff0000008b5000 x26: fffffd0009e3702c x27: fffffd0042ac2200 x28: ffff0000008b5000 x29: 0 sp: ffff0000589626f0 lr: ffff0000003e660c elr: ffff0000003e5f98 spsr: 60000005 far: ffffffffffffffa8 esr: 96000004 [ thread pid 12 tid 100019 ] Stopped at ip_forward+0x7c: ldr x8, [x29, #-88] db> bt Tracing pid 12 tid 100019 td 0xfffffd000019d000 db_trace_self() at db_stack_trace+0xf0 pc =3D 0xffff0000005e776c lr =3D 0xffff00000008b9b4 sp =3D 0xffff000058962000 fp =3D 0xffff000058962030 db_stack_trace() at db_command+0x220 pc =3D 0xffff00000008b9b4 lr =3D 0xffff00000008b638 sp =3D 0xffff000058962040 fp =3D 0xffff000058962120 db_command() at db_command_loop+0x60 pc =3D 0xffff00000008b638 lr =3D 0xffff00000008b3fc sp =3D 0xffff000058962130 fp =3D 0xffff000058962150 db_command_loop() at db_trap+0xf4 pc =3D 0xffff00000008b3fc lr =3D 0xffff00000008e5cc sp =3D 0xffff000058962160 fp =3D 0xffff000058962380 db_trap() at kdb_trap+0x1c8 pc =3D 0xffff00000008e5cc lr =3D 0xffff0000002fb38c sp =3D 0xffff000058962390 fp =3D 0xffff000058962440 --More--=20=20=20=20=20=20=20=20 kdb_trap() at data_abort+0x1c0 pc =3D 0xffff0000002fb38c lr =3D 0xffff0000005fff7c sp =3D 0xffff000058962450 fp =3D 0xffff000058962500 data_abort() at do_el1h_sync+0x11c pc =3D 0xffff0000005fff7c lr =3D 0xffff0000005ffcb8 sp =3D 0xffff000058962510 fp =3D 0xffff000058962540 do_el1h_sync() at handle_el1h_sync+0x74 pc =3D 0xffff0000005ffcb8 lr =3D 0xffff0000005e9874 sp =3D 0xffff000058962550 fp =3D 0xffff000058962660 handle_el1h_sync() at ip_forward+0x6ec pc =3D 0xffff0000005e9874 lr =3D 0xffff0000003e6608 sp =3D 0xffff000058962670 fp =3D 0x0000000000000000 db> The same configuration under 12.0-CURRENT r333055 run smoothly. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Aug 25 15:15:50 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 C4717108D543 for ; Sat, 25 Aug 2018 15:15:50 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 3B9E474621 for ; Sat, 25 Aug 2018 15:15:50 +0000 (UTC) (envelope-from nmingotti@gmail.com) Received: by mail-wr1-x434.google.com with SMTP id o37-v6so9818683wrf.6 for ; Sat, 25 Aug 2018 08:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:from:subject:message-id:date:user-agent:mime-version :content-language; bh=Mu+GYpAwtOmUii14N4O4s4EZnscEPAgXBGwWkqwtc2w=; b=S5eDvYSyZ7ZF4UEzB5unb3hsDeXh+oG1lOLBlr5ZYAMG56taLqm0xsDCFKMgQEDAWe pUxzpDxLrLjuBUWF9to2bxRi27DT3mxTJFrDZUjf9lxuEHxmJsRIpfIqys/7J00NZOIJ TjsU5qgGFbujR2OJEPGhhZllkxv58MUd5Bc6TprFNCoQSCYU/3MaCNLG8c953hrkOx79 Q0vqECZ/Zyy2MITsy58TCSEZhnEsINT/EsexQLCPT/+7fd8Ji1uKduExHfpZ8mm3eIoI uQNqSWD349VPANWmI9QfEf4bwlLpWYv8YlRfrieaF0YJOK7px0OViAUQc/sHhq0SnCiT SkKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:subject:message-id:date:user-agent :mime-version:content-language; bh=Mu+GYpAwtOmUii14N4O4s4EZnscEPAgXBGwWkqwtc2w=; b=sp/YH0FLKnOtRZgc3GWZdddlaY6XAYit1BoWpQH22l82/9RCKXUbUJDywxQDApBTsi HZzfO6Hjyqintv2P5zsE587mKi6kHHTSIhJIBSaCeUTV8BBaA70qtikyhPWmlHNHCVV1 k8K6anUGzP5a3M2vsOX3dwUo9JpDqCGCF/XIOtAise51SHOM7kGDkIJY+pm/PwkAZ2X8 NR1Gh3I9f7Tjyq+Je2oEKtB54qopyOdimTM1c3YkYdBTCqHHTiPCHlQb5jyYAiQCVAHC 584vURQBRV1IjecjaPNtgocU1qNfDGdHdEUQpW1SIdyvDuoKw6fTo1LhVDSaZqcKJlcA 4niw== X-Gm-Message-State: APzg51BmsoDBHNewVfO1wf8Mz++EARrjpFvLOcyl1fziIdmIFYEDvBUU zC83E+gXnb/10gyothrnbM0JPdbJ X-Google-Smtp-Source: ANB0Vda23rvidtcZZrplFCn06c4aiaFRP591rQ+W9zaGxQyBmwmiDef67jBeXKYtQHGvP0v/AfeB0Q== X-Received: by 2002:adf:f4ce:: with SMTP id h14-v6mr4300544wrp.259.1535210149145; Sat, 25 Aug 2018 08:15:49 -0700 (PDT) Received: from [172.16.0.150] (net-188-219-105-237.cust.vodafonedsl.it. [188.219.105.237]) by smtp.gmail.com with ESMTPSA id i4-v6sm8725431wrs.85.2018.08.25.08.15.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Aug 2018 08:15:48 -0700 (PDT) To: "freebsd-arm@freebsd.org" From: Nicola Mingotti Subject: FBS-12.0-APLHA, messages running portsnap Message-ID: Date: Sat, 25 Aug 2018 17:15:46 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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, 25 Aug 2018 15:15:51 -0000 Hi, I am doing some tests with: FreeBSD-12.0-ALPHA1-arm-armv7-BEAGLEBONE-20180810-r337557.img Lunching : #> portsnap fetch I get these messages on the serial console, I can not understand what they mean, can I ignore them or are they important ? ---------------------  1st 0xc33c0af0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3916  2nd 0xd365e000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:289 stack backtrace: lock order reversal:  1st 0xd406e034 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2572  2nd 0xc33c0af0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:282  3rd 0xd40ce84c ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2572 stack backtrace: -------------------- bye Nicola -- -------------------------- Dr. Nicola Mingotti R&D - Borghi Srl CTO - BondInsider -------------------------- From owner-freebsd-arm@freebsd.org Sat Aug 25 15:31:46 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 8DA69108DD9A for ; Sat, 25 Aug 2018 15:31:46 +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 1F89375429 for ; Sat, 25 Aug 2018 15:31:46 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: f87e433a-a87b-11e8-93fa-f3ebd9db2b94 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 f87e433a-a87b-11e8-93fa-f3ebd9db2b94; Sat, 25 Aug 2018 15:31:44 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w7PFVhua003318; Sat, 25 Aug 2018 09:31:43 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1535211103.1488.47.camel@freebsd.org> Subject: Re: FBS-12.0-APLHA, messages running portsnap From: Ian Lepore To: Nicola Mingotti , "freebsd-arm@freebsd.org" Date: Sat, 25 Aug 2018 09:31:43 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.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, 25 Aug 2018 15:31:46 -0000 On Sat, 2018-08-25 at 17:15 +0200, Nicola Mingotti wrote: > Hi, > > I am doing some tests with:  > FreeBSD-12.0-ALPHA1-arm-armv7-BEAGLEBONE-20180810-r337557.img > > Lunching : > #> portsnap fetch > > I get these messages on the serial console, I can not understand what  > they mean, > can I ignore them or are they important ? > --------------------- >   1st 0xc33c0af0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3916 >   2nd 0xd365e000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:289 > stack backtrace: > lock order reversal: >   1st 0xd406e034 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2572 >   2nd 0xc33c0af0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:282 >   3rd 0xd40ce84c ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2572 > stack backtrace: > -------------------- > > bye > Nicola > > > These are lock order reversal (LOR) warnings. While a LOR is a potential deadlock, these particular instances are well-known and don't cause any problems, so you can ignore them. Unfortunately, the mechanisms that detect and reports these situations make it hard to turn off the few specific places where the situation is known to be harmless. -- Ian