From nobody Mon Dec 27 02:42: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 CDAF619028BE for ; Mon, 27 Dec 2021 02:42:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JMhmD5zqrz3LsP for ; Mon, 27 Dec 2021 02:42:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640572971; bh=bUAAKISjf1xOlho+z9VuNrVGvrOrr6LYtxVvfiWIk7A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=lZsonhR9hvXL6cL4SO5HestI1UW/L9DzZdZou9cwFOyg8PvjkeF27GXV1J2+izM0hl8zKQ9uscd5B7qHA7QMTyPlBHJtqJiObzhUhdpJ104YgJRCVAvDEG07RLnBvuzYw9ZaF6LlYhAIEKvZvJkvYUS9FU5zu1PtB3jT8V4pSK6uSp396uTypiFPwS7kBoTn7F8Qxq6MacqPNbLJfHQu6fUT/P+QjI+/XgToIbsiB1KHZ9tM+Ip8W7N016G7M57a3Fc/Wv8CKwzMfFdyVoxHP3EPSFMRqtc9+nEio3+WP8CJW95fSKLZFzDQxx0wGAJ4H1SDwracp1+aUQfPJSlkow== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1640572971; bh=AL3XoqGjiqOzXcPDJxOeoFc2d+xoXZJeSxT9HqchxPE=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=C+AZpmae+wkjoVeta1cuhaL6gmb0m97So5opC2i4DZ7MRfGRu+YBRzNcgDlx6OIo28Ay5POsrzwegtE5y23tIma1sLe0FVTduqu80z1hTLcacGgDvwJICU1CqHNO822+msSQvUIPWCvp1kIInKD0wfN1UU9NX8MFypll59OJPNPpOjmVhiw875YqpsID+MVmVehSB7BgCZOy6WCveD79u0e6Kp9HBkqCljRu5hKoyatE4Ph1Y6L13RLDme00vgSHcSGU6gD5bJKVTUzkPNbn/XDHPEuiqf6KiAFLIwSqEyhzGgwPw4JStN/KPA0aHeA2Qa0GrR+l0u4ftse6Mcx/oA== X-YMail-OSG: rjbh.IwVM1n8tEwkcFy_ECzkVCVL9uJwZfiTPQXOxR95ulZfwpSelLuLUUwTWap 7YhLCSXt7rrep5kNf3zF5eA8shBvp.QtmmXso3hYVrgxz_q.sHpMqtZs_wvVlyYQy9w6QLqG7551 lyURPmPwiTOLEX7gAvAu2eAlWHb9wSncVm_5Y_RSRuc8mGgPlqiGvxCph5hVknRSf1ICyGF5A.W0 CC7SI1tuVgzH9z.S.1EvpwV83KNudVNaRTkj4JKe6d5N6Vx9iie1oX9cZQmrJBD2FX_whtyUkgok I_3KiHrfa.2lqesE2gAO23onKYcT6NQUPvEov84G2is07k20.9cFYJ6ZdcgurPkyWTIVmqLvURKE 8V5msgyr3xY_aKnlxj_QC8L8wfDIFXW_wfGGxMlR3WlSIk_3ITHEQYcsiIj_hxxviu3c3x2mfb7l fgbZPzhlkffhgmWU5Q9Tka.LgMXPbpDvYw_laCNBXukFwBDqfHzCtPAFPeKs3IoU0RuWteWEY9KL 4B.9aH6q7yMXQc2Q_jIJNfmr8lr.WeGqdjWDFSc.Qu4q5UO8AzaLqtR3Dc7_SD0G25LkXGhpsQ_M ypm2k.mbtb9dG1NO216IZ71h.rZsvOuAAP6jAftRe9Zo95MuXvcrtjLFSJEo3D3G2ZZ0O4DEJumD 7mVNDk6mOyQjNDxHOwTSEOn0wJaCXjHjWIPWGbFJbCknZuWhFRFSa_Kth70owwCtqTXUQ9TW.YZE cpVDjk7TYugTT7SWA5PVKXQU0DofcIs_sUEVzSWNWFitIhN34ep9N765wNfpxE23ov9ExWCrJ0eI 7cDlNmA1PTiqbf6f_iDyl9PQb79DT4kdzTIYCV.Ou9XwFA.BQludzfUU6sO5ukX89iRzWmJwEsxS wXmxnROjDupO_.LLnhZs6emnfIFCGN9hm35j_s4TfRGSBr8VPtOqApGlKcTiWtmlqq70b5bzhzZ0 FSDspAH9JKoJlee_aIxvZfeovm_dYDPCb5Ilp.nZc2FPFccRz93rkyQMFHdSeToIGtaIHSrsgpEN V7_77c2IyvpTk4KLgp66EM0tGawMWPRFtlgZxo.IlS_usVN1qAAJffNTAQjjizHfMufS9fFIDAx5 bMdQ.yUFH4MVXyvb4y7LnpD1k4V55ZhEHWN53rms0O7VsXBIms9tPFzRoRWVTmpZoRinHzTom_tG r.x6qhF1Ge5UvwN4Jq.Q7XX5xy_XdGcwg0NDyRLLX2Hu3TQjQV0BmrGUa2rknHoKvncXsNubvuxJ bQSmojkmfLjOZRG.grZxASt1qYtZLjxMTEKYE_cMLDSQ7.f7ygp5wx_bjadTS1TOvA81kdhQyH93 AJ_Po0__w5GvPGV3YVi41hdkJGtiwbsgc_Ywggae7jUK3gjF2KKBbTUT4DDVDy1qPksp4Nk2QfDY dmGCR9P2Xy.raBvldnnkY3Qu06QTeGdLEY8aUunJBJmnk8x8.VlxnLYq6kCdMK61CwxmAuKZqFes mbEVRm2abI5ch8RMT6VzHwnrYPFiypRWIE2weZ.3dbcj2O.uPIoUblIkYNnnoS58ObbpKvuCgg54 nGbURxnzJjzZjFC449dxUBg7usA8CnVyAXyu.aTNy2wTvLOq2gQ1U2rZCLGmCpKgpnIsRgB.u5eq LY4p.K87zzh60xThfuDcjn5KQrx4F9oqrSxjbT6hQJmTg8K2JlYlBvePy00j7h22t9hQBOUzE1lW iedTi65XtUgHd4PUqxnES_nYtUyQzyboiGLWzAgv9DsWJBNvunn4M6KtCnkpID.g8t715bQ4QWqI DzSSUJHdgJ.yCDh5zdb8XvO_JgDP3eIwncIQHek6E4JjDUsoYkN6Uy5cK9aQjnr6AYoXiyqcBz4G nNtSQdQ1J5JR5j7CgkYsy2f0ozG2SdlTHYigOk2HiVfBsvxnWQZchiGPBFQAyKOcNWZoftN7rNkb bhiHdL_S9e3UPlw6IvO8MvWZq_Ap7LPi6nwSdxRMAjNlbaK8oMMNWMKAaC6W9_WGGVsimxlQB5Qw 0Wk2jzppslQsI3WmR66YpfVwPdEerBF0uCjH4i04sEIggweimjCbNBt_jNrreJELtVjjQVJy8he4 Heyi94xLZfXaYQ2zWuwBMp17ML.Wqp3CDQwIG5ngxjnfjrn73cTcgWYLeJSEVuCuhmQDIHPGGAuH 6QGkwFl00lr4MYPBqfNAqpdEVcmS6TjwoPGTsZZ7kaqiP70J2iLqAmCpmTwcB4gpJ0OXRMK0TH34 Wp_tdDN3YHWpdisa8WXBAODdzbtdPsTQyXRzwA03e4NW7vmA9jYpppmP9DhTiRJGrfM22zRS5wGn Ouvwhq_pJI2u2f.8dNw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Mon, 27 Dec 2021 02:42:51 +0000 Received: by kubenode542.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 374e383100e6f67a61488114aa7bbd45; Mon, 27 Dec 2021 02:42:49 +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: Date: Sun, 26 Dec 2021 18:42:46 -0800 Cc: Free BSD Content-Transfer-Encoding: quoted-printable Message-Id: <3C4AFB1B-467D-455B-A1A7-2A77AC87E4D4@yahoo.com> 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: 4JMhmD5zqrz3LsP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=lZsonhR9; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 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.69.31: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(1.00)[0.998]; 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.69.31: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 On 2021-Dec-26, at 18:25, Mark Millard wrote: > On 2021-Dec-26, at 16:40, Mark Millard via freebsd-arm = wrote: >=20 >> 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. >=20 > I misremembered. Rock64's vs. RPi4B's: they behave differently > (booted with no microsd card media). >=20 > The Rock64 reports each insertion to and each removal from the > internal microsd card slot. For example: >=20 > 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 >=20 > But the RPi4B built-in slot handling reports nothing and gpart > show does not show the media (which has a FreeBSD installation > on each). >=20 >=20 > In addition, for a microsd card with: >=20 > =3D> 63 62333889 mmcsd1 MBR (30G) > 63 8129 - free - (4.0M) > 8192 62325760 1 fat32lba (30G) >=20 > 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: >=20 > # gpart show > =3D> 63 62333889 mmcsd0 MBR (30G) > 63 8129 - free - (4.0M) > 8192 62325760 1 fat32lba (30G) > . . . >=20 > Removal produces no messages, nor does insertion of > a 128 GiByte microsd card (that has a FreeBSD > installtion on it). And at this point: >=20 > # gpart show > =3D> 63 62333889 mmcsd0 MBR (30G) > 63 8129 - free - (4.0M) > 8192 62325760 1 fat32lba (30G) >=20 > 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). >=20 >=20 >>>> 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. >=20 > 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. >=20 >>> 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. >=20 I did a little Fedora testing for the USB3 reader handling: Plugging in the reader with no media reported the insertion reporting a bunch of information I'll not repeat here. Inserting the 128 GiByte microsd card reported: [674787.789768] sd 1:0:0:3: [sde] 249737216 512-byte logical blocks: = (128 GB/119 GiB) [674787.798729] sde: detected capacity change from 0 to 249737216 [674787.809873] sde: sde1 sde2 [674787.809873] sde2: Removal reported: [674796.646095] sde: detected capacity change from 249737216 to 0 Inserting the 32 GiByte microsd card reported: [674814.378393] sd 1:0:0:3: [sde] 62333952 512-byte logical blocks: = (31.9 GB/29.7 GiB) [674814.387473] sde: detected capacity change from 0 to 62333952 [674814.400235] sde: sde1 sde2 [674814.400235] sde2: Removal reported: [674816.959997] sde: detected capacity change from 62333952 to 0 So that such tracking does not happen on FreeBSD (when there there is no removal of the reader itself) seems to be FreeBSD specific. But inserting and removing microsd cards from the built-in slot reported nothing under Fedora. (It had been booted with nothing in the slot.) So this sort of thing for this type of context seems to not be FreeBSD specific. =3D=3D=3D Mark Millard marklmi at yahoo.com