Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Background

I have two visually same 2GB microSD cards, both labeled "SD-C02G JAPAN", under the "2GB microSD" logo.

My problem is that I can't read one of them in any device except an old Nokia 5310 "XpressMusic". The phone is dying, by which I mean it's very hard to operate (dysfunctional keys, display going nuts), but the fact that it can read/write the card leads me to believe that the card is not broken (whatever that means).

(I'd like to believe that the card is dead and just toss it into the garbage, but then I would have to live with questions like: why the old Nokia still could read it?)

I should also mention that the card has probably been previously encrypted by some technology in the Nokia phone (not the very same machine, but another piece of the same model, which is dead now as well.). ("Probably", because there are more cards in the house and I know one of them has been encrypted, and since all other work everywhere, I assume it was this one).

Methods / Outputs

Now other methods I tried with both cards (I'll mostly describe the "bad" card behavior):

  • (A) two different Android phones, both telling that the card is not inserted at all, therefore not offering option to format

  • (B) A PC with Ubuntu 12.04 LTS (kernel 3.2.0-37-generic, x86_64) using a small Kingston USB-stick-sized microSD card reader

  • a laptop with Debian Wheezy (kernel 3.0.0.1-amd64), using

    • (C) same method as (B); lsusb tells me:

      Bus 001 Device 005: ID 14cd:121c Super Top microSD card reader
      
    • (D) a built-in, i.e. PCI SD reader (with help of microSD to SD adapter since the reader lacks a slot small enough); lspci tells me:

      15:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)
      

(A) does not give me any useful info, and as far as I can see (B) and (C) behave the same. Therefore I will compare (C) and (D) with the "good" and the "bad" card:

mkdosfs

With method (C) and "bad" card, mkdosfs says /dev/sdb: No medium found. I did not try it with method (D); I find it pointless since the device file does not exist at all. And I did not try with the "good" card since I do not want to lose the data...

fdisk

  • When the "bad" card is mounted, (C) sudo fdisk -l /dev/sdb or (D) sudo fdisk -l /dev/mmcblk0 return nothing; in the latter case /dev/mmcblk0 does not exist.

  • For the "good" card, both outputs are as expected, after all the card is auto-mounted.

kern.log

  • method (C) and the "bad" card:

    usb 1-1: new high speed USB device number 7 using ehci_hcd
    usb 1-1: New USB device found, idVendor=14cd, idProduct=121c
    usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=2
    usb 1-1: Product: Mass Storage Device
    usb 1-1: Manufacturer: Generic
    usb 1-1: SerialNumber: 812320090519
    scsi9 : usb-storage 1-1:1.0
    scsi 9:0:0:0: Direct-Access     USB Mass Storage Device        PQ: 0 ANSI: 0 CCS
    sd 9:0:0:0: Attached scsi generic sg2 type 0
    sd 9:0:0:0: [sdb] Attached SCSI removable disk
    
  • method (C) and the "good" card:

    usb 1-1: new high speed USB device number 8 using ehci_hcd
    usb 1-1: New USB device found, idVendor=14cd, idProduct=121c
    usb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=2
    usb 1-1: Product: Mass Storage Device
    usb 1-1: Manufacturer: Generic
    usb 1-1: SerialNumber: 812320090519
    scsi10 : usb-storage 1-1:1.0
    scsi 10:0:0:0: Direct-Access     USB Mass Storage Device        PQ: 0 ANSI: 0 CCS
    sd 10:0:0:0: Attached scsi generic sg2 type 0
    sd 10:0:0:0: [sdb] 3842048 512-byte logical blocks: (1.96 GB/1.83 GiB)
    sd 10:0:0:0: [sdb] Write Protect is off
    sd 10:0:0:0: [sdb] Mode Sense: 03 00 00 00
    sd 10:0:0:0: [sdb] No Caching mode page present
    sd 10:0:0:0: [sdb] Assuming drive cache: write through
    sd 10:0:0:0: [sdb] No Caching mode page present
    sd 10:0:0:0: [sdb] Assuming drive cache: write through
     sdb:
    sd 10:0:0:0: [sdb] No Caching mode page present
    sd 10:0:0:0: [sdb] Assuming drive cache: write through
    sd 10:0:0:0: [sdb] Attached SCSI removable disk
    FAT-fs (sdb): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
    
  • method (D) and the "bad" card:

    mmc0: error -110 whilst initialising SD card
    [...10 secs later...]
    mmc0: Timeout waiting for hardware interrupt.
    sdhci: =========== REGISTER DUMP (mmc0)===========
    sdhci: Sys addr: 0x00000000 | Version:  0x00000400
    sdhci: Blk size: 0x00000000 | Blk cnt:  0x00000000
    sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
    sdhci: Present:  0x01ff0001 | Host ctl: 0x00000001
    sdhci: Power:    0x00000000 | Blk gap:  0x00000000
    sdhci: Wake-up:  0x00000000 | Clock:    0x00000000
    sdhci: Timeout:  0x00000009 | Int stat: 0x00000000
    sdhci: Int enab: 0x00ff00c3 | Sig enab: 0x00ff00c3
    sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
    sdhci: Caps:     0x01e021a1 | Caps_1:   0x00000000
    sdhci: Cmd:      0x00000102 | Max curr: 0x00000040
    sdhci: Host ctl2: 0x00000000
    sdhci: ===========================================
    mmc0: Got command interrupt 0x00030000 even though no command operation was in progress.
    sdhci: =========== REGISTER DUMP (mmc0)===========
    sdhci: Sys addr: 0x00000000 | Version:  0x00000400
    sdhci: Blk size: 0x00000000 | Blk cnt:  0x00000000
    sdhci: Argument: 0x00000000 | Trn mode: 0x00000000
    sdhci: Present:  0x01ff0000 | Host ctl: 0x00000001
    sdhci: Power:    0x00000000 | Blk gap:  0x00000000
    sdhci: Wake-up:  0x00000000 | Clock:    0x00000000
    sdhci: Timeout:  0x00000009 | Int stat: 0x00000000
    sdhci: Int enab: 0x00ff00c3 | Sig enab: 0x00ff00c3
    sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
    sdhci: Caps:     0x01e021a1 | Caps_1:   0x00000000
    sdhci: Cmd:      0x00000102 | Max curr: 0x00000040
    sdhci: Host ctl2: 0x00000000
    sdhci: ===========================================
    

    This repeats 4 times (including the 10s delay).

  • method (D) and the "good" card:

    mmc0: new high speed SD card at address ef87
    mmcblk0: mmc0:ef87 SD02G 1.83 GiB 
     mmcblk0:
    FAT-fs (mmcblk0): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
    

Question

Can anybody explain what is wrong with this card? Or at least what kern.log is showing?

Could the encryption corrupt the card? If so, why can't I simply re-format it? (I'm OK with blasting the content.)

