yashsingh1/xdaforums huggingface dataset:
[Galaxy Note GT-N7000 General] adv1sory:
Lol i knew you would. OCD kicking in.
[Galaxy Note GT-N7000 General] raagavak:
but what happens to the users who have already bricked their phone with warranty void root installation. i dont think the bricking is caused because of rooting , it is only because of factory reset/wipe data
[Galaxy Note GT-N7000 General] sangalaviral:
This is the basic reason samsung is using someone else to spreas news of owning up and fixing the bug.

If they themself post and own the bug they have return money and there reputation suffers.
[Galaxy Note GT-N7000 General] devonblue4u:
I had 2 motherboards bricked going from eclair to froyo on the original I9000M. Samsung is accustom to letting the end user be a part of their "R&D", no matter what it costs them (I mean us...). I Think I'm sitting ICS out for a month after the official release, until the smoke clears.
[Galaxy Note GT-N7000 General] androidindian:
Updated OP
[Galaxy Note GT-N7000 General] olivespin:
Flashed to official ICS and now its buggy and hangs my phone.

I wana reinstall ICS, will it cause 2 activate Emmc bug ?

I created a thread specifically for it, plz help me:

http://xdaforums.com/showthread.php?p=27212457#post27212457
[Galaxy Note GT-N7000 General] androidindian:
Also, to check whether you have a brick bug, Download this app from chainfire: http://xdaforums.com/showthread.php?t=1693704
[Galaxy Note GT-N7000 General] musashiro:
wow, they are recognizing custom roms as well...

good job Sammy..
[Galaxy Note GT-N7000 General] berserkrico:
Finally, a official response from Sammy. Hopefully we'll have this fix in our custom ROMS's anytime soon as well! Can't wait!
[Galaxy Note GT-N7000 General] arifaziz@msn.com:
Will this expected solution by samsung be able to fix my already bricked note?
[Galaxy Note GT-N7000 General] faisal:
Other than LPY (the German ICS which was released first), is there ANY instance of a stock ICS rom getting bricked when STOCK wipe or hard reset was done?

From what I can tell after trying to read through pages and pages of various threads on this issue, the instances that seem to be quoted are where someone used CWM recovery to wipe.

To me it seems that

ICS (stock or leaked) + CWM recovery + wipe = possibility of a brick
[Galaxy Note GT-N7000 General] dbreloaded:
Well if you want to take the risk then that is your own decision. Personally i would not XD Its caused by a bugged command being issued when being wiped, which the ICS kernel permits to go through. To my understanding CWM does not cause this bug its just more people are likely to wipe if they have CWM (whats the point in having CWM if not wipe/flash?) So you see its not that CWM causes the problem its just that people with CWM are more likely to wipe. Wait a couple weeks and a fixed firmware will be issued.

It seems to me that -

ICS + FAULTY EMMC COMAND = KERNEL PERMITS COMMAND = POSSIBLE BRICK

Alternatively:

GB + FAULTY EMMC COMAND = KERNEL DOES NOT PERMIT COMMAND = NO BRICK
[Galaxy Note GT-N7000 General] M3TALLICA:
So, is Samsung working on a workaround or next update would permanently fix eMMC (upgrade it to safe version) ?
[Galaxy Note GT-N7000 General] faisal:
Thank you for your considered reply. Some clarifications..

1. I have not taken the risk of wiping while on ICS (I am on ZSLPF, rooted, via temporary CWM) nor am I proposing that anyone should. I fully agree that we all wait for a proper solution.

2. I agree that the statistical odds of those with CWM using wipe are higher - BUT - the total number of those with an official stock ROM (obtained OTA or via PC Odin or Kies) is a much bigger population and to expect that not ONE of them hard reset their devices after the upgrade or wiped via the stock recovery doesn't seem right. Unless none of them are reporting this out here and quietly taking their devices to Samsung. Possible but still a bit odd...

3. The heightened state of anxiety of "sitting on a volcano" has caused some people on ICS to take uncharted and risky paths to revert back to GB, thus causing more problems.

My two cents...
[Galaxy Note GT-N7000 General] joe2316:
@Faisal

