yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] ChrisCTX:
Galaxy Tab (the original), specially CDMA (Sprint / Verizon) variants suffer from it a lot, a couple of people are "working" on a external booting kernel image, but non have delivered so far...
[Captivate Android Development] swayjd:
Can you be a tad more specific? Suffer how? Anyone has gotten his internal storage permanently unusable? Like it happens with the captivate.
[Captivate Android Development] jcjcc:
Hey Woodrube, anyone on the reference thread report a fried internal SD on vanilla CM9 with

no custom kernel

?

Just a thought, but CM9 was about when everybody's custom kernels started doing LiveOC... e.g. dangerous messing with internal voltages.

(I know I had an epic 130% stable live OC going on my phone before the sdcard died...)

Also, in the entire course of the thread, has anybody ever grabbed a logcat right at the moment the screen dims and the bootanimation starts looping (then, when you reboot you get EU)? I feel like that would be an extremely crucial clue (although difficult to obtain) and I don't think we can do anything but conjecture unless we have that log.

Re: people abandoning this problem, yeah, it's very frustrating, and it's been going on for such a long time that most people have moved on (including me, I wish the One X had more development though). My captivate is still a very good backup device and saved my skin in Japan (where docomo does imei filtering... yikes, and here I thought at&t was bad).
[Captivate Android Development] ReDaved:
file structure question

Ok maybe this is lame, and this is how it always is...

I have a path of /sdcard

and a seemingly identical path of /mnt/sdcard

Are these the same thing, copies, or is this the crapped EU fix trickery.

I've had issues with heat, crashing, and have had difficulties getting things back up and running, but it's running now...

thanks!

dave
[Captivate Android Development] Woody:
They are the same thing. #nosorcery

There was some mention not too long ago about overclocking to higher CPU frequencies essentially frying the internal chips but nothing ever came from it. Makes sense about the relationship to CM9 and it variants but Cyanogen himself gave up on this bug too (there is a link buried in here somewhere) .

But you do bring up a good idea/plan. I wonder if anyone who already has the EU and done the work around has tried to capture a logcat? It would have to be done on a PC with ADB.

Can someone with ADB try this? Power down and pull your external SD (presuming the fix has already been applied to the vold). Fire up ADB and get a logcat running. Plug in your phone and power it up (phone doesn't need to be on before to have ADB recognize it). Since you pulled the external you should get the EU bug straightaway. Catch the log, save it and post here. Then you should be able to put your external back in and it would be business as usual.
[Captivate Android Development] ableeker:
I have a Galaxy Tab 7 (the original), and I have seen the EU screen numerous times when I was running ICS (a modified beta CM9, and for a short time an AOKP). The EU screens were annoying, but I wasn't worried at the beginning, because all it did was wipe the phone, like a factory reset. However, they seemed to occur more and more frequently, so I got a bit worried. More so because I wondered why I sometimes couldn't flash back to stock, and failed while it was flashing the hidden file. Last time I was running an AOKP, when I rebooted it because GPS wasn't working. I got the EU screen again, and being sick of the screen decided to flash to an unofficial CM7 that was being created for the Tab. I restocked to Froyo, because I have a version that's recognised by Kies and will update to GB over the air. This time however, the OTA update failed, and Kies suggested to do a emergency recovery. Luckily this worked after some tries and I was able to flash CM7. This was a month ago or so, and I started to look up this phenomenon, and then I really started to worry...

So yes, it only happens on ICS, I have had no problem whatsoever with CM7, even though I flash newer versions almost weekly. And no, the EU screen hasn't permanently damaged the internal storage, even though I've seen it a dozen times so far. It "just" does a wipe. However, I am inclined to think it may damage the internal storage if I keep running ICS. This is just a gut feeling though. I do wonder though, because I've seen reports on the Tab's forum where people are having problems like internal being storage being read only, and flashing failing that sure looks like it's caused by internal storage being damaged...

I also don't think it's caused by pulling the Tab without unmounting it first, at least not in my case. I've been running and administering Windows and Linux computers for literally decades now, and I never pull a device without unmounting it. It's ingrained in my system.

I have read here somewhere that ICS uses a storage command that GB never has used, and that the new command triggers a bug that's present in certain versions of the controller. And that Google and Samsung know about it and have acknowledged its existence. Has that come to something?

I'm hoping this bug has been solved in Jellybean...
[Captivate Android Development] yosup:
Thanks for the detailed comment. It's good to see SGT7 added to the knowledgebase here. Btw, are you using the CDMA (VZW/Sprint) or GSM (P1000) version?

What puzzles me (about the SGT7) is a lot of CDMA 7" Tab users were reporting mount failure issues in recovery ... and many posts without any mention of the EU screen.

Typical example:

Then consider djmikebrady's post mentioning he had never rooted or flashed his "stock" rom:

I wonder if something more extreme is happening in the SGT7's??
[Captivate Android Development] trevd:
Hi Folks,

Here's my thread from the Galaxy Tab Forum Which Worked Around Internal SDCard Damage [FIX] [UPDATED] Internal SDCARD Damaged Essentially it's the Same as the OP,

Thought I share it as reference,

The Error was this:

mmc0:* error -110 whilst initialising MMC card.

Which I took at face value as an hardware failure and I thought no more about actually "Fixing" the Internal SD.

I would think it is "Something more extreme" on the SGT7 because the problem ( dmesg ) manifested it self long before ICS in the Summer of 2011. It just took me a while to learn how to fix it :) , Plus it seems the EU srceen is more a symptom than a cause.

