yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] sfhub:
Actually I did research that statement earlier when looking at the pathways to mmc_erase()

Our GB kernel's init.rc does mount /data with the discard option however they removed the discard option in the leaked ICS releases' init.rc so I didn't mention it as a pathway in ICS (for our phone)
[Samsung Epic 4G Touch] Entropy512:
BTW - I ran some tests that indicate that Samsung's XXLPY update for the GT-N7000 definitely has ALL of the prerequisites.

We know nearly all devices have VYL00M fwrev 0x19

We know the kernel has MMC_CAP_ERASE enabled

http://xdaforums.com/showpost.php?p=26897429&postcount=148 shows that their stock recovery tries to issue ERASE commands if the kernel allows it.
[Samsung Epic 4G Touch] Entropy512:
Same for I777 - GB kernels mounted with discard, ICS kernels don't.

This is really weird, I need to figure out where in the I777/I9100 Gingerbread kernels the "chain is broken" - we have all three of CONFIG_MMC_DISCARD, CONFIG_MMC_DISCARD_MERGE, and CONFIG_MMC_DISCARD_MOVINAND set.
[Samsung Epic 4G Touch] jgaviota:
sfhub, could you prepare a post with guidelines for kernel developers, kernel repackagers and rom developers so that everyone follows safe procedures?

A good prepared post that could be stickied in all relevant forums?

Thanks
[Samsung Epic 4G Touch] sfhub:
I intended this post to serve that purpose for kernel packagers and rom developers:

http://xdaforums.com/showthread.php?p=26893617#post26893617

As for kernel developers there are a couple of places in the mmc driver it could be patched. Given all the ifdefs in the GB code I was looking at, I was just going to wait until the ICS source for our phone dropped and base it on that. I am not sure, but may have read that ICS source dropped for other GS2s so I could potentially start looking at that.

Entropy probably has a leg up on compiling patched kernels so perhaps he could write that guide right now.
[Samsung Epic 4G Touch] sfhub:
At first I had a theory I was working with that the problem actually isn't with ERASE, TRIM, DISCARD variations of mmc_erase() but with SECDISCARD. The reason I was working on trying to prove/disprove that theory was because I saw that our GB init.rc enabled discard for /data and I figured that meant eventually when files got removed, discard would be called and then eventually mmc_erase() would be called, and since mmc_erase() in GB was already doing erase, trim, and discard and we weren't seeing any mass superbricks, then it stands to reason those functions might actually be fine.

I stopped looking down that path because on our GB kernel we have CONFIG_MMC_DISCARD disabled, and not only does that disable the ioctl() to trigger mmc_erase from user space, but I think I saw it also disabled the discard request code. It was late and I might have looked at it wrong, but if it did disable the discard request code, then I wouldn't be able to prove/disprove anything, so I stopped.

If I had pursued that path though, I would still have to explain if erase, trim, and discard were fine, what would be causing the superbrick in ICS. I actually had a theory to explain that because I noticed the main difference between our GB source tree and the generic ICS tree (in the area we are interested in) was the addition of SECDISCARD or secure discard. This is some erase variation where the EMMC will write a character to memory prior to zeroing it out, kind of like crossing out something before erasing it to make it even harder to read.

This theory also matched up with wipe.c which first tries to do a BLKSECDISCARD and only if that failed would it try to do a BLKDISCARD.

I stress I was NOT able to pursue this theory because of the state of our source tree, but it would kind of make sense. secure discard is some newer function in ICS. erase, trim, and discard (especially erase) are pretty basic functions and it would be surprising if Samsung's QC testing didn't already test those. I could see a bug with secure discard slipping through. This is all pure conjecture so we shouldn't start saying this is known true information.
[Samsung Epic 4G Touch] Entropy512:
mshci.c seems to be all you need - that's what our eMMC is hung off of. sdhci is the external SD card and the SDIO (wifi) port.

