yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] UPdownLoAD:
I need an "Idiots Guide" to try to figure out how to "fix" my problem:

I have a Epic Touch that does have the Insane Chip. Every time the screen goes off for more than 10 seconds, the phone is locked up (can't receive incoming calls, PC wont recognize it, no response from power button unless held for 6 seconds which causes phone to restart). I have tried every stock 1 click (usually rooted), as well as all 6 custom PIT files and all result in the same problem.

*side note- took phone apart before researching eMMC problem and ZERO signs of LD. Phone overall is in almost perfect shape)

After reading quite a few threads, I am quite confused on what to do next. From what it looks like I believe I now need to install a custom recovery, scan for bad sectors, and then making a custom PIT to workaround. Is this correct? Is there an "Idiot's Guide" to try to fix this? Thanks!!!
[Samsung Epic 4G Touch] garwynn:
@Shoey,

GB didn't have it because secure erase/trim

didn't exist in code until HC/ICS

. (Courtesy Mr. Sumrall, Google)

Rest of summary is just about right. I'm starting to believe Samsung's claims about the stock recovery wipe - see above info - and also believe JB is patched against this. Just hoping to prove it whenever they drop source for our GS2 variant.

---------- Post added at 11:32 AM ---------- Previous post was at 11:30 AM ----------

If your phone boots and operates normally you have not triggered this bug. You can automatically rule it out.

There's got to be something else going on - recommend posting a new thread in Q&A to see if others can help you get it going.
[Samsung Epic 4G Touch] Formhault:
Ookay... @ garwinn

I give up. Actually, I did so a while ago, but now, I attempted to chime in, again. Nevermind that, though :p

Don't get what's safe and what isn't anymore. Also don't get how one secure erase is dangerous than a non-secure or vice-versa... I thought formatting = replacing every bit with 0. Aaaaaaaanyway... Let's just patch all the kernels from now on so we are SURE Sammy didn't f something up (or leave something dangerous inside, deliberately).
[Samsung Epic 4G Touch] Entropy512:
Formatting = placing a fresh ext4 filesystem structure on the partition. A normal format will leave any data that's there where it is - there will just no longer be anything pointing to those files and they could be overwritten at any time.

Erase = actually erasing the memory cells that contain data. Erased doesn't mean zeros - it means contains NOTHING at all. Flash memory is different from hard drives here. Hard drives can overwrite a sector that contains data as fast as any sector that is empty. Flash requires any sector to be erased before writing. Also, modern flash chips contain a special controller that abstracts many of the internal workings of the chip to make it easier to work with. The bug is with this internal controller - it is prone to failing spectactularly when a secure erase command is sent to it. Samsung claims that a normal erase command is safe but most people are paranoid and so nearly any custom kernel completely blocks any and all erase commands. Samsung's patch only takes secure erase and replaces it with nonsecure erase.
[Samsung Epic 4G Touch] Formhault:
I see. I think I'm starting to get this... unless I'm stating to ultimately fail at it.

Glad to see you here, by the way! :victory:

So... when we wipe a partition, we don't format it - that would mean that we destroy only the links to the existing data that's there... and we would end up having a full eMMC all the time... Or perhaps there's more to this that is beyond my knowledge at this point (I was hoping our "architecture of computational systems" (hope the translation makes sense) teacher would teach us practical things like this in college... perhaps next year... :( ).

So we actually non-secure erase the partition... neither format it, nor secure erase it (which would mean controller going insane)... right?

