From nobody Mon Dec 27 02:25: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 8B7A7191EFE2 for ; Mon, 27 Dec 2021 02:25:40 +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 4JMhNM3p0Kz3Jl9 for ; Mon, 27 Dec 2021 02:25:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640571932; bh=UfUNQ8/RZpq4r4qKeA9vHCd+L5+38HnvPC7zg7zQexk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=GPOa/L8n57BHJZXpAvL6bYgXG6Qq958vj3NaR9S+7auCkT5JL3rqfmp5NkVFj5wJb9DzQ/WAYncsx+ursVM/HHlEYVmYlFXs0vqJQ2nLc3g26wgvCCTFXR2DFgOcw67kYoQeof/F4ftNLon0s+rxM0FRLTcFO5rU7TM90iVWnh9yrjMSI+F4NRdoyGVnDgA3f7OZebGrFRv0Q4R+k+cw7GWgnB0xnXfuMjN75bTtOTZxwgDOv5/rYq++qURGTl5+qxo66hrIQvR3tgky7cQJiW3LHIFY+rK9N3Bbgrm94yExKZ3LeKd69ojj/9aHdN3LyqwQO5UmSVfy+qyqdKdvXA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640571932; bh=nj/kh0+42uTsfshyMHB1x+g12I6dLJmghd+2B+iaIAW=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=oDDhBQcFv6IjAfBbSBYZpPAkaO+bv2qMis64Q4w2imqXGAQ3V7TSaFRMJXxhtSugUJzR5M7nQVcZ23T5lfVi5Vm5WfRk4nj0pNqf9+WVfPMwijMr9iGg3xLULU76Ho9TZxXXhgwZvDipy5qNzBuXKbOUvdZsY/9vTHeGr0FoLGiaEtDIgSrb287m6Vy78lsZ2asIpNB5xZAeGHQl2ljgqet+ne6FdZ7rx0x1rYJC4eJLJrurN3SQ/MNC8uGdwfWwr/aY4g01kLGwtcScWIex0NX27x8L33J2ru30Q4CiuDJF8N15PMVe6CCoAJUPMSP5J65b4jV3vC0MHtLowb85EA== X-YMail-OSG: dSSYZ.IVM1nTRofUdC1nq6.aOVdTtizelwGbihJF_ML8PlEnkMnC_dJOMrCdpQE 1KTP.miKFPQz1jjhLlC0KRJ5WCjLbFjUDrZ80uiF.e0YFVl4hcTo1g5WkvxDFzt2T2hk0zsXtsvL v08oVi_52q0ZkcH2Hmrqo7.6wOGhyG_CH6tQSvLxSSUfKaIget.__mbagW_mnRRRJ66G.uED02HZ lSBBoD4j9xY8UIQEmlQqUYpYqsgmPC.7xttjU2ggIKdgK16qI44X0AN.ftebfLRoHfL4tawbeHly eeH8vIvzgupf5uqxs97zfNCrXWhBwaJ5azmbypA2tCX5.cQxDtxb0KFMTF0u9.._Iu_SsMTtjqUa z8deQzbeplEtTlc5qfSZraHs_RZnst0gu6T0H94zyVQr4tCk7imoJKWtBGjACtQscxgcSi1km.0O ygsf3ydPdDuxpnZ.cPVPDkqE7T1E_.fq9jQW0S_5vgrkHOdKjdJC6BQjHNoLzuC1l3UJaV3JXEy5 3DUHYsI8TqlnCFD2wwxFVcbF9iAI_mXleScOGUL0JY4tmNN.jH88N0ua3kiwAjMs3iOiOyA8bYJ. Z7f8coOMdWEx_cDA9rjV3UKa7.ngi_2kFzYyfLtsk.7s5zcNU5OI8uPJpa35bRTT.5xZev6wBGSD g21K5sCmBiDPXykhDTxN6lOMoykgoj.obeRXzkLBEUEdGt.niE8nM29Yws4ePqzXxUPYST9ebw_S EiNYsRMNiy3uOR4Dq1Dc_6cyPpfIHjo6EXs1Yl1FjpZgsB8DsVg__Ib8Gby6ea10XNO3dCTjJHLd _hs40LuqdvBXEU15Uk2KszTOL5kIMvsBpixEAdxSS5C6AhNweC6doMbTnDR0bszRJuwvQKco3dfC yCq88JkXRbDcCHKDDSDUsIk8pfATsKUJLWPU5.YesDaMHjDQAaOn18cX.NZeXE4fMyuKefWE41S9 3gR61qncEhMK3xgwVoWnop1iXvk22v_1C1L9EQSQHtV0EtO50powE9Y9szrqEu64PqVm1PzyLtxE WhyVgJcIfCfzIXOFPcyEX14T8Hj1SGnpHTUvkBd0prDQtcUj8hIGHgpgjnObNsJtQFmIQV_LuBY2 ZYz_3JQD6dX0MAj0fRCahpMblXK43u43e0iCh0gS_DkOcxQXA9X6R3STgdlTZxfklT1xAW_Qmtct qgAEDemSrD8ZAalkCh9axXAN7yOPpp9398fIZ50MWbNkA23JvXhf8HSdmfRov6Q3O.0.NB4ekCYD RMdjTjYY7q6tfT3YQbhdEjrytK9XszcLGfssNPNsJKkJIwF5iIfHJ8CbaSCQ6rNCL8FNxxTQ3XD4 igI6r7lbCthEYSulTdRNhvp8c2PJ2uP8v.Jx.Nn04UiNvoax40ICJvTFep_3MLcLJxroMMgIdA2i 6VSnaFm7V2xSSGo5o35ziz7CufFJfyA0MOaf2bBm.2qeHIsatO55mwVoN6SZyECqM_E9sTXf.5.Z Dshe9CHhMNSBmfdXU2jfvsNBB2orBnRZfCy.HME0oBZ6mSMxIapoBOwdfYaH03V5B_1VpFFht1Zn mUVtXyuQB_QoGLO830SZcQldPZFb6OTq4KT4l6Rjzy2eQRPudcYwSYqBIhdr_uzzlrl3Oev7Cqy4 ZzUSxM5eIHknO4zt16Q37QhWXiv_xlNSFJ24CYNj14p5rzElUcqvTt5PdrfPoouUPzbO3Lypj8xo OL7Jot72Gnw8_7NOxaaZKkY_UjZQCvsvVDIRMppSNe5IEb4KQBD3Eg4CGGbTmjhpJ6N7X5Xhg4R_ pgqMBQazdQfpqV29C3lE03t6VgKVWkgskWpg2sSG10l5Dm36MP8hlpzZ2_hMqsn4mO.vm.QH6lNj pnRb9KbJVTaoqRc9iFz6XZFuG2TZ1G0scgKEBu2NzaPvHJTjwh9.4vt27i0e.bqKnegFLfGitcab NsTz2VBU0MFteIchRmRcJi2TraupSdKdf1MLHjk1yUvF8xQxcWIZIX7Zd0v9HwKnDiZOU2FWSZt1 TGAoqOkQhFoDHQ1vZHv91EfDFa5ESeF.0yAgiRC48DlfUVKDQwA.dmtCxftGe4nuHuHvSjdp8eP3 mFJX9mkJHWgeJJqeIgGhXidfBKFea9gCsavsi0KsAaHGw7OkRz0y1grpcrswRT58oZ8fPppuHJcI zeQSVnAwtb.tDoMQnF0JieISbw9udnen24NTpA4eeKHz_4PAx.nvWISQtDayyirnP2gW4oaZTwZA P3DHLJJqGZAV4HQ5mOADLxIayplQhRtxqks_ropA_j7Ju_oesJV55pLaaLteFfSLkeQk0Pe08lFM gMtdS2tyHJrTa5QCK X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Mon, 27 Dec 2021 02:25:32 +0000 Received: by kubenode522.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 12d8e60665cdf771a664f192f8a2c988; Mon, 27 Dec 2021 02:25:29 +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.120.0.1.13\)) Subject: Re: Hot-plugging microSD on Raspberry Pi under FreeBSD In-Reply-To: <1D17056C-AA76-4CF8-8A2C-C2908242AAFE@yahoo.com> Date: Sun, 26 Dec 2021 18:25:26 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211226192338.GA16188@www.zefox.net> <91D4CF6B-5690-413D-A873-2DB50CAF9637@yahoo.com> <20211226224709.GB16188@www.zefox.net> <1D17056C-AA76-4CF8-8A2C-C2908242AAFE@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JMhNM3p0Kz3Jl9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="GPOa/L8n"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.51 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.84:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_SPAM_SHORT(0.99)[0.992]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N Status: O Content-Length: 4532 Lines: 138 On 2021-Dec-26, at 16:40, Mark Millard via freebsd-arm = wrote: > On 2021-Dec-26, at 14:47, bob prohaska wrote: >=20 >> On Sun, Dec 26, 2021 at 01:00:38PM -0800, Mark Millard via = freebsd-arm wrote: >>> On 2021-Dec-26, at 11:23, bob prohaska wrote: >>>=20 >>>>=20 >>>> Obviously filesystems have to be gracefully unmounted, but is >>>> that all? Can the kernel be "aware" of an unused device and >>>> get confused if it goes away? >>>=20 >>> As I remember, for FreeBSD, >>>=20 >>> A) The built-in microsd card slot works fine for swapping >>> media that are not mounted at the time. >>=20 >> Ok, that's reassuring. I observed corruption of microSD card FAT=20 >> partitionss and wondered if hot-plugging might be the cause. >=20 > I could do a similar check of this context later. I misremembered. Rock64's vs. RPi4B's: they behave differently (booted with no microsd card media). The Rock64 reports each insertion to and each removal from the internal microsd card slot. For example: mmc1: on rockchip_dwmmc0 mmcsd1: 128GB at mmc1 = 50.0MHz/4bit/1016-block mmc1: detached mmc1: on rockchip_dwmmc0 mmcsd1: 32GB at mmc1 = 50.0MHz/4bit/1016-block But the RPi4B built-in slot handling reports nothing and gpart show does not show the media (which has a FreeBSD installation on each). In addition, for a microsd card with: =3D> 63 62333889 mmcsd1 MBR (30G) 63 8129 - free - (4.0M) 8192 62325760 1 fat32lba (30G) that has the msdosfs empty that is put in the RPi4B microsd card slot before power-on, the Ri4B boots off the USB3 SSD. After the boot it shows: # gpart show =3D> 63 62333889 mmcsd0 MBR (30G) 63 8129 - free - (4.0M) 8192 62325760 1 fat32lba (30G) . . . Removal produces no messages, nor does insertion of a 128 GiByte microsd card (that has a FreeBSD installtion on it). And at this point: # gpart show =3D> 63 62333889 mmcsd0 MBR (30G) 63 8129 - free - (4.0M) 8192 62325760 1 fat32lba (30G) As you can see, it is still showing the old information from the microsd card it was booted with (that has been removed and replaced). >>> but, for example (no mounts involved, RPi4B 8GiByte test context), >>>=20 >>> B.0) Plug-in the USB reader, no media present. (USB3 example here.) >>> B.1) Insert a 128 GiByte media to the reader. >>> B.2) Remove that media. >>> B.3) Insert a 32 GiByte media to the reader >>> (same slot in the reader). >>>=20 >>> Result: >>>=20 >>> (da4:umass-sim1:1:0:3): READ(10). CDB: 28 00 0e e2 af ff 00 00 01 00=20= >>=20 >> [...disk errors snipped....] >>=20 >> Was the Pi4 running from a USB hard disk? >=20 > USB3 SSD. I do not have the marginal/insufficient > power issues that you have. The "power issues" reference actually has more context than just power. I did not want to write a description of all the adapter issues and such that might be involved. >> I ask because plugging in a USB reader to my RasPiOS Pi4 while booted=20= >> from a USB hard disk seems to disrupt communication with the boot = drive.=20 >=20 > You have described having a marginal/insufficient > power context in other messages. >=20 >> It doesn't crash immediately but can't be gracefully rebooted. >>=20 >>> If you do the 32 GiByte first instead, then for the 128 GiByte you >>> get notices from GEOM_PART about "was automatically resized" >>> but it does not "address out of range". >>=20 >> That seems like the "confusion" I was wondering about. The kernel >> notices the first card insertion, fails to notice the removal and >> then mis-attributes the change to a partition resize. >=20 > I disconnect the reader, swap media, and reconnect. That > handles things fine. >=20 >>> I expect that swapping two media of the same capacity would >>> be less likely to generate any messages, but that does not >>> mean that such a swap would be handled fully correctly. >>>=20 >>> So I unplug the whole reader to swap media. This is messier >>> if multiple slots are in use (more unmounts and later >>> remounts). >>=20 >> That chain of events crashes my RasPiOS Pi4, at least when it's also >> booted from a USB drive.=20 >>=20 >=20 > You have described having a marginal/insufficient > power context in other messages. =3D=3D=3D Mark Millard marklmi at yahoo.com