mach-nuri has nothing to do with any released device I am aware of. All GS2 and Note Exynos variants are U1/Q1. nuri is ???? (something we've never seen yet)
[Samsung Epic 4G Touch] garwynn:
Don't know if Entropy mentioned but the past few posts have helped him prove that the LPY can brick the Note. Hopefully they'll get that addressed now.

Does anyone have any friends at AT&T who can find out why their Note seems to have the 0x25 revision on the eMMC? I'm still trying to track down that patch as I haven't heard anything back from Mr. Sumrall... just wondering if AT&T has it somewhere.
[Samsung Epic 4G Touch] globalm:
Hi

I am a Note user and have been following this thread with great interest. 'Safe' kernels for the Note, with MMC_CAP_ERASE removed, are now available on Note Android Development, notably Franco Kernel.

We are seeing, perhaps inevitably, a rash of reports of the nature of 'I used this kernel and I bricked anyway'. I don't believe that any of these reports stand up to scrutiny as actually being the eMMC lockout but they are certainly taking up lots of space!

My purpose in posting is to ask if Samsung accept that the bug is not limited to the Touch but is shared by the Note and perhaps other devices and to ask anyone who is in touch with Samsung to make that clear.

Thanks for all the efforts everyone!
[Samsung Epic 4G Touch] MR.change:
Cm9 for the note has a safe kernel so no matter what you do you wont superbrick with it.

I've been using it ever since it was out and must have did tens of nandroid restores with no problems.

What fshub was talking about is the E4GT cm9 not the note's ,you should focus on what you read a bit more.
[Samsung Epic 4G Touch] sfhub:
Sometimes what happens is people flash a bunch of ROMs and those ROM installs replace the kernel but since folks didn't explicitly replace the kernel themselves, they are still under the impression the original kernel they installed is still being used. Not saying that is definitely what is going on with the situations you describe, but it is something to watch out for in the described sequence of how someone arrived at a brick.
[Samsung Epic 4G Touch] sfhub:
Yes, what Mr.change said is accurate.

The CM9 for E4GT uses a leaked stock ICS kernel. This kernel's mmc driver has not yet been modified to prevent mmc erase, thus whether you brick or not is dependent on whether the userspace programs like Recovery and update-binary are asking for the partition to be wiped.

In OUR CM9, the update-binary included in the ROM's update.zip will ask to wipe an ext4 partition prior to creating one using the format() call. Also the install script asks to format("/system").

So we have all the conditions to superbrick

1) susceptible EMMC firmware (all our memory chips are PRV/fwrev 0x19)

2) susceptible kernel (stock leaked ICS which has not been patched to disable mmc erase)

3) susceptible update-binary (OUR CM9 includes the update-binary compiled in an ICS source tree that WILL try to wipe when you format an EXT4 partition)

4) Edify install script (updater-script) which trys to format("/system")

Since the EMMC firmware lockup/superbrick doesn't happen all the time, so it isn't guaranteed you will see it on every E4GT CM9 install, but if you take a large enough sampling you will see it happen.
[Samsung Epic 4G Touch] Entropy512:
The AT&T Note is VERY different from the international version, and it initially shipped MUCH later than the international version.

It seems like Samsung is choosing to continue shipping defective eMMC chips on devices that shipped with them initially, rather than "forward fitting" new manufactured devices. Devices that were released after they found and fixed the problem in fwrev 0x19, however, were shipped with fixed eMMC chips from the get-go.
[Samsung Epic 4G Touch] Entropy512:
Yup. I wouldn't say there have been a "rash" of reports of bricks happening on kernels with MMC_CAP_ERASE disabled, I've seen two so far.

One person flashed the kernel with Mobile Odin and immediately dropped to recovery without verifying that the kernel flashed correctly, then bricked. Two problems with this: 1) There have been numerous reports of Mobile Odin failing to properly flash kernels, leaving the users on the previous kernel (this particular user was on a CWM-repacked stock kernel prior to using MO) and 2) Since the kernel in question (Franco.kernel) was released as a CWM-flashable ZIP, there's a significant chance that even if MO flashed the kernel it was told to flash successfully, the user selected the wrong zImage after manually extracting it from the ZIP.

One person claimed they were on Franco.kernel when they bricked, but didn't state how they flashed it, nor did they verify they didn't have an old revision built before May 25. (Franco released two builds prior to disabling MMC_CAP_ERASE, he made that commit to source on May 25).

However, the following kernels are now running N7000 MMC driver code with the exception of disabling MMC_CAP_ERASE, with no negative reports so far:

My CM9 test kernels for I777 and N7000 posted Thursday evening

CM9 nightly kernels starting with 6/3/2012 for I777, N7000, and I9100

SiyahKernel 3.2.6.4 and above for I9100 (e.g. over a week)

Hardcore's SpeedMod ICS for N7000
[Samsung Epic 4G Touch] MR.change:
how come no one made a kernel with mmc_cap_erase disabled for your device yet?

Why is the note different in that regard?
[Samsung Epic 4G Touch] Mattix724:
Source code?
[Samsung Epic 4G Touch] sfhub:
Most folks are waiting for the source to drop. We've gotten hints our official ICS will be dropping pretty soon and obviously source will then be available.

