Re: Hot-plugging microSD on Raspberry Pi under FreeBSD

From: Mark Millard via freebsd-arm <freebsd-arm_at_freebsd.org>
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