Failing SD Card

Hi,

I would like to know if anyone here have encountered the following errors in your sd card?.

Thanks,

john

EXT3-fs error (device mmcblk0p1): ext3_free_blocks: Freeing blocks in system zones - Block = 256, count = 1
Aborting journal on device mmcblk0p1.
ext3_free_blocks_sb: aborting transaction: Journal has aborted in __ext3_journal_get_undo_access<2>EXT3-fs error (device mmcblk0p1) in ext3_free_blocks_sb: Journal has aborted
ext3_free_blocks_sb: aborting transaction: Journal has aborted in __ext3_journal_get_undo_access<2>EXT3-fs error (device mmcblk0p1) in ext3_free_blocks_sb: Journal has aborted
ext3_reserve_inode_write: aborting transaction: Journal has aborted in __ext3_journal_get_write_access<2>EXT3-fs error (device mmcblk0p1) in ext3_reserve_inode_write: Journal has aborted
EXT3-fs error (device mmcblk0p1) in ext3_truncate: Journal has aborted
ext3_reserve_inode_write: aborting transaction: Journal has aborted in __ext3_journal_get_write_access<2>EXT3-fs error (device mmcblk0p1) in ext3_reserve_inode_write: Journal has aborted
EXT3-fs error (device mmcblk0p1) in ext3_orphan_del: Journal has aborted
ext3_reserve_inode_write: aborting transaction: Journal has aborted in __ext3_journal_get_write_access<2>ext3_abort called.
EXT3-fs error (device mmcblk0p1): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only
EXT3-fs error (device mmcblk0p1) in ext3_reserve_inode_write: Journal has aborted
EXT3-fs error (device mmcblk0p1) in ext3_delete_inode: Journal has aborted
__journal_remove_journal_head: freeing b_committed_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_committed_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_committed_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_frozen_data
__journal_remove_journal_head: freeing b_committed_data
__journal_remove_journal_head: freeing b_frozen_data

Smells of corruption.

Unmount it and run "e2fsck -f /dev/<your device node>" and see what is reported.

I was trying to understand what are the causes of the problem. My system is using the sd card to write and delete data (.jpeg, video) (24/7), it maintain a couple of blocks up to 1GB of free space. Then, suddenly it reported the said errors and now it reported “sdf: unknown partition table”.

Could you guys give me some expert advise regarding with the said issue?.

Thanks,

john

SD cards have a limited number of write cycles (I heard 100,000 write
cycles) before they wear out. When you say you're recording video 24/7,
how many cycles would that be?

Thank you for the discussion. Are there any online resources for SD card performance, writes longevity, MTBF, & what are Class ratings about? It appears the B-B is somewhat sensitive to SD Cards. Here’s the Wikipedia SD Card page…
http://en.wikipedia.org/wiki/Sd_card

I’ve seeing different SD Card issues in the list. Are there any emerging patterns? If so then it should be possible to devise a diagnostic procedure that you can publish. That might help users DIY & reduce the repeating the same responses.

I’m having read problems of an original from the box B-B xM S/N: 0111xM400. The SD Card will not read in either of my laptops. I understand there is a FAT partition on it.

Arnd Bergmann wrote a good article on LWN:
https://lwn.net/Articles/428584/

Linaro wiki page:
https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey

Steve Sakoman's article:
http://www.sakoman.com/OMAP/microsd-card-perfomance-test-results.html

Class ratings are generally useless for embedded Linux use. They're a
decent reference point if you're buying for use in a digital camera /
camcorder, but if you're doing small writes (less than 1 MB in size),
they don't mean much. A better metric is number of simultaneous open
erase blocks (1 is horrible, 5 is OK, more is ideal), but that's never
printed on the packaging (or in the marketing material).

Partition alignment to the underlying flash also can matter. Using the
alignment provided with 255 heads and 63 sectors almost certainly won't
align to the underlying flash.

-Andrew

Andrew,

Thanks, this is the kind of depth I was looking to find. It is a start. I’m looking for Windows tools to inspect the SD card. It does not show when plugged into the SD slot. I’ve tried two laptops. I have a way to try a third and to try another SD card.

You would think however the OS would indicate a the card was at least in the reader even if it is not formatted correctly. Oh wait it’s Windows, I remember HDs not being recognized until at least one partition was created.

I wonder if anything was ever placed on this SD Card. It was packed in the B-B xM box when it arrived.

Cheers
John S Wolter

The card that ships with the board has a small FAT parttion and an EXT3 partition on it. It boots form FAT and runs the kernel using the EXT3 parttion.

