[PLUG] Weird microSD failure

Russell Senior russell at personaltelco.net
Tue May 1 21:42:12 UTC 2018


Followup on this, I noticed it again last night on multiple USB
thumbdrives.  A dd to the device immediately succeeds (which is weird in
itself for large writes of iso sized blobs), but unplugging-replugging
shows the writes didn't actually happen. The problem was persistent until I
rebooted the machine and it started working normally again. Very weird. I
think the microSD was probably fine and the hosage was at the USB or
something other than the hardware level. It might be related to unplugging
a mounted device at some point. Any ideas are welcome.

On Tue, Mar 6, 2018 at 8:29 PM, Russell Senior <russell at personaltelco.net>
wrote:

> https://www.youtube.com/watch?v=r3GDPwIuRKI
>
> On Tue, Mar 6, 2018 at 8:22 PM, Russell Senior
> <russell at personaltelco.net> wrote:
> > Yeah, I understood about the on-SD controller.  There is typically
> > some kind of ARM-based microcontroller that does all the block-device
> > to NAND translation.  It is doing something wrong and clearly
> > dysfunctional now, though.  I am sure that I did successful block
> > operations on the same microSD previously.
> >
> > On Tue, Mar 6, 2018 at 5:31 PM, Tomas Kuchta
> > <tomas.kuchta.lists at gmail.com> wrote:
> >> When I said card controller, I meant the card controller on/in the
> actual
> >> SD card. Not the piece of HW attached to your computer.
> >>
> >> My conclusion at the time I was trying to understand the same behavior
> was
> >> that the in-card controller must be doing file transactions of some
> kind.
> >> Not behaving quite like basic block device.
> >>
> >> I recall even trying to actively corrupt the card's content, no success.
> >> Still, all worked fine when installing Linux on said cards.
> >>
> >> Hope it helps you avoiding wasting whole day or three on this, like I
> did.
> >>
> >> Tomas
> >>
> >> On Mar 7, 2018 9:23 AM, tomas.kuchta.lists at gmail.com wrote:
> >>
> >>> I do not believe that SD cards respond to pure raw block writes from
> dd.
> >>> Not unless the stream looks like files.
> >>>
> >>> I run into the same discovery some time ago. If I remember correctly,
> dd
> >>> didn't overwrite the content even with random data. It could behave
> >>> different for different firmware, but I tried a few with the same
> result.
> >>>
> >>> Tomas
> >>>
> >>> On Mar 7, 2018 9:13 AM, "wes" <plug at the-wes.com> wrote:
> >>>
> >>> that's only if you want to generate a certain size. otherwise it just
> keeps
> >>> going until it runs out of blocks to fill.
> >>>
> >>> -wes
> >>>
> >>> On Tue, Mar 6, 2018 at 5:08 PM, Tim Garton <garton.tim at gmail.com>
> wrote:
> >>>
> >>> > Don't you need a "count=#" option to dd as well? Not at a computer
> right
> >>> > now otherwise I'd be able to check if that's the case...
> >>> >
> >>> > On Mar 6, 2018 5:02 PM, "Richard England" <rlengland at frontier.com>
> >>> wrote:
> >>> >
> >>> > > On 03/06/2018 04:20 PM, Tomas Kuchta wrote:
> >>> > >
> >>> > >> Try to delete the original files first. Then create empty file
> using
> >>> > >> /dev/zero and copy it to the card. I bet that it will be there on
> the
> >>> > card
> >>> > >> and some of your original data will disappear as result.
> >>> > >>
> >>> > >> My guess is that the card controller is deduplicating your
> /dev/zero
> >>> > >> blocks
> >>> > >> trying to protect the card from writes.
> >>> > >>
> >>> > >> Tomas
> >>> > >>
> >>> > >> On Mar 6, 2018 7:09 PM, "Russell Senior" <
> russell at personaltelco.net>
> >>> > >> wrote:
> >>> > >>
> >>> > >> On Tue, Mar 6, 2018 at 3:04 AM, Russell Senior
> >>> > >>> <russell at personaltelco.net> wrote:
> >>> > >>>
> >>> > >>>> On Tue, Mar 6, 2018 at 3:01 AM, Jim Karlock <
> jjkarlock at gmail.com>
> >>> > >>>> wrote:
> >>> > >>>>
> >>> > >>>>> My initial attempt to google this was unsuccessful (most people
> >>> point
> >>> > >>>>>> out the write protect tab, not my problem).
> >>> > >>>>>>
> >>> > >>>>>
> >>> > >>>>> Bad switch on the write protect tab? (The tab operates a tiny
> >>> > switch.)
> >>> > >>>>>
> >>> > >>>> Nope.
> >>> > >>>>
> >>> > >>>> I can turn the switch to lock and it mounts the device read only
> >>> very
> >>> > >>>> clearly.  The behavior I observe is that it happily writes
> /dev/zero
> >>> > >>>> over the block device, but then when I read again, the old data
> is
> >>> > >>>> still present.
> >>> > >>>>
> >>> > >>> For example, if I flip the tab to write protect tab to "Lock", I
> get
> >>> > >>> this:
> >>> > >>>
> >>> > >>> # dd if=/dev/zero of=/dev/sdc status=progress bs=1M
> >>> > >>> dd: failed to open '/dev/sdc': Read-only file system
> >>> > >>> _______________________________________________
> >>> > >>> PLUG mailing list
> >>> > >>> PLUG at pdxlinux.org
> >>> > >>> http://lists.pdxlinux.org/mailman/listinfo/plug
> >>> > >>>
> >>> > >>> _______________________________________________
> >>> > >> PLUG mailing list
> >>> > >> PLUG at pdxlinux.org
> >>> > >> http://lists.pdxlinux.org/mailman/listinfo/plug
> >>> > >>
> >>> > >
> >>> > > |Perhaps using dd if=/dev/urandom |of=/dev/sdc status=progress
> bs=1M
> >>> > > ...just a thought.
> >>> > >
> >>> > > _______________________________________________
> >>> > > PLUG mailing list
> >>> > > PLUG at pdxlinux.org
> >>> > > http://lists.pdxlinux.org/mailman/listinfo/plug
> >>> > >
> >>> > _______________________________________________
> >>> > PLUG mailing list
> >>> > PLUG at pdxlinux.org
> >>> > http://lists.pdxlinux.org/mailman/listinfo/plug
> >>> >
> >>> _______________________________________________
> >>> PLUG mailing list
> >>> PLUG at pdxlinux.org
> >>> http://lists.pdxlinux.org/mailman/listinfo/plug
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> PLUG mailing list
> >> PLUG at pdxlinux.org
> >> http://lists.pdxlinux.org/mailman/listinfo/plug
>



More information about the PLUG mailing list