From nobody Tue Nov 28 20:47:53 2023 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 4Sfvg00dRyz52XZb for ; Tue, 28 Nov 2023 20:48:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 4Sfvfy73v9z3C14 for ; Tue, 28 Nov 2023 20:48:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=KX3FM1j0; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1701204488; bh=1h88Cg4Z/AA9da2EZJ/TSaqC6AKdgPTIzNvQcUQrZvY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=KX3FM1j048qYbBzaVwCqEqlLbsfPO7/RZBWT9Jd8Ac1XkyFpa2cRyHkDPWmv9zlyGCAYUSJaqRp7ItXARUxf/ffXBrwiNU/T7WILG5a9OaWkf3ACACQbCuZ8cwa1W1NScWp4IBPYqThEKst9FQPqiPiIWK3ehILZR3PtTT0DuLdllLYIY0CRd//WeFadc39+7fxha4K3PPRqiPu9dAUcVi1Z5fbMujNlkKegwruyMq9/wjFoBYKlj9/IWyztZU1b/ucBHz/zJ12NgfIqGLDui6FYdyRtlmxujhqdEDQ1nIM7Dk1gnCvxyBLD3lpkM4mNx65915aStxYD9Qvrbr25vA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1701204488; bh=h3+ULfJp8bII8AquUlsJPX7NfsBjbeAHynV7kqZ8Wck=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=mei2VA8fjzoHoHcTTJm67AuKp00AsDNrwc0MBNXD9XBuIl3ML0RRTnmf5FI4qXcPGBNKo7/waA3IUj3/IBsdXeO0HcWWEbNniM5E1++ymWi9vRct0Dg3mT2k04K3aVuAjgJVyCxeOVkLjOxxXhkYIPT5TRWeM1ZhnmWEXSSEjymBjOceQPgXVBj78U3MNRUmT04OC1xMfKbLgSui6Qd2Vs4UDpoffYNJd+JidxBPUtlVvKI4er9WvSA5vVElJYWhqwHwv0RTGyqDgVQ2V1vC/EAZp5kBDFqUicaRbsgd3AhUx0Y4eRRxpxH1RZSx1DsKqSsGFhveUnQ7lXz/e/7u2Q== X-YMail-OSG: Z1QjWqwVM1msHPiXr2NzpGuMladE4i_ugh1bhqwPz7nYmd4Ic0eRuoEU4k9b4cL gERjlBFxUBATzAEX3Lka0YeP4EWJhP5vkiYtYnVflqnGF4rZao6RokrTnfNJuNd4hEmpLCCTFBVd GUg0_3.sEmPKlZYUJiFiHI3Z8tBL_1DfdUtfzXMPKqI6m3CHsbw0qvQNZygGa9K_XTGmu9Ktosov PPFKPelCd4xg18QUgraJ.VbTqA_z.0bFx8jEAejPalEGp9KGv6XRa8xTPabqr0BnfcCOFWS0.PpQ TI6TbEwwkr9UYrXO8xklp1ac2ps_GWorCnH9KIyOSymvSCddNPQXk1Suk1y3yWO6dc95q_0CWI_n 2B_BKb5TOBekjRwoT86WxsU3X1CzWKHvojndVDUSxS6GFeNTNKzS4IHL_bNN.F6vbKUa4GWIiWzq _qHLAJEJSMax4QXsUEO3oz.B5pmwVPMdMyg80_FQgJdv9SrLOrsSka93hZujoTbYsYaAq04x37oM 8THiwB2U78.NwR4z2pvJczOMDd4cxMXqnS_VKC29tuzk8Ypk1N6WWvPZ9NLnHxe2LIOOJNrAIyyz ZRlScwU8dxdWgeK_UNakO3JiZCaQYkz5FwoZ0_6Vvoz1ui42veV49srHkxLDxxQYaXJ.nOgHFIKc ZPzDht43W3bn8kHNzVUVRRaohyvTNSFIOMXsUONbDQrhb8IP.XhYH8IMqSw10nk.fvASrkuPY6b3 MTm3BcTfaNGhhgzAG4L8cixABfuxJSX1X0iPy7c5vmLddcGRi5pgprLiy7Q99hZugHnxSJfiuV0H Pnfnw5tL2XDhzOmwDfgQ4gTvycQZ1Vb9n0jioygnzbjAj2H1Im5y7.915dYQXmuceWd46Q4Jek4b PkVdDQfKqMNvV.jbTcf.1kzG0_JpJ_KdjBOsrcj6JpLA90.8VsgkrI7LGq5fTjDFBKA3t1TWX54r rT_M.tlxg6CrFjdMAWg6UeDgcXcW5R4lWl1VGfgEn8CFjAftagSDEBcO2x_DhzThEPwm_Ve2y3SE IVilmJ_jJiRNhGWsSjJNu4o5XSQZ5UsEL_SQqYL3PBq_CB.9zv1leHUKYLpY.zA17P2Psk3YtUtc HsOUuQdB7Qp6ML2.wIDi2i2yCEaxXaaJBriMMyIBbZtqyHssqeh7SM2mG.hJf0AHXnnjb0ZHqSAD UIisk9PLDB1BJ6SsWZhe4_szMv_W9mtLJAJpCofR0HJD.9_YEU3Xj0PJDRpeXAm3Xky8ZwoWf14Q VvIKXOhJyEPz_NQzL5a1DPPxLLILAsz_wSaYDhE42sTPREAsbBCaeRNge6lQZImq9jLqjRLvV8vq plx3fA3Fl7xgPzZ64ByrFwnFddl3em8NhWG5XZoauNVWgL0cus.pJI2fl7R5jSKgWE8Y0G6o_lw1 iHKHl5SxnXcE0bt_TiIQSlxVaXKt9z.5_rhyXLS0rCPRwm3w3uKIht1gDeHYUoDWW.eyubqjg5Nw AEdUM7eE1.WTneaHZLKjBPUCtiXBazRIu0XnsGSn4fZNW6RMQ0IoSsd4.jG0d3PT5AGP.hOjUw5D vttrdSQWZHGsUfnKws8Muzkk.vTmHDCZzsmTL8nmA8fyVFLQaIIWKNP9p1Dnw8cMZe68Jov7dk04 1v3TJ1zJ.7fkmw12pE8n.svI49GmgxfD1q0hqw6BxHD3iQZzfnCsUDyRVyvBVnVrt596FNZBGld. j8EM9.eh3he2Faabyqs9heVdJgPJGFmO9vKCUsJakRqNKv1zyU5SiAURi_aIUs6Z3HhdoWHZjsiP GM7Y6Q3fdx43IA1OiR48Fc3WNtOTMOChY1pCffVnQiWv3gdc26lwp89HrFithkqSCWM8c2Cdmum9 hbb_7uVZPg0LDf_Jwy7j.dovQ1fzmayvk4Yq_uaMQ.g_AsBj9YCJiJrUtDCaRPvG6VUf39BIU4mH M2YNEYj34FGOnfCop5UBMpxhibOn5E0Xv4fPHEkrgE6Hn0oBNrqBNGkcBawrsubJnMSis256PnV6 .QYp5eLBoIEM5MO8Duso0DTu6_ZvE4.DMnFmpK3pVtlmsLkW4oMeT5wu_enoGR9dAxNraKcwpTRF _1kSM0KsLfK3Nk2w2jAz88Cvq7lZF7c9EiCKDgGUorTNFlVrfUw3bz3TjCfBnAIVxrysziSk14Z3 na5Gr1UnpsCq46mZvwWBs0JHzHm56i4CTFm6wos28h40C7gxgjGwyx6kodmHxNkVH9_qteVR0zIj 1YmSPTTp6sJ0Kz3ntRLJcEP7Ew_5BFM_.SId2pKX_KQBRSf2.SPD0W6tg41k_ACTrS_.rq9sikk7 Ea4ajjBLXPB0- X-Sonic-MF: X-Sonic-ID: 1f329027-b970-42dc-9318-8f42a4f3e0c0 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Tue, 28 Nov 2023 20:48:08 +0000 Received: by hermes--production-gq1-5cf8f76c44-dxf8l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 70da7e043b12d8ab1225eda66812be01; Tue, 28 Nov 2023 20:48: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 16.0 \(3774.200.91.1.1\)) Subject: Re: reboot hesitation on Pi3 running -current From: Mark Millard In-Reply-To: <301571AE-130B-4BF7-B703-9458CF524F46@yahoo.com> Date: Tue, 28 Nov 2023 12:47:53 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <9E47467E-4147-4E08-899A-94D59A1A75F6@yahoo.com> References: <4078F04C-B4AA-4029-B260-2A075A8832DA@yahoo.com> <301571AE-130B-4BF7-B703-9458CF524F46@yahoo.com> To: Steve Rikli , bob prohaska X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Spamd-Result: default: False [-1.31 / 15.00]; NEURAL_HAM_SHORT(-0.98)[-0.980]; NEURAL_SPAM_LONG(0.80)[0.803]; NEURAL_HAM_MEDIUM(-0.63)[-0.634]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.31:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.31:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Sfvfy73v9z3C14 X-Spamd-Bar: - On Nov 28, 2023, at 12:35, Mark Millard wrote: > On Nov 28, 2023, at 12:27, Steve Rikli wrote: >=20 >> On Tue, Nov 28, 2023 at 12:00:08PM -0800, bob prohaska wrote: >>> On Tue, Nov 28, 2023 at 09:05:59AM -0800, Steve Rikli wrote: >>>> On Tue, Nov 28, 2023 at 08:15:30AM -0800, bob prohaska wrote: >>>>> On Tue, Nov 28, 2023 at 07:20:03AM -0800, Mark Millard wrote: >>>>>> On Nov 28, 2023, at 07:10, bob prohaska = wrote: >>>>>>=20 >>>>>>> A Pi3 running -current has taken to pausing during a shutdown >>>>>>> -r in a strange way: It gets to:=20 >>>>>>>=20 >>>>>>> Hit [Enter] to boot immediately, or any other key for command >>>>>>> prompt. Booting [/boot/kernel/kernel] in 5 second more >>>>>>> detailed help. >>>>>>>=20 >>>>>>> It then stops at the OK prompt: >>>>>>>=20 >>>>>>> OK boot <---typing boot fails: >>>>>>>=20 >>>>>>> unknown command <---this looks strange, the kernel should >>>>>>> already be loaded >>>>>>=20 >>>>>> A possibility here is garbage control characters, say before >>>>>> the "boot". YOu might want to type just to the first OK >>>>>> prompt and see if you ever still get "unknown command" once you >>>>>> do type just "boot" (and ). >>>>>=20 >>>>> IIRC I've done that in the past with the same result, but memory >>>>> is hazy and an attempt at a second shutdown -r came back up >>>>> without hesitation. >>>>>=20 >>>>> Another build/install cycle is running now, I'll be more careful >>>>> next time. >>>>>=20 >>>>>> The fact that the countdown stopped at 5 (or other early value) >>>>>> suggests such extra text at that point. >>>>>=20 >>>>> Rubbish on the serial console is a common occurence, but it = usually >>>>> shows up when the USB end is taken down and brought back up. In = this >>>>> case the USB end remained up throughout the reboot cycle, no stray=20= >>>>> characters were visible. >>>>=20 >>>> This topic has come up before here, I believe. >>>>=20 >>>> I can confirm the same or very similar behavior on rpi4, and = there's no >>>> USB-serial to disconnect on the remote end, rather an actual serial >>>> console server which is always-on. >>>=20 >>> That's a significant (I think) observation. I couldn't tell where = the >>> stray characters were originating and suspected the USB-serial >>> adapter. Your experience suggests very strongly the trouble is local >>> to the serial UART on the Pi or maybe wiring problems.=20 >>=20 >> I tend to agree. No USB-serial adapters involved in my setup. Wrt >> "wiring problem", fwiw I've tried multiple cables and db9 hoods, with >> both full-pins and 3-wire, no difference. All work as expected on = other >> systems (NUC, various x86 PC, the occasional network gear etc.). >>=20 >>> Is it possible that the serial port of the monitoring devices = occasionally >>> echos output from the Pi's console back to the Pi? Seems to me it = shouldn't, >>> but sometimes I see fragments of a login prompt among the rubbish.=20= >>=20 >> I imagine it's possible but I doubt it's happening. I've swapped = ports on >> the serial console server as well JIC, again no change, and no other = systems >> or devices exhibit behavior like this. >>=20 >>>> Unfortunately it's not consistent behavior, i.e. sometimes the = reboot >>>> proceeds uninterrupted. Sometimes typing 'boot' proceeds normally, >>>> sometimes typing 'boot' errors and then typing it again proceeds as >>>> normal. >>>=20 >>> Does it sometimes reboot hands-off? Mine does, at least = occasionally. >>=20 >> Yes, sorry, that's what I meant by "sometimes reboot proceeds = uninterrupted". >>=20 >>>> I too have been thinking it's spurious chars on the serial console = at >>>> various points, but I've yet to find a common behavior or = consistent >>>> method to reproduce. This doesn't happen on my other serial = consoles, >>>> FreeBSD or Linux. I also don't think it happened early on when this >>>> rpi4 was running raspbian for a brief time, but I didn't play with >>>> that setup very long. >>>>=20 >>>> So far I believe it's avoidable by not watching the serial console >>>> during reboot, not necessary (I think) to disconnect the cable. But >>>> obviously that defeats the purpose of the serial console vs. a = blind >>>> reboot. >>>=20 >>> Hopefully "not watching" means disconnecting Rx and Tx from the GPIO >>> pins. If it means not looking at the display it's a whole 'nother = story! >>>=20 >>> 8-) >>=20 >> Nothing is ever physically disconnected from the rpi4, if that's what = you >> mean. Fyi my rpi4 serial console is via a "Serial Hat" which = ultimately >> connects the appropriate GPIO pins to a db9 connector accessible = outside >> the case, which is in-turn connected to my serial console server. >>=20 >> "Not watching" in this context means I do not have an active = connection >> to the serial console server port which communicates with the rpi4 = db9 >> serial port. >>=20 >> Somewhat analagous to not running tip/cu/minicom from your laptop or >> whatever system you use to connect to the rpi4 GPIO pins. >>=20 >> Another note JIC: there are no keyboard, mouse, HDMI, or USB devices >> connected to any of the rpi4 ports. Only power, the serial console = and >> a network cable. In that regard it is a neat little headless server, >> but unfortunately I don't really want to use it in production due to >> this issue. >=20 > I'm going to remind of the known issue with U-Boot on the RPi*'s > sometimes leading to odd serial connection behavior for the > transition from U-Boot based UEFI handling the serial connection > to the FreeBSD UEFI loader handling it. >=20 I found some of the old text that referenced one of the examples of a U-Boot -> Loader text oddity. Here it the 2023-mid-April text: QUOTE But I can report that the prior [6n (Query Cursor Position) before the FreeBSD loader's OK prompt is during U-Boot activity: part of the escpe sequences just after: Device 0: Vendor: OWC Rev: 0 Prod: Envoy Pro mini =20 Type: Hard Disk Capacity: 228936.5 MB =3D 223.5 GB (468862128 x 512) ... is now current device Scanning usb 0:1... This suggests that U-Boot failed to read/clear some of the Report Cursor Position text --and that the loader accepts what it finds already present (probably so that typing ahead of time would work). So: Looks to me like a probable U-Boot issue for which a FreeBSD workaround to ignore text would have other consequences (lack of effective typeahead for the loader prompt). END QUOTE =3D=3D=3D Mark Millard marklmi at yahoo.com