I'm purely throwing in my 2cents worth as I own neither device ;

If as Some have suggested that the hardware is pyshically still good, than the problem is no where else than the kernel. That gives a couple of options.

1. Adjust / patch the IO Scheduling on the mmc driver Here is an example of something similar done with the Rasperberry PI

2 Fully back port the mmc drivers to the devices kernel, Probably not a trivial task as internal structure and privates api's tend to be pretty fluid in the linux kernel. The arm code for the mmc driver is here for anyone whos curious.

3. Upgrade Your devices Kernel to the Latest Stable or somewhere close. The that end Google have a 3.4 tree that from how I understand it has had the android patches applied to it ( GoogleSource ) you would than need to apply samsungs patches and make sure you have the correct board configs etc but it might be a "goer"

Building Custom Android Kernels is something I'm currently researching, Although It's not something I have any level of knowledge In really and when I say "Custom Kernels" I'm talking about applying the Android patches etc to a Vanilla Kernel, Not downloading a devices Kernel Source grabbing a /proc/.config.gz and running make menuconfig. ;)

Hopefully that's some food for thought and I've not grabbed the stick by the wrong end
[Captivate Android Development] ableeker:
How silly of me, I never mentioned that! Mine's the GSM P1000, the one used in Europe, the one that has phone functionality. It's a P1000 meant for The Netherlands, GT-P1000CWAPHN. The latest official Samsung update was to Gingerbread 2.3.6, P1000XWJQ8, modem P1000XXJPZ, CSC P1000PHNJQ1. After that I've been running mainly modified CM9 beta builds.
[Captivate Android Development] matase:
any way to do this without an sd card?I don't have one and don't feel like ordering it online because it would take a few days to get it shipped.
[Captivate Android Development] s0ul_ali:
JB work around

JB Emmc Reverrse is working great :) thanks budy..!
[Captivate Android Development] Woody:
Sorry man, but using the external SD is kind of the point of the work around. Internal is locked up real tight right now.

I'm mobile so I can't see where you are located, but if in the states you can get one on the cheap at Best Buy or MicroCenter.
[Captivate Android Development] RootTheMachine:
I just received this pm, and thought it was worth sharing another revival story.
[Captivate Android Development] s0ul_ali:
Does any dev has developed any Emmc Reverse ICS zip ? i need it badly...!
[Captivate Android Development] Demetris:
I did in this forum but all those pages hard to find it my self :eek:

I repost it here :fingers-crossed:
[Captivate Android Development] Demetris:
Can anyone please port this fix to our phones?

Would be great to have our SDCARD back, thanks

http://xdaforums.com/showthread.php?t=1840030
[Captivate Android Development] jmtheiss:
So in looking at that thread, I'm wondering if we could do something similar without fully porting. It looks to me (for what that's worth) that we could use the Odin3 that's linked in that thread with a bootloader package (like this one) in place of his bootchains, then flashing a stock, rooted Odin package, using the same boxes (I didn't see a package in the stock roms, but I may have just missed it).

It looks like there's something in rewriting the bootloaders (the bootchain packages contain sbl files), then following with a full nand wipe that is resetting their partitions.

