yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] krisqo:
not sure

Ok I hope I can help a little or at least learn a bit more. I got the the EMMC corruption bug, It was after installing stock ICS on my ATT I777. I then attempted to flash CWM with a rooted version of ICS. This is were my trouble began with the corruption, after several days doing what I can I managed to flash Siyah kernel 3.4.3 with odin and used the dual boot function to create the 2nd rom which will boot. This is the only post I have been able to find with excellent information on the issue, and i would like to help anyway I can. I am not good at Linux programming but if someone can walk me through it I will do what ever i can to help.

VYL00M

0X0

0X19

0X000015

0X0100

9/2011

MMC

0X1113410d

15010056594c30304d191113410d9ebb

hope this helps at least a little
[Samsung Epic 4G Touch] Entropy512:
You're toast, and unfortunately since you used CWM, it's hard to blame it on Samsung.

Where the hell did you find a CWM-repacked UCLE5 kernel? Please let me know so I can have the moderators take it down.
[Samsung Epic 4G Touch] krisqo:
Yes

The CWM UCLE5 came after the crash I tried to return to stock with Gingerbread and reflash with the matching CWM Im not sure where i managed to find it. I am thinking thats kind of what help save me tho, after that is when i found out about the SIYAH kernel and it dual booting function, after flashing it in Odin I can now boot and run stablely in the secondary rom, but my primary stays stuck in the boot loop. I don't know if this is a special case or not but, thats why I would like to help if I can. I'm running on a phone with a corrupt EMMC, stably with a secondary rom.

More specs

Android version 4.0.3

baseband version I777UCPLC5

kernel version 3.0.36 Siyah v3.4.3

Build number Phone Bricker v2.5
[Samsung Epic 4G Touch] Entropy512:
I can't tell if it's a special case or not. It doesn't sound like it.

State, clearly, in a step-by-step fashion, what you did BEFORE problems started. All the rambling about the 4279342703294 things you tried that didn't work AFTER problems started are irrelevant.
[Samsung Epic 4G Touch] krisqo:
ok

Ok I started off with a stock gingerbread with root, then I upgraded with samsung kies to the 4.0.3, after that I decided to root and installed the 4.0.3 stock with root. I decided since stock 4.0.3 wasnt anything special I would try a custom rom, so I installed the lasted CWM after installing CWM I attempted to do a backup of the system, while trying to do the backup the phone kept freezing and going into a boot loop afterwords, when I would try to open the boot log it would give the EMMC error, and the CWM screen would be the stock android screen.
[Samsung Epic 4G Touch] Entropy512:
Please state EXACTLY how you installed CWM and where you installed it from (which was my very first question...)
[Samsung Epic 4G Touch] krisqo:
It was installed from the google play store
[Samsung Epic 4G Touch] hakaz:
For info:

We have a 4.0.4 ROM Source at Sammy's OSRC (GT-I9100_ICS_Opensource_Update7.zip) .
[Samsung Epic 4G Touch] Entropy512:
What part of EXACTLY didn't you understand? You can't install CWM from the Play store - it must be flashed along with a custom kernel, or in some cases, certain apps can "fakeflash" it.

When I say "EXACTLY", don't just say "I installed some **** from the Google Play Store and I'm not going to tell you what the hell I installed and what I did with it."

I MEAN EXACTLY. WHAT, EXACTLY, DID YOU INSTALL FROM THE GOOGLE PLAY STORE, AND THEN WHAT THE HELL DID YOU DO WITH WHATEVER YOU INSTALLED? Give a DETAILED description, not worthless answers with no useful information like "I installed something from the Play Store."

BTW, users like you are why Samsung does not believe the reports of some people experiencing damage from stock recovery. When asked exactly what they did they just beat around the bush and don't provide an honest or detailed answer.
[Samsung Epic 4G Touch] Dchibro:
LOL! I can perfectly picture Entropy's face as he was typing out that last post. Hopefully your keyboard survived the onslaught. :D
[Samsung Epic 4G Touch] crazy_4_and1:
This message should be pasted into every discussion/support thread after an dishonest or partial( second or third ) answer to a straight question about chronology and details about the cause of a brick .

Entropy512 made it pretty easy to understand the essence of the problem to me/you/anybody interested in the matter and he NEEDS relevant , ordered (step by step and in chronology ) data to make sense of :

1. Do you actually have a problem that is related to hardbrick caused by eMMC corruption

2. If it is a eMMC caused brick what was it caused by in your individual case ( to know more relevant facts about the reasons and paths that can lead to a brick )

