PLEASE POST: Your Sd Card Experiences. (Cards/Build no./)

[Guest unrandomsam]

I have a play.com bought

PNY class 10 16GB works fine.

(Performs pretty badly though unless you use a 32k block size and then you waste tons of space).

I think I will buy lexar in the future.

Edited May 29, 2011 by unrandomsam

[Guest hugobosslives]

@ mushroom_man

this website has proved useful in the past: http://www.myphone.gr/forum/showthread.php...587#post3473587

i know its in greek. but its pretty obvious what its saying (if not use google translate!)

been pretty reliable for me (and my m8s with blades)

check it out :D

EDIT: scroll down a bit, to the list of working/non working cards

Edited May 29, 2011 by hugobosslives

[Guest k0zmic]

1.) Innov8 16GB Class 10 working fine as does a Transcend 8GB Class 6.

2.) White TFT with B10.

[Guest Mushroom_Lord]

Saying your Orginal Stock ROM Build No. Isn't really a way of identifiying which Blade has the problem or not, Try a 2.2 Stock ROM with a the stock Kernel, all ZTE 2.2 releases after the B13 Softbank rom as the kernel source is based on B13 and the later releases are using a newer source code it's not a hardware issue it's ZTE not giving us the badword new source code, but ZTE are supposing to be evaluating 2.3 for the Orange SF and bringing it to the SF in Q2. Try using the Stock Comviq Kernel with SS RLS5 and see if your still getting a SD Card troubles.

Sorry, I though b08 etc was what hardware revision you had - but anyhow you seemed to have ruled that out?

I think, that, the problem can occur for EITHER software OR hardware reasons...

Anyhow I got a reply from ZTE:

Dear sir/madam，

Thank you for contacting us, I'm sorry to reply to you so late.

In order to serve you better，it would be beneficial if some details are available:

1.The place you bought your Blade(country/city) and the IMEI/ESN/MSN number of it;

2.The date you bought your Blade;

3.Your service provider(Operator);

4.The specific description about the requirement/problem/fault phenomena, such as the computer brand, exact operating system information, etc.

To ensure proper handling, please continue to use the current subject line & reply with previous emails.

Then we will reply to you as soon as possible, looking forward to receiving your reply.

Should you require any further assistance, please do not hesitate to contact us!

Best Regards

Sincerely yours

I'm not too sure if this was automated, cause it does say blade like I did, but, in the first mail i already told them I had bought it from Orange in the UK! (but its different people I guess :D)

Anyhow the 16gb class4 Sandisk I ordered yesterday doesn't work when it arrives I will mail them back: no need as of yet :D

[Guest shadowninty]

http://code.google.com/p/cyanogenmod/issue...315#makechanges

STAR IT!!

[Guest shadowninty]

http://code.google.com/p/cyanogenmod/issue...315#makechanges

STAR IT!!

[Guest irishpancake]

http://code.google.com/p/cyanogenmod/issue...315#makechanges

STAR IT!!

You can say that again..... :D

OK, so I have a B10 (originally) OSF, now a GEN2 by TPT, running SS RLS5.....

Upgraded my SD recently, from the 2GB stock card to a SanDisk 16GB from Amazon...it says Class 2 but I git Class 4.

I got it, and re-formatted it, via ClockWork Recovery.....no adapter!!! Did this cos I saw it recommended, to avoid any probs with un-mounting, etc.

I restored all my backed-up SD data, no probs at all, so far so good.

I have noticed that this card is slower than the stock, if one goes by the SD Tools app, and the cache is increased to 2048 or 1024.....???

I do not know what class the stock card is, it's a Transcend.....??

But, I have also ensured to register my new card with SanDisk for warranty until 2016!!!! here:

http://kb.sandisk.com/app/account/prodreg/alist

Hope this helps...

[Guest Hanks6]

OLED B05 Model

8gb Samsung Micro SDHC PLUS Class 6 Card (the grey one)

FLB Froyo r11b

this card has also worked flawlessly on every other rom i've tried on my Blade.

[Guest Mushroom_Lord]

http://code.google.com/p/cyanogenmod/issue...315#makechanges

STAR IT!!

