Re: Hot-plugging microSD on Raspberry Pi under FreeBSD

On 2021-Dec-26, at 18:25, Mark Millard <marklmi@yahoo.com> wrote:

> 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.
> 

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: <bsd: sde5 (ignored 4 more) >

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: <bsd: sde5 >

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.


===
Mark Millard
marklmi at yahoo.com