Guest unrandomsam Posted May 29, 2011 Report Share Posted May 29, 2011 (edited) 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 Link to comment Share on other sites More sharing options...
Guest hugobosslives Posted May 29, 2011 Report Share Posted May 29, 2011 (edited) @ 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 Link to comment Share on other sites More sharing options...
Guest k0zmic Posted May 29, 2011 Report Share Posted May 29, 2011 1.) Innov8 16GB Class 10 working fine as does a Transcend 8GB Class 6. 2.) White TFT with B10. Link to comment Share on other sites More sharing options...
Guest Mushroom_Lord Posted May 29, 2011 Report Share Posted May 29, 2011 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 Link to comment Share on other sites More sharing options...
Guest shadowninty Posted June 1, 2011 Report Share Posted June 1, 2011 http://code.google.com/p/cyanogenmod/issue...315#makechanges STAR IT!! Link to comment Share on other sites More sharing options...
Guest shadowninty Posted June 1, 2011 Report Share Posted June 1, 2011 http://code.google.com/p/cyanogenmod/issue...315#makechanges STAR IT!! Link to comment Share on other sites More sharing options...
Guest irishpancake Posted June 1, 2011 Report Share Posted June 1, 2011 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... Link to comment Share on other sites More sharing options...
Guest Hanks6 Posted June 2, 2011 Report Share Posted June 2, 2011 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. Link to comment Share on other sites More sharing options...
Guest Mushroom_Lord Posted June 2, 2011 Report Share Posted June 2, 2011 (edited) 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 Link to comment Share on other sites More sharing options...
Guest dandroidme Posted June 2, 2011 Report Share Posted June 2, 2011 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. Link to comment Share on other sites More sharing options...
Guest Mushroom_Lord Posted June 2, 2011 Report Share Posted June 2, 2011 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 Link to comment Share on other sites More sharing options...
Guest Mushroom_Lord Posted June 3, 2011 Report Share Posted June 3, 2011 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 Link to comment Share on other sites More sharing options...
Guest shadowninty Posted June 3, 2011 Report Share Posted June 3, 2011 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 Link to comment Share on other sites More sharing options...
Guest shadowninty Posted June 3, 2011 Report Share Posted June 3, 2011 Any ideas how to change block size on SD Card? Link to comment Share on other sites More sharing options...
Guest Mushroom_Lord Posted June 3, 2011 Report Share Posted June 3, 2011 (edited) 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 Link to comment Share on other sites More sharing options...
Guest Jekle Posted June 3, 2011 Report Share Posted June 3, 2011 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? Link to comment Share on other sites More sharing options...
Guest shadowninty Posted June 3, 2011 Report Share Posted June 3, 2011 (edited) 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 Link to comment Share on other sites More sharing options...
Guest Mushroom_Lord Posted June 3, 2011 Report Share Posted June 3, 2011 Well, hopefully people will star the issue in cyanogen, and they might sort it out. Or shall we bother Zte? Link to comment Share on other sites More sharing options...
Guest shadowninty Posted June 3, 2011 Report Share Posted June 3, 2011 (edited) 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 Link to comment Share on other sites More sharing options...
Guest shadowninty Posted June 4, 2011 Report Share Posted June 4, 2011 BUMP! Link to comment Share on other sites More sharing options...
Guest Men in pyjamas Posted June 4, 2011 Report Share Posted June 4, 2011 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. Link to comment Share on other sites More sharing options...
Guest dandroidme Posted June 4, 2011 Report Share Posted June 4, 2011 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. Link to comment Share on other sites More sharing options...
Guest shadowninty Posted June 4, 2011 Report Share Posted June 4, 2011 Its been formatted so many times it wont make a difference Different partition tables don't help either I'm puzzled Link to comment Share on other sites More sharing options...
Guest shadowninty Posted June 5, 2011 Report Share Posted June 5, 2011 BTW, I was unable to change the amount of cylinders on the 8GB card.... Link to comment Share on other sites More sharing options...
Guest dandroidme Posted June 5, 2011 Report Share Posted June 5, 2011 (edited) 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 Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now