BackgroundI have two visually same 2GB microSD cards, both labeledSD-C02G JAPAN, under the 2GB microSD logo.My problem is that I can't read one of them in any device except an oldNokia 5310 XpressMusic.  The phone is dying, by which I mean it's very hard to operate (dysfunctional keys, display going nuts), but the fact thatit can read/write the card leads me to believe that the card is notbroken (whatever that means).(I'd like to believe that the card is dead and just toss it into thegarbage, but then I would have to live with questions like: why the oldNokia still could read it?)I should also mention that the card has probably been previouslyencrypted by some technology in the Nokia phone (not the very samemachine, but another piece of the same model, which is dead now aswell.). (Probably, because there are more cards in the house andI know one of them has been encrypted, and since all other workeverywhere, I assume it was this one).Methods / OutputsNow other methods I tried with both cards (I'll mostly describethe bad card behavior):(A) two different Android phones, both telling thatthe card is not inserted at all, therefore not offeringoption 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 readera 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 microSDto SD adapter since the reader lacks a slot smallenough); 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 thegood and the bad card:mkdosfsWith method (C) and bad card, mkdosfs says /dev/sdb: No mediumfound. I did not try it with method (D); I find it pointless since thedevice file does not exist at all.  And I did not try with the goodcard since I do not want to lose the data...fdiskWhen 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 allthe card is auto-mounted.kern.logmethod (C) and the bad card:usb 1-1: new high speed USB device number 7 using ehci_hcdusb 1-1: New USB device found, idVendor=14cd, idProduct=121cusb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=2usb 1-1: Product: Mass Storage Deviceusb 1-1: Manufacturer: Genericusb 1-1: SerialNumber: 812320090519scsi9 : usb-storage 1-1:1.0scsi 9:0:0:0: Direct-Access     USB Mass Storage Device        PQ: 0 ANSI: 0 CCSsd 9:0:0:0: Attached scsi generic sg2 type 0sd 9:0:0:0: [sdb] Attached SCSI removable diskmethod (C) and the good card:usb 1-1: new high speed USB device number 8 using ehci_hcdusb 1-1: New USB device found, idVendor=14cd, idProduct=121cusb 1-1: New USB device strings: Mfr=1, Product=3, SerialNumber=2usb 1-1: Product: Mass Storage Deviceusb 1-1: Manufacturer: Genericusb 1-1: SerialNumber: 812320090519scsi10 : usb-storage 1-1:1.0scsi 10:0:0:0: Direct-Access     USB Mass Storage Device        PQ: 0 ANSI: 0 CCSsd 10:0:0:0: Attached scsi generic sg2 type 0sd 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 offsd 10:0:0:0: [sdb] Mode Sense: 03 00 00 00sd 10:0:0:0: [sdb] No Caching mode page presentsd 10:0:0:0: [sdb] Assuming drive cache: write throughsd 10:0:0:0: [sdb] No Caching mode page presentsd 10:0:0:0: [sdb] Assuming drive cache: write through sdb:sd 10:0:0:0: [sdb] No Caching mode page presentsd 10:0:0:0: [sdb] Assuming drive cache: write throughsd 10:0:0:0: [sdb] Attached SCSI removable diskFAT-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:  0x00000400sdhci: Blk size: 0x00000000 | Blk cnt:  0x00000000sdhci: Argument: 0x00000000 | Trn mode: 0x00000000sdhci: Present:  0x01ff0001 | Host ctl: 0x00000001sdhci: Power:    0x00000000 | Blk gap:  0x00000000sdhci: Wake-up:  0x00000000 | Clock:    0x00000000sdhci: Timeout:  0x00000009 | Int stat: 0x00000000sdhci: Int enab: 0x00ff00c3 | Sig enab: 0x00ff00c3sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000sdhci: Caps:     0x01e021a1 | Caps_1:   0x00000000sdhci: Cmd:      0x00000102 | Max curr: 0x00000040sdhci: Host ctl2: 0x00000000sdhci: ===========================================mmc0: Got command interrupt 0x00030000 even though no command operation was in progress.sdhci: =========== REGISTER DUMP (mmc0)===========sdhci: Sys addr: 0x00000000 | Version:  0x00000400sdhci: Blk size: 0x00000000 | Blk cnt:  0x00000000sdhci: Argument: 0x00000000 | Trn mode: 0x00000000sdhci: Present:  0x01ff0000 | Host ctl: 0x00000001sdhci: Power:    0x00000000 | Blk gap:  0x00000000sdhci: Wake-up:  0x00000000 | Clock:    0x00000000sdhci: Timeout:  0x00000009 | Int stat: 0x00000000sdhci: Int enab: 0x00ff00c3 | Sig enab: 0x00ff00c3sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000sdhci: Caps:     0x01e021a1 | Caps_1:   0x00000000sdhci: Cmd:      0x00000102 | Max curr: 0x00000040sdhci: Host ctl2: 0x00000000sdhci: ===========================================This repeats 4 times (including the 10s delay).method (D) and the good card:mmc0: new high speed SD card at address ef87mmcblk0: 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!QuestionCan anybody explain what is wrong with this card?  Or at least whatkern.log is showing?Could the encryption corrupt the card?  If so, why can't I simplyre-format it?  (I'm OK with blasting the content.)Or, what other methods of debugging would you suggest?
SD card not accessible (works in an old Nokia though)
linux;debian;sd card
Short answerThe 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 evento the point of giving an useful error).  Presumably this applies to mentioned Androidsas wellthe phone refuses to format the card and remove the password.  You can eitherremove the password, but you need to know the old one, or format the card, but thatwill not remove the passwordSo maybe other firmware has option to wipe it completely, but this is another questionfor 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 ;-DPoint 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.