Again, I could be completely wrong, but it's fun to theorize.
[Captivate Android Development] fagnerkof:
What's that about that Odin 3.07 with options for Nand Erasing and all?... I've never seen it before... anyone tried it?
[Captivate Android Development] cbalt:
Doesn't work when checked even with the bootloaders in the PDA Slot. Just did it to see since I got someones cappy which will not boot past ATT screen or Recovery if not on stock firmware. Already tried every combo of going back to stock, tried the repartition of sd card in case it had the EU bug to no luck.
[Captivate Android Development] DerTeufel1980:
Have you also tried my new partition hellybean? As it is using a different way of formating, it maybe works.
[Captivate Android Development] DerTeufel1980:
As one user reported, he could install my rom without issues, which means, that his data partition is used again.

He just had to edit vold.fstab to use external SD as internal
[Captivate Android Development] TheSchatz:
I'll go out on a limb and assume I'm that user.

I can post my vold.fstab if anyone thinks it may help.
[Captivate Android Development] Demetris:
I tried to install new version but always returns to recovery.

Attached log.

Can you please offer us a solution? Thanks
[Captivate Android Development] TheSchatz:
Did you do a full wipe, flash, reboot to recovery, and flash again?
[Captivate Android Development] Demetris:
You are joking, right?
[Captivate Android Development] TheSchatz:
Well... no, I wasn't joking... I can't tell if that means you obviously did all that and how could I ask such a stupid question, or you think it's excessive for an update...

I'm not very good at discerning emotion from text, I only mean to help any way I can :)
[Captivate Android Development] Woody:
Demetris knows what he is doing. Lets just leave it at that. ;)

D, I looked at you logcat but couldn't find anything out if sorts. Ill look at it again after I put my kids to bed.
[Captivate Android Development] DerTeufel1980:
Seems like it can't mount the newly created data and system partitions, what is strange, as TheSchatz did not have this issue.

Can you please grep boot.txt, after reboot to recovery, by using adb

adb shell

cat boot.txt

And also try mounting data and system in recovery using adb

mount data

mount system
[Captivate Android Development] Demetris:
Hi,

Thanks for your response.

I have gone back to ICS but am willing to test this so like me, others will benefit also.

I just want this to be instant test/report thing as i cant be left without a phone is there any irc channel i can find you or anything else like gtalk so can solve this tet a' tet.

You can freely pm me, thanks

Edit: Attached is my boot.txt for ics that works, maybe for reference.
[Captivate Android Development] cas0404:
Hi