TELL ME HOW TELL ME HOW.

And thanks for the input guys ^^ :D

EDIT: I found it :D

Edited June 2, 2011 by Mushroom_Lord

[Guest dandroidme]

I've had a quick look and I reckon (say 70% confident) that the problem is that the blade Kernel is using a version of fsck which relys on DOSBOOTBLOCKSIZE (=512), for block calculation which up until recently was almost certain to be correct. It's no longer a certainty with the newer, larger SD cards. When fsck is run at start-up, it will be looking in all the wrong places for it's various cues, which would lead to entertaining consequences especially if it took it upon itself to repair the volume.

If I'm correct the problem exists in FAT32 formatted cards only that had managed to get themselves into a state where the block size was specified differently to 512. Quite how they get into that state is a bit of a mystery and would depend on a number of things, e.g. how they left the factory and what/how they have been formatted once in the hands of the end user.

Anyhoo, there's patches floating around for newer kernels which fix up fsck to use the block size reported by the drive itself, and not default to 512. Someone with enough time might want to try one of those.

d.

[Guest Mushroom_Lord]

I've had a quick look and I reckon (say 70% confident) that the problem is that the blade Kernel is using a version of fsck which relys on DOSBOOTBLOCKSIZE (=512), for block calculation which up until recently was almost certain to be correct. It's no longer a certainty with the newer, larger SD cards. When fsck is run at start-up, it will be looking in all the wrong places for it's various cues, which would lead to entertaining consequences especially if it took it upon itself to repair the volume.

If I'm correct the problem exists in FAT32 formatted cards only that had managed to get themselves into a state where the block size was specified differently to 512. Quite how they get into that state is a bit of a mystery and would depend on a number of things, e.g. how they left the factory and what/how they have been formatted once in the hands of the end user.

Anyhoo, there's patches floating around for newer kernels which fix up fsck to use the block size reported by the drive itself, and not default to 512. Someone with enough time might want to try one of those.

d.

Thanks for the info!

Looks like getting a fix is closer :D

[Guest Mushroom_Lord]

I suggest we all star that cm7 issue!

Oh, and, my 16gb Class 4 Sandisk just arrived and it works with my oled b08 :D

[Guest shadowninty]

I've had a quick look and I reckon (say 70% confident) that the problem is that the blade Kernel is using a version of fsck which relys on DOSBOOTBLOCKSIZE (=512), for block calculation which up until recently was almost certain to be correct. It's no longer a certainty with the newer, larger SD cards. When fsck is run at start-up, it will be looking in all the wrong places for it's various cues, which would lead to entertaining consequences especially if it took it upon itself to repair the volume.

If I'm correct the problem exists in FAT32 formatted cards only that had managed to get themselves into a state where the block size was specified differently to 512. Quite how they get into that state is a bit of a mystery and would depend on a number of things, e.g. how they left the factory and what/how they have been formatted once in the hands of the end user.

Anyhoo, there's patches floating around for newer kernels which fix up fsck to use the block size reported by the drive itself, and not default to 512. Someone with enough time might want to try one of those.

d.

Ah, but would these patches work with our .32 kernel or will we need to wait for .35?

Thanks for the info ! :D

[Guest shadowninty]

Any ideas how to change block size on SD Card?

[Guest Mushroom_Lord]

Any ideas how to change block size on SD Card?

I've never looked at it, but I'll have a look at easus partition manager: I think it had some fairly advanced settings there.. brb :D

*thoughts: Nope thats cluster size on ntfs you donut...

Sorry I haven't a clue :D

Edited June 3, 2011 by Mushroom_Lord

[Guest Jekle]

People are claming that they can use there unworking cards in ClockworkMod but won't work in Android with Custom Kernel, But To build both they use the 2.6.32 kernel source, can anyone explain?

[Guest shadowninty]

I was wrong, it seems that both have the same issue;

They cant write to the card

The difference is CWM doesn't go crazy when it can't write, but Android does

Edited June 3, 2011 by shadowninty

[Guest Mushroom_Lord]

Well, hopefully people will star the issue in cyanogen, and they might sort it out.

Or shall we bother Zte?

