From owner-freebsd-arm@freebsd.org Sun Mar 29 00:14:50 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A725B26B9C2 for ; Sun, 29 Mar 2020 00:14:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48qbgV1pdzz46x6 for ; Sun, 29 Mar 2020 00:14:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: gya3D4AVM1lcQ_aLWdz3os..IrkvqxB90uHJu8VrvpmhgQiHaCT.L5Fpi8j1nq6 pwtmDA9X1Hli8w_kI3XM6pDRY_Oyvc1TfyzRjL2tmFcEFR2cT8XShzgDgGIyHqS9Dic1MAJNw8Tl qkLZJc4eqHJ5uyua20QTy468ui1cdT2kvyYlw9Q3HEo.xA2ozhOTLV_CBTpGetOG.BEKe0xgfHst r0DREb6L_TUcnrmx4UTH2NK6QRmmPR4.J5jCqqNpemtcgH557zVQGhTiup9I..3u607dMEyKX7QN Uqvovd2ngLhEahV_EtkOc_EfT5_cFvmaBpPBoy0tVQamlFY7OaCHZXzWUReQVVgXT4CtCYVafhs2 ya8tIvC0rprxEiA.r_UVMsjhYk25DphVoIFSKxW8uZgqhp5gnfDFEPrsEwbwakb_6WEdOP10OLU. qKFTyrC3EsUXRN5ND9dRPl3WcrUP5VNgHqLEVz_sLi3hDar.BVq1PyOx9mqqee5nieNN5aGijy1W EgQbRQvTpSJDjc5my2_1E2lblk7HSGmCFUJxzcPpsO5ILSmdRiAUrMo5G9OnJwzO4X03pWAXCjr0 3DUcws3sqUhJedEPAQ8LxK0uJe4xDini3HvJ6G4rPBLTmFCznCXNUDVJx4aax2Sgrk58hfosLNLo Y5c_QgBb8TphE8kd4lz1E68mf0INIMoyfWE28wRUj37d5WIwVB_zI3bsRssK33dzm9F.9eRA_OO0 9JnxYh_KjudzaKrQx1pbhh0XaJ9SM2Ap0FG7abKylQrjyu6On_eYXzVTLyjdqo0u.GKfp.5knQ2E bS8uF25akZuujfBVJxU_GcdJZQl2Vk6YtKhivWjksCQdnhFzP_mOsrpDc8F1_QSaLUn7jO.IAF3a LGxTyrFbVpLZK4_gC9vNV3.gKv.okwqUeu_oK191.OmaUSUa0ykG8sgJl98wzwCJxh0BuBbJBjs7 1StX7tkC.O5i6dSZyOxFTuif4Ile6a.UmNmmqkZMoK5k_XsuCTOZxGPtsIJFqFaBUavFbCzLcJ68 k.AhUED3GxB7f7ddJjvepOGNDSvd9IyH94oGr0g4QqkHatP43FtaA8VOr8dadRZ.lniJ37blzGqk JwYXVp.dEzbNvNtfzzxGZfQsb5ArkWER.SW784HWmlP.UaSnIOtrpru9hZw05ExGMz9zz0UeH2JB mGTdghz.4a0yhtiwWu36g5tjWG9wHzD9zpG3uZ3v7Bu6wPodXolttctO0qHtu85i8T2As3qvhoC5 ceN1sxInDuJC1W9jI._1pJ0YsQbFHfjRTBUiJYp_Q5UePBtOu6uThD.g8numl4DPAC78zf0tJB3N SmJ5IY1vetDNjB78hJp5VzOjXnVE8diqMUknp0Q7y5ZsVwT6DYPgcb8sPufuaoaUusqLTIq.wZrQ oe0tl_I6p_ghwmxGaZvG13K9L89K2P26gSTT7oS8P Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 29 Mar 2020 00:14:19 +0000 Received: by smtp421.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 6d90e486c255acb531f125b0ff2e63e5; Sun, 29 Mar 2020 00:14:17 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: FYI: head -r358966 -> -r359736 and RPi4: -r359736 fails to boot (unless I use boot -v) where -r358966 booted fine before update Message-Id: Date: Sat, 28 Mar 2020 17:14:16 -0700 To: freebsd-arm X-Mailer: Apple Mail (2.3608.80.23.2.2) References: X-Rspamd-Queue-Id: 48qbgV1pdzz46x6 X-Spamd-Bar: + X-Spamd-Result: default: False [1.17 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; HFILTER_HELO_IP_A(1.00)[sonic317-21.consmr.mail.gq1.yahoo.com]; MV_CASE(0.50)[]; MAILSPIKE_FAIL(0.00)[147.66.137.98.rep.mailspike.net:query timed out]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.04)[-0.039,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (5.12), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.65), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ZRD_FAIL(0.00)[query timed out]; NEURAL_SPAM_LONG(0.71)[0.705,0]; RCVD_IN_DNSWL_NONE(0.00)[147.66.137.98.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 00:14:50 -0000 I use a microsd card that is set up for booting both a Rock64 and a RPi4: the dd'd u-boot vs. the RPi4 specific materials are in independent places and the rest is shared and rather generic. So at head -r358966 I'd been able to both the Rock64 and the RPi4 from the same media. Now with head -r359736 in place instead: A) The Rock64 boots via that media just fine. B) The RPi4 fails to boot (nothing special like "boot -v"). C) The RPi4 with "boot -v" boots just fine. (This makes identifying the issue non-obvious.) For (B, i.e., no boot -v): . . . Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 . . . Release APs...done CPU 0: ARM Cortex-A72 r0p3 affinity: 0 Trying to mount root from ufs:/dev/label/RPi4root [rw,noatime]... =20 . . . (looks normal until after the CPU 3 line) . . . CPU 1: ARM Cortex-A72 r0p3 affinity: 1 CPU 2: ARM Cortex-A72 r0p3 affinity: 2 CPU 3: ARM Cortex-A72 r0p3 affinity: 3 sdhci_bcm0-slot0: Controller timeout sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_bcm0-slot0: Sys addr: 0x000006c8 | Version: 0x00001002 sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000001 sdhci_bcm0-slot0: Argument: 0x0ee2afc1 | Trn mode: 0x00000036 sdhci_bcm0-slot0: Present: 0x1fff0a06 | Host ctl: 0x00000007 sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000080 sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 sdhci_bcm0-slot0: Timeout: 0x00000003 | Int stat: 0x00000000 sdhci_bcm0-slot0: Int enab: 0x01ff003b | Sig enab: 0x01ff003b sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_bcm0-slot0: Caps: 0x45ee6432 | Caps2: 0x0000a525 sdhci_bcm0-slot0: Max curr: 0x00080008 | ADMA err: 0x00000000 sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout Root mount waiting for: CAM Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying for = 10 more seconds Mounting from ufs:/dev/label/RPi4root failed with error 2. Loader variables: vfs.root.mountfrom=3Dufs:/dev/label/RPi4root vfs.root.mountfrom.options=3Drw,noatime Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:zroot/ROOT/default cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> ? List of GEOM managed disk devices: mmcsd0 mountroot>=20 So far the above has been 100% repeating. For (C, i.e., boot -v in use): . . . Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds...=20 Type '?' for a list of commands, 'help' for more detailed help. OK boot -v . . . . . . Release APs...done CPU 0: ARM Cortex-A72 r0p3 affinity: 0 Trying to mount root from ufs:/dev/label/RPi4root [rw,noatime]... . . . CPU 1: ARM Cortex-A72 r0p3 affinity: 1 CPU 2: ARM Cortex-A72 r0p3 affinity: 2 CPU 3: ARM Cortex-A72 r0p3 affinity: 3 Root mount waiting for:regulator: shutting down unused regulators CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Warning: no time-of-day clock registered, system time will not be set = accurately start_init: trying /sbin/init Setting hostuuid: REPLACED. Setting hostid: REPLACED. Starting file system checks: /dev/label/RPi4root: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/label/RPi4root: clean, 19057570 free (498234 frags, 2319917 blocks, = 1.8% fragmentation) . . . =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 Mar 29 01:20:40 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4D0B326D2C2 for ; Sun, 29 Mar 2020 01:20:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-48.consmr.mail.gq1.yahoo.com (sonic313-48.consmr.mail.gq1.yahoo.com [98.137.65.111]) (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 48qd7h6M2Nz4VyQ for ; Sun, 29 Mar 2020 01:20:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: N_6BpMEVRDvd.miR6A7lED5GPdAEx7ojsA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sun, 29 Mar 2020 01:20:22 +0000 Received: by smtp417.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 3f90b1cd2a0dad96ef670e9fcf55ec8e; Sun, 29 Mar 2020 01:18:21 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: FYI: head -r358966 -> -r359736 and RPi4: -r359736 fails to boot (unless I use boot -v) where -r358966 booted fine before update Date: Sat, 28 Mar 2020 18:18:19 -0700 References: To: freebsd-arm In-Reply-To: Message-Id: <147DDCEF-C081-4237-A81E-AEBCD71AB016@yahoo.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 48qd7h6M2Nz4VyQ X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.48 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.988,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.992,0]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE_FREEMAIL(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[111.65.137.98.list.dnswl.org : 127.0.5.0]; MV_CASE(0.50)[]; IP_SCORE(0.00)[ipnet: 98.137.64.0/21(0.82), asn: 36647(0.65), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 01:20:41 -0000 On 2020-Mar-28, at 17:14, Mark Millard wrote: > I use a microsd card that is set up for booting both > a Rock64 and a RPi4: the dd'd u-boot vs. the RPi4 > specific materials are in independent places and > the rest is shared and rather generic. >=20 > So at head -r358966 I'd been able to both the > Rock64 and the RPi4 from the same media. >=20 > Now with head -r359736 in place instead: >=20 > A) The Rock64 boots via that media just fine. >=20 > B) The RPi4 fails to boot (nothing special > like "boot -v"). >=20 > C) The RPi4 with "boot -v" boots just fine. > (This makes identifying the issue non-obvious.) >=20 Booting the old kernel seems to consistently work (unload, load, boot sequence). boot -v of the new kernel can fail. Plain boot of the new kernel can on occasion boot. This makes for more comparable output difference checking . . . Dealing with pain boot 1st (then I'll show the boot -v comparison), I show just differences in the captured output . . . EFI boot manager: Cannot load any image 679248 bytes read in 91 ms (7.1 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC vs. EFI boot manager: Cannot load any image 679248 bytes read in 90 ms (7.2 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting [/boot/kernel/kernel]... =20 vs. Booting [/boot/kernel/kernel] in 9 seconds...=20 Type '?' for a list of commands, 'help' for more detailed help. OK boot Extra lines on "it boots" case, after the first 2 "REGSITER DUMP"s, starting inside the 3rd sdhci_bcm1-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 sdhci_bcm1-slot0: Present: 0x000f0000 | Host ctl: 0x00000001 sdhci_bcm1-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_bcm1-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_bcm1-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_bcm1-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00bb sdhci_bcm1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_bcm1-slot0: Caps: 0x00000000 | Caps2: 0x00000000 sdhci_bcm1-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_bcm1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_bcm1-slot0: Got command interrupt 0x00030000, but there is no = active command. sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_bcm1-slot0: Sys addr: 0x00000000 | Version: 0x00009902 sdhci_bcm1-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_bcm1-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 sdhci_bcm1-slot0: Present: 0x000f0000 | Host ctl: 0x00000001 sdhci_bcm1-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_bcm1-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_bcm1-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_bcm1-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00bb sdhci_bcm1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_bcm1-slot0: Caps: 0x00000000 | Caps2: 0x00000000 sdhci_bcm1-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_bcm1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_bcm1-slot0: Got command interrupt 0x00030000, but there is no = active command. sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_bcm1-slot0: Sys addr: 0x00000000 | Version: 0x00009902 sdhci_bcm1-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 Extra lines on the "it fails to boot" side: sdhci_bcm0-slot0: Controller timeout sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_bcm0-slot0: Sys addr: 0x000006c8 | Version: 0x00001002 sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000001 sdhci_bcm0-slot0: Argument: 0x0ee2afc1 | Trn mode: 0x00000036 sdhci_bcm0-slot0: Present: 0x1fff0a06 | Host ctl: 0x00000007 sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000080 sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 sdhci_bcm0-slot0: Timeout: 0x00000003 | Int stat: 0x00000000 sdhci_bcm0-slot0: Int enab: 0x01ff003b | Sig enab: 0x01ff003b sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_bcm0-slot0: Caps: 0x45ee6432 | Caps2: 0x0000a525 sdhci_bcm0-slot0: Max curr: 0x00080008 | ADMA err: 0x00000000 sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout After one "Root mount waiting for: CAM" that both have, the failing side has: Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying for = 10 more seconds Mounting from ufs:/dev/label/RPi4root failed with error 2. Loader variables: vfs.root.mountfrom=3Dufs:/dev/label/RPi4root vfs.root.mountfrom.options=3Drw,noatime Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:zroot/ROOT/default cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> ? List of GEOM managed disk devices: mmcsd0 mountroot>=20 As for the "it boots" side of the comparison: Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Warning: no time-of-day clock registered, system time will not be set = accurately Setting hostuuid: a4f7fbeb-f668-11de-b280-ebb65474e619. Setting hostid: 0xcd8e9e25. Starting file system checks: /dev/label/RPi4root: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/label/RPi4root: clean, 19046293 free (498933 frags, 2318420 blocks, = 1.8% fragmentation) (And so on.) By contrast, the failing boot -v comparison goes like (not much is different between the two boot -v instances) . . . The working one had a 3rd REGISTER DUMP before the mmc0 bus width notice that the failing one did not have: sdhci_bcm1-slot0: Got command interrupt 0x00030000, but there is no = active command. sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_bcm1-slot0: Sys addr: 0x00000000 | Version: 0x00009902 sdhci_bcm1-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 sdhci_bcm1-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 sdhci_bcm1-slot0: Present: 0x000f0000 | Host ctl: 0x00000001 sdhci_bcm1-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_bcm1-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 sdhci_bcm1-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 sdhci_bcm1-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00bb sdhci_bcm1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_bcm1-slot0: Caps: 0x00000000 | Caps2: 0x00000000 sdhci_bcm1-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_bcm1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D where both then had: mmc0: setting bus width to 4 bits high speed timing The failing boot -v ended with: CPU 1: ARM Cortex-A72 r0p3 affinity: 1 CPU 2: ARM Cortex-A72 r0p3 affinity: 2 CPU 3: ARM Cortex-A72 r0p3 affinity: 3 regulator: shutting down unused regulators sdhci_bcm0-slot0: Controller timeout sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_bcm0-slot0: Sys addr: 0x000006c8 | Version: 0x00001002 sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000001 sdhci_bcm0-slot0: Argument: 0x0ee2afc1 | Trn mode: 0x00000036 sdhci_bcm0-slot0: Present: 0x1fff0a06 | Host ctl: 0x00000007 sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000080 sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 sdhci_bcm0-slot0: Timeout: 0x00000003 | Int stat: 0x00000000 sdhci_bcm0-slot0: Int enab: 0x01ff003b | Sig enab: 0x01ff003b sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_bcm0-slot0: Caps: 0x45ee6432 | Caps2: 0x0000a525 sdhci_bcm0-slot0: Max curr: 0x00080008 | ADMA err: 0x00000000 sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout mmcsd0: Error indicated: 1 Timeout Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying for = 10 more seconds Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying for = 9 more seconds Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying for = 8 more seconds Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying for = 7 more seconds Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying for = 6 more seconds Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying for = 5 more seconds Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying for = 4 more seconds Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying for = 3 more seconds Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying for = 2 more seconds Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying for = 1 more second Mounting from ufs:/dev/label/RPi4root failed with error 2. Loader variables: vfs.root.mountfrom=3Dufs:/dev/label/RPi4root vfs.root.mountfrom.options=3Drw,noatime Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:zroot/ROOT/default cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot>=20 The working boot -v instead had for that last area of the above output: CPU 1: ARM Cortex-A72 r0p3 affinity: 1 CPU 2: ARM Cortex-A72 r0p3 affinity: 2 CPU 3: ARM Cortex-A72 r0p3 affinity: 3 Root mount waiting for:regulator: shutting down unused regulators CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Warning: no time-of-day clock registered, system time will not be set = accurately start_init: trying /sbin/init Setting hostuuid: a4f7fbeb-f668-11de-b280-ebb65474e619. Setting hostid: 0xcd8e9e25. Starting file system checks: /dev/label/RPi4root: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/label/RPi4root: clean, 19057570 free (498234 frags, 2319917 blocks, = 1.8% fragmentation) (I omit the rest.) That is it for output differences for boot -v. I'll note that "shutdown -r now" does not reboot but just stops after the "Uptime:" message line. I do not expect that this is new. =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 Mar 29 02:58:42 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BE42E2702F0 for ; Sun, 29 Mar 2020 02:58:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (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 48qgJj3cT7z483B for ; Sun, 29 Mar 2020 02:58:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: BXd2akcVM1myQZyxC.4UxekoWYqVCJ8TJ8ybbRNVaTQK_XVyNtnb2KcBDkGKtHc KOKGtI_YAW6ENZTPrTvg7Zqoau2TbELtSl5JyowtVDwAsNMKruA7eOkKhxcU4XzTcZrAq5chAB_Y wJnRMmXTD.032w4Rv88IWL5CW5lcKAmcZanwCf7FKX16B0l8bQcMzn550kx.YyMfbFr1FblhRmKD KLa0N_5.HWHQexTyF.l6yWbjKC0M_onpMIgmo9l3wYFYAIhCD8faEw7pTGpJ4PfjdHysooGZaPb6 3jVZp5s2B93qv9pDYsuMGMDEesoLw7_DumH5QiJq4bzxRhSYaZICIu0w6p0HU4N_Pjkr79F2SGNX mWMuN6TJqiF8BzKKMjFtger4gElYqOZ2mr47hU92g7MJjQ5RHOPeyynP7t_BvVXHeUULlR3yNpZl lxynRVZEEe5LZLn4ZsavqxK9XcGzyYJr6.rI_XlfLhQYehqGqGeScB0EFRETyXmEqiBfUs66ZHRX 3.5XwnlaEFMRrLORSg7yPaBJYtjFPcVjR3L3YFK0hZ6GYQnfkwY4qGTOIq7JKjNuh9xo2YPPc7ob WGeOqsixdCfa5BOyVDbEG48IpIT8yZbthAD7Tmq8q2qYxp.nZMVBunHlHDwjXcNNXg9LndQKE92C CYZ7R7pOvOSxDxQrWp.DWnUgH9SnEEmotNetgiz_nKZo9qBFuvh8sBhNUgs2yQ9dhJMU_ZXgAxK_ wwD.zc6JTrXoYa_pHq252lFSKuiXSILlGJJceqGT70QXXfdwEU0BZ.TRR6z2ra5Gs8qGdURD38FP iA3dXQYgB0Xs4B6_hMzSM.8tpz8X06D7v7UmTUq61lJDP0qRjAfkayukAPWw7BljlW2zXLwkHeuK MbhEe1Jqmh6YsATOBij.1Gjq8GzgWG8mNCZoifJu3lEOd2i4ejEnZQuG.19FkqZaKFt8FvSHLkkG 4NeQgg80WGFqdwdQe3C1ui5eBpop7EWTM4JlR0vblh8W996LvPZ_gNo.JFKRF4kpLdT6Q2j4M.VT tvupL0LBmCcBOMudU9EorZLmfqAC03H0WL.EQbmW8qzxHoe558koOOksq5mFdSpb0lvhVn46oBSE .qdWcBrAER.uyG215uMqyFiSVV8XMCMHs8MeBdkExqodQKm1Gjmqsd_9BO2J_mQvx4svKLKQ3xbs 67nGgeHuVkzzfhQhF7kEqxik1q46l82XBrIZrWxovZnDtIj_ivVoahUMof6U2QbIeYLj3l6rnOxY 8MtMaMHzHLtEelkup1Pwq8utUk9ONe437kXPblfI043tuUkOo8UyB1lPfE7w7cmFpFZ.mYZvz6Sl 9uDbuv4jHHW.pq_X9pNDjDel3J6sLMIrmWqSZfAIxWHgs3q2jL3Rmk_MQkbQjMykDVFzm6LR_7cp eehlk1RVAluU.SykPHAh5xOIJdMmS7f3otsg7QvqWNQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 29 Mar 2020 02:58:17 +0000 Received: by smtp406.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID cbe0ed4219a9e5f11c9857a3fbfd180e; Sun, 29 Mar 2020 02:48:11 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: FYI: head -r358966 -> -r359376 and RPi4: -r359376 fails to boot (unless I use boot -v) where -r358966 booted fine before update Date: Sat, 28 Mar 2020 19:48:10 -0700 References: <147DDCEF-C081-4237-A81E-AEBCD71AB016@yahoo.com> To: freebsd-arm In-Reply-To: <147DDCEF-C081-4237-A81E-AEBCD71AB016@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 48qgJj3cT7z483B X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.17 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MAILSPIKE_FAIL(0.00)[31.65.137.98.rep.mailspike.net:query timed out]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.887,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.78)[-0.783,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (3.01), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.65), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[31.65.137.98.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 02:58:42 -0000 [Just correcting a persistent version number typo: head -r359376 is correct, not -r359736 . Subject corrected too.] On 2020-Mar-28, at 18:18, Mark Millard wrote: > On 2020-Mar-28, at 17:14, Mark Millard wrote: >=20 >> I use a microsd card that is set up for booting both >> a Rock64 and a RPi4: the dd'd u-boot vs. the RPi4 >> specific materials are in independent places and >> the rest is shared and rather generic. >>=20 >> So at head -r358966 I'd been able to both the >> Rock64 and the RPi4 from the same media. >>=20 >> Now with head -r359736 in place instead: Make that: -r358376 . >> A) The Rock64 boots via that media just fine. >>=20 >> B) The RPi4 fails to boot (nothing special >> like "boot -v"). >>=20 >> C) The RPi4 with "boot -v" boots just fine. >> (This makes identifying the issue non-obvious.) >>=20 >=20 > Booting the old kernel seems to consistently > work (unload, load, boot sequence). >=20 > boot -v of the new kernel can fail. >=20 > Plain boot of the new kernel can on occasion > boot. >=20 > This makes for more comparable output > difference checking . . . >=20 >=20 > Dealing with pain boot 1st (then I'll > show the boot -v comparison), I show > just differences in the captured output > . . . >=20 >=20 > EFI boot manager: Cannot load any image > 679248 bytes read in 91 ms (7.1 MiB/s) > libfdt fdt_check_header(): FDT_ERR_BADMAGIC >=20 > vs. >=20 > EFI boot manager: Cannot load any image > 679248 bytes read in 90 ms (7.2 MiB/s) > libfdt fdt_check_header(): FDT_ERR_BADMAGIC >=20 >=20 > Booting [/boot/kernel/kernel]... =20 >=20 > vs. >=20 > Booting [/boot/kernel/kernel] in 9 seconds...=20 >=20 > Type '?' for a list of commands, 'help' for more detailed help. > OK boot >=20 >=20 > Extra lines on "it boots" case, after the first 2 > "REGSITER DUMP"s, starting inside the 3rd >=20 > sdhci_bcm1-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 > sdhci_bcm1-slot0: Present: 0x000f0000 | Host ctl: 0x00000001 > sdhci_bcm1-slot0: Power: 0x0000000f | Blk gap: 0x00000000 > sdhci_bcm1-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_bcm1-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_bcm1-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00bb > sdhci_bcm1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 > sdhci_bcm1-slot0: Caps: 0x00000000 | Caps2: 0x00000000 > sdhci_bcm1-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 > sdhci_bcm1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 > sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > sdhci_bcm1-slot0: Got command interrupt 0x00030000, but there is no = active command. > sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_bcm1-slot0: Sys addr: 0x00000000 | Version: 0x00009902 > sdhci_bcm1-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_bcm1-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 > sdhci_bcm1-slot0: Present: 0x000f0000 | Host ctl: 0x00000001 > sdhci_bcm1-slot0: Power: 0x0000000f | Blk gap: 0x00000000 > sdhci_bcm1-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_bcm1-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_bcm1-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00bb > sdhci_bcm1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 > sdhci_bcm1-slot0: Caps: 0x00000000 | Caps2: 0x00000000 > sdhci_bcm1-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 > sdhci_bcm1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 > sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > sdhci_bcm1-slot0: Got command interrupt 0x00030000, but there is no = active command. > sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_bcm1-slot0: Sys addr: 0x00000000 | Version: 0x00009902 > sdhci_bcm1-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 >=20 >=20 > Extra lines on the "it fails to boot" side: >=20 > sdhci_bcm0-slot0: Controller timeout > sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_bcm0-slot0: Sys addr: 0x000006c8 | Version: 0x00001002 > sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000001 > sdhci_bcm0-slot0: Argument: 0x0ee2afc1 | Trn mode: 0x00000036 > sdhci_bcm0-slot0: Present: 0x1fff0a06 | Host ctl: 0x00000007 > sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000080 > sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 > sdhci_bcm0-slot0: Timeout: 0x00000003 | Int stat: 0x00000000 > sdhci_bcm0-slot0: Int enab: 0x01ff003b | Sig enab: 0x01ff003b > sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 > sdhci_bcm0-slot0: Caps: 0x45ee6432 | Caps2: 0x0000a525 > sdhci_bcm0-slot0: Max curr: 0x00080008 | ADMA err: 0x00000000 > sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 > sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > mmcsd0: Error indicated: 1 Timeout > mmcsd0: Error indicated: 1 Timeout > mmcsd0: Error indicated: 1 Timeout > mmcsd0: Error indicated: 1 Timeout > mmcsd0: Error indicated: 1 Timeout >=20 >=20 > After one "Root mount waiting for: CAM" > that both have, the failing side has: >=20 > Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 10 more seconds > Mounting from ufs:/dev/label/RPi4root failed with error 2. >=20 > Loader variables: > vfs.root.mountfrom=3Dufs:/dev/label/RPi4root > vfs.root.mountfrom.options=3Drw,noatime >=20 > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. >=20 > eg. ufs:/dev/da0s1a > zfs:zroot/ROOT/default > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) >=20 > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input >=20 > mountroot> ? >=20 > List of GEOM managed disk devices: > mmcsd0 >=20 > mountroot>=20 >=20 >=20 > As for the "it boots" side of the comparison: >=20 > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Warning: no time-of-day clock registered, system time will not be set = accurately > Setting hostuuid: a4f7fbeb-f668-11de-b280-ebb65474e619. > Setting hostid: 0xcd8e9e25. > Starting file system checks: > /dev/label/RPi4root: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/label/RPi4root: clean, 19046293 free (498933 frags, 2318420 = blocks, 1.8% fragmentation) >=20 > (And so on.) >=20 >=20 >=20 > By contrast, the failing boot -v > comparison goes like (not much is > different between the two boot -v > instances) . . . >=20 >=20 > The working one had a 3rd REGISTER DUMP > before the mmc0 bus width notice that the > failing one did not have: >=20 > sdhci_bcm1-slot0: Got command interrupt 0x00030000, but there is no = active command. > sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_bcm1-slot0: Sys addr: 0x00000000 | Version: 0x00009902 > sdhci_bcm1-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 > sdhci_bcm1-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 > sdhci_bcm1-slot0: Present: 0x000f0000 | Host ctl: 0x00000001 > sdhci_bcm1-slot0: Power: 0x0000000f | Blk gap: 0x00000000 > sdhci_bcm1-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 > sdhci_bcm1-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 > sdhci_bcm1-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00bb > sdhci_bcm1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 > sdhci_bcm1-slot0: Caps: 0x00000000 | Caps2: 0x00000000 > sdhci_bcm1-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 > sdhci_bcm1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 > sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=20 > where both then had: >=20 > mmc0: setting bus width to 4 bits high speed timing >=20 >=20 > The failing boot -v ended with: >=20 > CPU 1: ARM Cortex-A72 r0p3 affinity: 1 > CPU 2: ARM Cortex-A72 r0p3 affinity: 2 > CPU 3: ARM Cortex-A72 r0p3 affinity: 3 > regulator: shutting down unused regulators > sdhci_bcm0-slot0: Controller timeout > sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_bcm0-slot0: Sys addr: 0x000006c8 | Version: 0x00001002 > sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000001 > sdhci_bcm0-slot0: Argument: 0x0ee2afc1 | Trn mode: 0x00000036 > sdhci_bcm0-slot0: Present: 0x1fff0a06 | Host ctl: 0x00000007 > sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000080 > sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 > sdhci_bcm0-slot0: Timeout: 0x00000003 | Int stat: 0x00000000 > sdhci_bcm0-slot0: Int enab: 0x01ff003b | Sig enab: 0x01ff003b > sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 > sdhci_bcm0-slot0: Caps: 0x45ee6432 | Caps2: 0x0000a525 > sdhci_bcm0-slot0: Max curr: 0x00080008 | ADMA err: 0x00000000 > sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 > sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > mmcsd0: Error indicated: 1 Timeout > mmcsd0: Error indicated: 1 Timeout > mmcsd0: Error indicated: 1 Timeout > mmcsd0: Error indicated: 1 Timeout > mmcsd0: Error indicated: 1 Timeout > Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 10 more seconds > Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 9 more seconds > Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 8 more seconds > Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 7 more seconds > Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 6 more seconds > Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 5 more seconds > Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 4 more seconds > Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 3 more seconds > Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 2 more seconds > Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 1 more second > Mounting from ufs:/dev/label/RPi4root failed with error 2. >=20 > Loader variables: > vfs.root.mountfrom=3Dufs:/dev/label/RPi4root > vfs.root.mountfrom.options=3Drw,noatime >=20 > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. >=20 > eg. ufs:/dev/da0s1a > zfs:zroot/ROOT/default > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) >=20 > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input >=20 > mountroot>=20 >=20 >=20 > The working boot -v instead had for that last area of the > above output: >=20 > CPU 1: ARM Cortex-A72 r0p3 affinity: 1 > CPU 2: ARM Cortex-A72 r0p3 affinity: 2 > CPU 3: ARM Cortex-A72 r0p3 affinity: 3 > Root mount waiting for:regulator: shutting down unused regulators > CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Warning: no time-of-day clock registered, system time will not be set = accurately > start_init: trying /sbin/init > Setting hostuuid: a4f7fbeb-f668-11de-b280-ebb65474e619. > Setting hostid: 0xcd8e9e25. > Starting file system checks: > /dev/label/RPi4root: FILE SYSTEM CLEAN; SKIPPING CHECKS > /dev/label/RPi4root: clean, 19057570 free (498234 frags, 2319917 = blocks, 1.8% fragmentation) >=20 > (I omit the rest.) >=20 >=20 > That is it for output differences for > boot -v. >=20 >=20 > I'll note that "shutdown -r now" does not reboot > but just stops after the "Uptime:" message line. > I do not expect that this is new. =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 Mar 29 07:13:19 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8DB0727573A for ; Sun, 29 Mar 2020 07:13:19 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48qmyR71tSz3FFN for ; Sun, 29 Mar 2020 07:13:03 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from fomalhaut.potoki.eu ([IPv6:2001:470:71:d47:65f8:2b55:88c8:bb2c]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPSA id 02T7Clnv049394 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 29 Mar 2020 09:12:47 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1585465967; bh=vEKj7U6l2QbJelOFQPNv5b8eoCRvAePfoHcbD3yhNWk=; h=Subject:To:References:From:Date:In-Reply-To; b=CrFxK5J2YJ9DjbeMGMxP+nIKCfmVv/ynZ5TxyEqsLhbrHFr9imoSJdF4Wnu+3NDai Q1ZohXBwIuLqXas5OSRsRbk7QEjAIkHzsagcdfUJzQQ9jJYczh8kug1aGIdMW08eAZ SfunBQbAtfM65y91xYt+T78M8hCnPRixf/q9fEEs1Yb8OiInI94+nvU+u/lM3L6gZg 54KqgI3iVbedwRsed2IMpOdw7cQg8pG8KdT5IRO26K+jybEDveHqssTIU+S6kfxjCI c/RhfD5t1wr/ZWnO2XE6VqhKSO6cRKy6eyNK/+3tRHcV3k/EYrqVnWX5hOO9xO2fWa mT1vIA9oLo7gQ== X-Authentication-Warning: plan-b.pwste.edu.pl: Host [IPv6:2001:470:71:d47:65f8:2b55:88c8:bb2c] claimed to be fomalhaut.potoki.eu Subject: Re: FYI: head -r358966 -> -r359376 and RPi4: -r359376 fails to boot (unless I use boot -v) where -r358966 booted fine before update To: Mark Millard , freebsd-arm References: <147DDCEF-C081-4237-A81E-AEBCD71AB016@yahoo.com> From: Marek Zarychta Autocrypt: addr=zarychtam@plan-b.pwste.edu.pl; prefer-encrypt=mutual; keydata= mQENBFfi3cMBCADLecMTFXad4uDXqv3eRuB4qJJ8G9tzzFezeRnnwxOsPdytW5ES2z1ibSrR IsiImx6+PTqrAmXpTInxAi7yiZGdSiONRI4CCxKY9d1YFiNYT/2WyNXCekm9x29YeIU7x0JB Llbz0f/9HC+styBIu2H+PY/X98Clzm110CS+n/b9l1AtiGxTiVFj7/uavYAKxH6LNWnbkuc5 v8EVNc7NkEcl5h7Z9X5NEtzDxTOiBIFQ/kOT7LAtkYUPo1lqLeOM2DtWSXTXQgXl0zJI4iP1 OAu4qQYm2nXwq4b2AH9peknelvnt1mpfgDCGSKnhc26q6ibTfMwydp+tvUtQIQYpA6b9ABEB AAG0N01hcmVrIFphcnljaHRhIChQbGFuLWIpIDx6YXJ5Y2h0YW1AcGxhbi1iLnB3c3RlLmVk dS5wbD6JATcEEwEIACEFAlfi4LkCGwMFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQHZW8 vIFppoJXdgf8D9X3VRFSNaR9lthSx/+uqas17J3FJKBo1xMQsC2a+44vzNvYJSuPGLLJ+LW2 HPVazjP/BWZJbxOYpliY4zxNRU0YCp0BLIVLibc//yax+mE42FND/+NiIZhqJscl6MLPrSwo sIwXec4XYkldkyqW/xBbBYXoIkBqdKB9j5j42Npy1IV/RizOSdmvTWY27ir8e/yGMR1RLr4F 8P5K3OWTdlGy2H2F/3J8bIPBLG6FpaIyLQw4dHSx8V02PYqDxK1cNo2kAOnU8PnZL/AGuMOH iv3MN1VYL8ehcmpBBsrZGebQJxrjY2/5IaTSgp9xHYT70kshuU6Qb97vk1mOjNZxgbkBDQRX 4t3DAQgA10h6RCXuBLMHxq5B8X/ZIlj9sgLoeyfRdDZEc9rT2KUeUJVHDsbvOFf4/7F1ovWY hJbA6GK/LUZeHHTjnbZcH1uDYQeHly4UOLxeEvhGoz4JhS2C7JzN/uRnwbdOAUbJr8rUj/IY a7gk906rktsc/Ldrxrxh7O6WO0JCh2XO/p4pDfEwwB37g4xHprSab28ECYJ9JMbtA8Sy4M55 g3+GQ28FvSlGnx48OoGXU2BZdc1vZKSQmNOlikB+9/hDX8zdYWVfDaX1TLQ8Ib4+xTUmapza mV/bxIsaZRBw+jFjLQHhTbIMfPEU+4mxFDvTdbKPruKPqVf1ydgMnPZWngowdwARAQABiQEf BBgBCAAJBQJX4t3DAhsMAAoJEB2VvLyBaaaC6qkIAJs9sDPqrqW0bYoRfzY6XjDWQ59p9tJi v8aogxacQNCfAu+WkJ8PNVUtC1dlVcG5NnZ80gXzd1rc8ueIvXlvdanUt/jZd8jbb3gaDbK3 wh1yMCGBl/1fOJTyEGYv1CRojv97KK89KP5+r8x1P1iHcSrunlDNqGxTMydNCwBH23QcOM+m u4spKnJ/s0VRBkw3xoKBZfZza6fTQ4gTpAipjyk7ldOGBV+PvkKATdhK2yLwuWXhKbg/GRlD 1r5P0gxzSqfV4My+KJuc2EDcrqp1y0wOpE1m9iZqCcd0fup5f7HDsYlLWshr7NQl28f6+fQb sylq/j672BHXsdeqf/Ip9V65AQ0EV+OTdwEIAMxnGg7OO/ZAnSwiIiABA9lil1Lfa5BWTH3c l1rz4slz7Gw99G9J3bX3FiPA0vU89dgBZ2k0/UVk5cI5EsMAvwJN4bPwRsfBELQqjCKkVZr4 vUeGyvgQ2jnoK1fcEFOnCRdwFy4EJ6Y/fsZCTj4IfQpkM1W7C3KuSGPcjPDA9XCLDjjp8bbA Q9VgQ68MntAnYxMqK0S3CrHp5Pruvb0x4MfFLNwaKtWK+UnJGPT4umj8PMP6XLsFC3g+SGoP aWoYRDI297ZGx4IBWEaJq181oEC5iUQ6WREti9fNQ3TsAB3Q2CjNlkx1geSczIFJSyOHmyJZ RqAocw1sIuPopvhWtR0AEQEAAYkCRAQYAQgADwUCV+OTdwIbAgUJCWYBgAEpCRAdlby8gWmm gsBdIAQZAQgABgUCV+OTdwAKCRB1n+z//VKNLOETCAC3ggwAAQij4hkIxQFapnRuIVb5vq7D AwJ9+Ld5/zYHOj2Tfu+BPSNGzI2edqboz2w1t55UHEYzYDp2axxIfPrZrXsBV4DsjtGwzVV/ jZ9or5qTaYFDEStRkzL4mRpTyYhl/T7GgWpwOJWOih+cU7RWzjSOxiYMi4QSYlkpDUCcZew0 C3HfcxeFqpeL46zgysHC2ptjINXQ+xR2/F6dbed+l7OsvJAfkBqJoQ/48m+8ly1lbViKck7q gWw143ljaKn2qGIjZdb95zcI/CP4L45SXq8NOweACdx2NfUphLrIMbNCqLkMUJcrnruKfbnp C8OMjFJIqlu+PsW593NcZyOugEAH/0cBsDxlSauSVK4kp8ald26pcBI6igNnIMgjaxMiZBjn eoxBiKAOAO93sPnPr9/64CMMwv1T+0vU2lj8SMKOdHVrB9sW/ICGji5skE85xPEAtUkdAQN+ +c2clotujcaj9lBZKJdncKmSxY0SshEa66H+s76u+2Q3jGK6vOrdxakWYCvh2P0/l52Nd/t2 eazLFgwtk5rbo7O0MSC1GNXUsG07vtZ+zxJXFRx7PQ3ZIn0Y4HqwvXUvqgZ9EHiKy8F+ondz 9IS8/Fs81N5ieujHhSWqbaibapnpeDHvT/FWf8iXfJqWq+F7C8lGShSkmsS5AOhB4TNNH5/m ZzECJa1ql64= Message-ID: Date: Sun, 29 Mar 2020 09:12:42 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oFeBLMH5zyUY9QqSL9U6hqhgzKYZRP9Y4" X-Rspamd-Queue-Id: 48qmyR71tSz3FFN X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=CrFxK5J2; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-5.55 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; HAS_ATTACHMENT(0.00)[]; HAS_XAW(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; DWL_DNSWL_LOW(-1.00)[pwste.edu.pl.dwl.dnswl.org : 127.0.11.1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; R_SPF_NA(0.00)[]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; IP_SCORE(0.35)[asn: 206006(1.70), country: PL(0.06)]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 07:13:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oFeBLMH5zyUY9QqSL9U6hqhgzKYZRP9Y4 Content-Type: multipart/mixed; boundary="fxWP5blVh2munGe8b4EgxjW6L4QOfVsdy"; protected-headers="v1" From: Marek Zarychta To: Mark Millard , freebsd-arm Message-ID: Subject: Re: FYI: head -r358966 -> -r359376 and RPi4: -r359376 fails to boot (unless I use boot -v) where -r358966 booted fine before update References: <147DDCEF-C081-4237-A81E-AEBCD71AB016@yahoo.com> In-Reply-To: --fxWP5blVh2munGe8b4EgxjW6L4QOfVsdy Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US W dniu 29.03.2020 o=C2=A004:48, Mark Millard via freebsd-arm pisze: > [Just correcting a persistent version number typo: > head -r359376 is correct, not -r359736 . Subject > corrected too.] > > On 2020-Mar-28, at 18:18, Mark Millard wrote: > >> On 2020-Mar-28, at 17:14, Mark Millard wrote: >> >>> I use a microsd card that is set up for booting both >>> a Rock64 and a RPi4: the dd'd u-boot vs. the RPi4 >>> specific materials are in independent places and >>> the rest is shared and rather generic. >>> >>> So at head -r358966 I'd been able to both the >>> Rock64 and the RPi4 from the same media. >>> >>> Now with head -r359736 in place instead: > Make that: -r358376 . > >>> A) The Rock64 boots via that media just fine. >>> >>> B) The RPi4 fails to boot (nothing special >>> like "boot -v"). >>> >>> C) The RPi4 with "boot -v" boots just fine. >>> (This makes identifying the issue non-obvious.) >>> >> Booting the old kernel seems to consistently >> work (unload, load, boot sequence). >> >> boot -v of the new kernel can fail. >> >> Plain boot of the new kernel can on occasion >> boot. >> >> This makes for more comparable output >> difference checking . . . >> >> >> Dealing with pain boot 1st (then I'll >> show the boot -v comparison), I show >> just differences in the captured output >> . . . >> >> >> EFI boot manager: Cannot load any image >> 679248 bytes read in 91 ms (7.1 MiB/s) >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >> >> vs. >> >> EFI boot manager: Cannot load any image >> 679248 bytes read in 90 ms (7.2 MiB/s) >> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >> >> >> Booting [/boot/kernel/kernel]... =20 >> >> vs. >> >> Booting [/boot/kernel/kernel] in 9 seconds...=20 >> >> Type '?' for a list of commands, 'help' for more detailed help. >> OK boot >> >> >> Extra lines on "it boots" case, after the first 2 >> "REGSITER DUMP"s, starting inside the 3rd >> >> sdhci_bcm1-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 >> sdhci_bcm1-slot0: Present: 0x000f0000 | Host ctl: 0x00000001 >> sdhci_bcm1-slot0: Power: 0x0000000f | Blk gap: 0x00000000 >> sdhci_bcm1-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 >> sdhci_bcm1-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 >> sdhci_bcm1-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00bb >> sdhci_bcm1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 >> sdhci_bcm1-slot0: Caps: 0x00000000 | Caps2: 0x00000000 >> sdhci_bcm1-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 >> sdhci_bcm1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 >> sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> sdhci_bcm1-slot0: Got command interrupt 0x00030000, but there is no ac= tive command. >> sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> sdhci_bcm1-slot0: Sys addr: 0x00000000 | Version: 0x00009902 >> sdhci_bcm1-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 >> sdhci_bcm1-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 >> sdhci_bcm1-slot0: Present: 0x000f0000 | Host ctl: 0x00000001 >> sdhci_bcm1-slot0: Power: 0x0000000f | Blk gap: 0x00000000 >> sdhci_bcm1-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 >> sdhci_bcm1-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 >> sdhci_bcm1-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00bb >> sdhci_bcm1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 >> sdhci_bcm1-slot0: Caps: 0x00000000 | Caps2: 0x00000000 >> sdhci_bcm1-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 >> sdhci_bcm1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 >> sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> sdhci_bcm1-slot0: Got command interrupt 0x00030000, but there is no ac= tive command. >> sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> sdhci_bcm1-slot0: Sys addr: 0x00000000 | Version: 0x00009902 >> sdhci_bcm1-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 >> >> >> Extra lines on the "it fails to boot" side: >> >> sdhci_bcm0-slot0: Controller timeout >> sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> sdhci_bcm0-slot0: Sys addr: 0x000006c8 | Version: 0x00001002 >> sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000001 >> sdhci_bcm0-slot0: Argument: 0x0ee2afc1 | Trn mode: 0x00000036 >> sdhci_bcm0-slot0: Present: 0x1fff0a06 | Host ctl: 0x00000007 >> sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000080 >> sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 >> sdhci_bcm0-slot0: Timeout: 0x00000003 | Int stat: 0x00000000 >> sdhci_bcm0-slot0: Int enab: 0x01ff003b | Sig enab: 0x01ff003b >> sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 >> sdhci_bcm0-slot0: Caps: 0x45ee6432 | Caps2: 0x0000a525 >> sdhci_bcm0-slot0: Max curr: 0x00080008 | ADMA err: 0x00000000 >> sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 >> sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> mmcsd0: Error indicated: 1 Timeout >> mmcsd0: Error indicated: 1 Timeout >> mmcsd0: Error indicated: 1 Timeout >> mmcsd0: Error indicated: 1 Timeout >> mmcsd0: Error indicated: 1 Timeout >> >> >> After one "Root mount waiting for: CAM" >> that both have, the failing side has: >> >> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying fo= r 10 more seconds >> Mounting from ufs:/dev/label/RPi4root failed with error 2. >> >> Loader variables: >> vfs.root.mountfrom=3Dufs:/dev/label/RPi4root >> vfs.root.mountfrom.options=3Drw,noatime >> >> Manual root filesystem specification: >> : [options] >> Mount using filesystem >> and with the specified (optional) option list. >> >> eg. ufs:/dev/da0s1a >> zfs:zroot/ROOT/default >> cd9660:/dev/cd0 ro >> (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) >> >> ? List valid disk boot devices >> . Yield 1 second (for background tasks) >> Abort manual input >> >> mountroot> ? >> >> List of GEOM managed disk devices: >> mmcsd0 >> >> mountroot>=20 >> >> >> As for the "it boots" side of the comparison: >> >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Warning: no time-of-day clock registered, system time will not be set = accurately >> Setting hostuuid: a4f7fbeb-f668-11de-b280-ebb65474e619. >> Setting hostid: 0xcd8e9e25. >> Starting file system checks: >> /dev/label/RPi4root: FILE SYSTEM CLEAN; SKIPPING CHECKS >> /dev/label/RPi4root: clean, 19046293 free (498933 frags, 2318420 block= s, 1.8% fragmentation) >> >> (And so on.) >> >> >> >> By contrast, the failing boot -v >> comparison goes like (not much is >> different between the two boot -v >> instances) . . . >> >> >> The working one had a 3rd REGISTER DUMP >> before the mmc0 bus width notice that the >> failing one did not have: >> >> sdhci_bcm1-slot0: Got command interrupt 0x00030000, but there is no ac= tive command. >> sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> sdhci_bcm1-slot0: Sys addr: 0x00000000 | Version: 0x00009902 >> sdhci_bcm1-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 >> sdhci_bcm1-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 >> sdhci_bcm1-slot0: Present: 0x000f0000 | Host ctl: 0x00000001 >> sdhci_bcm1-slot0: Power: 0x0000000f | Blk gap: 0x00000000 >> sdhci_bcm1-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 >> sdhci_bcm1-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 >> sdhci_bcm1-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00bb >> sdhci_bcm1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 >> sdhci_bcm1-slot0: Caps: 0x00000000 | Caps2: 0x00000000 >> sdhci_bcm1-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 >> sdhci_bcm1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 >> sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> >> where both then had: >> >> mmc0: setting bus width to 4 bits high speed timing >> >> >> The failing boot -v ended with: >> >> CPU 1: ARM Cortex-A72 r0p3 affinity: 1 >> CPU 2: ARM Cortex-A72 r0p3 affinity: 2 >> CPU 3: ARM Cortex-A72 r0p3 affinity: 3 >> regulator: shutting down unused regulators >> sdhci_bcm0-slot0: Controller timeout >> sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> sdhci_bcm0-slot0: Sys addr: 0x000006c8 | Version: 0x00001002 >> sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000001 >> sdhci_bcm0-slot0: Argument: 0x0ee2afc1 | Trn mode: 0x00000036 >> sdhci_bcm0-slot0: Present: 0x1fff0a06 | Host ctl: 0x00000007 >> sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000080 >> sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 >> sdhci_bcm0-slot0: Timeout: 0x00000003 | Int stat: 0x00000000 >> sdhci_bcm0-slot0: Int enab: 0x01ff003b | Sig enab: 0x01ff003b >> sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 >> sdhci_bcm0-slot0: Caps: 0x45ee6432 | Caps2: 0x0000a525 >> sdhci_bcm0-slot0: Max curr: 0x00080008 | ADMA err: 0x00000000 >> sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 >> sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> mmcsd0: Error indicated: 1 Timeout >> mmcsd0: Error indicated: 1 Timeout >> mmcsd0: Error indicated: 1 Timeout >> mmcsd0: Error indicated: 1 Timeout >> mmcsd0: Error indicated: 1 Timeout >> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying fo= r 10 more seconds >> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying fo= r 9 more seconds >> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying fo= r 8 more seconds >> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying fo= r 7 more seconds >> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying fo= r 6 more seconds >> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying fo= r 5 more seconds >> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying fo= r 4 more seconds >> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying fo= r 3 more seconds >> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying fo= r 2 more seconds >> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying fo= r 1 more second >> Mounting from ufs:/dev/label/RPi4root failed with error 2. >> >> Loader variables: >> vfs.root.mountfrom=3Dufs:/dev/label/RPi4root >> vfs.root.mountfrom.options=3Drw,noatime >> >> Manual root filesystem specification: >> : [options] >> Mount using filesystem >> and with the specified (optional) option list. >> >> eg. ufs:/dev/da0s1a >> zfs:zroot/ROOT/default >> cd9660:/dev/cd0 ro >> (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) >> >> ? List valid disk boot devices >> . Yield 1 second (for background tasks) >> Abort manual input >> >> mountroot>=20 >> >> >> The working boot -v instead had for that last area of the >> above output: >> >> CPU 1: ARM Cortex-A72 r0p3 affinity: 1 >> CPU 2: ARM Cortex-A72 r0p3 affinity: 2 >> CPU 3: ARM Cortex-A72 r0p3 affinity: 3 >> Root mount waiting for:regulator: shutting down unused regulators >> CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Root mount waiting for: CAM >> Warning: no time-of-day clock registered, system time will not be set = accurately >> start_init: trying /sbin/init >> Setting hostuuid: a4f7fbeb-f668-11de-b280-ebb65474e619. >> Setting hostid: 0xcd8e9e25. >> Starting file system checks: >> /dev/label/RPi4root: FILE SYSTEM CLEAN; SKIPPING CHECKS >> /dev/label/RPi4root: clean, 19057570 free (498234 frags, 2319917 block= s, 1.8% fragmentation) >> >> (I omit the rest.) >> >> >> That is it for output differences for >> boot -v. >> >> >> I'll note that "shutdown -r now" does not reboot >> but just stops after the "Uptime:" message line. >> I do not expect that this is new. > > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > 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 probably RPi4 specific only. I have just upgraded Pine64LTS to recent CURRENT and rebooted without issues. --=20 Marek Zarychta --fxWP5blVh2munGe8b4EgxjW6L4QOfVsdy-- --oFeBLMH5zyUY9QqSL9U6hqhgzKYZRP9Y4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAl6ASm4ACgkQdZ/s//1S jSz26Af+Ls9ueP2TCjen2O66oO5mmtFxe39cKHP1xgD1iFqCuo+Vsa6/kDYnaoT6 bYrUKf9Eq/5ZsoFQnrQQoLCxcjWbFFL4cbQbuFQm4xybA/AAxold75WcbASjCrIY Skqrr5JmQs1H+ERi7gy5ymLTkll4TjJiWvbHUMaXBNdE1Yh3LKYCCppHjCVCFAPY XdypdJjw+6dapzGSvuWskmfpn7a5GDD2P8tK51mm6EWszv1olAo3XVlLrmzX5q3Z v69Xh3x+1N7sfuTym1KQgypE+/vPXIQLKDRUkEaNT3b51vayitiYqVE07EO7kqWS eMniD9L4d4bz0mDw4CUtQJTp6HmLIg== =zWq2 -----END PGP SIGNATURE----- --oFeBLMH5zyUY9QqSL9U6hqhgzKYZRP9Y4-- From owner-freebsd-arm@freebsd.org Sun Mar 29 07:29:33 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 79A33275AF5 for ; Sun, 29 Mar 2020 07:29:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.gq1.yahoo.com (sonic311-23.consmr.mail.gq1.yahoo.com [98.137.65.204]) (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 48qnK70tSBz3LHy for ; Sun, 29 Mar 2020 07:29:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: uutmYvkVM1mIUZhbczphqiDWbz9Cu7zSiW89LolMZr.tS.YQb1jS9icE01GKmYF h_RXjfzO5dFQ_Ls.ZcFwcagig4lEcPtbHEIa6dLm3cbfvPx2u.5lXeOoLBlswrJmqVFV1hbEW95g 625OkmfY15dJZVKv0i2hDRYEJhGoj7LJlyXbYX_IjSJydfD40vhc9yYHCxILrdyJGBt3lZ9_ZFwk ZtlI2I9hzanifaEkeMv2SsZAHhFYtfuBTnj0jbV4_YsIKxG5gaMhXPn9QYKBXWZjeaf2qqWTudg2 uawZzJmU7TwUcbayQJPb8KAQpN11u.CHNBm1pOYe97epivT199cL_YZrey9YeOcgDNZFckhN2axe QRWnJRKOsCbN04azx4InTWuKXTsAG1ox3iqw2WBbv.b4M3hofjBgcrseUuKq4BzKNkiz9w.12KpY VtCzC6PEeORp3MybmH7cflMpK5hBeUwzfA1lmz6OOVWvs.o4KmgFtNmTULsnjcxK7DgPVsccXbS_ Ij_VOonjOzzgoHjXEMP_z37gDmpY7h0aUDAsLb7ErUM_tk7Y7j2UxErGH9Q5QfJXmEUc7BSQUKA1 ZjxWQQdkqVTmUbP4BtcApwyC0UZD6jXNlvqzigcgGzdZBPlhbbpViw8LO15J1AyHwKgfPgmes8na EnvX1rI4tkFYaCpxXp5_S8RRSVHGReLmRQSZni9WUIDV3RBOLerIvLXBObHTOOex83ZGownSE1WM 4d8eKoqpHmGw68r5.lMfdcC9Y.6FsLBUV7yzZCskBJQjoz4zVkfVCjK92bHaZcIhIeQc1O_s_xKN 2__OdBf6txyieuU5.T_uWpScVXjxbR8Vct8t1CHhdLIO1JoiDWm_uXcOQPlgj6ZD0Ts2ra7SjjwC TOLwKb0eMEYJQm7q6_3lGFvUobt9wNTpUdABK1VaejxzZjkrjA5_dyjRVZ124yTo1XaokYy1xmBV ywZ4_GF5_VN8pJ5DaokxsYwjL.JyQnYra7QCrHkupvRjcIUcGtcU9q6CmKAlm3csDIJ.AIXgMnOQ mwxHxk3UOVQna3Eeee26Y41d37WhDJBK39loqQdpbAAzZYFban94.imBH1lTeQ5CCXSWS8TGvEt4 0PrkbtP9_u7cXUyTGhMeS1bbe9ssTUFc80SfXdx1ByxGso5ZaqVaksU3hnRQTFs8TbNw_ORjaCpc Dp6E.vtMs0V4btFDs2i.1O9hd4Fwrzp4BAF1VfNYxMbPZJCE3gkE.CR84rBIyg2DSxv9hmZrKuuR wkWIwPOCOqr2beGpcQdS5kTAJNDd7OPmID5fhUJYIYEomSSkdAmmbgI.tvlATgz9Qu0gzgiMLxR4 irpdgwZuFptEWnTHs_gvqVh2uD5_4PzELnNMI7OjBDywXIeg3sQN39Z2AlHnjR.gKRUEjNh7fj.H u1ir6SCikVdxobHFC94w- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 29 Mar 2020 07:29:02 +0000 Received: by smtp419.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 277c1985075cca6ed984a1306091203a; Sun, 29 Mar 2020 07:29:01 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: FYI: artifact-based head bisect and OPi+2e (an armv7): -r359311 fails to boot but -r359309 boots (kernel substitutions) Message-Id: <221A0E27-6A0F-4136-AB76-2D6664279363@yahoo.com> Date: Sun, 29 Mar 2020 00:29:00 -0700 To: Conrad Meyer , freebsd-arm , FreeBSD Current X-Mailer: Apple Mail (2.3608.80.23.2.2) References: <221A0E27-6A0F-4136-AB76-2D6664279363.ref@yahoo.com> X-Rspamd-Queue-Id: 48qnK70tSBz3LHy X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.32 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.945,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.88)[-0.879,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (5.38), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.65), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[204.65.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[204.65.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 07:29:33 -0000 While trying to update the head version in use I ran into boot hangups on the OrangePi+ 2e and did an approximate bisect of artificact.freebsd.org kernels to find approximately which kernel version the issue started at. I found that head -r359309 boots and -r359311 fails (shown later below). The original update attempt was from -r359966 to -r359376 and -r359376 stopped there as well. (I kept world there and varied the kernel version for the approximate bisect activity.) It seems that at least one of the "MI-namespace" atomics added do not work in all its usage-contexts on the cortexA7 (armv7) involved. [I also ran into boot problems on the RPi4 (arch64 CortexA72) for the original upgrade in that context. But the RPi4 is incomplete and is not a long-established FreeBSD context. I've not tested it specifically against -r359309 and -r359311 . I'll otherwise ignore the RPi4 here, at least for now.] The OPi+2e hangups look like (a boot -v example): . . . Release APs CPU(1) applied BP hardening: not necessary CPU(3) applied BP hardening: not necessary CPU(2) applied BP hardening: not necessary regulator: shutting down unused regulators regulator: shutting down vcc3v0... Trying to mount root from = ufs:/dev/gpt/BPIM3root []... ok Root mount waiting for:regulator: shutting down vcc3v3... usbus0busy usbus2regulator: shutting down vcc5v0... usbus4ok usbus6regulator: shutting down gmac-3v3... CAMbusy uhub1: 1 port with 1 removable, self powered uhub3: 1 port with 1 removable, self powered uhub4: 1 port with 1 removable, self powered uhub6: 1 port with 1 removable, self powered Root mount waiting for: usbus6 CAM ugen6.2: at usbus6 umass0 on uhub6 umass0: on usbus6 umass0:0:0: Attached to scbus0 Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM GEOM: new disk da0 pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Direct Access SPC-4 SCSI device pass0: Serial Number REPLACED pass0: 40.000MB/s transfers da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number REPLACED da0: 40.000MB/s transfers da0: 228936MB (468862128 512 byte sectors) da0: quirks=3D0x2 da0: Delete methods: mountroot: waiting for device /dev/gpt/BPIM3root... random: unblocking device. rtc0: providing initial system time start_init: trying /sbin/init (And that is as far as it gets. I can break into the debugger on the console.) Notes: vfs.root.mountfrom=3D is used in /boot/loader.conf to direct the root file system to be from the USB SSD. The original kernel and world were non-debug builds. But the artifact kernels are debug builds. They did not report anything odd. (The /dev/gpt/BPIM3* based naming is from=20 repurposing media without bothering to rename things.) =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 Mar 29 07:52:56 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1001B2767A6 for ; Sun, 29 Mar 2020 07:52:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.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 48qnrB0zxDz3yyR for ; Sun, 29 Mar 2020 07:52:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 2YgjsB0VM1mxAAf9ByVL_wIjxKFrP8D.8dhNS5LqINne4Ey7FbvglK8t3Q.yAWs ZY1LncwtBbd0CMyBBprWaWsv8gaGqCgpl72aqTlWMwudqlQTMkWRU0YDmmgw6uqetSV2DLDi1nUE A9jlS_4M1jfKoHrAI5IfhXwi2_ZB2BEtBIdFM6tIuDh_c5KUAycVamW7bKBJq0t089tIA6qWiiHy wVjNKLSQNZxK4kN0Sz29gIlhOiJxtu5T.OcAds.HnFYJNdmekeVpLQXWKOgnbzLpnyG9nTge2Jtc 6nwqk7jgUv9lWMJ7AD5cGE2lS5dWZZeaXCMp0TFaEskmpBA61STzOzSHOcvMrBitn_OEfKdNPTcT PexWbVF67q2N36qhptkHW7ZfjAmvgBS4nP7.HModqc64k0AqNEpDAHQZaPuEZOrTiousC6nFtxWO ETHECZJ_joblAR4vjUbByi4RiKLBK2htPzzPEV93XkmH_okWuOg2zDit68xjnUlysDXwvdOJcilH g1.9WywqRZ6d4UaZqODY5LfBkIhmOpsUvx.0hw1AK4Ktu3XTq7USKQEeXIclzk9ZNbrrwAEBkchA 9MRbO4gEwl6G0GRG7w8PfGJ1fOv_aJL1nLK6wHHHllHLBrcIxENJhLNLxC3e4NDtVPKlyg7g11Oh Qjrf4EDa15T.QrzjjRXbdUCvmQ9mO5RNTdEHK.08u1.yDH1wxCtlLra6uPfE.PdE5AA46EVXhw8L s2x7kCUcHYcGMkn12ax7sv7pVwKopfrQJ7zHf.5W35zaqNd1.tQO2N4uKFVRxpriORY9AlY6qk6k cIPTfrJoPSQlm1b5L6WjQDLlBz.Vl8UOACuacotgxFS.gE1N5vfbsANEHQ5Kr4rF_SoiJmxcsvY8 W2E9GdENeEvst1yeqcA_IjWF.Ce3ba54_QKbRUOxefLQEBcnTZzD1pzee7YSraZOpbwSUJ3W92Ct ASqWSqKZ0JNLDchIQ4_iFamiAT9_SBrAnuetIzvm7MCv3goyWaiJ30dSN9nTXC8qpIhItnTbUOX. RSBiq3ZzScJfNtmrZ3w8Vx754ZPv9RRO2VA6XBPYKW2tAHPtIslcgQN1dlmRk7_s1q4n8qkSWinx 48uuKWWw.McneYIyTP8OuUM0WmCMafiznTwomIJPqn9yQl_Oufr.1n1fmkjX9z4CHAl8asdHrKeg x07Uc6HMeZPtlpih2qreo8WYe0WN33Wjb7uITNa3xmkU8SB._ZNTuK0RMwaf35RLamgw1nsLRLn4 LVlYmMy5Xm.8gWTObLeA9yvw9dsTLk_g.BGbbxew7r0w_R.OJ692lpYhKKUiSe.V3xDknOUH.San UZwUq4UUQt1Q4_7X7CmrhfPsFxHkFHjOxKHb8gL0zd5ISmQ.EkwAvo2zNRdUqsF4JV9xty3C4wD9 _n7fKH7qJb12n0aYWU0W_DTfqjYjeoidVbVzA_KFqfh1jL77T8x1Vd0obmYh2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 29 Mar 2020 07:52:31 +0000 Received: by smtp414.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 3aa9fea92bc6eb196c70520e907ece76; Sun, 29 Mar 2020 07:52:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: FYI: head -r358966 -> -r359376 and RPi4: -r359376 fails to boot (unless I use boot -v) where -r358966 booted fine before update From: Mark Millard In-Reply-To: Date: Sun, 29 Mar 2020 00:52:26 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <512454AB-47CC-49EC-9E67-1111C7AAC471@yahoo.com> References: <147DDCEF-C081-4237-A81E-AEBCD71AB016@yahoo.com> To: Marek Zarychta X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 48qnrB0zxDz3yyR X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.16 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.908,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.76)[-0.756,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (6.45), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.65), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.66.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[148.66.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 07:52:56 -0000 On 2020-Mar-29, at 00:12, Marek Zarychta wrote: > W dniu 29.03.2020 o 04:48, Mark Millard via freebsd-arm pisze: >> [Just correcting a persistent version number typo: >> head -r359376 is correct, not -r359736 . Subject >> corrected too.] >>=20 >> On 2020-Mar-28, at 18:18, Mark Millard wrote: >>=20 >>> On 2020-Mar-28, at 17:14, Mark Millard wrote: >>>=20 >>>> I use a microsd card that is set up for booting both >>>> a Rock64 and a RPi4: the dd'd u-boot vs. the RPi4 >>>> specific materials are in independent places and >>>> the rest is shared and rather generic. >>>>=20 >>>> So at head -r358966 I'd been able to both the >>>> Rock64 and the RPi4 from the same media. >>>>=20 >>>> Now with head -r359736 in place instead: >> Make that: -r358376 . >>=20 >>>> A) The Rock64 boots via that media just fine. >>>>=20 >>>> B) The RPi4 fails to boot (nothing special >>>> like "boot -v"). >>>>=20 >>>> C) The RPi4 with "boot -v" boots just fine. >>>> (This makes identifying the issue non-obvious.) >>>>=20 >>> Booting the old kernel seems to consistently >>> work (unload, load, boot sequence). >>>=20 >>> boot -v of the new kernel can fail. >>>=20 >>> Plain boot of the new kernel can on occasion >>> boot. >>>=20 >>> This makes for more comparable output >>> difference checking . . . >>>=20 >>>=20 >>> Dealing with pain boot 1st (then I'll >>> show the boot -v comparison), I show >>> just differences in the captured output >>> . . . >>>=20 >>>=20 >>> EFI boot manager: Cannot load any image >>> 679248 bytes read in 91 ms (7.1 MiB/s) >>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >>>=20 >>> vs. >>>=20 >>> EFI boot manager: Cannot load any image >>> 679248 bytes read in 90 ms (7.2 MiB/s) >>> libfdt fdt_check_header(): FDT_ERR_BADMAGIC >>>=20 >>>=20 >>> Booting [/boot/kernel/kernel]... =20 >>>=20 >>> vs. >>>=20 >>> Booting [/boot/kernel/kernel] in 9 seconds...=20 >>>=20 >>> Type '?' for a list of commands, 'help' for more detailed help. >>> OK boot >>>=20 >>>=20 >>> Extra lines on "it boots" case, after the first 2 >>> "REGSITER DUMP"s, starting inside the 3rd >>>=20 >>> sdhci_bcm1-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 >>> sdhci_bcm1-slot0: Present: 0x000f0000 | Host ctl: 0x00000001 >>> sdhci_bcm1-slot0: Power: 0x0000000f | Blk gap: 0x00000000 >>> sdhci_bcm1-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 >>> sdhci_bcm1-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 >>> sdhci_bcm1-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00bb >>> sdhci_bcm1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 >>> sdhci_bcm1-slot0: Caps: 0x00000000 | Caps2: 0x00000000 >>> sdhci_bcm1-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 >>> sdhci_bcm1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 >>> sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>> sdhci_bcm1-slot0: Got command interrupt 0x00030000, but there is no = active command. >>> sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = REGISTER DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> sdhci_bcm1-slot0: Sys addr: 0x00000000 | Version: 0x00009902 >>> sdhci_bcm1-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 >>> sdhci_bcm1-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 >>> sdhci_bcm1-slot0: Present: 0x000f0000 | Host ctl: 0x00000001 >>> sdhci_bcm1-slot0: Power: 0x0000000f | Blk gap: 0x00000000 >>> sdhci_bcm1-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 >>> sdhci_bcm1-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 >>> sdhci_bcm1-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00bb >>> sdhci_bcm1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 >>> sdhci_bcm1-slot0: Caps: 0x00000000 | Caps2: 0x00000000 >>> sdhci_bcm1-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 >>> sdhci_bcm1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 >>> sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>> sdhci_bcm1-slot0: Got command interrupt 0x00030000, but there is no = active command. >>> sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = REGISTER DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> sdhci_bcm1-slot0: Sys addr: 0x00000000 | Version: 0x00009902 >>> sdhci_bcm1-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 >>>=20 >>>=20 >>> Extra lines on the "it fails to boot" side: >>>=20 >>> sdhci_bcm0-slot0: Controller timeout >>> sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = REGISTER DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> sdhci_bcm0-slot0: Sys addr: 0x000006c8 | Version: 0x00001002 >>> sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000001 >>> sdhci_bcm0-slot0: Argument: 0x0ee2afc1 | Trn mode: 0x00000036 >>> sdhci_bcm0-slot0: Present: 0x1fff0a06 | Host ctl: 0x00000007 >>> sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000080 >>> sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 >>> sdhci_bcm0-slot0: Timeout: 0x00000003 | Int stat: 0x00000000 >>> sdhci_bcm0-slot0: Int enab: 0x01ff003b | Sig enab: 0x01ff003b >>> sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 >>> sdhci_bcm0-slot0: Caps: 0x45ee6432 | Caps2: 0x0000a525 >>> sdhci_bcm0-slot0: Max curr: 0x00080008 | ADMA err: 0x00000000 >>> sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 >>> sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>> mmcsd0: Error indicated: 1 Timeout >>> mmcsd0: Error indicated: 1 Timeout >>> mmcsd0: Error indicated: 1 Timeout >>> mmcsd0: Error indicated: 1 Timeout >>> mmcsd0: Error indicated: 1 Timeout >>>=20 >>>=20 >>> After one "Root mount waiting for: CAM" >>> that both have, the failing side has: >>>=20 >>> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 10 more seconds >>> Mounting from ufs:/dev/label/RPi4root failed with error 2. >>>=20 >>> Loader variables: >>> vfs.root.mountfrom=3Dufs:/dev/label/RPi4root >>> vfs.root.mountfrom.options=3Drw,noatime >>>=20 >>> Manual root filesystem specification: >>> : [options] >>> Mount using filesystem >>> and with the specified (optional) option list. >>>=20 >>> eg. ufs:/dev/da0s1a >>> zfs:zroot/ROOT/default >>> cd9660:/dev/cd0 ro >>> (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) >>>=20 >>> ? List valid disk boot devices >>> . Yield 1 second (for background tasks) >>> Abort manual input >>>=20 >>> mountroot> ? >>>=20 >>> List of GEOM managed disk devices: >>> mmcsd0 >>>=20 >>> mountroot>=20 >>>=20 >>>=20 >>> As for the "it boots" side of the comparison: >>>=20 >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Warning: no time-of-day clock registered, system time will not be = set accurately >>> Setting hostuuid: a4f7fbeb-f668-11de-b280-ebb65474e619. >>> Setting hostid: 0xcd8e9e25. >>> Starting file system checks: >>> /dev/label/RPi4root: FILE SYSTEM CLEAN; SKIPPING CHECKS >>> /dev/label/RPi4root: clean, 19046293 free (498933 frags, 2318420 = blocks, 1.8% fragmentation) >>>=20 >>> (And so on.) >>>=20 >>>=20 >>>=20 >>> By contrast, the failing boot -v >>> comparison goes like (not much is >>> different between the two boot -v >>> instances) . . . >>>=20 >>>=20 >>> The working one had a 3rd REGISTER DUMP >>> before the mmc0 bus width notice that the >>> failing one did not have: >>>=20 >>> sdhci_bcm1-slot0: Got command interrupt 0x00030000, but there is no = active command. >>> sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = REGISTER DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> sdhci_bcm1-slot0: Sys addr: 0x00000000 | Version: 0x00009902 >>> sdhci_bcm1-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 >>> sdhci_bcm1-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 >>> sdhci_bcm1-slot0: Present: 0x000f0000 | Host ctl: 0x00000001 >>> sdhci_bcm1-slot0: Power: 0x0000000f | Blk gap: 0x00000000 >>> sdhci_bcm1-slot0: Wake-up: 0x00000000 | Clock: 0x0000fa07 >>> sdhci_bcm1-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 >>> sdhci_bcm1-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00bb >>> sdhci_bcm1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 >>> sdhci_bcm1-slot0: Caps: 0x00000000 | Caps2: 0x00000000 >>> sdhci_bcm1-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 >>> sdhci_bcm1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 >>> sdhci_bcm1-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>>=20 >>> where both then had: >>>=20 >>> mmc0: setting bus width to 4 bits high speed timing >>>=20 >>>=20 >>> The failing boot -v ended with: >>>=20 >>> CPU 1: ARM Cortex-A72 r0p3 affinity: 1 >>> CPU 2: ARM Cortex-A72 r0p3 affinity: 2 >>> CPU 3: ARM Cortex-A72 r0p3 affinity: 3 >>> regulator: shutting down unused regulators >>> sdhci_bcm0-slot0: Controller timeout >>> sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = REGISTER DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> sdhci_bcm0-slot0: Sys addr: 0x000006c8 | Version: 0x00001002 >>> sdhci_bcm0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000001 >>> sdhci_bcm0-slot0: Argument: 0x0ee2afc1 | Trn mode: 0x00000036 >>> sdhci_bcm0-slot0: Present: 0x1fff0a06 | Host ctl: 0x00000007 >>> sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000080 >>> sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00000107 >>> sdhci_bcm0-slot0: Timeout: 0x00000003 | Int stat: 0x00000000 >>> sdhci_bcm0-slot0: Int enab: 0x01ff003b | Sig enab: 0x01ff003b >>> sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 >>> sdhci_bcm0-slot0: Caps: 0x45ee6432 | Caps2: 0x0000a525 >>> sdhci_bcm0-slot0: Max curr: 0x00080008 | ADMA err: 0x00000000 >>> sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 >>> sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>> mmcsd0: Error indicated: 1 Timeout >>> mmcsd0: Error indicated: 1 Timeout >>> mmcsd0: Error indicated: 1 Timeout >>> mmcsd0: Error indicated: 1 Timeout >>> mmcsd0: Error indicated: 1 Timeout >>> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 10 more seconds >>> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 9 more seconds >>> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 8 more seconds >>> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 7 more seconds >>> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 6 more seconds >>> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 5 more seconds >>> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 4 more seconds >>> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 3 more seconds >>> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 2 more seconds >>> Mounting from ufs:/dev/label/RPi4root failed with error 2; retrying = for 1 more second >>> Mounting from ufs:/dev/label/RPi4root failed with error 2. >>>=20 >>> Loader variables: >>> vfs.root.mountfrom=3Dufs:/dev/label/RPi4root >>> vfs.root.mountfrom.options=3Drw,noatime >>>=20 >>> Manual root filesystem specification: >>> : [options] >>> Mount using filesystem >>> and with the specified (optional) option list. >>>=20 >>> eg. ufs:/dev/da0s1a >>> zfs:zroot/ROOT/default >>> cd9660:/dev/cd0 ro >>> (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) >>>=20 >>> ? List valid disk boot devices >>> . Yield 1 second (for background tasks) >>> Abort manual input >>>=20 >>> mountroot>=20 >>>=20 >>>=20 >>> The working boot -v instead had for that last area of the >>> above output: >>>=20 >>> CPU 1: ARM Cortex-A72 r0p3 affinity: 1 >>> CPU 2: ARM Cortex-A72 r0p3 affinity: 2 >>> CPU 3: ARM Cortex-A72 r0p3 affinity: 3 >>> Root mount waiting for:regulator: shutting down unused regulators >>> CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Root mount waiting for: CAM >>> Warning: no time-of-day clock registered, system time will not be = set accurately >>> start_init: trying /sbin/init >>> Setting hostuuid: a4f7fbeb-f668-11de-b280-ebb65474e619. >>> Setting hostid: 0xcd8e9e25. >>> Starting file system checks: >>> /dev/label/RPi4root: FILE SYSTEM CLEAN; SKIPPING CHECKS >>> /dev/label/RPi4root: clean, 19057570 free (498234 frags, 2319917 = blocks, 1.8% fragmentation) >>>=20 >>> (I omit the rest.) >>>=20 >>>=20 >>> That is it for output differences for >>> boot -v. >>>=20 >>>=20 >>> I'll note that "shutdown -r now" does not reboot >>> but just stops after the "Uptime:" message line. >>> I do not expect that this is new. >>=20 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >> ( dsl-only.net went >> away in early 2018-Mar) >>=20 >> _______________________________________________ >> 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 > This is probably RPi4 specific only. I have just upgraded Pine64LTS to > recent CURRENT and rebooted without issues. >=20 Actually, I've now also reported boot problems on an OrgangePi+ 2e (armv7) and did a kernel bisect that showed the OPi+2e problem starting at head -r359311 (and continuing on after that). ( -r359309 and before boots the OPi+2e just fine. ) Head -r359311 was an attempt to move various atomics into the "MI-namesace". It suggests that at least one atomic (or its use) is now broken on armv7. There might be more or some non-armv7 examples as well. With any broken atomics, I'd not necessarily expect a detailed behavioral match across the likes of OPi+2e vs. RPi4. The RPi4 might have hit such an issue. But I've not substituted artifact.freebsd.org kernels to test such (yet?) on the RPi4. The RPi4 is far from complete and not expected to be generally operational at this time. It does not make for a great debugging context as stands. I've not had such problems for the Rock64 or RPi3 that had the intended version upgrade. But it could also be that whatever breakage for either of them is just not as obvious. So, now I've got to figure out what I'm going to do for the other machines that were to have matching version upgrades. =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 Mar 29 09:55:25 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 346EF27926F for ; Sun, 29 Mar 2020 09:55:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-20.consmr.mail.gq1.yahoo.com (sonic309-20.consmr.mail.gq1.yahoo.com [98.137.65.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 48qrYM1xsCz3GNF for ; Sun, 29 Mar 2020 09:55:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 0kexIdYVM1lRHokh8PuG82YJ6Y84bVYiGVdzEzhYabtV5Sl2KspAssXP5B9zrA5 I6AKqZqu8s4oaWs8yqWCwf33dwdlS3aRQVzBhxF_YEADpTFdoHI53XziO_QVsMVbQHsz1942AAfl SPWN5qdHZHTP11XaxS0JzROBzQ9Be741VbUw8XVc67X3_uNooKXHJ5JesrWuoIqEGLT3yUnjwtNm 8LL2v8HLXd2TjRoG_gqGoq0Jj4Nx9YQUrVerCkpGdolBqfClivWSsPsYvV3SVRaFJ0XG5JqHMhLA lT7J0dRAQHW2eXDV0jOYVgdEp7ANuZ35a2mKRJH.ddB6a9xUW9YETYyPHuO6lUmiVmhg84_IUKLl aZStans8O1BKvBq_AblDExg9EWDnoSUU_2gnfow.IhvmX1xG6fSozvmJFHZZgsuV5_DjZRTYIZja 06_1sq.7h.0t5U2VyDBN0o3K0ikvhQNRqfWRHuN5uhtqYyQF2kjC1vc39_eSGc0ZDvHZLmn7wfXP nAUg3D9AJILQnGJyjYpVh47rCad0dF.3TLsgzQ5knKsJ8Ew7Mn.agpDp4wfzyuuIw_DYPe4gFqrN qtxN9RIZWv1rH37JY88dNQ0HIp221W_cSbF0.2usihMHmH3eAbIjClnc9l_6SHV6AgBZ91OpyrWY VrsVJZ948o5FHEVRIoQk1Qbeuv7AGFfGWH5fYd5cd0b4jtsA_QXcd60OTgpyB3zVTOCHUlugWmFk OKwMDg42ufIp5Mt6SI7szRmxCRVX.0_FcNgXXrqOa1BAT_GJifN_sRLM67MLFBN0tG9xsnMRXPaq GV3wLZXZm7wqHin1OmWV1N5NWYgnW97AHqO8NzQ7Kir9L.FEs4VxLwxqfLJdguGr8sx5vSlqa51Y W31.VgQl1POkFQB6eh4x5SFtfPHPcByhrDADq9uBc.Ds1xv7WaGsi931.WmgPzF7SHKVOuHCpX05 c2hx__7lZlVnXi7CWwOFumhYeGSMO.tAjH1Sf5VgpQ6N4RndWDh89ZJ8b25btZTbKBhzFrpL3l2K UoKi93yMV5Yy7AWu.Hutn4K4syhjhiyEO0tHaojvzNRJJdtQTAUWGoFcJJM72xuIz9VWwlqhCFle p0wtyyBusZdQg0UjhHoDQRrhp8GJtyCrdAv0AJliqCvOi2g3Oat61aE9cfNbAo6DwTh4yjHupVNZ nlitNfET_xEZ9eM_xDJt8rouTrzDazKig77FMHgDfe7nOg2HcJ7GWIjVHMDItyp0DRjrwgFvsdcf XzA7TmNViO7he.LHBz5A.Vh2_AiUqjhJSOwZfbzI2ngkj36vYL_RkrOXWRMv8wBpuH7pP6I0rW1g xh3YSd02vW.mNznLnCpvK0t15yjTXGY84VgkOIp8DNJoFMbYYTDxaNICAM3j93yNzXwbryxeAxRs uMexbMg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 29 Mar 2020 09:54:54 +0000 Received: by smtp414.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e410f683b97859629e4b728fdad5b8a7; Sun, 29 Mar 2020 09:54:49 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: FYI: head -r358966 -> -r359376 and RPi4: -r359376 fails to boot (unless I use boot -v) where -r358966 booted fine before update Date: Sun, 29 Mar 2020 02:54:48 -0700 References: <147DDCEF-C081-4237-A81E-AEBCD71AB016@yahoo.com> To: freebsd-arm In-Reply-To: Message-Id: <1F506CB0-A809-4DF6-9272-D41239C8A63B@yahoo.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 48qrYM1xsCz3GNF X-Spamd-Bar: - X-Spamd-Result: default: False [-1.51 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.72)[-0.715,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.30)[-0.297,0]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE_FREEMAIL(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[146.65.137.98.list.dnswl.org : 127.0.5.0]; MV_CASE(0.50)[]; IP_SCORE(0.00)[ip: (6.95), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.65), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 09:55:25 -0000 On 2020-Mar-28, at 19:48, Mark Millard wrote: > [Just correcting a persistent version number typo: > head -r359376 is correct, not -r359736 . Subject > corrected too.] > > On 2020-Mar-28, at 18:18, Mark Millard wrote: > >> On 2020-Mar-28, at 17:14, Mark Millard wrote: >> >>> I use a microsd card that is set up for booting both >>> a Rock64 and a RPi4: the dd'd u-boot vs. the RPi4 >>> specific materials are in independent places and >>> the rest is shared and rather generic. >>> >>> So at head -r358966 I'd been able to both the >>> Rock64 and the RPi4 from the same media. >>> >>> Now with head -r359736 in place instead: > > Make that: -r358376 . [Not my day. Trying again: -r359376 . But that is not a major point of this note.] >>> A) The Rock64 boots via that media just fine. >>> >>> B) The RPi4 fails to boot (nothing special >>> like "boot -v"). >>> >>> C) The RPi4 with "boot -v" boots just fine. >>> (This makes identifying the issue non-obvious.) >>> >> >> Booting the old kernel seems to consistently >> work (unload, load, boot sequence). Turns our that the following sequence seems to always boot, using just my non-debug head -r359376 build: Get to the boot-loader prompt then: unload load /boot/kernel/kernel boot In other words: reloading the same kernel leads to such boot attempts working. The old kernel need not be involved at all for this kind of sequence. Also: I tried some artifact.freebsd.org debug kernel builds and they all booted fine. (This is not like the OPI+2e boot problem that I've separately reported. The OPI+2e boot-problem has a successful artifact bisection result: head -r359311 breaks things and -r359309 and before boot fine in my testing.) Somehow the RPi4 problem appears to be specific to non-debug builds --or at least to my non-debug builds of -r359376 . >> boot -v of the new kernel can fail. >> >> Plain boot of the new kernel can on occasion >> boot. Such variability likely somehow fits with the unload/load/boot sequence leading to changed behavior. I omit the prior boot-output diffs below. >> . . . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Mar 29 14:53:47 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A10632A1EE6 for ; Sun, 29 Mar 2020 14:53:47 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48qz9t6MQGz4PBh for ; Sun, 29 Mar 2020 14:53:38 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wm1-x332.google.com with SMTP id e9so6363021wme.4 for ; Sun, 29 Mar 2020 07:53:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=GXcVRkerbw/5kst0j7yEonv14S29e9hNPic3WuGLEkQ=; b=bZ1TnX8zwFNLMVrpStlp33oteNTcJY3fdo3fRyRCEPoB4DUwQD+MyzeZ4E+7TMm2N+ zlnCA304RzFDvDTNQPLIYWMtqh5RW5Fc94vtHHtV3lYpQ5JEMqMRQAM0zh7kEv73+/fd Gw47fw5lfDW75pXhA9zdJo6oYThERERsK+efb2csjiHTxARzkCqLSJdJDziEFcsLMvL2 J1+q1pVAsjH3LqSElrI18nHx2L3l1aWsWUbO10HLigpT4su+4XhpUXuP7J28NdDiMOKA v0JXjBCNzN1Ls06PXruc4pFU5NUNqejtgf/YI/2tHuAWZyf7iJGihaCZYnpa54eYYtk8 Mufg== X-Gm-Message-State: ANhLgQ2Ip81MvuUJs42gInLSFpNPhFI2l45ts+TZ+N6+Yi6PpQ5pGh6D V31e6mtFuOULrcNDM2fc4FUb82z0 X-Google-Smtp-Source: ADFU+vuLXtPzxqj4kDQAXRb7nxI4nVCp4tj9jHnZHBy6eTyV9QWzsBz+/E6pJLQcheFCDK0bvGCwlQ== X-Received: by 2002:a1c:e30b:: with SMTP id a11mr8332680wmh.7.1585493607673; Sun, 29 Mar 2020 07:53:27 -0700 (PDT) Received: from [192.168.1.168] (x59cc9bed.dyn.telefonica.de. [89.204.155.237]) by smtp.googlemail.com with ESMTPSA id r15sm18827446wra.19.2020.03.29.07.53.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Mar 2020 07:53:26 -0700 (PDT) From: =?utf-8?Q?Klaus_K=C3=BCchemann?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Switch to UEFI Re: CFT: alpha test of Ethernet driver for RPi4 Date: Sun, 29 Mar 2020 16:53:25 +0200 References: <964BBCA2-5EE1-4673-966E-63D37FEDB4EA@googlemail.com> <202003281622.02SGMcmi027728@mail.karels.net> <57d4ba4ef95eeaf382d2c0b2407e9dab@unrelenting.technology> <3d84dbd6acea80b04bee712b59661a86@unrelenting.technology> To: Greg V , freebsd-arm@freebsd.org, Mike Karels In-Reply-To: <3d84dbd6acea80b04bee712b59661a86@unrelenting.technology> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 48qz9t6MQGz4PBh X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.00)[ip: (-9.13), ipnet: 2a00:1450::/32(-2.38), asn: 15169(-0.46), country: US(-0.05)]; RECEIVED_SPAMHAUS_PBL(0.00)[237.155.204.89.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[googlemail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2.3.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 14:53:49 -0000 > Am 28.03.2020 um 23:39 schrieb greg@unrelenting.technology: >=20 >=20 > What allwinner? > How did you find anything allwinner-related in ACPI code, when AFAIK = no Allwinner SoC ever had ACPI tables written for it? >=20 > I'm talking about generic XHCI. Sorry, I always mix up Allwinner with Marvell, where you changed some things in generic_xhci_fdt. =E2=80=A6 Mo matter, what I wanted to say is that there perhaps could be some need = to add things for the bcm-soc what is called ACPi-glue by jmcneill in his sources=E2=80=A6= `hope you are right that it `ll be only a simple bugfix for you to get = the right IRQ setup in generic_xhci.c =E2=80=A6 > Am 28.03.2020 um 23:27 schrieb Mike Karels : >=20 >=20 > I=E2=80=99m not ready to put the source out in public, as the = copyright notice is not yet approved. I=E2=80=99ll put it in = phabricator when it=E2=80=99s ready. >=20 > About UEFI: I don=E2=80=99t know what=E2=80=99s involved, but half of = the driver interfaces with the rest of the network stack, and I don=E2=80=99= t see how using UEFI simplifies any of that. >=20 > Mike O.K., seems I misunderstood your 'alpha test=E2=80=98- offer=E2=80=A6 I thought you wanted us to test/review your code before you put it to = phabricator. Well, jmcneill, where you derived the genet-driver-sources from, has = already=20 integrated the driver in UEFI, while it is not yet integrated in = rpi4-uefi upstream, afaik. You can dual-boot in UEFI from dt(hangs at gpioregulator at the moment) = or ACPI(hangs unrelenting at greg`s irq-code at the the moment[.. just = kidding] . They are working on netboot at the moment ..=20 I really suggest to track the UEFI - devs to understand what=E2=80=99s = going on there..=20 it could be the right way to finally get this damned board under = control.. Regards Klaus= From owner-freebsd-arm@freebsd.org Sun Mar 29 15:18:06 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DF5862A27A7 for ; Sun, 29 Mar 2020 15:18:06 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48qzjq1vs3z4Xh8 for ; Sun, 29 Mar 2020 15:17:51 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wm1-x334.google.com with SMTP id g62so18376206wme.1 for ; Sun, 29 Mar 2020 08:17:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=J9/EntF+vMppuDvKz2kiC60rkHyoGZ4QBl+dLOUztXI=; b=bv0O7SzW5TFv9OxaTGfnkBaejwvtgVr8/f5rMwMHZxcgAueqjftEIiUPP7LIFE2ajs /wah/qYH7FulofejyaMQ5eLeY5yo/zMFieG8fE2bHyD4oz/ja2rwhO69nkD2FakjlAWX bg0LYRRzKTT0CElNBObPpEi/26+12EddF+uBnNyMrDtMwOEM6617WQ0bxVhP14MlYYaX bsBsb/0Xso47n1Pw6nbotPRt2xlZaR/QOpcQ1/BhOqsgv1HaMGl3+K1x2VXx+fqcIiFU Igumw83mhBufo/M3hndF589PokzEA5hT6dm7LynVSjfzDlmfuBbQQ+bAVOT3Q1vWHa05 wuAQ== X-Gm-Message-State: ANhLgQ1T/xx/XQQL3Vxo3KskSvSmpOgT7bHF7KDZDNIKe+XesduyK8Rw LGndElywjM7TAsB7bUO2rkE= X-Google-Smtp-Source: ADFU+vtoOWvPdBWSIkDAgZIoJOEInwZX+iinGykKkLqU054trCClAMTyEUMKgrGF6pJmta/O8tJFGw== X-Received: by 2002:a7b:c450:: with SMTP id l16mr8750292wmi.9.1585495059180; Sun, 29 Mar 2020 08:17:39 -0700 (PDT) Received: from [192.168.1.168] (x59cc9bed.dyn.telefonica.de. [89.204.155.237]) by smtp.googlemail.com with ESMTPSA id b187sm17841867wmc.14.2020.03.29.08.17.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Mar 2020 08:17:38 -0700 (PDT) From: =?utf-8?Q?Klaus_K=C3=BCchemann?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Switch to UEFI Re: CFT: alpha test of Ethernet driver for RPi4 Date: Sun, 29 Mar 2020 17:17:36 +0200 References: <964BBCA2-5EE1-4673-966E-63D37FEDB4EA@googlemail.com> <202003281622.02SGMcmi027728@mail.karels.net> <57d4ba4ef95eeaf382d2c0b2407e9dab@unrelenting.technology> <3d84dbd6acea80b04bee712b59661a86@unrelenting.technology> To: Greg V , freebsd-arm@freebsd.org, Mike Karels In-Reply-To: Message-Id: <7008E91E-3B0C-4FDA-9F1F-43C35B0DB9E4@googlemail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 48qzjq1vs3z4Xh8 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.00)[ip: (-8.81), ipnet: 2a00:1450::/32(-2.38), asn: 15169(-0.46), country: US(-0.05)]; RECEIVED_SPAMHAUS_PBL(0.00)[237.155.204.89.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[googlemail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.3.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 15:18:07 -0000 > Am 29.03.2020 um 16:53 schrieb Klaus K=C3=BCchemann = : >=20 >=20 > =E2=80=A6. > Well, jmcneill, where you derived the genet-driver-sources from, has = already=20 > integrated the driver in UEFI, while it is not yet integrated in = rpi4-uefi upstream, afaik. > =E2=80=A6=E2=80=A6=E2=80=A6.. > Klaus They merged it in edk2-upstream 10 minutes ago =E2=80=A6. Regards Klaus= From owner-freebsd-arm@freebsd.org Sun Mar 29 16:06:11 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1287F2A3932 for ; Sun, 29 Mar 2020 16:06:10 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48r0nD6s5lz3N6H for ; Sun, 29 Mar 2020 16:05:52 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wr1-x42b.google.com with SMTP id h9so17972315wrc.8 for ; Sun, 29 Mar 2020 09:05:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=lyqBDiLAg4mCxGgI5Z4IIReXIEqguLBb+mMiX9iHXyE=; b=amIxOYN+o2wrHN4q7LrA/YElP10aVsxdovUOFZzd5qKgB91WJMix8LSDBKBIcGehbx xKKjMmGdJ6jclgAs6KcX/PdBDUa1SlTna1MmoybTWBub3w63mvXi/sX5PVW4ZyujY9XA DJNiArwT6bElViEJeQX8Z4J6CTs+1/l2bzgNiaEstUWVI3GbhXTSIrQuNwAOlBHR0rqP y5GoltMMsiEk1d1TNnmCA7kZN8183s5dM6rU29YNvFn+UwdVsXE5i2Dg0dX9j+0qWOXM R5IHBYn4GXrXTst+6DKK5/YYUDaTT4HKBwRjuQg/hhk2Cw50GtcW4gxYeqKDJofRQTnG 6QQg== X-Gm-Message-State: ANhLgQ0viEeuepDc1LO+OgfEpuqztaTyMWcRmXwrSIjW5SAGm6M8mxwW 4uNcV6biTybj5emP5mW1G+AGfnX1 X-Google-Smtp-Source: ADFU+vtqzOd4Ruww4PVBAxzgIc4URLTU1x+keg8Da5F4xApcrHrU1N/SJhUln2zWm2GcDG2NEOqHPQ== X-Received: by 2002:adf:afd4:: with SMTP id y20mr11028045wrd.57.1585497942238; Sun, 29 Mar 2020 09:05:42 -0700 (PDT) Received: from [192.168.1.168] (x59cc9bed.dyn.telefonica.de. [89.204.155.237]) by smtp.googlemail.com with ESMTPSA id b15sm17706790wru.70.2020.03.29.09.05.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Mar 2020 09:05:41 -0700 (PDT) From: =?utf-8?Q?Klaus_K=C3=BCchemann?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Switch to UEFI Re: CFT: alpha test of Ethernet driver for RPi4 Date: Sun, 29 Mar 2020 18:05:39 +0200 References: <964BBCA2-5EE1-4673-966E-63D37FEDB4EA@googlemail.com> <202003281622.02SGMcmi027728@mail.karels.net> <57d4ba4ef95eeaf382d2c0b2407e9dab@unrelenting.technology> <3d84dbd6acea80b04bee712b59661a86@unrelenting.technology> <7008E91E-3B0C-4FDA-9F1F-43C35B0DB9E4@googlemail.com> To: Greg V , freebsd-arm@freebsd.org, Mike Karels In-Reply-To: <7008E91E-3B0C-4FDA-9F1F-43C35B0DB9E4@googlemail.com> Message-Id: <71EE10A9-4C21-4976-B96C-E305F1A32B56@googlemail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 48r0nD6s5lz3N6H X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[googlemail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; RCVD_IN_DNSWL_NONE(0.00)[b.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[237.155.204.89.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[googlemail.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 16:06:11 -0000 >=20 >=20 >> Am 29.03.2020 um 16:53 schrieb Klaus K=C3=BCchemann = : >>=20 >>=20 >> =E2=80=A6. >> Well, jmcneill, where you derived the genet-driver-sources from, has = already=20 >> integrated the driver in UEFI, while it is not yet integrated in = rpi4-uefi upstream, afaik. >> =E2=80=A6=E2=80=A6=E2=80=A6.. >> Klaus >=20 > They merged it in edk2-upstream 10 minutes ago =E2=80=A6. >=20 >=20 >=20 I have asked @jmcneill & @AndreiWarkentin of https://rpi4-uefi.dev/ for = permission to expose their work=20 on the FreeBSD-Wiki, will do that tonight=E2=80=A6 @ all fbsd-arm-devs : please step in to RPI4-uefi and let`s put things = together to=20 get this board really running usable=E2=80=A6 thanks... Regards Klaus=20= From owner-freebsd-arm@freebsd.org Sun Mar 29 16:17:53 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AD4782A3DF6 for ; Sun, 29 Mar 2020 16:17:53 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 48r12v1sx0z3x3G for ; Sun, 29 Mar 2020 16:17:41 +0000 (UTC) (envelope-from mike@karels.net) Received: from [10.0.2.10] (mjk-mac.karels.net [10.0.2.10]) by mail.karels.net (8.15.2/8.15.2) with ESMTP id 02TGHTm2032168; Sun, 29 Mar 2020 11:17:29 -0500 (CDT) (envelope-from mike@karels.net) From: "Mike Karels" To: "Klaus =?utf-8?q?K=C3=BCchemann?=" Cc: "Greg V" , freebsd-arm@freebsd.org Subject: Re: Switch to UEFI Re: CFT: alpha test of Ethernet driver for RPi4 Date: Sun, 29 Mar 2020 11:17:24 -0500 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: References: <964BBCA2-5EE1-4673-966E-63D37FEDB4EA@googlemail.com> <202003281622.02SGMcmi027728@mail.karels.net> <57d4ba4ef95eeaf382d2c0b2407e9dab@unrelenting.technology> <3d84dbd6acea80b04bee712b59661a86@unrelenting.technology> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.karels.net id 02TGHTm2032168 X-Rspamd-Queue-Id: 48r12v1sx0z3x3G X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net X-Spamd-Result: default: False [-4.49 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[karels.net]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-2.29)[ip: (-7.44), ipnet: 216.160.36.0/22(-3.87), asn: 209(-0.11), country: US(-0.05)]; FREEMAIL_TO(0.00)[googlemail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 16:17:53 -0000 On 29 Mar 2020, at 9:53, Klaus K=C3=BCchemann wrote: >> Am 28.03.2020 um 23:39 schrieb greg@unrelenting.technology: >> >> >> What allwinner? >> How did you find anything allwinner-related in ACPI code, when AFAIK=20 >> no Allwinner SoC ever had ACPI tables written for it? >> >> I'm talking about generic XHCI. > > Sorry, I always mix up Allwinner with Marvell, > where you changed some things in generic_xhci_fdt. =E2=80=A6 > Mo matter, what I wanted to say is that there perhaps could be some=20 > need to add things > for the bcm-soc what is called ACPi-glue by jmcneill in his sources=E2=80= =A6 > `hope you are right that it `ll be only a simple bugfix for you to get=20 > the right IRQ setup in generic_xhci.c =E2=80=A6 > > >> Am 28.03.2020 um 23:27 schrieb Mike Karels : >> >> >> I=E2=80=99m not ready to put the source out in public, as the copyrigh= t=20 >> notice is not yet approved. I=E2=80=99ll put it in phabricator when i= t=E2=80=99s=20 >> ready. >> >> About UEFI: I don=E2=80=99t know what=E2=80=99s involved, but half of = the driver=20 >> interfaces with the rest of the network stack, and I don=E2=80=99t see= how=20 >> using UEFI simplifies any of that. >> >> Mike > > O.K., seems I misunderstood your 'alpha test=E2=80=98- offer=E2=80=A6 > I thought you wanted us to test/review your code before you put it to=20 > phabricator. I=E2=80=99m ready to provide source to individual testers, but not to pub= lish=20 it yet. For anyone that wants to try it, I can provide source and maybe=20 a kernel; I=E2=80=99m not set up to do full images. I=E2=80=99ll also no= te that=20 I=E2=80=99m testing using a kernel that is not recent, because it boots w= ith=20 my current u-boot, but I suspect it will work fine with a recent kernel. > Well, jmcneill, where you derived the genet-driver-sources from, has=20 > already > integrated the driver in UEFI, while it is not yet integrated in=20 > rpi4-uefi upstream, afaik. > You can dual-boot in UEFI from dt(hangs at gpioregulator at the=20 > moment) or ACPI(hangs unrelenting at greg`s irq-code at the the=20 > moment[.. just kidding] . > They are working on netboot at the moment .. > I really suggest to track the UEFI - devs to understand what=E2=80=99s = going=20 > on there.. > it could be the right way to finally get this damned board under=20 > control.. > > > Regards > > Klaus From owner-freebsd-arm@freebsd.org Sun Mar 29 16:44:54 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6FB202A4468; Sun, 29 Mar 2020 16:44:54 +0000 (UTC) (envelope-from thomas-bsd@skibo.net) Received: from brown.elm.relay.mailchannels.net (brown.elm.relay.mailchannels.net [23.83.212.23]) (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 48r1dy0DLtz46mL; Sun, 29 Mar 2020 16:44:37 +0000 (UTC) (envelope-from thomas-bsd@skibo.net) X-Sender-Id: dreamhost|x-authsender|thomas-bsd@skibo.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 02342100E2A; Sun, 29 Mar 2020 16:44:27 +0000 (UTC) Received: from pdx1-sub0-mail-a53.g.dreamhost.com (100-96-14-9.trex.outbound.svc.cluster.local [100.96.14.9]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 529DA100F4B; Sun, 29 Mar 2020 16:44:26 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|thomas-bsd@skibo.net Received: from pdx1-sub0-mail-a53.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Sun, 29 Mar 2020 16:44:26 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|thomas-bsd@skibo.net X-MailChannels-Auth-Id: dreamhost X-Duck-Absorbed: 1cf501d15561da5d_1585500266775_830148381 X-MC-Loop-Signature: 1585500266775:3399237811 X-MC-Ingress-Time: 1585500266775 Received: from pdx1-sub0-mail-a53.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a53.g.dreamhost.com (Postfix) with ESMTP id 0E7167FFD9; Sun, 29 Mar 2020 09:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skibo.net; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=skibo.net; bh=e7BW9rHU41nU3IuNyeTuZrqAtOQ=; b=nr Y2jXoUu6RnrNn9q/xNUfEvW4YZDHwh579Bf2c+hrkk+MyXP0A7F0mIvkpufknd++ js6xyl45DyMopbkKYSIHsx3o0PVyqKqkz3hKOV0YxzzuRAToECC49pDAsmj5Y/dz tHJIdarpWGGvMUgXDMfmlZJ6h9Rt6vFUuVEaKy9/k= Received: from bentley (c-67-180-59-81.hsd1.ca.comcast.net [67.180.59.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas-bsd@skibo.net) by pdx1-sub0-mail-a53.g.dreamhost.com (Postfix) with ESMTPSA id 727307F7D3; Sun, 29 Mar 2020 09:44:25 -0700 (PDT) Date: Sun, 29 Mar 2020 09:44:22 -0700 X-DH-BACKEND: pdx1-sub0-mail-a53 From: Thomas Skibo To: Mark Millard Cc: Conrad Meyer , freebsd-arm , FreeBSD Current Subject: Re: FYI: artifact-based head bisect and OPi+2e (an armv7): -r359311 fails to boot but -r359309 boots (kernel substitutions) Message-ID: <20200329164422.GA68768@bentley> References: <221A0E27-6A0F-4136-AB76-2D6664279363.ref@yahoo.com> <221A0E27-6A0F-4136-AB76-2D6664279363@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <221A0E27-6A0F-4136-AB76-2D6664279363@yahoo.com> X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudeifedguddtiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepvfhhohhmrghsucfukhhisghouceothhhohhmrghsqdgsshgusehskhhisghordhnvghtqeenucffohhmrghinhepfhhrvggvsghsugdrohhrghenucfkphepieejrddukedtrdehledrkedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepsggvnhhtlhgvhidpihhnvghtpeeijedrudektddrheelrdekuddprhgvthhurhhnqdhprghthhepvfhhohhmrghsucfukhhisghouceothhhohhmrghsqdgsshgusehskhhisghordhnvghtqedpmhgrihhlfhhrohhmpehthhhomhgrshdqsghsugesshhkihgsohdrnhgvthdpnhhrtghpthhtohepfhhrvggvsghsugdqtghurhhrvghnthesfhhrvggvsghsugdrohhrgh X-Rspamd-Queue-Id: 48r1dy0DLtz46mL X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skibo.net header.s=skibo.net header.b=nr Y2jXo; dmarc=none; spf=pass (mx1.freebsd.org: domain of thomas-bsd@skibo.net designates 23.83.212.23 as permitted sender) smtp.mailfrom=thomas-bsd@skibo.net X-Spamd-Result: default: False [-3.25 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[skibo.net:s=skibo.net]; RCVD_COUNT_FIVE(0.00)[6]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:23.83.208.1/20]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[skibo.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[skibo.net:+]; RCVD_IN_DNSWL_NONE(0.00)[23.212.83.23.list.dnswl.org : 127.0.3.0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(-1.25)[ip: (-4.12), ipnet: 23.83.208.0/21(-1.11), asn: 36483(-0.96), country: CA(-0.09)]; FREEMAIL_TO(0.00)[yahoo.com]; RECEIVED_SPAMHAUS_PBL(0.00)[81.59.180.67.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:36483, ipnet:23.83.208.0/21, country:CA]; MIME_TRACE(0.00)[0:+] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 16:44:54 -0000 On Sun, Mar 29, 2020 at 12:29:00AM -0700, Mark Millard via freebsd-arm wrote: > While trying to update the head version > in use I ran into boot hangups on the > OrangePi+ 2e and did an approximate > bisect of artificact.freebsd.org kernels > to find approximately which kernel > version the issue started at. > > I found that head -r359309 boots and > -r359311 fails (shown later below). > The original update attempt was from > -r359966 to -r359376 and -r359376 > stopped there as well. (I kept world > there and varied the kernel version > for the approximate bisect activity.) > > It seems that at least one of the > "MI-namespace" atomics added do not work > in all its usage-contexts on the cortexA7 > (armv7) involved. It looks like my previous reply didn't go to the mailing lists. I'm new to mutt. Anyway, I looked at this problem yesterday and it seems r359311 enables using some atomic operations that were not being used until now. In particular, atomic_fcmpset_8() seems broken and hangs up in vm_page_bits_swap(). I think I have a fix but I want to run it by Ian. --Thomas Index: sys/arm/include/atomic-v6.h =================================================================== --- sys/arm/include/atomic-v6.h (revision 359412) +++ sys/arm/include/atomic-v6.h (working copy) @@ -196,7 +196,7 @@ \ __asm __volatile( \ "1: ldrex" SUF " %[tmp], [%[ptr]] \n" \ - " ldr %[ret], [%[oldv]] \n" \ + " ldr" SUF " %[ret], [%[oldv]] \n" \ " teq %[tmp], %[ret] \n" \ " ittee ne \n" \ " str" SUF "ne %[tmp], [%[oldv]] \n" \ -- ========= Thomas Skibo thomas-bsd@skibo.net From owner-freebsd-arm@freebsd.org Sun Mar 29 17:25:29 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DC3D42A5148 for ; Sun, 29 Mar 2020 17:25:29 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48r2Xz06nvz4Mbf for ; Sun, 29 Mar 2020 17:25:22 +0000 (UTC) (envelope-from maciphone2@googlemail.com) Received: by mail-wm1-x331.google.com with SMTP id b12so17187120wmj.3 for ; Sun, 29 Mar 2020 10:25:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=uc+fJwHgk0IPJT6oAutfxpdGqmSS7Sq6taz45qDJSg8=; b=AFkL8VHGxDpi3dO5dqv6viG/qwRifvFjervUhdhHWYbvdavDhnWs/yodf/9hWbGe0z oK3DuQG850joAyvdGnlPcUq8E70ZPacExYk+WFKRzGkDrDE+KUE1G5BekhYmxBF59d67 mE5kCJa9/j9Qja6XQAk8t+SNqAiS4VvgaxQTzGSldkqquVsYv/LirwRyG9wGSRR2FEEn LhgLn3Sw/vxox0Em9dZITGrDwbHPyFGzWK5AL78o7w2YCc4zh+X2P0Jk5EpPLgp3zcGj KqarXBHuJk771ARaYViXjOUjSIsrtbpMSHPoUSPo/IdxvD3I0sklnnB+IdtUiCt3O59l 5ChQ== X-Gm-Message-State: ANhLgQ29tbojMTouePWApL6zH2IdYG5t8PWeG3EwrnL6gtwFnA4tNTRm LXlTmuD4nyI1E1SBNxiu8HeIEEMM X-Google-Smtp-Source: ADFU+vsmxpvxBjKSanWOH4FVg4DJoPxVlnPlrez9F7k48K7w3W3CzpbSbbtz0Cvl70/2YpbjNXTo7Q== X-Received: by 2002:a7b:c5c6:: with SMTP id n6mr8997948wmk.74.1585502712971; Sun, 29 Mar 2020 10:25:12 -0700 (PDT) Received: from [192.168.1.168] (x59cc9bed.dyn.telefonica.de. [89.204.155.237]) by smtp.googlemail.com with ESMTPSA id w67sm17139677wmb.41.2020.03.29.10.25.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Mar 2020 10:25:12 -0700 (PDT) From: =?utf-8?Q?Klaus_K=C3=BCchemann?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Switch to UEFI Re: CFT: alpha test of Ethernet driver for RPi4 Date: Sun, 29 Mar 2020 19:25:10 +0200 References: <964BBCA2-5EE1-4673-966E-63D37FEDB4EA@googlemail.com> <202003281622.02SGMcmi027728@mail.karels.net> <57d4ba4ef95eeaf382d2c0b2407e9dab@unrelenting.technology> <3d84dbd6acea80b04bee712b59661a86@unrelenting.technology> To: Mike Karels , freebsd-arm@freebsd.org In-Reply-To: Message-Id: <65211DDC-590E-4B68-B6E6-4DF295198657@googlemail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 48r2Xz06nvz4Mbf X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[googlemail.com]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; RECEIVED_SPAMHAUS_PBL(0.00)[237.155.204.89.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[googlemail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[1.3.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (-8.81), ipnet: 2a00:1450::/32(-2.38), asn: 15169(-0.46), country: US(-0.05)]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 17:25:30 -0000 > Am 29.03.2020 um 18:17 schrieb Mike Karels : >=20 >=20 >=20 > I=E2=80=99m ready to provide source to individual testers, but not to = publish it yet. For anyone that wants to try it, I can provide source = and maybe a kernel; I=E2=80=99m not set up to do full images. I=E2=80=99ll= also note that I=E2=80=99m testing using a kernel that is not recent, = because it boots with my current u-boot, but I suspect it will work fine = with a recent kernel. >=20 Well, Mike, you posted to a public mailing - list and not to individual = persons, so we could have more benefit to help you, ourselves and FreeBSD if we = would know about which code from you we discuss. Since it's called FreeBSD you can of course feel free to do(or let be) = what you want :-) But we cannot discuss your work if you keep it away from us... If you think your code is not ready for phab or bugs@ , you could just put snippets in a public gist or something similar... Just my few cents, please don't feel offended ,=20 But why not discuss your code here if you posted here ?=20 We don't need disk-images from you nor do we need compiled kernel, nor = u-boot, we need your src-tree(context) to test your code but a gist = (-diff) ( with pasted in copyright of jmcneill) could also help out ... Regards Klaus From owner-freebsd-arm@freebsd.org Sun Mar 29 17:58:48 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 009CB2A5B05 for ; Sun, 29 Mar 2020 17:58:47 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48r3HR6z7pz4ZBY for ; Sun, 29 Mar 2020 17:58:41 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1585504708; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=XLDTjNc1+OVhcdeK1fyGEL80grCuKSeRQlpEWcNTHKbXE6VNQPfa8aIRu7N9RhQk/iKrU7qOcOVID FMlqA0ASM1PFKOrbaY3+WiFkykDnoIGfcxzv3XGctG7NW8ftu0dTSmTOPsZZSwfv0NVCN2sz28v96h Q3xO9TZDTOB/DPzqoyzo0ri1fpHHCyWkgg/aZnCe6mQZ2LKs6t24I/jf2COYiWmV1oEIr7EKWrTT40 NlEPgcCwVyIXJrDa1Ym2Rr8F56o/9iBfYT+D9Nwq5kcMul45WaN6Tl6tEV9L0+VXvBwqTUsVNA28US yn/aCXkVSHQupYqmm/rcyUnaF1ctAoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=iReOXOg6GXWrGccjjA5f846ZqmdAyfE/2RbN9KuZQeE=; b=WEjx9et29GZfopUYqSgb6MguOQQg9rQIUZbdbeyJ7D0Uj7Pa4k//IVXL+B3U5tIXFY8Z2DvRcyv6I lcyOktzrX9jNrKZBYZ3TyoNX0IcGXQ2Re0ybZxL5JuAA3cuGla/VEoYxRYOQGgIsa0RKo6ZHWsRAIQ syZClGmMFzecgyyVRQRanrNfs/uf7wkTa9QdohYUY2vA7KK+1S9VPToZnzTq0yWgJOxBpUo2Q1bf1x shD1WQUHJk71rAqahuwXLoRV2kPdIiX83OhuDifY6JzKJkPKaKUCBB2hR1ZZerSCjYMWwyB3A++B8Z JdVrJhkH9zQugj8Nkv+ML5gsQs1BLJw== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=iReOXOg6GXWrGccjjA5f846ZqmdAyfE/2RbN9KuZQeE=; b=UhkI+NM9+QJvB94uWH7zsssVMwyVfVO77ZMe5BKUCUmMr9YeNRxg4Zpf72DGijRZOL7wWW5kuD4a8 4Uw7LU7OKQICzmEVAjMC1Xt2mcg8fYjvGpk0lmHbCa7FOYT5y7JV3q8oxSBvOBlTV6V+cwoyyIdw85 OCcStGtrJLQdne35XPJQk9mz0+9b6w7onpt1oA2nBETZMuXdjmAvtiAAAov6hBpzCG4W4b7Sf8drda Vcna6zRJsrVeHxlrwPlxX8hlZIF7iUvUUKw9AsFJL6fIZfbQfHlppDYsVquKusbWlYpghk9SQWUXnl Ue0VUuTNt0dl7aoVADAC5Iyb40sWVMQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: e32659c6-71e6-11ea-b80e-052b4a66b6b2 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 (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id e32659c6-71e6-11ea-b80e-052b4a66b6b2; Sun, 29 Mar 2020 17:58:26 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 02THwPft004336; Sun, 29 Mar 2020 11:58:25 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <85cab8fe92c87458be8e3c66d4071b3f6e3158ba.camel@freebsd.org> Subject: Re: FYI: artifact-based head bisect and OPi+2e (an armv7): -r359311 fails to boot but -r359309 boots (kernel substitutions) From: Ian Lepore To: Thomas Skibo , Mark Millard Cc: freebsd-arm , FreeBSD Current , Conrad Meyer Date: Sun, 29 Mar 2020 11:58:25 -0600 In-Reply-To: <20200329164422.GA68768@bentley> References: <221A0E27-6A0F-4136-AB76-2D6664279363.ref@yahoo.com> <221A0E27-6A0F-4136-AB76-2D6664279363@yahoo.com> <20200329164422.GA68768@bentley> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 48r3HR6z7pz4ZBY X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.78 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.94)[-0.945,0]; NEURAL_HAM_LONG(-0.83)[-0.833,0]; ASN(0.00)[asn:16509, ipnet:54.200.0.0/15, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 17:58:48 -0000 On Sun, 2020-03-29 at 09:44 -0700, Thomas Skibo wrote: > On Sun, Mar 29, 2020 at 12:29:00AM -0700, Mark Millard via freebsd- > arm wrote: > > While trying to update the head version > > in use I ran into boot hangups on the > > OrangePi+ 2e and did an approximate > > bisect of artificact.freebsd.org kernels > > to find approximately which kernel > > version the issue started at. > > > > I found that head -r359309 boots and > > -r359311 fails (shown later below). > > The original update attempt was from > > -r359966 to -r359376 and -r359376 > > stopped there as well. (I kept world > > there and varied the kernel version > > for the approximate bisect activity.) > > > > It seems that at least one of the > > "MI-namespace" atomics added do not work > > in all its usage-contexts on the cortexA7 > > (armv7) involved. > > It looks like my previous reply didn't go to the mailing lists. I'm > new to > mutt. > > Anyway, I looked at this problem yesterday and it seems r359311 > enables > using some atomic operations that were not being used until now. In > particular, atomic_fcmpset_8() seems broken and hangs up > in vm_page_bits_swap(). I think I have a fix but I want to run it > by Ian. > > --Thomas > > Index: sys/arm/include/atomic-v6.h > =================================================================== > --- sys/arm/include/atomic-v6.h (revision 359412) > +++ sys/arm/include/atomic-v6.h (working copy) > @@ -196,7 +196,7 @@ > \ > __asm __volatile( \ > "1: ldrex" SUF " %[tmp], [%[ptr]] \n" \ > - " ldr %[ret], [%[oldv]] \n" \ > + " ldr" SUF " %[ret], [%[oldv]] \n" \ > " teq %[tmp], %[ret] \n" \ > " ittee ne \n" \ > " str" SUF "ne %[tmp], [%[oldv]] \n" \ > I've committed this fix as r359423, thanks! -- Ian From owner-freebsd-arm@freebsd.org Mon Mar 30 17:45:45 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 66E2C261ACA for ; Mon, 30 Mar 2020 17:45:45 +0000 (UTC) (envelope-from thomas-bsd@skibo.net) Received: from fossa.birch.relay.mailchannels.net (fossa.birch.relay.mailchannels.net [23.83.209.62]) (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 48rfxn2wKbz3KlF for ; Mon, 30 Mar 2020 17:45:31 +0000 (UTC) (envelope-from thomas-bsd@skibo.net) X-Sender-Id: dreamhost|x-authsender|thomas-bsd@skibo.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 4F25F1E0F12 for ; Mon, 30 Mar 2020 17:45:21 +0000 (UTC) Received: from pdx1-sub0-mail-a69.g.dreamhost.com (100-96-9-10.trex.outbound.svc.cluster.local [100.96.9.10]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 6FE991E130E for ; Mon, 30 Mar 2020 17:45:16 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|thomas-bsd@skibo.net Received: from pdx1-sub0-mail-a69.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Mon, 30 Mar 2020 17:45:21 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|thomas-bsd@skibo.net X-MailChannels-Auth-Id: dreamhost X-Ruddy-Army: 3cdab7660846d2e7_1585590320733_658045489 X-MC-Loop-Signature: 1585590320733:3176243892 X-MC-Ingress-Time: 1585590320733 Received: from pdx1-sub0-mail-a69.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a69.g.dreamhost.com (Postfix) with ESMTP id 6EB6A7EFE8 for ; Mon, 30 Mar 2020 10:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skibo.net; h=date:from:to :subject:message-id:mime-version:content-type; s=skibo.net; bh=J cB0TIkfeoTidNjOje+M8f7EH3U=; b=aZJcOABjzwmaoiVu3UQsOvCPbB5P6LJeZ ocJTRGFsIiMPqYfhkR6jp7vB68xOuwJ+ABokHg1lpx2ufEMol50LCEZIUp1gxoYz VuAfEqB1t5afZrZFUauFoMUprnV3y79iZp7ayhDIYYd+Qp0+2yt1DfY0xCWOZwAp QzATutS8r0= Received: from bentley (c-67-180-59-81.hsd1.ca.comcast.net [67.180.59.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas-bsd@skibo.net) by pdx1-sub0-mail-a69.g.dreamhost.com (Postfix) with ESMTPSA id BE7747EFE5 for ; Mon, 30 Mar 2020 10:45:07 -0700 (PDT) Date: Mon, 30 Mar 2020 10:45:05 -0700 X-DH-BACKEND: pdx1-sub0-mail-a69 From: Thomas Skibo To: freebsd-arm@freebsd.org Subject: 64-bit extensions for Cadence if_cgem.c driver. Message-ID: <20200330174505.GA1561@bentley> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudeihedgudduhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehttdertddttddvnecuhfhrohhmpefvhhhomhgrshcuufhkihgsohcuoehthhhomhgrshdqsghsugesshhkihgsohdrnhgvtheqnecukfhppeeijedrudektddrheelrdekudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopegsvghnthhlvgihpdhinhgvthepieejrddukedtrdehledrkedupdhrvghtuhhrnhdqphgrthhhpefvhhhomhgrshcuufhkihgsohcuoehthhhomhgrshdqsghsugesshhkihgsohdrnhgvtheqpdhmrghilhhfrhhomhepthhhohhmrghsqdgsshgusehskhhisghordhnvghtpdhnrhgtphhtthhopehfrhgvvggsshguqdgrrhhmsehfrhgvvggsshgurdhorhhg X-Rspamd-Queue-Id: 48rfxn2wKbz3KlF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skibo.net header.s=skibo.net header.b=aZJcOABj; dmarc=none; spf=pass (mx1.freebsd.org: domain of thomas-bsd@skibo.net designates 23.83.209.62 as permitted sender) smtp.mailfrom=thomas-bsd@skibo.net X-Spamd-Result: default: False [-3.16 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[skibo.net:s=skibo.net]; RCVD_COUNT_FIVE(0.00)[6]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:23.83.208.1/20]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[skibo.net:+]; RCVD_IN_DNSWL_NONE(0.00)[62.209.83.23.list.dnswl.org : 127.0.3.0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(-1.16)[ip: (-3.65), ipnet: 23.83.208.0/21(-1.11), asn: 36483(-0.95), country: CA(-0.09)]; DMARC_NA(0.00)[skibo.net]; RECEIVED_SPAMHAUS_PBL(0.00)[81.59.180.67.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:36483, ipnet:23.83.208.0/21, country:CA]; MIME_TRACE(0.00)[0:+] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 17:45:45 -0000 Hello. I have been working on 64-bit extensions to the Cadence GEM Ethernet driver (dev/cadence/if_cgem.c). The GEM is used not only in the Zynq platform but also the Zynq UltraScale+ and the SiFve Highfive Unleashed (riscv) platforms. I finally got hardware that let me test the driver on a Zynq UltraScale. (I have an Ultra96 board with a 96B four-port Ethernet mezzanine card.) It will need a bit more testing but I think I am ready to put it up for review on phabricator. But, I have also fixed up a lot of style and white-space issues in the driver. Does it make sense to submit those changes first as a separate review before putting my functional changes up on phabricator? Or should I submit it all at once? Thanks, --Thomas -- ========= Thomas Skibo thomas-bsd@skibo.net From owner-freebsd-arm@freebsd.org Mon Mar 30 17:51:57 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 448D0261DEE for ; Mon, 30 Mar 2020 17:51:57 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48rg551kBMz3MrG for ; Mon, 30 Mar 2020 17:51:52 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1585590702; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=SnEk6pxIDATuL4YBHMPvjduqgGMEu+BRNOIaNnggPThnh56LjS8Gzn71NqBlnIg7tZt2Iz/9TUaGh Vs8/QNnYh+xlU6KFa+FacxBIi1gFLavOfYVOkb2uOIadU+3G4HVYbP0EXmFEpTi2Q2s3HQvgLESg5l qJhyg3wLQulib0eHWNBfY9yMrwCY5bEGZRz6TiC7QqSZd52G4NFLVN6zMrun3KuvDNvsKy80rRW1UM Ja9tIsBHfB7nu5ZuB1cM0UnbWEqjNi8zFOeGBgV5sdkf9R5yozH4pFy1m1+aB51I0wPfh1KpgzQAzM 7VzMiXdnwzrfogLKMk42fkuEWFwGOyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=jUrv5YcSP8BQg2iYHl6jJug+9PFTAymBCMveq/bgG9Q=; b=m/lO+Ztw3uqYpgk+kYf9ma6ZVirZFis3cYXyYvvqbLAcirMjkYx2p/W0aimdwCj2fmZWl/dPWWBa6 5W1mPrj7RuT7c+pP7DT8M6+GcHty72dpGgtdVrwf2JAnZrGiM9RjchKz0kNFJqg2w5rqCoiNwX0mgi dsKRAZhbpc8mDgOfhLZTzuL1kH8vivHAmG2kFRg7XpL2+fvV271Qxv2PNH6Xy1afla0KURv+GudYlO CQZNAyWV62C6y6jhk5KNrxXk4pwbQmS9zl9wiaN5yuEnGk1Fr6K6efF4iKnIHp5KfaDfheQ0UBYNqt DR+gRSk1Fk2UEFG4yp0Wl3E2YEy7n9w== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=jUrv5YcSP8BQg2iYHl6jJug+9PFTAymBCMveq/bgG9Q=; b=ZzGj8zoC37/WH1BvATiWfB9j/X9qDZF8EDD/bRFJUFLBKoXD731Rvg/Ek/QnSBW0cz5yc5N9Np73Y QKwVJCp34VY9HCC8iYHwzHq5BaEHRa4beYEjGZ2Ynf/jss8C2WjQJTVLabTYRkuphEJzIYuDbUIKLO L8qtXAwfpAqXnoCc0lAHnUulKb0oHhHptvAWGhPbNn66ukLoxkXGG/3zM1byb1FTlm0tf5zbWQO909 VIVC0M7fjIcolUJOEu0Qjd2/znBfz+NZdwPn1GQnuNpNs2CpfCv3lI5BhtXlwITAQFd7DEMFlFJ+7l NzA3Y8YT3f8uiE5zg8L9UbeJTYI9gsQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: 1c32678b-72af-11ea-b80e-052b4a66b6b2 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 (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 1c32678b-72af-11ea-b80e-052b4a66b6b2; Mon, 30 Mar 2020 17:51:41 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 02UHpe6R008283; Mon, 30 Mar 2020 11:51:40 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <3a62d50a338eb34dade74afc8a4fc556fcfbb754.camel@freebsd.org> Subject: Re: 64-bit extensions for Cadence if_cgem.c driver. From: Ian Lepore To: Thomas Skibo , freebsd-arm@freebsd.org Date: Mon, 30 Mar 2020 11:51:40 -0600 In-Reply-To: <20200330174505.GA1561@bentley> References: <20200330174505.GA1561@bentley> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 48rg551kBMz3MrG X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.63 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.88)[-0.879,0]; NEURAL_HAM_LONG(-0.75)[-0.747,0]; ASN(0.00)[asn:16509, ipnet:54.200.0.0/15, country:US] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 17:51:58 -0000 On Mon, 2020-03-30 at 10:45 -0700, Thomas Skibo wrote: > > Hello. > > I have been working on 64-bit extensions to the Cadence GEM Ethernet > driver > (dev/cadence/if_cgem.c). The GEM is used not only in the Zynq > platform but > also the Zynq UltraScale+ and the SiFve Highfive Unleashed (riscv) > platforms. > I finally got hardware that let me test the driver on a Zynq > UltraScale. (I > have an Ultra96 board with a 96B four-port Ethernet mezzanine card.) > > It will need a bit more testing but I think I am ready to put it up > for review on phabricator. But, I have also fixed up a lot of style > and > white-space issues in the driver. Does it make sense to submit those > changes > first as a separate review before putting my functional changes up on > phabricator? > > Or should I submit it all at once? > > Thanks, > --Thomas If you have the style changes separate from the functional changes already, it would be good to get those out of the way first, then the diffs for the functional changes will be much easier to read and review. -- Ian From owner-freebsd-arm@freebsd.org Mon Mar 30 18:47:55 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EFF7C263887 for ; Mon, 30 Mar 2020 18:47:55 +0000 (UTC) (envelope-from thomas-bsd@skibo.net) Received: from antelope.elm.relay.mailchannels.net (antelope.elm.relay.mailchannels.net [23.83.212.4]) (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 48rhKX1ptLz4Dl4; Mon, 30 Mar 2020 18:47:43 +0000 (UTC) (envelope-from thomas-bsd@skibo.net) X-Sender-Id: dreamhost|x-authsender|thomas-bsd@skibo.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 591F7480D29; Mon, 30 Mar 2020 18:39:50 +0000 (UTC) Received: from pdx1-sub0-mail-a69.g.dreamhost.com (100-96-12-20.trex.outbound.svc.cluster.local [100.96.12.20]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id AD056480601; Mon, 30 Mar 2020 18:39:49 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|thomas-bsd@skibo.net Received: from pdx1-sub0-mail-a69.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.6); Mon, 30 Mar 2020 18:39:50 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|thomas-bsd@skibo.net X-MailChannels-Auth-Id: dreamhost X-Blushing-Thread: 42fd330524dd380c_1585593590128_3746314858 X-MC-Loop-Signature: 1585593590128:1085905553 X-MC-Ingress-Time: 1585593590128 Received: from pdx1-sub0-mail-a69.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a69.g.dreamhost.com (Postfix) with ESMTP id 471F97EFE1; Mon, 30 Mar 2020 11:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skibo.net; h=date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=skibo.net; bh=rXQ/qbBnHdq/NSJTl4d5p8KoZyM=; b=0E /czOnN2zfvZyM4WAgCaIZB2YUL3QzVIK6koQLpTQV9/B9Gkl/Q3/wHEoNQKN7u+1 7coRipucJ7zaq4/VeWU9U4wgYMLSHt9eCTB3DOWK438D2u6abzhAk3O1i8avToUS vvT3WAT+2isPvvr8rYLaZ0SvmYorGnHV0cXY35sDQ= Received: from bentley (c-67-180-59-81.hsd1.ca.comcast.net [67.180.59.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas-bsd@skibo.net) by pdx1-sub0-mail-a69.g.dreamhost.com (Postfix) with ESMTPSA id 9DC957EFEF; Mon, 30 Mar 2020 11:39:48 -0700 (PDT) Date: Mon, 30 Mar 2020 11:39:46 -0700 X-DH-BACKEND: pdx1-sub0-mail-a69 From: Thomas Skibo To: Ian Lepore Cc: freebsd-arm@freebsd.org Subject: Re: 64-bit extensions for Cadence if_cgem.c driver. Message-ID: <20200330183946.GA1677@bentley> References: <20200330174505.GA1561@bentley> <3a62d50a338eb34dade74afc8a4fc556fcfbb754.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a62d50a338eb34dade74afc8a4fc556fcfbb754.camel@freebsd.org> X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudeihedguddvjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefvhhhomhgrshcuufhkihgsohcuoehthhhomhgrshdqsghsugesshhkihgsohdrnhgvtheqnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecukfhppeeijedrudektddrheelrdekudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopegsvghnthhlvgihpdhinhgvthepieejrddukedtrdehledrkedupdhrvghtuhhrnhdqphgrthhhpefvhhhomhgrshcuufhkihgsohcuoehthhhomhgrshdqsghsugesshhkihgsohdrnhgvtheqpdhmrghilhhfrhhomhepthhhohhmrghsqdgsshgusehskhhisghordhnvghtpdhnrhgtphhtthhopehfrhgvvggsshguqdgrrhhmsehfrhgvvggsshgurdhorhhg X-Rspamd-Queue-Id: 48rhKX1ptLz4Dl4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skibo.net header.s=skibo.net header.b=0E /czOn; dmarc=none; spf=pass (mx1.freebsd.org: domain of thomas-bsd@skibo.net designates 23.83.212.4 as permitted sender) smtp.mailfrom=thomas-bsd@skibo.net X-Spamd-Result: default: False [-2.43 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[skibo.net:s=skibo.net]; RCVD_COUNT_FIVE(0.00)[6]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:23.83.208.1/20]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[skibo.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-0.43)[ipnet: 23.83.208.0/21(-1.11), asn: 36483(-0.95), country: CA(-0.09)]; DKIM_TRACE(0.00)[skibo.net:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.212.83.23.list.dnswl.org : 127.0.3.0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36483, ipnet:23.83.208.0/21, country:CA]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[81.59.180.67.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 18:47:56 -0000 On Mon, Mar 30, 2020 at 11:51:40AM -0600, Ian Lepore wrote: > > If you have the style changes separate from the functional changes > already, it would be good to get those out of the way first, then the > diffs for the functional changes will be much easier to read and > review. > > -- Ian > > That's what I was thinking. Here they are: https://reviews.freebsd.org/D24226 Thanks, --Thomas -- ========= Thomas Skibo thomas-bsd@skibo.net From owner-freebsd-arm@freebsd.org Thu Apr 2 00:45:57 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 958742AA7AB for ; Thu, 2 Apr 2020 00:45:57 +0000 (UTC) (envelope-from crowston@protonmail.com) Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48t49X5nt6z3Qh3 for ; Thu, 2 Apr 2020 00:45:36 +0000 (UTC) (envelope-from crowston@protonmail.com) Date: Thu, 02 Apr 2020 00:25:46 +0000 To: mike@karels.net, freebsd-arm@freebsd.org From: Robert Crowston Reply-To: Robert Crowston Subject: Re: CFT: alpha test of Ethernet driver for RPi4 Message-ID: In-Reply-To: <202003281622.02SGMcmi027728@mail.karels.net> References: <202003281622.02SGMcmi027728@mail.karels.net> MIME-Version: 1.0 X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-Rspamd-Queue-Id: 48t49X5nt6z3Qh3 X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; HAS_REPLYTO(0.00)[crowston@protonmail.com]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; FREEMAIL_FROM(0.00)[protonmail.com]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[protonmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; RCPT_COUNT_TWO(0.00)[2]; MIME_BASE64_TEXT(0.10)[]; RCVD_COUNT_ZERO(0.00)[0]; RCVD_IN_DNSWL_LOW(-0.10)[134.40.70.185.list.dnswl.org : 127.0.5.1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=default]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; HAS_PHPMAILER_SIG(0.00)[]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ZRD_FAIL(0.00)[query timed out]; IP_SCORE(0.00)[ip: (-9.82), ipnet: 185.70.40.0/24(-4.89), asn: 62371(-3.91), country: CH(0.04)]; RBL_NIXSPAM_FAIL(0.00)[134.40.70.185.ix.dnsbl.manitu.net:query timed out] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 00:45:57 -0000 VGhpcyBpcyBicmlsbGlhbnQgbmV3cyEgV2VsbCBkb25lLgoKSeKAmW0gaGFwcHkgdG8gaGVscC4g SSBoYXZlIGEgZmV3IGRpZmZlcmVudCBQaTRzIGx5aW5nIGFyb3VuZCBhbmQgYSBKVEFHLgoKRG9l cyBldGhlcm5ldCB3b3JrIGZvciBuZXRic2QgeWV0IG9yIGlzIHRoaXMgc3RpbGwgaW4gZGV2ZWxv cG1lbnQgdGhlcmU/CgooV2lzaCBJIGhhZCBiZXR0ZXIgbmV3cyBvbiB0aGUgcGNpZSBmcm9udC4g SSBjYW4gZGV0ZWN0IHRoZSBwZXJpcGhlcmFsLCB0aGF0IGlzLCB0aGUgVVNCIGNvbnRyb2xsZXIs IGFuZCBjb25maWd1cmUgaXQsIGJ1dCBzdGlsbCBubyBsdWNrIGluIG1hcHBpbmcgdGhlIFBDSS1F IGJhcnMgaW50byB0aGUgYWRkcmVzcyBzcGFjZS4gSWYgeW91IGxlYXJudCBhbnkgdHJpY2tzIHRv IGdldCB0aGUgUGkgNOKAmXMgRE1BIHRvIGJlaGF2ZSwgZ2l2ZSBtZSBhIHNob3V0LikKCk9uIFNh dCwgTWFyIDI4LCAyMDIwIGF0IDE2OjIyLCBNaWtlIEthcmVscyA8bWlrZUBrYXJlbHMubmV0PiB3 cm90ZToKCj4gSSBoYXZlIGEgZHJpdmVyIGZvciB0aGUgRXRoZXJuZXQgb24gdGhlIFJQaTQgdGhh dCBpcyBuZWFybHkgcmVhZHkgZm9yCj4gaW5pdGlhbCB0ZXN0aW5nLiBJZiB5b3UgaGF2ZSBhIFJQ aTQgYW5kIGFyZSB3aWxsaW5nIHRvIHRlc3QsIGxldCBtZQo+IGtub3cuIEFsc28sIGlmIGFueW9u ZSBpcyBhYmxlIHRvIHJldmlldyB0aGUgYnVzZG1hIGhvb2tzLCB0aGF0IHdvdWxkCj4gYmUgYXBw cmVjaWF0ZWQuCj4KPiBUaGVyZSBhcmUgYSBsb3Qgb2YgbG9vc2UgZW5kcy4gVGhlIG1haW4gbWlz c2luZyBmZWF0dXJlIGlzIGNoZWNrc3VtCj4gb2ZmbG9hZC4gVGhlcmUgYXJlIGFsc28gc29tZSBx dWVzdGlvbiBtYXJrcyBpbiB0aGUgaW5pdGlhbGl6YXRpb24gY29kZQo+IHRoYXQgbWFrZSBjb25m aWd1cmF0aW9uIGZhaXJseSBub2lzeSBhdCB0aGUgbW9tZW50Lgo+Cj4gVGhpcyBkcml2ZXIgaXMg ZGVyaXZlZCBpbiBwYXJ0IGZyb20gdGhlIE5ldEJTRCBiY21nZW5ldC5jIGRyaXZlciBieQo+IEph cmVkIE1jTmVpbGwuIEkgYWxzbyB1c2VkIGZyYW1ld29yayBmcm9tIHRoZSBBbGx3aW5uZXIgaWZf YXdnLmMgZHJpdmVyLAo+IGFsc28gYnkgSmFyZWQgTWNOZWlsbC4KPgo+IE1pa2UKPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IGZyZWVic2QtYXJtQGZy ZWVic2Qub3JnIG1haWxpbmcgbGlzdAo+IGh0dHBzOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1h bi9saXN0aW5mby9mcmVlYnNkLWFybQo+IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRv ICJmcmVlYnNkLWFybS11bnN1YnNjcmliZUBmcmVlYnNkLm9yZyI= From owner-freebsd-arm@freebsd.org Thu Apr 2 03:03:46 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ACB432AE61B for ; Thu, 2 Apr 2020 03:03:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48t7Dl53WZz3KPN for ; Thu, 2 Apr 2020 03:03:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: aKFl1AEVM1mLv7G0PxAx4d5avpexRRD.4Y8tuNtqLorJTv5h_pyqPSW3Hx4x04P GXbwNGQQ8TtKnL8NGRyArAdzijEryE_eGLW2VZ_7EOfXMduzC7l0HsxijC7eYXwC9eKbhJ3jgE4_ MqHL8a7oS57Pmon8eO7jDEmPMJBMFYh7uYtr4_fTMvBOYgf1eoz4U.n5GVDBWlD.Kr3yScFG5D4L 8Geyn_xY4T2NnN1EEDGsRpUOxViOrdAAQq9JG_RootSyKSdGys3IUq_XCQJGDKcw2EGqGorqXOIY s0v7abzkQlkpAf9yf4ttQqUE_qeWZdvJCHTl.PNLcr75L6k750CHlLmOYQqq5894zWCwuol2ke3S HTnDxxdWbTeYYtdIErU5Tml8tWrllyUKCgla3lMF83BVb6ilQdfKtOMprGcPSl6whmz0bigt27cz mkgB1UoYntQIcqMBLz.696GhEeYjmJpMHd72My.ae3hsUWQbV6VpQuFNtgJzBwfxq7PLzWcTUvhT JAgvUu2bn1EGBqWyoqPETMmyXphepRVOVoyG8Vs5pENxq0.CSWpzNbDlpkBh0.Ak79Qu7wdDFS7D WMc4QwFwN8vwr4vGh8l6B7rn8CNCV7ibtLa6sDDpZ_QucecTZwp3IAc4duXiShXuktlX62vhtFbe sMRJC_VRlHSW9lMqNxuVfmqr2ugxXSqycu9lmYbB3RezE6zRJEsn7RrU91TdUvVDmrHCrM1qFp5N A6emdElhqdptRHhBzau3Wfygm3t_5cvO_RZOYR7u6Cii2H.Qg_fFTUavBWZCtoKYeFKqwxpUnDjR HfnZe59kiK0AWq8mgyLTp3qaXw3fyKtgRpJXWINvMiCcV1_3h0aEfFpsUTUXiTjOOW4apG13l54p LkiEUriSluxVlZHHuBbHiosNJGTfvQzAwrh51I6FsFYcnERklqRD5wY1YAII4BBwliCxFgd1CK5p kR0eu7qS6eIVDou5qRazml9Tr4f8xva_8U2ROtnztUZNAZ5ExQEkfmWp9fyHKtDAQROrRnPvr40H _O2YyW4dXQ1vjm7bbqA2wB5MZf3XNe5LlmJlTU26LXhrqwhrkQzYHrfEqCZhYikckPDuJJ8m1uVN YB25k7EOKhhiEoMDuNyxyfx3O7R_b099gPZq3XZtFJsdoYqt8j9rHXA7IoZaGJbcO0khzC4Nm9yL 3Vdxa8c3PX7tQABAQNxZowwSRd.J4dTC4Sk5yWwvsOFWoVYauerrd4kSx.w.e1IEvmOv904gtXAO gQGPP1s6rvvCGnIyvDvO6VekS.6NUBqqF9aQbSZ2sKim7oGfGPMnUJOrzarOn_lEKbEhmfKCfvgF 0kw4h_VofQiB8qilqyoN9vNCFhH2CzDsOHpUZgmkArAg4sfAL4r8jvU.WXzxQWAjIqDzIqoQqnN7 A1fEnVD726LI8oObL2ZNW.Q-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 2 Apr 2020 03:03:27 +0000 Received: by smtp422.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f527517e8c662f49149958c26321af3e; Thu, 02 Apr 2020 03:03:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: FYI: artifact-based head bisect and OPi+2e (an armv7): -r359311 fails to boot but -r359309 boots (kernel substitutions) From: Mark Millard In-Reply-To: <85cab8fe92c87458be8e3c66d4071b3f6e3158ba.camel@freebsd.org> Date: Wed, 1 Apr 2020 20:03:25 -0700 Cc: freebsd-arm , FreeBSD Current , Conrad Meyer Content-Transfer-Encoding: 7bit Message-Id: References: <221A0E27-6A0F-4136-AB76-2D6664279363.ref@yahoo.com> <221A0E27-6A0F-4136-AB76-2D6664279363@yahoo.com> <20200329164422.GA68768@bentley> <85cab8fe92c87458be8e3c66d4071b3f6e3158ba.camel@freebsd.org> To: Ian Lepore , Thomas Skibo X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 48t7Dl53WZz3KPN X-Spamd-Bar: - X-Spamd-Result: default: False [-1.92 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.79)[-0.795,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.62)[-0.624,0]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_FIVE(0.00)[5]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[147.66.137.98.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[ip: (4.83), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.65), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 03:03:46 -0000 On 2020-Mar-29, at 10:58, Ian Lepore wrote: > On Sun, 2020-03-29 at 09:44 -0700, Thomas Skibo wrote: >> On Sun, Mar 29, 2020 at 12:29:00AM -0700, Mark Millard via freebsd- >> arm wrote: >>> While trying to update the head version >>> in use I ran into boot hangups on the >>> OrangePi+ 2e and did an approximate >>> bisect of artificact.freebsd.org kernels >>> to find approximately which kernel >>> version the issue started at. >>> >>> I found that head -r359309 boots and >>> -r359311 fails (shown later below). >>> The original update attempt was from >>> -r359966 to -r359376 and -r359376 >>> stopped there as well. (I kept world >>> there and varied the kernel version >>> for the approximate bisect activity.) >>> >>> It seems that at least one of the >>> "MI-namespace" atomics added do not work >>> in all its usage-contexts on the cortexA7 >>> (armv7) involved. >> >> It looks like my previous reply didn't go to the mailing lists. I'm >> new to >> mutt. >> >> Anyway, I looked at this problem yesterday and it seems r359311 >> enables >> using some atomic operations that were not being used until now. In >> particular, atomic_fcmpset_8() seems broken and hangs up >> in vm_page_bits_swap(). I think I have a fix but I want to run it >> by Ian. >> >> --Thomas >> >> Index: sys/arm/include/atomic-v6.h >> =================================================================== >> --- sys/arm/include/atomic-v6.h (revision 359412) >> +++ sys/arm/include/atomic-v6.h (working copy) >> @@ -196,7 +196,7 @@ >> \ >> __asm __volatile( \ >> "1: ldrex" SUF " %[tmp], [%[ptr]] \n" \ >> - " ldr %[ret], [%[oldv]] \n" \ >> + " ldr" SUF " %[ret], [%[oldv]] \n" \ >> " teq %[tmp], %[ret] \n" \ >> " ittee ne \n" \ >> " str" SUF "ne %[tmp], [%[oldv]] \n" \ >> > > > I've committed this fix as r359423, thanks! Thanks to both of you: the OPi+2e boots just fine now and has been operating like it used to (head -r359427 in use). === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Apr 2 23:37:38 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7319726AACD for ; Thu, 2 Apr 2020 23:37:38 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48tfcS089nz3GZG for ; Thu, 2 Apr 2020 23:37:27 +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 032NXxUp031744 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 2 Apr 2020 16:34:00 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 032NXxQt031743; Thu, 2 Apr 2020 16:33:59 -0700 (PDT) (envelope-from fbsd) Date: Thu, 2 Apr 2020 16:33:59 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Unexpected OOM kill on rpi2 while building world Message-ID: <20200402233359.GA31562@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 48tfcS089nz3GZG X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [0.61 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.70)[-0.701,0]; WWW_DOT_DOMAIN(0.50)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; IP_SCORE(0.05)[ip: (0.24), ipnet: 50.1.16.0/20(0.12), asn: 7065(-0.03), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.65)[-0.647,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; MID_RHS_WWW(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 23:37:38 -0000 Two installations of the FreeBSD-12.1-STABLE-arm-armv7-RPI2-20200305-r358659.img image have set up and built -j4 world using a single 64GB Samsung Evo Plus microSD card with a 2.6 GB swap partition. No changes to /boot/loader.conf required. On the third installation, the machine stopped with pid 68521 (c++), jid 0, uid 0, was killed: out of swap space so I set vm.pfault_oom_attempts="-1" and restarted buildworld with -DNO_CLEAN The machine promptly reported pid 93318 (c++), jid 0, uid 0, was killed: out of swap space In neither case were there any "indefinite wait...." or any other warning messages. At that point I set vm.pageout_oom_seq="4096" and restarted buildworld, again with -DNO_CLEAN. Buildworld seems to have gotten past the bottleneck and looks like it will complete, but I'm puzzled, both at the appearance of the trouble, not formerly seen on the Pi2, and on the failure of vm.pfault_oom_attempts="-1" by itself to disable OOMA. Casual observation suggests swap use peaks at a few hundred MB under 12.1 on the Pi2. All three installations were run on the same physical Pi, though of course the microSD cards were distinct. Even so, all three cards are nominally identical and likely from the same batch. The one tangible difference is that the Pi2 is now on a private network, the two earlier buildworlds were on a public network. Can't see how that would matter, however. Thanks for reading, and any insights. bob prohaska From owner-freebsd-arm@freebsd.org Fri Apr 3 00:11:50 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6623626C3FA for ; Fri, 3 Apr 2020 00:11:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48tgMq5Hg8z3yPP for ; Fri, 3 Apr 2020 00:11:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: cjYdHuIVM1m.fGQvWzt4A_rSJtknwjSnQtuYbIPHvwM5rtKoPeHmevPrx.pbtv7 kYFGh0vDhZZ7GUhoh589jntiC3nczNEnMdFcwgAOjNaw1zrBLoh.ohE4Hr3V1ahcWpFtH5DW2OTh tbhiFwzdOuiJ4eUsIs.PCpcE9WR1kvK85vVX0Gtza_P2NAa7tHEgWkuymjF36OD4.A4_E1dWTOEx gawbZ1VqJIL6naTAKplkw.bX54MyXTBwXwJo2hrE9trR3VVMzYFrzB7AOQnthrAzTkzA6gDqJPm_ 8mU1YxR4jKErrBol4LHG8ZTAjFCgpe7t7RhVc_P8n1av5sACfP7.NChyrrlnjBe9e14AZUBqfxKx HJlJai7iSSxeuw15_6ZDtHZFRntg7TF03mCE.RIDWs8HjLOKVsbT904.ob3Fq7lp9.3JkhqSCUDk YO4kkgagIY340GX4g0t7HngGW0Fp9mUM5M_tdRSxXRnCFLIH997mlNhhoM4an4eKbKm445weAzJ1 0YjcgY8gr1uXHthzyYbYkVbtGBRX29WiXb9GP0YUF35h8HfqJAqwKeKETvviEnemq3ClAXh_HCic 22JXoXy1NZrAUh238cGPVjjroE0fDjDEXOSIOKHOnKoho.emZH8jVQ9mTEHV6LlkAP5RnxJnpATT FrhVcrU4Aq7nzg75xs4vqjlpGVCsrXCt7IHkrn.As8qBS3hVjS0tnE4FEdp.nfoRoeSG5vv3ntwh ynBM_R5_dptytB399ks_Acn9iSRMer.KfR38GZUXX7c95X09iZ1V7RkwVesTdKl69wVERjZNwKZp wBDyS29RG3ABUlmr0makjKZIiXwik7ZRzwfcB16KXtXs8bv_jck6N7R5v6e7ZeXdYHfBHfc2DJ2g 2TdEBhTYg65C7kHqM4A1av.ZgZh5nhTHiLUutMarjBUgu88nLef1T_xv8T1w.3kkTEOD9bPwwBlU waoR815DT5aM4hpwbI.K3st63tecxDC8HblO_JBL81x8N5U3V3kbEsjIL5KmVVeRqSGrZ5qMU.Uo 4pBDoEKMXL_6SCX0sQo.4ZXg3zejis_V88reQ_.11o47v2xJVKlJRPs9V7Dvwc4VmQd__MFmy8f6 sz200uTFyCjJWCnC0vqoHxTSw6HTZeSeLzckGUaP5RP8MYBm9K0pq0d9PYrsMAtYiW03MxTXFsQC iqBU3x6Mr8stgF05YbnJAUnd2Vg4TBniLxY.mlxzj2jxChaKrDgCaNxNAY6RXdv4E1gJ5lVRo.qB nbUn31NXF80v0WBa2BCnUw0uVDlbgXoiYmAoSD.71BH_zGQLMRqMTWCWqYZvBAK_FiyGageTSRtA 46QctmIibfWWkOK0qU.Luapf37LVPjyo2WvVMcg3st1f5f0cTB6ow7mF5jfZkqKjltVOC_iNlceV bL1Nn4TGmh94PlEY- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 3 Apr 2020 00:11:28 +0000 Received: by smtp432.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID aea4df3a291358c49f2053f7e5fafa7e; Fri, 03 Apr 2020 00:11:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Unexpected OOM kill on rpi2 while building world From: Mark Millard In-Reply-To: <20200402233359.GA31562@www.zefox.net> Date: Thu, 2 Apr 2020 17:11:24 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <2ECB61DA-1DDA-4BDC-9ABF-5051E7388D20@yahoo.com> References: <20200402233359.GA31562@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 48tgMq5Hg8z3yPP X-Spamd-Bar: - X-Spamd-Result: default: False [-1.69 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.58)[-0.581,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-0.61)[-0.612,0]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[147.66.137.98.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[ip: (4.53), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.65), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 00:11:51 -0000 On 2020-Apr-2, at 16:33, bob prohaska wrote: Two installations of the FreeBSD-12.1-STABLE-arm-armv7-RPI2-20200305-r358659.img image have set up and built -j4 world using a single 64GB Samsung Evo Plus microSD card with a 2.6 GB swap partition. No changes to /boot/loader.conf required. On the third installation, the machine stopped with pid 68521 (c++), jid 0, uid 0, was killed: out of swap space so I set vm.pfault_oom_attempts="-1" and restarted buildworld with -DNO_CLEAN The machine promptly reported pid 93318 (c++), jid 0, uid 0, was killed: out of swap space In neither case were there any "indefinite wait...." or any other warning messages. At that point I set vm.pageout_oom_seq="4096" and restarted buildworld, again with -DNO_CLEAN. Buildworld seems to have gotten past the bottleneck and looks like it will complete, but I'm puzzled, both at the appearance of the trouble, not formerly seen on the Pi2, and on the failure of vm.pfault_oom_attempts="-1" by itself to disable OOMA. Casual observation suggests swap use peaks at a few hundred MB under 12.1 on the Pi2. All three installations were run on the same physical Pi, though of course the microSD cards were distinct. Even so, all three cards are nominally identical and likely from the same batch. The one tangible difference is that the Pi2 is now on a private network, the two earlier buildworlds were on a public network. Can't see how that would matter, however. Thanks for reading, and any insights. bob prohaska _______________________________________________ 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" === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Apr 3 01:37:03 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0BB5126F273 for ; Fri, 3 Apr 2020 01:37:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (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 48tjG92PNPz4VPG for ; Fri, 3 Apr 2020 01:36:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: smQvHDMVM1mIGzXVbDC3mBW9w4xUFV08RCyjjgwGdCIeEJiCJWxtUqBky7qj3jr 2zu6J6UcYPi2q1pc2lOAcbDjis8LC_uCvhivJbXlosO8QUp5WreHQq8.QUSUIN7LVwaJgM5bC1fP rzu70BO6stIMYmd9oMsuqfukT4aRbN6M2E9YP2EnMsWanuoubm1kViqYwd5IgQDOqGGhZBb4zmxq CamfwdyWClX4oWEztN7oFiypaTzqZMXwNkyhGzi_NdyO3YLKqljpcdyoREU0402RC38.qDNUoXWV Ugx3gJ6CzAMeuuHLJBARkWkMQCjul3GWA5FBqoTYuXx__VK5RU5ameNYjgzV4MCqpMQkvR.PbJbi k9qMTBBo.SJ_8vhWdj2uJ3wJd3Hj8pYMw7d0A3a9Z8rgfR.kFwsIt477Hnsd7QBlp3b.ovDiwzOy w9oMsZ.IHiE3MGTv8Hs80PrkZwkPWhzW7Fxh2mk1bO5Hg47ihbFAoHmwG0miNMWGt1wuiXE0x7z1 RtiyNidW.D.NspXgkTOBdYkjZpEJxl6e69FKNv7YrnkZWkvktkmfOIi_IxXip7R8yu4sVuik2aMZ fDrG5.5n1pil3qxWgHY2EG7vQWbDcge8uisP3ZprY73yrB8Spo81X3MxOThhCXrFdYDoyMlGV2tX JjmKCSj6.2GlvCPFP90_PzausGZcWFKrhM2DBDvpQdCbq8XnSSmuvZ_u32k9yToGpyQnvHDg1F03 VHx50P6lRczoL58jjNdJyP5OM9f2.jce4kAIfz5GYAT6m4uL.RuMFZkNvnlV8pTyUI9PGHyFqHIW 1wUIxR3sPL66j92MJirIQCmyrVHiP9r7csexWLBA_YeXGAoGmwJ2RFhXq.DXeGGTAlWTScTkhAWb LLijlgUzIvuHeGoxIKEXhshQ3VE.DB2AsCiDPsYEjum.cLt8TuihSVJN0BlMdtHJ4a3zoRFlXR6n 1m981YuyqNnMR2M0VHmCMTJLwr_BgFSIN02Yb_ZCAt0QOE1GGO_FtL6OYsoS3H4taDY.FSZ1L9nK CpdgM6bj9B5fc.XDpaVgPylAvHD52LiP2EeAfU8znVDVpUxgzC_5SQWSRtC6j.oazUBM5M7CGzOt MJNqlAFfXJaKEGFN.oz1taLi0feiBR15VpAqbdwIcw2MNlmQB9lbp6RcrZ9l3n7f3vABpOhf5SEs JT9JErenI6oV8412aSR8YOvGxD71_vsBo7SZT__PocFLorOb_B3L8TaS5fz9KX0x6DbH9eRiPIEw L5X4LraYdquV2eD4MJZbjOujkESReE.ENLN4WfRhNQVMbnl3bS00.tLh.0rqJvX.SBJW7r5wq3d5 nl3Vck2ViINBJ01M3naThaq90RbcOg27djkldj4JTWX5c1fBxZQRs.KKrMZFALMgwgeTry.g7.cH rrvZhrZMDte3cTAutGqF19J6Uo_iHcUCyqLuuVNALdY__MnvN_g.X Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Fri, 3 Apr 2020 01:36:38 +0000 Received: by smtp424.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c7fda82c192fa50d7c50f07252e72187; Fri, 03 Apr 2020 01:36:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Unexpected OOM kill on rpi2 while building world From: Mark Millard In-Reply-To: <2ECB61DA-1DDA-4BDC-9ABF-5051E7388D20@yahoo.com> Date: Thu, 2 Apr 2020 18:36:33 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <131F8442-02E9-4AAF-B15D-827D775170ED@yahoo.com> References: <20200402233359.GA31562@www.zefox.net> <2ECB61DA-1DDA-4BDC-9ABF-5051E7388D20@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 48tjG92PNPz4VPG X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[206.65.137.98.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[ip: (-5.92), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.65), country: US(-0.05)]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 01:37:03 -0000 {Sorry for the earlier accidental send before even editing the text to reply.] >=20 > On 2020-Apr-2, at 16:33, bob prohaska wrote: >=20 > Two installations of the=20 > FreeBSD-12.1-STABLE-arm-armv7-RPI2-20200305-r358659.img > image have set up and built -j4 world using a single 64GB > Samsung Evo Plus microSD card with a 2.6 GB swap partition. > No changes to /boot/loader.conf required. The following is from an head -r358966 armv7 example of having one 3072 MiByte swap/paging partition: QUOTE warning: total configured swap (786432 pages) exceeds maximum = recommended amount (468832 pages). warning: increase kern.maxswzone or reduce amount of swap. END QUOTE 468832 pages is between 1831 MiByte and 1832 MiByte. 2.6 GB is far beyond the recommendation. I've noticed some variability between armv7 versions for the recommended figure, but not large differences. So your context may not be an exact match. (aarch64 for the same size RAM [1 GiBYte] allows a much larger swap space without complaint: 3072 MiByte does not get a complaint on a RPi3 running aarch64 FreeBSD.) Did you leave things configured such that such a message was produced on the armv7? What did it say (if produced)? What was its recommended maximum (translated to, say, MiBYtes). If you changed the configuration to avoid the complaint, what did you change? Going in a different direction . . . I'll note that stable/12 -r358659 includes: stable/12/contrib/googletest/googlemock/test/gmock-matchers_test.cc which is known to be an issue for OOM activity for 1 GiByte machines, even for -j1 in some configurations. See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241848 My experiment showed that built by itself (as if -j1) on a armv7 with 2 GiByte of RAM it got an Observed: 1146Mi MaxObs(Act+Wir) . (1740 MiByte of swap space, but it stayed all free.) (aarch64 took far more in its analogous experiment.) > On the third installation, the machine stopped with=20 > pid 68521 (c++), jid 0, uid 0, was killed: out of swap space > so I set=20 > vm.pfault_oom_attempts=3D"-1" and restarted buildworld with -DNO_CLEAN > The machine promptly reported > pid 93318 (c++), jid 0, uid 0, was killed: out of swap space (The following is based on head. I've not compared 12-STABLE to be sure how close the match is.) Possible causes of the OOM kill activity include: The swap blk uma zone was exhausted. The swap pctrie uma zone was exhausted. vm.pfault_oom_attempts and vm.pageout_oom_seq make no direct difference for these, as far as I know. Unfortantely, FreeBSD does not specifically report either cause when it happens, but gives the generic "out of swap" type of notice. Your 2.6GB swap space configuration may be making one or both of these exhaustions more likely. For all I know "exhaustion" might included something becoming too fragmented to have individual areas of sufficient size despite total free in the involved one being seemingly sufficient. I'm not claiming that -j4 is even possible to do reliably, much less staying within the maximum recommended by default. But, what the consequences might be for what the warning reports, might put one outside the generally-well-understood range of FreeBSD use. Rare expertise might be involved in understanding what to expect. > In neither case were there any "indefinite wait...." or any other > warning messages. Such messages need not be involved in the uma zone exhaustions. > At that point I set > vm.pageout_oom_seq=3D"4096" and restarted buildworld, again with = -DNO_CLEAN. Which need not contribute to avoiding uma zone exhaustions. > Buildworld seems to have gotten past the bottleneck and looks like it > will complete, but I'm puzzled, both at the appearance of the trouble, > not formerly seen on the Pi2, and on the failure of > vm.pfault_oom_attempts=3D"-1" by itself to disable OOMA. There is no setting that disables all the OOM kill criteria. The two settings together are not enough to disable all the OOM kill criteria. > Casual observation suggests swap use peaks at a few hundred MB > under 12.1 on the Pi2. Is 12.1 the version number? The MB figure(s) seem to be missing from this statement for what is the few hundred MB is under. Did you mean something like 2.6 GiByte (swap), so fairly near 2.6 GiByte but definitely over 2.0 GiByte of swap in use? > All three installations were run on the same physical Pi, though > of course the microSD cards were distinct. Even so, all three=20 > cards are nominally identical and likely from the same batch. buildworld buildkernel would still have lots of variations in the relative timing of activities during the various builds. Such could matter to the uma zone usage, for example. If things are marginal for working, such variable results might well be expected. > The one tangible difference is that the Pi2 is now on a private > network, the two earlier buildworlds were on a public network. > Can't see how that would matter, however.=20 Note: I have a RPi2B V1.2 with armv7 FreeBSD ( head -r358966 ) doing a -j2 buildworld buildkernel with top watching, top having my changes that track and report some maximum observed figures. Maximum Observed swap space usage is reported, as it MaxObs(Act+Wir). But it likely will be a day or two before it completes, presuming it is successful. (For reference: It is configured like the RPi3 was for that -j4 test that I reported to you earlier, other than the swap partition being set to 1800 MiByte and the use of -j2 for armv7.) =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 Apr 3 22:35:27 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E9EDB274DE1 for ; Fri, 3 Apr 2020 22:35:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (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 48vFB55y6tz4ZVn for ; Fri, 3 Apr 2020 22:35:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: xL5HazIVM1l.SoQ6OxynFTVQJkjKVfqkree9PXIM_kkSpRBf6QKo0h684nAH_sw s6TEItImuZQOgFoAaqA0oYibgQmsvIcXyot7y6EzrOxJ9aLIHlgsICBnt7LTv_XsRtonihtMwaxy dSw9tX_mcUT5paqogsAWztGdlledLlButCR3_abEydwor5kYwxoajQYxbHm1XfJ7cByUHtAqGjF9 _ds3uXgpYweMLok.fcWb0X3xBcMNcpg6E8chDCTmIHxQe.b0aQCM6h8QPKhgz1we.L04nkNKNRdc DDLj3C_XRdhIgeYdAT2pbbS3M7kkixMcg1l4Kr_SCiF8UWoOWQPmxiJRIX_r4WuikKxz.kpE9TXb vEXgrXBJOiUw0DJLYuE9X8aK2eoHd.UywGEeCO9wa23DTUKsqULgUKe0xVHrf_bnJYYfgd109IHG NsHmVIiJbKyluWYV6d2Smv3C3VFD1xQNgGHNULeaB6461jtIdklj5BWIanOZgCrf9TZUy4vAAWSH dwt3gY8qjmjqUK3CeFk5fc6qtsUa4ofTOo_2v.TBAxVqJsdvAQODYEfCfq5LNj_8tJl2PQlxl0Ow F4D.H97A2DeCSHyuj16jTWjXDiPV.EnRYlMmNozjkTSHk6pgIPXRGy5jgPM6X_fnqiAdG8c11agI PBp9Fqr1GvBryLzhM9TXXXO57POxpTebK0dDgiFv2zqnLQfxP5U9jHIYMwlwIefDiF8010YI9ylF jQzX8UIjoieI2VCvMFYsYdlclZL10KJgImNz.i.mTV0lN_1mdi2cCuAXq34i8Ooqzgj9SqeDcw9U xZIn.Z28kFVLhTZCJVI_zQu.we_rlKtV77BtUyaoo_AxXmd0JXBnDPsOahCQLhj11lRc01BEj9c9 cb2Wdf6mwSL8WWyDyfh9KH_FGmECH804yNNYl76zTYbkLFVeNDQJuQYHOuoOQjbGHjqGrW7iwFPf rG31OO3FNZWkjMbj4UsPJ3X5nlwZtIPFzXsouZyyW1PdHWzE.c91OHEvVUzGZEYSTdQZkDFN0SOs P.BGOjYqtJ9z4GeRbuAW4hriuM_Crf_j9AftjGW3.hNRg_KXFTyaesHoJmHJsGAUviLmju69VJW7 munRLrLfGLSfzSmU3IhnGGYGOra3Zlf85eF..tnYoVYGgvyVwtgHeODJSG0q1WI944rXia1exHBt NDXprgNo7fWq4ezsI0MtLBkQF5uz4cr1FXQObBWtxGJ6XpjEHaxiaxvMdnsa07y6Cq.Gy3DEueza uJf8W1s3dIc6R6z44ADAmpKAIT83XXf4L3JwJjD3y0qTR_Rfn47b81nKQu2UpFWSOCSi71T2zhpk jwLkHj_uZEhjlfmhqtcy0qjHK81F9rtzioxyhyX1dl212OPWDJD.jjUORzxZzgW5A2j9rKO0dpTF 7Rhsa9frw7n9D_R9Qi5UQSFOXTC0euz8H7lUSSfPUIosCZZVKtEdmopg- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Fri, 3 Apr 2020 22:34:57 +0000 Received: by smtp414.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f2a77cc93db803ca13c22ba1f758e3c4; Fri, 03 Apr 2020 22:34:54 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Unexpected OOM kill on rpi2 while building world From: Mark Millard In-Reply-To: <20200403163313.GA33978@www.zefox.net> Date: Fri, 3 Apr 2020 15:34:53 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <42583CC7-4650-4F17-8E22-78B02CD47832@yahoo.com> References: <20200402233359.GA31562@www.zefox.net> <2ECB61DA-1DDA-4BDC-9ABF-5051E7388D20@yahoo.com> <131F8442-02E9-4AAF-B15D-827D775170ED@yahoo.com> <16E9257C-D400-4DF7-BE6C-4D1EA2BA1653@yahoo.com> <20200403163313.GA33978@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 48vFB55y6tz4ZVn X-Spamd-Bar: - X-Spamd-Result: default: False [-1.87 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.71)[-0.713,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.66)[-0.659,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (3.86), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.65), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[31.69.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[31.69.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 22:35:28 -0000 [Some of this exchange occurred off-list. This brings it back to the list.] On 2020-Apr-3, at 09:33, bob prohaska wrote: >=20 > On Thu, Apr 02, 2020 at 07:23:22PM -0700, Mark Millard wrote: >> [Not sent to the lists.] >>=20 >> On 2020-Apr-2, at 18:36, Mark Millard wrote: >>=20 >>=20 >>> {Sorry for the earlier accidental send before even editing the >>> text to reply.] >>>=20 >>>>=20 >>>> On 2020-Apr-2, at 16:33, bob prohaska = wrote: >>>>=20 >>>> Two installations of the=20 >>>> FreeBSD-12.1-STABLE-arm-armv7-RPI2-20200305-r358659.img >>>> image have set up and built -j4 world using a single 64GB >>>> Samsung Evo Plus microSD card with a 2.6 GB swap partition. >>>> No changes to /boot/loader.conf required. >>>=20 >>> The following is from an head -r358966 armv7 example of having >>> one 3072 MiByte swap/paging partition: >>=20 >> Actually: head -r359427 . I've progressed the FreeBSD >> version I'm using since the RPi3 results that I'd >> reported. >>=20 >> I do not see needing a world wide message for >> this before the build results are available. But >> Hopefully, this will help remind me to make the >> correction then. >>=20 > Agreed. >>> QUOTE >>> warning: total configured swap (786432 pages) exceeds maximum = recommended amount (468832 pages). >>> warning: increase kern.maxswzone or reduce amount of swap. >>> END QUOTE >>>=20 >>> 468832 pages is between 1831 MiByte and 1832 MiByte. >>> 2.6 GB is far beyond the recommendation. I've noticed >>> some variability between armv7 versions for the >>> recommended figure, but not large differences. So >>> your context may not be an exact match. >>>=20 >>> (aarch64 for the same size RAM [1 GiBYte] allows a much >>> larger swap space without complaint: 3072 MiByte does >>> not get a complaint on a RPi3 running aarch64 FreeBSD.) >>>=20 >>> Did you leave things configured such that such a message >>> was produced on the armv7? What did it say (if produced)? >>> What was its recommended maximum (translated to, say, >>> MiBYtes). >>>=20 > No changes to swap configuration, in the past no problems emerged. > The warning is: > warning: total configured swap (675200 pages) exceeds maximum = recommended amount (312480 pages). 312480 * 4096 / 1024 / 1024 =3D 1220.625 MiByte This is far less than what head reported as its recommended maximum for the RPi2 V1.2 using head armv7 FreeBSD (between 1831 MiByte and 1832 MiByte someplace). I'll stick in a note here about some context: buildworld buildkernel takes long enough for nightly jobs and such to also run with the build still going on. This can be another example variability in memory handling that could contribute to OOM criteria being met. >>> Going in a different direction . . . >>>=20 >>> I'll note that stable/12 -r358659 includes: >>>=20 >>> stable/12/contrib/googletest/googlemock/test/gmock-matchers_test.cc >>>=20 >>> which is known to be an issue for OOM activity for >>> 1 GiByte machines, even for -j1 in some configurations. >>> See: >>>=20 >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241848 >>>=20 >>> My experiment showed that built by itself (as if >>> -j1) on a armv7 with 2 GiByte of RAM it got an >>> Observed: 1146Mi MaxObs(Act+Wir) . (1740 MiByte >>> of swap space, but it stayed all free.) >>>=20 >=20 > I'm confused, was this on a Pi? armv7, not a RPi* but an OrangePi+ 2e (OPi+2e). The major difference for the issue is the amount of RAM. (I did not have RPi2 access at the time.) In fact, I use the same microsd card, USB SSD, root file system, msdos file system, and a common swap partition on the RPi2 V1.2. I do switch between boot.scr files when I move the media between machines. The RPi2 ignores the dd'd material on the microsd card. The same media would work in the RPi2 V1.1 but that microsd card slot has a broken retention mechanism and ejects the microsd card as I take my fingers away. I've no access to another RPi2 V1.1 . > My observation was casual > and I think peaked at about 700MB. Alas, no logging in progress.=20 For: stable/12/contrib/googletest/googlemock/test/gmock-matchers_test.cc Dimitry Andric reported clang90 with assertions disabled used: "maxrss of 1755320, so ~1714 MiByte". So not much different than my figure (but measured a different way). With -j4 active, you would probably need the 3 other cores to be waiting for something to do during the big memory use time frame of this compile in order for swap space use to be only 700 MiByte over that time frame. (I'll note that this file and related files were added to stable/12 in -r344078 , somewhat over a year ago. It was copied from vendor/ tp contrib at -r344082 and integrated in -r345203 and -r348138 [2019-Mar/May].) > The OOMA kills seemed to be toward the end of the "building libraries" > phase but before ld became active. contrib/googletest/googlemock/test/gmock-matchers_test.cc would be compiled later than in the libraries part of the build. So you likely saw an earlier local-peak in the memory use. >>>=20 >>>=20 >>>> On the third installation, the machine stopped with=20 >>>> pid 68521 (c++), jid 0, uid 0, was killed: out of swap space >>>> so I set=20 >>>> vm.pfault_oom_attempts=3D"-1" and restarted buildworld with = -DNO_CLEAN >>>> The machine promptly reported >>>> pid 93318 (c++), jid 0, uid 0, was killed: out of swap space >>>=20 >>> (The following is based on head. I've not compared >>> 12-STABLE to be sure how close the match is.) >>>=20 >>> Possible causes of the OOM kill activity include: >>>=20 >>> The swap blk uma zone was exhausted. >>> The swap pctrie uma zone was exhausted. >>>=20 >>> vm.pfault_oom_attempts and vm.pageout_oom_seq make no >>> direct difference for these, as far as I know. >>>=20 >>> Unfortantely, FreeBSD does not specifically report >>> either cause when it happens, but gives the generic >>> "out of swap" type of notice. >=20 > Ok, that seems like a plausible candidate, but would setting > vm.pageout_oom_seq=3D"4096" > subsequently suppress the OOMA kill?=20 vm.pageout_oom_seq does not change being unable to allocate from either of the 2 memory areas (uma zones), other than having possibly prevented some prior potential OOM kills. So: No. As near as I can tell exhausting either of these uma zones means that the kernel can no longer manage the swap space, short of killing processes to free up the related zone contents for other uses. Nothing ever disables all the OOM kill criteria, only specific aspects of the overall criteria. (As far as I know anyway.) The alternatives are things like forced reboots, deadlocks, and such under various conditions. >>>=20 >>> Your 2.6GB swap space configuration may be making one >>> or both of these exhaustions more likely. For all I >>> know "exhaustion" might included something becoming >>> too fragmented to have individual areas of sufficient >>> size despite total free in the involved one being >>> seemingly sufficient. >>>=20 >=20 >>> I'm not claiming that -j4 is even possible to do >>> reliably, much less staying within the maximum >>> recommended by default. But, what the consequences >>> might be for what the warning reports, might put >>> one outside the generally-well-understood range >>> of FreeBSD use. Rare expertise might be involved >>> in understanding what to expect. >>>=20 > Up to now -j4 buildworlds were successful on the Pi2, with > minimal use of swap. 12.1 uses clang9, which seems considerably > larger than former versions. Perhaps that's part of the trouble.=20 stable/12 -r356460 (2020-Jan-7) switched to llvm 9.0.0 . If all your prior 12.x activity predates that, then, yea, things are likely different this time around. Interestingly, gmock-matchers_test.cc predates that. If you used between -r348138 and -r356460 without such large memory use, clang 9+ would be contributing for the subset of issues tied to gmock-matchers_test.cc . (Even though gcc uses even more RAM for the file, as I understand.) >>>> In neither case were there any "indefinite wait...." or any other >>>> warning messages. >>>=20 >>> Such messages need not be involved in the uma zone >>> exhaustions. >>>=20 >>>> At that point I set >>>> vm.pageout_oom_seq=3D"4096" and restarted buildworld, again with = -DNO_CLEAN. >>>=20 >>> Which need not contribute to avoiding uma zone >>> exhaustions. >>>=20 > Even so, buildworld completed.... I thought you said you were having to restart things. That gets a likely greatly different mix of what is running at the same time in the detailed timing. Peak memory use times across the cores likely would be different after each restart, making OOM activity related comparisons problematical. >>>=20 >>> There is no setting that disables all the OOM kill >>> criteria.=20 >=20 > Ok, this is a surprise, I gathered that > vm.pfault_oom_attempts=3D"-1"=20 > turned off all OOMA activity. >=20 >>> The two settings together are not enough >>> to disable all the OOM kill criteria. >>>=20 >=20 > Yet, using both together seems to have suppressed OOMA. I thought you said you were having to restart things because of OOM kill activity, even with both set. That would mean that OOM kill activity had not been suppressed. >>>> Casual observation suggests swap use peaks at a few hundred MB >>>> under 12.1 on the Pi2. >>>=20 >>> Is 12.1 the version number? The MB figure(s) seem to be missing >>> from this statement for what is the few hundred MB is under. >=20 > Yes, 12.1 is the version number from the snapshot name. >=20 >>> Did you mean something like 2.6 GiByte (swap), so fairly near >>> 2.6 GiByte but definitely over 2.0 GiByte of swap in use? >>>=20 > Sorry, the few hundred MB was total swap use. IIRC I saw ~700MB in > use very briefly. Roughly 30% of 2.6GB.=20 Wired memory is not swapped and there are possibly other overheads. A quick estimate is that you had between 700 MiByte and 800 MiByte of RAM in use for the CPU time takers at the time of the around 700 MB swap space use. So, something like 1400 MB to 1500 MiByte overall, counting related swap space as well. In other words, having, say, 1100 MiByte to 1200 MiByte of swap space would have been more than sufficient for that stage. This means that seeing if you still have -j4 problems at that stage with the smaller swap space could be a useful experiment, even if there are later problems with the swap size. (You may have to risk eventual deadlock if you do not stop it after the stage in question.) Testing, unfortunately requires repeating from the same initial conditions, probably always starting a from- scratch build. (Not that this gives full repeatability.) >>>> All three installations were run on the same physical Pi, though >>>> of course the microSD cards were distinct. Even so, all three=20 >>>> cards are nominally identical and likely from the same batch. >>>=20 >>> buildworld buildkernel would still have lots of variations >>> in the relative timing of activities during the various >>> builds. Such could matter to the uma zone usage, for example. >>> If things are marginal for working, such variable results >>> might well be expected. >>>=20 >>>> The one tangible difference is that the Pi2 is now on a private >>>> network, the two earlier buildworlds were on a public network. >>>> Can't see how that would matter, however.=20 >>>=20 >>>=20 >>> Note: >>>=20 >>> I have a RPi2B V1.2 with armv7 FreeBSD ( head -r358966 ) >>=20 >=20 > That might be a significant difference. My pi2's are v1.1,=20 > unlike the later version in that they're (I think) obligately > armv7, with an older processor. =20 Older processor: yes. But, if I understand right, armv7 FreeBSD makes very little internal distinction in the kernel for the two, including for relevant issues to the OOM kill criteria and activity. (Those who know more can correct any misimpression that I have.) >> Nope: head -r359427 again. Sorry. >>=20 >>> doing a -j2 buildworld buildkernel with top watching, top >>> having my changes that track and report some maximum >>> observed figures. Maximum Observed swap space usage is >>> reported, as it MaxObs(Act+Wir). >>>=20 >>> But it likely will be a day or two before it completes, >>> presuming it is successful. >>>=20 >>> (For reference: It is configured like the RPi3 was >>> for that -j4 test that I reported to you earlier, >>> other than the swap partition being set to 1800 >>> MiByte and the use of -j2 for armv7.) I'll list the results later in this reply. >=20 > Back in late January you observed an error in the code handling > the setting of vm.pfault_oom_attempts=3D"-1" and reported it under > the subject line: Re: OOMA kill with vm.pfault_oom_attempts=3D"-1"=20 > on RPi3 at r357147 (a vm_pfault_oom_attempts < 0 handling bug as=20 > of head -r357026) >=20 > Is there any chance the bug survived in the `12 branch? The change in -r357026 that introduced that issue was not MFC'd and was not labeled as intended to be MFC'd: it is 13+ specific. So it is not involved in stable/12 issues. Going back to: >>> (For reference: It is configured like the RPi3 was >>> for that -j4 test that I reported to you earlier, >>> other than the swap partition being set to 1800 >>> MiByte and the use of -j2 for armv7.) It completed fine, with my odd top variant showing: Mem: 758544Ki MaxObsActive, 189972Ki MaxObsWired, 928060Ki = MaxObs(Act+Wir) Swap: 527388Ki MaxObsUsed But it turned out that the high memory use time frame for gmock-matchers_test.cc was matched with a very low memory use activity. So the 527388Ki MaxObsUsed is on the low side for figuring out having margin to cover variability in what the paired activity might be. Other pairings could easily have used over 700 MiByte more (say, linking clang), and so have reached in the realm of 1400 to 1500 MiByte for swap, leaving, say, 400 MiBytes to 300 MiBytes unused. (I happened to be there to watch the top display over the period of time at issue, seeing the growth to 527388Ki MaxObsUsed.) (Unfortunately, 1400+ MiByte is more than the about 1200 MiByte your context gives as a warning for the recommended maximum. This suggests that even -j2 has risks for total swap usage in your context but the stable/12 vs. head consequences are not obvious for such a comparison.) Personally, I'd not want any small to non-existent potential swap space margins from trying -j3. So I'll not try such: -j2 at most for the 1800 MiByte swapping/paging space for armv7 head RPi2 with only 1 GiByte of RAM. (More on the 2 GiByte RAM OPi+2e: 2nd swap file to enable when I need it in that context.) I'm not claiming that -j3 would usually run out of swap space for the RPi2. I'm just trying to make it highly unlikely that I'd ever have a case of running out of swap space: I want vm.pfault_oom_attempts=3D"-1" to be reasonable to use, without noticeably risking deadlocking the armv7 in the 1 GiByte RAM context. With 2 GiByte of RAM the OPi+2e allows 3072 GiByte of swap space without the warning as well, making -j4 reasonable in that context. FYI for the -j2 RPi2 v1.2 based build: Ended: 2020-04-03:10:46:52 Started: 2020-04-01:20:59:24 So somewhat under 38 hours for the from scratch build, same sort of detailed selections as for the earlier aarch64 RPi3 example. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Apr 4 08:36:36 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ADCFB2A5632 for ; Sat, 4 Apr 2020 08:36:36 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [37.187.123.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tignes.restart.be", Issuer "CA master" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48vVWl5grxz4CYD for ; Sat, 4 Apr 2020 08:36:19 +0000 (UTC) (envelope-from hlh@restart.be) X-Comment: SPF check N/A for local connections - client-ip=192.168.25.127; helo=restart.be; envelope-from=hlh@restart.be; receiver= DKIM-Filter: OpenDKIM Filter v2.10.3 tignes.restart.be 48vVWY4K4SzDv Received: from restart.be (norquay.tunnel.bel [192.168.25.127]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 48vVWY4K4SzDv; Sat, 4 Apr 2020 10:36:08 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:a:f40b:1:1:0:1]) (authenticated bits=0) by restart.be (8.15.2/8.15.2) with ESMTPSA id 0348a5MH006340 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=OK); Sat, 4 Apr 2020 10:36:06 +0200 (CEST) (envelope-from hlh@restart.be) X-Authentication-Warning: norquay.restart.bel: Host morzine.restart.be [IPv6:2001:41d0:a:f40b:1:1:0:1] claimed to be morzine.restart.bel Subject: Re: FreeBSD 13.0-CURRENT #0 r358465 on rockpro64 and RTC To: Greg V Cc: "freebsd-arm@freebsd.org" References: <2ff55aa2-b919-3f2b-715b-a97bb0debe21@restart.be> <71529742-60eb-4301-808a-d9dd3902d50e@localhost> <95809d4d-9375-70b7-df83-1ba614ad6a8a@restart.be> <1bb31f7d-2fef-3c98-5243-4818be9c8de0@restart.be> From: Henri Hennebert Message-ID: <62980dcd-468a-8df5-608a-5a1fc981a3d5@restart.be> Date: Sat, 4 Apr 2020 10:36:05 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <1bb31f7d-2fef-3c98-5243-4818be9c8de0@restart.be> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 48vVWl5grxz4CYD X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.21 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[restart.be:s=tignes]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:37.187.123.11/32]; NEURAL_HAM_LONG(-0.99)[-0.993,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.995,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[restart.be:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[restart.be,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.78)[ipnet: 37.187.0.0/16(1.85), asn: 16276(2.04), country: FR(0.00)]; ASN(0.00)[asn:16276, ipnet:37.187.0.0/16, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2020 08:36:36 -0000 On 3/8/20 9:18 AM, Henri Hennebert via freebsd-arm wrote: > On 3/7/20 12:06 PM, Henri Hennebert via freebsd-arm wrote: >> On 3/6/20 3:20 PM, Greg V wrote: >>> >>> >>> Mar 6, 2020 3:21:03 PM Henri Hennebert via freebsd-arm : >>> >>>> Hello >>>> >>>> I am running FreeBSD 13.0-CURRENT #0 r358465 on a rockpro64 4GB with a >>>> RTC BACKUP BATTERY HOLDER - CR-2032. >>>> >>>> (u-boot from https://wiki.freebsd.org/arm64/ROCKPro64 to run with the >>>> 4GB and with hw.ncpu=4 in loader.conf) >>>> >>>> I tested the 3V of the battery. >>>> >>>> It seems that the RTC is not managed for now (time lost after power >>>> off), is it correct? >>> >>> Hi, the RTC driver is not merged yet: >>> >>> https://reviews.freebsd.org/D22692 >>> >> I try it and it work for me! >> > Strangely after a night off time is lost :-o I change the battery (Duracell 2032). All was well but after 3 days the voltage drops from 3.2 to 2.98 V and the RTC lost the time and date. So it's a hardware problem. > > Henri > _______________________________________________ > 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" >