Looks like this bug Does not show up on jelly beam, am i right???
[Captivate Android Development] Woody:
At this point we don't know if it hits JB or not. So far I haven't heard anyone on JB get hit with it, but that doesn't mean it isn't out there. Was months before ICS users realized what was happening and then it was too late.
[Captivate Android Development] Demetris:
I think bug was on cwm 5.5.0.4 only.
[Captivate Android Development] Woody:
You know, IIRC the people who got tagged in the Transformer threads might have been using that version. It was causing all kinds if problems, ie see my signature. I'll review the threads later on. I can also check my wife's recovery that hit her Nook Color. Can a few people that got it on their Cappys and Vibrant check too? Nice theory Demetris. Lets see how the ball bounces.
[Captivate Android Development] schwick:
I hope it's just a CWM recovery bug, I really love ICS.
[Captivate Android Development] azunino:
Are you referring to the eMMC erase bug? Because as far as I remember (it's somewhere buried in this thread) that bug does not affect SGS phones. The eMMC bug was triggered by cwm when performing a factory reset using some specific ICS leaked kernels.
[Captivate Android Development] schwick:
I believe he was referring to the encryption bug.
[Captivate Android Development] swayjd:
There is no encryption bug. The screen is just a consequence of the /data being unreadable.

The less miss information the better.
[Captivate Android Development] Woody:
But it would be worth looking into bc it could explain why some people are getting their data back after flashing a new ROM/kernel combo. Not all kernels are using the same recoveries, so maybe flashing a different kernel and then running some commands like the one in my signature for the TF101 Recovery Loop to get rid of the bad recovery still in /cache might be something. I'm still checking on my above post, but I just got a SGS3, so I've been setting and flashing that up.

Fwiw, I almost had my hands on a EU infected Vibrant to work on, but he had already given it away.
[Captivate Android Development] Jolufa:
I created two zip files, one with the original and other vold.fstab file with the modified file so it can be flashed from recovery.

The files were created using the correct files, and so I feel good add in the first post.

I'm using Jelly Bean with Devil Kernel 1.2.1 (or Semaphore 2.0.6)

When I apply the change, either by mounting the system folder and copying the file in /etc or flashing the zip file, when I reboot the phone hangs on logo.

Flashing the original file from the recovery, the system loads normally.

Edited

# internal sdcard that is no longer working
dev_mount emmc /mnt/emmc 1 /devices/platform/s3c-sdhci.0/mmc_host/mmc0

# external sdcard
dev_mount sdcard /mnt/sdcard auto /devices/platform/s3c-sdhci.2/mmc_host/mmc2

Original

# FIXME: Swap again?
# internal sdcard
dev_mount emmc /storage/sdcard1 auto /devices/platform/s3c-sdhci.2/mmc_host/mmc2

# external sdcard
dev_mount sdcard /storage/sdcard0 1 /devices/platform/s3c-sdhci.0/mmc_host/mmc0

Could anyone tell me what should I get the error? :confused:

What could be wrong?

Thank you

[Edit]

Now I found the solution given by demetris_I
[Captivate Android Development] jmtheiss:
I hope so very much this is what it is. I've been back on GB-based roms for the last 3-4 months because I don't want to risk ruining my phone before I upgrade in a couple of months. If it's just a matter of avoiding roms with that version of CWM, I can finally flash up to ICS or JB.
[Captivate Android Development] RootTheMachine:
You know what? I don't think EU can hit anybody on CM10. pawitp put /system where /data used to be, so if it was an issue relating to that partition, it most likely won't happen since we don't mess with /system as much as we do /data. This could be totally wrong if it's not a problem with that particular partition.
[Captivate Android Development] jmtheiss:
That's interesting. Maybe the reason nobody that I've seen has had the EU bug on JB is a combination of the /data being moved and newer CWM versions being used. If either of those factors are what caused it on ICS, it would explain why it isn't showing up on JB roms.
[Captivate Android Development] TheSchatz:
I'm loving all these new ideas floating around, but I have to ask...

What does this mean as far as fixing our affected devices? People seem to have been able to restore function with different ROMs and kernels, but it doesn't appear we know exactly how or why.

If this is indeed a CWM issue, what can we do with that information?

I don't know much about the mechanics of all this, but obviously you guys do, and I'm quite thankful for that!

Thanks for putting your time and effort into this problem, and hopefully we'll have a solution one day :D
[Captivate Android Development] jmtheiss:
The reason a CWM version matters is that if Rom X is using version 6.0.1.1, and Rom Y uses 5.5.0.4, knowing that the 5.5.0.4 CWM is causing issues allows users to know ahead of time of the risk, and allows the developer to update their CWM version to a newer one without the bug.

(This is, of course, assuming the bug is CWM-based.)

As far as fixing the device goes, knowing where the bug exists puts us one step closer to squashing it. If it could possibly be in the kernel, CWM, or rom, that's 3 different and very large sets of variables to work with. Knowing that it's in one of them (CWM, for example), reduces the places to look by a large amount (66% in the example).
[Captivate Android Development] TheSchatz:
Thanks jmtheiss!

Is there anything someone with rather basic knowledge (such as myself) can do to help?
[Captivate Android Development] crt60:
Only thing to do at this point is grab a jellybean rom and hope for the best.
[Captivate Android Development] Johnsondr80:
You mean grab a AoCP jelly belly ROM and experience the best.:cool:
[Captivate Android Development] matmanchu5:
Installing a Rom on an "EUbugged" cappy

Hey, all. Has anybody attempted to get any JB rom running on a cappy with the EU bug? Is is possible that This newer version of CWM might allow any rom to be installed using a partitioned external SDcard instead of the internal DATA partition? The only Rom I have been able to get working is the (formerly) two-part SLIMROM, which consequently erased my un-backed up efs folder. Could this have been a result of using CWM 5.5.0.4? I wonder...
[Captivate Android Development] Jolufa:
I'm using JellyUI , a amazing MIUI port..

I formatted the external memory following the following tutorial:

http://www.youtube.com/watch?v=zdMhYYdMB08

Or using a Kubuntu live disk:

http://www.youtube.com/watch?v=yypzIx-Ayho

And applying Encryption Unsuccessful - Reset Android [ICS Issue] fix for Jelly Bean:

http://xdaforums.com/showthread.php?p=29449973#post29449973

[Click Thanks] :p ;)