You need to appreciate that the population on xda are mostly rooters, tinkerers and general vagabonds ;-) so you will understand that others might not even be aware of it's existence. An example, my colleague bought a Gnote after seeing mine but has no interest in rooting or ICS, he's just pleased as it is. My wonderful wife has a Gnote too (I copied her!) and although she is rooted purely for Adblocking, has no interest in ICS either. So of these 3 note users, 66% will not even upgrade to ICS as they see no need to.

I imagine most undemanding users will just flash in place, let it run and not even know about stock recovery/hard wipe, so never trigger the conditions. Let's see if this continues for the next 2-3 months when more stock ICS people need a hard wipe.
[Galaxy Note GT-N7000 General] KaranKapoor:
So it possible that Samsung will only release a Kernel without the call to the eMMC erase function and not release a solution for those who have already bricked their phones?
[Galaxy Note GT-N7000 General] jeriz:
I have a job where i meet new people on a daily basis and get to talk to them on average 3h. Being an android fan smartphones are always mentioned.

less than 1% have had their phone rooted and of that less than 1% more than half had a friend root their phone to get rid of ads.

A factory reset falls almost in the same category as rooting you have to be an advanced user so I'm guessing no more than 5% made factory resets.

there hasn't been a massive brick report flood so I'm guessing that the brick bug doesn't occur in more than 1 to 2% of factory rests that means about 3000 to 7000 factory reset bricks not to bad considering 7 million sold.

none of which will be reported on xda cuz xda people wipe.

So in my opinion this is a real bug but it mostly affect the advanced users and Samsung could probably ignore it and still be in the money and money is everything these days so I'm actually surprised that they are working on a solution... Don't really have a point whit this rant... Just airing my opinion I guess

Ps all numbers where pulled out my ass don't give them any scientific value
[Galaxy Note GT-N7000 General] PoisonWolf:
I wish reinbeau could come in here and start deleting posts that are spreading potentially dangerous information, telling people it is safe to wipe.... Despite the clear instructions from Google..... Sigh. Some people are just appalling.
[Galaxy Note GT-N7000 General] prasad.adam:
I would rather err on the side of caution than repent later. Given the intermittent nature of the issue, it is safe to assume that all stock ICS wipes are potentially dangerous, non-rooted notwithstanding.
[Galaxy Note GT-N7000 General] porcusor:
It's almost impossible to revive a bricked Note. The only way is changing the mobo through their service centre.

Samsung will most likely release a safe kernel, rather than an updated emmc fw, the latter being a proper fix.
[Galaxy Note GT-N7000 General] chasmodo:
Touche.:)
[Galaxy Note GT-N7000 General] SpyderTracks:
The fact youve clearly stated, there is no issue wiping from stock roms in many different posts kinda leaves your last post dead in the water. Dont advise on stuff you aint got a clue about!

Those guys have been in constant talks with GOOGLE AND SAMSUNG developers since then. Its a recongnised issue, face facts and shut the hell up with your poison!

Reported, you've had enough chances.
[Galaxy Note GT-N7000 General] SpyderTracks:
I totally agree with this, they'll limit the emmc erase command rather than address the firmware issue.
[Galaxy Note GT-N7000 General] dbreloaded:
What you need to remember is that people use this forum to obtain reliable information. Currently reliable sources are advising that there is a problem effecting wiping in all stock ICS releases and say not to wipe the phone.

Your advice is in direct contradiction to what the experts are saying. XDA has good search features and has good Google SEO. Your contradictory advice may be what new users find first and they may follow it and could brick their phones.

Can you guarantee that they will not brick their phones when wiping if unrooted? What is your evidence to support this?

The fact is that the experts say it could effect unrooted stock ICS roms and that means someone could read your advice, think they are OK and brick their phones.

Dont get me wrong if you can provide believable evidence that not one person with stock unrooted ICS has bricked their phones in this manner then I will be over the moon and you will have found a temporary and safe solution for those who want ICS.

And btw I am on stock LQ2 rooted via DR Keetan's method and I have wiped using recovery BEFORE I READ THE POSTS (it was on day of release of ICS) and my device was fine. After reading the situation I WOULD NOT WIPE MY PHONE! Even if i was unrooted I WOULD NOT WIPE IT!
[Galaxy Note GT-N7000 General] Entropy512:
I'm waiting to see what this "fix for custom firmware" is they're claiming to provide and how it is an improvement over what we already have.

