From nobody Mon Jun 7 13:02:30 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C5C5A950820 for ; Mon, 7 Jun 2021 13:02:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FzD6t538kz4sDv for ; Mon, 7 Jun 2021 13:02:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 95F7D16382 for ; Mon, 7 Jun 2021 13:02:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 157D2U7T036395 for ; Mon, 7 Jun 2021 13:02:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 157D2UNu036394 for freebsd-arm@FreeBSD.org; Mon, 7 Jun 2021 13:02:30 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 256468] reaching a breakpoint on an armv7 binary on arm64 causes a SIGBUS Date: Mon, 07 Jun 2021 13:02:30 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: fuz@fuz.su X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256468 Bug ID: 256468 Summary: reaching a breakpoint on an armv7 binary on arm64 causes a SIGBUS Product: Base System Version: 13.0-RELEASE Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: fuz@fuz.su It appears that debugging armv7 binaries on arm64 is broken. I've created an armv7 jail on an arm64 FreeBSD 13.0-RELEASE system, entered= it, and install gdb from ports. Then I executed an arbitrary program under gdb, set a breakpoint and let the program run (a simple way to do this is to type "start"). The breakpoint is reached and gdb informs me that a SIGBUS was delivered to the program; attempting to continue after this breakpoint is impossible. I suppose there's something wrong here as debugging on a native armv7 system seems to work fine. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Jun 7 18:40:16 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 94A4AE59E65 for ; Mon, 7 Jun 2021 18:40:23 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4FzMck3hSSz3qTD for ; Mon, 7 Jun 2021 18:40:22 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 157IeGtF011284 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 7 Jun 2021 11:40:17 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 157IeGIM011283; Mon, 7 Jun 2021 11:40:16 -0700 (PDT) (envelope-from fbsd) Date: Mon, 7 Jun 2021 11:40:16 -0700 From: bob prohaska To: marklmi@yahoo.com Cc: freebsd-arm@freebsd.org Subject: Re: Strange u-boot behavior Message-ID: <20210607184016.GA11184@www.zefox.net> References: <20210606043152.GA94545@www.zefox.net> <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> <20210606160040.GA97697@www.zefox.net> <407FDEDF-8595-4F20-91B9-B475CCE95B39@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <407FDEDF-8595-4F20-91B9-B475CCE95B39@yahoo.com> X-Rspamd-Queue-Id: 4FzMck3hSSz3qTD 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 [-1.10 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; 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]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, Jun 06, 2021 at 10:34:26AM -0700, Mark Millard via freebsd-arm wrote: > > > On 2021-Jun-6, at 09:00, bob prohaska wrote: > > > > > It's a dual-boot system, with a complete FreeBSD-current install > > on both USB and microSD storage. > > How do you control which device provides kernel+world > if both have a kernel_world? > If the machine is powered up and not touched, it boots from the microSD card. If boot is interrupted at the u-boot prompt it's (was) possible to issue a usb reset command, at which point the external USB hard drive was discovered. At that point issuing a run bootcmd_usb0 command would boot kernel and mount world from the USB device. > I suggest trying the same vintage that is on 13.0-RELEASE's I've written the 13.0-release image to a microSD card and tried that. It reports a version of U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000) Stopped at the u-boot prompt and given the usb reset command, zero storage devices are found. However, usb tree still reports USB device tree: 1 Hub (480 Mb/s, 0mA) | U-Boot Root Hub | +-2 Hub (480 Mb/s, 2mA) | +-3 Vendor specific (12 Mb/s, 90mA) | FTDI FT232R USB UART AM00FGTR | +-4 Vendor specific (480 Mb/s, 2mA) | +-5 Mass Storage (480 Mb/s, 0mA) ASMT ASM105x 12345678D558 The mismatch between what usb reset and usb tree report strikes me as extremely puzzling. As an experiment, I tried booting with no microSD card installed at all. This got confusing; u-boot still came up, apparently from the USB hard drive. The USB disk is still not found by usb scan, but it is recognized by usb tree. As a final test I tried connecting a monitor that had been used with this Pi previously. The monitor's presence made no difference, the display looked normal. A hands-off boot to single user is successful from the microSD card. It's possible to see and access the USB hard drive. At this point I'm beginning to suspect some obscure mischief with the USB-SATA adapter, based only on earlier intermittent problems detecting the USB hard drive. In those cases a few repeats of usb scan found the disk and allowed booting from it. Thanks for following this goose chase! bob prohaska From nobody Mon Jun 7 20:09:52 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7F04895B9C2 for ; Mon, 7 Jun 2021 20:10:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (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 4FzPc86NkXz4VbJ for ; Mon, 7 Jun 2021 20:10:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623096598; bh=RD7gMDGRCnkCtcusI/mhLuN3qSGk6en90OhyU8RF1HA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=LcXV2/8c+ZcpC3SYnYDcLY7/sFJEXw5wxZS67IBQD7nDip5AeCnqWxRrpwpfOokBE6k9Ol0L4Pg6xlWmFSbeBAg7YrGoVoY0dL/QIigl/3ARS/HrJb/yGQft952yEaWC+ncNBo1OvhCZFfrjGtEui7hzG+l0kPqqHebKuPPZnff1tkiQVxfRMla50XSV2WqBR/OPNzYncum5Rz/72R6VPYRKOHjFJA0cLRHlDLG3koQA7IUPicMFfGtroqg/KNbTE76jIFGBRD/eUoN8KS2JHI8on7uwBDxL+wWNgtItnk148KL27ROiHZRRyG35Zc+/m9D27uF32SW1uNLn1QFjdA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623096598; bh=zCt1sfYFXSqyBnOaRgC9O4uwR+ksrQ4CWiTkG8Ah1IB=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ni5wxp5d0ZqcUjvCgsNwSGbrnl+u2+a/IxATjJ6Zo4O38vJB8sppVoG8T8xpjCOUY3EKSiX9HeMTVPWP0DYKrBA4qJTdb7T1s84qpD7b3M0yplaPNHe3PgY5+UHA2AqNvLkXH3cKMILOT+wrfVMijVhX0Y3FrX/f4ctgRTLoaeX6IP1VjMnWzPKSpU0LSH9jSk4YboTgSvVE9SBkOWh7GdAsbdF9kLLWvTN17P+a83RvVVh43XkWyu58eIGeSwGMzx/8g8RXWId+CnrfGP+LNMWzRoduxst1LYylg0zoRCCL1btzTWL2uByYys9QsG3hU3Xp4ex6jBQxVDraeLe10Q== X-YMail-OSG: lVgkzUoVM1mwlHAyKH4ZoM4B7a2y7CGyLwOTpjPhnRAMqJqepolDqST0whwwxT_ jBZk25VBYz.iT419CkyvfDikFVkkVUh9jtt5UuVMePw91HUU5a7VXfOhZGmS2rYkxwgvJu4WWuMo WFhrSDuOHs5Xy0pnlpyxaEmzQy8cUoqF43L_GpHpD6x29TvKu18othSplKzNAioJ4SJWMKUrHqLn BAmTsTO37nxxiWElbJEnMb1Ik.fCLQmSWj8P3sGsLGjg7ZkKNV6uhKJWMMjq7aoiJ2b9VRsBElNx bagvzGmxKEYjs3LdokbFkv2GpVLchDzhHC.vlgINd0AkKMbml5PeiAdD91pMXFdm5_Nc4PIhB3d0 IBNj.57Q2qBZIgsdAuFCMPCRs14YFZAqDebZHQWbp9YQZ6YhyqZd86kJLBBrJvGX0u0MXdy3vvtK pd628MPck1cdjiOgF.8GtKntmBPSLiGogEUuPchQUR1AW.gA0OXeY6GAZ7deXz1ppnVO2VqejPh5 pLG_ubsddZWMHP6vkMj8xGkp_fLK8DlG4Yt7AJf9_S8LFGmylJa2zdNVapP.pebH_8O6ZwsUi5BC z.sUHt1W2XehC7BhOk5fiT8_1OSeuQJNpeHAy5CUMb1hNF8TZ.IVH.eI_.S2m4xDmmxfw4qoKeXv SEY.AlxBkvMRgSqx.O.zmUln9KNVBkLqzfaAzhRbiWMBOzS729PutYSqeebfWcr51Rmjd3cPH6_c Mffb0RsG2FyhhZrueYiAyncvWW7fROfsUP9mq0EgN5uMwq0vICFCLjTpHyNw_DcxX24SIBxrKd.2 TGnWK_MZfSgytEuq4GSqF_0HcJXK4QaDlKgUHGMvOGqIcBp06wL0l5j6m.0BFcI.OiiWiMityp_F Vsv0owA48TFy.eQNp6q8E3_KqxA0ebQ_jUFcrZ_nUlXtbaVPLxlIvIlkPe20PMY7qUgftHaqU8ES mqfPihjeJK2P1aFSoi2hDSNM..zywhhKWKdgU.T77X0C0ZWbZpR.YxFKqiZFoi1qQris9HBWpGSO _hp_.YUw4m5.rWdr0laH7jyThv7qi4_QVhx.iC_h3IFvfIQPKJ4qZ6FwvfppEJlQ.RmmNPtg7DME bdnTuYwrzV2H20epaKbe9AfMdE4r_toB6sAKYf9wnvKYhMEyj.ln9ipYTCaH9JQ11lK1DBvj6JJA 3gYHmeBxeGhZ5UZSuK87bDk0Y0VAtFIRveVzthzkh0bG241WH0DKQe3m_UH5aN66b0H7cwlDAZP5 _m._lLYgbOQxSqfdDIfotpaDDKEvM_hgbbrrFAEY4iCLzihmjuopfQ3YcY.bkP185al7vP.I_zBZ o2_KuIh3sqvoelaz6_7EJLGRrms5DXEwdgklwV0ts7vu4uuky6teno7mK.pmFLNStAqTd6.haE_D JcR6uatyAlD3zRoUgHbFpNySukYnhyz1ypNpMAfpVHZd1n3W7IGYH1wQWKahNbf9S2xNJmBa8dgZ MsoODUPyGHXKoC7SCpfBYe6F_uJ_vBYnrmY.tjFycjgRTrzW5WTcJNh8AGQ2__hP8XSgQeaLV1ba ShNXoxl8As78r0c0YtQi1vspULdOHRp6WRKaawg.bFLOqqLTM3XMcCVUC2JsfCKn2Hy3xglgqHmV 8GDcKCRYuoZw1sNhBb_nDs03hgvz_jsVVbob2QzRBC96rdiRwQNEcVZW3Mw2z_EY30DCfHSuxx.i zOJZqp91T0kJaEy4CTP0mAMWp.I7iam8UVYtrZmCnwfTuOZSmnY1riJTBSC.dUDWY7Nq5NkBGdGr TRH9yH4VAttkY5gTZv49YECCZRoVbcJb2t5A_QBd.ntSvqpKFAiRvqUmuTcyRTq3oIaDnqaAGjFo 3ZUghPZzzKgW5NmieQbBxQ1yrq2ZJsls0vSkYiViSyE6kgAkIf1FHa1GMCDFXA5gLr0mTg6C66Zl TvPb93O3J5QVTYaDb0KEdx5Ieb_nLzeGmRbJguyTDDLfv4oHihQUC2HV9ADlzgoI2oGUMr2sBcy8 3yrg9lSacoSx5TiY1t8cEmZFk29.8Cx2ugaH821TTKgXtJFpYnFVRoj_H2wpkdZxZ84oUrbakR9z IQgMa7p_xQ68ucnptI_lWxQQ8uvW28nRijIHMmNG2ts.wRDz6WnEhFTZDDBrAhUgf0vG5PO9LkdK ZoGjtiNVaK2YCfPKCAyaewYSx52RMOMAN1aDTIvGIImsctTKdytXY7P3BWTFQW6FZUuYSoRfXPG_ Kw8.3lIxI_.LiefS4gN_6AYPrekUIy0mc81YX5PpEVYlJT54d0jQgt7LLde1AMZH1KZXWdX4jCwH 2vl2LBcQqNDj7gvgiJEImNJYJA1.p11AovGkIPH9C97YKdrAA3T66CDVwsSZ3PSa68WEOpOHFRbL Z1Fou1IMr9Vth456kBm0jLPaT12uK80q7eoCTWbw9.OwSaySatk0isA1ddv1mUQ7jqy0nLC3DqgU 7XqCybi9j2D99wtJ8MA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 7 Jun 2021 20:09:58 +0000 Received: by kubenode518.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID eb9335f46370b89fd79642d158f1c164; Mon, 07 Jun 2021 20:09:54 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Strange u-boot behavior In-Reply-To: <20210607184016.GA11184@www.zefox.net> Date: Mon, 7 Jun 2021 13:09:52 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210606043152.GA94545@www.zefox.net> <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> <20210606160040.GA97697@www.zefox.net> <407FDEDF-8595-4F20-91B9-B475CCE95B39@yahoo.com> <20210607184016.GA11184@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4FzPc86NkXz4VbJ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-7, at 11:40, bob prohaska wrote: > On Sun, Jun 06, 2021 at 10:34:26AM -0700, Mark Millard via freebsd-arm = wrote: >>=20 >>=20 >> On 2021-Jun-6, at 09:00, bob prohaska wrote: >>=20 >>>=20 >>> It's a dual-boot system, with a complete FreeBSD-current install >>> on both USB and microSD storage.=20 >>=20 >> How do you control which device provides kernel+world >> if both have a kernel_world? >>=20 >=20 > If the machine is powered up and not touched, it boots from the > microSD card. If boot is interrupted at the u-boot prompt it's > (was) possible to issue a=20 > usb reset > command, at which point the external USB hard drive was discovered. > At that point issuing a=20 > run bootcmd_usb0 > command would boot kernel and mount world from the USB device.=20 I see I force to to tell me what you had already reported. Sorry for that. As for your manual usb commands . . . Looking around on the web I see reports of the: Request Sense returned 02 04 01 (and the matching Device NOT ready) mean that the problem will occur and that repeating usb start or usb reset again until it does not report that leads to things working. But I've also seen other, more complete information indicating that there is a environment setting (showing an example value): usb_ready_retry=3D5 to set up before the usb restart (or usb start) command. It deals with the issue more explicitly for slow devices. Another one is (units: msec): usb_pgood_delay=3D10000 There are also device that have problems with large transfers and require extra protocol to deal with transfer problems before they will work again, U-Boot not doing that. usb_max_blk=3D20 sets a old historical value that generally just works for such devices form what I read. I see no indication that other usb commands are worthwhile until one has avoided that "Request Sense returned 02 04 01" message for usb reset (a.k.a. usb start). The reports of this sort of thing are not limited to RPi's and go back to at least 2014. If I understand correctly, usb_ready_retry and usb_pgood_delay and usb_max_blk are part of normal U-Boot builds these days. But I'm not certain of that. I will note: QUOTE Common USB Commands: - usb start: - usb reset: (re)starts the USB. All USB devices will be initialized and a device tree is build for them - usb tree: shows all USB devices in a tree like display . . . Storage USB Commands: - usb scan: scans the USB for storage devices.The USB must be running for this command (usb start) . . . END QUOTE Note that the wording indicates that having the tree is not the same as having classified the storage devices: storage classification is an seprate step. "usb reset" seems to automatically do a scan. But, still, the tree listing things that "usb storage" or "usb part" would not is apparently normal util after a successful "usb scan" has occured (possibly automatically executed). >> I suggest trying the same vintage that is on 13.0-RELEASE's >=20 > I've written the 13.0-release image to a microSD card and tried > that. It reports a version of > U-Boot 2020.10 (Apr 09 2021 - 03:55:54 +0000) >=20 > Stopped at the u-boot prompt and given the=20 > usb reset command, zero storage devices are found. However, > usb tree still reports >=20 > USB device tree: > 1 Hub (480 Mb/s, 0mA) > | U-Boot Root Hub=20 > | > +-2 Hub (480 Mb/s, 2mA) > | > +-3 Vendor specific (12 Mb/s, 90mA) > | FTDI FT232R USB UART AM00FGTR > | =20 > +-4 Vendor specific (480 Mb/s, 2mA) > | =20 > +-5 Mass Storage (480 Mb/s, 0mA) > ASMT ASM105x 12345678D558 >=20 > The mismatch between what usb reset and usb tree report strikes me > as extremely puzzling. See my earlier notes about tree vs. storage and part information. > As an experiment, I tried booting with no microSD card installed at > all. This got confusing; u-boot still came up, apparently from the > USB hard drive. The RPi internal code is handling the USB drive initially and loading the RPifirmware from the USB drive. That firmware is in turn loading U-Boot in this case. It is when U-Boot tries to take over and set up the USB drive for its own use that things are having the problem. > The USB disk is still not found by usb scan, but it=20 > is recognized by usb tree.=20 See the earlier notes about tree vs. storage and part information. > As a final test I tried connecting a monitor that had been used with=20= > this Pi previously. The monitor's presence made no difference, the > display looked normal. =20 >=20 > A hands-off boot to single user is successful from the microSD card.=20= > It's possible to see and access the USB hard drive.=20 This sequence by-passes U-Boot having to have usb storage operational. The FreeBSD kernel is better behaved for handling the properties of your devices involved. > At this point I'm beginning to suspect some obscure mischief with the > USB-SATA adapter, based only on earlier intermittent problems = detecting > the USB hard drive. In those cases a few repeats of usb scan found > the disk and allowed booting from it. =20 But did the problem cases show: Request Sense returned 02 04 01 or: Device NOT ready ? Or were such details different? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Mon Jun 7 23:52:48 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 361CF13EC75D for ; Mon, 7 Jun 2021 23:53:53 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4FzVZR1JqMz4mLm for ; Mon, 7 Jun 2021 23:53:46 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 157NrNgj013120 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 7 Jun 2021 16:53:41 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 157NrKB4013119; Mon, 7 Jun 2021 16:53:20 -0700 (PDT) (envelope-from fbsd) Date: Mon, 7 Jun 2021 16:52:48 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Strange u-boot behavior Message-ID: <20210607235248.GB11184@www.zefox.net> References: <20210606043152.GA94545@www.zefox.net> <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> <20210606160040.GA97697@www.zefox.net> <407FDEDF-8595-4F20-91B9-B475CCE95B39@yahoo.com> <20210607184016.GA11184@www.zefox.net> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4FzVZR1JqMz4mLm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Jun 07, 2021 at 01:09:52PM -0700, Mark Millard wrote: > > > On 2021-Jun-7, at 11:40, bob prohaska wrote: > > > On Sun, Jun 06, 2021 at 10:34:26AM -0700, Mark Millard via freebsd-arm wrote: > > Looking around on the web I see reports of the: > > Request Sense returned 02 04 01 > > (and the matching Device NOT ready) mean that the > problem will occur and that repeating usb start > or usb reset again until it does not report that > leads to things working. > > But I've also seen other, more complete information > indicating that there is a environment setting > (showing an example value): > > usb_ready_retry=5 > > to set up before the usb restart (or usb start) > command. It deals with the issue more explicitly > for slow devices. > > Another one is (units: msec): > > usb_pgood_delay=10000 > Presto! using editenv usb_pgood_delay prompted for input, typing 10000 and hitting return set the value and the disk was found. It looks like the setting can only be saved to microSD. With no card saveenv reports Saving Environment to FAT... Card did not respond to voltage select! Failed (1) > There are also device that have problems with > large transfers and require extra protocol to > deal with transfer problems before they will > work again, U-Boot not doing that. > > usb_max_blk=20 > > sets a old historical value that generally > just works for such devices form what I read. > > I see no indication that other usb commands are > worthwhile until one has avoided that "Request > Sense returned 02 04 01" message for usb reset > (a.k.a. usb start). > > The reports of this sort of thing are not limited > to RPi's and go back to at least 2014. > > If I understand correctly, usb_ready_retry and > usb_pgood_delay and usb_max_blk are part of > normal U-Boot builds these days. But I'm not > certain of that. > > > I will note: > > QUOTE > Common USB Commands: > - usb start: > - usb reset: (re)starts the USB. All USB devices will be > initialized and a device tree is build for them > - usb tree: shows all USB devices in a tree like display > . . . > > Storage USB Commands: > - usb scan: scans the USB for storage devices.The USB must be > running for this command (usb start) > . . . > END QUOTE > > Note that the wording indicates that having the tree is not > the same as having classified the storage devices: storage > classification is an seprate step. > I didn't appreciate how independent u-boot's usb commands are. Info and tree could see the disk but dev, storage and reset didn't. > > > As an experiment, I tried booting with no microSD card installed at > > all. This got confusing; u-boot still came up, apparently from the > > USB hard drive. > > The RPi internal code is handling the USB drive > initially and loading the RPifirmware from the > USB drive. That firmware is in turn loading > U-Boot in this case. > > It is when U-Boot tries to take over and set up > the USB drive for its own use that things are > having the problem. > [regarding earlier, intermittent failures] > But did the problem cases show: > > Request Sense returned 02 04 01 > > or: > > Device NOT ready > > ? Or were such details different? > Not sure. When I saw that the disk wasn't detected, I waited a few seconds and re-ran usb reset. Within a few tries the disk was found. > It's unclear to me what changed, probably something I did, but setting u-boot environment variable usb_pgood_delay=10000 seems to have put matters right again. Thank you! bob prohaska From nobody Tue Jun 8 02:06:14 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8C24E57B887 for ; Tue, 8 Jun 2021 02:06:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (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 4FzYWJ20LBz4vYf for ; Tue, 8 Jun 2021 02:06:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623117978; bh=Cr00l+wyQ1tqt3GxLACA5hcM3mnvOpziAW7F4DasHBo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=YGKW8EEzVPzo+y6u9F8K8tNwJX2VBOVmdWKcUmTusAO57hUncXwhnWtba0/+HKQlY+nECYr2zs7E7J6Mmhbo3aS5iEVFJ/bBOrTP5xzj83FHSXzBdkRGhr66z52NItoj7jEC+oIjADESGppRun+mS1+iLHy3MMpRmiw/53HCeIAh1m8QvxrEu5QkmU0boCXQiwbxgKs2RXn8j/jvBRwWkitnshHwG+tY9TxWgGWCiAQ5kU6t4Lt9dM66bCTwG48IsnQ2YyuLLT1ZFeR5BKhoXE7NwwvM3WVlmdUwtK7Wgc+ibLNIc6hvkS4HWm8vs5g53DzIwnp0xCBhY0kkCNE2hQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623117978; bh=tsNn3GK41ZGH7Zcw1pvHoOPkHtkvE3p/logn9lnpCu5=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=qbsGs3ZMWU02Oln7HQJ4bmzJDLqUgD4eWdzrFALuSBbd/b0mETBKlufCsPpMPueMNzuuxergQBj1sXnNNiWqa0/HdK2cBRax8RdAJWl2EOUR0Yog+nLAy/RP0xyuzswRayIqiPiU9b0yrlAXBb2R7C88WT94jP1BS2Iy1UyZP4rqV8L5hqwHSCtBn3SoL4Xr73gw77nn+Y24VVArux40RyeI/AWDo2G3BsKOnwOgmLYRNGLW5x4ElBHR06017b0RtayuK1YA3nVz77bNYSyqA6geiQJ24EMk2wE8jNv8XHiwzKaQA5J3ybbmBll07wGVa5L3OpxIquvO0GLm1+KHhQ== X-YMail-OSG: nZMxIfEVM1mG4N6u2plAozL3OegrD08AThLXTLggTWr0QWlTg8dOTDJ8N_CeYGP EOErXs96F3xLrXhX7.ojpwAqoiZNy79TUDeUoAFECdorGYH38P42NBMGH_GQ7AOz2xqS95x6zt7c HIzWhOHv9LcdTw5FPw6X7PbgZFILE.UTtjuDl460HZBuUXsMV3RzfiU2sNh0qdwyBlQgdmpQZEOH NEt17heqWsSxMGWckie4nETRWdEok6eWc1OfhMCUERWEWBHGIJC_Y5Yg8v8hIAIIpYc3BcSgpAzl MWdTZg0xQV0whSqr3l_5oVZKgG8gYfcHGwp7z5se3JKxl7LEqi9prYA3mS93Jk83fa.cWBixwem0 ssSBXMIEGqtCfxdDbxfNznkZuCnkPpa6n4rl4yNwt4epYeNlsGDh5vq66mRSjJ7RFqpqeaCoEfdv YNIa7eTBoRMyK1HTWF7_7_7u2W4_m8HUsHkrfjBzM7AX7ulwJKzbYbUuxYUrbdZrzKUCkvvounfl irTGOge9NaOAV8dNcPbFpnun2pdasJkeUvzu94o54ZkDTSF0B72T9LX3TE6x6s_Q0Q4iQdgsnTKy d7FbfOnMPkXhD3pbbqD1XPkK7Bh.aXN0VDAgDmMMX6d4NpBFi1Qh3cM7RC8O8vy46._ZL54agW7d f743ET4S5EgoTeKQbr5lrGDkG91Rqc7QFcir.4uhSCqwFfXxD4rsJi2AUsa1S7SkVJAtY.AAPsnb M0F8alAYcJQPEW90L8sb4CW4.aT9zZeJYaY8JItRnC55_cRrmLxsIzywWS1HHc4uCNE26Pf9gQMl qHGxCr9T1Zs8kxM7XVHd36o6ySNWlxOjRLRl8s9zgHk6mmPYfREEieNpHOEFZhFgLW9M8bXlO6qI v8rWpysPZh5tA5NN9fNjLBmxsK50RxRRPV49iAL73T2SKXW2ZStBWAjijm6q8W3Ap77E_x2Bsw.i hR5MnSezO_ZOBajpURZDJiQnwE7uAw6Mf5Cq4eCgXQBid2wBs.VCc_gCcxSctGFPUZH4R6v.sGrp rVGOmlFvMuOGk4qEF_zUNcVGy75gpBAO8FYlH724I05a5wOR9aQaS1fEX23e7jmA7ZkYThWkal.D KdWSxhv2ZjIn92Y5ckUAZB7pD3LfRpkHkngJzZPaIbj3awbXDqRdcuh.94RDgWZ0JCUvWPr5U5AM xMeZqb9cCctG6qyFhZ61e6g4vzXxBWfIvvcyui5QdZXDB6Ph5ffma8rMM5n26gpzdXoVLN3gKOfp 83GocIy350SuRob4JYh8COvMD507JOUWWhzz6DQnn4q0eUpL1qkQkp1jgJ9CUYPHWipS2javMw2r YajMMtNnNrYphzG10BPpw.Y7ee.PH9m_NG9Uo5cj7YC0T7FlnvZAwprgBw5OZIcuCSRaMJER122w YCi4leA1iWMKHJilGRCRxiBajgvOKrtsWNm12Hj3Qb5Pr7ZX2erCBFZIe.ZgnN_wg95y5fmrkjI2 7CdcZt1ZNNbRX2V7JbbWE35EeYjw7Rrhz3Kss_Kz7VPECSH50lcExc9fC1aQC06gQGLlNInqZP.x 9ZFrwT3oq3U_XzDx7ciO9NdW1_.9yPWCfboEcIpXygUkSgzD.QQJ1F1yeTrg80CUhMp5d31ncyYT .5m8i4EsbC1fRI3y49HpL8KLAr2qLH5mGajtEyMJffdLF5VC2Mvf4flF.B9vIAOgxRJZZXPKYHDm 7apMHdC91Cg.aYd0VAspD4SgLOuUPxkDzL0y24NXJVScGu.FlFYibkFpI3_Lcv0Y6f99Z_F4jvQQ xUChR3dTAvz66aJK.LXNivs0QtdrO8W4NjPhVihg61q8mmOs6wl_t7eNRWb8qvnOs9e_HGyLo7_C VlsQkR6G2M8a1bwMaCMjYh.ZBa0LMO_CN01_WGvDnemHbcF7iz1FNXmYTNNOrkpDsjXfrxKGj5Lo 4Oox1pXfEOP3R.EDRfG4WPbbF.KH2ybFGOnVF1djIUnDdiPWikS3QZmXEQFoiCTKXhAy7lTWVbml gUzpmcN6osaa81lPqMbkeWK6nT617OvTRU6x3PTz9Sw.kZ66Tpl2hoNgHx4TCr4lBesSG0ICLLbP .ON3FRTHIdgr_DtdS30uiI5ja7wMPR.vcPhh6qgz1PfMkrOvEzf.ae2K37.9CdKMqtImITEr8Gwt m28MyfyF8jaFp6enoKWqNYuysNYmkHk6m1zs4cjAW8Vg_k4JViHq7EYKFPhalSnQN8Ks5I5NudqR 4n9uTQW6F1XtCb3eZlQ.dOI_V7CZ_WdH7gY.AzImFtTobL_O_r9ycphbc1asdRI1pM1LIGKHvXwC Tese0vRW6q6fkaVrLqbPeZPyqYryxYwyTLHiR7XcvLL7wsTBm8xDYnxFYmCXmQMx9MHcNvAOPoP3 ZbhUvAVLlUR.nmkDN0LKmCrRnmFdOaVz0mbzjgG4tQ85Va_1p5xC_lhT1lWhnotESgR.6Bdhjdy8 Or23bOQKDEY2yLwGucf3F96ZD4CeRQcCUXv8h_zmizYQYZVPTZLR2iEufSMZ3xgM3TZjm28qd X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Jun 2021 02:06:18 +0000 Received: by kubenode575.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 806012e8be4e6159e62a33ef03c69741; Tue, 08 Jun 2021 02:06:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Strange u-boot behavior In-Reply-To: <20210607235248.GB11184@www.zefox.net> Date: Mon, 7 Jun 2021 19:06:14 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210606043152.GA94545@www.zefox.net> <27786296-8C55-4CEC-A587-14BF4465A4F8@yahoo.com> <20210606160040.GA97697@www.zefox.net> <407FDEDF-8595-4F20-91B9-B475CCE95B39@yahoo.com> <20210607184016.GA11184@www.zefox.net> <20210607235248.GB11184@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4FzYWJ20LBz4vYf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-7, at 16:52, bob prohaska wrote: > On Mon, Jun 07, 2021 at 01:09:52PM -0700, Mark Millard wrote: >>=20 >>=20 >> On 2021-Jun-7, at 11:40, bob prohaska wrote: >>=20 >>> On Sun, Jun 06, 2021 at 10:34:26AM -0700, Mark Millard via = freebsd-arm wrote: >>=20 >> Looking around on the web I see reports of the: >>=20 >> Request Sense returned 02 04 01 >>=20 >> (and the matching Device NOT ready) mean that the >> problem will occur and that repeating usb start >> or usb reset again until it does not report that >> leads to things working. >>=20 >> But I've also seen other, more complete information >> indicating that there is a environment setting >> (showing an example value): >>=20 >> usb_ready_retry=3D5 >>=20 >> to set up before the usb restart (or usb start) >> command. It deals with the issue more explicitly >> for slow devices. >>=20 >> Another one is (units: msec): >>=20 >> usb_pgood_delay=3D10000 >>=20 > Presto! using editenv usb_pgood_delay prompted for input, typing 10000 > and hitting return set the value and the disk was found. Cool. > It looks like the setting can only be saved to microSD. With > no card saveenv reports > Saving Environment to FAT... Card did not respond to voltage select! > Failed (1) >=20 >=20 >=20 >> There are also device that have problems with >> large transfers and require extra protocol to >> deal with transfer problems before they will >> work again, U-Boot not doing that. >>=20 >> usb_max_blk=3D20 >>=20 >> sets a old historical value that generally >> just works for such devices form what I read. >>=20 >> I see no indication that other usb commands are >> worthwhile until one has avoided that "Request >> Sense returned 02 04 01" message for usb reset >> (a.k.a. usb start). >>=20 >> The reports of this sort of thing are not limited >> to RPi's and go back to at least 2014. >>=20 >> If I understand correctly, usb_ready_retry and >> usb_pgood_delay and usb_max_blk are part of >> normal U-Boot builds these days. But I'm not >> certain of that. >>=20 >>=20 >> I will note: >>=20 >> QUOTE >> Common USB Commands: >> - usb start: >> - usb reset: (re)starts the USB. All USB devices will be >> initialized and a device tree is build for them >> - usb tree: shows all USB devices in a tree like display >> . . . >>=20 >> Storage USB Commands: >> - usb scan: scans the USB for storage devices.The USB must be >> running for this command (usb start) >> . . . >> END QUOTE >>=20 >> Note that the wording indicates that having the tree is not >> the same as having classified the storage devices: storage >> classification is an seprate step. >>=20 >=20 > I didn't appreciate how independent u-boot's usb commands are. > Info and tree could see the disk but dev, storage and reset didn't. Looking in some actual U-Boots for other reasons, I found no "usb scan" command. usb start (the first time) and usb reset both did a scan automatically and the help description indicated that scanning explicitly. The behavior that you got, however, suggests that internally the scan is still separate (and such can be observed via some types of failures having tree information left behind but not storage or partition information). >>=20 >>> As an experiment, I tried booting with no microSD card installed at >>> all. This got confusing; u-boot still came up, apparently from the >>> USB hard drive. >>=20 >> The RPi internal code is handling the USB drive >> initially and loading the RPifirmware from the >> USB drive. That firmware is in turn loading >> U-Boot in this case. >>=20 >> It is when U-Boot tries to take over and set up >> the USB drive for its own use that things are >> having the problem. >>=20 >=20 > [regarding earlier, intermittent failures] >> But did the problem cases show: >>=20 >> Request Sense returned 02 04 01 >>=20 >> or: >>=20 >> Device NOT ready >>=20 >> ? Or were such details different? >>=20 >=20 > Not sure. When I saw that the disk wasn't detected, I waited a > few seconds and re-ran usb reset. Within a few tries the disk > was found.=20 >>=20 >=20 > It's unclear to me what changed, probably something I did, but > setting u-boot environment variable usb_pgood_delay=3D10000 seems > to have put matters right again. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Tue Jun 8 14:48:32 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0C6507E8526 for ; Tue, 8 Jun 2021 14:48:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FztQl6tpSz3FTW for ; Tue, 8 Jun 2021 14:48:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D4DCD2C33 for ; Tue, 8 Jun 2021 14:48:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 158EmVrC025992 for ; Tue, 8 Jun 2021 14:48:31 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 158EmVAF025991 for freebsd-arm@FreeBSD.org; Tue, 8 Jun 2021 14:48:31 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 256482] [genet] gen_encap() dma loads into active map when 'tx_queue' is full Date: Tue, 08 Jun 2021 14:48:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ghuckriede@blackberry.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256482 Bug ID: 256482 Summary: [genet] gen_encap() dma loads into active map when 'tx_queue' is full Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: ghuckriede@blackberry.com Created attachment 225638 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D225638&action= =3Dedit Potential Fix In gen_encap() #n1053 it always calls bus_dmamap_load_mbuf_sg() into 'map' (which is the current tx_queue). If the tx_queue is full, it will load wit= h a 'map' that already has a currently active mapping. https://www.freebsd.org/cgi/man.cgi?query=3Dbusdma&sektion=3D9 bus_dmamap_load: "map A DMA map without a currently active mapping." Also "(if nsegs =3D=3D 0)" #n1077 shouldn't bus_dmamap_unload() be called as bus_dmamap_load_mbuf_sq() was successful? See https://cgit.freebsd.org/src/tree/sys/arm64/broadcom/genet/if_genet.c?id=3D= f66a1f40740c63741b6ebe48cb0cbce9e52ef34e for line number references. Attached is diff with a potential fix. Checking for a full queue and returning ENOMEM will allow gen_start_locked(= ) to set the IFF_DRV_OACTIVE faster without having to needlessly check if the mb= uf will fit (it won't). --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue Jun 8 19:38:05 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B80B85D03D0; Tue, 8 Jun 2021 19:38:11 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4G00ry45Lpz4bjm; Tue, 8 Jun 2021 19:38:10 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 158Jc5En025421 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 8 Jun 2021 12:38:06 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 158Jc56i025420; Tue, 8 Jun 2021 12:38:05 -0700 (PDT) (envelope-from fbsd) Date: Tue, 8 Jun 2021 12:38:05 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Cc: freebsd-current Subject: Re: 14-CURRENT/aarch64 build problem Message-ID: <20210608193805.GA24803@www.zefox.net> References: <12319609-40E7-429A-B290-9C01B0A8ACDC@FreeBSD.org> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12319609-40E7-429A-B290-9C01B0A8ACDC@FreeBSD.org> X-Rspamd-Queue-Id: 4G00ry45Lpz4bjm 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.90 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(1.00)[0.997]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; 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]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm,freebsd-current]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Jun 08, 2021 at 09:15:37PM +0200, Juraj Lutter wrote: > Hi, > > I???m having problem to build recent 14-CURRENT/aarch64 as of 6d2648bcaba9b14e2f5c76680f3e7608e1f125f4: > > --- cddl/lib/libuutil__L --- > make[4]: make[4]: don't know how to make uu_dprintf.c. Stop > make[4]: make[4]: don't know how to make uu_open.c. Stop > `uu_alloc.c' is up to date. > `uu_avl.c' is up to date. > `uu_dprintf.c' was not built (being made, type OP_DEPS_FOUND|OP_MARK, flags REMAKE|DONE_WAIT|DONE_ALLSRC|DONECYCLE)! > ??? > > The build is performed with pristine /usr/obj > FWIW, same problem seen here. In an added twist, git pull (hoping for a fix) fails also: root@www:/usr/src # git pull error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/legacy': 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create 'refs/remotes/freebsd/vendor/openzfs/legacy' >From https://git.freebsd.org/src ! [new branch] vendor/openzfs/legacy -> freebsd/vendor/openzfs/legacy (unable to update local ref) error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/master': 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create 'refs/remotes/freebsd/vendor/openzfs/master' ! [new branch] vendor/openzfs/master -> freebsd/vendor/openzfs/master (unable to update local ref) error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/zfs-2.1-release': 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create 'refs/remotes/freebsd/vendor/openzfs/zfs-2.1-release' ! [new branch] vendor/openzfs/zfs-2.1-release -> freebsd/vendor/openzfs/zfs-2.1-release (unable to update local ref) Is this a problem at my end, or the server's end? Thanks for reading, bob prohaska From nobody Tue Jun 8 19:42:02 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 10E8B5D15DF; Tue, 8 Jun 2021 19:42:16 +0000 (UTC) (envelope-from SRS0=emw9=LC=FreeBSD.org=otis@ns2.wilbury.net) Received: from ns2.wilbury.net (ns2.wilbury.net [92.60.51.55]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "svc.wilbury.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G00xg6Rp0z4dLL; Tue, 8 Jun 2021 19:42:15 +0000 (UTC) (envelope-from SRS0=emw9=LC=FreeBSD.org=otis@ns2.wilbury.net) Received: from smtpclient.apple (gw-upc.owhome.net [188.167.168.254]) (Authenticated sender: juraj@lutter.sk) by svc.wilbury.net (Postfix) with ESMTPSA id 697BE45CF18; Tue, 8 Jun 2021 21:42:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: 14-CURRENT/aarch64 build problem From: Juraj Lutter In-Reply-To: <20210608193805.GA24803@www.zefox.net> Date: Tue, 8 Jun 2021 21:42:02 +0200 Cc: freebsd-arm@freebsd.org, freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: <12319609-40E7-429A-B290-9C01B0A8ACDC@FreeBSD.org> <20210608193805.GA24803@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,KHOP_HELO_FCRDNS, SPF_HELO_NONE,SPF_SOFTFAIL,TW_NZ,TW_ZF autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on ns2.wilbury.net X-Rspamd-Queue-Id: 4G00xg6Rp0z4dLL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 8 Jun 2021, at 21:38, bob prohaska wrote: >=20 > FWIW, same problem seen here. In an added twist, git pull (hoping for > a fix) fails also: >=20 > root@www:/usr/src # git pull > error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/legacy': = 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create = 'refs/remotes/freebsd/vendor/openzfs/legacy' > =46rom https://git.freebsd.org/src > ! [new branch] vendor/openzfs/legacy -> = freebsd/vendor/openzfs/legacy (unable to update local ref) > error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/master': = 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create = 'refs/remotes/freebsd/vendor/openzfs/master' > ! [new branch] vendor/openzfs/master -> = freebsd/vendor/openzfs/master (unable to update local ref) > error: cannot lock ref = 'refs/remotes/freebsd/vendor/openzfs/zfs-2.1-release': = 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create = 'refs/remotes/freebsd/vendor/openzfs/zfs-2.1-release' > ! [new branch] vendor/openzfs/zfs-2.1-release -> = freebsd/vendor/openzfs/zfs-2.1-release (unable to update local ref) >=20 > Is this a problem at my end, or the server's end? This already has been documented, as the old openzfs branch has been = renamed/moved. $ git remote prune freebsd $ git pull See: = https://lists.freebsd.org/archives/freebsd-git/2021-June/000015.html otis =E2=80=94 Juraj Lutter otis@FreeBSD.org From nobody Tue Jun 8 20:14:07 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B81E65D4816 for ; Tue, 8 Jun 2021 20:14:21 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G01fh54XWz4jYr; Tue, 8 Jun 2021 20:14:20 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 158KE8tV063629 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 8 Jun 2021 16:14:13 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Re: 14-CURRENT/aarch64 build problem To: freebsd-arm@freebsd.org References: <12319609-40E7-429A-B290-9C01B0A8ACDC@FreeBSD.org> <20210608193805.GA24803@www.zefox.net> Cc: eduardo@FreeBSD.org From: George Mitchell Message-ID: <3134b379-2729-05d8-df91-0cbcadc540dc@m5p.com> Date: Tue, 8 Jun 2021 16:14:07 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tOWFdOmEP8sA7DyVel0pX5s8Sn0ksifAa" X-Spam-Status: No, score=0.2 required=10.0 tests=HELO_MISC_IP,HELO_NO_DOMAIN, NICE_REPLY_A autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4G01fh54XWz4jYr X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-4.78 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[74.104.188.4:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[m5p.com]; SPAMHAUS_ZRD(0.00)[74.104.188.4:from:127.0.2.255]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.38)[-0.376]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; TAGGED_FROM(0.00)[freebsd]; MAILMAN_DEST(0.00)[freebsd-arm]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tOWFdOmEP8sA7DyVel0pX5s8Sn0ksifAa Content-Type: multipart/mixed; boundary="07AJ5ZgzELtkczkbTJwrcaqN06ckhvcZg"; protected-headers="v1" From: George Mitchell To: freebsd-arm@freebsd.org Cc: eduardo@FreeBSD.org Message-ID: <3134b379-2729-05d8-df91-0cbcadc540dc@m5p.com> Subject: Re: 14-CURRENT/aarch64 build problem References: <12319609-40E7-429A-B290-9C01B0A8ACDC@FreeBSD.org> <20210608193805.GA24803@www.zefox.net> In-Reply-To: --07AJ5ZgzELtkczkbTJwrcaqN06ckhvcZg Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/8/21 3:42 PM, Juraj Lutter wrote: >=20 >=20 >> On 8 Jun 2021, at 21:38, bob prohaska wrote: >> >> FWIW, same problem seen here. In an added twist, git pull (hoping for >> a fix) fails also: >> >> root@www:/usr/src # git pull >> error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/legacy': '= refs/remotes/freebsd/vendor/openzfs' exists; cannot create 'refs/remotes/= freebsd/vendor/openzfs/legacy' >> From https://git.freebsd.org/src >> ! [new branch] vendor/openzfs/legacy -> freebsd/vendor/op= enzfs/legacy (unable to update local ref) >> error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/master': '= refs/remotes/freebsd/vendor/openzfs' exists; cannot create 'refs/remotes/= freebsd/vendor/openzfs/master' >> ! [new branch] vendor/openzfs/master -> freebsd/vendor/op= enzfs/master (unable to update local ref) >> error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/zfs-2.1-re= lease': 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create 'refs= /remotes/freebsd/vendor/openzfs/zfs-2.1-release' >> ! [new branch] vendor/openzfs/zfs-2.1-release -> freebsd/= vendor/openzfs/zfs-2.1-release (unable to update local ref) >> >> Is this a problem at my end, or the server's end? >=20 > This already has been documented, as the old openzfs branch has been re= named/moved. >=20 > $ git remote prune freebsd > $ git pull >=20 > See: https://lists.freebsd.org/archives/freebsd-git/2021-June/000015.ht= ml >=20 > otis >=20 > =E2=80=94 > Juraj Lutter > otis@FreeBSD.org >=20 >=20 How would this affect net/gitup users? (I'm guessing gitup would force the local repo into conformance with the remote repo by default.) -- George --07AJ5ZgzELtkczkbTJwrcaqN06ckhvcZg-- --tOWFdOmEP8sA7DyVel0pX5s8Sn0ksifAa Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAmC/z48FAwAAAAAACgkQwRES3m+p4fkq 8g//RIiU3npKLG9dyIwwJnpJ6SkaYsDq5ZI68s6lBadpiUHrP5khU+sRBlXXF5SuMu7GFziHlnt8 trpr9r+8JOImb+HNHATv559MLVOPr6m0B2wJC1KWkUvTGgd/pDuXgrliGS9F9m1QT1LKzpaxG1JD UlDMQVDxMmJxBBKGc5a5SWl8yyA+Nu3q76H6r6i4+qC+YJXF3aTi1mt5MnrsXdl0KFQadEZm2ijN XsXN49Wvob6jg2Z/ggpW6jNmI4U3DlRB+3o/LYNyX6eWv1FXsH0AzzI9Og2z4X3Sq2O8tsvE5BMS EDuKyLs2crBFjiJSVPv2iE4RZ2insz0KrOGe5GFTkRm5t35eAChyHYVGACcu4sZr9dXRrRJowYdn M3GM1gFMIPGKnyHV1waX/Q6fgwTyHpF8vpDFieUsV3nKiWEIm/O1JVem66KQsCUq6DuVEzZzKRTz rOcdC6BOuEShWPnhEiapmBL3YOhBe813WQqDBcR5zlXtS76nSTrhASSYChrc6bDRvPu1z3naynfh 44hQKKiRxU48sQzjesbb98v1TJ5VjmkNnJZwljqalUaDI6Vc4TPAM5Kd5J1HX/nEloqWNivrsNgV qzms0Pc9u3G/xuaVsmAC62RRU6XjLRcAz9Q595gVHzZKPJtlt1yHLj+cu15/N0V+E+dh5VY4TGwu MJ8= =uXeF -----END PGP SIGNATURE----- --tOWFdOmEP8sA7DyVel0pX5s8Sn0ksifAa-- From nobody Tue Jun 8 20:37:43 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E35E75D5620 for ; Tue, 8 Jun 2021 20:37:49 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G029n66J1z4kTb; Tue, 8 Jun 2021 20:37:49 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from smtpclient.apple (unknown [73.99.214.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id A68681B5; Tue, 8 Jun 2021 16:37:43 -0400 (EDT) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: 14-CURRENT/aarch64 build problem From: Paul Mather In-Reply-To: <3134b379-2729-05d8-df91-0cbcadc540dc@m5p.com> Date: Tue, 8 Jun 2021 16:37:43 -0400 Cc: freebsd-arm@freebsd.org, "eduardo@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <21617CC8-7FC4-432F-BBDF-EF821DA4670B@gromit.dlib.vt.edu> References: <12319609-40E7-429A-B290-9C01B0A8ACDC@FreeBSD.org> <20210608193805.GA24803@www.zefox.net> <3134b379-2729-05d8-df91-0cbcadc540dc@m5p.com> To: George Mitchell X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G029n66J1z4kTb X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[freebsd]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Jun 8, 2021, at 4:14 PM, George Mitchell = wrote: > On 6/8/21 3:42 PM, Juraj Lutter wrote: >>> On 8 Jun 2021, at 21:38, bob prohaska wrote: >>>=20 >>> FWIW, same problem seen here. In an added twist, git pull (hoping = for >>> a fix) fails also: >>>=20 >>> root@www:/usr/src # git pull >>> error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/legacy': = 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create = 'refs/remotes/freebsd/vendor/openzfs/legacy' >>> =46rom https://git.freebsd.org/src >>> ! [new branch] vendor/openzfs/legacy -> = freebsd/vendor/openzfs/legacy (unable to update local ref) >>> error: cannot lock ref 'refs/remotes/freebsd/vendor/openzfs/master': = 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create = 'refs/remotes/freebsd/vendor/openzfs/master' >>> ! [new branch] vendor/openzfs/master -> = freebsd/vendor/openzfs/master (unable to update local ref) >>> error: cannot lock ref = 'refs/remotes/freebsd/vendor/openzfs/zfs-2.1-release': = 'refs/remotes/freebsd/vendor/openzfs' exists; cannot create = 'refs/remotes/freebsd/vendor/openzfs/zfs-2.1-release' >>> ! [new branch] vendor/openzfs/zfs-2.1-release -> = freebsd/vendor/openzfs/zfs-2.1-release (unable to update local ref) >>>=20 >>> Is this a problem at my end, or the server's end? >> This already has been documented, as the old openzfs branch has been = renamed/moved. >> $ git remote prune freebsd >> $ git pull >> See: = https://lists.freebsd.org/archives/freebsd-git/2021-June/000015.html >> otis >> =E2=80=94 >> Juraj Lutter >> otis@FreeBSD.org > How would this affect net/gitup users? (I'm guessing gitup would = force > the local repo into conformance with the remote repo by default.) This is what I got when I tried updating one of my -CURRENT systems = right now: =3D=3D=3D=3D=3D # gitup current # Scanning local repository... # Host: git.freebsd.org # Port: 443 # Repository Path: /src.git # Target Directory: /usr/src # Have: b5d37e5a20ab1b189499e2824dc269d998c31989 # Want: f20893853e8e6909d422f6646b706b4b6e299682 # Branch: main # Action: pull zsh: segmentation fault (core dumped) gitup current =3D=3D=3D=3D=3D Even deleting everything under /usr/src and doing "rm = /var/db/gitup/current" and re-running "gitup current" to re-clone = everything afresh results in this: =3D=3D=3D=3D=3D # gitup current # Scanning local repository... # Host: git.freebsd.org # Port: 443 # Repository Path: /src.git # Target Directory: /usr/src # Want: f20893853e8e6909d422f6646b706b4b6e299682 # Branch: main # Action: clone gitup: load_object: local file for object = 3331601f6dc50ef2c9779c1656218701b48b276c -- = /usr/src/sys/contrib/openzfs/scripts/zfs-images not found: No such file = or directory =3D=3D=3D=3D=3D So I guess "gitup" needs to be taught how to resolve this kind of = change. :-\ Cheers, Paul.= From nobody Tue Jun 8 21:06:56 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0CF195D7F92 for ; Tue, 8 Jun 2021 21:08:15 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (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 4G02rs4K20z4nnl for ; Tue, 8 Jun 2021 21:08:13 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.15.2/8.15.2) with ESMTP id 158L86Xi099694 for ; Tue, 8 Jun 2021 16:08:06 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (65-36-5-114.static.grandenetworks.net [65.36.5.114]) by mail.shrew.net (Postfix) with ESMTPSA id EF3FB19A11C for ; Tue, 8 Jun 2021 16:08:00 -0500 (CDT) To: freebsd-arm@freebsd.org From: Matthew Grooms Subject: RPI4 Hardware PWM Message-ID: <9bb7f3d1-8256-be26-ba87-90946ce1b95f@shrew.net> Date: Tue, 8 Jun 2021 16:06:56 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.shrew.net [10.24.10.10]); Tue, 08 Jun 2021 16:08:06 -0500 (CDT) X-Rspamd-Queue-Id: 4G02rs4K20z4nnl X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.131 as permitted sender) smtp.mailfrom=mgrooms@shrew.net X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[38.97.5.131:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[38.97.5.131:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[shrew.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N Hey All, I have a project I'm working on that depends on interfacing with a few sensor modules using both i2c and PWM. I've got the i2c devices to work correctly, but I'm not sure how to interface with the HW PWM support of the RPI4. I can see there are settings exposed via sysctl for Beaglebone systems ... https://zewaren.net/bbb-pwm.html I was hoping I'd be able to force GPIO 12 or 13 into ALT0  and set the duty values via sysctl, but that doesn't seem to be an option. Any help would be greatly appreciated. Thanks, -Matthew From nobody Wed Jun 9 21:16:49 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BFE0D5D56F0 for ; Wed, 9 Jun 2021 21:16:58 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (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 4G0g0T32TKz3mfd; Wed, 9 Jun 2021 21:16:57 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.15.2/8.15.2) with ESMTP id 159LGoVt016485; Wed, 9 Jun 2021 16:16:50 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (unknown [136.49.68.36]) by mail.shrew.net (Postfix) with ESMTPSA id 4C35D19A11C; Wed, 9 Jun 2021 16:16:45 -0500 (CDT) Subject: Re: RPI4 Hardware PWM To: freebsd-arm@freebsd.org References: <9bb7f3d1-8256-be26-ba87-90946ce1b95f@shrew.net> From: Matthew Grooms Message-ID: Date: Wed, 9 Jun 2021 16:16:49 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: <9bb7f3d1-8256-be26-ba87-90946ce1b95f@shrew.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx2.shrew.net [10.24.10.11]); Wed, 09 Jun 2021 16:16:50 -0500 (CDT) X-Rspamd-Queue-Id: 4G0g0T32TKz3mfd X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.132 as permitted sender) smtp.mailfrom=mgrooms@shrew.net X-Spamd-Result: default: False [0.49 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[38.97.5.132:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[shrew.net]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[38.97.5.132:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.79)[0.794]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RECEIVED_SPAMHAUS_PBL(0.00)[136.49.68.36:received] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On 6/8/2021 4:06 PM, Matthew Grooms wrote: > Hey All, > > I have a project I'm working on that depends on interfacing with a few > sensor modules using both i2c and PWM. I've got the i2c devices to > work correctly, but I'm not sure how to interface with the HW PWM > support of the RPI4. I can see there are settings exposed via sysctl > for Beaglebone systems ... > > https://zewaren.net/bbb-pwm.html > > I was hoping I'd be able to force GPIO 12 or 13 into ALT0  and set the > duty values via sysctl, but that doesn't seem to be an option. Any > help would be greatly appreciated. Replying to myself with a bit more info. I see that there is a driver available for rpi boards authored by PHK ... https://cgit.freebsd.org/src/tree/sys/arm/broadcom/bcm2835/bcm2835_pwm.c That has notes on RPi2/3 boards, but not mention of RPi4. When I load that, I see the following output ... Jun  9 18:29:50 generic kernel: pwm0: mem 0x7e20c000-0x7e20c027 on simplebus0 Jun  9 18:29:50 generic kernel: pwm0: cannot find Clock Manager I assume I'm doing something wrong. Any feedback would be greatly appreciated. Thanks, -Matthew From nobody Thu Jun 10 20:22:44 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4A19B7E99CC; Thu, 10 Jun 2021 20:22:49 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1FlX1MDNz4YLr; Thu, 10 Jun 2021 20:22:47 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Thu, 10 Jun 2021 20:22:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1623356565; bh=i/Oay3cYGx8mgAz42dQdVdbT+Be6kfo/AzQMS1o+euk=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=beJJ1zoopEEBHgTzs0DOlIt5dDZQSABcwFlTHBnp7XPbwI1LyX/8GJOfdUrLqJ0v5 nPO7/hhpG1IAeMm95E8uVHZUXWThic7BnNjYS9BHpDiyYD0MkVmGm6RXq6dut+FQNQ +gygs6kpsOBvB51K3xEfStnOIiias7gY4EOue/8w= To: Dmitry Salychev From: Dan Kotowski Cc: "Bjoern A. Zeeb" , freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org Reply-To: Dan Kotowski Subject: Re: U-Boot for HoneyComb LX2 Message-ID: In-Reply-To: References: <198F84BF-5932-4E58-BCE3-CC33B185923A@lists.zabbadoz.net> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4G1FlX1MDNz4YLr X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=a9development.com header.s=protonmail header.b=beJJ1zoo; dmarc=pass (policy=none) header.from=a9development.com; spf=none (mx1.freebsd.org: domain of dan.kotowski@a9development.com has no SPF policy when checking 185.70.43.16) smtp.mailfrom=dan.kotowski@a9development.com X-Spamd-Result: default: False [-3.80 / 15.00]; HAS_REPLYTO(0.00)[dan.kotowski@a9development.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[a9development.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[185.70.43.16:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[a9development.com:+]; DMARC_POLICY_ALLOW(-0.50)[a9development.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[185.70.43.16:from]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm,freebsd-hackers] X-ThisMailContainsUnwantedMimeParts: N > > I=E2=80=99ve got a local tree (on Jan 2021, needs updating to latest an= d > > > > re-test before > > > > submit) for the uEFI firmware (not u-boot). > > Btw, do you have that tree available somewhere? Did you manage to > > load a blob from NXP and initialize DPAA2 MC? > > Regards, > > Dmitry Hmm, so this went to my spambox... You REALLY wanna stick to UEFI for FreeBSD on lx2160 if you can. We did a l= ot of work to get the PCIe BAR space and ACPI tables sorted a while back an= d it's been basically stable for a while. And you can get their prebuilt BS= P images here: https://images.solid-run.com/LX2k/lx2160a_uefi As for DPAA2, we just don't support it today and afaict there's no plans to= in the future other than the dreams in my head and I just don't have the t= ime to implement it myself. I've been trying to drum up some support for it= though and seeing a few more names on the "I wish we had this" list is alw= ays good :) --Dan Kotowski From nobody Fri Jun 11 00:22:00 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C459A5D116C for ; Fri, 11 Jun 2021 00:22:11 +0000 (UTC) (envelope-from freebsd@dsllsn.net) Received: from mail.disillusion.net (mail.disillusion.net [96.126.127.161]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.disillusion.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1M3k1wZnz4vk4 for ; Fri, 11 Jun 2021 00:22:09 +0000 (UTC) (envelope-from freebsd@dsllsn.net) Received: from roast.disillusion.net (localhost [127.0.0.1]) by roast.disillusion.net (OpenSMTPD) with ESMTP id 161f5d4f; Thu, 10 Jun 2021 19:22:01 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=dsllsn.net; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=drip; bh=g8u3sTU9VjqVPGZCHi7upwOaIeAfDKAV5B agRsGUSrk=; b=2bugqoNvl/eHy3AkbSzpsl1ABBadSJBk1RETeiQ0qIoybUetjQ Px1pw3VVkPTDotVRQxeGFctgYdRpCRIrIxl9smIwRWmcOGXQQAWO3lAm3N5HBRde nZHV2r1+SSp8/FzCv1Z8yeDC7n1q8JhdGMYEmSNtlr7sOsrYU0JtPg/bg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=dsllsn.net; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=drip; b=qLjHOObD3gY2pSqN5CeRq9CZkyIi N7+9UCoivkC5m4dls50k2kf/ISTHfL8/8Bf5Y8spyRWHxcd8V5CcgeiGEZ/NMCqK GCEOxGK6eXXgaQiSx9Pb28ajGOfexcvRJ6tzKiSGwhUfttu1C4EvQMA5NnHxLJZP eO47ST483ZPd86c= Received: by mail.disillusion.net (OpenSMTPD) with ESMTPSA id a12848f3 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Thu, 10 Jun 2021 19:22:01 -0500 (CDT) Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_15676D4B-6923-46F8-9A3F-472A02C3ABF0" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: Boot from USB on RPi4 8GB? Date: Thu, 10 Jun 2021 19:22:00 -0500 In-Reply-To: Cc: freebsd-arm To: Mark Millard References: <4F3EE8D2-649B-4522-AD5A-7C308291802F@dsllsn.net> <43FAEEAC-EE36-4810-88AA-FF82AFBCC128@yahoo.com> <2F58272B-BD9C-464B-9A98-BF638971BA86@dsllsn.net> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Rspamd-Queue-Id: 4G1M3k1wZnz4vk4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dsllsn.net header.s=drip header.b=2bugqoNv; dmarc=pass (policy=reject) header.from=dsllsn.net; spf=pass (mx1.freebsd.org: domain of freebsd@dsllsn.net designates 96.126.127.161 as permitted sender) smtp.mailfrom=freebsd@dsllsn.net X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[dsllsn.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[dsllsn.net,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[96.126.127.161:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:63949, ipnet:96.126.112.0/20, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[dsllsn.net:s=drip]; SUBJECT_ENDS_QUESTION(1.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; SPAMHAUS_ZRD(0.00)[96.126.127.161:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] Reply-To: freebsd@dsllsn.net From: William Carson via freebsd-arm X-Original-From: William Carson X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail=_15676D4B-6923-46F8-9A3F-472A02C3ABF0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 30, 2021, at 6:54 PM, William Carson via freebsd-arm = wrote: >=20 >>=20 >> On May 30, 2021, at 4:08 PM, Mark Millard wrote: >>=20 >> On 2021-May-30, at 13:50, Mark Millard via freebsd-arm wrote: >>=20 >>> On 2021-May-30, at 10:59, William Carson via freebsd-arm = wrote: >>>=20 >>>>> . . . >>>>> I use a USB3 SSD that has small enough power requirements >>>>> to not require a powered hub. (I also use a 5.1V 3.5A >>>>> power supply as part of that context.) I've never tried >>>>> spinning rust or higher powered USB3 media. >>>=20 >>> I view the power supply that I use as just giving a little >>> more margin, not as a way to increase what the devices >>> total to. >>>=20 >>>> . . . I'm not sure what's considered "high powered" but the Samsung = tech specs say this particular model uses 5.7 W on average and 10.0 W = maximum. But it does seem curious that the Raspberry PI OS will boot = this disk without issue, so I don't think it's the drive. I also tried a = Samsung 950 PRO using a different enclosure (QNINE NVME Enclosure, M.2 = PCIe SSD (M Key) to USB 3.0 External Case), but it behaved the same. >>> . . . >>>=20 >>> Then you need to use a powered hub for that device. >>=20 >> I should have just referred to independent power. You >> had written: >>=20 >> QUOTE >> I'm trying to use a SAMSUNG (MZ-V7E500BW) 970 EVO SSD 500GB - M.2 = NVMe, attached via the Geekworm X872 M.2 NVMe 2280/2260/2242/2230 SSD = Expansion Board. >> END QUOTE >>=20 >> = https://geekworm.com/products/raspberry-pi-4-x872-m-2-nvme-2280-2260-2242-= 2230-ssd-expansion-board >>=20 >> shows that it has its own power connector and has an image >> that says "please power x872 via DC Jack of XH2.54 connector >> if SSD is not recognized or low power". Later text on the >> page says: >>=20 >> QUOTE >> Specifications: >> Power Supply >> =E2=80=A2 5Vdc +/-5% , Powered by Raspberry Pi USB port >> =E2=80=A2 5Vdc via DC power jack or XH2.5 connector, Extra power = for the SSD >> END QUOTE >>=20 >> So, if I gather right, you need to connect a power >> supply to the X872 and another to the RPi4B. >>=20 >> Another image says "Note: NOT recommended to use SAMSUNG SSD, >> if use SAMSUNG SSD, please close WiFi". Later text on the page >> says the same. >=20 > A-ha, indeed. I just noticed that as well. I've gone ahead and ordered = a supplementary power supply and a lower-power NVMe to do more testing. = I'll send an update once I've received and tested them. >=20 > Thank you for hopefully pointing me in the right direction. Alright, so, I ended up buying a WDS500G2B0C, which seems to only use a = maximum of 75 mW (this seems ... low, to say the least, but the column = is unlabeled in the spec sheet I found here = https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/= public/western-digital/product/internal-drives/wd-blue-nvme-ssd/product-br= ief-wd-blue-sn550-nvme-ssd.pdf). Sadly, it also would not boot from = either of my NVMe-USB adapters. After a while of getting frustrating forgetting which combination of = image + usb adapter + drive configuration I had or hadn't tried, I = thought to myself.. what would happen if I tried one of the USB2 ports? = Bingo! It booted FreeBSD no problem. So I'm not sure what exactly that means, except that I know the = power/usb adapter/drive/image is not the issue. I don't think I really = "need" the performance improvement of the USB3 port at the moment, but = maybe that's something that will help troubleshoot the issue? It would = certainly be nice to use little USB bridge pcb "cable" to have a neater = installation though. Any ideas? >> = https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/READM= E.md >>> lists: >>>=20 >>> "Maximum total USB peripheral current draw" as: 1.2A , >>> which at 5.1V is 6W. >>>=20 >>> That figure is the total for all USB devices attached >>> that are not powered independently. >>>=20 >>> That document also says that a 5.1V supply is required, >>> not 5V. >>>=20 >>> The power supply that the RPi folks supply is 5.1V @ 3A >>> or 15.3W. Even the 5.1V 3.5A power supply that I use >>> only multiplies out to 17.85W. >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >> ( dsl-only.net went >> away in early 2018-Mar) >>=20 >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >> ( dsl-only.net went >> away in early 2018-Mar) --Apple-Mail=_15676D4B-6923-46F8-9A3F-472A02C3ABF0-- From nobody Fri Jun 11 02:57:39 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5EDB67C8E55 for ; Fri, 11 Jun 2021 02:57:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.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 4G1QWF0Fpxz3MTj for ; Fri, 11 Jun 2021 02:57:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623380263; bh=d364mP47l9veJ5xqWnLIprbVuJXuWhBWSeE+5R9Q1yg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Ns/NdBIm99/0FaZwBu6j6FkKv7wT4hW4TuMvfa2lb02FSyKtTYsgVWK/5HnqIEXVpdK+9itFy/vvbBUnxtPhNUII8D9Fn17kYmOMVKaJ3dAUcFWQBHx0Znog8tDl9lrWhCb5Bo+3XJskT3M+xAintd2ckh5pVIWYEVB7TDQVA/p8vu7eXzYUKkpmWZVu1FfCzupPZi0F4V65i0p6MlVQEj3h4G8+jUkaojsg7btfTN3a2rJuFCZ9lOv+wIhOeciQoP+QSgjsQv45Hfn+krlx7nGm9Wk2hxHyKdkVoTfWz2W6jhr9wFjemTrlJesV1QSMkEkYd7fRjVGU0UEdlcZftw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623380263; bh=L+9yhPucZOV5pIx7eu7/Zp2Pv39usE5uUnphLFQp+0J=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=HLbI+7qPFRrltLYcmL5tl87GU7cZVu4eOacluSQQKRH25/gbVyA2wzhizVSyAQmOp+4v39KzSYNE0jdrY95A3WetuuQCJOp7oDMakzfYfaGXxiMMqWUlOE2CzXubS4QjVpAzNqc9VU8Ol5Qp8JkqZNEqh2JSB/xp7u6iBJq37ENzOdoxGvpH4voEXufiTbPC/Hir0AqsjW8QQl26Eko9R3+DmwPou94CL133oamhMuvMQ2T96SinH2iYk9Y/qJUgOnLou/PvSO1yP7i6TQo7NKlbo6TAY0TheBi01AULkl3xoCMIcwMDc2ovpexKG/g80PAeK+RiiK/rypSZ+Fg7KQ== X-YMail-OSG: cCQZ8ZgVM1niIL23owqd_v5Qdh3lFMBAGhnbT5PGqsKaxpvxE2mTjjr8nX72N8r NRRstkpDdSHm9PoiOB.vDxuVkL28OnV1Sw0jwKptFTfEZWxKw66V1Silzh5aRJYBS2cxMKMn8rZq 2nIWc0Yh7fv_Mey3t73xpjgcIGt0zNY90pIcTyk4R3ErKjW5dMxcw1l5WsrsppSJggwejtYKVy2Y u4WX0_U079TuXPw02RC2WjklgbQ2k_PtyhkmF57ioEo3iSTuUK1ETHI1XT1d7D_r3tYWXOTIYEwU zbrSBJ9MQ3zMBPzhBrQtOwhaF7M.HxkDjCrW9nxC2E9rRT5T3VUYf21oaNo1HKztv26J6quDgluu JDHcAMey1._I7fGnPovo0cb2YEB4TB4LQmZmHMVFKKdkuKQf9ae1ZSno7gprSQbqh1vx7QvEHgFj MIZh2VnxPHXC50GrjLm2Qpu31iTanxuqsiI1km8gBZNQZsOnBum6lEb5ApaEE8bYkMPjPDw3l4AK 62mDTsicibnyevT4_Fyiu3VQdIrzS30tcoXYYaEq.6kwHzn2_l6s1nPyjbq4TyR1wvBWmIf5CXGE 6tILQ2sg9viXhmkQj6RRFGpbWJD9_Gi1d0NvPrFe5XoBe9PeN3LUSzE4554s_40R53qi4QxNzIYj GnF_afdPqBzspJ4dJWlkidvlx4f7oFFQJDXCR8dNgC6ws3FmgBHoFJqYC4WGZAiNC_OYy1rumBwG SxGGdUGgbunh_PI3yoI4yfMxkQO2Cgq0wVexDL0FL9jzB3n1GH6sEz0QDjJAK4PoxBShaFjOESQu ENBt62i7GCLyPmESXd.nYnku.GUtn9E_EE_dVS_C4ckNk.3b6wXz.iEwg15iD01Sz9DPubHf1Cld UApPJ0DGtRCV3f0tIFc6Fy4qrCAUzO43lz1mxbVrP6LRmXSHpv2BXgl6wcvAsZ_Fc9BnhYOWmeAv ami8Q_OBpASrXqX7kAP9qu5izeiH2vzUrNlhwXM2ATyp6JLE20_CfI8Fbv_sMr7DEsbYcW2kULBM bLwlCGhRQoslm0OS_1TPNYgbtdfzfniqU.1u0KlaLUz1HoYs3wDjazGyJCA5hyEiGPgxgmKOqNMJ AH7nhk4AirpCJB5CaFihCiEDwjpmYITeSLITe3ymUn5BPeWGstMEPT38yKHUOTakm5d892IQMe_w uHamK_Tk7aiaE4Dt_3WNKJaDxzWwvvpvA9x.Hdl2y31dMnJLx6FW1crugjV_z0MPafmqx5UAuCR_ IOGjOD1dDG0a3MIHxUYT.FYf5q4LIOD9sjg0YPSV0_pu1nd6J1HIOoBYgjL6tfAg0_YaJZQObvyt Qwv2ggTves57oawPJhTJvaw9VKMAHtj_4dfz9dynPs1YAUf37XW0jahme56CAU63oMoLh9lsHEjn qg4q9APpFNIjtsWH7732rfs6yFPGYHlkXzESu8__U1lVSOUsdH1QHS_4JnRPzbh_ll1TmMsX1T7m pmNXZoGLzd5lHrCfGI7MbjyHWKVpnJhqcKmWO.nvXnmc_z9yYV1EJm4BZPg.z58JDOrF1nnvsXGs uyWK8aDP0sNKgw9IF8o9xK1OTaS5PPkGns3pfUoLYGQ4UKkOAAAOxt4FwmDAuTv_fAj8aPg8.BiU ueQf.rmmdotq6lcrmTyzEeRS7ZfVw5pqFkvfkUR3sI9uITTQtB81X0wrzMZDGurXZv5rvp1Vk2Q9 tIgC0p1S_3BHtiEfLthMhBPAu6zamXRWdD6qWRME28fn9hPe5Vnqc5rXAF8UkWuU1SxwWeZqsQkl rFszlgDnHS.EgWQWZQnnZLMBGs6NpP0w9PGrRh5CC18yhoTJMvOvSPUfKpWUupEBIq80uI55FOsB 0tK.WcePXrMY9WAb8t052Z1QhpseI8hF.Fv0KPHfWq9Wlh9GqHvpCBwlXfjwzadzU2SfH9_T8kpk 4Qx7K_643g0YZlVCDoapRFGfE2IbbzNzhUJQAfdcQyLqZtEI_M2Pcom6bm7pzlEqpdmHwXtm6DcQ ZNnWsxGq8JGsHbOsa17L04Dk9krSBCZVvu1KR0pgm8xiaj4r.Dzy36nvc4kJm2IbeA30iG0zx2TT oO.VLkFRCW_1DaXFPbjJYRjxqcDgg0IbXVFmQsrB4tkodehRsQk49TZMcdbfYqjXsxp86dMeNCbv wWpzRMreQPStb5exjjLJs2Fh34kuKWc6pso_EA39LWg81wjQEqQemGfdDVww9fOE.E0r_Y5GTXf8 QbWuIquZQD_VfCKSWY9lKGY_y96r1vhWKnoo1qYp.R6f0ZhTlm3j9pzGn_zv1DlimsdkMTtlq_iR sRO6j5pKddQpANM7nnl4GM8Q_4iDYSR59ZUCoRfjUCRsw9JrB._IXGzeycV21uM4Y6H0CHDNWvMl kPFvG8iGvLrrKwKpuVZXFolQ8ls_ADIAMng6B770jle9grV54yuXjyBdZOtLDsTfJWv40.urb8I_ Lvjjyj8WSz4O4i1t4XX7fIb3JKdbDEnF_iHyWEO4tLumDPPPHknCT3HEbYBgxQk9RqAQUfWJY4WW E0NIh_TVHW6ID46r1 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Fri, 11 Jun 2021 02:57:43 +0000 Received: by kubenode528.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 492b6126a7deac069939499b7a42bb5d; Fri, 11 Jun 2021 02:57:41 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Boot from USB on RPi4 8GB? In-Reply-To: Date: Thu, 10 Jun 2021 19:57:39 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3EE8D2-649B-4522-AD5A-7C308291802F@dsllsn.net> <43FAEEAC-EE36-4810-88AA-FF82AFBCC128@yahoo.com> <2F58272B-BD9C-464B-9A98-BF638971BA86@dsllsn.net> To: William Carson X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G1QWF0Fpxz3MTj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-10, at 17:22, William Carson via freebsd-arm wrote: > On May 30, 2021, at 6:54 PM, William Carson via freebsd-arm = wrote: >>=20 >>>=20 >>> On May 30, 2021, at 4:08 PM, Mark Millard wrote: >>>=20 >>> On 2021-May-30, at 13:50, Mark Millard via freebsd-arm wrote: >>>=20 >>>> On 2021-May-30, at 10:59, William Carson via freebsd-arm = wrote: >>>>=20 >>>>>> . . . >>>>>> I use a USB3 SSD that has small enough power requirements >>>>>> to not require a powered hub. (I also use a 5.1V 3.5A >>>>>> power supply as part of that context.) I've never tried >>>>>> spinning rust or higher powered USB3 media. >>>>=20 >>>> I view the power supply that I use as just giving a little >>>> more margin, not as a way to increase what the devices >>>> total to. >>>>=20 >>>>> . . . I'm not sure what's considered "high powered" but the = Samsung tech specs say this particular model uses 5.7 W on average and = 10.0 W maximum. But it does seem curious that the Raspberry PI OS will = boot this disk without issue, so I don't think it's the drive. I also = tried a Samsung 950 PRO using a different enclosure (QNINE NVME = Enclosure, M.2 PCIe SSD (M Key) to USB 3.0 External Case), but it = behaved the same. >>>> . . . >>>>=20 >>>> Then you need to use a powered hub for that device. >>>=20 >>> I should have just referred to independent power. You >>> had written: >>>=20 >>> QUOTE >>> I'm trying to use a SAMSUNG (MZ-V7E500BW) 970 EVO SSD 500GB - M.2 = NVMe, attached via the Geekworm X872 M.2 NVMe 2280/2260/2242/2230 SSD = Expansion Board. >>> END QUOTE >>>=20 >>> = https://geekworm.com/products/raspberry-pi-4-x872-m-2-nvme-2280-2260-2242-= 2230-ssd-expansion-board >>>=20 >>> shows that it has its own power connector and has an image >>> that says "please power x872 via DC Jack of XH2.54 connector >>> if SSD is not recognized or low power". Later text on the >>> page says: >>>=20 >>> QUOTE >>> Specifications: >>> Power Supply >>> =E2=80=A2 5Vdc +/-5% , Powered by Raspberry Pi USB port >>> =E2=80=A2 5Vdc via DC power jack or XH2.5 connector, Extra power = for the SSD >>> END QUOTE >>>=20 >>> So, if I gather right, you need to connect a power >>> supply to the X872 and another to the RPi4B. >>>=20 >>> Another image says "Note: NOT recommended to use SAMSUNG SSD, >>> if use SAMSUNG SSD, please close WiFi". Later text on the page >>> says the same. >>=20 >> A-ha, indeed. I just noticed that as well. I've gone ahead and = ordered a supplementary power supply and a lower-power NVMe to do more = testing. I'll send an update once I've received and tested them. >>=20 >> Thank you for hopefully pointing me in the right direction. >=20 > Alright, so, I ended up buying a WDS500G2B0C, which seems to only use = a maximum of 75 mW (this seems ... low, to say the least, but the column = is unlabeled in the spec sheet I found here = https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/= public/western-digital/product/internal-drives/wd-blue-nvme-ssd/product-br= ief-wd-blue-sn550-nvme-ssd.pdf). That document says for WDS500G2B0C: QUOTE Maximum Operating power 3.5W END QUOTE So at about 5V: about 0.7A maximum. Of itself, that is under the 1.2A figure. The X872 must take some power as well. But I do not find any W or A specifications for it. I do not know what other power draws in the overall system might be. Any combination that might use more than about 0.5A? (So: more than about 2.5W total)? Unless you specify otherwise, I'm going to presume: no. So I'm not expecting power to be a problem. > Sadly, it also would not boot from either of my NVMe-USB adapters. Is the failing behavior identical to before? If not, what evidence is it now producing when trying to boot? ("would not boot" leaves open all possible ways of failing.) You previously reported getting: QUOTE scanning bus xhci_pci for devices... Device NOT ready Request Sense returned 02 04 01 END QUOTE Someone else recently was getting that and got around the problem while trying 3 U-Boot extra steps. They are listed below and I leave in the indication of which happened to work in that context. The point is to establish a configuration setting before U-Boot tries to scan the USB buses looking for the storage media. Otherwise a "usb reset" would need to happen after making the configuration change. QUOTE > Looking around on the web I see reports of the: >=20 > Request Sense returned 02 04 01 >=20 > (and the matching Device NOT ready) mean that the > problem will occur and that repeating usb start > or usb reset again until it does not report that > leads to things working. >=20 > But I've also seen other, more complete information > indicating that there is a environment setting > (showing an example value): >=20 > usb_ready_retry=3D5 >=20 > to set up before the usb restart (or usb start) > command. It deals with the issue more explicitly > for slow devices. >=20 > Another one is (units: msec): >=20 > usb_pgood_delay=3D10000 >=20 Presto! using editenv usb_pgood_delay prompted for input, typing 10000 and hitting return set the value and the disk was found. It looks like the setting can only be saved to microSD. With no card saveenv reports Saving Environment to FAT... Card did not respond to voltage select! Failed (1) > There are also device that have problems with > large transfers and require extra protocol to > deal with transfer problems before they will > work again, U-Boot not doing that. >=20 > usb_max_blk=3D20 >=20 > sets a old historical value that generally > just works for such devices form what I read. >=20 > I see no indication that other usb commands are > worthwhile until one has avoided that "Request > Sense returned 02 04 01" message for usb reset > (a.k.a. usb start). >=20 > The reports of this sort of thing are not limited > to RPi's and go back to at least 2014. >=20 > If I understand correctly, usb_ready_retry and > usb_pgood_delay and usb_max_blk are part of > normal U-Boot builds these days. But I'm not > certain of that. END QUOTE > After a while of getting frustrating forgetting which combination of = image + usb adapter + drive configuration I had or hadn't tried, I = thought to myself.. what would happen if I tried one of the USB2 ports? = Bingo! It booted FreeBSD no problem. >=20 > So I'm not sure what exactly that means, except that I know the = power/usb adapter/drive/image is not the issue. For the new device, anyway. > I don't think I really "need" the performance improvement of the USB3 = port at the moment, but maybe that's something that will help = troubleshoot the issue? It would certainly be nice to use little USB = bridge pcb "cable" to have a neater installation though. >=20 > Any ideas? See above. >>> = https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/READM= E.md >>>> lists: >>>>=20 >>>> "Maximum total USB peripheral current draw" as: 1.2A , >>>> which at 5.1V is 6W. I either should have listed 5V or instead have listed 6.12W. >>>> That figure is the total for all USB devices attached >>>> that are not powered independently. >>>>=20 >>>> That document also says that a 5.1V supply is required, >>>> not 5V. >>>>=20 >>>> The power supply that the RPi folks supply is 5.1V @ 3A >>>> or 15.3W. Even the 5.1V 3.5A power supply that I use >>>> only multiplies out to 17.85W. >>>=20 >>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Jun 11 05:42:27 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0E4507CFCE6 for ; Fri, 11 Jun 2021 05:42:36 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (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 4G1V9Q5vCxz3lD6 for ; Fri, 11 Jun 2021 05:42:34 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.15.2/8.15.2) with ESMTP id 15B5gRqc025200 for ; Fri, 11 Jun 2021 00:42:27 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (unknown [136.49.68.36]) by mail.shrew.net (Postfix) with ESMTPSA id 4A1CD198718 for ; Fri, 11 Jun 2021 00:42:22 -0500 (CDT) To: freebsd-arm@freebsd.org From: Matthew Grooms Subject: Easily reproducible stable/13 kernel crash Message-ID: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> Date: Fri, 11 Jun 2021 00:42:27 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx2.shrew.net [10.24.10.11]); Fri, 11 Jun 2021 00:42:27 -0500 (CDT) X-Rspamd-Queue-Id: 4G1V9Q5vCxz3lD6 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.132 as permitted sender) smtp.mailfrom=mgrooms@shrew.net X-Spamd-Result: default: False [-3.13 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[38.97.5.132:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[38.97.5.132:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[shrew.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.86)[-0.860]; NEURAL_HAM_MEDIUM(-0.97)[-0.972]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RECEIVED_SPAMHAUS_PBL(0.00)[136.49.68.36:received] X-ThisMailContainsUnwantedMimeParts: N Hey all, If I build an up-to-date stable/13 arm64 kernel and type sysctl -a on a rpi4 system, it reboots every time. I've blown away the source and object tree multiple times and still get the same result. FreeBSD generic 13.0-STABLE FreeBSD 13.0-STABLE #1 stable/13-n245932-04c4bd7f7b5: Fri Jun 11 00:09:11 CDT 2021 mgrooms@x.x.x:/var/rpi4/build/usr/src/arm64.aarch64/sys/GENERIC arm64 Has anyone else been testing stable builds recently? I'll try to build a debug kernel and see if I can dig up more info. Thanks, -Matthew From nobody Fri Jun 11 06:00:56 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 708E87E9466 for ; Fri, 11 Jun 2021 06:02:07 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1Vby3bvlz3mJ9 for ; Fri, 11 Jun 2021 06:02:05 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Fri, 11 Jun 2021 08:00:56 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail202005; t=1623391317; bh=ka3kbAvVE2wbIJhrLVpVCH4cN/G4SNRDkHNXvoOIxWE=; h=Date:Message-ID:From:To:Subject:MIME-Version:Content-Type; b=RVX8SVw+i4fDYb91zZzYRNp5hAT0MEsiZMYwySU5BhFS6xwXBs+8mmYmgnZOONl3+ WmTSGDDu+cEgxJIYjNGUH1i4fnVQWLknnfaVOtvCwfkLLwxpNcFDKa4TnOPHsZXFm+ EBwQIr3RtDauyUOSkR6nIO3PDEngLscX+G73FJmcu6hopJpbA3uMiy6KTYsVhL3V6m 3tojlvgYBcS1pTPR0MFAZup7tcfaShsvSYJvcoN68jW8vBPTdCXEu8xVoo5+jrGgQX B6VEV53H9+0Cs2J3fIGQjOtOO/aX2V6s48V+wa4NphGqElRokMKQ0Vc0KjwWiTVPI8 X6YMWS8MGfp1A== Message-ID: <87y2bhuehz.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: freebsd-arm@freebsd.org Subject: Re: Easily reproducible stable/13 kernel crash In-Reply-To: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> References: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 Mule/6.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4G1Vby3bvlz3mJ9 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gojira.at header.s=mail202005 header.b=RVX8SVw+; dmarc=none; spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 94.130.200.20 as permitted sender) smtp.mailfrom=herbert@gojira.at X-Spamd-Result: default: False [-2.49 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:94.130.200.20]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[gojira.at]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[94.130.200.20:from:127.0.2.255]; DKIM_TRACE(0.00)[gojira.at:+]; NEURAL_HAM_SHORT(-0.99)[-0.995]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.130.200.20:from]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N On Fri, 11 Jun 2021 07:42:27 +0200, Matthew Grooms wrote: > > Hey all, > > If I build an up-to-date stable/13 arm64 kernel and type sysctl -a on > a rpi4 system, it reboots every time. I've blown away the source and > object tree multiple times and still get the same result. > > FreeBSD generic 13.0-STABLE FreeBSD 13.0-STABLE #1 > stable/13-n245932-04c4bd7f7b5: Fri Jun 11 00:09:11 CDT 2021 > mgrooms@x.x.x:/var/rpi4/build/usr/src/arm64.aarch64/sys/GENERIC arm64 > > Has anyone else been testing stable builds recently? I'll try to build > a debug kernel and see if I can dig up more info. I can confirm this issue: Rasperry Pi 2 (armv7), 3 and 4 (both aarch64). When booting kernel.old (from May 17th; e0f2b8aaf1ed) 'sysctl -a' doesn't crash the system. -- Herbert From nobody Fri Jun 11 07:02:50 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 35A9C7EB961 for ; Fri, 11 Jun 2021 07:03:54 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1WzF0WbSz3pm5 for ; Fri, 11 Jun 2021 07:03:52 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Fri, 11 Jun 2021 09:02:50 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail202005; t=1623395030; bh=Ne78xXxj8ZGRESAW367WCAjOo2Ijdij20XwZjVD/dNY=; h=Date:Message-ID:From:To:Subject:MIME-Version:Content-Type; b=N0EgrIxOddGxao2ueFHMuDSU1iH7eH6Ww2WEmdmUh5ruEUzE5GPUdYSR8HL5LlJ3M 8qH2xnHw8kpgxZB/o0qnyZ3gvslCkuS+S54nwagRITQ1JCyoi1hGRL2rlUjQAjtwYZ LzgoFeX2Evn9BydQb5hff/H79ewcV27XvIT8iy4DEAAdnRPhaEBpZHlsNPG9JsatQ/ pesYPDp2iV5g2D3wcqpm6Sc+ryCSAG6pFlQWuevcZtDxQ2QgCMWxuUYEOZoWBA03IU eThDNMRrectEM/qy3HY1/MeXD2SDcKkrFE2FzOM4EJqPOBsxsYGOtRpAsEvxu3zGAG xmT1UWl0qU/Eg== Message-ID: <87wnr0vq79.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: freebsd-arm@freebsd.org Subject: Re: Easily reproducible stable/13 kernel crash In-Reply-To: <87y2bhuehz.wl-herbert@gojira.at> References: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> <87y2bhuehz.wl-herbert@gojira.at> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 Mule/6.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4G1WzF0WbSz3pm5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gojira.at header.s=mail202005 header.b=N0EgrIxO; dmarc=none; spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 94.130.200.20 as permitted sender) smtp.mailfrom=herbert@gojira.at X-Spamd-Result: default: False [-2.49 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:94.130.200.20:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[gojira.at]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[94.130.200.20:from:127.0.2.255]; DKIM_TRACE(0.00)[gojira.at:+]; NEURAL_HAM_SHORT(-1.00)[-0.995]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.130.200.20:from]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N On Fri, 11 Jun 2021 08:00:56 +0200, "Herbert J. Skuhra" wrote: > > On Fri, 11 Jun 2021 07:42:27 +0200, Matthew Grooms wrote: > > > > Hey all, > > > > If I build an up-to-date stable/13 arm64 kernel and type sysctl -a on > > a rpi4 system, it reboots every time. I've blown away the source and > > object tree multiple times and still get the same result. > > > > FreeBSD generic 13.0-STABLE FreeBSD 13.0-STABLE #1 > > stable/13-n245932-04c4bd7f7b5: Fri Jun 11 00:09:11 CDT 2021 > > mgrooms@x.x.x:/var/rpi4/build/usr/src/arm64.aarch64/sys/GENERIC arm64 > > > > Has anyone else been testing stable builds recently? I'll try to build > > a debug kernel and see if I can dig up more info. > > I can confirm this issue: Rasperry Pi 2 (armv7), 3 and 4 (both aarch64). > When booting kernel.old (from May 17th; e0f2b8aaf1ed) 'sysctl -a' > doesn't crash the system. The kernel from the May 27th snapshot (stable/13-n245691-024a9aa7010) is OK, the one from June 3rd (13-n245852-4775325dd66) isn't. -- Herbert From nobody Fri Jun 11 07:18:32 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0BAD47EC675 for ; Fri, 11 Jun 2021 07:18:35 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1XJB5zRSz3qbl for ; Fri, 11 Jun 2021 07:18:34 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 217882604E4; Fri, 11 Jun 2021 09:18:33 +0200 (CEST) Subject: Re: Easily reproducible stable/13 kernel crash To: "Herbert J. Skuhra" , freebsd-arm@freebsd.org References: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> <87y2bhuehz.wl-herbert@gojira.at> <87wnr0vq79.wl-herbert@gojira.at> From: Hans Petter Selasky Message-ID: <6d268f28-373e-fd84-9fe8-9e39831760e5@selasky.org> Date: Fri, 11 Jun 2021 09:18:32 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: <87wnr0vq79.wl-herbert@gojira.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G1XJB5zRSz3qbl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 6/11/21 9:02 AM, Herbert J. Skuhra wrote: > On Fri, 11 Jun 2021 08:00:56 +0200, "Herbert J. Skuhra" wrote: >> >> On Fri, 11 Jun 2021 07:42:27 +0200, Matthew Grooms wrote: >>> >>> Hey all, >>> >>> If I build an up-to-date stable/13 arm64 kernel and type sysctl -a on >>> a rpi4 system, it reboots every time. I've blown away the source and >>> object tree multiple times and still get the same result. >>> >>> FreeBSD generic 13.0-STABLE FreeBSD 13.0-STABLE #1 >>> stable/13-n245932-04c4bd7f7b5: Fri Jun 11 00:09:11 CDT 2021 >>> mgrooms@x.x.x:/var/rpi4/build/usr/src/arm64.aarch64/sys/GENERIC arm64 >>> >>> Has anyone else been testing stable builds recently? I'll try to build >>> a debug kernel and see if I can dig up more info. >> >> I can confirm this issue: Rasperry Pi 2 (armv7), 3 and 4 (both aarch64). >> When booting kernel.old (from May 17th; e0f2b8aaf1ed) 'sysctl -a' >> doesn't crash the system. > > The kernel from the May 27th snapshot (stable/13-n245691-024a9aa7010) > is OK, the one from June 3rd (13-n245852-4775325dd66) isn't. > Do you have the kernel backtrace of the resulting panic? --HPS From nobody Fri Jun 11 07:19:16 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 744AD7ECA62 for ; Fri, 11 Jun 2021 07:19:19 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1XK3143lz3r30 for ; Fri, 11 Jun 2021 07:19:18 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1623395956; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8zkbNI+Y5X4mdn+StenQibdJn/oeJo5i4YH/Oc7Zu58=; b=Cd2FhVCG8YSUsIisePx+5y/ZnkOrBfnDPi8vXjgXA6FLdUy2aajgdWIHm/J1BY7GTiITUh /Stsu5yZYZ1zyyqRG+GTHDgGsDYgzAAaYMTPg/tfv1xpUzD6zmxw06mtNm1Ov+CJGKspEW J/8JqZoEgHivdwc9Hj7TudqMAvO+kiQ= Received: from amy (lfbn-idf2-1-644-4.w86-247.abo.wanadoo.fr [86.247.100.4]) by mx.blih.net (OpenSMTPD) with ESMTPSA id e0726524 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 11 Jun 2021 07:19:16 +0000 (UTC) Date: Fri, 11 Jun 2021 09:19:16 +0200 From: Emmanuel Vadot To: "Herbert J. Skuhra" Cc: freebsd-arm@freebsd.org Subject: Re: Easily reproducible stable/13 kernel crash Message-Id: <20210611091916.9e3d5fa55303a68dbfb1f6d2@bidouilliste.com> In-Reply-To: <87wnr0vq79.wl-herbert@gojira.at> References: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> <87y2bhuehz.wl-herbert@gojira.at> <87wnr0vq79.wl-herbert@gojira.at> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G1XK3143lz3r30 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 11 Jun 2021 09:02:50 +0200 "Herbert J. Skuhra" wrote: > On Fri, 11 Jun 2021 08:00:56 +0200, "Herbert J. Skuhra" wrote: > > > > On Fri, 11 Jun 2021 07:42:27 +0200, Matthew Grooms wrote: > > > > > > Hey all, > > > > > > If I build an up-to-date stable/13 arm64 kernel and type sysctl -a on > > > a rpi4 system, it reboots every time. I've blown away the source and > > > object tree multiple times and still get the same result. > > > > > > FreeBSD generic 13.0-STABLE FreeBSD 13.0-STABLE #1 > > > stable/13-n245932-04c4bd7f7b5: Fri Jun 11 00:09:11 CDT 2021 > > > mgrooms@x.x.x:/var/rpi4/build/usr/src/arm64.aarch64/sys/GENERIC arm64 > > > > > > Has anyone else been testing stable builds recently? I'll try to build > > > a debug kernel and see if I can dig up more info. > > > > I can confirm this issue: Rasperry Pi 2 (armv7), 3 and 4 (both aarch64). > > When booting kernel.old (from May 17th; e0f2b8aaf1ed) 'sysctl -a' > > doesn't crash the system. > > The kernel from the May 27th snapshot (stable/13-n245691-024a9aa7010) > is OK, the one from June 3rd (13-n245852-4775325dd66) isn't. > > -- > Herbert > Can't reproduce here (running a stable_13-n245022-7d588615865 freshly built) on sopine. You could try to find which tree of the sysctl causes this (sysctl hw ; sysctl vm etc ...) -- Emmanuel Vadot From nobody Fri Jun 11 07:46:04 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3AA487EE789 for ; Fri, 11 Jun 2021 07:47:13 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [IPv6:2a01:4f8:13b:240c::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1XxF05C6z3sqb for ; Fri, 11 Jun 2021 07:47:12 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Fri, 11 Jun 2021 09:46:04 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail202005; t=1623397624; bh=Tc1loaK3tIpwmaqCcsLgsoS+0kSgrcKrm6HSTEv1Ea4=; h=Date:Message-ID:From:To:Cc:Subject:MIME-Version:Content-Type; b=Kh2KGzuMabvRET+xljtD805IBUG6pSQcXcnDgTbByyAk5RfY56LruDz6fA/W2fwsB EIz4SqH20mlQX9rdtUOeh2S7AXLMaXllBJ168rrsdTi8uiIcLq3Nzobd8oX5b72XWa NJIs5igrYvl0Vh3VMT3oNVjwn4OMH4C7OFbIqYcTUimpMb4y3JUUPd6DRnVLaywPTm ifG6A9jiyRq+Kq8MsraaPD/JVq+WGJIwnywU/QhDWH7DcfbvruIEd/q7AJ/StIJCew 5u7AptYWskqFlFMg4UZJuJHy12Duk5qMviyPy9NOsPcLovjFHmIQP8tJmVPMK5LHns nrrpWR9myrLVw== Message-ID: <87v96kvo77.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: Emmanuel Vadot Cc: freebsd-arm@freebsd.org Subject: Re: Easily reproducible stable/13 kernel crash In-Reply-To: <20210611091916.9e3d5fa55303a68dbfb1f6d2@bidouilliste.com> References: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> <87y2bhuehz.wl-herbert@gojira.at> <87wnr0vq79.wl-herbert@gojira.at> <20210611091916.9e3d5fa55303a68dbfb1f6d2@bidouilliste.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 Mule/6.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4G1XxF05C6z3sqb X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 11 Jun 2021 09:19:16 +0200, Emmanuel Vadot wrote: > Can't reproduce here (running a stable_13-n245022-7d588615865 freshly > built) on sopine. > You could try to find which tree of the sysctl causes this (sysctl > hw ; sysctl vm etc ...) net.inet.tcp.lro The last displayed line is: net.inet.tcp.path_mtu_discovery: 1 -- Herbert From nobody Fri Jun 11 07:56:18 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 21DA07EF5C0 for ; Fri, 11 Jun 2021 07:56:21 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1Y7m5nrKz3tqB for ; Fri, 11 Jun 2021 07:56:20 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1623398179; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lIt1qGdLCN/aG9thc4uFArdx8ey/g+s7esHRIc2AOws=; b=HCJhmQnAIosFHCG2hHWKcmAewoA2/oCcNjEEXLManZOFqi5YuMptA8mjkMzpcz1Xw8rje7 t0vd6F8JR0l61BzeM2qiqvkf6+an5rU1w8t8Vm4Q0gWItHJtkxwbbCCAISzTAIolynVWKq lRpMdbjiDXVKDKCeO+0u88PdORyQLT0= Received: from amy (lfbn-idf2-1-644-4.w86-247.abo.wanadoo.fr [86.247.100.4]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 795e9b24 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 11 Jun 2021 07:56:19 +0000 (UTC) Date: Fri, 11 Jun 2021 09:56:18 +0200 From: Emmanuel Vadot To: "Herbert J. Skuhra" Cc: freebsd-arm@freebsd.org Subject: Re: Easily reproducible stable/13 kernel crash Message-Id: <20210611095618.5df5abbe6696671a8966af65@bidouilliste.com> In-Reply-To: <87v96kvo77.wl-herbert@gojira.at> References: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> <87y2bhuehz.wl-herbert@gojira.at> <87wnr0vq79.wl-herbert@gojira.at> <20210611091916.9e3d5fa55303a68dbfb1f6d2@bidouilliste.com> <87v96kvo77.wl-herbert@gojira.at> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G1Y7m5nrKz3tqB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 11 Jun 2021 09:46:04 +0200 "Herbert J. Skuhra" wrote: > On Fri, 11 Jun 2021 09:19:16 +0200, Emmanuel Vadot wrote: > > > Can't reproduce here (running a stable_13-n245022-7d588615865 freshly > > built) on sopine. > > You could try to find which tree of the sysctl causes this (sysctl > > hw ; sysctl vm etc ...) > > net.inet.tcp.lro > > The last displayed line is: > > net.inet.tcp.path_mtu_discovery: 1 > > -- > Herbert > So just doing sysctl net.inet.tcp.lro make the board panic ? -- Emmanuel Vadot From nobody Fri Jun 11 08:14:47 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 71F6611C8DC9 for ; Fri, 11 Jun 2021 08:14:49 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1YY52CzZz4RGg for ; Fri, 11 Jun 2021 08:14:49 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Fri, 11 Jun 2021 10:14:47 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail202005; t=1623399287; bh=gn2aDAkc92FaqTS9g1tNfWaQSmwUMdNFwjt5aeSff1o=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=HuFL0m62iNOOVjQNZZg6HGeS0Hp3hm/ZPso0bWPERjDBDEKR4Q6jkkRp+i28NlQyj oeMMrlvlXaIjkShiZpXeBM44J62QANqAUkBaRz4m3SFHvGDz1BoCUmgN1WCSQCkBlW KJC8/atcEkV5GeWYix7OQ/BubIPrZdHWrJLnZiFMBtqhgWx7OIPxm/nSWofaXCnlnG DYMFF9rO8RvtBXWX41UmSl41/dhMyBBzBMrsFQnNkOzB+vacD9ghh9OylMhwBlkJKV 5Bv4Mf22pZhexgWkjD3KA8POot6emWSIVvSj3fcgZgxILysSWxhtbOHmslcMcVDbz4 Ms+XZp+82vHug== From: "Herbert J. Skuhra" To: Emmanuel Vadot Cc: freebsd-arm@freebsd.org Subject: Re: Easily reproducible stable/13 kernel crash Message-ID: References: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> <87y2bhuehz.wl-herbert@gojira.at> <87wnr0vq79.wl-herbert@gojira.at> <20210611091916.9e3d5fa55303a68dbfb1f6d2@bidouilliste.com> <87v96kvo77.wl-herbert@gojira.at> <20210611095618.5df5abbe6696671a8966af65@bidouilliste.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210611095618.5df5abbe6696671a8966af65@bidouilliste.com> X-Rspamd-Queue-Id: 4G1YY52CzZz4RGg X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Jun 11, 2021 at 09:56:18AM +0200, Emmanuel Vadot wrote: > > So just doing sysctl net.inet.tcp.lro make the board panic ? Yes. (And why is ~/ always reset to root:wheel?) -- Herbert From nobody Fri Jun 11 08:25:31 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 79E9611CA0CD for ; Fri, 11 Jun 2021 08:25:42 +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 4G1Ynf1bnqz4ScM for ; Fri, 11 Jun 2021 08:25:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623399939; bh=uANw3TjbcJHsI2l7ro2zGqaOVCIxGzx01pJkq2RJWg4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=bgxr+KqrxWL/GeKQ+HHWzmcJFTpz8Ng0MwUR/w/LNpQ7OV88riCPFmgNAiLHWcs4vXGT3Z/HcAUgR/3Q/BJ0SMrR9DFHdXmyuooA8WsmRVDTOrOY0s/nQGWxVS3bM7cgoHS1kqBet4qK3LDjvFvM/JHdMZGU84bsC/iNvWmRhSumbA4qgq+tSvL5n+vyqpaZ1qnfusTixl3TUr+z8ZjBIewemtBYdbMlIWOc1G/jJijWmv/lDFZlP//8a+2Fe9fxO8rus/Km27T9W6ac4TD6SOh6zG2ZxLdBcoTK7L40W1WdlBNLikK0xAWcyhT1Un06Lu6G4PLAeO346Sr63JqQYw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623399939; bh=wuOWo7ubdKPkDSxOcP+NMbUdu3Hik5NYeVn1si2HxZC=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cZED+EvXoA/SFtTNC0PTV8sr4M+vHV8x2JR1zz6g0xSXjqHx8Du27033V8UXo+REefXUSMO0Ot9SmZ5T5Y81P+7HYG8I3SkuH2BV9EAGwBHUoftOzD+hQgP+ZrG0Tkp9yPdooCc0RM28Wn1pD8xraubU+ey7Z6N5AudtmFCjVNwwLWVyhL++I3UGsLHNJs5gP9jvWu2MlIx2QwneUBZLZICpWN5yes4zLY9mWD7QpfaNUTk8BIbPNXk3VULam77lwvtNoH/++MrNjP/SmzH4ygsjad2Wpw/DTc0Fa5GIwH4Plz5P7u1+Cyi6Jow2psx+lXJ/sO6JexhHkTV5hpAPYQ== X-YMail-OSG: dt4WNkMVM1kdKFx.iPQtqdBnHxQGmIk0hccIGFqrPYqwwH6xhHIzkIzabiZFWA7 b3mghHjbf9fWdYzwk2hlxOb2WAA98PntWCAjOfPmiFMjOSTZhvkK7Y7EKut.E2uLrml5W98q7LWc NSPMCPDFIiVrpwOsqb6lCUvQo4ElADdjiU2vEXtXFvCz6fFF19fqiEIwpIgt8pI.T9PZLaS96OdH .qjmCT0QgrocCx_2SKnNWX2bJTDRRYmuT.22kRHyJjkvZOE2RKqjW6OQQAWGrClImmpzykk9Lzq9 zws4Iic21A0pO0vzzOqJwg1uqoMaux4NT1V5RzgKuY8AWLRmhSpw1.VxTa29cqaPpsUwsZDs_zvr TkK_uPzujp39BSgLWwOiPJ3zv_RTxod6UzHnYR8vI2BmqqfAxJeu_E5iprY013zLjPQHRiKjx17t rwkqTtA8sFLDkwwbCDJqHzVXAjUJsPCMVQ2GpEWQsAVjyZH5YTvl2U74iPsuCphS1h6gd1TOSoWB eiB6FTFpPSivOK6sPflj6dNGdb.z1ztoGieIEo_voRnoBEsnhclSaeDZO6DKZBy87eeuWgJ.WPAm ZlEgb5fVi2wkxi_j9uwvr5l4xjGs43SLv4nEhn5NwFOmZO97PKFOybFwKwGW4.W.DbBpRRHkhOEk eYaCMibmnlGKc6ZEQ0aADc7BTZGeU98PBPQYwpLWMERt_SGgA1lBCXnhkEPPaMpRzEaL313gRYWL 5qnxV4OQ7mIoblGRISbSJPVaY0X.SqEAO78qTI4PLoePEkOsaCOf3XCCalL4Hk5K1KYHczWAjwX1 pqXQL8Icl3XxrOQkXlgAzO1px42hMQHmzCL41vPtamXt_YeJUt_gyZR2ywDbNE39GM6TUi5FdUxE BhGmGxX4u_1ywlFNHNLIjUKe_lnAB7qWtg6OgN_gMXArrRwvhOpS9fBI7zTdQHzyzTHPqJ6wR1k6 CJwlH4DUPp7iNpazZardunURp8ktdibNuLT09pGe1vdnCHtxWTGdO5b_pRR54Ewg2NOE4DDa20Bu Mnya3ZqxFfhxhOAL9yQR.uRq6wVyQ7Sd3hQHDQygV6wrekSwSbR4wEvxmnxaUTmREQi90Fq3Gzok NWF8HrMAiozCpKTN4ejisTQ7Q_VVyODG1zlt.wOvzPyBsHM9nWSyb.VoR_ow84PUH0VLJ9eURqDh anIDEOq7Bx67C.fvJn7c9hZ7KyOAEbiJCrPJvTb1fJjEih3jTyKkfWrDwMYxhFNPVmwbJiv3VdW5 fJA4rUbWCp8CTb7rnwZts6YwdDDKtLEP421d_S5m7P4LzBCfemSB5rrF4k3q54oFh.pl_SSigOTe OAAF1uewNfDgDR7rO3DcQXxUM91SRh9oLzXsAYRR3HRfkoRF_a2sdVgtcMTg1zXJCV3XMthMmDm_ g1lnL4FA1qj81DptrPBCkune9X.CGG2bx3KkVrzLRvMduHYHhIIiCdbvFJBQ_cglB.ca0.Jto9i5 todVIqEh23G1aQ_7LN0s3sYvSwbbUszQcJUSjk6Pdkl.ylKh2VV1HEZMHyW1dEIroBkO63Mq4Fla 0BQc6y84i7TPjAPjGmYWZefldMkQKKjy1xVwfHdamldgBnkT6YvL0E4Uv2m_akfBwYWgqIYBusk. iW3K1ij3nbB_lBNvkqzY2eCU92gGy.WFyR2K0jyZPQQ9pPeo_Kx2FWiZJ2211vjANLT3tjB83sOW 5dpYB7WAD26HXJiFOYX9iJjjaEbJFgiDZHUwVz9aNzO.QxaLSkno8H7MS.cgz2_l0Uw5b6M2TKdS b9SoPu3euAA1POOrc28gZ2sHEZ3txLqr4Ei.lQumlThb8gX.iMjEUPx5pGxGp7ZBmLfgAHsoTNqb kBZ2O2JM9ORpjZZlAWGmVFWb.bIgHNFJ0f5vjo1KOlSklNNSqPkhDrGxVHnfTFGRH1YlIfXbewR3 CzXoPl7F7nQCXBbaPHl4NOBJpG8LOs8uJ0S2ZHTRGi.y7jiPlLDeQMa0SCZSNAUThJxQKjHjQP1X JFIUEJvzaDMn10Ki.s3v8C8CyBs9b_YgE7tHEW6Dwg5o8MdvBNTM2nm1EzZSOhIuYiOgqb0fpyOj LcomM4S0tInnbgYY3mKXtjUErOtwhFZFrNuUinOU1BZx3hWCqPEDHTNG89EaAlyN2tfedkLnwcfE 4I_HMcQOB1JTMp_ITEyP9gxtdj4vprIs4Pca8dJSyAPCQ7cge0dBt7iS33uKtLjOL778Sm6T_9FO 7nAzQ7YjdAPywL3Wdv2LtPUi2SY95XnM3tupWAvI.yHGf5DGAzpyQ7Jfca64VOZX.lvrFubeTz9F kaWUcEAr.rPAMvjrn5WsB72kfQ1Fhe.RLf_vIxuzkkT9C082Q2uW3VhFzO0U28ZF2uGxbRjltLCP Qa.X6Ao0uHVTEgs6y8nicnxjunxkhZp9hCE4oqXb1XTpazt9zyTB4OBR7_EiwhSc1_ICuUAigSiP 8oj6B1TQsiUcmjXB9dlTc5sG6TlQQtS8lK4u7bGKl X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 11 Jun 2021 08:25:39 +0000 Received: by kubenode508.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3ae65d6f1155c054820f55debca0c9e4; Fri, 11 Jun 2021 08:25:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Easily reproducible stable/13 kernel crash In-Reply-To: <87wnr0vq79.wl-herbert@gojira.at> Date: Fri, 11 Jun 2021 01:25:31 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <5675A430-06C2-4424-B13A-4327F37F82FD@yahoo.com> References: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> <87y2bhuehz.wl-herbert@gojira.at> <87wnr0vq79.wl-herbert@gojira.at> To: "Herbert J. Skuhra" X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G1Ynf1bnqz4ScM X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-11, at 00:02, Herbert J. Skuhra wrote: > On Fri, 11 Jun 2021 08:00:56 +0200, "Herbert J. Skuhra" wrote: >> >> On Fri, 11 Jun 2021 07:42:27 +0200, Matthew Grooms wrote: >>> >>> Hey all, >>> >>> If I build an up-to-date stable/13 arm64 kernel and type sysctl -a on >>> a rpi4 system, it reboots every time. I've blown away the source and >>> object tree multiple times and still get the same result. >>> >>> FreeBSD generic 13.0-STABLE FreeBSD 13.0-STABLE #1 >>> stable/13-n245932-04c4bd7f7b5: Fri Jun 11 00:09:11 CDT 2021 >>> mgrooms@x.x.x:/var/rpi4/build/usr/src/arm64.aarch64/sys/GENERIC arm64 >>> >>> Has anyone else been testing stable builds recently? I'll try to build >>> a debug kernel and see if I can dig up more info. >> >> I can confirm this issue: Rasperry Pi 2 (armv7), 3 and 4 (both aarch64). >> When booting kernel.old (from May 17th; e0f2b8aaf1ed) 'sysctl -a' >> doesn't crash the system. > > The kernel from the May 27th snapshot (stable/13-n245691-024a9aa7010) > is OK, the one from June 3rd (13-n245852-4775325dd66) isn't. I tried the stable/13-n245765-bec0d2c9c841 based bectl environment that I happen to have in place on a RPi4B: # sysctl net.inet.tcp.lro net.inet.tcp.lro.sackwakeups: 0 net.inet.tcp.lro.lockcnt: 0 net.inet.tcp.lro.single: 0 net.inet.tcp.lro.compressed: 0 net.inet.tcp.lro.wokeup: 0 net.inet.tcp.lro.fullqueue: 0 net.inet.tcp.lro.entries: 8 net.inet.tcp.lro.hold_lock: 0 # sysctl -a > /dev/null # No crash. That might narrow the range a bit unless some other context-specific issue is involved. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Jun 11 08:40:22 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id ECFD111CB199 for ; Fri, 11 Jun 2021 08:40:23 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1Z6b5dX3z4Tw2 for ; Fri, 11 Jun 2021 08:40:23 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Fri, 11 Jun 2021 10:40:22 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail202005; t=1623400822; bh=N86ILcDmUX+g9A0VZPKf6tGQNxHck6PDMNNpwG/GYdw=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=oqZmC6DiaDBC0EQo0rRn5MLj4vKLgKExFEo9SkTdDHUA740Z1ZojOsuJhoX64GMZu eX+1YD2aAUTZiF//pNndmrfo8O3SkeDVUhV4Flm6h1H7Qs4Z/5tUymj4j0yNpYfQuI MTtDuwI04R+6yol/mT0ylFDWE5RROAsUmvUS0E1RYyqzISH/ER2CCqglFZzQGkh6O6 n1hKL6UDHskVs+KOo+vQRrsYMG3OZU0yVSafbdT5xUTnbHwkhR2TLVeLIwerc8v14Y xHe/ZcRftXYphVR30zRQ5P1x91lHbQjYPq3bHDuQmqEh0ihuRUO1rOOsiswegceo3k 4ItCtCXTEOTag== From: "Herbert J. Skuhra" To: marklmi@yahoo.com Cc: freebsd-arm@freebsd.org Subject: Re: Easily reproducible stable/13 kernel crash Message-ID: References: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> <87y2bhuehz.wl-herbert@gojira.at> <87wnr0vq79.wl-herbert@gojira.at> <5675A430-06C2-4424-B13A-4327F37F82FD@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5675A430-06C2-4424-B13A-4327F37F82FD@yahoo.com> X-Rspamd-Queue-Id: 4G1Z6b5dX3z4Tw2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Jun 11, 2021 at 01:25:31AM -0700, Mark Millard via freebsd-arm wrote: > > I tried the stable/13-n245765-bec0d2c9c841 based bectl environment > that I happen to have in place on a RPi4B: > > # sysctl net.inet.tcp.lro > net.inet.tcp.lro.sackwakeups: 0 > net.inet.tcp.lro.lockcnt: 0 > net.inet.tcp.lro.single: 0 > net.inet.tcp.lro.compressed: 0 > net.inet.tcp.lro.wokeup: 0 > net.inet.tcp.lro.fullqueue: 0 > net.inet.tcp.lro.entries: 8 > net.inet.tcp.lro.hold_lock: 0 # sysctl net.inet.tcp.lro.sackwakeups sysctl: unknown oid 'net.inet.tcp.lro.sackwakeups' # sysctl net.inet.tcp.lro.single sysctl: unknown oid 'net.inet.tcp.lro.single # sysctl net.inet.tcp.lro.hold_lock sysctl: unknown oid 'net.inet.tcp.lro.hold_lock' Still trying to get a crash dump and a backtrace. -- Herbert From nobody Fri Jun 11 09:02:12 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DC12511CC61B for ; Fri, 11 Jun 2021 09:02:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.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 4G1Zbt4SQkz4WZ6 for ; Fri, 11 Jun 2021 09:02:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623402136; bh=5CEkO9tpo5YK2WzuVfsh/fs7iP0/dUj6G4EYMendJUY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=lLDQm0w90Q6CwYo2X62t71mbXaXWiullwc4L67rL8kG6L8PlUTO+MBxRWs8S7tTdk+mejmQ85bQIlDxJVUy1Dxdg26IE9XHAG+HLhSi9nQ0sOcoHBU3HWY8F1xvIrRzsgHu7e99KTI5yDIqz4E6sxg61Qn2sKASzgfVtXac1HPzvBrwif6Y1UK7sL05rhLQI+c6j1xCazKwEJH8uUymciNcM0EqXknDedb4XBI743DDGRSWswk4ociVFm9DcQd1srUVVtMF2W3RKb4+fz55R64rjN2Mz1d44m7ljrHGpqIjsxkYu09N3brtjciH8Bc0VckqQUS7iqY93e8KKV9Yj5g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623402136; bh=rCYHG0n0BuBOdI2H5SrknL+A4mvdacwZQBFVt7dwle8=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=eNli2hFrwyNnMQHlKsconGJMK6sSYHqe4NqVIZnfbQ5K7VtrfFyaQXvvMEGzt86HDSJzV9TO3bXPK+pWNKsqPDHlJ22aBJwixw1RYisH8CtijG1HZItUbS4PwzdQO9OMdPQaVvD9XZXabUU67vAO/I6aLItV6GYIS4nIeRN1CIk4JEyhCbRa+8Pgw9ynkEpFfK7PkQcOIP0RPisev2oEHIs1ETKsARekJihxTeEzP6tK9XbSae7ldiPf+UaynpiWtvDhg4hhLXXtD2a8tHJ3W2Xi9nFcRDvqRcIy9vg2m56Oew2KekrSSWnD0N5ONabR5bx7rBL9r8pjbORmz7533g== X-YMail-OSG: iSvbM20VM1mzN6PZJU6bUkilVJfevmobvjiK7BXETSBzVuV7ZEyM7ZzvuzXRtTy CYYakcoCKqVTmdgqk8W_6CpE6Dpz3xHW8nHBeZo.z1.6uzM3qfQzLpyS48tAVG1h_L5J52vNeGIe RtKHuPlsny4Nj151.kOlO3p78S_4iJyK_Q7uXEQ2QbD.62N1FlnhiJ1121Jxl8hdwkJ86zX_zPIN fvwiH9BE8nRmdsVKWuKIcYkgMFLKA6s7.bK8feV5fMLS5g64ZBNfvLo9S00vMDB_fQm3XbLAam2i 9LGMtJYqnECFqsDJMbJh1jLjtbCHUHmS8KnHGWBPxdKtSOqZOpKSoEbtSHpk_SsZOVaLPUUVfday in.aQcspf0zPWPLmoyLTUgqHAIREqDFW3IaAQzKcxeqOVSlYherdQKvIWxdp1ut6BpGgy.geZN3W _vFEO.2j6z_GL9uvpIS2S6Zd4PXZ0EzooeEkPKOqnBA5uzlUAgXHl6UpDOxP0CcpIDBsnRwQvAL5 V4iGBqhUX8Wx2CaricCTF7wCjY4tBvNAL4yDX1Hz2uu5CZPSI04qf_7DC8kNtZ1HUQ.sPBu2vcfk ZpVerabaLoZnb_gcXyPHJ9zD0J3b1UWGGfI8j_8ZLCWtW.0kVIYfrFu7xjv1XLGqCZygyFE0Clbs tiMb19fekvvk8mw0nfNlZfdcR00iVPKJU2Q5Jgh3FIbkq41It7qGerqiTTknM8MksejZ5100eVkh NnWpoDB_agQH_MBm3yX93KXGcz1OFtNc9OE9spUZU5xgK6MUVt_jYiSYTkgKbxQeTfUMuQajIqzA KHJctMUxK0KABTHVWrDNsPdPzAptAZPYhmtrjSB0f14jiMOl9N.D7BSkOYM7rPP2mBC51NW50.oS koeDtRrM7V6CfA3GUl1cr8XOF3Zoz9BXZ77PogANmaEVrkhPBQCPhF70O5ka19p0AIwYOYMXizrg rdbanZiTozKwdkle25GLizNuUdBKNHgePfE8f2EBwCalV8_BAY3SJJKf_d6V6zeOnPKSzfb7HEqU dbb3MigBYORcv8c.PzpNR16peAO2sOPGMhFmFOjqiFhuQxs1BpjpRJko6jA8lwXfQ.ghtB6uuLUn _JfPOtFcNgiflC1lIbM75loHf4hdCRjMZoj85WfDZ1CfnxBssSS8RrH9VMQ9_JhRqi62DvKIdci3 qDZEu.MSQDUuLRPsenp8vqumuRvG2taQz5uW2vTuuKPLMCZOt.dcHZqjbQqTNG._xu.Yhj1yZa3W rg4Y1gJgREAbbKOv2rHoZ0z9LNsmLMap_fiICVEqJmcLq.x.HmfrlPy8EMTFTuyIDj__jD2owDLY ZnDPybzsgDXwYES6HcOxfGrbUDCpaOnI0GNDgrzPpFo0NdIroGmcX0Nf8AUfi3kgsme1r9eiA.Uk jBEU.X04ZSAFxX3ejwgxXz5LVUg8Xvx0d8krxSIzsV_DzwcxwEcPmU5P7C.1UaGUFXbxSbKnIs2e qeIKFSPfLcVWbI0c0kXT_rX24.j3tTzRMHrm7.7CEykUytIOtEUdI.N_qYbPoqczl5ea1CqswskM .5hpyT74CEavtBFj3koMeUibPjH0OjAAZqtTgFMijDAIhPpAJKwPGjwAAc1iS34eBMXg8cKbGVih NyHxgi.bdlNxKkDukRVh7snfXsBH931ptCBMZBDWKWGYuaEf2gNOENGyTB3xcEL8hQXbViKWFEMn RejYgoM2fLW_42xV8vJ8soIbelD0V3R8LlCpy8hs5aV0m.YeG_A7StI54qZLn1S3TgV4HILiDppG JBkVLqC_LXjKg6yQmDAA_1GAlnSY6bdHvZ1nFMzFSJkt8z_taKaU4_JNMvDZnKP8vDRKiSU_xtuY dPee3pXQpAT6w2IRigKOT9IAKzUje3EhO2QyT8i7exFDncBqUD1sHlp_CgLXlUwA4kkwU1i5kYMi Vt72dybhsWpvtVvI5Ej.m5rEF2jR3icHXVwOcC4RGNKRivmRbG1KPNuD35hm97gWRGodWM9oUilD WPRdI5jA4ZQY4azHCyScoHSYOTrn4aQdeo8px7nsK.0NUX1p4.DRWJKEGFrgSptaGfUlDolWSuQ9 x2qWsIo7FZBywtH6vklZ6EGL3QSESNjcuG3NrjRXF1TgNZplLEFqi7eEtgAGSqB9mvsyYtF1n3pE F3BKJhZ3p_J9lcLEyfnSbr._KVoJd91.SrlpNn_umKmSUDbUWVLXcsrRKs1ECO54a9ptNxUYQt3. iof0pO7LGcC7bkBG6Ult9dQtvhIY_g1M2UqK4gEp9A1x6gaOKpYz_pm79wO2wHFUNzEUcTytIBzI oB9LjuVw8UiEJLK_whLXbJQjwW_ZzuiWcCJkDy4wXTn8jYYB_ITC6Do8.PH1etzeJ0UUHjPrAn.e Lr9taxoRiDqZ8Q0Xb2AAAnPy..d6qeBWgOBzOiRM8Fm8inyjnSOFe5aMVGBvHo2Hf9N6hp.M2DRh un.jFPL4I5G7LsyuDQboVyQB1hvI6paQ7ILMzhNimhGujIXIBVCdVEqBXjtmcTYM84tgmWM5vmDs tD1MckSPlVOsNvUEMg28q X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Fri, 11 Jun 2021 09:02:16 +0000 Received: by kubenode536.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1bf0b269b4b9d2943ae083d9e261c6ac; Fri, 11 Jun 2021 09:02:13 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Easily reproducible stable/13 kernel crash In-Reply-To: Date: Fri, 11 Jun 2021 02:02:12 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> <87y2bhuehz.wl-herbert@gojira.at> <87wnr0vq79.wl-herbert@gojira.at> <5675A430-06C2-4424-B13A-4327F37F82FD@yahoo.com> To: "Herbert J. Skuhra" X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G1Zbt4SQkz4WZ6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-11, at 01:40, Herbert J. Skuhra = wrote: > On Fri, Jun 11, 2021 at 01:25:31AM -0700, Mark Millard via freebsd-arm = wrote: >>=20 >> I tried the stable/13-n245765-bec0d2c9c841 based bectl environment >> that I happen to have in place on a RPi4B: >>=20 >> # sysctl net.inet.tcp.lro >> net.inet.tcp.lro.sackwakeups: 0 >> net.inet.tcp.lro.lockcnt: 0 >> net.inet.tcp.lro.single: 0 >> net.inet.tcp.lro.compressed: 0 >> net.inet.tcp.lro.wokeup: 0 >> net.inet.tcp.lro.fullqueue: 0 >> net.inet.tcp.lro.entries: 8 >> net.inet.tcp.lro.hold_lock: 0 >=20 > # sysctl net.inet.tcp.lro.sackwakeups > sysctl: unknown oid 'net.inet.tcp.lro.sackwakeups' > # sysctl net.inet.tcp.lro.single > sysctl: unknown oid 'net.inet.tcp.lro.single > # sysctl net.inet.tcp.lro.hold_lock > sysctl: unknown oid 'net.inet.tcp.lro.hold_lock' Looks like main [so: 14] does not have those. > Still trying to get a crash dump and a backtrace. Just for reference, booting 3 distinct bectl environments that are on the same media: # uname -apKU FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #4 = main-n247017-e5f5b6a75c0a-dirty: Sat May 29 01:08:39 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400017 1400017 # sysctl net.inet.tcp.lro net.inet.tcp.lro.without_m_ackcmp: 0 net.inet.tcp.lro.with_m_ackcmp: 0 net.inet.tcp.lro.would_have_but: 0 net.inet.tcp.lro.extra_mbuf: 0 net.inet.tcp.lro.lockcnt: 0 net.inet.tcp.lro.compressed: 0 net.inet.tcp.lro.wokeup: 0 net.inet.tcp.lro.fullqueue: 0 net.inet.tcp.lro.entries: 8 # uname -apKU FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p1 FreeBSD 13.0-RELEASE-p1 #1 = releng/13.0-n244744-8023e729a521-dirty: Wed May 26 15:20:08 PDT 2021 = root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/ar= m64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 # sysctl net.inet.tcp.lro net.inet.tcp.lro.sackwakeups: 0 net.inet.tcp.lro.lockcnt: 0 net.inet.tcp.lro.single: 0 net.inet.tcp.lro.compressed: 0 net.inet.tcp.lro.wokeup: 0 net.inet.tcp.lro.fullqueue: 0 net.inet.tcp.lro.entries: 8 net.inet.tcp.lro.hold_lock: 0 # uname -apKU FreeBSD CA72_4c8G_ZFS 13.0-STABLE FreeBSD 13.0-STABLE #2 = stable/13-n245765-bec0d2c9c841-dirty: Thu May 27 14:16:42 PDT 2021 = root@CA72_4c8G_ZFS:/usr/obj/BUILDs/13S-CA72-nodbg-clang/usr/13S-src/arm64.= aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300505 1300505 # sysctl net.inet.tcp.lro net.inet.tcp.lro.sackwakeups: 0 net.inet.tcp.lro.lockcnt: 0 net.inet.tcp.lro.single: 0 net.inet.tcp.lro.compressed: 0 net.inet.tcp.lro.wokeup: 0 net.inet.tcp.lro.fullqueue: 0 net.inet.tcp.lro.entries: 8 net.inet.tcp.lro.hold_lock: 0 So the releng/13.0 and stable/13 have net.inet.tcp.lro.sackwakeups and the like but main does not. Note: I do use a USB3 EtherNet dongle instead of genet0, in case that matters. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Jun 11 09:47:46 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E793011CECED for ; Fri, 11 Jun 2021 09:48:46 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1bdV5kCNz4ZvK for ; Fri, 11 Jun 2021 09:48:46 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Fri, 11 Jun 2021 11:47:46 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail202005; t=1623404924; bh=LyxOz5jMnMGbBFWvUVy71X327bnDo74XqTzTgUAekW8=; h=Date:Message-ID:From:To:Cc:Subject:MIME-Version:Content-Type; b=2RQlmhN9uCm2CJ1qsAxe762Ttr3VplNwWDpLzpebR6EKfZAM0P17THy3+fJGr2T/G lKcCXBYC+OBENVRtKlrI3jr3vj13pfoZymubY9GhA8P299vjgGB5aO+GWszLxM5PwC o4eGTM5hs+KRXBECIGwCCEyn6hDWUShYDHCah/tx85xWxE4CqZE9Sbq+97H27d5uG5 WNUZAr8NjKFygkOZzs7Ul+gSUV0Twn0mRq4dwnLmWl+fMumM6BurvM4SVyFcDUdFxb ZXI9os2E/bwWSZgft/U6940rWSYGWv0BIKY1+I1x29XzjTBA5cMefnABqespCzhNFq dCJQyfCmXmd7A== Message-ID: <87v96k91h9.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: Hans Petter Selasky Cc: freebsd-arm@freebsd.org Subject: Re: Easily reproducible stable/13 kernel crash In-Reply-To: <6d268f28-373e-fd84-9fe8-9e39831760e5@selasky.org> References: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> <87y2bhuehz.wl-herbert@gojira.at> <87wnr0vq79.wl-herbert@gojira.at> <6d268f28-373e-fd84-9fe8-9e39831760e5@selasky.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 Mule/6.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4G1bdV5kCNz4ZvK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 11 Jun 2021 09:18:32 +0200, Hans Petter Selasky wrote: > > On 6/11/21 9:02 AM, Herbert J. Skuhra wrote: > > On Fri, 11 Jun 2021 08:00:56 +0200, "Herbert J. Skuhra" wrote: > >> > >> On Fri, 11 Jun 2021 07:42:27 +0200, Matthew Grooms wrote: > >>> > >>> Hey all, > >>> > >>> If I build an up-to-date stable/13 arm64 kernel and type sysctl -a on > >>> a rpi4 system, it reboots every time. I've blown away the source and > >>> object tree multiple times and still get the same result. > >>> > >>> FreeBSD generic 13.0-STABLE FreeBSD 13.0-STABLE #1 > >>> stable/13-n245932-04c4bd7f7b5: Fri Jun 11 00:09:11 CDT 2021 > >>> mgrooms@x.x.x:/var/rpi4/build/usr/src/arm64.aarch64/sys/GENERIC arm64 > >>> > >>> Has anyone else been testing stable builds recently? I'll try to build > >>> a debug kernel and see if I can dig up more info. > >> > >> I can confirm this issue: Rasperry Pi 2 (armv7), 3 and 4 (both aarch64). > >> When booting kernel.old (from May 17th; e0f2b8aaf1ed) 'sysctl -a' > >> doesn't crash the system. > > > > The kernel from the May 27th snapshot (stable/13-n245691-024a9aa7010) > > is OK, the one from June 3rd (13-n245852-4775325dd66) isn't. > > > > Do you have the kernel backtrace of the resulting panic? So far I could only get: # sysctl net.inet.tcp.lro Fatal data abort: x0: ffff000000b25820 x1: ffff000000e4b6d8 x2: 0 x3: ffff0000abf7a650 x4: ffff0000abf7a5d8 x5: 0 x6: 0 x7: ffff0000abf7aaa0 x8: 0 x9: 0 x10: 0 x11: 0 x12: 3 x13: ffff000000e3a750 x14: f x15: f x16: 4048d2e8 x17: 403d15e4 x18: ffff0000abf7a540 x19: ffff000000e4b6d8 x20: ffff0000abf7a650 x21: ffff0000abf7a650 x22: 0 x23: ffff000000e4b6d8 x24: ffff000000b8e000 x25: ffff000000b8e000 x26: 40800 x27: 14 x28: 234000 x29: ffff0000abf7a540 sp: ffff0000abf7a540 lr: ffff0000004caef4 elr: ffff00000050355c spsr: 60000145 far: 0 esr: 96000006 panic: vm_fault failed: ffff00000050355c cpuid = 1 time = 1623404572 KDB: stack backtrace: #0 0xffff00000050d794 at kdb_backtrace+0x60 #1 0xffff0000004b9160 at vpanic+0x184 #2 0xffff0000004b8fd8 at panic+0x44 #3 0xffff0000007e86e8 at data_abort+0x1d8 #4 0xffff0000007c8874 at handle_el1h_sync+0x74 #5 0xffff0000004caef0 at sysctl_root_handler_locked+0x118 #6 0xffff0000004caef0 at sysctl_root_handler_locked+0x118 #7 0xffff0000004ca350 at sysctl_root+0x218 #8 0xffff0000004ca944 at userland_sysctl+0x18c #9 0xffff0000004ca778 at sys___sysctl+0x68 #10 0xffff0000007e7d34 at do_el0_sync+0x498 #11 0xffff0000007c8a1c at handle_el0_sync+0x90 Uptime: 1m26s Resetting system ... -- Herbert From nobody Fri Jun 11 13:19:16 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A0AD55D3BFA for ; Fri, 11 Jun 2021 13:20:14 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1hKV3bZbz4vwP for ; Fri, 11 Jun 2021 13:20:14 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Fri, 11 Jun 2021 15:19:16 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail202005; t=1623417611; bh=yfsE6aJp/lxT5FWcPEXFVMtF4CLO4hdqv3GnDOG4EXM=; h=Date:Message-ID:From:To:Cc:Subject:MIME-Version:Content-Type; b=PkyTSM90k33w661o/J946AOJkgQQYhvV5t5SHzm5mcxXJ2W9d99x8bVFebIK8DyYu YimglyL866q8YFAX1FEKtBcwex482AI4YEVeu8yA4dAO7QLMwqwuZm5YslFoHwAUa/ dJmdbwM14E9z4rbtUb+op0EIjsB/ZEdeq3UKJ/eXk80eo3dnZqtL7fjrS5+p34UqGi C/6Tzvs5lSBsoVDVUxTA/RF5Efcpzd6jQm6bkGFfo4iZVC2Z5edn1OBC3l1m4vQAR5 8MQYYx51ZjvnXOvWXEOmVWUAgX3tZ8xQr0RdIg5dAQ3qG0ZNbWH5dpaqqEGhqyIeOE N+YBO6lDL9A2A== Message-ID: <87tum48ror.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: Hans Petter Selasky Cc: freebsd-arm@freebsd.org Subject: Re: Easily reproducible stable/13 kernel crash In-Reply-To: <6d268f28-373e-fd84-9fe8-9e39831760e5@selasky.org> References: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> <87y2bhuehz.wl-herbert@gojira.at> <87wnr0vq79.wl-herbert@gojira.at> <6d268f28-373e-fd84-9fe8-9e39831760e5@selasky.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 Mule/6.0 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4G1hKV3bZbz4vwP X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 11 Jun 2021 09:18:32 +0200, Hans Petter Selasky wrote: > > Do you have the kernel backtrace of the resulting panic? #0 get_curthread () at /usr/src/sys/arm64/include/pcpu.h:68 #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffff0000004b8c5c in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:486 #3 0xffff0000004b91f0 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:919 #4 0xffff0000004b8fdc in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:843 #5 0xffff0000007e86ec in data_abort (td=0xffffa00001740000, frame=0xffff0000dfbd93a0, esr=2516582406, far=, lower=0) at /usr/src/sys/arm64/arm64/trap.c:337 #6 #7 counter_u64_read_one (p=, cpu=0) at /usr/src/sys/arm64/include/counter.h:45 #8 counter_u64_fetch_inline (p=) at /usr/src/sys/arm64/include/counter.h:56 #9 counter_u64_fetch (c=) at /usr/src/sys/kern/subr_counter.c:57 #10 sysctl_handle_counter_u64 (oidp=0xffff000000b25820 , arg1=0xffff000000e4b6d8 , arg2=0, req=0xffff0000dfbd9650) at /usr/src/sys/kern/subr_counter.c:80 #11 0xffff0000004caef4 in sysctl_root_handler_locked (oid=oid@entry=0xffff000000b25820 , arg1=arg1@entry=0xffff000000e4b6d8 , arg2=arg2@entry=0, req=req@entry=0xffff0000dfbd9650, tracker=tracker@entry=0xffff0000dfbd95d8) at /usr/src/sys/kern/kern_sysctl.c:184 #12 0xffff0000004ca354 in sysctl_root (oidp=, arg1=0xffff000000e4b6d8 , arg1@entry=0xffff0000dfbd9720, arg2=0, arg2@entry=5, req=, req@entry=0xffff0000dfbd9650) at /usr/src/sys/kern/kern_sysctl.c:2261 #13 0xffff0000004ca948 in userland_sysctl (td=, td@entry=0xffffa00001740000, name=, name@entry=0xffff0000dfbd9720, namelen=, old=, oldlenp=, inkernel=, new=, newlen=, retval=0xffff0000dfbd9718, flags=0) at /usr/src/sys/kern/kern_sysctl.c:2418 #14 0xffff0000004ca77c in sys___sysctl (td=0xffffa00001740000, uap=0xffffa000017403e8) at /usr/src/sys/kern/kern_sysctl.c:2291 #15 0xffff0000007e7d38 in syscallenter (td=0xffffa00001740000) at /usr/src/sys/arm64/arm64/../../kern/subr_syscall.c:189 #16 svc_handler (td=0xffffa00001740000, frame=) at /usr/src/sys/arm64/arm64/trap.c:187 #17 do_el0_sync (td=0xffffa00001740000, frame=) at /usr/src/sys/arm64/arm64/trap.c:506 #18 #19 0x00000000403d15ec in ?? () #20 0x0000000040353770 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) -- Herbert From nobody Fri Jun 11 13:32:07 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BE5005D562E for ; Fri, 11 Jun 2021 13:32:13 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1hbK4TSYz3Dhq for ; Fri, 11 Jun 2021 13:32:13 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 8732C260072; Fri, 11 Jun 2021 15:32:11 +0200 (CEST) Subject: Re: Easily reproducible stable/13 kernel crash To: "Herbert J. Skuhra" Cc: freebsd-arm@freebsd.org References: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> <87y2bhuehz.wl-herbert@gojira.at> <87wnr0vq79.wl-herbert@gojira.at> <6d268f28-373e-fd84-9fe8-9e39831760e5@selasky.org> <87tum48ror.wl-herbert@gojira.at> From: Hans Petter Selasky Message-ID: <770ec82a-5fa5-530c-b059-bcae09c213e1@selasky.org> Date: Fri, 11 Jun 2021 15:32:07 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: <87tum48ror.wl-herbert@gojira.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G1hbK4TSYz3Dhq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, This patch should fix it: diff --git a/sys/netinet/tcp_subr.c b/sys/netinet/tcp_subr.c index dff7767cd9c..33bc0549165 100644 --- a/sys/netinet/tcp_subr.c +++ b/sys/netinet/tcp_subr.c @@ -1234,6 +1234,10 @@ tcp_init(void) tcp_inp_lro_wokeup_queue = counter_u64_alloc(M_WAITOK); tcp_inp_lro_compressed = counter_u64_alloc(M_WAITOK); tcp_inp_lro_locks_taken = counter_u64_alloc(M_WAITOK); + tcp_extra_mbuf = counter_u64_alloc(M_WAITOK); + tcp_would_have_but = counter_u64_alloc(M_WAITOK); + tcp_comp_total = counter_u64_alloc(M_WAITOK); + tcp_uncomp_total = counter_u64_alloc(M_WAITOK); #ifdef TCPPCAP tcp_pcap_init(); #endif --HPS From nobody Fri Jun 11 13:40:36 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 670E35D5DF5 for ; Fri, 11 Jun 2021 13:40:40 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1hn26d9Gz3FZY for ; Fri, 11 Jun 2021 13:40:38 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 7BBE3260072; Fri, 11 Jun 2021 15:40:37 +0200 (CEST) Subject: Re: Easily reproducible stable/13 kernel crash From: Hans Petter Selasky To: "Herbert J. Skuhra" Cc: freebsd-arm@freebsd.org References: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> <87y2bhuehz.wl-herbert@gojira.at> <87wnr0vq79.wl-herbert@gojira.at> <6d268f28-373e-fd84-9fe8-9e39831760e5@selasky.org> <87tum48ror.wl-herbert@gojira.at> <770ec82a-5fa5-530c-b059-bcae09c213e1@selasky.org> Message-ID: <6539d48b-499c-b27b-f4aa-1af339bb5bc8@selasky.org> Date: Fri, 11 Jun 2021 15:40:36 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: <770ec82a-5fa5-530c-b059-bcae09c213e1@selasky.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G1hn26d9Gz3FZY X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-3.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; RBL_DBL_DONT_QUERY_IPS(0.00)[88.99.82.50:from]; SPAMHAUS_ZRD(0.00)[88.99.82.50:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N Hi, Also need to update tcp_var.h: diff --git a/sys/netinet/tcp_subr.c b/sys/netinet/tcp_subr.c index dff7767cd9c..33bc0549165 100644 --- a/sys/netinet/tcp_subr.c +++ b/sys/netinet/tcp_subr.c @@ -1234,6 +1234,10 @@ tcp_init(void) tcp_inp_lro_wokeup_queue = counter_u64_alloc(M_WAITOK); tcp_inp_lro_compressed = counter_u64_alloc(M_WAITOK); tcp_inp_lro_locks_taken = counter_u64_alloc(M_WAITOK); + tcp_extra_mbuf = counter_u64_alloc(M_WAITOK); + tcp_would_have_but = counter_u64_alloc(M_WAITOK); + tcp_comp_total = counter_u64_alloc(M_WAITOK); + tcp_uncomp_total = counter_u64_alloc(M_WAITOK); #ifdef TCPPCAP tcp_pcap_init(); #endif diff --git a/sys/netinet/tcp_var.h b/sys/netinet/tcp_var.h index c9b337b3c3d..049aa0cc7b0 100644 --- a/sys/netinet/tcp_var.h +++ b/sys/netinet/tcp_var.h @@ -984,6 +984,10 @@ extern counter_u64_t tcp_inp_lro_direct_queue; extern counter_u64_t tcp_inp_lro_wokeup_queue; extern counter_u64_t tcp_inp_lro_compressed; extern counter_u64_t tcp_inp_lro_locks_taken; +extern counter_u64_t tcp_extra_mbuf; +extern counter_u64_t tcp_would_have_but; +extern counter_u64_t tcp_comp_total; +extern counter_u64_t tcp_uncomp_total; #ifdef NETFLIX_EXP_DETECTION /* Various SACK attack thresholds */ From nobody Fri Jun 11 13:49:04 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0C5B35D6B27 for ; Fri, 11 Jun 2021 13:49:05 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (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 4G1hym1xw9z3GlC for ; Fri, 11 Jun 2021 13:49:04 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.15.2/8.15.2) with ESMTP id 15BDn224027623 for ; Fri, 11 Jun 2021 08:49:02 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (unknown [136.49.68.36]) by mail.shrew.net (Postfix) with ESMTPSA id DC4DF199AA9 for ; Fri, 11 Jun 2021 08:48:57 -0500 (CDT) Subject: Re: Easily reproducible stable/13 kernel crash To: freebsd-arm@freebsd.org References: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> <87y2bhuehz.wl-herbert@gojira.at> <87wnr0vq79.wl-herbert@gojira.at> <6d268f28-373e-fd84-9fe8-9e39831760e5@selasky.org> <87tum48ror.wl-herbert@gojira.at> <770ec82a-5fa5-530c-b059-bcae09c213e1@selasky.org> <6539d48b-499c-b27b-f4aa-1af339bb5bc8@selasky.org> From: Matthew Grooms Message-ID: Date: Fri, 11 Jun 2021 08:49:04 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: <6539d48b-499c-b27b-f4aa-1af339bb5bc8@selasky.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx2.shrew.net [10.24.10.11]); Fri, 11 Jun 2021 08:49:02 -0500 (CDT) X-Rspamd-Queue-Id: 4G1hym1xw9z3GlC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.132 as permitted sender) smtp.mailfrom=mgrooms@shrew.net X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[38.97.5.132:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[38.97.5.132:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[shrew.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RECEIVED_SPAMHAUS_PBL(0.00)[136.49.68.36:received] X-ThisMailContainsUnwantedMimeParts: N On 6/11/2021 8:40 AM, Hans Petter Selasky wrote: > Hi, > > Also need to update tcp_var.h: > > diff --git a/sys/netinet/tcp_subr.c b/sys/netinet/tcp_subr.c > index dff7767cd9c..33bc0549165 100644 > --- a/sys/netinet/tcp_subr.c > +++ b/sys/netinet/tcp_subr.c > @@ -1234,6 +1234,10 @@ tcp_init(void) >         tcp_inp_lro_wokeup_queue = counter_u64_alloc(M_WAITOK); >         tcp_inp_lro_compressed = counter_u64_alloc(M_WAITOK); >         tcp_inp_lro_locks_taken = counter_u64_alloc(M_WAITOK); > +       tcp_extra_mbuf = counter_u64_alloc(M_WAITOK); > +       tcp_would_have_but = counter_u64_alloc(M_WAITOK); > +       tcp_comp_total = counter_u64_alloc(M_WAITOK); > +       tcp_uncomp_total = counter_u64_alloc(M_WAITOK); >  #ifdef TCPPCAP >         tcp_pcap_init(); >  #endif > diff --git a/sys/netinet/tcp_var.h b/sys/netinet/tcp_var.h > index c9b337b3c3d..049aa0cc7b0 100644 > --- a/sys/netinet/tcp_var.h > +++ b/sys/netinet/tcp_var.h > @@ -984,6 +984,10 @@ extern counter_u64_t tcp_inp_lro_direct_queue; >  extern counter_u64_t tcp_inp_lro_wokeup_queue; >  extern counter_u64_t tcp_inp_lro_compressed; >  extern counter_u64_t tcp_inp_lro_locks_taken; > +extern counter_u64_t tcp_extra_mbuf; > +extern counter_u64_t tcp_would_have_but; > +extern counter_u64_t tcp_comp_total; > +extern counter_u64_t tcp_uncomp_total; > >  #ifdef NETFLIX_EXP_DETECTION >  /* Various SACK attack thresholds */ > This patch fixes the crash for me. A sysctl -a now completes without an issue. Thanks for the fast response! -Matthew From nobody Fri Jun 11 13:55:29 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2A4F65D7C08 for ; Fri, 11 Jun 2021 13:55:29 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (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 4G1j683pwXz3Hq7 for ; Fri, 11 Jun 2021 13:55:28 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.15.2/8.15.2) with ESMTP id 15BDtRsT027672 for ; Fri, 11 Jun 2021 08:55:27 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (unknown [136.49.68.36]) by mail.shrew.net (Postfix) with ESMTPSA id 7609019A78D for ; Fri, 11 Jun 2021 08:55:22 -0500 (CDT) Subject: Re: Easily reproducible stable/13 kernel crash To: freebsd-arm@freebsd.org References: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> <87y2bhuehz.wl-herbert@gojira.at> <87wnr0vq79.wl-herbert@gojira.at> <6d268f28-373e-fd84-9fe8-9e39831760e5@selasky.org> <87tum48ror.wl-herbert@gojira.at> From: Matthew Grooms Message-ID: Date: Fri, 11 Jun 2021 08:55:29 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: <87tum48ror.wl-herbert@gojira.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx2.shrew.net [10.24.10.11]); Fri, 11 Jun 2021 08:55:27 -0500 (CDT) X-Rspamd-Queue-Id: 4G1j683pwXz3Hq7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.132 as permitted sender) smtp.mailfrom=mgrooms@shrew.net X-Spamd-Result: default: False [-3.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[38.97.5.132:from]; R_SPF_ALLOW(-0.20)[+mx:c]; 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]; SPAMHAUS_ZRD(0.00)[38.97.5.132:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[shrew.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RECEIVED_SPAMHAUS_PBL(0.00)[136.49.68.36:received] X-ThisMailContainsUnwantedMimeParts: N On 6/11/2021 8:19 AM, Herbert J. Skuhra wrote: > On Fri, 11 Jun 2021 09:18:32 +0200, Hans Petter Selasky wrote: >> >> Do you have the kernel backtrace of the resulting panic? > #0 get_curthread () at /usr/src/sys/arm64/include/pcpu.h:68 > #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:399 > #2 0xffff0000004b8c5c in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:486 > #3 0xffff0000004b91f0 in vpanic (fmt=, ap=...) at /usr/src/sys/kern/kern_shutdown.c:919 > #4 0xffff0000004b8fdc in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:843 > #5 0xffff0000007e86ec in data_abort (td=0xffffa00001740000, frame=0xffff0000dfbd93a0, esr=2516582406, far=, lower=0) at /usr/src/sys/arm64/arm64/trap.c:337 > #6 > #7 counter_u64_read_one (p=, cpu=0) at /usr/src/sys/arm64/include/counter.h:45 > #8 counter_u64_fetch_inline (p=) at /usr/src/sys/arm64/include/counter.h:56 > #9 counter_u64_fetch (c=) at /usr/src/sys/kern/subr_counter.c:57 > #10 sysctl_handle_counter_u64 (oidp=0xffff000000b25820 , arg1=0xffff000000e4b6d8 , arg2=0, req=0xffff0000dfbd9650) > at /usr/src/sys/kern/subr_counter.c:80 > #11 0xffff0000004caef4 in sysctl_root_handler_locked (oid=oid@entry=0xffff000000b25820 , > arg1=arg1@entry=0xffff000000e4b6d8 , arg2=arg2@entry=0, req=req@entry=0xffff0000dfbd9650, tracker=tracker@entry=0xffff0000dfbd95d8) > at /usr/src/sys/kern/kern_sysctl.c:184 > #12 0xffff0000004ca354 in sysctl_root (oidp=, arg1=0xffff000000e4b6d8 , arg1@entry=0xffff0000dfbd9720, arg2=0, arg2@entry=5, req=, > req@entry=0xffff0000dfbd9650) at /usr/src/sys/kern/kern_sysctl.c:2261 > #13 0xffff0000004ca948 in userland_sysctl (td=, td@entry=0xffffa00001740000, name=, name@entry=0xffff0000dfbd9720, namelen=, > old=, oldlenp=, inkernel=, new=, newlen=, retval=0xffff0000dfbd9718, flags=0) > at /usr/src/sys/kern/kern_sysctl.c:2418 > #14 0xffff0000004ca77c in sys___sysctl (td=0xffffa00001740000, uap=0xffffa000017403e8) at /usr/src/sys/kern/kern_sysctl.c:2291 > #15 0xffff0000007e7d38 in syscallenter (td=0xffffa00001740000) at /usr/src/sys/arm64/arm64/../../kern/subr_syscall.c:189 > #16 svc_handler (td=0xffffa00001740000, frame=) at /usr/src/sys/arm64/arm64/trap.c:187 > #17 do_el0_sync (td=0xffffa00001740000, frame=) at /usr/src/sys/arm64/arm64/trap.c:506 > #18 > #19 0x00000000403d15ec in ?? () > #20 0x0000000040353770 in ?? () > Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thanks for providing this. I started a debug build before crashing out last night. Waking up with a patch ready to test was super awesome :) -Matthew From nobody Fri Jun 11 14:19:26 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1B9937CA26B for ; Fri, 11 Jun 2021 14:19:33 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (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 4G1jdv5yZRz3Lst for ; Fri, 11 Jun 2021 14:19:31 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.15.2/8.15.2) with ESMTP id 15BEJPR1017924 for ; Fri, 11 Jun 2021 09:19:25 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (unknown [136.49.68.36]) by mail.shrew.net (Postfix) with ESMTPSA id 17F3719ACD2 for ; Fri, 11 Jun 2021 09:19:20 -0500 (CDT) Subject: Re: RPI4 Hardware PWM To: freebsd-arm@freebsd.org References: <9bb7f3d1-8256-be26-ba87-90946ce1b95f@shrew.net> From: Matthew Grooms Message-ID: <05ec75e0-8b9c-e69f-904d-6166337611e0@shrew.net> Date: Fri, 11 Jun 2021 09:19:26 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.shrew.net [10.24.10.10]); Fri, 11 Jun 2021 09:19:25 -0500 (CDT) X-Rspamd-Queue-Id: 4G1jdv5yZRz3Lst X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.131 as permitted sender) smtp.mailfrom=mgrooms@shrew.net X-Spamd-Result: default: False [-3.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[38.97.5.131:from]; R_SPF_ALLOW(-0.20)[+mx:c]; 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]; SPAMHAUS_ZRD(0.00)[38.97.5.131:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[shrew.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RECEIVED_SPAMHAUS_PBL(0.00)[136.49.68.36:received] X-ThisMailContainsUnwantedMimeParts: N On 6/9/2021 4:16 PM, Matthew Grooms wrote: > On 6/8/2021 4:06 PM, Matthew Grooms wrote: >> Hey All, >> >> I have a project I'm working on that depends on interfacing with a >> few sensor modules using both i2c and PWM. I've got the i2c devices >> to work correctly, but I'm not sure how to interface with the HW PWM >> support of the RPI4. I can see there are settings exposed via sysctl >> for Beaglebone systems ... >> >> https://zewaren.net/bbb-pwm.html >> >> I was hoping I'd be able to force GPIO 12 or 13 into ALT0  and set >> the duty values via sysctl, but that doesn't seem to be an option. >> Any help would be greatly appreciated. > > Replying to myself with a bit more info. I see that there is a driver > available for rpi boards authored by PHK ... > > https://cgit.freebsd.org/src/tree/sys/arm/broadcom/bcm2835/bcm2835_pwm.c > > That has notes on RPi2/3 boards, but not mention of RPi4. When I load > that, I see the following output ... > > Jun  9 18:29:50 generic kernel: pwm0: > mem 0x7e20c000-0x7e20c027 on simplebus0 > Jun  9 18:29:50 generic kernel: pwm0: cannot find Clock Manager > > I assume I'm doing something wrong. Any feedback would be greatly > appreciated. Hey Everyone, I decided to take a look at the patch that introduced rpi4 support in Linux. I'm pretty out of my depth here but they didn't look all that extensive. One obvious difference that stood out was that the FreeBSD clock manager driver only appears to load for the bcm2835 part while the Linux driver loads for both 2835 and 2711. Adding the following line to the clkman driver allows the pwm driver to load without an error now ... --- bcm2835_clkman.c    2021-06-11 09:06:19.893728000 -0500 +++ bcm2835_clkman.c    2021-06-11 08:50:44.646221000 -0500 @@ -51,6 +51,7 @@  #include  static struct ofw_compat_data compat_data[] = { +       {"brcm,bcm2711-cprman",         1},         {"brcm,bcm2835-cprman",         1},         {"broadcom,bcm2835-cprman",     1},         {NULL,                          0} root@generic:/home/mgrooms # tail -n 1 /var/log/messages Jun 11 08:35:58 generic kernel: pwm0: mem 0x7e20c000-0x7e20c027 on simplebus0 Additionally, there appears to be valid sysctl values for the hardware pwm devices now. I'll try testing them out and see if I can determine if they're working as expected and report back. Thanks, -Matthew From nobody Fri Jun 11 14:21:13 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8D9B57CA7CA for ; Fri, 11 Jun 2021 14:21:13 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (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 4G1jgr6W2vz3M3d for ; Fri, 11 Jun 2021 14:21:12 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.15.2/8.15.2) with ESMTP id 15BELBlJ017956 for ; Fri, 11 Jun 2021 09:21:11 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (unknown [136.49.68.36]) by mail.shrew.net (Postfix) with ESMTPSA id C2E8D19AC88 for ; Fri, 11 Jun 2021 09:21:06 -0500 (CDT) Subject: Re: RPI4 Hardware PWM To: freebsd-arm@freebsd.org References: <9bb7f3d1-8256-be26-ba87-90946ce1b95f@shrew.net> <05ec75e0-8b9c-e69f-904d-6166337611e0@shrew.net> From: Matthew Grooms Message-ID: Date: Fri, 11 Jun 2021 09:21:13 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: <05ec75e0-8b9c-e69f-904d-6166337611e0@shrew.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.shrew.net [10.24.10.10]); Fri, 11 Jun 2021 09:21:12 -0500 (CDT) X-Rspamd-Queue-Id: 4G1jgr6W2vz3M3d X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.131 as permitted sender) smtp.mailfrom=mgrooms@shrew.net X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[38.97.5.131:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[38.97.5.131:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[shrew.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RECEIVED_SPAMHAUS_PBL(0.00)[136.49.68.36:received] X-ThisMailContainsUnwantedMimeParts: N On 6/11/2021 9:19 AM, Matthew Grooms wrote: > On 6/9/2021 4:16 PM, Matthew Grooms wrote: >> On 6/8/2021 4:06 PM, Matthew Grooms wrote: >>> Hey All, >>> >>> I have a project I'm working on that depends on interfacing with a >>> few sensor modules using both i2c and PWM. I've got the i2c devices >>> to work correctly, but I'm not sure how to interface with the HW PWM >>> support of the RPI4. I can see there are settings exposed via sysctl >>> for Beaglebone systems ... >>> >>> https://zewaren.net/bbb-pwm.html >>> >>> I was hoping I'd be able to force GPIO 12 or 13 into ALT0  and set >>> the duty values via sysctl, but that doesn't seem to be an option. >>> Any help would be greatly appreciated. >> >> Replying to myself with a bit more info. I see that there is a driver >> available for rpi boards authored by PHK ... >> >> https://cgit.freebsd.org/src/tree/sys/arm/broadcom/bcm2835/bcm2835_pwm.c >> >> That has notes on RPi2/3 boards, but not mention of RPi4. When I load >> that, I see the following output ... >> >> Jun  9 18:29:50 generic kernel: pwm0: >> mem 0x7e20c000-0x7e20c027 on simplebus0 >> Jun  9 18:29:50 generic kernel: pwm0: cannot find Clock Manager >> >> I assume I'm doing something wrong. Any feedback would be greatly >> appreciated. > > Hey Everyone, > > I decided to take a look at the patch that introduced rpi4 support in > Linux. I'm pretty out of my depth here but they didn't look all that > extensive. One obvious difference that stood out was that the FreeBSD > clock manager driver only appears to load for the bcm2835 part while > the Linux driver loads for both 2835 and 2711. Adding the following > line to the clkman driver allows the pwm driver to load without an > error now ... > > --- bcm2835_clkman.c    2021-06-11 09:06:19.893728000 -0500 > +++ bcm2835_clkman.c    2021-06-11 08:50:44.646221000 -0500 > @@ -51,6 +51,7 @@ >  #include > >  static struct ofw_compat_data compat_data[] = { > +       {"brcm,bcm2711-cprman",         1}, >         {"brcm,bcm2835-cprman",         1}, >         {"broadcom,bcm2835-cprman",     1}, >         {NULL,                          0} > > root@generic:/home/mgrooms # tail -n 1 /var/log/messages > Jun 11 08:35:58 generic kernel: pwm0: > mem 0x7e20c000-0x7e20c027 on simplebus0 > > Additionally, there appears to be valid sysctl values for the hardware > pwm devices now. I'll try testing them out and see if I can determine > if they're working as expected and report back. Woops. I was going to include these for reference: root@generic:/home/mgrooms # sysctl -a | grep pwm dev.pwm.0.mode2: 0 dev.pwm.0.ratio2: 2500 dev.pwm.0.period2: 10000 dev.pwm.0.pwm_freq2: 0 dev.pwm.0.mode: 0 dev.pwm.0.freq: 125000000 dev.pwm.0.ratio: 2500 dev.pwm.0.period: 10000 dev.pwm.0.pwm_freq: 0 dev.pwm.0.%parent: simplebus0 dev.pwm.0.%pnpinfo: name=pwm@7e20c000 compat=brcm,bcm2835-pwm dev.pwm.0.%location: dev.pwm.0.%driver: pwm dev.pwm.0.%desc: BCM2708/2835 PWM controller dev.pwm.%parent: -Matthew From nobody Fri Jun 11 15:36:34 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9BA3B7E934C; Fri, 11 Jun 2021 15:36:45 +0000 (UTC) (envelope-from dsl@mcusim.org) Received: from mcusim.org (mcusim.org [176.58.93.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1lM04bsRz3lJs; Fri, 11 Jun 2021 15:36:44 +0000 (UTC) (envelope-from dsl@mcusim.org) Received: from x230.ds (unknown [83.28.234.19]) (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) (No client certificate requested) by mcusim.org (Postfix) with ESMTPSA id 5B8B77DCA4; Fri, 11 Jun 2021 17:36:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mcusim.org; s=default; t=1623425796; bh=eIyrC4gOgRu5WRNFP7idhLGx5FpFJV3bvdkkdn18/Hc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=btOrZs3ch+4pUOtXqnDjELC3Sh8GhFOh03sMinKDOCnJUGytN8tO7FIsSn8qxMcY2 WXEv7reoI9+sU0n7eBlSWw98yFkdLrlPTQevADZEDv4oEtNPf7JlNS+MlilgreIRNa bPKpcFyyecIT0CGdWKpefuIwy9ItaOH46leMUKTY= Date: Fri, 11 Jun 2021 17:36:34 +0200 To: Dan Kotowski Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: U-Boot for HoneyComb LX2 Message-ID: References: <198F84BF-5932-4E58-BCE3-CC33B185923A@lists.zabbadoz.net> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4G1lM04bsRz3lJs X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mcusim.org header.s=default header.b=btOrZs3c; dmarc=pass (policy=reject) header.from=mcusim.org; spf=pass (mx1.freebsd.org: domain of dsl@mcusim.org designates 176.58.93.53 as permitted sender) smtp.mailfrom=dsl@mcusim.org X-Spamd-Result: default: False [-2.57 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[mcusim.org:s=default]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.43)[0.430]; NEURAL_HAM_LONG(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[176.58.93.53:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[mcusim.org:+]; DMARC_POLICY_ALLOW(-0.50)[mcusim.org,reject]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[176.58.93.53:from]; ASN(0.00)[asn:36236, ipnet:176.58.93.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm,freebsd-hackers]; RECEIVED_SPAMHAUS_PBL(0.00)[83.28.234.19:received] Reply-To: dsl@mcusim.org From: Dmitry Salychev via freebsd-arm X-Original-From: Dmitry Salychev X-ThisMailContainsUnwantedMimeParts: N (well, I had to configure DKIM long ago... done finally) Personally, I'd be glad to use any bootloader which provided a firmware for DPAA2 MC. I checked SolidRun's script [1] to build a UEFI image briefly and didn't find anything about MC firmware, DPL or DPC. However, similar script with U-Boot [2] has them written to the resulted image: # DPAA2-MC at 0x5000 dd if=$ROOTDIR/build/qoriq-mc-binary/lx216xa/${MC} of=images/${IMG} bs=512 seek=20480 conv=notrunc # DPAA2 DPL at 0x6800 dd if=$ROOTDIR/build/mc-utils/config/lx2160a/CEX7/${DPL} of=images/${IMG} bs=512 seek=26624 conv=notrunc # DPAA2 DPC at 0x7000 dd if=$ROOTDIR/build/mc-utils/config/lx2160a/CEX7/${DPC} of=images/${IMG} bs=512 seek=28672 conv=notrunc Do you know how MC is initialized in case of UEFI? Regards, Dmitry [1] https://github.com/SolidRun/lx2160a_uefi/blob/master/runme.sh [2] https://github.com/SolidRun/lx2160a_build/blob/master/runme.sh From nobody Fri Jun 11 15:49:03 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A7DC47EAF24 for ; Fri, 11 Jun 2021 15:49:08 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1ldJ3pnXz3nBV for ; Fri, 11 Jun 2021 15:49:08 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 5845826015A; Fri, 11 Jun 2021 17:49:06 +0200 (CEST) Subject: Re: Easily reproducible stable/13 kernel crash To: Matthew Grooms , freebsd-arm@freebsd.org References: <63c37775-f1f6-def7-1ca2-4ac0460c46e2@shrew.net> <87y2bhuehz.wl-herbert@gojira.at> <87wnr0vq79.wl-herbert@gojira.at> <6d268f28-373e-fd84-9fe8-9e39831760e5@selasky.org> <87tum48ror.wl-herbert@gojira.at> From: Hans Petter Selasky Message-ID: <664eac09-2fba-e485-07cb-c5f3164aed37@selasky.org> Date: Fri, 11 Jun 2021 17:49:03 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4G1ldJ3pnXz3nBV X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Should be fixed now: https://cgit.freebsd.org/src/commit/?id=ca81bcbbf1182b725d2f7c1eada932731a9d6432 --HPS From nobody Fri Jun 11 18:54:24 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E2BBF11CCE96 for ; Fri, 11 Jun 2021 18:54:39 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1qlL5sqZz4XSf for ; Fri, 11 Jun 2021 18:54:38 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 15BIsOMn088127 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 11 Jun 2021 14:54:30 -0400 (EDT) (envelope-from george+freebsd@m5p.com) From: George Mitchell To: freebsd-arm@freebsd.org References: <35728cba-0152-9b73-77f9-48683e870bbd@m5p.com> Subject: Re: Oversimplification Message-ID: Date: Fri, 11 Jun 2021 14:54:24 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4C4JosH7VCYXZeduEY8EbQUyD6nWMw0TG" X-Spam-Status: No, score=0.2 required=10.0 tests=HELO_MISC_IP,HELO_NO_DOMAIN, NICE_REPLY_A autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4G1qlL5sqZz4XSf X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-5.37 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[74.104.188.4:from]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[freebsd]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.969]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[m5p.com]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[74.104.188.4:from:127.0.2.255]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4C4JosH7VCYXZeduEY8EbQUyD6nWMw0TG Content-Type: multipart/mixed; boundary="0YM7zG6qkl8JAQl05nIEQNYxrEVuMAA1K"; protected-headers="v1" From: George Mitchell To: freebsd-arm@freebsd.org Message-ID: Subject: Re: Oversimplification References: <35728cba-0152-9b73-77f9-48683e870bbd@m5p.com> In-Reply-To: --0YM7zG6qkl8JAQl05nIEQNYxrEVuMAA1K Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6/2/21 1:34 PM, George Mitchell wrote: > On 6/2/21 7:13 AM, Milan Obuch wrote: >> On Sun, 30 May 2021 17:49:01 -0400, George Mitchell >> wrote: >> >>> [... what's the least hassle ARM system for FreeBSD? ...] >> >> Did you consider RockPro64 from pine64.com? [...] >> Regards, >> Milan > On 6/3/21 2:20 AM, Peter Jeremy via freebsd-arm wrote:>> I'll second = Milan's followup.=C2=A0 [...] The RockPro64 is currently sold out on the pine64 web site. Coincidence? I think Milan's and Peter's recommendations in this very thread might have led to this! -- George --0YM7zG6qkl8JAQl05nIEQNYxrEVuMAA1K-- --4C4JosH7VCYXZeduEY8EbQUyD6nWMw0TG Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAmDDsWAFAwAAAAAACgkQwRES3m+p4fmR hw/+MBfwtNVySQvPPtmcDWu8iPBEi/sZPnCyd57O/vpgpKb/+XrByt9n6YPV+6QoR9Sa6myK5216 qfSafbUsZbQdrT72dghp8T8Ci+84/QqLEznSFlGr5bc/5H6enPv71WQWuV3zCjcXnqivZ3L9/psS Hu1BnwGABrHQSrkp7J0hL7k6fUlRZfxYNLAclP7e/jkBF+wp730QqAnG2Le1j0d/YpigjuIenC4+ G84YWypq6Q2bptlP3Ztfrg9srboDTVxD/s2zkINq/E22z/dzybZ0xG1rLT1l7RhMPVUk6dzonxCW NU6G/eDKOCYl1Wk3915MUADxAKWrz+EWcIYvQFfZuzmW/XxVtROCQ5OP+vQnGYy2xrqaRmD6IJAX oyMckmJysvLnAxMi0U8bdX6QvIb7Ui25tkhCA6Pykxst1JDZ9J43TVBHZ10ybekpRF6tLbFVkKVD zPGDTYPUYjwkovhvVCflh5rXsvXWPLwSyeLzogMw6ptrLZfS0y62SlQUyFeLQ+kMRVA0YyXNMBlm fm+4MfM5EVuvPTygbBcd6met308XtYZWz7F3KXLC0joGRoK1KynFwHfSpELRTQRTk0jc8sFhgmZl qqQlRnOpwWfN3NfBCffsr4jJiUquBUsdpw5XyWzHLTGy10y5NjzLLschkyBb4kExf7Ifft1zeYfI zUE= =7tif -----END PGP SIGNATURE----- --4C4JosH7VCYXZeduEY8EbQUyD6nWMw0TG-- From nobody Fri Jun 11 19:43:19 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CEEC211CF862 for ; Fri, 11 Jun 2021 19:43:33 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1rqn404sz4c4G for ; Fri, 11 Jun 2021 19:43:33 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Fri, 11 Jun 2021 21:43:24 +0200 id 00DD63A3.60C3BCDC.0000098F Date: Fri, 11 Jun 2021 21:43:19 +0200 From: Milan Obuch To: freebsd-arm@freebsd.org Subject: Re: Oversimplification Message-ID: <20210611214319.657fa6f1@zeta.dino.sk> In-Reply-To: References: <35728cba-0152-9b73-77f9-48683e870bbd@m5p.com> X-Mailer: Claws Mail 3.17.8git86 (GTK+ 2.24.33; i386-portbld-freebsd11.4) List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4G1rqn404sz4c4G X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 11 Jun 2021 14:54:24 -0400, George Mitchell wrote: > On 6/2/21 1:34 PM, George Mitchell wrote: >=20 > > On 6/2/21 7:13 AM, Milan Obuch wrote: =20 > >> On Sun, 30 May 2021 17:49:01 -0400, George Mitchell > >> wrote: > >> =20 > >>> [... what's the least hassle ARM system for FreeBSD? ...] =20 > >> > >> Did you consider RockPro64 from pine64.com? [...] > >> Regards, > >> Milan =20 > > On 6/3/21 2:20 AM, Peter Jeremy via freebsd-arm wrote:>> I'll > > second =20 > Milan's followup.=C2=A0 [...] > The RockPro64 is currently sold out on the pine64 web site. > Coincidence? I think Milan's and Peter's recommendations in this > very thread might have led to this! -- George >=20 I think you greatly overrate my influence in this area :) Regards, Milan From nobody Fri Jun 11 23:14:21 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id ED65E7C97E3 for ; Fri, 11 Jun 2021 23:14:27 +0000 (UTC) (envelope-from furkan@fkardame.com) Received: from sender4-of-o53.zoho.com (sender4-of-o53.zoho.com [136.143.188.53]) (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 4G1xW66HXBz4qK2 for ; Fri, 11 Jun 2021 23:14:26 +0000 (UTC) (envelope-from furkan@fkardame.com) ARC-Seal: i=1; a=rsa-sha256; t=1623453263; cv=none; d=zohomail.com; s=zohoarc; b=hjeiHdR+Db1HuQqinDBY5uFBCpGaW4UjEjqem5svizhrHYiEYDTAdAmduY2g57JPG6h1C5iKahahcmaU91cpsM9NmVpMDOvkOiglP3n8mCaFqwtq8LNNhXXTRWzqhaWwyg5mKxWHgte0DYGcikIhydX4/F/+OpnRX3DA4KoA/aY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1623453263; h=Content-Type:Date:From:MIME-Version:Message-ID:Subject:To; bh=Tin+vDKWsnY8mxGOX5j4kWuqXOauv1PD+6zQ4oh/XQg=; b=Vb/Li0IXdTf1tpP9+M6Zicc87Luyk3iyXI1sLtEUTQY8ZDVEYD/p7JHw7pldNMueLGfWwGijcc1Cu1Jle67ij6B0mk8AWafD/OYcHtOPjwMEAwUg5SwhYKs8HlsheoFrBw6W/0VFKd7ae9bCW9mRhtF9ek9ckTRylsgL5W5b+UA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=fkardame.com; spf=pass smtp.mailfrom=furkan@fkardame.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1623453263; s=fktech; d=fkardame.com; i=furkan@fkardame.com; h=Date:From:To:Message-Id:In-Reply-To:Subject:MIME-Version:Content-Type; bh=Tin+vDKWsnY8mxGOX5j4kWuqXOauv1PD+6zQ4oh/XQg=; b=L+6hHyr09aWvRtfEivRg7mMVNyCJ4N9Qz2f+vtHuI7Esto6wnv9fDBFTJwKn/WuY Jbd989O5xy0M0nSQDl+BTO5WZJUrTkHMKIagZl1BGnEZ/+CLFmSYuWv/84oAwdkZH1t RBHe40BkIyiwRjDWuV2Ufgx4utjzc/ewRsssJTjQ= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1623453261663218.1815682966319; Fri, 11 Jun 2021 16:14:21 -0700 (PDT) Date: Sat, 12 Jun 2021 02:14:21 +0300 From: Furkan Salman To: "Freebsd Arm" Message-Id: <179fd5adf3d.bd467c96485860.4055140932064679988@fkardame.com> In-Reply-To: Subject: FriendlyARM NanoPi R2S board support. List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1590563_1663848507.1623453261629" Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Rspamd-Queue-Id: 4G1xW66HXBz4qK2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none (invalid DKIM record) header.d=fkardame.com header.s=fktech header.b=L+6hHyr0; arc=pass (zohomail.com:s=zohoarc:i=1); dmarc=none; spf=pass (mx1.freebsd.org: domain of furkan@fkardame.com designates 136.143.188.53 as permitted sender) smtp.mailfrom=furkan@fkardame.com X-Spamd-Result: default: False [-4.19 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[136.143.188.53:from]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[136.143.188.53:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:136.143.188.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[fkardame.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[136.143.188.53:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[fkardame.com:~]; NEURAL_HAM_SHORT(-0.90)[-0.898]; RCVD_IN_DNSWL_NONE(0.00)[136.143.188.53:from]; R_DKIM_PERMFAIL(0.00)[fkardame.com:s=fktech]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:2639, ipnet:136.143.188.0/23, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm]; ARC_ALLOW(-1.00)[zohomail.com:s=zohoarc:i=1] X-ThisMailContainsUnwantedMimeParts: Y ------=_Part_1590563_1663848507.1623453261629 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hello, Sharing a test image of FreeBSD built by Sergey https://twitter.com/S199pWa1k9r https://mirror.fkardame.com/Linux/Images/FriendlyArm/NanoPi-R2S/FreeBSD-aarch64-13.0-RELEASE-NanoPi-R2S-20210610.img.xz https://personalbsd.org/images/FreeBSD-aarch64-13.0-RELEASE-NanoPi-R2S-20210610.img.xz Supports both Lan. Added LED support. Kindly test the lan performance and share your feedback. Regards, Furkan Kardame. ------=_Part_1590563_1663848507.1623453261629-- From nobody Fri Jun 11 23:59:52 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 600A47CD0B1 for ; Fri, 11 Jun 2021 23:59:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1yWX1thGz4v6X for ; Fri, 11 Jun 2021 23:59:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 294742BD74 for ; Fri, 11 Jun 2021 23:59:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 15BNxqTv040003 for ; Fri, 11 Jun 2021 23:59:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 15BNxqYn040002 for freebsd-arm@FreeBSD.org; Fri, 11 Jun 2021 23:59:52 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 219367] svnlite update fails with "E175003: Attempt to fetch capability 'depth' resulted in 'yes'" Date: Fri, 11 Jun 2021 23:59:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219367 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Overcome By Events Status|New |Closed --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Jun 12 00:00:57 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 13EA77CD68B for ; Sat, 12 Jun 2021 00:00:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G1yXm6GdMz4vYq for ; Sat, 12 Jun 2021 00:00:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id BD5602C324 for ; Sat, 12 Jun 2021 00:00:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 15C00uvW040317 for ; Sat, 12 Jun 2021 00:00:56 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 15C00uXN040316 for freebsd-arm@FreeBSD.org; Sat, 12 Jun 2021 00:00:56 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 191599] base OS svnlite segfaults at random Date: Sat, 12 Jun 2021 00:00:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Overcome By Events X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D191599 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |Overcome By Events --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Jun 12 12:16:39 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1B4215D664B; Sat, 12 Jun 2021 12:16:50 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Received: from mail-4323.protonmail.ch (mail-4323.protonmail.ch [185.70.43.23]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G2Gss5g2zz4j4w; Sat, 12 Jun 2021 12:16:49 +0000 (UTC) (envelope-from dan.kotowski@a9development.com) Date: Sat, 12 Jun 2021 12:16:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=a9development.com; s=protonmail; t=1623500200; bh=R9DHuXM0+0EoOcoipmoEb+odndLt/JMRY9rLEcfuQQc=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=FvZ8Th6v9EB/gQx/vzdcMK/f+IovGa3Vz/3BWNQMDOVA78KFeoMG6rRw2MLPLEaOD 3dhGMFSgbV1VYtZV8ey7h4xliBG2Z2AJDR+3jV53JyykcFywESe+loIPVBfIpTv4hQ 0NfsvVY5GP4J228P9SN1n7vKokUM6FBAvZJOwCu0= To: Dmitry Salychev From: Dan Kotowski Cc: bzeeb-lists@lists.zabbadoz.net, freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org Reply-To: Dan Kotowski Subject: Re: U-Boot for HoneyComb LX2 Message-ID: <_31rYm0hKlOPZ9FvQ0EqZmig8gGICEKyq9meNvnA29wDK5dpKs0KFnFBgBr3mJ6L_ufrceojMNgSi1Z_-TqjYh7Vem28hWkffAVCMnkb1cs=@a9development.com> In-Reply-To: References: <198F84BF-5932-4E58-BCE3-CC33B185923A@lists.zabbadoz.net> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4G2Gss5g2zz4j4w X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > (well, I had to configure DKIM long ago... done finally) > > Personally, I'd be glad to use any bootloader which provided a firmware f= or > > DPAA2 MC. I checked SolidRun's script [1] to build a UEFI image briefly a= nd > > didn't find anything about MC firmware, DPL or DPC. However, similar scri= pt > > with U-Boot [2] has them written to the resulted image: > > # DPAA2-MC at 0x5000 > > dd if=3D$ROOTDIR/build/qoriq-mc-binary/lx216xa/${MC} of=3Dimages/${IMG} b= s=3D512 seek=3D20480 conv=3Dnotrunc > > # DPAA2 DPL at 0x6800 > > dd if=3D$ROOTDIR/build/mc-utils/config/lx2160a/CEX7/${DPL} of=3Dimages/${= IMG} bs=3D512 seek=3D26624 conv=3Dnotrunc > > # DPAA2 DPC at 0x7000 > > dd if=3D$ROOTDIR/build/mc-utils/config/lx2160a/CEX7/${DPC} of=3Dimages/${= IMG} bs=3D512 seek=3D28672 conv=3Dnotrunc > > Do you know how MC is initialized in case of UEFI? > > Regards, > > Dmitry > > [1] https://github.com/SolidRun/lx2160a_uefi/blob/master/runme.sh > > [2] https://github.com/SolidRun/lx2160a_build/blob/master/runme.sh DPL and DPC are tied to the SERDES config: if [ "x${SERDES:0:3}" =3D=3D "x13_" ]; then =09DPC=3Ddpc-dual-100g.dtb =09DPL=3Ddpl-eth.dual-100g.19.dtb fi if [ "x${SERDES:0:2}" =3D=3D "x8_" ]; then =09DPC=3Ddpc-8_x_usxgmii.dtb =09DPL=3Ddpl-eth.8x10g.19.dtb fi if [ "x${SERDES:0:2}" =3D=3D "x4_" ]; then =09DPC=3Ddpc-8_x_usxgmii.dtb =09DPL=3Ddpl-eth.8x10g.19.dtb fi if [ "x${SERDES:0:3}" =3D=3D "x20_" ]; then =09DPC=3Ddpc-dual-40g.dtb =09DPL=3Ddpl-eth.dual-40g.19.dtb fi Right now we're mostly working with 8_5_2, but I know Jon is doing some mor= e work to get things sorted. IIRC he's waiting on some PRs to get merged up= stream in the Tianocore EDK2 repos. I think someone was working on porting the lx2160a_uefi repo but I haven't = heard much about it in a while. If you're a Discord user, Jon Nettleton - one of SolidRun's engineers - and= a handful of others who are playing with Honeycombs in different capacitie= s are also collaborating here: https://discord.gg/tgHuG4Cq From nobody Sat Jun 12 17:29:57 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C56047EDC38; Sat, 12 Jun 2021 17:30:03 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4G2PqG5Wb3z3GBT; Sat, 12 Jun 2021 17:30:02 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 15CHTwsZ071455 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 12 Jun 2021 10:29:58 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 15CHTwRQ071454; Sat, 12 Jun 2021 10:29:58 -0700 (PDT) (envelope-from fbsd) Date: Sat, 12 Jun 2021 10:29:57 -0700 From: bob prohaska To: freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Subject: Restraining poudriere Message-ID: <20210612172957.GA71089@www.zefox.net> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4G2PqG5Wb3z3GBT 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 [-1.01 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[50.1.20.27:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[50.1.20.27:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.907]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; 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]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm,freebsd-ports]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N In playing with poudriere on raspberry pi 3 and 4 it seems to work well on the 8 GB Pi4 but is over-optimistic on the 1 GB Pi3. Can poudriere be configured to tackle packages one at a time? For example, it started to build both sqlite8 and llvm10 at the same time. I know the setup in this example can finish llvm (just barely) with 4 threads and turning off OOMA with vm.pfault_oom_attempts="-1" in /boot/loader.conf. The intervals of high swap use are generally quite brief, struggling through them seems to reward use of 4 threads. With OOMA turned off and 6 GB of swap a poudriere run on 14.0-CURRENT #0 main-n247255-f20893853e8: Wed Jun 9 18:29:07 PDT 2021 stalled with login: swap blk zone exhausted, increase kern.maxswzone swblk zone ok swap blk zone exhausted, increase kern.maxswzone swblk zone ok swap blk zone exhausted, increase kern.maxswzone swblk zone ok swap blk zone exhausted, increase kern.maxswzone swblk zone ok swap blk zone exhausted, increase kern.maxswzone swblk zone ok swap blk zone exhausted, increase kern.maxswzone swblk zone ok swap blk zone exhausted, increase kern.maxswzone swblk zone ok swap blk zone exhausted, increase kern.maxswzone swblk zone ok swap blk zone exhausted, increase kern.maxswzone Jun 12 09:17:09 www kernel: pid 1044 (sh), jid 0, uid 0, was killed: out of swap space Jun 12 09:17:40 www kernel: pid 2145 (cc), jid 23, uid 65534, was killed: out of swap space Jun 12 09:17:40 www syslogd: last message repeated 1 times Jun 12 09:18:38 www kernel: pid 2179 (sh), jid 0, uid 0, was killed: out of swap space swblk zone ok swap blk zone exhausted, increase kern.maxswzone Jun 12 09:20:00 www kernel: pid 2180 (cron), jid 0, uid 0, was killed: out of swap space Jun 12 09:22:13 www kernel: pid 2181 (sshd), jid 0, uid 0, was killed: out of swap space Despite killing processes, the machine remains unresponsive short of calling the debugger. A backtrace reports KDB: enter: Break to debugger [ thread pid 11 tid 100003 ] Stopped at kdb_alt_break_internal+0x1a8: undefined f904411f db> bt Tracing pid 11 tid 100003 td 0xffffa00000bf4580 db_trace_self() at db_trace_self db_stack_trace() at db_stack_trace+0x11c db_command() at db_command+0x244 db_command_loop() at db_command_loop+0x54 db_trap() at db_trap+0xf8 kdb_trap() at kdb_trap+0x1c4 handle_el1h_sync() at handle_el1h_sync+0x74 --- exception, esr 0xf2000000 kdb_alt_break_internal() at kdb_alt_break_internal+0x1a8 kdb_alt_break() at kdb_alt_break+0xc uart_intr_rxready() at uart_intr_rxready+0x88 uart_intr() at uart_intr+0x128 intr_event_handle() at intr_event_handle+0xf4 intr_isrc_dispatch() at intr_isrc_dispatch+0x74 bcm2835_intc_intr() at bcm2835_intc_intr+0xa0 intr_event_handle() at intr_event_handle+0xf4 intr_isrc_dispatch() at intr_isrc_dispatch+0x74 bcm_lintc_intr() at bcm_lintc_intr+0x1d4 intr_irq_handler() at intr_irq_handler+0x80 handle_el1h_irq() at handle_el1h_irq+0x70 --- interrupt cpu_idle() at cpu_idle+0x74 sched_idletd() at sched_idletd+0x164 fork_exit() at fork_exit+0x74 fork_trampoline() at fork_trampoline+0x14 db> Persuading poudriere to bite off packages one at a time would help, if it's possible. I'm game to try increasing kern.maxswzone, but given the Pi3's i/o limitations that seems unlikely to help much. Thanks for reading! bob prohaska From nobody Sat Jun 12 17:57:04 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EED1C11C9902; Sat, 12 Jun 2021 17:57:04 +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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4G2QQS4yZXz3MQx; Sat, 12 Jun 2021 17:57:04 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 15CHv5wT071564 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 12 Jun 2021 10:57:05 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 15CHv4Ag071563; Sat, 12 Jun 2021 10:57:04 -0700 (PDT) (envelope-from fbsd) Date: Sat, 12 Jun 2021 10:57:04 -0700 From: bob prohaska To: Michael Gmelin Cc: freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Restraining poudriere Message-ID: <20210612175704.GC71089@www.zefox.net> References: <20210612172957.GA71089@www.zefox.net> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4G2QQS4yZXz3MQx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Jun 12, 2021 at 07:36:48PM +0200, Michael Gmelin wrote: > > > > On 12. Jun 2021, at 19:31, bob prohaska wrote: > > > > ???In playing with poudriere on raspberry pi 3 and 4 it seems to > > work well on the 8 GB Pi4 but is over-optimistic on the 1 GB Pi3. > > > > Can poudriere be configured to tackle packages one at a time? > > Yes, see poudriere.conf: > > # parallel build support. > # > # By default poudriere uses hw.ncpu to determine the number of builders. > # You can override this default by changing PARALLEL_JOBS here, or > # by specifying the -J flag to bulk/testport. > # > # Example to define PARALLEL_JOBS to one single job > # PARALLEL_JOBS=1 > > -m > I perhaps misunderstood what was meant by "builders", confusing it with threads. Or maybe cores.... Trying it now, hoping to see parallel core use. Thanks for writing! bob prohaska From nobody Sat Jun 12 22:28:54 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8D5357CA03D for ; Sat, 12 Jun 2021 22:28:59 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (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 4G2XSB4x4lz4Sxq for ; Sat, 12 Jun 2021 22:28:58 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.15.2/8.15.2) with ESMTP id 15CMSpwb027870 for ; Sat, 12 Jun 2021 17:28:51 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (unknown [136.49.68.36]) by mail.shrew.net (Postfix) with ESMTPSA id 4CE6A199FE8 for ; Sat, 12 Jun 2021 17:28:46 -0500 (CDT) To: freebsd-arm@freebsd.org From: Matthew Grooms Subject: arm64 stable/13 boot stuck Message-ID: <4affccce-080b-1108-a845-8e8811fa3bd7@shrew.net> Date: Sat, 12 Jun 2021 17:28:54 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8A13A03CCBA53F3E8AD14E1F" Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.shrew.net [10.24.10.10]); Sat, 12 Jun 2021 17:28:51 -0500 (CDT) X-Rspamd-Queue-Id: 4G2XSB4x4lz4Sxq X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.131 as permitted sender) smtp.mailfrom=mgrooms@shrew.net X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[38.97.5.131:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[38.97.5.131:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[shrew.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RECEIVED_SPAMHAUS_PBL(0.00)[136.49.68.36:received] X-ThisMailContainsUnwantedMimeParts: Y This is a multi-part message in MIME format. --------------8A13A03CCBA53F3E8AD14E1F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I just updated my rpi4 kernel sources today and get this very early in my rpi4 boot output ... bcm_mbox_write: STATUS_FULL stuck If I roll back to 043f204985261d6daae69538c4609b3e143ee444 from yesterday, it boots fine again. I assume this is related to Andrew Turner's latest batch of arm64 commits. Thanks, -Matthew --------------8A13A03CCBA53F3E8AD14E1F-- From nobody Sun Jun 13 00:53:44 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9D6E67E9048 for ; Sun, 13 Jun 2021 00:53:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.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 4G2bgQ14sCz4bjm for ; Sun, 13 Jun 2021 00:53:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623545631; bh=hQHg7ugPyTHEhXOT3B/6+lshu/QEFA1Co0aDkU8WSdY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=J7cj1f0J7vWuCeR7mVNR5w1vf7SHblviTehmiCm1qnIGCDrct/NKz4VrWMdLLrp9ZLRnwpUM1tuRWw9zTyI1ycyCyRVelJqCHWDqpPHS/O3uUke/RDF0gOaAL8WNjYPYgNZiBKKm79l8JRLqHmdZO6fzWc2jwCJKccrY9RYypwCwhYx+k+B9Mye5v/ehu2xRYl0TfAF+QVw2JH1RrNxOAhuUlnfHu4sGx1T9BhRmVbNmbzeEcwUHVHsbdvTrQQ8+PrgSCp8aLrfxlnk6PnpSY0mbkLklJnKLXfkGAImN9MxW7/FlogTfEC2P5w02V0cPyUvWnlRbdc/CBsWpFB8YcA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623545631; bh=dfGktU4MHDGwKTz5Ygk2Kj9ilu0o/NIuezwl3exbdxm=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=hPbWXguUWibwIwbLe2y8smmBhvWpwBB8lCjmpuAcsSkI3XHALTR3WOZhNNRXhdI/oD/ZZJbzNkV34i1bIS/+o60v6X27hiKmHnG66lGKxnQVhZjFBnQvF/NqNghjJb/b7S9Ou2OjkMSjycE7tlaPhPfx8EpPIpDcz4eHDIYJMlg9nMymXv5GUNhmXu7Dw3OJVd7WBPivYma10y+p9CMAAv76gKEAoI3+B9mComFLQ57p6kholqEMN4Si+kpOtBWOD0tAiXt4xpuykg0oqx3wqPfBMck0i6dT6hqyyawfozmTkvXxCcKM1+7E8HrcODKmLsyZV+DNlosDAu26wfk9GQ== X-YMail-OSG: LYO9iPoVM1l41N7tzj6YzJVL8aXtyDudMaV40Ju5axl4hTRR_0XhL2ORHLv_g_g FuQvvHW1o0jlx_FmsRp5j1WmwTE5mYsIL7vIdaW9X_u2dCAZ4kq1UyypvP_CpYWf79OdRgjdF6Zn jSHuQWoeAvM4E1N_Gs46SP4gay_GRwI7Yt0tPbkHjkO4seUSd.UjFyGxodpofNHCMFc_2bneOa6k I2NLPdMoTQLfsK6HLlEa4UKYju_orw6uMIlyRFum1CLjqVsB7nprwFenWnkDmAaQqeKc7ZzvYDXx aFufuq5zd_dbWQqYXOLcK._S2M17lfiTvEIah4lECnMmNu92CG9Tbfzp5Hsyd__8ajHfhOw0MLGw H68nw0fa3xUwu7lYF9yYbYUwPqLlytLW8m.6uQf7sEKyNZkgDeHI0IONV_OHLrBMGp0ELk5yqzG8 fFBxMLDwF3D4AdzjxyeoMATmHTvs5o9MkF.eZNgwTAeRrY30dp_goH4cXqAc4p_ACzX_IONbjXzI bQTtQglqxRcv04V4TJnAs3eqWWq_xlXhndPWb67RFaqyd3FqfHpoVOuS0zbs5NNBVBQ_IvDyUuVG fFf3WsmBFRyIVRLKVwQ97JS63PrProiqo3aRMTE32zn2yPHktnyj.C9EV19AfTBBFazcg0rNxPQq wmDrTcDUUCt8ZjiZ2zbAg4LLmaBsPSG.wAEeBbG6XEo5u42BSf3.oMwG8r50ZhW_kZuPwjnpm.C5 AwkW.6nWwuctkhwl.WvJrXoaVK3BmOQw5KvH7v9v56UjHju7Uf0USGcbuxUZi0hW7thljiHD8SNM sTeK8x3mCzCK.84iHJQOaJr_rvmqxrS7FtzX..4eUNYaY5Txm5DHpwOsLr7KPH_TMOXusHKY7F.z GFSw0mCN3a2.eWclZqauOPHANBHImMqNzI7K393QWN7oeXu4M0yJqweZKc5yJXEeRKqzyacao_eL 1hFSDC4iIcxblZ4TbWbTwp_29uXo5JtxCf_K2H3IVI6cXdIqIhOqFHMg0G4YI7lM_K8YDqVIVsdN SV4kJhFcxJIuA1IeWd31_bAHyd6FLWud4JDwI_vefva9YXwukWF6yLarXRCLB6EF3jnEUqA2d7gf uBifyPhYt4E7aW3fZZ7l0bq1mIo0AJdGH_P3fgm2FWfKCtsfUoTvWD06YJqw3yy9QZhJwjH7HKZJ N4FYkI1d3Uq3DQi6qWncl17dENkEsiOhuRUfVPcD0QsWtuO8PyPJKD5cPZV.UDwKFjba3O86ZZLU HgHrbVLGAT9GKVR3QscactAgxWj_ssxBS0bN39iE0knxevSKHVq87dxr1HhAnQWLkzvv8b3M12Uz MP3jRn6CQRxWzDSWF9OSNVJvj4YTWGVDolzCAjgD6owFhhyYX11wRz8f15SKSfjz4FFO05Qm7l6v 4i9XaCochKY1.RwUNM4VA2VV_qfpg._V80sDsOD18JHMFoJ4EkL6yPHmHdncZGBC4iDJKt5CGfjq t46rgdE082RFiaonCQPthlKltX7zsalAAMlu6VsxwtVHDRDBuhY9Kxj_hIDF36jaRGJDm2Q1sZOy CawUHpoSr4w7j0UydizWgx8O8S.IXCmmPw3MuncblGcD2NUzaJ0vCsgyVzK9fF2q3rWTmJe1m5Wr paWEQ1zZkhoJk.dJVzgLXnvTzF47H65Sbr8XTjq29u.Kl7HdoX6PGwz3Pmt5pMm7ccNvpP4gJAxx iBr_.FpiHygXlb.gkzkx15GHXIXXzEoVAq146Be.I9BAVa33uikXPq4GWn31xa0RukiGaRXmcYv6 YzyRinBP7jb2vDBQ2nZhchoSCevZ4ygmzUBU4sMYyAqypbpxROJhj3bfXwA4hzNvQaaHT3ZF.Zxa P58z1g3ulbkZTLS4rvQl05M5uvZHGfUDNvQu5E6DLG8Jcz5vdJG_jwxjosHD67N9hc9pxwRtXNPb Ldh.jLAN_LSdNRfjZhKiktOsqP38oB1q0Zqh86IW0IXbyztXgPrKv6CYmyaKsuUpd2lJj6Hs0S5l HEMQlWKdqSvZk32eh1AFRZh_2arHFgUakNMe9VqUsMvFZE4ML3d5M8ReUpa_ajD2grLKJhh_Pktu Y59DjBlj.H6hm.55uUCUhHJuczkc2RXV8IyYEPpz1RL6mpS6P3L_M9LxWpxYXchv8rDDmO1NoCkK R.wK2Yf1tSVCt_DRA9dTT922XFH52tMYc5mu0Y70TXvRV3VNsYzD7dq7abWVKT7HfwKZ.I88.JVQ V5n5LLPbOoJNwIInbSNdGy_EMsqV6dIFsrRyGTFzYBpMBDeqDFgvXZj2dCZoVJKWMX51OqwQL4HO 6q.zwA3ngRoEGWKijUFs6El_N7FconAC5u0n86hdumKFLilabNfL59fd55NThVTnxbBNMy1UluEh mPBEPCxL2ML2GWlJHb0WjQEzN0s13Rsv6KBHGXGZ9aUcFnVMrfcB3qSvHJdQBIHKIe6zk9dEkDik 95eAwTQDfxN8rQPcNuXCInqJsGESu0ePmo3mldQEVx_DdM_z2jIys4.nlnsXE0SRQGtHoChbA8i0 qVEPsJgEyE0kzEW.UyFMdwsi_bVMP.qerwbUOJtTdS_G9y1fhJCCC6WdM1rANIWG9N.ow50w8iAe hJ8bpK036a0GO6zOkifku78xkEY05i4kjDKm6v1wYUBSBizhLYA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Jun 2021 00:53:51 +0000 Received: by kubenode511.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c81012ee855044ceb7b6969436801447; Sun, 13 Jun 2021 00:53:46 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Restraining poudriere In-Reply-To: <20210612175704.GC71089@www.zefox.net> Date: Sat, 12 Jun 2021 17:53:44 -0700 Cc: Michael Gmelin , freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <16D4307D-FCAC-4027-A41D-F1BD7265D3FC@yahoo.com> References: <20210612172957.GA71089@www.zefox.net> <20210612175704.GC71089@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G2bgQ14sCz4bjm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-12, at 10:57, bob prohaska wrote: > On Sat, Jun 12, 2021 at 07:36:48PM +0200, Michael Gmelin wrote: >>=20 >>=20 >>> On 12. Jun 2021, at 19:31, bob prohaska wrote: >>>=20 >>> ???In playing with poudriere on raspberry pi 3 and 4 it seems to >>> work well on the 8 GB Pi4 but is over-optimistic on the 1 GB Pi3. >>>=20 >>> Can poudriere be configured to tackle packages one at a time? >>=20 >> Yes, see poudriere.conf: >>=20 >> # parallel build support. >> # >> # By default poudriere uses hw.ncpu to determine the number of = builders. >> # You can override this default by changing PARALLEL_JOBS here, or >> # by specifying the -J flag to bulk/testport. >> # >> # Example to define PARALLEL_JOBS to one single job >> # PARALLEL_JOBS=3D1 >>=20 >> -m >>=20 >=20 > I perhaps misunderstood what was meant by "builders", confusing it > with threads. Or maybe cores.... >=20 > Trying it now, hoping to see parallel core use.=20 You do not seem to have mentioned use of: vm.pageout_oom_seq=3D (just vm.pfault_oom_attempts=3D"-1"). You also mention "[with] OOMA turned off" but no combination of settings actually completely disables the possibility. Based on notes in my poudriere.conf for a 2 GiByte RAM context: #NOTE: on 2 GiByte RAM contexts I've used: PARALLEL_JOBS=3D2 but # two llvm*'s are likely the biggest combination that # could occur in my context. lang/rust or other even # larger build contexts need not be appropriate. I # normally use ALLOW_MAKE_JOBS=3Dyes . PARALLEL_JOBS=3D2 So for the smaller RAM context: PARALLEL_JOBS=3D1 is a possibility. On a 1 GiByte RPi2B v1.1 (armv7) I've used the combination: PARALLEL_JOBS=3D2 MAKE_JOBS_NUMBER_LIMIT=3D2 so that no more than 4 generally active processes in builders/JOBS overall. You have used MAKE_JOBS_NUMBER_LIMIT before to build www/chromium (2018-Dec-18 report): QUOTE On Fri, Dec 14, 2018 at 05:59:21AM +0100, Jan Beich wrote: >=20 > MAKE_JOBS_NUMBER_LIMIT is a user variable, so you can either set in > make.conf or Makefile.local e.g., >=20 > $ cat <<\. >>${__MAKE_CONF:-/etc/make.conf} > .if ${.CURDIR:M*/www/chromium} > MAKE_JOBS_NUMBER_LIMIT=3D2 > .endif Setting MAKE_JOBS_NUMBER_LIMIT=3D2 allowed www/chromium to compile = successfully over several days. The -DBATCH option was used, in hopes it'd fetch the right = options.=20 END QUOTE As for allowing 4 processes in a build per builder (a.k.a. per JOB) generally (for the 4 core context without MAKE_JOBS_NUMBER_LIMIT in use) . . . # By default MAKE_JOBS is disabled to allow only one process per cpu # Use the following to allow it anyway ALLOW_MAKE_JOBS=3Dyes So with PARALLEL_JOBS=3D1 that would have a total of 4 processes. I'll note that threads is yet a separate issue. For example the llvm linker might use 1 or 2 more threads than there are cores. (These happen in one process.) poudriere does not have a control over such tread usage by programs. Threads may or may not use up significant RAM in total. I also override a bunch of MAX_EXECUTION_TIME_'s and NOHANG_TIME: # This defines the max time (in seconds) that a command may run for a = build # before it is killed for taking too long. Default: 86400 #MAX_EXECUTION_TIME=3D86400 # Cortex-A53 and such are slow for the purpose, allow 4 times the = defaults: MAX_EXECUTION_TIME=3D432000 # This defines the time (in seconds) before a command is considered to # be in a runaway state for having no output on stdout. Default: 7200 #NOHANG_TIME=3D7200 # Cortex-A53 and such are slow for the purpose, allow 4 times the = defaults: # Also: boost-libs seems to have a long time with no output but it = making # progress in parallel builds. NOHANG_TIME=3D28800 # Cortex-A53 and such are slow for the purpose, allow 4 times the = defaults: MAX_EXECUTION_TIME_EXTRACT=3D14400 MAX_EXECUTION_TIME_INSTALL=3D14400 MAX_EXECUTION_TIME_PACKAGE=3D28800 MAX_EXECUTION_TIME_DEINSTALL=3D14400 I use: USE_TMPFS=3Dno in order to avoid tmpfs competing for RAM in these small RAM contexts. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Jun 13 01:35:01 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B51607ED1D7 for ; Sun, 13 Jun 2021 01:35:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.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 4G2cb13msyz4h7w for ; Sun, 13 Jun 2021 01:35:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623548107; bh=Trpgz2ujKT+FVwLfu7q1PoydA5TX0Ai83srzqWw6jbU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=gmXCVU8AGa2dH0gjKlgEDfhbz/XvY2G5YDb26QrPBHtV55p3A5NKGYSCbbd6gWZVr87nsoxEs5zuxjq8znfMw2YTuFTCkiO2RFdf6/2f/fM4dKXj/5IQrs6vjs6e+Kb2OauWjjm6LnnvZuGVY4CfTFUwqIadYQf/PuVrrrezHC4WfK1PmTGnW+RFia7lvg1GONKPxXXudkqUH/ByoTxblty9rZgDIC54kdrUwTrG4LJFVpWbySDWPaBGhreOFyun25swAFd6Cy46R2qTit1WIRmNej6NjDytR0aWuXv9ylIieS8/RvnfOui5Z2dr4JMISC1EFkO5CteETNpwk7pnHw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623548107; bh=I054auOGKeWsOFRAGiYNbsFiXjynU1fh1BdQSxbf1L1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=a2Da9jxVQ3gIRzslTP/QkIS0G+MDlGZP9twOul/DI4OEvJ1OgnL1lLeBM+B/MkKdTyoL2fMDNofePF74CQ31jgFbVd0G+wrah2UJY1FMHW5f9+kKK7KA7dAp7o8oxSxVNc3hp/39Fn+UpHfbbQPriGi9Tkl5nD+b4+eM8+C9tGtkK5yGhsFhClNUEpjejLKXb+/driFFsUWut9vNE6HbVyWfNAWu7z7X2+x95XMHGqGZdLxdGkH1bqUqPp4nIb7y8vVTaMl5wAymEG2ABSxsdexeA52eAnFXfURVxjkKrRDfjXMiskfsajfZT6Aca230QCv9agYFfKO2T4Cb46AK/Q== X-YMail-OSG: sAvUqFUVM1k0n7n5G4hbH6O7IwK.ob7Ca38BZb.BRC_j3vUKuD5w_WTg7kCzk_c 02zFEEszuQ5H73Q.uFy8o03s63HhycYHYo029ORbvUR5_ahkkJ3TekqJZtfLs9mUa7I2um.WIsu9 nsbSMrxxyk8gl7WtaciWvwncsz1547yr4kItE159yyvFtuizpnSdqAl8z9A_JbAQ0lak39ToNlOp 1GayNmXNwTMqOZT3zV5YK0pAVETI30pUpkIVRAu0vLAefufsUGkrTg4CttU7UHnP3S0uXW7AmXie MW5K950.PJ2RZrOjUn_fFRuqxW2rTI4f9.6CX0Ujd8CK8oY.75_dzQ.l1MThXqxD4W9vEV5B36o9 3co.nslRKtsurMhvsZSHXivPFuvEigHVOJbrq4gkEIqcfmRnppvKgLaNBCHNaerkWKaZRPUH5Q_6 _IuQSfCdkazWUklyJ_b9ryXsLVSyfQ8JvkyUi4VIKheATgpMo.poD5wJg2_RbCFuYMcFd9JqTc9i 5zKz2Kv3bffy4Xv9Nzrf.pMpO7kotWefjiPnN.bH5677J_fPo64J3EChVoCfkXuZ7V88a_xjSByE ir_bgCSMLWxRbV4vqvwyau.1K7n_qay.Q_EKjPUDzMMCXwyC0fLloH.c57tdj4zF07nBYPrhyOC1 C_ccjfG44KhPlC133bsOD05R9dbsB2erzBJGAGw0O97iDKfv352pVOR8xJ07nEn4VOQxWwMzmTdh hupyMOnXhNbkM._nX14FSTx9IILjxq5ZSDbnYKeGG9O_QaioSSGa0i_e4vbW7XVxOcZRmTCgkR5U NZNWCIdkFy12WITR2o7moi2Ym_h34x_ccA4PGMci5WZ9A6LdEVr.tVToQDqSG7CeNaojqal6F1JG EInFUsvZ4hvEGAfUb2oPZAAutUvOtAyPJONOmByq2oxFi2bMDD8S_9yoUrNZger5nmVcZf0qiR5B Qws_EWJtPsH1je_PgqgGzmSCDDBRm6TUC7PuelP2izqyurLpKiBvhmBhV8VqSFf2F.sCwBj0UQ99 1TD0BxpsxbyvNTNJcRvB5h9K2nFvelmCTiLqMu4xpq6s_fQScaB8cvqRkEW7iASm2ytgqe_eXWew 3qxlWukFpQ6IksP8_5aZVJQfc.yITJKV42r5eX28Cxj2wBgEE9ic_mfCOjoUTS39tbyEiSC_0Qwv EaygumWv.rDdlugpKcljP1etDaWKge1km6f5Yx3j2bB7dV3.eOkKy9yXhrLEIoeJ4H_o1qZVW7_E AdVIxrbTdEcZgCEImoG13P6C.LtFcbcvt97yufXYbDpDQPygU1r8tzGolwtw9aJg7cNgINdrmeqF IppmMqctyQ_1iyjETXrs.shQhKcMsKXJlFfMeT9.bd4l4po2gPjuKIIMFS3bqmc3K1w0bHajaRO5 iz.UdGOA_YsxcW5MNcSduz7uO6PPFduQaViodw2u.xeHC39WTLQYfOhIlImFP.FOjlNYznK3O6qJ Iu6n47GsTZJSi3qphatS0pl4jMbgkLvnloDFT7h.E.TAka.v5yTgsX180172QpQVrgFYO1eF0U6E B_o.GJFT12zmF.ez.LBq3T2eDboFfdulVYp0nqXpf9Q8N9w.Q7GaDLfjwwsa8kuyxrEJkSC.m.4f 6qGEe_RX_lar1wbvWevHg_FywOY_OLjBs9LZndoBQw.b5gbi1SK26uMZr3mZm3mPeowfeAbtuFsS I17wxbHrjGyW9GfbsESWFmXp9AAmL3JBDKznGhWBafbHptuy1rDA68vOALMojTdSEBLgDhGknnYo Nayp6EHjEVYtR_gEhq.C99AlMGrY0jERmaf14tXtdxPb7lLlOLmuHtYsPPS5SyBnjhcLaLo1AEq0 EhljdhEG6p6p24h2odRPH47wV32rnF3AjIiA1QGUIlt5bvL2MoaQflntwk2Zjdm6wKBgwdf0Cd3x HgRIAmer4q9ZSXBHSxrpFzeFFuXmPXRGVkPQtvm.Gycx3y2sP9j8k_nlyPD.vJZU0uUo8cyBNOWN YU4ROU87pjBBpbyk_SjhaGFUO5y8o_4Jke8mwWqRBd7Z956DJof7.2L4hFdYH0g4t7oj7Cz7eEuv VBzaZhNmPo5L0wDAsThHLG_14X35BFy40XjkF7IwgxTHWWw0PioI.rztXF3gcMOxfw2MXkg2JJGH cU1FlMfM_AzeMFj5DgLBaFwoo7q55UD0cyTRYY7a9_KCkQT7eduMrGOOwix5dG_rPoikM40YNXvg diYaf8nYGSn84dnI2ic.68nVqK0BFM0m91ShfiQHLov44GcC5mnA_X_g1LpMk5QdhdN.KxUcnBPz kPwdag.8Dvy7U6KpzbBFcKV9leeAVKShbL56Jmf1aRZAt3w74MbNtz8r6BV6SEaYY8xGt674ysCB oItYfJsj1cyUUG8kUCEwJ6t.kY5ZDy.uDrtwxr1SK7Ic3L1xQZlZI_sxDO6Qu6wAOKS7H01v4t00 C4.QzqMmS9ePxYAJrgG.LKPuPWis40W0q6Hbqu_wk86Q0EP1pz0HVv3oO6mBxeYMOC3NAmxAX1tX KDfbTFwYDOi3Gf1.PARDrxB_.uIUKzfR01lPG8YbwpRrqSklDDwiqaPcNjPVPQ5.oxxjQkO56nVg rIodbonrqaUCYFbILJCGUMJjDgh7O4281_qtGJy2EQjPFF8rPDw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Jun 2021 01:35:07 +0000 Received: by kubenode520.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 76a7bf7ff912d97c8fa34549c9879f53; Sun, 13 Jun 2021 01:35:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Restraining poudriere In-Reply-To: <16D4307D-FCAC-4027-A41D-F1BD7265D3FC@yahoo.com> Date: Sat, 12 Jun 2021 18:35:01 -0700 Cc: Michael Gmelin , freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3CDFB92D-00A4-42E6-891C-B31F10C4842F@yahoo.com> References: <20210612172957.GA71089@www.zefox.net> <20210612175704.GC71089@www.zefox.net> <16D4307D-FCAC-4027-A41D-F1BD7265D3FC@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G2cb13msyz4h7w X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=gmXCVU8A; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.69.148:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.69.148:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.148:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-12, at 17:53, Mark Millard wrote: > On 2021-Jun-12, at 10:57, bob prohaska wrote: >=20 >> On Sat, Jun 12, 2021 at 07:36:48PM +0200, Michael Gmelin wrote: >>>=20 >>>=20 >>>> On 12. Jun 2021, at 19:31, bob prohaska wrote: >>>>=20 >>>> ???In playing with poudriere on raspberry pi 3 and 4 it seems to >>>> work well on the 8 GB Pi4 but is over-optimistic on the 1 GB Pi3. >>>>=20 >>>> Can poudriere be configured to tackle packages one at a time? >>>=20 >>> Yes, see poudriere.conf: >>>=20 >>> # parallel build support. >>> # >>> # By default poudriere uses hw.ncpu to determine the number of = builders. >>> # You can override this default by changing PARALLEL_JOBS here, or >>> # by specifying the -J flag to bulk/testport. >>> # >>> # Example to define PARALLEL_JOBS to one single job >>> # PARALLEL_JOBS=3D1 >>>=20 >>> -m >>>=20 >>=20 >> I perhaps misunderstood what was meant by "builders", confusing it >> with threads. Or maybe cores.... >>=20 >> Trying it now, hoping to see parallel core use.=20 >=20 > You do not seem to have mentioned use of: vm.pageout_oom_seq=3D > (just vm.pfault_oom_attempts=3D"-1"). You also mention "[with] > OOMA turned off" but no combination of settings actually > completely disables the possibility. >=20 >=20 > Based on notes in my poudriere.conf for a 2 GiByte RAM > context: >=20 > #NOTE: on 2 GiByte RAM contexts I've used: PARALLEL_JOBS=3D2 but > # two llvm*'s are likely the biggest combination that > # could occur in my context. lang/rust or other even > # larger build contexts need not be appropriate. I > # normally use ALLOW_MAKE_JOBS=3Dyes . > PARALLEL_JOBS=3D2 >=20 > So for the smaller RAM context: PARALLEL_JOBS=3D1 is a possibility. >=20 > On a 1 GiByte RPi2B v1.1 (armv7) I've used the combination: >=20 > PARALLEL_JOBS=3D2 > MAKE_JOBS_NUMBER_LIMIT=3D2 >=20 > so that no more than 4 generally active processes in > builders/JOBS overall. You have used MAKE_JOBS_NUMBER_LIMIT > before to build www/chromium (2018-Dec-18 report): >=20 > QUOTE > On Fri, Dec 14, 2018 at 05:59:21AM +0100, Jan Beich wrote: >>=20 >> MAKE_JOBS_NUMBER_LIMIT is a user variable, so you can either set in >> make.conf or Makefile.local e.g., >>=20 >> $ cat <<\. >>${__MAKE_CONF:-/etc/make.conf} >> .if ${.CURDIR:M*/www/chromium} >> MAKE_JOBS_NUMBER_LIMIT=3D2 >> .endif >=20 > Setting MAKE_JOBS_NUMBER_LIMIT=3D2 allowed www/chromium to compile = successfully over > several days. The -DBATCH option was used, in hopes it'd fetch the = right options.=20 > END QUOTE >=20 > As for allowing 4 processes in a build per builder > (a.k.a. per JOB) generally (for the 4 core context > without MAKE_JOBS_NUMBER_LIMIT in use) . . . >=20 > # By default MAKE_JOBS is disabled to allow only one process per cpu > # Use the following to allow it anyway > ALLOW_MAKE_JOBS=3Dyes >=20 > So with PARALLEL_JOBS=3D1 that would have a total of 4 > processes. >=20 > I'll note that threads is yet a separate issue. For example the > llvm linker might use 1 or 2 more threads than there are cores. > (These happen in one process.) poudriere does not have a control > over such tread usage by programs. Threads may or may not use > up significant RAM in total. >=20 >=20 > I also override a bunch of MAX_EXECUTION_TIME_'s and > NOHANG_TIME: >=20 > # This defines the max time (in seconds) that a command may run for a = build > # before it is killed for taking too long. Default: 86400 > #MAX_EXECUTION_TIME=3D86400 > # Cortex-A53 and such are slow for the purpose, allow 4 times the = defaults: > MAX_EXECUTION_TIME=3D432000 >=20 > # This defines the time (in seconds) before a command is considered to > # be in a runaway state for having no output on stdout. Default: 7200 > #NOHANG_TIME=3D7200 > # Cortex-A53 and such are slow for the purpose, allow 4 times the = defaults: > # Also: boost-libs seems to have a long time with no output but it = making > # progress in parallel builds. > NOHANG_TIME=3D28800 >=20 > # Cortex-A53 and such are slow for the purpose, allow 4 times the = defaults: > MAX_EXECUTION_TIME_EXTRACT=3D14400 > MAX_EXECUTION_TIME_INSTALL=3D14400 > MAX_EXECUTION_TIME_PACKAGE=3D28800 > MAX_EXECUTION_TIME_DEINSTALL=3D14400 >=20 > I use: >=20 > USE_TMPFS=3Dno >=20 > in order to avoid tmpfs competing for RAM in these > small RAM contexts. >=20 Something else I will note: you reported for the 1 GiBYte RAM RPi3B use: QUOTE With OOMA turned off and 6 GB of swap END QUOTE Does the system generate a warning about being mistuned when the swap space is added: warning: total configured swap (??? pages) exceeds maximum recommended = amount (??? pages). Such likely would contribute to "swap blk zone exhausted" notices. I avoid setting up contexts that generate this warning about the configured swap by avoiding having too much swap space for the RAM available to manage it. As covered in multiple past exchanges, attempting to adjust kern.maxswzone to deal with this has other tradeoffs (less space for other kernel information) if I understand right. It takes more knowledge than I have to know if such tradeoffs are appropriate for a particular context. My memory is that when I move the Rock64 media to an RPi3B for an experiment, I use a 3 GiByte swap space to avoid the warning. (I have a 2nd swap partition that can be also put to use on the 4 GiByte RAM Rock 64 that goes unused on the RPi3B. It is rare that I do things sort of experiments. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Jun 13 02:34:31 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A8A8C11C82D4 for ; Sun, 13 Jun 2021 02:34:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4G2dvd504hz4m5h for ; Sun, 13 Jun 2021 02:34:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623551675; bh=bgScS/O+cicyr30ZDYRljXOL8MhWgKgkcVkD/8sQ9MQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=W1QuM7qsR4pFC9aPlTX/JuP530rkt57Lh4MGlxcSM/aveX0tGn68rhkrl/AeDL57P4fvV9ueHv/9D5igZxoOcfIk37PTMN9dw8SgcPotfVGybC8YaGvmyegDCbmYKloeAQZz13WACgmE8rtz2atSZVmqhKg5/zj2uo2cHP6HjzF7J3MAwh9fhavsNnpQRSgLLp0eRBZNXwAyFpM0MrGM/RxJCQ9CL7ZKuDwyHKnYfHjAO6DkCPTe+sPD23b8EZZSO1PTjM8pc5IHznwbWxABp43JJtNGBOL2WseSJJze4HwN2C0a/lddTsE8ySkEpjUKn7pluZBsk3sAhue2nbVBog== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623551675; bh=fiRl79oyEnImoRlGW/drZHT7DiYY0LuRDjzB0likAiN=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=sHqyXx6L45E1RTvtbF/uv5tnT3l2XyQjsnq8ih+mA1V+/klMoUtNVMc6E8HMPI0bztidb6/ffpDeCl0j6JYvnNO+lNo4IbPDv3x1OEorR+W3MGSCAUCRzI24irJ5zzCpVEBaA8xnGQbzQwZxH207GC76hh9KcPoETLcmhMRYfqr9lC0at+1X9ruLuirzEFG53SZvv52XJ0KemhjLG9FYGJinMN8iufqEcwfsYVJsYNIhnFnW9N2SdIctfjsND50jppia+uyX8J/hhYOe63qwd5sKnVlit3CLVXjZc+avDuIp7naeT1NPAUZWYufqAc6wBjHFsypeawBwqS6pwVXMbQ== X-YMail-OSG: zqm5rCcVM1lufV1PwkbTkxq5_3dG58eu9ENw9NjipupAcYkbmvqqscfoedsLedQ QPCE5U0rCqATMMMcpg7__dr6RQCqAy.gDKZrXpu.47DUH.fK7OeeJpBX3xZBjzOAqRPiQigcHMBF NBArtaGWlwABLSbSIWc05JXBdwdr96PDVfWp2THRIOqf.UnjUu38zYZJO2MTwZFLxsujj1EPEcyf VL9qc4saoFEbC7Rwm34utBKnnOSbW3Gius_eveg7kr5CfIEzs0KUzyI8YLfxbnefkmaf.Yr2EjCJ _IU2HA1SJdm.U_slZ9wZJBkiWAK28zp5DkdhbDUujGTwxb.26v0vNxEwcthfCvaZbLFqwfx1Q2CY ErtJ5LIe1jsfQSf62VJlAkOUpBC0JwzoR8qo8QnPS98QUQestS0H_QA4Vv.2ynSEfpS7LtFDVavh VcET1ynrPssU_4GB1Ju1ZW26ym6wkyTILWk9V2pl44z6sfPSYvE4YnL1J6RJ3KLMfiAoNI9AzTOW VXYt6ZJTg1ikRAl2nZomR3npXkSTElWy3aU0d17JPLeHxgLFcSf_Hqyd7E_oehds2xejcnq4a9nX RX5T__JJ3T4moF8q_pBu5FDc9A6QRX0nMpYo5cEA0Wm2UHsPfZGk1kbmzwfCpMNhNsTCE6zZbkWF BaxSEziqPuK2ARyraLK87Ja0l9FjQpn_.7ZGm._BdN0BrDNKEbBleb6YdDj14IUSLpz4sgjXRqA7 KlKqk6LixAMuqIqFwIjDp_3kvGU6A2eNdYZBoMDvJRu3DyaO4xfI7ATIi3cusAmWdRPt72CCmHV7 aVJCRf6FJOYgaZy1HFshae8HbdRVOPsJussPuVOM6R7e83NpDTS_mxPdWjmd_DpolWkfjP2y3mkA VYTEAkNUD23wD8j1tZ.prN5oTeRGtG.dlP1bZ5zP85wZ5N6PRLnF7z1JMP5anllrM.VO0S9YR0Tm yXDhBAvKEqqVBG.HRCCAov8EmQZ12pzHD1vWZ0jZhw_nQqayGzRccZBdrK3vixui3K0Rd0sbeo8a v1E.eyx7Zfey98s_Rqp9zbsmCCamS40u0L70BLHutyOHD8R.fok_CUvUyJfirfjENOtYoGO9ZFWK O2m5NpeCArv6WU_rZI6zlqJTD.cY.ss.sNQK6XxvMpCXsyFJqeQftcB7axKw_Oiys1N9.1I9w2Uv miFH1Hs06xLoMi6489VAI74dyrqXBo.FNRcjH6fgkDh9I4Mjg4F_D4rChurXy6YZsr2x8uYyuh7n 385BIbgPjpV8h_4D2SZuWQVlWqpHsJyiF9nwjp4GTmxBFU6wAabLJVyTBvjiuvNJuqmd7WZOs18D HLzt6yADj.pQSupf0efsk0VyOyMsip9paPh_xWxwYGMZcp61.BBBDcsk2yxy6BIU0SeN39UOWTLm TlE3GdDDhVGutD1OEJxH7wc_FiDbymichgIvqaRoxxZOaJFTY4qNZGoT4La_MS.n29sSn4SfSCY. SJ5Zr_vlm.K4yVHG6Umdxyv5QrGXd7WlW4e7dawUVZ4Npz0TcLZwRNm6lF7xfewCTLQ0o3QaBE2l ahU1Vgj66vVC9gunDi5J7YrooiBVO9LekvbmfR6Ti0KkDgqUahGHTLQRHlu8YZrnte894ZaK8HHJ Jcj3GFHPGDhpGJETrDnuV1Kscsya2dNejomXnI2Ym_jQJkSnTQY0cJfVKQ_pHMd718wpsbKroBLN NguUc9l9oMR_PAG70AHmjGRiQ4FLgJ3I40TXumEkxdBh2M5DIPT0SVxiRqkniExXXw7vRrDBZCFC LKqPAg_yh5ADPaOpMCh4ZaY0CpXSjFT9Z6BJHZEBTzYqhppX0AY0BzeMoXgjHFo0Sd0fg5ysbll2 B7LyKIaEpndIeHivPNZlr6mOgnE.XIle3J48dzs2XVe2MbfcmiJghSVm3t.FhO8hOlRVv0HN7vZj 0mkT4MQZ6t2y6xx52dJ1NwWF7qzWcAL181Lt9oaMtibS_MSGACG0mTzxM_RvGad7bI_PM0eyNvOL R9.fjJZzDNmsF2sP.a2j1BwFHAbVjQiJhY3fiFpOcEy7e5A5WmfugMQ0z9N8GLk0X.m4hEC7UI6f oWDhW.w4KeDdX5J0moWXgdwdos7FFWFS1V06JsH0.XDz4.oUGJp0tHde7FSXfssBvReNCy1aP2Ru tGzaZXDB1VFjJXtvP1P8RfyNVGTAJ0vj96JNx54jPk0eVRQ1HOUjm5jluAERy59YvX5DrIm.D80S tiXYeulRdeJjn7ruZu4BxXhx1AXWz.7VYSTD9DN_CTg6xE.D745MMODVAonmHbKrQXpmXsv8EBsA 6Z5vrVfPGTgj5roHXslQpZtSlpgg37uACDQWxybTWCxcb4gUkw7kFT6AOmnXxkC0EdduX_81eO1s H0wOk1nty4JnFfPPWFGlET41HpZ6jWCxSKp3DdpKtg6sKch9dqOaWcll4HlX.LWnCAt3UdiwS9hT ILXTceYG_mb0J70AVPYDHFfZdi5y8v.8q0JJOJvP3_G3qhsYmtg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Jun 2021 02:34:35 +0000 Received: by kubenode511.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7d8ebe1cebdeeb4fa9f3c4005697c063; Sun, 13 Jun 2021 02:34:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Boot from USB on RPi4 8GB? [SOLVED] In-Reply-To: <0E3E9A40-2E56-4C49-A992-247408A88EFD@dsllsn.net> Date: Sat, 12 Jun 2021 19:34:31 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F3EE8D2-649B-4522-AD5A-7C308291802F@dsllsn.net> <43FAEEAC-EE36-4810-88AA-FF82AFBCC128@yahoo.com> <2F58272B-BD9C-464B-9A98-BF638971BA86@dsllsn.net> <0E3E9A40-2E56-4C49-A992-247408A88EFD@dsllsn.net> To: William Carson X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G2dvd504hz4m5h X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=W1QuM7qs; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; 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]; NEURAL_HAM_SHORT(-1.00)[-0.999]; 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/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.68.32:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.68.32:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-12, at 18:18, William Carson wrote: > On Jun 10, 2021, at 9:57 PM, Mark Millard via freebsd-arm = wrote: >>=20 >> On 2021-Jun-10, at 17:22, William Carson via freebsd-arm wrote: >>=20 >>> On May 30, 2021, at 6:54 PM, William Carson via freebsd-arm = wrote: >>>>=20 >>>> Thank you for hopefully pointing me in the right direction. >>>=20 >>> Alright, so, I ended up buying a WDS500G2B0C, which seems to only = use a maximum of 75 mW (this seems ... low, to say the least, but the = column is unlabeled in the spec sheet I found here = https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/= public/western-digital/product/internal-drives/wd-blue-nvme-ssd/product-br= ief-wd-blue-sn550-nvme-ssd.pdf). >>=20 >> That document says for WDS500G2B0C: >>=20 >> QUOTE >> Maximum Operating power 3.5W >> END QUOTE >>=20 >> So at about 5V: about 0.7A maximum. Of itself, that is under the 1.2A >> figure. The X872 must take some power as well. But I do not find any >> W or A specifications for it. >>=20 >> I do not know what other power draws in the overall system might be. >> Any combination that might use more than about 0.5A? (So: more than >> about 2.5W total)? >>=20 >> Unless you specify otherwise, I'm going to presume: no. So I'm not >> expecting power to be a problem. >=20 > Here is my setup, trying to be precise as possible: >=20 > Static components: > - Apple 30W USB-C Power Adapter > - Apple USB-C Charge Cable (2m) The original RPi4B's (v1.1) were missing a resistor and caused various power supplies to misidentify the RPI4B context. But I doubt this is your problem: normally that blocks the supply from working at all if I understand right. But there is the problem that the RPi4B only supports part of the Power Delevery specifications and does not negotiate current or power at all: just uses a register to tell an "e" PD power supply connection that it needs about 5V. As one RPI engineer/forum monitor put it in response to reported experimental results (and a misinterpetation of them) for a RPi4B: QUOTE (2021-May-31 material): The PI does NO negotiation with power supply under any circumstances. Your results are down to different power supply ability, not any sort of negotiation. i.e. some supplies are better than others. END QUOTE Apple USB-C power adapters (only listing 5.?V combinations supported): Older: 29W USB-C: 5.2V/2.4A 61W USB-C: 5.0V/2.4A (an older model) 87W USB-C: 5.2V 2.4A Newer (USB-C Power Delivery 2.0+): 18W USB-C: 5V/3A 30W USB-C: 5V/3A 61W USB-C: 5V/3A (a newer model) Note that none of those with 3A are 5.1V, which is what the RPi4B is indicated to require. Using a true 5V has more risk of voltage droop problems as I understand. = https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/READM= E.md reports: QUOTE The power supply requirements differ by Raspberry Pi model. All models require a 5.1V supply, but the current supplied generally increases according to model. END QUOTE (So far as I know, the 5.1V requirement only fits with USB-C at all via the margins allowed around the nominal USB-C figure.) The CanaKit 5.1V 3.5A ones that I've been using have worked well. The Power Supply from the RPi folks is 5.1V/3.0A. Look for 5.1V and 3.0A to no more than, say, 4.0A or less. It might be worth testing with such a power supply instead of the Apple one. (Unless you can measure and see that you are getting the 5.1V.) > . . . For the moment I'm going to stop with this one point before looking at your other material. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Jun 13 03:17:14 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E0B3C11C9CCD for ; Sun, 13 Jun 2021 03:17:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4G2frw4mqBz4p2W for ; Sun, 13 Jun 2021 03:17:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623554239; bh=8AUvgUtHhHzLOf1mHKP5xQtqJAtelUpdfReP/bpjOrs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=o43ShCVYyKFIHwVbHdZ6hTZYQwfOTVoYaqRINM8Z8gWoDKwkTw/MG5YkpVQqXsg8OuqL7yjZgv4zr6Y+5sETfZ/iKXQ3Z/WhL/fYIEXM/YIs1cPeTonJSZtnb6W0ohe1dwTQ6n3huo3qnYoL4TC3zsZojBC+sK6NnS0xfbEseSwtiC/aanqu+giGNeME6hsFu0R3L1K0fA+wIAXdKTi1XBBPNu0shN5AluXNC8PX+a9047y3OmAWxRJ79aY9gG8Y5iTwPBE/CZMjn0nKPQIPeqdM8IHO6hxCx9+dhD29PhLrZZpHxA1oLFDcfAnnJ7Zu2x32L9OAhb59b5nUs6Ztyg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623554239; bh=GjkvqOcM6nn32+IEAqXcnrlyOk6O0AFfEvOkWJbmomS=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=effIy7C3olUweYuHuh+VxkB1ZicSoUtx9Up7fGoOPcMoQlAgipWoiB/LOmf3ljWtwu8V9uAZ6UMAkt6rznVxfAUVnxO1ipca+E0ZXbVQ009m8EJeQNyApVBetF0inwwHWoTUIkdQm05v5nFNl1ePbU51l16Q4O7b8cRAoUA3qPTmThNU13RDrN6WT4VcOm66z/2UG/9ufOxxoDn4spLhm81VDieRBqV4Rg7fJgwKBob2qFKZXsrTYq0wmj8+/rIR4kXdPn85v1jglMppbENqUlmp0fjpyhag1h7slbpm2FmdgfD7uitMGyY11I7L5H40RbS54JNNqy6aHw+Sq7Fpug== X-YMail-OSG: hO718CoVM1m8Dg4VOsDMUlHPqnKmZmnvz3neULZUyLmNBs8cb3kfBPmMIasR.lX IEBBPYeooniLS.AjIRp1oi9j_LmnQj_qQ5XPrKxzW6clql0aHIo73LyGnZBS3o3wU..6LzGt3kX4 aekNDFgKS_n3JYGuA.mAdqL4hmpkwGCUn.QzpncRqu.kQTKWfxz1pJ1F4h6e_mceqgSx0tYHWEal FY1ZQqKPcMBhqSdeJVztmPc1jgqC5JQIuiNDZYgcD1S7JUl1vXptYhMVNqIPPTYR9kmAPFyZcaMZ TOKW5LMgA0iSBHHEqEbv6FsVdpZ7Ugz9JNpXfALeR5gC.GbJEt5qEYDhCUR5WIC3qbal9nqdI9tg xWNrDLVa2U7Pe9ha4ROxWHOlN.V82Bzkm.8d7oVwQwhiMklmItycSY14U14rq44dtMtK52qHqVod hSeLif34S5cfVY5cnzc3SO5ebs1oc7eE4Zu4S5jIGbJ9PKGZC_DuMgxZPkyarsDSxaDgDfqgFC9Z Bm80VmU.sc2JnkFhnh1oqmNPbUbeV7EEJPtjhrudgW0_IZlV8Gkb1UACgvcnM0xDjLHOo_yrq_7e q71JfuUJiyLzyPoMqd4gId1OsOOfr.TQzS90zfW64Ry995Tqwf27ilp4H_bzJEOq3LMN5H4BNOxS p9k2XCY9FTwlM.Nr3Ywds7SFRzLYqXg1LwBFvWhQyXAPbTne48H_ubEuX5_o1gPjNDjOyAyoaaUV eSeTQYE9WOaLRsXHs1fwMvxKlzL87VFzCv0F8VgaPiaUsSjuDqLl4bMX95DtYIUQjMmUvzepQhQh .ADWtBgiCTFVnqUE6zRbZqMJmejxKT_7Ghp39oR0wmxDJ.wX7_YgW0dtCpqUgHV82WTDHCdS19t0 bhL9U95g3jKX3cjvhc3EHHEU7CgGOqT9xCu49wuh9iQltruOsYd_mMMOzQfUaDl8N9_xM5shB72t y5DAvyFuT.Zzsg7J27PuxOyFPOxkLi9hlIKLS4iJ3BCUzMDaLPw8FQujfr7_tmDIthe8ub_KEQ4B 2zPAIEKVnkWYR6GcpO9SJWh6lD9PjoOyIszatNc9KKPL9_R7C4Vxs9F8H.Apn5YACReOkfhTPjCn 5NwkxzfIxbZMq2o0BZyO1raGa6ijeI.jWgojnRVkj_nO.HbbEUJm7SmPo4OK1Cz0cLv3FNof9vzb epCmx7VhqKweivn7DV2TFC9lmqZJPIBYmHeakN41vuUan5VBeXzW4W_ir669eV2ZNhEY.NMkxoZ2 gW6FdGz80iWEhNKhNx9h3MHNgS.4E.GqMH2Eu2fRPWD8gr59sDhcF8dePaC0uMucHjI.NUefTR.g 3pQOANELiWVR9D1cl3EcsuXOYRAteqOeVL2zeiy.zhebyhtZa5m2oob3p4N8AqMZwco2WCB0wIxd .SK3HCJT0NyMS.NAT0w6GHimb52XfVgg9T3JRxuB99kiXd2mfaFkcHmCgRWET12nSCafVMYyEN.h 8ZnL0RO7FHZUs84NMErlkNG7_GypP9vBG4RqVLAFmN7w2G6yVAnPJU1Zpk0ER4mn7ziisBpxXFUb Rl4s_YML0CY_NuPI83l0Ys9C4kjyGAXUcW.sByZr3lX10f.6zQw8YdMzJbwW.LJFJXmVODuZNS0T Q3OJ7B12zuLYQwslKRHaw1qBL.4vKeRKiPdVbTSzzVruUsr7gXuZxZ6vHzYPYfSvDws8bCQQC2kU o9hWA2fc4kWdcddACYASu9XELSXgHCSfMUhn1COQiPR1pwyQp3jUTwZwNCkKBrtJf9rhVLrHQKSg k7rs1NMR0.sgZBGMhncQJ_R5Z8UIia4V6Nn0ReOGVSkXgedEspLiJ4IXlguQbO7yH7v6DyYuTwTs 6w8Z2jtY.ZkHiYpmG4nfK9bwIVBgY1jC0Xr1Fo0AisitK3UGjd2Fjug0xKX1eWU936ZuulV3GDUs fCbNESeuIyiWAqvQC9kjGRCrgMeh.bkD.7.Mj1JZCw_DV8XoG5akwsKFYK3xpEVXpmTQr2uY8MRG vbgOhBGNyUIg9G3uxEV1c3CVg_ZhYo6YLLBC37HI_8dGFVy2ibd7eu9eky2LIR_WVwZnYJQHhrRd UKxZBwwsY7INxz3wXXdOMx9q3i3zzgOa8PweUb1TylGH.pFg_jQfCDd7j1S4RR_U4rWAnainqXbc Y2mqzMTP.UzA7i.XNL80wvY_s3ND3dsGNK_FPG_qbxNc8t.YySA1AKPLLfVweUrrGbgLfM6AEnj9 C8qSTwAItwv40AUUzz_gVDdcr15IWCxW44j2n3c_aTcDVqHSz1VhXMjEosopN4W8.5JV.eVUzdYR pMW1oqH6uOUCIc9.XsS7b9pCmPVEnrtcUMePKLWXAjIxIVS6GGUGxIv7lPkNOpqZRZ8e0bkFE4qc 16kc6_vX5AaiCTbtkk90GH6fAgLmCwU0q.fpy9FjgSURbrYjh46tFhct9kg9UnWbuKcpSC9f_R7x .BrM0hprHrJndT150ZJ_Gfe0dE.RtLBDnYgo_E0ev0.uHWu6fFXiSrQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 13 Jun 2021 03:17:19 +0000 Received: by kubenode561.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a5e2a6d640c4044927bdb80fd1b7f151; Sun, 13 Jun 2021 03:17:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: Boot from USB on RPi4 8GB? [SOLVED] In-Reply-To: <0E3E9A40-2E56-4C49-A992-247408A88EFD@dsllsn.net> Date: Sat, 12 Jun 2021 20:17:14 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <4F6B79E1-B087-4606-A4B8-663FD85105BD@yahoo.com> References: <4F3EE8D2-649B-4522-AD5A-7C308291802F@dsllsn.net> <43FAEEAC-EE36-4810-88AA-FF82AFBCC128@yahoo.com> <2F58272B-BD9C-464B-9A98-BF638971BA86@dsllsn.net> <0E3E9A40-2E56-4C49-A992-247408A88EFD@dsllsn.net> To: William Carson X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Rspamd-Queue-Id: 4G2frw4mqBz4p2W X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=o43ShCVY; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; 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]; NEURAL_HAM_SHORT(-1.00)[-0.999]; 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/20, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[98.137.64.146:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[98.137.64.146:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.146:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Jun-12, at 18:18, William Carson wrote: > . . . >>=20 >>> Sadly, it also would not boot from either of my NVMe-USB adapters. >>=20 >> Is the failing behavior identical to before? If not, what >> evidence is it now producing when trying to boot? ("would >> not boot" leaves open all possible ways of failing.) >>=20 >> You previously reported getting: >>=20 >> QUOTE >> scanning bus xhci_pci for devices... Device NOT ready >> Request Sense returned 02 04 01 >> END QUOTE >>=20 >> Someone else recently was getting that and got around >> the problem while trying 3 U-Boot extra steps. They >> are listed below and I leave in the indication of which >> happened to work in that context. The point is to >> establish a configuration setting before U-Boot tries to >> scan the USB buses looking for the storage media. >> Otherwise a "usb reset" would need to happen after >> making the configuration change. >>=20 >> QUOTE >>> Looking around on the web I see reports of the: >>>=20 >>> Request Sense returned 02 04 01 >>>=20 >>> (and the matching Device NOT ready) mean that the >>> problem will occur and that repeating usb start >>> or usb reset again until it does not report that >>> leads to things working. >>>=20 >>> But I've also seen other, more complete information >>> indicating that there is a environment setting >>> (showing an example value): >>>=20 >>> usb_ready_retry=3D5 >>>=20 >>> to set up before the usb restart (or usb start) >>> command. It deals with the issue more explicitly >>> for slow devices. >>>=20 >>> Another one is (units: msec): >>>=20 >>> usb_pgood_delay=3D10000 >>>=20 >> Presto! using editenv usb_pgood_delay prompted for input, typing = 10000 >> and hitting return set the value and the disk was found. >>=20 >> It looks like the setting can only be saved to microSD. With >> no card saveenv reports >> Saving Environment to FAT... Card did not respond to voltage select! >> Failed (1) >>=20 >>> There are also device that have problems with >>> large transfers and require extra protocol to >>> deal with transfer problems before they will >>> work again, U-Boot not doing that. >>>=20 >>> usb_max_blk=3D20 >>>=20 >>> sets a old historical value that generally >>> just works for such devices form what I read. >>>=20 >>> I see no indication that other usb commands are >>> worthwhile until one has avoided that "Request >>> Sense returned 02 04 01" message for usb reset >>> (a.k.a. usb start). >>>=20 >>> The reports of this sort of thing are not limited >>> to RPi's and go back to at least 2014. >>>=20 >>> If I understand correctly, usb_ready_retry and >>> usb_pgood_delay and usb_max_blk are part of >>> normal U-Boot builds these days. But I'm not >>> certain of that. >>=20 >> END QUOTE >=20 > Ok, so in the scenario of SN550 + GeekWorm + USB3, when I'm at the = U-Boot> prompt, I did the following: >=20 > editenv usb_pgood_delay > edit: 10000 > editenv usb_ready_retry > edit: 5 > editenv usb_max_blk > edit: 20 > usb reset ; run usb_boot >=20 > And we have a successful USB3 boot all the way to the login prompt! = Unfortunately as indicated, I could not saveenv. I'm not going to bother = any more with the Samsung NVMes due to the power issue and not having = any way to provide external, dedicated power to them. >=20 > With this success, I figured I'd try adding these env values to my = u-boot build and go back to using my crochet image. I added this patch = to sysutils/u-boot-rpi4: >=20 > # cat files/patch-include_configs_rpi.h > --- include/configs/rpi.h.orig 2021-06-12 23:20:03.061510000 -0000 > +++ include/configs/rpi.h 2021-06-12 23:20:14.131306000 -0000 > @@ -209,6 +209,9 @@ > ENV_DEVICE_SETTINGS \ > ENV_DFU_SETTINGS \ > ENV_MEM_LAYOUT_SETTINGS \ > + "usb_pgood_delay=3D10000\0" \ > + "usb_ready_retry=3D5\0" \ > + "usb_max_blk=3D20\0" \ > BOOTENV I'd be surprised if all 3 assignments were required for your specific context: likely more than what is necessary for that context. But it might not be worth bothering to explore for a more minimal combination/singleton. > I built my new image, dd'ed it to the SN550, and booted with the = GeekWorm + USB3. I aborted the autoboot and did a printenv to confirm = the environment variables were set. They were. I pulled the power and = did a fresh boot, and we booted successfully all the way to the FreeBSD = login prompt! Problem solved indeed. Cool. > Thank you so much for all of your help and patience, Mark. I wonder if = maybe those defaults should be added to the u-boot-rpi4 or = u-boot-rpi-arm64 ports? (I won't pretend to know how this might impact = other users.) >=20 > Oh, also, I dropped usb_pgood_delay down to 2000, which seemed common = for other boards and worked just fine: Again: Cool. > -boot-2021.04/configs/teres_i_defconfig:CONFIG_PREBOOT=3D"setenv = usb_pgood_delay 2000; usb start" > u-boot-2021.04/include/configs/alt.h: "usb_pgood_delay=3D2000\0" > u-boot-2021.04/include/configs/aristainetos2.h: = "usb_pgood_delay=3D2000\0" \ > u-boot-2021.04/include/configs/beacon-rzg2m.h: = "usb_pgood_delay=3D2000\0" \ > u-boot-2021.04/include/configs/gw_ventana.h: = "usb_pgood_delay=3D2000\0" \ > u-boot-2021.04/include/configs/minnowmax.h: = "usb_pgood_delay=3D40\0" > u-boot-2021.04/include/configs/nitrogen6x.h: = "usb_pgood_delay=3D2000\0" \ > . . . =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Sun Jun 13 19:18:13 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 858E211D7F6A for ; Sun, 13 Jun 2021 19:18:22 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4G349p22lHz4cBw for ; Sun, 13 Jun 2021 19:18:21 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from [192.168.42.21] (cpc91232-cmbg18-2-0-cust554.5-4.cable.virginm.net [82.2.126.43]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id AA10A4E6E3; Sun, 13 Jun 2021 19:18:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; s=mail; t=1623611894; bh=x683kAitLHkLUalayh3olo01cqxvcyGp0ldGxRcPZtI=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=rZm32eWkcc49BcD+6oYJV/J+Ka0q0fVy8yjeNUMcpyfFQigtf31GlC2ThhNoXXZOI sYHfz/KjW9j8STOF7NQ1vZCVp6o9UP3zz5KsQbmxIcXSiIpIZm0NQespAFwBH55MY1 37F6zRxpUQArNJpAdK06ZvB/NzaGQIKMeWHS5p3wpjpMPYKQhfrxNI0fiPRfkoKHjC IqCYXotNjqr60fCFftg/9iSnWfJs/f7FjFfJdxb/vrMiPmWbU6jRIvucjwp5sHRpeD eaPGYmr7AtRRP8evNYCfvd3A8G6RYuUwciBJWZvOr+oe9U/YixTR8Dcuq9PAUDFSs6 XlpsE0BPvm31uXz4jFgwI1mb7sMzbonRjxU/hVRW/DDYb+VnsvLiD26TplA8c2fQBp YtYqrlu48ndKiqRw5LpKmwivhfhkqTiBW7URtzwCw+3Tzgyc6encO35joxESj64Ikq 42eI95B2u76m+jGsdAIE+B6QjizOF0JPtSCo4dwGp7RHHmOxZWNIuG1HoW1epKX+WX ZAmyUTwPn0PnMFdwpBSRFdA4C0HQ7aiBe1AWvdTPfGudFlZH3RcryODgxjf9oiLTB8 kZTTJtNtOblXEaV+lW315JvYyYUWLCsdxSIj4+RqhwI48VxpoVOKTXhkIOD7Vf3REh NdDim7Zu+1xqUOArrjaHHGnY= From: Andrew Turner Message-Id: <26D60C14-9A4F-4E0B-8B1B-D26483AD7B55@fubar.geek.nz> Content-Type: multipart/alternative; boundary="Apple-Mail=_EA4F137B-1CD6-4302-AB72-6D3C1916CCFA" List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.20\)) Subject: Re: arm64 stable/13 boot stuck Date: Sun, 13 Jun 2021 20:18:13 +0100 In-Reply-To: <4affccce-080b-1108-a845-8e8811fa3bd7@shrew.net> Cc: freebsd-arm@freebsd.org To: Matthew Grooms References: <4affccce-080b-1108-a845-8e8811fa3bd7@shrew.net> X-Mailer: Apple Mail (2.3445.104.20) X-Rspamd-Queue-Id: 4G349p22lHz4cBw X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail=_EA4F137B-1CD6-4302-AB72-6D3C1916CCFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This should be fixed in ade8b810b02f. Andrew > On 12 Jun 2021, at 23:28, Matthew Grooms wrote: >=20 > I just updated my rpi4 kernel sources today and get this very early in = my rpi4 boot output ... >=20 > bcm_mbox_write: STATUS_FULL stuck >=20 > If I roll back to 043f204985261d6daae69538c4609b3e143ee444 from = yesterday, it boots fine again. I assume this is related to Andrew = Turner's latest batch of arm64 commits. >=20 > Thanks, > -Matthew >=20 --Apple-Mail=_EA4F137B-1CD6-4302-AB72-6D3C1916CCFA-- From nobody Sun Jun 13 21:00:29 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 90CAD5D6FDF for ; Sun, 13 Jun 2021 21:00:30 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G36Rd5flkz4mRr for ; Sun, 13 Jun 2021 21:00:29 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 424FB27E43 for ; Sun, 13 Jun 2021 21:00:29 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 15DL0TA4021107 for ; Sun, 13 Jun 2021 21:00:29 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 15DL0TWA021106 for freebsd-arm@FreeBSD.org; Sun, 13 Jun 2021 21:00:29 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202106132100.15DL0TWA021106@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 13 Jun 2021 21:00:29 +0000 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="16236180292.8eEEd2.20383" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: Y --16236180292.8eEEd2.20383 Date: Sun, 13 Jun 2021 21:00:29 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 239673 | Spurious Interrupt message from /dev/led/led1 2 problems total for which you should take action. --16236180292.8eEEd2.20383-- From nobody Sun Jun 13 21:08:43 2021 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 304FD7CD19E for ; Sun, 13 Jun 2021 21:08:52 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx1.shrew.net (mx1.shrew.net [38.97.5.131]) (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 4G36dH23TQz4tQX for ; Sun, 13 Jun 2021 21:08:50 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx1.shrew.net (8.15.2/8.15.2) with ESMTP id 15DL8lKP034462 for ; Sun, 13 Jun 2021 16:08:47 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (unknown [136.49.68.36]) by mail.shrew.net (Postfix) with ESMTPSA id BE3E1199FE8 for ; Sun, 13 Jun 2021 16:08:42 -0500 (CDT) Subject: Re: arm64 stable/13 boot stuck To: freebsd-arm@freebsd.org References: <4affccce-080b-1108-a845-8e8811fa3bd7@shrew.net> <26D60C14-9A4F-4E0B-8B1B-D26483AD7B55@fubar.geek.nz> From: Matthew Grooms Message-ID: <39b72240-92a1-3f24-9ce1-3fdcc24149d8@shrew.net> Date: Sun, 13 Jun 2021 16:08:43 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 In-Reply-To: <26D60C14-9A4F-4E0B-8B1B-D26483AD7B55@fubar.geek.nz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.shrew.net [10.24.10.10]); Sun, 13 Jun 2021 16:08:47 -0500 (CDT) X-Rspamd-Queue-Id: 4G36dH23TQz4tQX X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.131 as permitted sender) smtp.mailfrom=mgrooms@shrew.net X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[38.97.5.131:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; 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]; SPAMHAUS_ZRD(0.00)[38.97.5.131:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[shrew.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm]; RECEIVED_SPAMHAUS_PBL(0.00)[136.49.68.36:received] X-ThisMailContainsUnwantedMimeParts: N Hi Andrew, I can confirm the issue has been resolved with that commit. Thanks for the fast response. -Matthew On 6/13/2021 2:18 PM, Andrew Turner wrote: > This should be fixed in ade8b810b02f. > > Andrew > >> On 12 Jun 2021, at 23:28, Matthew Grooms wrote: >> >> I just updated my rpi4 kernel sources today and get this very early in my rpi4 boot output ... >> >> bcm_mbox_write: STATUS_FULL stuck >> >> If I roll back to 043f204985261d6daae69538c4609b3e143ee444 from yesterday, it boots fine again. I assume this is related to Andrew Turner's latest batch of arm64 commits. >> >> Thanks, >> -Matthew >> >