Or, what other methods of debugging would you suggest?

share|improve this question
3  
I'd guess you have a password-protected SD card, which is something that at least Wikipedia informs me is a hardware feature on the card. Maybe you can reformat it from the Nokia? –  derobert Feb 7 '13 at 21:20
    
@derobert The password protection: Thanks for pointer. That would make sense, but since the card was previously used in other 5310 machine, the password would have to be shared, say, across all 5310's. (AFAIK, the password was never provided by user nor asked for; I'd assume Nokia uses some algorithm to generate a strong one....) –  Alois Mahdal Feb 7 '13 at 21:46
    
@derobert I'll try to re-format, but as I have said, due to its technical condition, it will be probably tough call to make any reasonable communication with the machine ;) –  Alois Mahdal Feb 7 '13 at 21:48
    
Did you use the same MicroSD adapter with both cards? Possibly need to clean contacts? –  vonbrand Feb 7 '13 at 22:34

2 Answers 2

up vote 3 down vote accepted

Short answer

The card is password-protected. (@derobert's guess is right.) And kernel modules do not provide useful pointers to this.

TL;DR:

I was suspecting this but I did not know that it's a SD-specific hardware feature; I thought that the Nokia simply encrypts the partition which I would be able to solve by action like mkdosfs /dev/sdb or such.

Too bad that:

  • it seems that this function is widely unsupported by current Linux modules (not even to the point of giving an useful error). Presumably this applies to mentioned Androids as well

  • the phone refuses to format the card and remove the password. You can either remove the password, but you need to know the old one, or format the card, but that will not remove the password

So maybe other firmware has option to wipe it completely, but this is another question for another forum.

Funny background note:

While I was attending to collecting the data above, my old man (user of the phone/cards, born '45), took the old-school approach and fixed the "dying" phone by cleaning it with piece of cloth and ethanol!

This magical-sealed-computer-driven-gadget age: 0 My dad: 1 ;-D

Point is that I am now able to verify that the password has been set (and compare to the "good" card). Who and how did it, will remain a mystery.

share|improve this answer

I have a lot of bad experience with MicroSD-Cards. They seem to be very sensitive. I have some, that are readable in a Navigon routing device. But not in my Thinkpad X40 internal card reader (with SD card to microSD adaptor).

I never tried that—but I should—to clean the contacts of the card. Maybe that helps. I think that at least one of the contacts has bad connection. The card is recognized ([sdb] Attached SCSI removable disk) at least in a generic way. I assume you have no further entries in /proc/partitions, do you?

If you search for mmc error 110 you get a lot of discussions about that. Couldn’t find the solution. But maybe you can search in this direction again and post your results here.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.