Unless they provide a method for repairing damage already done - we already know how to prevent kernels and recoveries from triggering this bug.

For kernels, disabling MMC_CAP_ERASE in drivers/mmc/host/mshci.c works and has been proven by two months of user of the I9100 update4 source base, and by explicit removal of it from the GT-N7000 Update3 source code.

In addition there is being work done to make recoveries/update-binaries safer for use with affected kernels such as http://review.cyanogenmod.com/#/c/17326/ - This will, for example, allow safely flashing CM9 even from an affected kernel.

Obviously, a fix for stock binaries so they don't do damage will be great, although it looks like that could take time.

As mentioned in my post which is linked to from the OP of the Got Brickbug? app thread - To be in danger you need three things:

1) Recovery that issues ERASE commands (Most ICS recoveries do, most GB recoveries don't) or an update-binary in a ZIP you're flashing that does

2) Kernel that allows ERASE commands through (we know how to protect devices by disabling this)

3) A defective flash chip.
[Galaxy Note GT-N7000 General] dbreloaded:
When you say "defective flash chip" does that mean it is a hardware problem?
[Galaxy Note GT-N7000 General] Entropy512:
So far, I have yet to see any indication that we'll be getting any information on a recovery methodology for damaged device. I hope I'm wrong. The information required to update the eMMC chip and perform a low level wipe appears to be something that Samsung considers to be highly proprietary. I really hope I'm wrong and Samsung decides to make things right in this case, I'm now in contact with someone at Samsung and I'm pushing for this as it's really the only thing (other than safe stock binaries) we need from Samsung right now.
[Galaxy Note GT-N7000 General] Entropy512:
The thing is, Samsung's internal communications is obviously poor.

Some of the XDA developers are in touch with a contact in Korea, but first-line tech support may be still completely unaware of the situation.

I'm guessing it's how we got into this mess - the team working with Google on the GNex didn't talk to the teams for any other device, and the team working on the I9100 kernels somehow found out and rendered their device safe without telling any of the other kernel development teams. Either that or they have no proper code review process and MMC_CAP_ERASE was allowed to make its way back into their kernels after the I9100 source branched.

Compare to my company - I get "mission success bulletins" from one of our divisions once or twice a month. Despite the seemingly positive name, if you're a vendor, you DON'T want to be mentioned in an MSB - they're reports of supplier defects that had negative impact on one of our business units that was severe enough to warn the entire company about the issue. Without a doubt, a defect like this would've caused an MSB to go out.
[Galaxy Note GT-N7000 General] Entropy512:
When you start talking about low level firmware running the wear leveler of an eMMC chip, the lines between hardware and software start getting blurry.

As far as most XDA users may be concerned, this is a hardware problem - the eMMC firmware revision present in your device is what it shipped with and there is no easy way to change it. So it's effectively hardware.

It is in theory possible to update the firmware within the eMMC chip, and in fact this is the method for resurrecting a damaged device. Unfortunately, there are barriers to deploying a fix like this.

1) It involves COMPLETELY wiping the flash chip - including the bootloaders. This means it can only be done via JTAG or USB bootloader

1a) So with the proper info from Samsung, the RIFFbox guys could implement a JTAG recovery/immunization mechanism. Right now, devices that have suffered damage due to this bug can't even be brought back with JTAG.

1b) With a little bit more info from Samsung, AdamOutler could implement a resurrector/updater that worked via the USB port, taking advantage of low-level boot capabilities of the Exynos CPU itself

2) The firmware itself seems to be considered highly proprietary by Samsung

3) The eMMC extended commands needed to perform an update are not part of the JEDEC eMMC standard, and these extensions also appear to be considered proprietary by Samsung

That's why I'm waiting to see what Samsung actually provides us... My contact has stated that they can't themselves release proprietary information to the community, but the information listed above is what we need to recover damaged devices. We already have all the info we need to protect devices from damage thanks to Ken Sumrall of Google's valuable help.
[Galaxy Note GT-N7000 General] PoisonWolf:
Quick question Entropy....about the eMMc bug...is the 0x19 firmware causing uneven wear-leveling till the point that a section of the NAND becomes damaged, or it is a sudden out of the blue damaging of parts of the NAND when the ERASE command is called?