I think I've read something about this a while back. It was for SSD`s, though, but that's (almost) the same principle of functioning as a phone's eMMC (since it's still flash memory)... When you format / erase a SSD in a specific way (in the way you would do for a standard HDD, if I remember correctly), you risk the chips inside to lose integrity because of its controller - especially if its controller is not created specifically for the types of chips it uses (like crappy OEM`s tend to do). Or something like that. Or... I'm entirely wrong, haha.

Sent from my Galaxy Note
[Samsung Epic 4G Touch] Entropy512:
Not quite. When you choose "Wipe" in CWM, it can happen in a few ways:

Gingerbread and "neutered/safe" ICS recoveries (including kernels with MMC_CAP_ERASE removed): Standard ext4 format. Any data is still there, just not pointed to. This has some small performance impacts once the wear leveller runs out of blocks to work with, but nothing too significant in my experience.

Samsung's own recoveries, or "standard" ICS recoveries combined with Samsung's official patch: "nonsecure" erase of the partition, followed by ext4 format. All data is erased, although if the wear leveller has moved data around from one block to another, old copies of it may exist somewhere.

"Standard" ICS and later recoveries: "Secure" erase of the partition followed by ext4 format. This means that ALL copies of the data are erased, not just the "current" copy for a given block.

Samsung could, in theory, use the "trim" function to erase blocks of flash whenever a file is deleted, in addition to erasing whole partitions when a wipe occurs. This is done using the "discard" mount option to ext4. In fact, this is why they claim they couldn't just remove MMC_CAP_ERASE as a fix - except that NO ICS release I've ever seen used the "discard" mount option for any filesystem.
[Samsung Epic 4G Touch] Formhault:
Ah... that's why they say flash memory gets the "wear effect" every time you format it... now it makes sense.

And, apparently, they didn't change anything in JB neither - at least that's what the JB leaks indicate, at least for the Note...

So, trimming the memory means... whenever a file is deteleted, the blocks of flash it occupied are erased? Not the entire partition? Wikipedia agrees, apparently. I didn't think there are such ways to "format" something...
[Samsung Epic 4G Touch] hg42:
First, my custom pit packages contain far more than 6 patched pits, so which ones do you use?

Then you should use my 'find brick' scanners to determine if you and where you have an emmc brick. Read my pit thread for details (at least the first post, note: it's written for galaxy note, but applies to other models, too).

You may also use the 'check brick bug' app, which has a check button to scan the whole emmc. This is slower than my scanners, but may be more thorough.

If these scans finish successful, you should have a different problem.

---------- Post added at 09:51 AM ---------- Previous post was at 09:44 AM ----------

Entropy512 and others,

what do you think about those 'moving bricks', emmc bricks that constantly change their position (according to start and end of the brick determined by my scanners).

There are many users hit by this kind of emmc brick.

Is there any good theory behind that?

How could this be triggered?

I would like to write a piece of software that tries to stabilize such a brick (I assume some write pattern should fit). May be that's impossible, but I want to try something.
[Samsung Epic 4G Touch] Entropy512:
Probably as the wear leveller does its thing, pointers get shuffled around, and the corrupt structures get pointed to in different situations.

There's no way to stablize "moving bricks" other than: don't write ANYTHING to the MMC, ever. Or completely update its firmware, which is a super-duper-uber-Samsung-secret.
[Samsung Epic 4G Touch] hg42:
I wanted to do the opposite, that is write many many times to the emmc hoping the wear leveler will get a stable configuration (as it is in the standard case).

My own brick first also moved for a time, but then at a point stayed stable.

I already wrote a 'scanner' that writes a file, deletes it, writes again. But this didn't stimulate the wear leveler to move the brick (according to people with a moving brick that used the write scanner).

Now I want to give it another try.
[Samsung Epic 4G Touch] garwynn:
Update: FL24 source - ICS - has dropped for the Sprint Epic 4G Touch (GS2 variant)

Official fix not in this - which we're now not expecting until JB source - so treat as unsafe and continue to make necessary modifications to render safe.
[Samsung Epic 4G Touch] Entropy512:
you have GOT to be kidding me.

"working hard" on Superbrick was obviously a pile of PR bull****. They've been sitting on this patch for months now.
[Samsung Epic 4G Touch] garwynn:
I'd say I'm surprised but I'm honestly not. At this point it looks like they've switched eMMCs on newer boards (of this model) and if i9100 HKG source holds it will be patched in JB. In the meantime the community was left high and dry for over a year... only to have folks like yourself, Chainfire, hg42 and others to take the extraordinary steps to protect the community as much as possible against the effects. Wish I could say all others were as fortunate... have heard GS2 variants will get JB but I haven't heard much on the GN(1) side.

Still would love an explanation why they held it to JB - time constraints? Easier code merges? Now that I can compile the kernel one thing I'd love to do is see how hard it is to implement their "official" solution on ICS and see how difficult it is/was to do so.
[Samsung Epic 4G Touch] Formhault:
Don't worry about us, GN(1) users. We've got the brickbug patched... What we don't have patched is the FREAKING BLACK CLIPPING on which some Sammy devs claimed 3 months ago to be working on, and failed to provide information regarding progress a few days ago. If they're unable to fix some gamma levels... I doubt they're able to find workarounds for bad chips :) .
[Samsung Epic 4G Touch] t_galownia:
ok so here's the deal. LOL

being so far behind the curve I got the T699 Relay around Oct. was following many threads as it was a bit difficult to follw with all the "sub threads and links to others :) ( Not a complaint mind you." Thank you allot XDA for the help thus far I have learned alot. However I am still young grasshopper in training who knows enough to be dangerous but doesn't know enough to always get out of jam he put himself into. LOL

/data won't unmount and /sdcard won;t mount. not sure how I managed that one but I am sure it was in my confusion as one thread said on thing and the development kept growing. So all through my soft brick experience I was never able to find a pit. my computer still for some reason won't work with some of the tools provided or noted in threads and due to this needing to get fixed haven't been able to builid stable linux development 'puter. I am in need of the following as I believe I know what I need to do but I also think an order of operations is coming in to play. :)

1. finish any CM9 adjustments per and see if I can't get in back in Zip format LOL :)

2. 1 pit for T696 ( I have the stock rom however my extracting tools will only go so far, so far. :)

Then ultimately

3. Adjust partioning of the SD Card per responses and then Apply Pit

3a. which tool to best for partitioning SD. I already formated a 16G I beleive half fat 32 and half ext4.

4. I already have two CM 9's both same . ( However I unzipped one to fix the VoldFstab file so I don't have to at after it is intsalled. Is there anytthing else I need to change while it is in work able fashion. (outside of the img's that is LOL)

5. Flash the ROM in Odin and pray I didn't muck it up again. :)

Does that sound about complete? :)
[Samsung Epic 4G Touch] garwynn:
Okay.... Let's start from the beginning.

1) Does your phone boot and operate?

2) Does it freeze requiring a battery pull

3) What is your eMMC model #? (You can get this from apps like Got BrickBug)

If #1 is yes or #2 is no you can automatically rule out the eMMC bug being triggered and it's something else. #3 will tell you if the model (SGH-T699) is susceptible.

For your PIT file, easiest way is to have someone download Heimdall and pull the PIT file that way. Will suggest someone do it as close to stock as possible.

If you're having issues I suggest you work with someone to get the PIT file via Heimdall and then use that with Odin and a stock TAR to try and give your phone as much of a "clean slate" if possible. Saw the links here for those:

http://xdaforums.com/showpost.php?p=34757617&postcount=27

Once you get stock working as it should then try doing it in another ROM. If it's not working in stock then there may be something else at play. From there it's just a process of eliminating changes until you find what did it.
[Samsung Epic 4G Touch] t_galownia:
1. Yes the phone boots up and everything is 100% functional.

2. No the phone doesn't require battery pull except for the normal out of the blue anamoly.

3. No freezes require battery pull.

4. Apexqtmo

I didn't think it was the bug perse' <sp>, however many of the same symptoms are occuring here.

/data only has /media under it and that is empty.

Correction in recovery /data will mount however it will not unmount.

skipping execution of extended command. File not found

Cant partition non v fat data/media

Cant partition unsafe device /dev/block/mmcblk1p1 - this occurs twice when trying to mount /sdcard

cant format unknown volume emmc - this occurs twice when trying to mount /sdcard
[Samsung Epic 4G Touch] t_galownia:
I should be seeing an actual emmc folder on the T699 Relay correct? when I do a search it doesn't come up with results
[Samsung Epic 4G Touch] UPdownLoAD:
If my Epic Touch's screen goes off, it "freezes" and will not respond to even plugging in the charger. I hold the power button down for 4 seconds and the phone will reboot.

I ran the eMMC Check program and it says as follows:

eMMC chip

Type: MAG4FA

Date 12/2011

CID: 1501004d41473446411956d67be1ce7b

FwRev:0x19

Brick Bug?

YES. Insane chip

When running the memory test within it, it says:

Congratulations. Test Passed.

414s

15758000128 bytes (14.7GB) 36.5MB/s

Currently, I am running stock recovery and using GA10 One-click rooted. I have also tried to "brick" it by wiping in recovery and within Android with no different results. I have some time this weekend to work with it, so please let me know what you suggest doing next. Thanks!! :fingers-crossed:
[Samsung Epic 4G Touch] evilsanta2:
Did you figure this out? I seem to be having a similar problem with my I9100. Freezing requiring holding power button down to reboot.
[Samsung Epic 4G Touch] garwynn:
Honestly need a logcat to diagnose further.
[Samsung Epic 4G Touch] t_galownia:
Ok. so phone is working however /data doesn't unmount still and /sdcard will not mount. Galaxy 'Relay' doesn't have the emmc bug however has all the symptoms of. (not sure what i did however i am think it may be from using two different Odin's (as I got confused between two diferent threads, if that is not the case please let me know they were 3.04 and 3.07. I still have been unable to find a pit for the Relay.I have the app that i can move the mounts but not sure if that will correct nor where to move them. I have also noticed the "emmc" block is actually mounted on a 'Fuse' can anyone give me guidane on what my next step should be? phone is working so far as I can tell nothing is broken however i run out of space with very few apps.
[Samsung Epic 4G Touch] Rila:
Hi

I have 2 questions:

I buy an SGS2 i9100 international which came with stock 4.0.4 from Orange Romania BVLPH in November. The phone is manufactured in October, I think. The eMMC chip is V3U00M and revision is 0xE Do you believe that it still has the bug after all this mess?

I mean is logically that new released phone to be immune to the eMMC bug but I expect Samsung to protect themselves and manufacture phones without this bug after they found it.

Second questions is: You write somewhere (I don't remember where I read it) that that the code which do the mess is still out there in some CWM.zip. I root my phone using an CWM update signed and after that I installed SU and Busybox (I followed this thread: http://xdaforums.com/showthread.php?t=1501719) so basicaly I didn't write a kernel but only the CWM. That could have the same efect like a kernel with CWM?

Let me ref-raze The bad command which do the mess is in the kernel or in the CWM ?

Thank you in advance for your explanation.
[Samsung Epic 4G Touch] Entropy512:
You need three things: Defective flash chip, kernel that allows MMC erase commands through, and a recovery that attempts to do a secure erase.

V3U00M is an unknown chip, but so far, it is believed to be safe. No guarantees.

There are some CWM releases out there that have secure erase disabled, but if you're unsure, I suggest flashing a custom kernel that has MMC_CAP_ERASE removed, which will render the device safe regardless of whether CWM is dangerous or not.
[Samsung Epic 4G Touch] Desparoux:
emmc check bug freezes at 1gb

my information this im a victim of brick monster when i start check it stops at 1 gb actually freezes what to do ? and my phone always freeze even if i don't do check bug checking

youtube video check please

http://www.youtube.com/watch?v=G_soO0cX2R0
[Samsung Epic 4G Touch] shoey63:
Did you do a wipe with CWM.zip on stock ICS and then repartition? If so your emmc is irreparably damaged. Your phone will never be the same again unless you replace MOBO.
[Samsung Epic 4G Touch] Desparoux:
yes exactly i did so becos my phone wasnt going to be same again what should i say to samsung warranty can u offer me a lie i want to get it free if i am lucky
[Samsung Epic 4G Touch] Desparoux:
What should I say to warranty replace my mobo :thumbdown:
[Samsung Epic 4G Touch] garwynn:
Honestly? Tell them that the internal memory had an issue.

They know well about this issue so they hopefully won't give you any problems.

It's technically a manufacturer defect - that's how I've always seen it.

(Software can always change - hardware can't. That's all manufacturer.)

Alternatively, since your phone will start up you can probably get it back to life:

1) Visit hg42's thread and find the PIT file you need based on where it is freezing in the tests.

2) Use said PIT file with a stock restore and restore the system.

3) Take it into service for assistance.
[Samsung Epic 4G Touch] Entropy512:
From the looks of it... motherboard replacement time.

There is currently no available way to repair corrupted eMMCs. There's currently some work being done on I9300 SDS that might lead to an eMMC repair/reset method, but as no Exynos 4210 device can be emergency-booted from external SD or USB due to lack of a properly signed EBL for 4210, 4210 devices (basically, anything that is Superbricked) will remain screwed without JTAG.

Right now JTAG will not repair the damage, but there is now a small bit of hope (<10%) that a way to fix these chips will be figured out without assistance from Samsung.
[Samsung Epic 4G Touch] Rawi666:
I've just downloaded i9100_JB_Opensource and in drivers/mmc/host/sdhci.c and mshci.c I can see the following line:

mmc->caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE;

Does this mean Samsung haven't fixed brick-bug yet in the latest sources?

Or have they fixed it in somewhere else?
[Samsung Epic 4G Touch] Desparoux:
So how those people fix their phones by hg42 s method or they have different situation I'm using revolt 3. 1 now no freezing so far also not going to have checking cos when I did brick scan star it started freeze at 1000 something mb and end brick scan 2000 something I also did forhead method it found no bad block I don't know what's my situation or hard to understand you can u put last dot about my phone sorry for being annoying
[Samsung Epic 4G Touch] Entropy512:
As covered earlier in this thread, they fixed it in another manner.
[Samsung Epic 4G Touch] Mattix724:
Any news from Adam Outler regarding the work he wanted to do with an unbrickable mod?
[Samsung Epic 4G Touch] Entropy512:
He has had success on Exynos 4412 devices due to one of the ODROID releases leaking an unsigned EBL for 4412. (Similar to how one of the ODROID releases leaked critical components for Exynos 3110, aka Hummingbird, for the original Unbrickable mod.)

4210 users are still "****ed without JTAG" due to lacking critical components for Exynos 4210.

All Exynos devices have a locked bootloader at the hardware level - we're just lucky that:

1) Samsung drops security early on in the chain of trust, so as far as a user knows, they have an "unlocked bootloader" - The first parts of the boot chain are locked, but those parts don't perform signature checks of anything later on in the boot sequence.

2) All devices of a particular subvariant seem to always share the same root key. e.g. all 4412s seen so far use the same root key, all 3110s seem to share a key with each other. We just don't have the components we need for 4210.

There has been some new developments in understanding Samsung eMMCs thanks to the I9300 SDS fiasco - such that it is starting to look like a way of resetting fubared eMMCs may be possible. (Well, we've always known it was POSSIBLE, we just didn't know HOW). However, since there is no way other than JTAG to boot 4210 devices with a hosed bootloader, this method won't be of much use except for by JTAG houses like mobiletechvideos. (No, the method doesn't exist YET. But there have been promising discoveries recently. No guarantees any of this **** will pan out though.)
[Samsung Epic 4G Touch] carlo67:
hi

i have the p6800

it won't let me to install the eMMC Brickbug Check on pa2.55
[Samsung Epic 4G Touch] leaderbuilder:
How about trying here http://xdaforums.com/forumdisplay.php?f=1482
[Samsung Epic 4G Touch] V3TTOO:
Is this still a concern?

I was hesitant in running any non official firmware due to this bug, but I jumped in with 4.1.2 leak: http://www.sxtpdevelopers.com/showthread.php?t=166

I did a factory reset in the settings, and it rebooted. I thought this should have caused the bug, since I do have it according to eMMC BrickBug app. Now, I am just starting all this since I stopped once I saw it was able to brick a few months back, so I don't know if future leaks had this issue fixed. But even in the link above, it says not to use restore. Am I missing something, or was I just lucky?

Update, I also did a factory reset in recovery mode and it is all working. Sorry if it was answered before, but I do not see any info about it on any OP or last few pages of some posts. This is strictly out of curiosity, but maybe it shows it has been fixed?
[Samsung Epic 4G Touch] TrayLunch:
You're lucky... and, I don't mean any offense, but I don't know how else to say this, a bit misguided. Custom kernels are generally the safe ones. Official ones are not. The eMMC bug is funny in that it is not predictable. It won't brick your phone every time. It could happen the first time, or it may not happen til the hundredth time. Factory resets and restores are the way to do it, so if your goal is to trigger the bug, you're on the right path. :thumbup: If it isn't, then I would change your practices immediately. They are not safe.

Bugging up my phone, so you don't have to!

Need help? XDA.Tray@gmail.com on GTalk or by Email
[Samsung Epic 4G Touch] V3TTOO:
Great, thank you for the information. That is what I was hoping to find out. I was "trying" to brick it, since it is my work phone, I can get it replaced. I was just seeing it it would brick, not that I want it to brick. It was a test, but now I know. I am not planning on putting any custom recovery, so I will leave it as is, without restoring from now on. I will do it through an ODIN install later.
[Samsung Epic 4G Touch] garwynn:
Actually we're hoping that JB source will verify that the official fix is in. Just need source to prove without a doubt.
[Samsung Epic 4G Touch] V3TTOO:
Yeah, I was wondering if that is what I had stumbled upon when my phone didn't brick. I am probably wrong, but I thought I read that the problems was going from ICS to GB or something like that. Anyways, I am happily working on my S2.