Gerald

I'm not sure how low-level it can go, but TestDisk is an excellent
tool for diagnosing and repairing/recovering disks:
http://www.cgsecurity.org/wiki/TestDisk
It has a Windows version, so it's worth a shot. It's a command-line
interface, but it's fairly straightforward.

Joel

I haven't seen it mentioned in your previous threads... Have you tried
a linux live cd, just to verify that card is okay?

Regards,

Nope, no FAT showing except my belt line.

Sorry, I'm not familiar with Windows tools of this kind.

I'd recommend Joel or Robert's suggestions of TestDisk or using a Linux
live cd. The Linux live cd approach (with a recent Ubuntu, for example)
should auto-mount the SD card when inserted, showing you all the
partitions that are formatted. fdisk could also be used to inspect the
partition table.

-Andrew

Also, Bunnie (Andrew Huang) just wrote a blog post, with a focus more on
MTBF type testing:

http://www.bunniestudios.com/blog/?p=2297

Worth reading.
-Andrew

Andrew,

The blog seemed informed. I was particularly interested to see the remarks are purchasing. The purchase size and expected negotiating leverage you may or may not have.

Is Mr. Haung located in Taiwan or PRC? One does not want to create issues for people in my replys.

Cheers
John S Wolter

The blog seemed informed. I was particularly interested to see the
remarks are purchasing. The purchase size and expected negotiating
leverage you may or may not have.

Bunnie created the Chumby [1] and NeTV [2].
[1]: http://www.chumby.com/
[2]: What is NeTV - Chumby Wiki

There's quite a lot of experience with SD cards and embedded systems there.

Is Mr. Haung located in Taiwan or PRC?

I don't know, sorry.

-Andrew

I don’t know either, but Singapore seems most likely.

Hey Guys,

Is there any group or entity who conducted a research of the following for the sd card solutions?.
1.1. SD card wear leveling
1.2. Corruption of data
1.3. Early end-of-life
1.4. Other possible cause of sd card failure (Heat or Temperature, lost of power, uncleaned shutdown).
1.5. Writing multiple files at the same time.
1.6. What are the recommendations in order to avoid the problems?.

Thanks,

john

See the prior postings to this thread to find shared links.

I reinstalled the SD Card driver & it worked immediately. Next I’ll test Windows ext3 driver, seeing if it works.

Cheers,
John S Wolter

John Tobias wrote:

Hey Guys,

Is there any group or entity who conducted a research of the following for the sd card solutions?.
    1.1. SD card wear leveling
    1.2. Corruption of data
    1.3. Early end-of-life
    1.4. Other possible cause of sd card failure (Heat or Temperature, lost of power, uncleaned shutdown).
    1.5. Writing multiple files at the same time.
    1.6. What are the recommendations in order to avoid the problems?.

Even if you did a large study across all the SD cards you
can buy today, most of it would not apply in 6 month as
manufacturers are constantly changing and updating sd card
controllers, firmware and the raw NAND chips inside SD cards.

If you are really after reliability, there are "industrial"
grade SD cards available where the manufacturer might
guarantee some card properties.

John Tobias wrote:

Hey Guys,

Is there any group or entity who conducted a research of the following for the sd card solutions?.
   1.1. SD card wear leveling
   1.2. Corruption of data
   1.3. Early end-of-life
   1.4. Other possible cause of sd card failure (Heat or Temperature, lost of power, uncleaned shutdown).

There is one important possibility to take into account: the card reader.

I have e.g. a Transcend 8 GB Class 10 card that can't be correctly written on
* eeePC 701 internal reader with Debian Squeeze
* some old external card reader with USB 1 & 2
* a brand new Transcend (!) external SDHC/SDXC card reader with USB 2 & 3

It works perfectly when connected to an OMAP3 CPU. And I can
write it perfectly on the SD reader built into an UMTS/USB stick.
Finally, I was able to write the card on the eeePC with the original
Xandros system.

The symptoms are that you create/mount a file system and write data.
No errors are reported. But when reading back, some random sectors
of the card show bad data. I.e. the kernel may not boot because it
has a CRC error. But correct file size and date. Well, the MD5 sum
does not match any more.

fsck usually does not find these errors (because they rarely damages
the file system structures).

The only way to find out is running the badblocks tool.
If you get a static bad blocks pattern, your card is broken.
If you get a random bad blocks pattern, your reader is broken.

So it is *not* necessarily the card if you have problems on your Beagle.