Trying to understand how the damage is done, whether it is purely random and has nothing to do with uneven wear leveling or it is damaging the NAND by wearing it out completely.

Thanks for any clarification you can provide on this. :)
[Galaxy Note GT-N7000 General] Entropy512:
The NAND itself is not damaged. What happens, at least according to Mr. Sumrall's info, is that the ERASE command crashes midway through, and leaves the wear leveller's internal data structures in la-la-land.

So the flash chip is fine internally, but the wear leveller's internal data structures are corrupt, so without completely resetting the chip, any attempt to access that data causes the chip to hang.

Unfortunately, the JEDEC eMMC standard does not have the equivalent of a "low-level format" that completely resets the wear leveler. If it did, JTAG repair services could repair these devices.

Another way to think of it is, in analogy form:

Imagine you have a FAT file system.

When deleting a file, a kernel bug caused the FAT data structures themselves to get corrupted

Now, whenever you work with the filesystem, weird **** happens

Your only tools available for repair are the standard userspace operations - delete files, create them, etc.

The ability to format the partition and start fresh is considered manufacturer proprietary so you can't do it.

Same idea here, except at a lower level than disk filesystems.
[Galaxy Note GT-N7000 General] friedje:
If what you are saying is true then the chip wouldn't be operational anymore, because it uses the wear leveling on all write operations, not only wipe or flash..

It would it make impossible to do a recovery like some ppl did by erasing and repartitioning the chip, loosing a part of it to bb.

Or those ppl never got the wear level data structure in lala land...

What could be happening is that the bb table gets corrupted during format and existing bb getting used and block the chip.

It would also explain why not everyone is concerned, but only those with already existing bb. inside their chip,

or even after many times when the first bb. start to rear their ugly heads but not written into the bb table anymore because

it is corrupted.
[Galaxy Note GT-N7000 General] PoisonWolf:
Thanks mate. That brings my understanding of the issue to a whole new level.
[Galaxy Note GT-N7000 General] shoey63:
OK then. I'm going back to GB. CM9 with Thor 11 kernel works great (Sorry, went over to the Dark Side), but I need a few bells and whistles to show off to my

mates and work colleagues. (only had SGN a couple of weeks and flashing ROMS and kernels every day, but NOT from ICS). So which is the best GB ROM?

I mean I have flashed from ICS but always going back to pre-rooted GB ROM first.
[Galaxy Note GT-N7000 General] nuramohammed26:
SO you mean to tell me as far as my note is concern,if at all i bricked it while trying to update to ICS i will get my warranty whether i am on a custom rom or not, or my flash counter has reached 30?
[Galaxy Note GT-N7000 General] friedje:
I wouldn't take it for granted.

I guess we are at the grace and mercy of the service center and the employee

that receives us....
[Galaxy Note GT-N7000 General] Entropy512:
Why wouldn't it be operational? Some of the data structures are corrupted, some are not. If you don't touch the corrupted structures, you're fine. Touch them, and you're toast because the chip locks up.

In the anlalogy I gave above - one directory would be corrupted and touching anything in it would cause a crash. Another directory could be completely fine as it never references the corrupt data.

Losing the bad block map wouldn't explain this:

1) Chips aren't designed with THAT much spare memory cells for bad blocks that losing the bad block map would cause multi-gigabyte swaths of the chip to go poof

2) If losing the bad block map were the problem, then performing a full low-level wipe/reset of the chip would make the problem worse instead of fixing it. Performing a firmware upgrade (which fully resets the chip including all wear leveller data structures) has been described by a contact at Google as the only way to repair this damage.
[Galaxy Note GT-N7000 General] garwynn:
Couple of clarifications here:

Warranty: Check it before making assumptions. The E4GT warranty, for example, has a clause in there that fairly well exempts

any

software - as it doesn't specify anything beyond that - to the point that this brick would not be under warranty.

eMMC lockup - The way it has been described by people who have experienced this first-hand is that the device freezes. The initial occurrence happens during a call to mmc_erase() which triggers use of a action in the eMMC's embedded controller (the interface that does the talking between the rest of the phone and the actual storage) and can but not always cause it to hang.

Once it is triggered any access to the memory area in question will cause the same lockup/freeze. drnull has tested and verified this on the E4GT back in March. It was also then found that you could partition your way around it, such as hg42's new PIT files for the Note - but was not recommended for a permanent solution.

