Date: Sun, 26 Dec 2021 18:25:26 -0800 From: Mark Millard via freebsd-arm <freebsd-arm@freebsd.org> To: bob prohaska <fbsd@www.zefox.net> Cc: Free BSD <freebsd-arm@freebsd.org> Subject: Re: Hot-plugging microSD on Raspberry Pi under FreeBSD Message-ID: <A1B8FCD1-B3CA-47CC-AC3D-A1D2B66EEE0F@yahoo.com> In-Reply-To: <1D17056C-AA76-4CF8-8A2C-C2908242AAFE@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Dec-26, at 16:40, Mark Millard via freebsd-arm =
<freebsd-arm@freebsd.org> wrote:
> On 2021-Dec-26, at 14:47, bob prohaska <fbsd@www.zefox.net> 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 <fbsd@www.zefox.net> 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: <MMC/SD bus> on rockchip_dwmmc0
mmcsd1: 128GB <SDHC SN128 8.0 SN 88508225 MFG 01/2020 by 3 SD> at mmc1 =
50.0MHz/4bit/1016-block
mmc1: detached
mmc1: <MMC/SD bus> on rockchip_dwmmc0
mmcsd1: 32GB <SDHC SE32G 8.0 SN 80FBA7D2 MFG 07/2017 by 3 SD> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A1B8FCD1-B3CA-47CC-AC3D-A1D2B66EEE0F>