sbrissen is working on kernel from intl gs2 update4. We are on CDMA so there are always changes on our platform from the intl version.

Even then there are many folks who actually prefer the stock kernel repacks.
[Samsung Epic 4G Touch] Entropy512:
Because the Note is the first device (other than SHW-M250S/K/L) to receive official ICS (and source) that is affected by the bug.

All E4GT ICS releases so far are leaks - no source. And from the sounds of it, their official release (and source) should have the fix.
[Samsung Epic 4G Touch] garwynn:
Just an update - same source is saying that the E4GT fix was also plugged into the SGH-T989 update due out next week. So it might be worth watching for a source drop here as well to see if we can figure out where the fix was made.
[Samsung Epic 4G Touch] Ogy77:
VYL00M - 0x19 And me too have this on my SGSII,is this so bad or not,what soluiton for this is the best or some step dont brick device???
[Samsung Epic 4G Touch] Entropy512:
That's interesting - Has anyone obtained name/cid data from the T989? I guess its significantly earlier release date means that it might have fwrev 0x19, not a newer revision like the I717.

So far, all I9100 leaks, official updates, and custom kernels (except for Siyah 3.1rc6 which was pulled - all other Siyah releases are safe) have MMC_CAP_ERASE disabled in the kernel, which prevents them from triggering the bug.

Please read this thread before posting - all of the prerequisites for danger have been listed and it has been discussed quite thoroughly why all I9100 releases so far (with the one exception listed) have been safe.
[Samsung Epic 4G Touch] sfhub:
Good to hear. I think with the extra time elapsed since we originally expected our official ICS to drop, we will probably end up seeing the fix in the kernel mmc driver, as they would have had more time to review the change.
[Samsung Epic 4G Touch] pachi72:
Aphroditelikesme on Youtube said that CF resolved the problem..is that true?
[Samsung Epic 4G Touch] Mattix724:
Anyone try the FF02 recovery yet to test factory reset?
[Samsung Epic 4G Touch] sol_671:
F#%@ that!!! Lol, I think all the brave souls that did that did it awhile back and already got a replacement and would not do it again.
[Samsung Epic 4G Touch] RainMotorsports:
The only T989 I have seen so far was on 0x13 i believe or it was 12 or 15, it was lower than 0x19 in number.
[Samsung Epic 4G Touch] Entropy512:
No, he only partially worked around it. (See the discussion in this thread about rendering recovery binaries safe on dangerous kernels. Flashing ICS zips with a standard recovery binary is still dangerous.)

What was the part name? fwrev alone is not sufficient.
[Samsung Epic 4G Touch] garwynn:
Minor Update

Well, we've heard unofficially that this was being looked at... now here's something a little more official.

In an attempt to address this by any means available I shot off another email to the Samsung Open Source team a few weeks ago, suggesting that they look at and patch all variations of GS2 and Note kernel code, providing the eMMC details and Mr. Sumrall's suggested solution (skip the mmc_erase() call or replace with a new function writing all zeros.). Didn't hear anything back until this morning.

(REAL IMPORTANT NOTE: I copied/pasted as-is with the exception of removing my personal information. If you see grammar or spelling errors realize that the person writing this is from S. Korea and English is not their primary language.)

So for those of you wanting to make sure they're officially aware and working on it this should answer it finally.
[Samsung Epic 4G Touch] zarthan:
Sfhub

Just a thought as you are talking to devs:

Since there will be remnants of the problems for some time even if this is patched in the release it might be helpful if the various recoveries could test for issues with the update-binary and kernel. Upon boot to recovery the recovery would state it was a SAFE recovery and test the MD5 signature and kernel version before flashing a ROM. Just a thought.
[Samsung Epic 4G Touch] sfhub:
Interesting idea, I'll mention to agat to see if he'd be interested in adding to his recovery. I think the simplest would just be have a table of known safe update-binary MD5s and warn the user of an unknown or known unsafe update-binary. It could be modeled after signature verification, where you can turn it off if you really know you want to install something regardless.
[Samsung Epic 4G Touch] zarthan:
It would make agat's recovery the one to use for sure. I think would be re assuring given all the problems and WARNINGS that accompany every ROM.

I think you have listed the checksum signatures of some of the update-binaries in this thread somewhere. I am assuming that agat's recovery is safe with a GB update-binary and that it would be useful for anyone using this recovery to pull the zip apart and check with the posted checksums??
[Samsung Epic 4G Touch] RainMotorsports:
It was on the list. KYL00M and yeah my bad 0x12. I posted all this in the thread awhile back.