[Guest shadowninty]

Non working card

Disk /dev/sdb: 7969 MB, 7969177600 bytes

246 heads, 62 sectors/track, 1020 cylinders

Units = cylinders of 15252 * 512 = 7809024 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x0005fdfc


   Device Boot	  Start		 End	  Blocks   Id  System

/dev/sdb1   *		   1		1020	 7778489	b  W95 FAT32

Working card

Disk /dev/sdb: 3965 MB, 3965190144 bytes

49 heads, 48 sectors/track, 3292 cylinders

Units = cylinders of 2352 * 512 = 1204224 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x07007e00


   Device Boot	  Start		 End	  Blocks   Id  System

/dev/sdb1			   4		3293	 3868160	b  W95 FAT32

Issues I see are sectors per track and Cylinders

Edited June 3, 2011 by shadowninty

[Guest shadowninty]

BUMP!

[Guest Men in pyjamas]

I have a 16GB noname card I have bought from pandawill (no links, sorry, find it yourself).

On my previous ZTE blade it was not recognised at all. For my surprise, on a replacement one this card works like a charm. So the equation is more complex like card manuacturer/model/production series number.

Buy whatever is reported to be working and YMMV, don't take any information as granted. An think of possible other uses if the card proves not operational on your phone: readyboost, picture camera, other phone.

[Guest dandroidme]

Non working card

Disk /dev/sdb: 7969 MB, 7969177600 bytes

246 heads, 62 sectors/track, 1020 cylinders

Units = cylinders of 15252 * 512 = 7809024 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x0005fdfc


   Device Boot	  Start		 End	  Blocks   Id  System

/dev/sdb1   *		   1		1020	 7778489	b  W95 FAT32

Working card

Disk /dev/sdb: 3965 MB, 3965190144 bytes

49 heads, 48 sectors/track, 3292 cylinders

Units = cylinders of 2352 * 512 = 1204224 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x07007e00


   Device Boot	  Start		 End	  Blocks   Id  System

/dev/sdb1			   4		3293	 3868160	b  W95 FAT32

Issues I see are sectors per track and Cylinders

That does not appear to be a problem with the block size - So much for my theory.

There is something odd with it, though. Try formatting the non working card with this - http://panasonic.jp/support/global/cs/sd/download/index.html, do the full format which will take forever but will rid the card of any nonsense. Then put it straight into the phone without letting your PC write to it or even remount it. Then refer to the instructions in the cyanogen bug tracker, see if fsck_msdos is still choking on it.

d.

[Guest shadowninty]

Its been formatted so many times it wont make a difference

Different partition tables don't help either

I'm puzzled

[Guest shadowninty]

BTW, I was unable to change the amount of cylinders on the 8GB card....

[Guest dandroidme]

Its been formatted so many times it wont make a difference

Different partition tables don't help either

I'm puzzled

Yep, I guessed that. When you format a card you don't normally touch the boot record which exists in the first 1 block and I suspect this is where the problem is. Using the Panasonic formatter will delete the boot record and all the partition tables (you don't actually need them!)

What I'm worried about is this bit of code from (older) msdos_fsck:

  

65		 if (block[510] != 0x55 || block[511] != 0xaa) {


  66				 pfatal("Invalid signature in boot block: %02x%02x", block[511], block[510]);


  67				 exit(2);


  68		 }

Which is looking for a signature (0x55, 0xAA) near the end of the first block (bytes 510, 511). This is always correct if the block size is 512 bytes. However, if the block size was (say) 1024 bytes, then this signature would actually be at the end of that (bytes 1022, 1023).

If you look at the layout of the two cards which you posted, the FAT partition on the working card starts at block 1 (x512), suggesting the calculation above will work. On the broken card, however, the FAT partition starts at block 4 (x512), which says to me the boot record is not 512 bytes long, and that means an unpatched msdos_fsck is looking in the wrong place for the signature.

One thing you can try is to use the linux "dd" command (sorry, cannot be bothered trying to explain the syntax!) or a disk editor to dump the first 4x512 bytes of your non-working card and see if you can locate the signature.

d.

Edited June 5, 2011 by dandroidme