On Tue, Jul 14, 2015 at 11:49:29PM -0400, Tim Moody wrote:
> I think the bottom line is that on this xo1.5 I need to use a usb thumb
> drive instead of this micro sdcard and its holder.
>
> > -----Original Message-----
> > From: xsce-de...@googlegroups.com [mailto:xsce-
> > de...@googlegroups.com] On Behalf Of James Cameron
> > Sent: Tuesday, July 14, 2015 8:14 PM
> > To: Tim Moody
> > Cc: server-de...@lists.laptop.org; devel@lists.laptop.org; xsce-
> > de...@googlegroups.com
> > Subject: Re: [XSCE] sdcard for /opt and /library on xo 1.5
> >
> > G'day Tim,
> >
> > Thanks, that's interesting.
> >
> > My best guess is you have a bad connector and the 24-hour thermal test you
> > did fixed it. The problem may return.
> >
> > Another guess is that the card has the production state awareness feature
> > [1], part of e.MMC v5.0, which uses the storage cells differently before
> they
> > are enabled for normal use. The state can be changed with suitable tools,
> or
> > will clear itself once enough data is written; followed by a power cycle.
> The
> > result is a sudden increase in performance after that power cycle.
> >
> interesting ideas. I have no way of judging either.
>
> My guess is that I tried so many different ways of partitioning it from
> fdisk to parted that it was so messed up that an xo 1.5, a nuc, and a dell
> all found it corrupt, compounded by the fact that systemd has it in use even
> if it is not actually mounted.
Yes, it sounds like you lost track of the provenance.
At heart though, an SD card is just a set of blocks, so I always make
a copy of it before writing. The copy usually compresses really well
for permanent storage.
>
> The sdcard holder is also looking pretty suspect as used with the card slot
> on the xo. I put the micro sd in the holder back into the xo 1.5 and it
> reported two devices with pttype of "dos", but gave unknown file system when
> I tried to mount
>
> -bash-4.2# mount
> /dev/mmcblk1p1 on /bootpart type ext4 (rw,relatime,user_xattr,barrier=1)
> /dev/mmcblk1p2 on / type ext4 (rw,noatime,user_xattr,barrier=1,data=ordered)
> devtmpfs on /dev type devtmpfs
> (rw,nosuid,relatime,size=475460k,nr_inodes=118865,mode=755)
> /dev/mmcblk1p2 on /home type ext4
> (rw,relatime,user_xattr,barrier=1,data=ordered)
> /dev/mmcblk1p2 on /versions type ext4
> (rw,relatime,user_xattr,barrier=1,data=ordered)
> /dev/mmcblk1p1 on /security type ext4 (rw,relatime,user_xattr,barrier=1)
> proc on /proc type proc (rw,relatime)
> sysfs on /sys type sysfs (rw,relatime)
> tmpfs on /dev/shm type tmpfs (rw,relatime,size=51200k)
> devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
> tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
> tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
> cgroup on /sys/fs/cgroup/systemd type cgroup
> (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgro
> ups-agent,name=systemd)
> cgroup on /sys/fs/cgroup/cpu type cgroup
> (rw,nosuid,nodev,noexec,relatime,cpu)
> systemd-1 on /proc/sys/fs/binfmt_misc type autofs
> (rw,relatime,fd=27,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
> hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
> debugfs on /sys/kernel/debug type debugfs (rw,relatime)
> mqueue on /dev/mqueue type mqueue (rw,relatime)
> vartmp on /var/tmp type tmpfs (rw,relatime,size=51200k)
> /tmp on /tmp type tmpfs (rw,relatime,size=204800k)
> none on /var/lib/stateless/writable type tmpfs
> (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/cache/man type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/lib/xkb type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/cache/httpd/ssl type tmpfs
> (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/cache/httpd/proxy type tmpfs
> (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/cache/php-pear type tmpfs
> (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/lib/dav type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/lib/dhclient type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> none on /etc/adjtime type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/lib/logrotate.status type tmpfs
> (rw,relatime,size=4096k,nr_inodes=2048)
> none on /var/spool type tmpfs (rw,relatime,size=4096k,nr_inodes=2048)
> /dev/mmcblk1p1 on /etc/ssh type ext4 (rw,relatime,user_xattr,barrier=1)
> /dev/mmcblk1p1 on /var/lib/dbus type ext4 (rw,relatime,user_xattr,barrier=1)
> /dev/mmcblk1p1 on /var/lib/random-seed type ext4
> (rw,relatime,user_xattr,barrier=1)
> /dev/mmcblk1p1 on /etc/NetworkManager/system-connections type ext4
> (rw,relatime,user_xattr,barrier=1)
> /dev/sda2 on /library type ext4
> (rw,noatime,user_xattr,barrier=1,data=ordered)
> /dev/sda1 on /opt type ext4 (rw,noatime,user_xattr,barrier=1,data=ordered)
> (sda is a usb thumbdrive)
>
> -bash-4.2# blkid
> /dev/sda1: UUID="20d7ab6c-ec76-4fc3-a702-75c0051b5ce6" TYPE="ext4"
> /dev/sda2: UUID="e1c0ef6a-dc89-4d46-bcef-7b19360d41f7" TYPE="ext4"
> /dev/mmcblk0p1: UUID="de889f2b-fffb-4a45-8358-dce449f2cf7e" TYPE="ext4"
> /dev/mmcblk0p2: UUID="0ad6a5ee-bc3d-4fc6-8b9b-ca9bc456cb74" TYPE="ext4"
> /dev/mmcblk1p1: LABEL="Boot" UUID="ac3c6c0f-8350-47ab-a308-42d49652f030"
> TYPE="ext2"
> /dev/mmcblk1p2: LABEL="OLPCRoot" UUID="61a34c92-0f69-409d-9b61-23a5522d296d"
> TYPE="ext4"
> /dev/mmcblk0: PTTYPE="dos"
> /dev/mmcblk1: PTTYPE="dos"
>
> -bash-4.2# mkdir /mnt/sdcard
> -bash-4.2# mount /dev/mmcblk0 /mnt/sdcard
> mount: unknown filesystem type '(null)'
Expected. You should have been trying /dev/mmcblk0p1 or p2. Without
p1 or p2 it is the overall device, usually not a partition.
>
> But when I put the micro sdcard into my usb adapter and plugged that into
> the xo 1.5 I see
>
> -bash-4.2# ll /dev/sde*
> brw-rw---- 1 root disk 8, 64 Jul 15 2015 /dev/sde
> brw-rw---- 1 root disk 8, 65 Jul 15 2015 /dev/sde1
> brw-rw---- 1 root disk 8, 66 Jul 15 2015 /dev/sde2
>
> and /dev/sde1 automounted on /media/usb0
Ok.
>
> I tried another holder from nexxtech and got the same result as the sandisk
> one.
>
> > Suggestions:
> >
> > - next time you want to erase a card, send it the erase command, which
> > takes between three and fifteen seconds in my tests [2],
>
> you mentioned erase before, but I couldn't find it. the googling I did only
> mentioned using dd to erase.
>
> [root@schoolserver zims]# which erase
> /usr/bin/which: no erase in
> (/usr/local/sbin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/u
> sr/bin:/root/bin)
The link supplied in [2] was for Open Firmware, and I've not studied
how to do the same in Linux. It would be really annoying to do it by
accident.
> >
> > - test the communications between the system and the card by measuring
> > the sequential read performance; this is usually the easiest way to
> > test communications,
>
> not sure I had anything to read as I never had a file system.
The card is an array of blocks, so you can always read them;
su
sync
echo 1 > /proc/sys/vm/drop_caches
dd if=/dev/mmcblk0 of=/dev/null bs=1M count=256
A data rate will be printed by dd. That will give you a performance
measurement that is never more than the actual performance, and
occasionally less.
> > - try on a different XO-1.5, in case you have a faulty XO-1.5, and
> > raise doubts if the performance differs,
>
> only have the one
> >
> > - try on a modern desktop system; that will isolate the problem to
> > interoperability with the XO-1.5,
>
> even I thought of this. in fact I saw differences between fedora 22 (my
> NUC) and fedora 20 (my old Dell). It was fedora 20 on which I did anything
> useful including the zeroing. I guess the subject line of my email is
> misleading in this regard.
> >
> > - identify the kernel, in case you have a version that doesn't
> > properly switch to 1.8V; if so, the slot on the XO-1.5 will run it
> > at 3.3V, warm, and so the card firmware will intentionally slow the
> > transfers to ensure compliance with thermal specifications,
> >
> > - try reseating the card in the adapter, and the adapter in the
> > system, because a bad connection can show up as slow data rate, then
> > re-test the communications,
>
> this is a possible factor in that I used a usb adapter for the micro sd more
> successfully than the holder
Also by using USB adapter you are offloading some of the
communications work to a processor in the adapter.
The electrics of the adapter might also be a better match.
> >
> > - if available, use uninit_bg when calling mke2fs, so that the
> > "formatting" doesn't have to write much,
> >
> > - publish the dmesg fragment showing the card being detected.
> >
> > When thinking about problems with SD card, it is best to imagine it as a
> > separate computer, in which you can't change the software. There's no
> > telling what it will do. ;-) They are very complex systems, made to look
> > simple. Plug and play, dumbing down.
>
> and apparently the home of a new class of virus, undetectable due to the
> fact that the os is stored in write-only memory.
Yes, and also undetectable because it isn't in the data area of the card.
> >
> > +CC devel@ for general XO-1.5 and SD card interest.
> >
> > References:
> >
> > 1.
> > https://www.jedec.org/news/pressreleases/jedec-announces-publication-
> > emmc-standard-update-v50
> >
> > 2.
> > http://wiki.laptop.org/go/Firmware/Storage#How_to_quickly_erase_everyt
> > hing
> > (but use http://wiki.laptop.org/go/Firmware/Storage#devalias_fsdisk
> > first)
> >
> > On Tue, Jul 14, 2015 at 06:34:52PM -0400, Tim Moody wrote:
> > > I have been around the block with a 128G micro sdcard allegedly from
> > > Sandisk. I made various attempts at creating two partitions and
> > > formatting them ext4, some of which progressed at the rate of
> > > 10G/hour.
> > >
> > > I finally used dd to write /dev/zero to the entire device, which took
> > > almost 24 hours.
> > >
> > > After that parted mklabel msdos and mkpart worked fine and mkfs.ext4
> > > also worked fine in a couple of minutes.
> > >
> >
> > --
> > James Cameron
> > http://quozl.linux.org.au/
--
James Cameron
http://quozl.linux.org.au/
_______________________________________________
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