3. The pattern that must exist in this issue for it to be fixable in any way (no exception can exist because then it is not a pattern anymore )

So when he asks me/you/anyone , don't be rude to give irresponsible answers because it is not helping (say you don't know , rather than insisting on a sloppy answer ) .

Maybe a thread should be opened (if it is not already ) with a set of guidelines that explain (step by step ) on how to write a report about a problem that might be related to eMMC brick - something like a log , but manually written following a certain pattern that you (technically better acquainted guys) give us - to avoid confusion and irrelevant answers .

Sorry if I sound naive or stupid , just trying to give ideas or point to a better organisation in solving this .

If it is of any relevance - I have a 0x19 revision chip , I flashed all the stock ROMs (pre June not July built ) I could download in past few days (maybe 10 - 12 ROMs) and on each one I did a factory reset from the menu , a data/cache wipe from stock recovery and a system/data/cache wipe after flashing appropriate Chainfires kernel through CWM that came with it - AN I DID ALL OF THIS AT LEAST TWICE FOR EACH ROM I flashed . All ROMs were ICS ones (4.0.3) because I read that GB did not cause a single case of bricking of this type .
[Samsung Epic 4G Touch] Dchibro:
So some hard bricks started popping up over the weekend, after sbrissen completed a booting JB kernel for the E4GT, and a CM10 ROM ported by Dark Knight2 posted over at Android Central. There are numerous reports of people hard bricking while flashing from what was confirmed as a "safe" ICS kernel+recovery. Some seem to think flashing from a file on internal storage rather than an sdcard is the cause of the brick, but that doesn't pass my common sense test.

Can someone who actually knows something about this stuff (read: not me) download the file and take a look at the update binary to see what might be causing it?

Post: http://forums.androidcentral.com/ep...-jb-07-30-12-cyanogenmod-10-beta-1-a.html#anb
[Samsung Epic 4G Touch] Entropy512:
I'm more interested in what kernel people were claiming was "safe".

I'm not downloading a 140MB file just to check the update-binary. Do:

strings update-binary |grep MMC

Although I can tell you anything built prior to Friday evening will contain a dangerous update-binary due to a mismerge of the MMC wipe protection patch.

Currently, a kernel isn't truly "safe" unless it was built with MMC_CAP_ERASE removed from mshci.c
[Samsung Epic 4G Touch] Dchibro:
Thanks for the reply Entropy. Here is a post example of one of the bricks ...

http://xdaforums.com/showpost.php?p=29394687&postcount=116

http://xdaforums.com/showpost.php?p=29397393&postcount=121

The second post included the exact kernel, which is chris41g's RC1-b3 kernel repacked with CWM6.

Kernel link: http://xdaforums.com/showthread.php?t=1781939

The RC1-b3 kernel was actually listed as the recommended kernel+recovery to use to the flash the JB ROM Port, which was later pulled after the brick reports. The guy who's post I linked above said he may have bricked because the ROM was being flashed from internal storage rather than external. I'm skeptical on that one, as little as I really know about this stuff. I think it was just coincidence that he flashed successfully from the ext sd, then bricked when flashing from internal sd, as we know the emmc brick bug is random and doesn't always occur.

In the end, as in most cases, this probably isn't enough information to go on. So many varying reports and differing variables involved. But I doubt there is something wrong with chris' kernel. The guy knows his stuff. I just wonder if it was some freak combination of his kernel and this CM10 ROM port.
[Samsung Epic 4G Touch] Entropy512:
Not safe - https://github.com/EpicAOSP/android...touch/blob/ics/drivers/mmc/host/mshci.c#L2039

As of the time of this posting, if that is his source code, MMC_CAP_ERASE is enabled in mshci.c
[Samsung Epic 4G Touch] Dchibro:
Thank you very much for checking it out.
[Samsung Epic 4G Touch] weboide:
This is from one of chris41g's kernel zip.

warning: %s: Wipe via secure discard suppressed due to bug in EMMC firmware
emmc
/proc/emmc
/dev/block/mmc
/dev/block/mmcblk0
EMMC
EMMC:
failed to open emmc partition "%s": %s

Is the first line what Im looking for in a safe update-binary?

---------- Post added at 08:19 AM ---------- Previous post was at 08:02 AM ----------

I downloaded the JB port beta 1 from androidcentral.

$ strings ./META-INF/com/google/android/update-binary | grep MMC
EMMC
EMMC:

$ strings ./META-INF/com/google/android/update-binary | grep -i MMC
/proc/emmc
emmc
/dev/block/mmc
/dev/block/mmcblk0
EMMC
EMMC:
failed to open emmc partition "%s": %s

