Re: Hot-plugging microSD on Raspberry Pi under FreeBSD
Date: Mon, 27 Dec 2021 02:25:26 UTC
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:
>
>> 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:
>>>
>>>>
>>>> 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?
>>>
>>> As I remember, for FreeBSD,
>>>
>>> A) The built-in microsd card slot works fine for swapping
>>> media that are not mounted at the time.
>>
>> Ok, that's reassuring. I observed corruption of microSD card FAT
>> partitionss and wondered if hot-plugging might be the cause.
>
> 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:
=> 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
=> 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
=> 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),
>>>
>>> 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).
>>>
>>> Result:
>>>
>>> (da4:umass-sim1:1:0:3): READ(10). CDB: 28 00 0e e2 af ff 00 00 01 00
>>
>> [...disk errors snipped....]
>>
>> Was the Pi4 running from a USB hard disk?
>
> 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
>> from a USB hard disk seems to disrupt communication with the boot drive.
>
> You have described having a marginal/insufficient
> power context in other messages.
>
>> It doesn't crash immediately but can't be gracefully rebooted.
>>
>>> 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".
>>
>> 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.
>
> I disconnect the reader, swap media, and reconnect. That
> handles things fine.
>
>>> 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.
>>>
>>> So I unplug the whole reader to swap media. This is messier
>>> if multiple slots are in use (more unmounts and later
>>> remounts).
>>
>> That chain of events crashes my RasPiOS Pi4, at least when it's also
>> booted from a USB drive.
>>
>
> You have described having a marginal/insufficient
> power context in other messages.
===
Mark Millard
marklmi at yahoo.com