So either the older revisions have it too and non Exynos based devices ARE effected. Or they are chasing ghosts?
[Samsung Epic 4G Touch] garwynn:
The better question for those other devices would be is if people are developing ICS builds for them or not - and if so has anyone seen a rash of bricks on ICS? It also isn't known how long that eMMC controller f/w had the problem before revision 0x19 (if at all), which could be another factor.

Easiest way would probably be to just test it out, but who's going to volunteer such a device?
[Samsung Epic 4G Touch] Entropy512:
There's no good way I am aware of to test a kernel for whether it is dangerous or not. Same for update-binaries.

You could whitelist the md5sum of known good binaries - but the whitelist will quickly grow monstrous and many "OK" binaries may get flagged.

Whitelisting kernels is impossible - too many variations, especially once source gets released for your device. As an example, every GT-N7000, GT-I9100, and SGH-I777 CM9 nightly has a different md5sum for its kernel, as the kernel is built from source as part of the nightly build process and the kernel is tagged with its build date/time.
[Samsung Epic 4G Touch] zarthan:
Like I said it was just a thought and if there was a way to check it would be worthwhile. There should be some way to accomplish this. The offending parts should have some binary evidence/string.
[Samsung Epic 4G Touch] feyrune:
If unsure of the update-binary's source, is it ok to just edit the update script and change the format function calls to delete recursive calls? Or is there more that has to be done to be safe than just editing the text inside the zip file?

Sent from my Epic 4G Touch
[Samsung Epic 4G Touch] sfhub:
Yes, that was the idea, update-binary white/black list rather than kernels.

The place I was thinking on adding it was try_update_binary() where the update-binary is already extracted for you. This would basically be modeled after signature verification (in that user could disable this feature if they REALLY wanted to install something). Also good/bad MD5s of update-binary would be kept in a file for easy edit without recompiles.

We only have a few update-binary executables on our phone that are used by most ROM developers. They don't change that often. All our GB updates had the same update-binary MD5 and I think all the ICS leaks had the same update-binary MD5. They are all listed in the first post under the post that says md5 in the description.

The ability to turn off the white/black list feature would be the catch-all to handle cases where the ROM developer used an unknown/unsafe update-binary.
[Samsung Epic 4G Touch] zarthan:
With all the late night work devs tend to do it is inevitable that someone will grab the wrong one.
[Samsung Epic 4G Touch] MR.change:
Oh well then, I do apologize for asking a stupid question in the first place , but I wasn't aware that the official ICS wasn't out yet for the E4GT

my bad, sorry
[Samsung Epic 4G Touch] Esoteric68:
I'm game.
[Samsung Epic 4G Touch] sfhub:
That is great. I'll be around in case there are any questions.
[Samsung Epic 4G Touch] Esoteric68:
After the reboot to CM9 on step 3 I may or may not be stuck. No brick just the CM9 boot animation is going for a longggggg time. Should I let it ride or pull the battery? I'm content to wait it out if needed.
[Samsung Epic 4G Touch] sfhub:
Did you flash the CM9a5 kernel, step 3d? CM9a5 won't boot with AGAT's kernel/CWM in place. It needs its own kernel.
[Samsung Epic 4G Touch] Esoteric68:
OMG Could XDA have chosen a worse time to go down? lol

Okay *deep breath* yes, I flashed the update kernel and this is the message I got.

assert failed: package_extract_file("zImage", "/tmp/zImage")

E:Error in /sdcard/update-kernel-CM9a5.zip

(Status 7)

Installation aborted

So thinking maybe I had a bad download I popped my sdcard out of the phone and re-downloaded the update kernel, went through the steps in #3 again and got the same message when I flashed the update kernel.

I wasn't supposed to extract the zImage myself, was I?

I'm currently chilling on CM9 while waiting for this forum to come back up.

So where do I go from here?
[Samsung Epic 4G Touch] sfhub:
EDIT: I figured out what was wrong with the kernel flash. I renamed the zImage by mistake. Will fix in a moment.

I would just reflash the full CM9 for now, while I figure out why that kernel flash failed.

Basically skip 3 and goto 4.
[Samsung Epic 4G Touch] Esoteric68:
Okay so then I'll wait lol
[Samsung Epic 4G Touch] sfhub:
Ok, please redownload the update-kernel-CM9a5.zip. Sorry about that.
[Samsung Epic 4G Touch] Esoteric68:
Not a problem :)

Will report back, thanks!

Quick update: breezed through step 3 this time with no issues. ::thumbup::

Moving on to step 4.
[Samsung Epic 4G Touch] sfhub:
Collective sigh of relief :)
[Samsung Epic 4G Touch] Esoteric68:
You and me both lol