Doesn't look safe?
[Samsung Epic 4G Touch] Entropy512:
Yes.

http://review.cyanogenmod.com/#/c/17326/

My contact at Samsung was wondering why we implemented multiple redundant blocks against wiping - stuff like this is why. Too easy to accidentally break one of the protections.

As to chris's kernel - it was another case of a mismerged patch. :(
[Samsung Epic 4G Touch] vinscuzzy:
Add this one to the list

http://xdaforums.com/showpost.php?p=29475469&postcount=1
[Samsung Epic 4G Touch] weboide:
This really looks like people were really out of luck. Chris's kernel was unsafe due to mismerge, the JB port zip was unsafe as well. Both combined and there's the brick...
[Samsung Epic 4G Touch] jgaviota:
People should also learn to check the zip's update script and replace any formats with delete recursive. :(

A pity that everything bad lined up in this case.
[Samsung Epic 4G Touch] Dchibro:
Yeah a pity indeed, but it can happen. Entropy and sfhub warned about this possibility many weeks ago right in this thread.
[Samsung Epic 4G Touch] Entropy512:
No, just check the update-binary using the strings command to make sure it doesn't wipe when formatting.

Using delete recursive can lead to problems, the filesystem needs to be formatted.
[Samsung Epic 4G Touch] gkahd:
What exactly should the result be for the string command to know it is safe?

For the update-binary I tried, I get

$ strings update-binary |grep MMC

E[COLOR="Red"]MMC[/COLOR]
E[COLOR="red"]MMC[/COLOR]:

And apologies if it has been asked before but the combos are quite a few and new things keep poping up.

What makes a "safe" set?

i.e. "Safe" update-binary + safe kernel? + something else?

is CWM to be somehow checked? or CWM/stock recovery makes no difference?

Thanks
[Samsung Epic 4G Touch] Entropy512:
Hmm, that's interesting and looks like it might be a Gingerbread update-binary (should be safe, but not sure)

What I can tell you is if you see:

warning: %s: Wipe via secure discard failed, used discard instead