Entropy,

Do I take from your posts you've gotten a response from someone different at Samsung as of late? I hope that's good news since I haven't heard anything back from Mr. Sumrall nor Samsung semiconductor.

I agree that the fix will probably be all of the various kernel changes and probably a pre-packaged update-binary for people to use in their ROM development... but the best solution would be the firmware update. It is seeming less likely that we'll see it but one could hope they'll at least give it out to the carrier's support teams.
[Galaxy Note GT-N7000 General] ainidmor:
I think, however, the solution comes too late...

It's not serious that a company like Samsung takes all this time to fix a bug that HE HAS GENERATE and can totally brick your phone; and you can lose all your personal and profesional information in a device aimed at business!.

What does it mean "soon"? hours? days??? 2013???

I could not imagine me saying this but .. what Apple have done???

Google translator.... sorry...
[Galaxy Note GT-N7000 General] friedje:
1. We got no idea how much bb we got. it could be 500 bytes or 2Gb.

Out of caution the 'unbrickers' ommit 2Gb, but it could be way less.

2. Performing a low level format , that nobody has been able to perform,

since only samsung has the tools to do it, includes the rebuilding of the

bb table at the end.

You do agree with me that the wear leveling is not only used for formatting

but for all write operations ?

These are the same algorithms, so if they are ****ed up, they are ****ed up..

The chip won't be able to write, or if it still can write, it can also format.

Furthermore the FW is in static memory, even if the erase command hangs,

the FW is not affected in anyway since you are not erasing or changing it, you

are just executing it's functions. It might leave the chip in a weary state once

hung, but a reset (power off for a lapse of time) would bring it back to life.

Although it could leave it's 'data' tables corrupted. maybe bb, maybe something else.

However if the bb table gets screwed we get similar symptoms to what we

are seeing. Anyway as long as we cannot get to test the chip and the tools for it,

we keep guessing. The best we might get is what we already have...Altered kernels

that don't use the erase command.

We could use a hardbricked motherboard and try to revive it, or a developers

kit like the linaro one http://www.youtube.com/watch?v=d1rlCTNOiyA or the samsung origen board. Still it would require the software tools.
[Galaxy Note GT-N7000 General] dbreloaded:
One word - Antennagate http://gizmodo.com/5589336/apple-antennagate-and-why-its-time-to-move-on

But lets not turn this into an anti apple debate lol
[Galaxy Note GT-N7000 General] friedje:
There is no need to blow this out of proportions.

If Google hadn't enabled the wipe in ICS we would never

have known we had a bad FW in the Emmc controller.

So if we now just take the bad kernels offline, and Samsung gives

us safe ones instead + source, the problem is out of the world..

You won't die prematurely from having a FW 0x19 in your VYLOOM
[Galaxy Note GT-N7000 General] Entropy512:
Correct. It happens to actually be a contact that one of the other ERDs has. I gave your email and name to that contact as someone who they might want to bring in on this discussion. (We haven't heard from them since Friday morning.)

Unfortunately this contact is in the Mobile division and it seems like the info we REALLY need comes from Microelectronics/Semiconductor.
[Galaxy Note GT-N7000 General] jgaviota:
friedje from Mr. Sumrall:

So, he did state that this bug is in the wear leveler data structures (I thought he hadn't said where the damage was).

So please Entropy, could you ask your latest Samsung contact for the 0x19 firmware errata, so that we have a firsthand description of why the bug occurs? (I admit it's a long shot that they will release the errata, but it is a professional curiosity :))
[Galaxy Note GT-N7000 General] friedje:
thanks for copying Mr Sumralls dialog here, it saves some navigation :)

In fact he is telling a similar story as i am. The difference is that he is saying that the block identifiers are likely corrupted. However those could be recovered. Without information from Samsung, as you reclaim, it stays a wild guess. The bug can be anything inside the code.

Just one last remark for the kernel devs that are working on solutions. I read somewhere in a thread that either disabling the erase command flag would be a possible solution, or "make it write zeros" instead.

Flash memory doesn't work like regular memory. You cannot overwrite anything, and you MUST erase cells, or you will never be able to reuse or reclaim them. You would run out of memory in no time. But that remark probably didn't come from a Kernel dev; I assume they know what they are doing :)