I recently bought this particular SD Card from Amazon:
I get some very weird and super slow writes, as around 100KB/s writes, and depending on whether or not I have done a write, I get speeds from 20MB/s to as low as 500KB/s. I was looking up as to why, and discovered about implementation details that may explain the performance issues, such as erasure and how pages are pooled together, but honestly I have some extreme doubts here.
Rasberry Pi Imager (RPI) fails its verification after finishing but BalenaEtcher fails immediately and I’m not sure whether that is because it tries to read back after writing blocks of data to the SD Card. I’m wondering if I can safely just say that this SD Card is essentially DoA or even fraudulent, despite it being shipped from Amazon LLC and sold by SanDisk themselves…
Mind the pixelated image; had to use Peek, but then had to use an online GIF editor since it pops up my real name in the permissions menu when asking for root access.
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:1c.0/0000:53:00.0/mmc_host/mmc0/mmc0:aaaa/block/mmcblk0':
KERNEL=="mmcblk0"
SUBSYSTEM=="block"
DRIVER==""
ATTR{ro}=="0"
ATTR{capability}=="50"
ATTR{ext_range}=="256"
ATTR{removable}=="0"
ATTR{discard_alignment}=="0"
ATTR{force_ro}=="0"
ATTR{events_poll_msecs}=="-1"
ATTR{size}=="1999749120"
ATTR{alignment_offset}=="0"
ATTR{events}==""
ATTR{inflight}==" 0 0"
ATTR{stat}==" 1243 1592 202794 13461 38218 5088 31225008 72555265 0 175236 72491444 0 0 0 0"
ATTR{range}=="8"
ATTR{events_async}==""
ATTR{hidden}=="0"
looking at parent device '/devices/pci0000:00/0000:00:1c.0/0000:53:00.0/mmc_host/mmc0/mmc0:aaaa':
KERNELS=="mmc0:aaaa"
SUBSYSTEMS=="mmc"
DRIVERS=="mmcblk"
ATTRS{date}=="04/2021"
ATTRS{erase_size}=="512"
ATTRS{manfid}=="0x000003"
ATTRS{ocr}=="0x00200000"
ATTRS{hwrev}=="0x8"
ATTRS{dsr}=="0x404"
ATTRS{scr}=="0245848700000000"
ATTRS{name}=="SN01T"
ATTRS{type}=="SD"
ATTRS{csd}=="400e0032db79001dcc6f7f800a404000"
ATTRS{fwrev}=="0x0"
ATTRS{rca}=="0xaaaa"
ATTRS{oemid}=="0x5344"
ATTRS{ssr}=="0000000008000000040090000f05391e000800000002fc0003000000000000000000000000000000000000000000000000000000000000000000000000000000"
ATTRS{cid}=="035344534e303154804677dd9c015400"
ATTRS{serial}=="0x4677dd9c"
ATTRS{preferred_erase_size}=="4194304"
looking at parent device '/devices/pci0000:00/0000:00:1c.0/0000:53:00.0/mmc_host/mmc0':
KERNELS=="mmc0"
SUBSYSTEMS=="mmc_host"
DRIVERS==""
looking at parent device '/devices/pci0000:00/0000:00:1c.0/0000:53:00.0':
KERNELS=="0000:53:00.0"
SUBSYSTEMS=="pci"
DRIVERS=="sdhci-pci"
ATTRS{dma_mask_bits}=="64"
ATTRS{max_link_width}=="1"
ATTRS{vendor}=="0x17a0"
ATTRS{numa_node}=="-1"
ATTRS{ari_enabled}=="0"
ATTRS{irq}=="150"
ATTRS{local_cpus}=="ffff"
ATTRS{msi_bus}=="1"
ATTRS{subsystem_vendor}=="0x17aa"
ATTRS{current_link_width}=="1"
ATTRS{local_cpulist}=="0-15"
ATTRS{driver_override}=="(null)"
ATTRS{broken_parity_status}=="0"
ATTRS{enable}=="1"
ATTRS{class}=="0x080501"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{max_link_speed}=="5 GT/s"
ATTRS{subsystem_device}=="0x229f"
ATTRS{revision}=="0x00"
ATTRS{d3cold_allowed}=="1"
ATTRS{device}=="0x9755"
ATTRS{current_link_speed}=="5 GT/s"
looking at parent device '/devices/pci0000:00/0000:00:1c.0':
KERNELS=="0000:00:1c.0"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport"
ATTRS{aer_rootport_total_err_cor}=="0"
ATTRS{local_cpulist}=="0-15"
ATTRS{revision}=="0xf0"
ATTRS{current_link_speed}=="5 GT/s"
ATTRS{subsystem_device}=="0x229f"
ATTRS{d3cold_allowed}=="1"
ATTRS{subsystem_vendor}=="0x17aa"
ATTRS{msi_bus}=="1"
ATTRS{aer_rootport_total_err_fatal}=="0"
ATTRS{vendor}=="0x8086"
ATTRS{aer_rootport_total_err_nonfatal}=="0"
ATTRS{current_link_width}=="1"
ATTRS{subordinate_bus_number}=="83"
ATTRS{driver_override}=="(null)"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{device}=="0xa338"
ATTRS{enable}=="1"
ATTRS{class}=="0x060400"
ATTRS{broken_parity_status}=="0"
ATTRS{max_link_width}=="1"
ATTRS{irq}=="125"
ATTRS{max_link_speed}=="8 GT/s"
ATTRS{dma_mask_bits}=="32"
ATTRS{local_cpus}=="ffff"
ATTRS{ari_enabled}=="0"
ATTRS{numa_node}=="-1"
ATTRS{secondary_bus_number}=="83"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
So ATTRS{oemid}=="0x5344" and ATTRS{manfid}=="0x000003" so it appears to be a SanDisk SD Card.
Strangely, I ran dd if=/dev/zero of=dummy.txt count=$((2 * 1024 * 1024 * 1024 / 512)) and it completed pretty quickly at 371 MB/s, far faster than what I saw last night. 2nd time I got 70MB/s. Now it is hanging on deleting the file… I wonder if it really is just the page pool implementation detail I read about earlier
Edit: Decided to write file with /dev/urandom and get ridiculously slow speed!
Only the last sector is being seen as damaged; chkdsk /f /r /x does not find any actual bad sectors though so I am not certain whether or not this is a false positive or not.
I managed to flash everything using Raspberry Pi Imager (RPI) this time around on Windows 10, so likely has to do with the open source drivers; also write speeds are far better now, too, and no verification errors.
This is an odd one, and I am not totally sure what is going on, but mostly I’m just glad to hear that you were able to make use of the SD Card, since it’s obviously a high quality and expensive one. If RPI did the trick, then so be it, as long as you got the card functioning. I’ll watch the forums to see if we get additional reports of that same SD Card, perhaps there is something unique about them due to their capacity.
