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