when you run strings against an update-binary or recovery, it is DANGEROUS (ok I had the wrong information before since MMC doesn't appear there)

If you see

Wipe via secure discard suppressed due to bug in EMMC firmware

that recovery or update-binary is safe
[Samsung Epic 4G Touch] gkahd:
Thanks for the reply.

Yes indeed it is an updater used by dsixda's kitchen - I usually cook my own ROMs - and I have not done a wipe for months now.

(BTW I am using the Galaxy S2).

So if the updater-binary is safe, what is the next danger? If the kernel is safe I am ok?

Also is the wipe dangerous even if done from within the Andorid OS? i.e. not from recovery?
[Samsung Epic 4G Touch] Joepozz:
chainfire's apk is telling me that my emmc is known as brick bugged. but I flashed some times this week and i dont got wrong kernel (siyah is good one right?) do i have the bug then yes or no?
[Samsung Epic 4G Touch] Entropy512:
Almost all I9100 units have defective MMC - but you also need a recovery that issues secure erase and a kernel that allows it to go through for danger.

Prior to XXLQ5 all I9100 kernels were safe - newer kernels are not.
[Samsung Epic 4G Touch] Joepozz:
Hmm. But, now i don't know if i'm safe or not. Siyah kernel says it got no brickbug in its feature list. I don't realy know can i flash a rom or what can i do and what can't
[Samsung Epic 4G Touch] Entropy512:
Um, how can you not know? You just answered your own question in your post.
[Samsung Epic 4G Touch] Joepozz:
sorry, thanks for your help
[Samsung Epic 4G Touch] hakaz:
Entropy512: Have you got any information about the reason

why

the corruption occurs?

After bricking my I9100 Sammy's service center returned it with replacement board and eMMC Chip version VIS00M dated 04/2012 / FW Rev. 0x09.

Testing the eMMC memory for errors shows an average test speed between 30-35 MB/s instead of about 50 MB/s on the brickable version with FW Rev. 0x19 (which means a remarkable cut-down to 2/3 of original speed). I asked around in other threads for equal findings and experience with the new chip and found only one hint here.

More postings were about replacement with this eMMC chip version after bricking and the oldest manufacturing month I found was 02/2012.

Could it be that Sammy tries to avoid the bricking by cutting down the data speed so a corruption is not longer possible (too many data packets to process in a certain time frame causing a buffer overflow during write cycle - just as a clue)? Cheers.
[Samsung Epic 4G Touch] Mattix724:
I'll be getting my E4GT back from Samsung soon. I'll post back here to with info about the eMMC firmware version and anything else you guys might want to know.
[Samsung Epic 4G Touch] Entropy512:
Most likely that difference is due to some other change in the chip - after all it contains a different part number.

The problem is we don't have a proper "apples to apples" comparison - VYL00M fwrev 0x19 vs. 0x25 in the same device. VYL00M 0x25 is only seen in Galaxy Nexus and AT&T Galaxy Note - and these devices will benchmark differently due to having different CPUs.

If there were a significant write speed difference that would be more interesting - all of the differences are going to be in how the wear leveller writes data and handles erasure of written data. It should have little to no effect on read performance.
[Samsung Epic 4G Touch] hakaz:
Found this hardbrick description in a 4.0.4 thread. According to the writer his SGS2 bricked without doing any wipe just in low battery condition. Symptoms look like hardbrick bug but can be caused by other hw malfunction as well (dead battery?). Cheers.

BTW: on weekend I will have both a brickable SGS2 and mine with replacement board at hands (same build - international version). So it should be possible to make a comparison of internal write speeds.
[Samsung Epic 4G Touch] jboxer:
Yes, they can also brick themselves during low battery shutdown. You should turn the phone off if the battery is low and you are unable to charge it.
[Samsung Epic 4G Touch] hg42:
Hmm, is this related to software or to hardware alone?

Are safe kernels exposed to this problem, too?
[Samsung Epic 4G Touch] hakaz:
The guy I wrote about swears he never had any version of 4.0.4 installed on his SGS2 (read here) so I must assume that hardware alone in low battery condition is enough :(
[Samsung Epic 4G Touch] garwynn:
There was talk about a "sleep of death" that sound similar to that... just the blue light faintly glowing.

But that is a different issue from this.

Sent from my SPH-D710
[Samsung Epic 4G Touch] weboide:
Since a lot of people do not know how to use `strings` and `grep`, or are not techies. I thought it would be a good idea to create a tool that automatically checks for safe/unsafe update-binary's.

It is a very basic tool. Hoping it would be useful. I wanted your guys' opinion and ideas on this.

http://update-binary.codealpha.net/
[Samsung Epic 4G Touch] ChromJ:
it appears that one of my friends has bricked his galaxy note after performing wipes while on cm9.

After the wipes he was still able to enter download mod. I asked him to flash the 4 files rom through odin, after that his phone went completely dead no download, and no recovery mod is possible.

ROM instructions states clearly that cm9 kernels are safe to perform wipes.

Any clues of what may has happened.

thanks
[Samsung Epic 4G Touch] Mattix724:
Which version of CM9?
[Samsung Epic 4G Touch] Entropy512:
"bricked AFTER performing wipes" and "bricked WHILE performing wipes" are completely separate things.

He wiped, his device was working fine, then you asked him to flash something in Odin, then the device was dead - so probably whatever he flashed in Odin was bad.

Bootloaders getting nailed when wiping /data is very rare - A fullblown hardbrick (bootloaders gone) usually only happens when damage occurs during a /system reformat. This is why the term "Superbrick" was coined - A device can still boot but be useless due to /data being cratered, so it's effectively bricked - but it's not a hardbrick, and it's also not a softbrick because it can't be recovered.
[Samsung Epic 4G Touch] sfhub:
I think you are agreeing that with the code as written and the reported values in the kernel, this fix shouldn't be active on your phones. I think you earlier explanation about why our kernel reports fwrev 0x0 is reasonable (ie the kernel is not setting the fwrev value for this revision of memory spec)

I didn't look over the manual decode of the fwrev string yet, but is your thinking that the person who wrote the code put 0x25 because they took a decimal and entered it in as hex by accident? I guess that is possible, but even if they entered it in as 0x19, it still wouldn't allow our fwrev 0x0 (even if the kernel didn't parse the fwrev correctly, that is what it thinks we are at internally) to trigger the patch code.

Also I saw they had some debug print statements to verify the fix was triggered as they appear to read back the values they tried to set, so presumably they tested this and saw the print statements give them the expected values.
[Samsung Epic 4G Touch] robertm2011:
OK, here 'tis:

Start- running sfhub's SPH-D710.FE07 stock rom, FE07 modem and FE07 Plus kernel.

ODINed FE07 repack - flashed Calk's format_all - flashed Calk's 1.5 - reboot...

OK.

ODINed FE07 repack - flashed Calk's format_all - flashed AOKP Build 35 - flashed GAPPs 20120429 (didn't stick) - reboot...

OK

ODINed FE07 repack - flashed GAPPs 20120429 3 times (it took) - reboot...

OK

no problems (knocking on wood now - repeat).:)
[Samsung Epic 4G Touch] garwynn:
Yes to first paragraph. Second one I sent to Mr. Sumrall for clarification. No response yet. It certainly is possible that this may not apply... But if testing indicates something did change it may prove that I am still misunderstanding something in the code. (Also a possibility)

Didn't get the fwrev because I was reading the string left to right. Forgot that bit offsets in C go opposite way. Finding the serial was the giveaway, could easily follow after that. Tried same with CSD but think eMMCs use the extended version instead. (Wanted to find out how it populated the structure.)
[Samsung Epic 4G Touch] garwynn:
*Edit* Installed FE10, no change on cid or fwrev.
[Samsung Epic 4G Touch] sfhub:
FE10 repacks added to Resources section.

So far nobody has reported any /data EMMC corruption with unlocked stock recovery.

Can folks do some wipe data/factory resets also? Make sure you do it right after flashing FE07 / FE10 repack in ODIN so you are assured you are using the right kernel, otherwise it can get confusing and you might use the kernel that came with the ROM you flashed.
[Samsung Epic 4G Touch] azyouthinkeyeiz:
Will get on that when I get home tonight.
[Samsung Epic 4G Touch] robertm2011:
Ditto.
[Samsung Epic 4G Touch] garwynn:
Today's Update

Not much today, at least so far. Waiting on response from Mr. Sumrall regarding the 3 questions we had:

1) Why fwrev is not pulling correctly (yet should be in source so far as we know)

