If you own a Samsung Galaxy S II or the Galaxy Note and are a regular member of the xda-developers forum, you may already be aware of a bug with some of these devices where erasing the eMMC could hard brick your phone.
This problem would surface if the user tried to flash a custom ROM or kernel that used MMC_CAP_ERASE. Thankfully, developer Chainfire came up with an app that would let you know if your device was shipped with a faulty eMMC.
Apparently, this issue has existed for a long time now and even though it was noticed a couple of months ago and was much talked about in the developer community Samsung did not respond to it, until now.
According to user Daniel Hillenbrand on Google+, Samsung has said that "Patches will be out in form of new official ROMs and also sourcecode releases after testing, which might take some time."
If you have a Galaxy S II or Galaxy Note, just use the Chainfire GotBrickbug app from here and see if the eMMC in your device is affected. If it is, refrain from any kind of ROM flashing (except for CM9 kernels, which are safe to flash) until the patch from Samsung starts rolling out.
SOURCE
Atleast give source of info and links ?
anshmiester78900 said:
Atleast give source of info and links ?
Click to expand...
Click to collapse
It's there, but in camouflage:
https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB
Cheers.
buzzboy said:
It's there, but in camouflage:
https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB
Cheers.
Click to expand...
Click to collapse
Cheers mate and it is good to know that samsung is working hard on it
Stupid question but does that mean that we need to wait first Samsung to release something and then rom and kernel makers to implement it in their products? I just flashed slimics rom and now checked that I have brick bug, nice!
Sent from my GT-I9100
I don't really think it's Samsung fault. They have spend a lot of time working on those devices, and of course, bugs are all part of the development. I don't think that Samsung is a bad company, but they need at least to figure out the problem and fix in the next device or firmware, so that's enough to me.
edit: well, it's kindda samsung's fault, hehehe.
I have the bug, according to Chainfire's app, but I've never had any problems after many, many flashes.
Am I just lucky?
How likely are those whose eMMC chips are faulty in this way to be bitten by the bug?
I've typically flashed all new leaks of Stock ROMs only. How do we know if are using kernels based on sources where MMC_CAP_ERASE is present?
donalgodon said:
I have the bug, according to Chainfire's app, but I've never had any problems after many, many flashes.
Am I just lucky?
How likely are those whose eMMC chips are faulty in this way to be bitten by the bug?
I've typically flashed all new leaks of Stock ROMs only.
Click to expand...
Click to collapse
It's only triggered if using certain kernels (Or, more worrying, some stock GNote builds)
There is a thread listing "bad" kernels and an explanation kicking around on XDA if you want to know more.
In short.. Stick to well known and well tested kernels and you'll never have a problem
Azurren said:
It's only triggered if using certain kernels (Or, more worrying, some stock GNote builds)
There is a thread listing "bad" kernels and an explanation kicking around on XDA if you want to know more.
In short.. Stick to well known and well tested kernels and you'll never have a problem
Click to expand...
Click to collapse
Does that list get updated?
How do we know if are using kernels based on sources where MMC_CAP_ERASE is present?
I assume that since this is such a potentially serious issue, the MMC_CAP_ERASE issue is something that devs are well aware of. I wasn't aware of it until very recently.
IF I understand correctly, are you saying that the stock kernels no longer have this issue or do they still and can MMC_CAP_ERASE be removed from the kernel?
it will b great if the patches roll out soon
Just curious, what effect does MMC_CAP_ERASE have? I mean what does it actually do? And is not being able to perform it somehow reduces the performance of our emmc chips?
mzone1510 said:
Just curious, what effect does MMC_CAP_ERASE have? I mean what does it actually do? And is not being able to perform it somehow reduces the performance of our emmc chips?
Click to expand...
Click to collapse
this thing can destroy your mobile
MMC_CAP_ERASE is one of the big reason to hardbrick the sgs2 phone.
NOMIOMI said:
If you have a Galaxy S II or Galaxy Note, just use the Chainfire GotBrickbug app from here and see if the eMMC in your device is affected. If it is, refrain from any kind of ROM flashing (except for CM9 kernels, which are safe to flash) until the patch from Samsung starts rolling out.
Click to expand...
Click to collapse
I normally ignore posts like this but just need to clear something up as you only make things worse for new members who are unaware when you spread false information through a forum like this. Can you please remove or reword what you've said. I'll break it down for you:
If you have a Galaxy S II or Galaxy Note, just use the Chainfire GotBrickbug app from here and see if the eMMC in your device is affected - This is fine as people can run that app.
If it is, refrain from any kind of ROM flashing (except for CM9 kernels, which are safe to flash) until the patch from Samsung starts rolling out. - So wrong it hurts! Everyone should completely ignore this sentence and actually read the thread of the app which states all currently available kernels based on Update4 sources (so all custom kernels in the dev areas) are safe. It was particular leaks that raised this issue as found in an earlier Siyah beta which was rectified as quick as Gok could do it but to this day people still question devs on their kernels. Please read the thread and add useful guidance only or direct people to the post which states the safe kernels!
And as a last note, please don't post in kernel threads asking if they're safe, simply do a search as it's been asked stupid amounts of times and no more spam is required.
Thanks and happy flashing
AvRS said:
I normally ignore posts like this but just need to clear something up as you only make things worse for new members who are unaware when you spread false information through a forum like this. Can you please remove or reword what you've said. I'll break it down for you:
If you have a Galaxy S II or Galaxy Note, just use the Chainfire GotBrickbug app from here and see if the eMMC in your device is affected - This is fine as people can run that app.
If it is, refrain from any kind of ROM flashing (except for CM9 kernels, which are safe to flash) until the patch from Samsung starts rolling out. - So wrong it hurts! Everyone should completely ignore this sentence and actually read the thread of the app which states all currently available kernels based on Update4 sources (so all custom kernels in the dev areas) are safe. It was particular leaks that raised this issue as found in an earlier Siyah beta which was rectified as quick as Gok could do it but to this day people still question devs on their kernels. Please read the thread and add useful guidance only or direct people to the post which states the safe kernels!
And as a last note, please don't post in kernel threads asking if they're safe, simply do a search as it's been asked stupid amounts of times and no more spam is required.
Thanks and happy flashing
Click to expand...
Click to collapse
Im sick of seeing people asking/commenting about this in the Kernel threads, when they have no idea what they are on about!
superleeds27 said:
Im sick of seeing people asking/commenting about this in the Kernel threads, when they have no idea what they are on about!
Click to expand...
Click to collapse
Indeed and unfortunately it starts due to threads like these, sorry OP.
Here's some further reading for those who avoid using search so sit down, read and then forget:
Entropy512 said:
It would be beneficial to provide more information on the brick bug to avoid some people getting unnecessarily scared (such as most I9100 users).
This bug requires three things for you to be in danger, and ALL of these conditions must be met for danger:
1) A defective eMMC chip/fwrev that is unable to handle eMMC ERASE commands (command 38) properly. (I'll provide a link with more detail on the nature of the bug later) - This condition is the one Chainfire's new app checks for. By the way, M8G2FA fwrev 0x11 (seen on some Kindle Fires) is also suspected of being defective.
2) A recovery binary that attempts to erase partitions when formatting them. Most ICS recovery binaries fit in this category, most Gingerbread recoveries do not attempt to perform an erase operation so are safe. Note that also, an affected update-binary in a ZIP could be a cause of problems too. (e.g. flashing a firmware that has an ICS update-binary and formats the partition could cause a problem even with a "safe" recovery.) So a kernel can be repacked with a "safe" CWM (such as the most recent CF-Root releases) but it will still only be partially safe.
3) A kernel that allows attempts to erase a partition to actually happen. (as opposed to reporting "not supported" and doing nothing.) - A common way of rendering a kernel safe is to remove MMC_CAP_ERASE from the capability flags in drivers/mmc/mshci.c
As of June 6, 2012, this is what I know as far as kernels that meet condition 3:
All GT-I9100 ICS leaks and official releases are SAFE (MMC_CAP_ERASE not present)
All kernels based on GT-I9100 ICS Update4 sources are SAFE (MMC_CAP_ERASE not present) - This includes all CM9 nightlies for SGH-I777, GT-I9100, and GT-N7000, all GT-I9100 custom kernels I am aware of, and all SGH-I777 custom kernels I am aware of
All GT-N7000 ICS leaks are UNSAFE
All GT-N7000 ICS official kernels are UNSAFE
All kernels built from the GT-N7000 sources are UNSAFE unless the following condition is met:
MMC_CAP_ERASE is removed from the capability flags in drivers/mmc/host/mshci.c - check the kernel features for this. Franco.kernel R3 and later and all Speedmod ICS releases are SAFE due to this.
All SHW-M250S/K/L ICS kernels are suspected to be UNSAFE
All SHW-M250S/K/L ICS source releases as of this date are UNSAFE (SHW-M250L Update4 was the cause of the SiyahKernel 3.1rc6 incident. Other Siyah releases are SAFE)
All SPH-D710 ICS releases as of this date are UNSAFE - Rumor has it that the official OTA may have a fixed kernel, but it is recommended to consider this kernel UNSAFE until source code is released and can be reviewed.
The SGH-I777 UCLD3 leak is UNSAFE, as is most likely every other leak for that device. Fortunately nearly everyone is using I9100 Update4-based custom kernels.
SGH-I727 and SGH-T989 ICS leaks are UNSAFE - However as these two devices use separate recovery and operational kernels, if you have a Gingerbread recovery/kernel, you should be safe regardless of what you are booting for normal operation.
It's hard to get ALL of the cases and evaluate them, but in general in terms of levels of danger (As of June 6, 2012 - this could change with time):
SPH-D710 users are in the most danger - They have no official ICS releases AND the I9100 Update4 source base can't be used to build a usable kernel for their device without major developer work
GT-N7000 users are second on the list - They are the only ones outside of Korea to receive official ICS updates that trigger the eMMC firmware defect. However, I9100 Update4 sources required only minor work to create "safe" kernels, and developers know the proper procedure for rendering the official N7000 Update3 source drop "safe"
SGH-I777 users are next - I777 leaks proved to be dangerous a month or so ago. However, the SGH-I777 required the least amount of work to be able to use the GT-I9100 Update4 source base, and as a result, with the exception of the leaks themselves, nearly all I777 ICS kernels are based off of safe source code bases.
GT-I9100 users are in the least danger - No leak, official binary release, or source code release for this device has been dangerous. Only one I9100 kernel has ever proven dangerous and that was quickly pulled by its developer.
I am not evaluating the SHW-M250S/K/L in the above list, as while I know their source and binaries are dangerous, the language/culture barrier means we have very little information on how this fiasco is panning out for those users.
UPDATE:
We have at least one confirmed report of this bug occurring with KYL00M fwrev 0x12 on a Samsung Skyrocket (SGH-I727) with their ICS leak kernels
In addition, Samsung Hercules (SGH-T989) has the same fwrev and I've been told that they have observed bricks of this type with their ICS leaks
UPDATE 2:
I've received an email from a contact at Samsung who has indicated they are working on some sort of fix to be deployed to devices with an "UNSAFE" configuration listed above. I have requested that I receive an explicit list of which binary builds contain this fix, as without that I cannot know for sure which builds are fixed and which are not. Fixes are not yet deployed to affected devices.
Click to expand...
Click to collapse
HELP!
I have bad news (for me, of course) my phone is bricked, I write here because I want my phone back and I find no solution so far for this model, only for the Note and Epic 4G. Anyone have any ideas to solve the problem of brick MMC_CAP_ERASE for i9100? I'm reading from 6am..
if the moderator feels that this post should not go here, is his right of disposal. I just want an answer and a possible solution. thanx
I got the emmc bug too..good thing nothing happened when I flashed my phone. using siyah 4.1.5 kernel
I got to emmc bug and o tried all stuff i have jtag-et device 4 times but nothing always same when instaling something my phone freazes. And i have byed new sgs2 and my old phone is just waiting bether times
Sent from my GT-I9100 using xda app-developers app
Related
Entropy recently stated that using any leaked build was dangerous.
I have used every single version of AOSP and CM9 from the beginning to current, jumping between and back and forth from GB many times with no issues.
I have also never SEEN a report of anyone bricking (when properly) flashing around with these roms.
Just curious if a case actually exists.
crawlgsx said:
Entropy recently stated that using any leaked build was dangerous.
I have used every single version of AOSP and CM9 from the beginning to current, jumping between and back and forth from GB many times with no issues.
I have also never SEEN a report of anyone bricking (when properly) flashing around with these roms.
Just curious if a case actually exists.
Click to expand...
Click to collapse
No but there is a risk. And the question is : "Do you want to take this risk while CM9 is announce next week with a safe kernel".
I was using Imilka Cm9, and yesterday i flashed back to GB. Maybe you could wait one week and avoid flashing a hazardous repack !
I had no issues with Imikas cm9 roms, I used all 3 of them and have since flashed to a stock gingerbread as the video playback in all the ICS roms is not good enough yet compared to GB roms.
I have tried all the ICS leaks and gone back to GB with no issues, just waiting for a proper stable release of ICS with good video playback performance as I get in GB then I will stick with the Ice Cream
remixtech said:
No but there is a risk. And the question is : "Do you want to take this risk while CM9 is announce next week with a safe kernel".
I was using Imilka Cm9, and yesterday i flashed back to GB. Maybe you could wait one week and avoid flashing a hazardous repack !
Click to expand...
Click to collapse
I wasn't stating that there isn't a risk, or that anyone should chance it. Just simply that I have not heard of a single case of anyone having a problem with iMilka's releases (killing the board). Therefore my none developer point of view is that the risk must be VERY small IF said risk does truly exist with all Kernel Leak builds.
It SEEMS to me that the problem does not lie with the kernel build but the way it is scripted and executed. Hence why no one has ever had the problem with AOSP/CM9, but the problem came up with Angelom's kernel and the last Stunner build. The problems were also immediate in both cases, again where no one has ever had this problem caused by AOSP/CM9. So YES, I am sure AOSP/CM9 could have caused the problem if iMilka made whatever mistake was made by Stunner/Angelom, but I would say to me it is quite obvious he did not, and that the problem IS a mistake in the way the kernel is handled. Speculation and opinion only of course.
I have been running them since the beginning, so I am not saying I personally would have chanced it this close to offical ICS / Official CM9, but i've been running his releases for quite some time.
crawlgsx said:
Entropy recently stated that using any leaked build was dangerous.
I have used every single version of AOSP and CM9 from the beginning to current, jumping between and back and forth from GB many times with no issues.
I have also never SEEN a report of anyone bricking (when properly) flashing around with these roms.
Just curious if a case actually exists.
Click to expand...
Click to collapse
Flashed all imilka Roms from day one, and never had as much as a hiccup on any one of them.
The question is if anyone tried to restore a cwm backup ? The most of the bricks were caused by doing that task..
Sent from my GT-N7000 using xda premium
No issues here either with Midnote or TeamMid ROMS (also tried a couple of Alba versions and Stunner).
I have flashed many times and with LP5 kernel through CWMR or Mobile Odin including full wipes.
I have made nandroid backups but haven't tried to restore any, perhaps this has saved me?
Tried CWM restore twice on ICS (missed reports that it is not recommended). Both times ended with corrupted system partition. But both times fixed this problem by flashing stock ROM with desktop Odin. Had no problems after.
Sent from my GT-N7000 using xda premium
dimcus said:
Tried CWM restore twice on ICS (missed reports that it is not recommended). Both times ended with corrupted system partition. But both times fixed this problem by flashing stock ROM with desktop Odin. Had no problems after.
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
Exactly the same here. Unable to format /system partition after restoring.
Odin managed to fix it tho.
jscurtu said:
The question is if anyone tried to restore a cwm backup ? The most of the bricks were caused by doing that task..
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
I have multiple times. CWM Backup restore works sometimes for me ICS to ICS, and fine GB to GB. ICS to GB or GB to ICS causes issues but I can easily fix them with a flash/odin/etc and still have complete access to download mode / CWM. ICS to ICS I have run in to problems such as funky root or partition issues, once again still easily fixable and still have plenty of access to the phone/flash abilities, By no means even close to a brick.
That said at this point in the game I wouldn't even consider doing a CWM restore, why even chance it!
dimcus said:
Tried CWM restore twice on ICS (missed reports that it is not recommended). Both times ended with corrupted system partition. But both times fixed this problem by flashing stock ROM with desktop Odin. Had no problems after.
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
Just to report, I experienced exactly the same.
Regards!
Sent from my GT-N7000 using xda premium
dimcus said:
Tried CWM restore twice on ICS (missed reports that it is not recommended). Both times ended with corrupted system partition. But both times fixed this problem by flashing stock ROM with desktop Odin. Had no problems after.
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
Which kernel were you on?
chill392 said:
Which kernel were you on?
Click to expand...
Click to collapse
The first leaked one - LP1.
jscurtu said:
The question is if anyone tried to restore a cwm backup ? The most of the bricks were caused by doing that task..
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
I think you are wrong.Bricks caused when trying to format /system
Sent from my GT-N7000 using Tapatalk
Bricks were caused by anything that tried to wipe a partition - and restoring a nandroid will first wipe a partition.
What kernel is imilka's a repack of? Maybe it's an unaffected one. I recall seeing stuff in imilka's thread saying not to use its CWM.
Without source for the leak kernels it's impossible to tell what's changed and declare one kernel "safe" and another "dangerous" - as long as some are proven dangerous they should all be considered dangerous.
afilopou said:
I think you are wrong.Bricks caused when trying to format /system
Sent from my GT-N7000 using Tapatalk
Click to expand...
Click to collapse
When restoring a backup , you usually format /system ; )...so basically yes that is correct, I only mentioned that it mostly happened while doing that task..
Sent from my GT-N7000 using xda premium
Entropy512 said:
What kernel is imilka's a repack of? Maybe it's an unaffected one. I recall seeing stuff in imilka's thread saying not to use its CWM.
Without source for the leak kernels it's impossible to tell what's changed and declare one kernel "safe" and another "dangerous" - as long as some are proven dangerous they should all be considered dangerous.
Click to expand...
Click to collapse
It was multiple different kernels, up to LP5 and LP6 even.
I understand the logic and respect your words of caution with what is most certainly from someone who has a much better understanding than I, I just feel it is the way the kernel was used/modified/implemented that caused the potential problems (by the devs), not the kernel itself. Based on the logic I provided earlier in the thread. I am not saying the problem still does not exist in the kernel, I have no idea, but it is obviously something that did not come out in many rom implementations, just those 2.
Flashed all roms from maxicet and some repack stock ICS roms. Never got any problems. Tested over 10 ICS roms... And now using maxicet's ROM as daily.
crawlgsx said:
It was multiple different kernels, up to LP5 and LP6 even.
I understand the logic and respect your words of caution with what is most certainly from someone who has a much better understanding than I, I just feel it is the way the kernel was used/modified/implemented that caused the potential problems (by the devs), not the kernel itself. Based on the logic I provided earlier in the thread. I am not saying the problem still does not exist in the kernel, I have no idea, but it is obviously something that did not come out in many rom implementations, just those 2.
Click to expand...
Click to collapse
The thing is, this has happened over multiple devices, with multiple recovery implementations, including recovery implementations that work fine with other kernel bases. The end result is the same - fried eMMC that can't even be recovered with JTAG.
Entropy512 said:
The thing is, this has happened over multiple devices, with multiple recovery implementations, including recovery implementations that work fine with other kernel bases. The end result is the same - fried eMMC that can't even be recovered with JTAG.
Click to expand...
Click to collapse
Agreed, very bad.
All I am saying is that it ONLY happened on those 2 botched kernel implementations. It is obviously SOMETHING the Dev's did with the kernel that caused this, seeing how ALL the other roms/versions clearly have not caused this. Since the result was immediate with both of those and many of us have jumped/cwm'ed/etc from MANY different Leaked kernel builds and NOT had that problem.
I am not trying to put them at blame, running any rom/dev is strictly at your own responsibility and risk, just stating that I don't think it is fair to place every leaked rom build in the same category of danger. Is there a risk, certainly, as the dev's could accidentally make said same mistake (I am not even clear if "we" know what causes it?) in a future version. That said I feel pretty confident that if the "final" versions of iMilka's roms were going to cause that issue, it would've happened by now. That is why I wanted to see if anyone had ever been bricked (fried eMMC) from them, and it seems, no.
they say (in the PSA message of entropy) that the OTA update of ICS is affected with the "superbrick" bug that bricked a lot of users... and the idea scares me...
garwynn said:
Hello fellow XDAers!
I'm looking into something and need to kindly request some data from Note owners for comparison. We found a potential attempt to fix this and want to check Note eMMC cid data to see if it matches.
Can you please run the following from adb shell?
(Thanks to sfhub for original steps, two additions to it.)
[email protected]:/ $ su
[email protected]:/ # cd /sys/class/block/mmcblk0/device
[email protected]:/sys/class/block/mmcblk0/device # cat name hwrev fwrev manfid oemid date type serial
MAG4FA
0x0
0x0
0x000015
0x0100
08/2011
MMC
0x01234567
[email protected]:/sys/class/block/mmcblk0/device # cat cid
1501004d414734464119012345671f0f
Click to expand...
Click to collapse
Please copy and paste the results (examples in italics) and either PM or add here when possible. I need to expand the sample set as much as possible so those who can do it it is much appreciated!
And to follow the discussion on the Epic 4G Touch side (Sprint Galaxy S2):
http://forum.xda-developers.com/showthread.php?t=1644364
Thanks to all in advance for your help!
Click to expand...
Click to collapse
Please post your eMMC CID data to help mr. garwynn in his investigations.
As of now, the bug or effects of the bug is hard to pinpoint. and with your help, it could be solved.. thanks for cooperating.
NOTE: you can use Terminal Emulator and input the codes in bold above. then copy paste it here. thanks
To MODS: i edited the thread since a few users have posted their eMMC CID here and avoid split threads with the same posts. thank you.
Note: stop posting eMmc data. Mr. Garwynn got enough stuff already. Just post if you have different cid other than 0x19 (check his thread how to determine)
Latest Update from Android Team:
garwynn said:
Well, it's been some time but thankfully Mr. Sumrall from Android did get back to us on our questions. I think the community will find that this was worth the wait.
Issue: fwrev not set properly.
As we suspected the bugfix is not in our build. (The patch applies this unconditionally.)
Originally Posted by Ken Sumrall
The patch includes a line in mmc.c setting fwrev to the rights bits from the cid register. Before this patch, the file /sys/class/block/mmcblk0/device/fwrev was not initialized from the CID for emmc devices rev 4 and greater, and thus showed zero.
(On second inquiry)
fwrev is zero until the patch is applied.
Click to expand...
Click to collapse
Question: Revision didn't match the fix
(Emphasis mine in red as it discusses the superbrick issue.)
Originally Posted by Ken Sumrall
You probably have the bug, but rev 0x19 was a previous version of the firmware we had in our prototype devices, but we found it had another bug that if you issued an mmc erase command, it could screw up the data structures in the chip and lead to the device locking up until it was powered cycled. We discovered this when many of our developers were doing a fastboot erase userdata while we were developing ICS. So Samsung fixed the problem and moved to firmware revision 0x25. Yes, it is very annoying that 0x19 is decimal 25, and that led to lots of confusion when trying to diagnose emmc firmware issues. I finally learned to _ALWAYS_ refer to emmc version in hexadecimal, and precede the number with 0x just to be unambiguous.
However, even though 0x19 probably has the bug that can insert 32 Kbytes of zeros into the flash, you can't use this patch on devices with firmware revision 0x19. This patch does a very specific hack to two bytes of code in the revision 0x25 firmware, and the patch most likely will not work on 0x19, and will probably cause the chip to malfunction at best, and lose data at worst. There is a reason the selection criteria are so strict for applying this patch to the emmc firmware.
I passed on our results a few days later mentioning that the file system didn't corrupt until the wipe. This is a response to that follow-up.
As I mentioned in the previous post, firmware rev 0x19 has a bug where the emmc chip can lockup after an erase command is given. Not every time, but often enough. Usually, the device can reboot after this, but then lockup during the boot process. Very rarely, it can lockup even before fastboot is loaded. Your tester was unlucky. Since you can't even start fastboot, the device is probably bricked. :-( If he could run fastboot, then the device could probably be recovered with the firmware update code I have, assuming I can share it. I'll ask.
Click to expand...
Click to collapse
Question: Why the /data partition?
Originally Posted by Ken Sumrall (Android SE)
Because /data is the place the chip that experiences the most write activity. /system is never written to (except during an system update) and /cache is rarely used (mostly to receiving OTAs).
Click to expand...
Click to collapse
Question: Why JTAG won't work?
Originally Posted by Ken Sumrall
As I mention above, the revision 0x19 firmware had a bug that after an emmc erase command, it could leave the internal data structures of the emmc chip in a bad state that cause the chip to lock up when a particular sector was accessed. The only fix was to wipe the chip, and update the firmware. I have code to do that, but I don't know if I can share it. I'll ask.
Click to expand...
Click to collapse
Question: Can a corrupted file system be repaired (on the eMMC)?
Originally Posted by Ken Sumrall
e2fsck can repair the filesystem, but often the 32 Kbytes were inserted at the start of a block group, which erased many inodes, and thus running e2fsck would often result in many files getting lost.
Click to expand...
Click to collapse
So, while the fix doesn't apply to us at the moment, we've been given a great insight into the superbrick issue as well as information that a fix is already developed (hopefully we'll see it released!). The bug likely applies to us and assuming the fix for the 0x19 firmware is given then it would apply to our devices.
On a lighter note, I wanted to include his close:
Originally Posted by Ken Sumrall
You are getting a glimpse into the exciting life of an Android kernel developer. Turns out the job is mostly fighting with buggy hardware. At least, it seems that way sometimes.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
musashiro said:
they say (in the PSA message of entropy) that the OTA update of ICS is affected with the "superbrick" bug that bricked a lot of users... and the idea scares me...
questions :
1. why is the bug present on an OTA update?
2. a lot of users say that they use wipe and their ICS is fixed. if LPY is affected with this "superbrick" bug, how come they are still using their phone after wiping?
3. how to safely go back to Stock GB??
Click to expand...
Click to collapse
1) I have no clue - I have lost a LOT of faith in Samsung as a result of this. For more detail, see chasmodo's post in the CM9 thread.
2) Maybe only 5-10% of people get hit by Superbrick - many can wipe with affected kernels and be safe, also in many cases you can wipe 3-4 times and die on the 5th attempt (see Epic 4G Touch forums)
3) Flash an unaffected kernel using Odin.
Entropy512 said:
1) I have no clue - I have lost a LOT of faith in Samsung as a result of this.
Click to expand...
Click to collapse
Yeah man. Last Samsung phone for me. Luckily I didn't "upgrade" to it yet.
I've tested:
Wipe everything with original recovery
Wipe Everything with CWM
Not a single issue.
My guess is that the "superbrick" is something related to the use of a kernel that's its not intended to this device. Maybe there's more diference between I9220 and N7000 that we know!
Just my 2c.
Chas flashed cfroot lpy ontop of cm9. His was only case. Nobody has reported issues of cfroot lpy using official ics. The fear campaign is unnecessary. Jist dont use cfroot lpy with your cm9
Atrix_E said:
Chas flashed cfroot lpy ontop of cm9. His was only case. Nobody has reported issues of cfroot lpy using official ics. The fear campaign is unnecessary. Jist dont use cfroot lpy with your cm9
Click to expand...
Click to collapse
thats what im thinking...
glad im not the only one who thinks that way....
we NEED confirmations with CF, but he is also thinking that LPY *does* have the I/O bug...
musashiro said:
thats what im thinking...
glad im not the only one who thinks that way....
we NEED confirmations with CF, but he is also thinking that LPY *does* have the I/O bug...
Click to expand...
Click to collapse
Time will tell. This was official OTA not a leak. So if thia creates a lot of problems I would not be surprised to see some sort of litigation against Sammy.
how dead is the emmc actually?
is it dead physically, or is there any security key got erased?
to my understanding, emmc is just a sd card(or mmc card), that is soldered onboard directly. it should handle all nand flash trouble internally and act like a block device. the driver should be fairly simple.
for nor flash there is a high voltage factory high speed programming mode that can only be used for 10 times or so.
first thing that bugs me is that, out of all the users who flashed the LPY rom and LPY cfroot, he is the only one complaining about brick...
Whenever I read about these bricked notes, CM9 always seems to be mentioned too... maybe that is just a coincidence.
Atrix_E said:
Chas flashed cfroot lpy ontop of cm9. His was only case. Nobody has reported issues of cfroot lpy using official ics. The fear campaign is unnecessary. Jist dont use cfroot lpy with your cm9
Click to expand...
Click to collapse
that's what i did, straight from cm9 v7 to lpy. may be i'm lucky
What the hell is this thread? People bricked there note with the chinese leak. This is a officiele rom. Before update make sure your not on chinese sh!t kernel.
Atrix_E said:
Chas flashed cfroot lpy ontop of cm9. His was only case. Nobody has reported issues of cfroot lpy using official ics. The fear campaign is unnecessary. Jist dont use cfroot lpy with your cm9
Click to expand...
Click to collapse
The contents of /system are irrelevant to how recovery behaves when wiping.
Look, guys, it's extremely hard to tell what exactly caused my Note to brick up.
Maybe all my Repack Rom hopping made it wonky, and LPY was the proverbial
straw that broke the camel's back?
Maybe LPY contains some bug that affects one Note in a thousand? Ten thousand?
I certainly don't think CM9 is to blame. If the kernel is 100% pukka, not a single Rom
could cause a hard-brick.
Anyway, I wouldn't start a panicky retreat to GB if I were you.
Use your phones cautiously, though: don't start flashing custom Roms left, right
and center when they emerge. Also, don't use your CWMR if you don't have to,
just in case. And check the fora regularly to see if there are any more bricks.
Then decide what to do.
I sincerely hope I'm the first and the last victim of LPY.
robertberma said:
What the hell is this thread? People bricked there note with the chinese leak. This is a officiele rom. Before update make sure your not on chinese sh!t kernel.
Click to expand...
Click to collapse
He wasn't on a chinese leaked kernel, he was on official CM9 kernel.
ykk_five said:
that's what i did, straight from cm9 v7 to lpy. may be i'm lucky
Click to expand...
Click to collapse
i think there's a difference in flashing.
chas was already on cm9 and decided just to flash the kernel only.
whereas your case you flashed the full lpy rom package from cm9 over cm9.
my case was similar to yours but i flashed the rom and cf lpy root kernel all at one go without wipe in mo, but could not get pass the boot screen after which a complete wipe in cwm solved the problem.
but i guess i won't be flashing anything in cwm yet until it is confirmed safe.
robertberma said:
What the hell is this thread? People bricked there note with the chinese leak. This is a officiele rom. Before update make sure your not on chinese sh!t kernel.
Click to expand...
Click to collapse
I was on officiele™ CM9, Bobby, not Chinese...ahem...as you so eloquently put it.
We're really unlucky with this hardbricking and all crap i mean how long will this go on? This is getting ridiculous ...
I think the difference was: Most people wiped when flashing LPY, and when they wiped, they were still on an old "safe" kernel.
In Chas's case - he forgot to wipe initially, so went and wiped using the LPY kernel.
Wiping (and anything that incurs a wipe/format, which includes flashing full firmware packages and Nandroid restores) seems to be the most dangerous operation - it's the same deal over in the Epic 4G Touch forums - wipes are the killer.
And as stated in the sticky - this may only affect a small percentage of users - maybe 2%, maybe 5%, maybe 10%. That's why some people have been able to safely wipe with affected kernels in the past. It's the same over in the E4GT forums - some people wiped 10 times and problems showed up on the 11th.
i guess i will just use the phone normally, no flash, no wipes.. just a regular phone(the main reason for buying the phone) and wait till clarifications arise..
since Chainfire also uses the words "might", "appears" and others that certainly tell that he isn't sure as well...
lets wait for more clarifications....
for me if its an OTA update.. it means that its fully polished.. the main reason why i used it instead of custom roms and sh*tty leaks..
Ok, so we have had "numerous" bricks, which may or may not be kernel / CWM recovery related.
Here's my 5c worth:
1) We had bricks with the dodgy Angelom ICS touch recovery
2) We had bricks with people flashing from rooted and CWM recovery based ROMS of LP1/5/6 to CM9 or CM9 Based ROMS
3) We had one brick with someone on CM9 who flashed the LPY kernel on CM9
So my comments:
1) OK, dodgy kernel, nothing new here. It happens. Self explanatory
2) All these people flashed to CM9 from the leaked Kernels when they bricked. No one that I can recall had this happen flashing other things such as GB kernels. Even Nandroid recovery's just failed, not bricked, although the first thing a nandroid recovery restores is the previous Kernel, so when it failed, it booted into the nandroided kernel.
3) Chasmodo, proven chronic addicted flasher , and also while on CM9
So, for the can of worms:
Does this seems to be an issue related to CM9 based roms more than anything else?
I am not questioning the pedigree of Entropy or XplodWild or CM9, I am just putting it out there to see where this all comes from, and if these are the only scenario's.
I could be completely wrong of course, and I'm OK with that.
Does anyone have a brick from outside of the above, such as flashing from a leaked kernel back to GB? At least lets put all the info in one place.
there were 2 cases of team midnote 1.0 --> team midnote 1.1 (the original midnote 1.1, not the current one)
So these were LP1 - LP5?
some bricked by wiping in CWM alone.
quoted from public service announcement,
Based on reports from the Epic 4G Touch community, some people can wipe/flash 20-30 times before hardbricking - Just because you didn't brick once, DO NOT continue flashing with an affected kernel
Damn the next thread with brick here brick there. Guys dont panic don't open so many threads and stop flashing LP6 and CM9 kernel.
Sent from my GT-N7000 using Tapatalk
So many bricking threads....there will be no shortage of bricks for sometime...lol
We need to stop this train wreck fast... So many devs are getting crippled because of it!
Btw please post how neobuddy bricked so that we can be sure that LPY is safe!
Sent from my GT-N7000 using Tapatalk 2
mobilevil said:
some bricked by wiping in CWM alone.
quoted from public service announcement,
Based on reports from the Epic 4G Touch community, some people can wipe/flash 20-30 times before hardbricking - Just because you didn't brick once, DO NOT continue flashing with an affected kernel
Click to expand...
Click to collapse
Yes, but in all honesty, the EPIG 4G Touch community has bugger all to do with the Note community. How a specific source affects a device must surely be device specific to some degree.
m3dd0g said:
Damn the next thread with brick here brick there. Guys dont panic don't open so many threads and stop flashing LP6 and CM9 kernel.
Sent from my GT-N7000 using Tapatalk
Click to expand...
Click to collapse
The "to be official" CM9 kernel based on the update4 from teamhacksung are not affected and is good and trusted ... all kernels "from Samsung" after update4 are considered dangerous and simply are not compatible with CWM.
Avoid kernels after update4 that come with CWM injected.
Use instead the tw-kernel (dafug) from entropy for Samsung ICS stock roms if you need or want CWM or want to safely switch to CM9 and avoid a brick.
Using the affected kernels without CWM are possibly safe.
Follow those rules and your safe its that simple..
Gesendet von meinem GT-N7000
This thread could be very useful to calm down the situation if not everyone spams pointless yet another brick thread posts.
The opener tries to show that there were not many bricks at all especially not with LPY and you spoil it.
Gesendet von meinem ARCHOS 101G9 mit Tapatalk 2
I myself have escaped my note's death, yesterday i was on the LPY rom and heard about the possibility to brick my phone (it survived the previous leaked chinese tortures) so i went to CWM and tried to restore my CM9 build #7. in the process of restoring my backup the phone freezes halfway and after ~5 mins it suddenly rebooted and went into CM9 with loads of errors.
Booted back into CWM and tried to flash the CM9 updated again with wipes and it froze again halfway the installation and then rebooted on itself after i hung for like 5 mins again.
It booted to CM9 again with all kinds of errors.
My hands got really sweaty from all this risky flashing so i flashed a stock GB rom with PC odin and then flashed my beloved CM9 rom again and im never gonna turn my back on it again.
Kanalcommander said:
This thread could be very useful to calm down the situation if not everyone spams pointless yet another brick thread posts.
The opener tries to show that there were not many bricks at all especially not with LPY and you spoil it.
Gesendet von meinem ARCHOS 101G9 mit Tapatalk 2
Click to expand...
Click to collapse
Who is you? ..
Gesendet von meinem GT-N7000
To put things in perspective, there was an issue with Siyah 3 R6 which was based on the official Korean kernel for SG2, so the evidence is pointing more towards the kernel.
Better be safe than sorry, will switch back to GB until the source of the problem is found. As Entropy said the source lies between the changes of SG2 I9100 and the Korean make.
hkgrob said:
Yes, but in all honesty, the EPIG 4G Touch community has bugger all to do with the Note community. How a specific source affects a device must surely be device specific to some degree.
Click to expand...
Click to collapse
both EPIC 4G and Note run on the same Exynos processor family(donno about the generation), most likely they will share the same emmc controller IP, same driver, same samsung made EMMC chip, then the same bug can happen.
IP = intellectual property, in silicon design it means part of the circuit design which is available for sale. samsung buy different IPs from different vendor, arm core, mali 3D, serial ports, usb ports etc and cook it into one single chip. everybody can become a CPU vendor nowadays.
of course i don't know the details, just want to say if it is kernel related then it should affect similar products.
mobilevil said:
both EPIC 4G and Note run on the same Exynos processor family(donno about the generation), most likely they will share the same emmc controller IP, same driver, same samsung made EMMC chip, then the same bug can happen.
IP = intellectual property, in silicon design it means part of the circuit design which is available for sale. samsung buy different IPs from different vendor, arm core, mali 3G, serial ports, usb ports etc and cook it into one single chip. everybody can become a CPU vendor nowadays.
of course i don't know the details, just want to say if it is kernel related then it should affect similar products.
Click to expand...
Click to collapse
How about the SG2, it also was affected when Gokhanmoral used the Korean based kernel in his Siyah Rom in one version 3R6?
well same chip set same manufacturer........it can happen
it is not always even possible for software to kill a hardware, I am highly interested in the root cause
jscurtu said:
The "to be official" CM9 kernel based on the update4 from teamhacksung are not affected and is good and trusted ... all kernels "from Samsung" after update4 are considered dangerous and simply are not compatible with CWM.
Avoid kernels after update4 that come with CWM injected.
Use instead the tw-kernel (dafug) from entropy for Samsung ICS stock roms if you need or want CWM or want to safely switch to CM9 and avoid a brick.
Using the affected kernels without CWM are possibly safe.
Follow those rules and your safe its that simple..
Gesendet von meinem GT-N7000
Click to expand...
Click to collapse
Before update4, not after. after would be update5 etc..
antiochasylum said:
Before update4, not after. after would be update5 etc..
Click to expand...
Click to collapse
No.. after update4 (sgs2) are affected on all devices..
Gesendet von meinem GT-N7000
UPDATE
Samsung is now working to release a fix for this issue. Also glad to know Samsung is working closely supporting developers in this XDA community
More info here:
http://www.xda-developers.com/android/samsung-diligently-working-towards-hardbrick-fix/
Thank you to all members that helped contacting Samsung, and in a constructive way identifying the problem and report it in a professional way.
I hope Samsung is here to stay and work more collaboratively with this community
Cheers!
____
Hi
Just received a response from Samsung developers on the topic, and need your help providing more details.
Please note that, you must only refer to scenarios using the STOCK Samsung ROM (not custom, cooked, rooted) and standard flashing methods (OTA or Kies).
If we're not able to provide this information, the case is closed.
http://innovator.samsungmobile.com/...Id=1&selectedSequence=00dgu030000~&viewMode=2
Hi,
We have failed to reproduce the bug, please provide a sure way to reproduce it, otherwise we won't be able to help.
While reading through the xda developers forum where this issue is discussed, I noticed that everyone reporting this is using rooted or leaked software. We cannot help you if you don't provide us with all the information - which software version? What are the exact steps?
Regards,
Adam Panasiuk
Samsung Developers
Click to expand...
Click to collapse
nCoder said:
Hi
Just received a response from Samsung developers on the topic, and need your help providing more details.
Please note that, you must only refer to scenarios using the STOCK Samsung ROM (not custom, cooked, rooted) and standard flashing methods (OTA or Kies).
If we're not able to provide this information, the case is closed.
http://innovator.samsungmobile.com/...Id=1&selectedSequence=00dgu030000~&viewMode=2
Click to expand...
Click to collapse
I've seen at least one report of XXLPY killing someone's device in stock recovery.
Also, Sprint was able to reproduce this on their devices (and apparently is deploying a fix) - I'll try to find more on that later.
"please provide a sure way to reproduce this" - ARE THEY KIDDING? If you reproduce this, YOUR DEVICE IS DEAD. One can't provide a sure way to reproduce a bug that you can test ONCE successfully. As stated by others, even a Google engineer himself, the fwrev 0x19 ERASE bug is intermittent and won't always happen. There is no "sure" way to reproduce this. However, this is a bug that was confirmed by Google during Galaxy Nexus development and we have confirmed that we have the same chip/fwrev as ones that Google experienced problems with in GNex prototypes.
Entropy512 said:
I've seen at least one report of XXLPY killing someone's device in stock recovery.
Also, Sprint was able to reproduce this on their devices (and apparently is deploying a fix) - I'll try to find more on that later.
"please provide a sure way to reproduce this" - ARE THEY KIDDING? If you reproduce this, YOUR DEVICE IS DEAD. One can't provide a sure way to reproduce a bug that you can test ONCE successfully. As stated by others, even a Google engineer himself, the fwrev 0x19 ERASE bug is intermittent and won't always happen. There is no "sure" way to reproduce this. However, this is a bug that was confirmed by Google during Galaxy Nexus development and we have confirmed that we have the same chip/fwrev as ones that Google experienced problems with in GNex prototypes.
Click to expand...
Click to collapse
I understand, but not proving evidence the bug exists in a stock rom, or reference to a reliable source (Do you have a formal statement from Sprint?) Even if the scenario is "Install ROM version N7000XXXLPx using Kies, then go to recovery and do this, then repeat XX times step 3, reboot, ...", we need to provide a scenario and examples of users that bricked their devices or else this channel to Samsung simply closes .
From what I understand, they are willing to break some devices to be able to confirm the problem.
Feel free to go to the link above and reply directly to Samsung
Weasels! I'm seriously disappointed that their "engineers" don't read up on the latest regarding their own devices....
one thing is for sure, if they can't reproduce it, they wont fix it and pretend that it has nothing to do with their roms..
same situation as franco on his kernel, he can't reproduce the wifi problem so he wont do anything.
i can't use a stock ics + cwm thinking that this bug is present...
We just need as much information as possible.
This is a privileged channel to Samsung, and we should take advantage of this opportunity.
Complaining doesn't help. We need constructive ideas and reliable information
Well, can just say one thing.
Long Live to CM9 and all CM based roms.
Seems that those will be the only safe roms for a long long time.
@nCode : Then go for it bro', break your phone and tell samsung what happend. I wont try to find a way to reproduce the bug except if they give me a Note to test on it.
Well this gonna be challenging. Actually there's no exact way to reproduce hardbrick.
Maybe Entropy or someone of the guys that understand situation to the details should simply try to EXPLAIN what is actually going on... but i agree with Samsung developers it's hard to fix something when you can't reproduce the problem ...
nCoder said:
We just need as much information as possible.
This is a privileged channel to Samsung, and we should take advantage of this opportunity.
Complaining doesn't help. We need constructive ideas and reliable information
Click to expand...
Click to collapse
Well, they could try this scenario on a dozen phones, and they will reproduce it:
1. install a GB Rom, root it
2. make a nandroid backup
3. flash official ICS Rom, get root
4. do several factory resets and cache wipes
5. attempt to do a nandroid restore from the CWMR
They are bound to brick at least one device on step 4 or 5.
Yes, there is a sure way to reproduce the bug:
Take as many Notes as you can that have LPY or any official ICS, it doesn't matter how they got it.
Now factory reset them at least 100 times.
This is no joke, they can do it, it's quality assurance.
chasmodo said:
Well, they could try this scenario on a dozen phones, and they will reproduce it:
1. install a GB Rom, root it
2. make a nandroid backup
3. flash official ICS Rom, get root
4. do several factory resets and cache wipes
5. attempt to do a nandroid restore from the CWMR
They are bound to brick at least one device on step 4 or 5.
Click to expand...
Click to collapse
They won't accept this since it involves root and/or CWM.
I'll try to dig up the report of a user dying on stock recovery.
Why does not Samsung contact Mr Sumrall and other Google developers who worked on the Nexus?
i thought they support developers by supplying smartphones with unlocked bootloaders... they should support rooting and cwm in a way (even the slightest consideration for the betterment of stock )
If I'm not wrong the guy who bricked his phone with stock recovery was Robotu.
http://forum.xda-developers.com/member.php?u=2526707
His brick post. He used stock recovery but was rooted though.
http://forum.xda-developers.com/showpost.php?p=26046849&postcount=140
musashiro said:
i thought they support developers by supplying smartphones with unlocked bootloaders... they should support rooting and cwm in a way (even the slightest consideration for the betterment of stock )
Click to expand...
Click to collapse
That's not the point, if the bug can only be reproduced on a rooted/unofficial ROM then they can simply ignore it by saying that it's not a bug introduced by them. They're not liable for other people's mistakes.
Dragooon123 said:
That's not the point, if the bug can only be reproduced on a rooted/unofficial ROM then they can simply ignore it by saying that it's not a bug introduced by them. They're not liable for other people's mistakes.
Click to expand...
Click to collapse
and again, im just saying its like a "pathway" to fixing it and its proven to be present on official roms by Ken Sumrall..
sorry for not helping a lot, and posting chitchat...
im no big developer but whenever i troubleshoot, i make it to a point that i inspect every possible angle or scenario..
somehow reminds me of the quote "When you have eliminated the impossible, whatever remains, however improbable, must be the truth."
just my 2 cents on this
Dragooon123 said:
That's not the point, if the bug can only be reproduced on a rooted/unofficial ROM then they can simply ignore it by saying that it's not a bug introduced by them. They're not liable for other people's mistakes.
Click to expand...
Click to collapse
But it's a way for them to ESTABLISH that there's something wrong with their kernels. If they want to, of course.
You can wipe everything, and do restores till you drop dead on rooted GB, and everything will be fine.
Not so on ICS, as we all know only too well.
old news, everyone know/should know that samsung software support is peace of sh*t.. even if they will find that bug, they wont announce it because they dont want to reduce company reputation :/
Dragooon123 said:
That's not the point, if the bug can only be reproduced on a rooted/unofficial ROM then they can simply ignore it by saying that it's not a bug introduced by them. They're not liable for other people's mistakes.
Click to expand...
Click to collapse
This is very true. It needs to be something that "the average users" could recreate, meaning going through the "OFFICIAL" steps that Samsung put out. When I was developing for RIM/Blackberry we didn't support any custom software packages and the same thing when I was doing freelance development for Apple as we did NOT support and jailbroken software since it altered out factory coding....LOL.
Ueihtam said:
Well, can just say one thing.
Long Live to CM9 and all CM based roms.
Seems that those will be the only safe roms for a long long time.
@nCode : Then go for it bro', break your phone and tell samsung what happend. I wont try to find a way to reproduce the bug except if they give me a Note to test on it.
Click to expand...
Click to collapse
Nobody is asking to break anyone's phone. We just need reliable information either from people that bricked his phone using a stock ROM, or someone that understands and is able to explain the scenarios.
The objective of this thread is to have all the knowns issues and known (or potential) fixes for the I9300 in an OP.
Latest Updates
- What to do if you only want warranty
- Updated CF-Auto-Root
- Perseus Kernel patched
Universal
There are mainly two major issues I've found around the forums: Exynos Root Exploit and Sudden Death (eMMC failure).
Exynos Root Exploit
alephzain said:
Recently discover a way to obtain root on S3 without ODIN flashing.
The security hole is in kernel, exactly with the device /dev/exynos-mem.
This device is R/W by all users and give access to all physical memory.
Click to expand...
Click to collapse
It was fixed by Samsung in the XELLA/XELLC kernel.
Stock ROMs collection.
Sudden Death
Sudden Death Syndrome (SDS): Some S3 devices which have a faulty eMMC chip seem to just die. Most victims have found their phone completely unresponsive while taking it out of charge. Some have managed to boot into download mode but are unable to flash any ROM (presumably because the NAND is already damaged).
There are two theories of this: both are explained below:
rlorange said:
Guys we don't know enough to say for sure that previous faulty wear leveling has already dine damage.
According to the best informed guess by Entropy, the faulty wear leveling firmware causes a brick only when it decides to move critical data to fresh block which DOESN'T EXIST.
Wear leveling works by keeping track of read/write cycles for data blocks. The faulty emmc controller is guessed to have a bad block address move as part of it's wear leveling which causes the failure.
There is no evidence that the brick happens because of too many read/writes in one place which eventually fails (Theory 1). Rather if and when the wear leveling controller moves a block there is a bug which screws this up somehow (Theory 2).
Assuming the kernel patch prevents the emmc wear leveling code from triggering the buggy block move then it really will prevent the affected NAND chips from ever failing.
We don't yet know for Sure but Entropy seems to think that the failure event is triggered during normal wear level block moving which goes wrong and does the damage then. Not the other scenario of the wear leveling actually never moving blocks thus after time eventually "wearing a block out" due to too many read/write cycles.
Click to expand...
Click to collapse
rootSU said:
The "Sudden Death" issue is caused by firmware on the (16 GB) VTU00M, revision 0xf1 eMMC (Embedded MultiMedia Card or internal memory if you like). Samsungs Kernel Source Code (Update 7) has been identified as the fix.
Click to expand...
Click to collapse
Appropriate fixes found in the OP.
NOTE
A lot of people seem to be confused about this: there are effectively two kernels that need to be patched: the obvious one: which Android runs on, and also the less obvious recovery.
- If you are running stock, flashing LLA onwards is enough to prevent further NAND damage
- If you are running a custom ROM or flashing a custom recovery, make sure you flash a patched recovery!
As of 14th January 2013:
EViollet said:
You have 3 different software parts on the GS3:
* bootloader
* recovery
* rom
The bootloader appears not to have the fix. NO bootloader is currently known to have the fix. So, any version will do. It won't protect you.
There is currently ONE known recovery that includes the kernel that fixes the SDS : philz recovery. No more.
ROM. This is what you're running on your phone. It comes bundled with a kernel. The SDS fix is included in the kernel. If you use the latest Siyah kernel, then you're safe. Up until the moment you boot recovery. Then you depend on the recovery you currently have on your phone.
Siyah kernel, however, has a peculiarity: it comes bundled with it's own TEMPORARY recovery that is used to manage 2 ROMs.
If you reboot in recovery from the Siyah STweaks tool, then you'll be using the Siyah recovery, which is correctly patched.
If you reboot in recovery from the ROM (or any other means of rebooting to recovery), you'll be back on your default recovery.
You can also "hijack recovery" from the Siyah STweaks tool. This will overwrite your current recovery with the Siyah recovery. And you will be protected whichever means of rebooting to recovery you choose.
Click to expand...
Click to collapse
rootSU said:
For those who don't care about being "safe" and only care about warranty, the step is simple.
Step 1: Do nothing
For those who don't care about being "safe" and only care about warranty AND are rooted
[Step 0: Flash ICS sboot]
Step 1: Reset flash counter
Step 2: Flash stock ROM [flashing patched firmware should make you "safe" too]
Click to expand...
Click to collapse
As of now ClockworkMod recovery is not patched.
Use PhilZ recovery instead.
Siyah kernel has been patched.
rootSU said:
Chainfire has updated to the ELLC recovery in Cf-auto-root
Click to expand...
Click to collapse
Update:
Patched Perseus Kernel
AndreiLux said:
Perseus alpha31 (09/01):
Removed my own security fixes and replaced them with the official Samsung one. I guess it can now be disclosed: exynos-mem was only one of multiple entry-points for the memory exploit. We discovered the s5p-smem exploit ourselves back in December but kept it quiet, I fixed that one back in version 29.2 without mentioning. Nobody was secure from a smart exploiter up until then, SuperCurios or Chainfire's software fixes are also just patching a single hole in what is a Swiss cheese. Kernels >v31 and beyond stock LLA are now the only truly protected ones.
Samsung's fix for the sudden death syndrome (SDS) included. It is caused by eMMC failure on phones with VTU00M internal memory chips with revision 0xF1. You can check your phone with the "eMMC Brickbug Check" in the Play Store (Ignore the message if it says you're not affected, the type and revision is what matters). The patch is a firmware soft-patch that is applied on every boot and MMC resume, it is not a permanent fix. You will need to stay forever on kernels which include the patch, this also includes updated recoveries and their embedded kernels.
Some other minor MMC changes extracted from Update 7 sources.
Click to expand...
Click to collapse
Bootloader Exclamation Mark
Apparently after flashing LLA bootloader, the red exclamation mark notoriously keeps reappearing unless you follow very specific steps, involving TraingleAway, recovery and ODIN flashing.
Original thread
EdgaBimbam said:
To start with, I'm flash addict and always trying to flash new roms/firmwares. However after flashing one of the newest samsung firmware i got this little red exlamation mark
Click to expand...
Click to collapse
Thread listing workarounds
Android 4.2 (CyanogenMod 10.1)
NFC Fix
It seems most devices coming from Stock Jellybean 4.1 to JB 4.2 are facing broken NFC. The current considered permanent solution is to:
1) Take a Nandroid backup
2) Flash a stock 4.0 ROM
3) Switch on WiFi and NFC
4) Restore from Nandroid
There is also a separate fix for CM10.1. ONLY apply the fix if your NFC is not working.
View attachment NFCFix.zip
Official CM10.1 discussion thread
Note: Not sure if this is a CM-specific issue. Let me know if that is the case.
don't you mean devices coming from Jellybean 4.1 to Jellybean 4.2? coming from ICS to JB 4.2.1 doesn't have the issue with NFC.
just checking.
EDIT: minor typo fixed.
you can add the downgrade from LLA bootloader to avoid the red exclamation mark..
''It seems most devices coming from Ice Cream Sandwich to Jellybean 4.2 are facing broken NFC.''
I think you meant devices coming from STOCK Jelly Bean to CM10.1 are facing the NFC problems
thegh0sts said:
don't you mean devices coming from Jellybean 4.1 to Jellybean 4.2? coming from ICS to JB 4.2.1 does have the issue with NFC.
just checking.
Click to expand...
Click to collapse
erto90 said:
you can add the downgrade from LLA bootloader to avoid the red exclamation mark..
Click to expand...
Click to collapse
PLUG313 said:
I think you meant devices coming from STOCK Jelly Bean to CM10.1 are facing the NFC problems
Click to expand...
Click to collapse
Done!
me thinks the NFC issue exists is because of the updated firmware in stock JB 4.1 and for some reason it can't communicate with CM10.1.
you can add my "KeepRil" zip if you like ... http://forum.xda-developers.com/showpost.php?p=35790900&postcount=1069
75markus said:
you can add my "KeepRil" zip if you like ... http://forum.xda-developers.com/showpost.php?p=35790900&postcount=1069
Click to expand...
Click to collapse
Is it a fix to a known issue of this phone? My understanding was that you need a matched RIL and Modem no matter what, i.e., it's not an "issue" as such, it's a technical constraint.
what about sdcard0/0 ... 0 issue ?
is not a real issue , i know , is just the way should be when running CM 10.1 Android 4.2.1
i think people found difficulties to understand how it works and how to deal with it in view of reverting to a Sammy Rom ... etc
i opened a thread in Q&A but i`m not sure if is complete or/and helpful enough
have a look please :angel:
http://forum.xda-developers.com/showthread.php?t=2075162
xanthrax said:
what about sdcard0/0 ... 0 issue ?
is not a real issue , i know , is just the way should be when running CM 10.1 Android 4.2.1
i think people found difficulties to understand how it works and how to deal with it in view of reverting to a Sammy Rom ... etc
i opened a thread in Q&A but i`m not sure if is complete or/and helpful enough
have a look please :angel:
http://forum.xda-developers.com/showthread.php?t=2075162
Click to expand...
Click to collapse
As far as I recall, It's an Android 4.2 "feature" (or issue, whatever way you look at it), not really specific to either CM or the I9300 device in particular.
pickandwhammy said:
As far as I recall, It's an Android 4.2 "feature" (or issue, whatever way you look at it), not really specific to either CM or the I9300 device in particular.
Click to expand...
Click to collapse
is this from your signature ?
ROM: CyanogenMod 10.1 (Android 4.2.1) Latest Nightly
don`t you have this sdcard 0 feature ?
of course is not specific to sg s3 but is specific for a ROM available for sg s4 ...
you confused me ... i`ll think about it ...
xanthrax said:
is this from your signature ?
ROM: CyanogenMod 10.1 (Android 4.2.1) Latest Nightly
don`t you have this sdcard 0 feature ?
of course is not specific to sg s3 but is specific for a ROM available for sg s4 ...
you confused me ... i`ll think about it ...
Click to expand...
Click to collapse
What I meant was it's a Google feature, which turns out to be not-very-user-friendly on phones (as opposed to tablets). It's not an issue with the device, be it hardware or firmware.
KERNEL issue or bootloader ?
pickandwhammy said:
The objective of this thread is to have all the knowns issues and known (or potential) fixes for the I9300 in an OP.
Exynos Root Exploit
It was fixed by Samsung in the XELLA/XELLC bootloader.
Click to expand...
Click to collapse
I thought Exynos bug was solved by KERNEL fix (XELLA , Perseus) .... NOT bootloader ??
could you please confirm ,
Thks
Got my answser : the exynos fix is in the kernel NOT in the booloader ...
philgalaxs3 said:
Got my answser : the exynos fix is in the kernel NOT in the booloader ...
Click to expand...
Click to collapse
Please post the thread/post URL elaborating on that, I'll update the first post with it.
pickandwhammy said:
Please post the thread/post URL elaborating on that, I'll update the first post with it.
Click to expand...
Click to collapse
Thks for the post update . But sorry I don't understand your "thread/post URL" remark ? seems Im on the correct thread and no need any URL ?
philgalaxs3 said:
Thks for the post update . But sorry I don't understand your "thread/post URL" remark ? seems Im on the correct thread and no need any URL ?
Click to expand...
Click to collapse
Okay. I thought the bootloader was initially believed to be the fix, and then the kernel, so I guess it was my misunderstanding. Since I've never run stock, I've never had any first-hand experience
Okay ! Not easy to know everything ! and thks again for your compile post :good:
Thanks
Sent from my GT-I9300 using xda app-developers app
Hello, first thanks alot of ur topic giving us solutions to protect our phones from SDS , but i wanna add something , there is another patched kernel beside Siyah one, its Perseus kernel .
Envoyé depuis mon GT-I9300 avec Tapatalk