SD Memory cards that we have tested

[mw]

I have been having intermittent troubles with an Integral Ultima Pro 4GB SDHC card. I was hoping that someone can point me towards anything that might help me to resolve the problem.

Two or three times now, the system would suddenly develop a spate of errors reading the card. This after a period of some months of trouble free operation.
Reformatting the card and reloading the system has cured matters in the past, but clearly this is not effective in the longer term.

The console messages look like this:

mmcblk0: error -110 sending read/write command, response 0x400d00, card status 0x400d00

I have noted many posts with this characteristic signature. Clearly I am not alone. I don't know how to interpret the message.
Once it starts, that's it ! Matters deteriorate rapidly, even after the disk volume itself is fsck'd.

I did wonder whether there might be a problem with how the basic boot partition is laid out. I may have inadvertently mucked it up.
Or perhaps some sectors need to be marked as "bad", somehow.

Any pointers would be very welcome.

The partition table looks like this:

fdisk's "p" option:
 /dev/mmcblk0: 4093 MB, 4093640704 bytes
255 heads, 63 sectors/track, 497 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x5f13c976

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1               1           8       64228+   6  FAT16
/dev/mmcblk0p2               9         497     3927892+  83  Linux

fdisk's "expert p" option:
Disk /dev/mmcblk0: 255 heads, 63 sectors, 497 cylinders

Nr AF  Hd Sec  Cyl  Hd Sec  Cyl     Start      Size ID
 1 00   1   1    0 254  63    7         63     128457 06
 2 00   0   1    8 254  63  496     128520    7855785 83
 3 00   0   0    0   0   0    0          0          0 00
 4 00   0   0    0   0   0    0          0          0 00

For what it's worth, these are the card details recorded in the kernel:

cid:    1b534d303030303010b1c822e7009600
csd:    400e00325b5900001e7f7f800a400000
date:   06/2009
fwrev:  0x0
hwrev:  0x1
manfid: 0x00001b
name:   00000
oemid:  0x534d
scr:    0235000000000000
serial: 0xb1c822e7

(Extracted from files in /sys/class/mmc_host/mmc0/mmc0:0002)

[NewIT_Marcus]

We see the same errors after a mounted card is inadvertently removed from a Sheevaplug. I haven't noticed subsequent deterioration.

[mw]

Thanks. It is possible that the card may be simply "unseating" itself a little over time, and that I have become a victim. I rarely touch it.

I have discovered the "badblocks" component of e2fsck, I'll put that to use and see if it comes up with anything.

[mw]

The badblocks command reports a continuous stream of bad blocks on the second partition, starting at 1,688,832.
About 45% of the way through the drive, I think.
My guess is that my "spate of errors" starts up as soon as linux decides to reach that far into the disk.

I am thinking that: either I have managed to muck up the geometry, or I have been sold a pup.

Does any one have an idea on how one might determine what a correct geometry should be ?

[Percival P Plugsley]

 

Hooray - fixed the problem with reading SD cards.

To be honest, I'd just given up after all these months but a melted PSU gave me the incentive to open the case only to discover that the metal roof (probably not the right term but obvious if you see it) of the SD card reader was sticking up at about 20 degrees. Pushed it back down after replacing the power circuit and lo and behold, the card is read first time.

I am  but 

[d_strigaro]

I bought a Kodak sdhc class 4 8gb and i had some problems with it (error -110)

Yesterday i bought a Sandisk extreme class 10 8gb 30mb/s and it seems to work fine...

[aleandro]

hello there,

I'm managing a weather station since dec 2010 by a sheevaplug and I bought  2 Lexar SDHC Multi-use 4GB. I noticed after some energy blackouts that the first card (mounting Debian) had a lot of errors and there was no way to recover the filesystem. I reinstalled the OS by dd using an image and I was able to fix the problems for a few months. One day I was not able to connect by ssh and extracting the SD card from the slot I tried to see if it had some problem. The filesystem was completely damaged and not recoverable. I formatted it using gparted and put the OS in it again using dd. After this operation and in a few days the card was not responding any more. Gparted said exactly the I/O errors you are reporting here. Not convinced I used the other remaining SD card (Lexar). I wrote the original image to it (cause I had saved  all configurations in it and the Noaa archive too). After only a month the card was unusable with I/O errors like before and this time I lost everything.