Salu2
[Captivate Android Development] Woody:
If this is something to do with CWR5 that would be awesome because then we would have a real, tangible starting point to breakdown. When the CWR bug hit in the Transformer forums, Kousch was able to find what the problem was and implement a fix in the next version. But the problem still remained that the old "bad" version of CWR was still in the tablet/phone and was not overwritten.

The code to remove it from the partition scheme in the Transformers was as follows:

su
echo boot | dd of=/dev/block/[B]mmcblk0p3[/B] bs=1 seek=0 [COLOR=Red]--->our would be mmcblk0p2 [/COLOR]
Reboot

Now if we can figure out that the bad recovery is doing this and so far no one on JB has suffered the EU, then we can (I'll go old school english here)

compare and contrast

the 2 versions, see what is different and why and then reverse engineer the fix.

Obviously all this is easier said then done and I personally am limited in what I can do. We need a kernel dev to look into this. Anyone have one on their team?

Read and keep reading. Maybe some fresh eyes will pick something up that we might have misses. Even basic knowledge is still knowledge my friend and the only way to get more is to read. (Coincidentally, I just had this conversation with my son last night. Not implying that you are young or I am a father figure, it is just a bit ironic is all)

Grip it and Rip it and hope that you don't get tagged down the line. I like it. No guts, no glory.

Nothing wrong with a little shameless, self promotion!!
[Captivate Android Development] jmtheiss:
Congrats to you on mod status, and thanks.
[Captivate Android Development] Woody:
So, like I said the other day, one of my FSM forums (Galaxy Tab 8.9) are having the superbrick EMMC bug and they have narrowed it down to the kernel (sort of).

From what I have read, it sounds eerily similar to ours and it seems to be happening to most Samsung devices. Anyways, while reading through their CM9 thread (troll hunting, muhahaha), I came across this linked post from the Epic 4g thread (Discussion thread for /data EMMC lockup/corruption bug). Beware there are 80 pages going on in that thread. But the post I mentioned can be found here. There is a direct link to CM9/AOKP ROMs and the bug. IIRC, almost all our EU locks have been in some derivative of CM9 or AOKP.?.?

I still think that we need a kernel cook to check out our CWR/Kernels and how they interact. Might be making progress on this after nearly a year's worth of lockups.

Edit::

I would also suggest reading from post 784 to the end. Seems Sammy knows something is wrong. Now just need to see if our chips are included in the "bum" batches. Here is the page, just scroll down a bit to #784.
[Captivate Android Development] s0ul_ali:
"Custom Recovery is responsible for 2 potential bricking points:

1) wipe data/factory reset

2) nandroid backup/restore "

Great work probably EU bug coming to an end. :)
[Captivate Android Development] silvertag:
Post #786 and #790 are interesting. Maybe we could get the persons hit by the EU to check for the eMMC chip version with the GotBrickbug app from post #790.

Mine reports as MAG8DE with Rev 0x16 (EDIT: Never been hit by EU during GB).
[Captivate Android Development] schwick:
Same verdict here. Unknown chip but not on the list of known bad chips.
[Captivate Android Development] TheSchatz:
Mine listed unknown as well
[Captivate Android Development] swayjd:
Yes. 10x. Everyone, hit or not! Would be better if you were hit though, we could start identifying bad chips instead of possible good ones.

Get this app and post your chips!

MAG8DD, used cm9 for about 2 months when I found about this, gingerbread since then. I'm now taking my chances with cm10.

Edit, our chips will probably all be reported as unknown just because the app was made for sgs2 and note afaik. But we can ourselves compile a list.

Edit 2, Disregard, the app reads the external chip for those that are using a workaround. making the exercise futile.
[Captivate Android Development] schwick:
My chip is MAG8DE.
[Captivate Android Development] TheSchatz:
I was hit using a CM9 nightly (don't remember exactly which one, sorry) in early July, iirc

Chip: SU16G

Rev: 0x0
[Captivate Android Development] s0ul_ali:
Got brick bug app started scanning in sd card and it's also showing info of my sd card not unscanable chip.
[Captivate Android Development] greygoose425:
I didn't actually get the EU bug. I got the EU screen, but I never lost my sd card. I was one of the lucky ones that did an immediate battery pull and flashed to stock. My card is MAG8DE date 10/10