2) Could 0x25 be a bug in the cid_rev parms? If it is supposed to be decimal it would put us in play - if not and we can rule out program bug then we can fairly certainly close the door that this bug affects us.

3) If this is still file system corruption only why is it not repairable? (Believe it is exclusive to eMMC - maybe firmware/driver lack of support - but would like to get something more if possible.)

In addition I'm hoping the invitation sent to MobileTechVideos.com will be accepted. As he has been involved both in previous discussions and his work it would be great to get he and any others with JTAG experience to give their feedback on Mr. Sumrall's remarks.

I'm very interested in the testing results so far and will be even more interested to follow this when possible over the weekend. If it turns out that something did change and the bricks are being avoided, I would really like to know why before the community starts thinking it's okay again.
[Samsung Epic 4G Touch] sfhub:
I probably would have phrased this as why couldn't a repartition and reformat make the EMMC usable again. Repairable could imply that we are asking for the original data prior to corruption to be restored and allowing the user to continue as if nothing happened.

Keep in mind we are using stock recovery, compiled by Samsung, presumably in an ICS build environment, right now. If it works out, we can expand to CWM or CWM-Rogue. Hopefully the results are the same.
[Samsung Epic 4G Touch] zonlicht:
It seems that the good people from Galaxy Note is also experiencing our EMMC hardbrick with ICS leak.

http://www.reddit.com/r/Android/comments/tibt5/heads_up_superbrick_bug_present_in_ics_leaks_for/
[Samsung Epic 4G Touch] Esoteric68:
If I remember from my testing the other night it's just the repack, not the plus right?
[Samsung Epic 4G Touch] sfhub:
Yes, the unlocked version has only one change, the recovery.

Although I think Plus would have the same effect for testing as the other changes are unrelated, I'd like to stay disciplined, so if something should go wrong, we definitely know nothing else was involved.
[Samsung Epic 4G Touch] sfhub:
There is some theory about the bug from Entropy here:

http://xdaforums.com/showthread.php?p=25385420#post25385420

I didn't read the whole thread so don't know if this information was later reconfirmed or contradicted.

More info here:

http://xdaforums.com/showthread.php?p=25500497#post25500497
[Samsung Epic 4G Touch] Esoteric68:
Gotcha, thanks! I'll report back shortly.
[Samsung Epic 4G Touch] robertm2011:
Start:

Running SPH-D710.FE10 stock rom, FE10 modem, FE10 repack plus.

ODINed FE07 repack - flashed wipe data/factory reset - flashed Calk's 1.5 - reboot...

OK

ODINed FE07 repack - flashed wipe data/factory reset - flashed AOKP Build 35 - flashed GAPPs 20120429 (didn't stick) - reboot...

OK

ODINed FE07 repack - flashed wipe data/factory reset - flashed AOKP Build 35 - flashed GAPPs 20120429 3 times - reboot...

black screen, blue light; won't boot into ODIN mode. Pulled battery, waited 15 minutes, black screen, blue light; won't boot at all, looks like I bricked.