Friends of mine report that they use other sd-card models with success since 2 years without having problems of any sort (even clean filesystems)
My advice is yet not to buy Lexar if you manage a sheeva.

It would be interesting to hear someone having same troubles with that model of card. In the meanwhile I'm used to save my noaa archives to a USB stick.

I'm wondering if the problems reported are due to SD hardware or to a wrong writing of dd.

 

[mw]

I'm wondering if the problems reported are due to SD hardware or to a wrong writing of dd.

I have tentatively formed a conclusion that the Linux MMC driver does not recover from this card error very gracefully. Such that, once the error starts, Linux is unable to read from any part of any partition of the card, whether that part/partition be damaged or undamaged. As my Linux is on the card, the system simply dies. I junked the card.

My current 'Transcend 8GB SDHC Class 10 Memory Card' seems to be behaving itself, and the package it came in (now lost) indicated a manufacturer's life time guarantee.

I have also arranged matters to limit the frequency at which data is written to the card. System logging can be very heavy if not constrained. The 'flashybrid' system (debian package available) or some similar ramdisk based approach might be helpful here.

And I back up each raw partition at appropriate intervals onto the mother ship, so that the system can be easily reinstalled should that ever become necessary.

[aleandro]

Hi, here another card. Six month duration without troubles then suddenly dead. This time the junked card had a missing partition with all important data.

Testdisk was unable to recover something.

Bad, very bad.

[NewIT_James]

Aleandro,


What make / size card was it?

[aleandro]

I cannot read the make of that 4GB sd card. I cannot remember. In any case it is a sd hc. It is unrecoverable with none of the recovery tools around.

 It cannot be that my weather station makes so many read-write cycles to destroy cards in few months.

[aleandro]

I'm trying to use this time a 4GB SD HC of Sandisk (named Sandisk Ultra with a reported velocity of 15MB/s). I'll will post the result when the system managing the weather station is going again. I suspect that the sheevaplug is going to be junked cause I feel a high temperature on the case.

[aleandro]

hello folk, here another SD card utilised for 2 months in my weather station and completely destroyed by my sheeva.

Experiment: I wanted to try no HD and HC cards. I bought just a normal one: KINGSTONE SD 2GB

In the attachment the result of the filesystem check from Gparted. Any idea? I destroy a card every 2-3 months....

Additional info: the debian system on the SD card began to have some problem and the weatherstation began to have shutdowns and malfunctions and didn't send updates to the webserver. I removed it after a "shutdown - h now", waiting some minute and cutting finally the power off. I put it into my laptop and started Gparted that found that the system couldn't be mounted and was proposing a check; I did it and after the check the result was: "ext3 journal has been cancelled. FS will be ext2 only". The other ultimate check shows what I have left in the attach. I hope you could explain me something more detailed.

I'm keeping the destroyed SD cards in a box. In few months when I'll get the next one I'll send you the cards to England. Maybe you could check them with more sophisticated methods.

Bye 



 

[mw]

It cannot be that my weather station makes so many read-write cycles to destroy cards in few months.

Do you actually know how many read-write cycles your weather station makes ?

For example, a system log entry every 5 minutes = 12 per hour = 288 per day ~ 2,000 per week. This might happen if, for example, you had a cron job running every five minutes.

[aleandro]

I do not know how many cycles. But I have a cron every  5 minutes plus some other every now and then.

Do you know a command to measure them under debian? It is important to investigate this point too.

In any case a friend of mine with the same entries in crontab has a normal SD since 2 years without problems. I sicerely think it is either an hardaware problem or a problem of filesystem. I actually use ext3. Might  it help next time to try xfs or ext4 ?