Okay so I'm waiting for my Nandroid restore to finish, then I'll reboot and see if my changes from 4e stuck.

Will report back shortly. :)

Nandroid restore completed, phone rebooted into CM9, changes I made to home screen (added two apps) present.

Houston we have lift off!
[Samsung Epic 4G Touch] sfhub:
You want to press your luck?

ODIN Agat's recovery, then flash agat's ROM at the bottom of this post:

http://xdaforums.com/showthread.php?t=1694609

Then repeat the test plan from step 1.

I think if that works, we've flashed CM9 enough times, and from different scenarios that it is very likely safe.
[Samsung Epic 4G Touch] Esoteric68:
So insert agat's ROM (tFF02_v0.1.0.zip) into every step where we did the CM9 brickfix? Do I still do the update CM9 kernel or one of his kernels instead?

Or did you just mean flash his ROM to start then repeat the steps over again as they're written?
[Samsung Epic 4G Touch] sfhub:
Nah, essentially do a step 7 where you flash Agat's ROM, so we can get you back to stock to test flashing CM9 when coming from a stock ICS ROM.

Then repeat from step 1 just like it is written.

Mostly this is just going to get another 4 or 5 flashes of CM9 in just to be extra sure we aren't just getting lucky.
[Samsung Epic 4G Touch] Esoteric68:
Gotcha.

Okay, here goes nothin ;)
[Samsung Epic 4G Touch] sfhub:
I just uploaded a BRICKFIX AOKP 37 so if you can at the end, ODIN flash AGAT CWM, and just flash AOKP 37 once so we can know it is safe also.
[Samsung Epic 4G Touch] Esoteric68:
Okay, good timing as I'm just finishing up step 6 for the second go round.
[Samsung Epic 4G Touch] leaderbuilder:
Just got a break and a little late to the excitement here.

Thanks Esoteric68 for being willing to give this a go! And once again thanks to sfhub for the work and being right on top of it. Watching this with excitement. More XDA awesomeness here.
[Samsung Epic 4G Touch] Esoteric68:
Go through steps 1-6 again but with AOKP brickfix and update kernel instead of CM9, yeah?

FYI second set of testing (starting off by flashing Agat's ROM) completed with no troubles.

Will report back after the AOKP series is completed.
[Samsung Epic 4G Touch] sfhub:
If you have the energy to go through the whole set, sure, but I was just going to say flash AOKP BRICKFIXv1 once to make sure it works too (make sure to flash AGAT CWM repack first)

I think if you actually flashed AOKP for the whole test plan, we can be very confident there is no luck involved, as that will be something like 6 flashes of CM9, 3 flashes of AOKP, 3 factory resets, 3 nandroid restores, and 1 flash of mostly stock FF02
[Samsung Epic 4G Touch] Esoteric68:
I'm in the groove, may as well give it one more run through just to be sure.

Will report back shortly (btw I might need new volume and power buttons for my phone when I'm done lol)
[Samsung Epic 4G Touch] sfhub:
I think you already know, but for the Recovery portion, you can use the capacitative buttons.

Up, Down, Back, Select (in left to right order)
[Samsung Epic 4G Touch] Esoteric68:
Thankfully lol

Okay the first flash of AOKP brickfix went fine, so I'm going to continue on down the list and see how it goes.

---------- Post added at 11:33 PM ---------- Previous post was at 11:10 PM ----------

Okay, steps 1-6 completed using the AOKP files. No issues to report. Home screen change was present following the Nandroid restore.

I've never had such a high Odin count lol thank god for the usb jig!
[Samsung Epic 4G Touch] sfhub:
You are awesome. Thanks so much for taking the risk.

Now I'm off to recruit a few more testers to make sure you don't have a super-phone that is immune to bricks.
[Samsung Epic 4G Touch] Esoteric68:
My pleasure :) glad I could help.

I'm going to give my phone (and my brain) some much needed rest now.

Thank you for working so hard on this and good luck with future testing!
[Samsung Epic 4G Touch] robertm2011:
Looks like you guys may have it licked, Congratulations!

Way to go, Esoteric!

I would offer my phone up for testing, but...

Well, I hope y'all understand...
[Samsung Epic 4G Touch] Esoteric68:
Totally understand. Your contribution (sacrifice) is what helped move this thing forward and kept others from bricking during the same process.

Thank you :)
[Samsung Epic 4G Touch] Mattix724:
Sounds like the bug is fixed... I'll have to try flashing with AGAT's FF02 repack.

I figured it was safe to use, but i cant afford a replacement if anything were to happen...