Database Users

Siyah kernel 3.1RC6 and BRICKED GALAXY S2

On 22.4.2012 many people bricked their S2 while performing full wipe having Siyah kernel 3.1RC6.
What disappointed me is the update on development coming from developer in real hurry these days.
Developer need to test their development 1000 times before releasing it to users.
As a rule only we the user are responsible flashed kernel knowing the risk of RCs and BETAs.
We can't blame developer for this disaster.........
This thread is for those who bricked S2 and now are in process to recover their devices.
As a general habit, posts on bricked devices can be avoided easily by fan boys.
So now we need to help each other in the process of device recovery.
Please discuss here, what you are doing, any fix whether you found or not.
Thanks
Kachrukamble

kachrukamble said:
Yesterday many people bricked their S2 while performing full wipe having Siyah kernel 3.1RC6..
What disappointed me is the update on development coming from developer in real hurry these days.
Developer need to test their development 1000 times before releasing it to users
As a rule only we the user are responsible flashed kernel knowing the risk of RCs and BETAs.
We can't blame developer for this disaster, BUT.........
This thread is for those who bricked S2 and now are in process to recover their devices.
As a general habit, posts on bricked devices can be easily avoided by fan boys.
So now we need to help each other in the process of device recovery.
Please discuss here, what you are doing, any fix whether you found or not.
I will add Names for those who bricked S2 in OP
Thanks
Kachrukamble
Click to expand...
Click to collapse
Sad story bro. I know that feeling.
GM must be happy to hear that
Sent via my s2 monster

release candidate = not final = beta = not fully tested =still bugs = bricked = bug = because still beta= your own risk = your fault. Hope this helps.
Sent from my GT-I9100 using xda premium

Thanks for the info buddy. I'm in RC6 only. I was planning to do a full wipe and try out a ROM, and luckily I saw your post. Do let us know if you find a fix (for bricked phones). So can I just flash Siyah v3.1 and this problem will go away?

RobinRichard said:
Thanks for the info buddy. I'm in RC6 only. I was planning to do a full wipe and try out a ROM, and luckily I saw your post. Do let us know if you find a fix (for bricked phones). So can I just flash Siyah v3.1 and this problem will go away?
Click to expand...
Click to collapse
of course you can flash 3.1, it solves the issue. only the last updated rc6 had the problem. IF you are on rc6 better flash the updated kernel before doing any factory reset/data wipe to be in the safer side.
So did any one had a chance to solve it without going to service center??

bala_gamer said:
of course you can flash 3.1, it solves the issue. only the last updated rc6 had the problem. IF you are on rc6 better flash the updated kernel before doing any factory reset/data wipe to be in the safer side.
So did any one had a chance to solve it without going to service center??
Click to expand...
Click to collapse
What the hell happened? Efs cleared?
Gesendet von meinem GT-I9100 mit Tapatalk

I'm one of the "lucky" owners of a bricked-by-Siyah phone
I tried to flash a stock rom with odin but it doesn't work. I tried with:
- KI3, which is a 3-file-fw + .pit. The flash process hangs on data.img
- ILA2, which is a 1-file-fw. The flash with Odin is successful, but the phone can't boot and stays on the "Samsung Galaxy S2" screen all the time.
The only way to access recovery I found is to flash rogue recovery, but it can't mount internal sdcard so I can't flash anything

Ghost-of-the-Sun said:
I'm one of the "lucky" owners of a bricked-by-Siyah phone
I tried to flash a stock rom with odin but it doesn't work. I tried with:
- KI3, which is a 3-file-fw + .pit. The flash process hangs on data.img
- ILA2, which is a 1-file-fw. The flash with Odin is successful, but the phone can't boot and stays on the "Samsung Galaxy S2" screen all the time.
The only way to access recovery I found is to flash rogue recovery, but it can't mount internal sdcard so I can't flash anything
Click to expand...
Click to collapse
if you can access download mode, then you have many ways to recover your s2 without reaching SC

RobinRichard said:
Thanks for the info buddy. I'm in RC6 only. I was planning to do a full wipe and try out a ROM, and luckily I saw your post. Do let us know if you find a fix (for bricked phones). So can I just flash Siyah v3.1 and this problem will go away?
Click to expand...
Click to collapse
Happy to hear that you saved, many people didnt
Sent from my HTC EVO 3D X515m using Tapatalk

bala_gamer said:
if you can access download mode, then you have many ways to recover your s2 without reaching SC
Click to expand...
Click to collapse
Yes I can access it, but the internal sdcard is never mounted so I can't use my phone... I hope somebody will find and share a fix for this problem :-(

Unless the hardware is damaged, every full-bricked Galaxy S2 can be recovered witha J-tag repair.
If one does not have the hardware hardware to perform such a repair, he has to either purchase it or find somebody that has it nearby.

Ghost-of-the-Sun said:
Yes I can access it, but the internal sdcard is never mounted so I can't use my phone... I hope somebody will find and share a fix for this problem :-(
Click to expand...
Click to collapse
Did anyone try flashing a boot loader? Nothing to lose now really
Sent from my GT-I9100 using xda premium

Mine is bricked, partly due to me not reading the posts. I'm able to get into download mode, will have a play with Odin on the off chance something fixes it but I guess it's unlikely...

Ghost-of-the-Sun said:
Yes I can access it, but the internal sdcard is never mounted so I can't use my phone... I hope somebody will find and share a fix for this problem :-(
Click to expand...
Click to collapse
Try to enter 3e recovery and factory reset phone and see what happens mate. Wait for like 5 mins and if buttons light up ur good...
Gesendet von meinem GT-I9100 mit Tapatalk

Dang I'm on siyah rc6 still running, if I flash 3.1 or another kernel its safe right?
Its safe using cwm app

is CWM available at all on Siyah bricked mobiles?

bartoloandre98 said:
Dang I'm on siyah rc6 still running, if I flash 3.1 or another kernel its safe right?
Its safe using cwm app
Click to expand...
Click to collapse
flash immediately 3.1 without wipe
---------- Post added at 05:59 PM ---------- Previous post was at 05:56 PM ----------
itchetrigr said:
is CWM available at all on Siyah bricked mobiles?
Click to expand...
Click to collapse
its available but working with errors because of the mount problem of some partitions.

itchetrigr said:
is CWM available at all on Siyah bricked mobiles?
Click to expand...
Click to collapse
Bricked means dead in this case, you can't do anything with dead piece..

Well this just reinforces my belief to stick with stock kernels.
To the people with bricked phones, hope you guys are able to unbrick it without too much pain!

Does anyone know how to find a jtag service in korea, seoul? my phone is fully bricked and i need it back asap ....

Anyone bricked from iMilka's AOSP/CM9?

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.

Samsung responds to Galaxy S II / Note eMMC bug problem

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

It was nice to meet you!!

It was nice 8 months experience,just Super bricked my Note while perfotming a wipe with CWM,too bad couldnt claim the warrenty.
Thanks for everyone who helped me during this period,both Developers and Members.
Jack

Sorry for your phone man.
Btw which kernel were you using?

Boy124 said:
Sorry for your phone man.
Btw which kernel were you using?
Click to expand...
Click to collapse
German LRK DBT stock 4.0.4 and it was running fine no problems,just wiped it to test the Paranoid Android JB 4.1.1,which was actually the last thing it did.

I see. But you can't flash roms using stock recovery. Anyways it confirms the bug still exists.

What CWM did you use or did you wipe from stock recovery?
Does it give any sign of life?
If it boots you can use: https://play.google.com/store/apps/details?id=net.vinagre.android.emmc_check
to see if you have emmc damage.

jgaviota said:
What CWM did you use or did you wipe from stock recovery?
Does it give any sign of life?
If it boots you can use: https://play.google.com/store/apps/details?id=net.vinagre.android.emmc_check
to see if you have emmc damage.
Click to expand...
Click to collapse
Unfortunately doesnt boot up,just stuck on the Gt-7000 logo but the download screen works,however when try to flash with PC Odin stops at the factoryfs.img which after research discovered is a Superbrick symptom.

hagba said:
too bad couldnt claim the warrenty.
Click to expand...
Click to collapse
Hello hagba, since you cannot claim warranty have you thought of getting your device repaired via the Samsung service centre in your region?
I would suggest you to enquire about the repair cost and then make a suitable decision.

Have you tried this? it worked for many users.
http://forum.xda-developers.com/showthread.php?p=26285877

YLNdroid said:
Hello hagba, since you cannot claim warranty have you thought of getting your device repaired via the Samsung service centre in your region?
I would suggest you to enquire about the repair cost and then make a suitable decision.
Click to expand...
Click to collapse
First thing on monday,

dr.ketan said:
Have you tried this? it worked for many users.
http://forum.xda-developers.com/showthread.php?p=26285877
Click to expand...
Click to collapse
Dr.Ketan,
I have tried the PIT procedure,but its such a long and tedious process Im not sure will be able to make viable partition for normal usage.
However will see what Samsung does on Monday.

So does this mean that Stock ROMS are still unsafe to wipe rather than how samsung claims that Stock ROM wont brick?
Did you report this to Entropy? Did you wipe after flashing Paranoid ROM successfully or did you wipe on stock. If it was after succesfully flashing the CM10 based JB ROM, it should mean that CM10 doesnt have MMC_CAP_ERASE disabled or maybe no ICS kernel is safe.
Should report to Entropy if you didnt.

He already.wrote 'wipe it to test jb' means wiped on.stock.
Entropy aleeady aware of this (i have already reported 2 case on 4.0.4). And he hav mentioned on his thread, stock ics are known unsafe kernels.
Sent from my GT-N7000 using xda premium

dr.ketan said:
He already.wrote 'wipe it to test jb' means wiped on.stock.
Entropy aleeady aware of this (i have already reported 2 case on 4.0.4). And he hav mentioned on his thread, stock ics are known unsafe kernels.
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
I made a mistake of wiping twice from Settings under android in Indian Stock DDLP8 stock 4.0.3 but luckily never bricked. But now I take care not to. But do you think I may have caused damage in the first two wipes? I see no issues till now but just asked.

It cause damage once in while, not every wipe/reset result to brick (good if it was like that, sammy must have find solution then)
Still if you have any doubts find 'emmc brick bug' application from market n scan ur device.
Sent from my GT-N7000 using xda premium

dr.ketan said:
It cause damage once in while, not every wipe/reset result to brick (good if it was like that, sammy must have find solution then)
Still if you have any doubts find 'emmc brick bug' application from market n scan ur device.
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
I have the affected emmc firmware VYLOOM 0x19. Its just that I turned out to be lucky. I dont believe Samsung would fix the Indian firmware (4.0.3) while the bug remains on the latest 4.0.4 ROMS. If there is a fix from Samsung, we Indians are the ones who usually get it last. But strangely, I havent heard of any superbricked Indian Notes in this forum.

satishp said:
So does this mean that Stock ROMS are still unsafe to wipe rather than how samsung claims that Stock ROM wont brick?
Did you report this to Entropy? Did you wipe after flashing Paranoid ROM successfully or did you wipe on stock. If it was after succesfully flashing the CM10 based JB ROM, it should mean that CM10 doesnt have MMC_CAP_ERASE disabled or maybe no ICS kernel is safe.
Should report to Entropy if you didnt.
Click to expand...
Click to collapse
I think Samsung's claim was that you won't get bricked if you stick to stock and don't root. I'm not saying that's true . Even seems unlikely since I think you can factory wipe from the settings without root, IIRC (memory's rusty, haven't been on a stock ROM for ages).
There were some bricks with CM10, but only from people who flashed from stock ICS or stock ICS based ROMs. Flashing from the safe ICS kernels seems to still be safe.
satishp said:
But strangely, I havent heard of any superbricked Indian Notes in this forum.
Click to expand...
Click to collapse
Maybe that's because Indians are careful enough to read the instructions before risking their device? I doubt it's because Indian Notes have had some special pixie dust sprinkled over them while they passed customs.

If you dont mod your device then how many chances are.there to make hard reset device?
I know lot ppl they purchasing and selling.device without single reset.
So rooting opens.100 ways to explore ur device, simultaneously opens 100 ways to put u in situation,u needs reset. That is the only reason rate.of bricking is high with rooted device, but if you read carefully and avoid reset/wiping there is almost zero chances to brick.
And yes if you look, compare to selling of notes in india, u don't see indians are quite less on forum?
Sent from my GT-N7000 using xda premium

dr.ketan said:
If you dont mod your device then how many chances are.there to make hard reset device?
I know lot ppl they purchasing and selling.device without single reset.
So rooting opens.100 ways to explore ur device, simultaneously opens 100 ways to put u in situation,u needs reset. That is the only reason rate.of bricking is high with rooted device, but if you read carefully and avoid reset/wiping there is almost zero chances to brick.
And yes if you look, compare to selling of notes in india, u don't see indians are quite less on forum?
Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
I'm really worried because you said if I avoid wiping I'm almost zero chance of briking.. I got my note clean, I mean I don't dare to put music and movies into it because then I don't dare to delete all those files... Will this brick my phone? I'm stock 4.0.4 rooted
Enviado desde mi GT-N7000 usando Tapatalk 2

Obviously the culprit is wiping with CWM,I have factory Reset million times with no consequences at all,and just once with CWM was enough to Superbrick it,and yes I was on stock ROM.

msedek said:
I'm really worried because you said if I avoid wiping I'm almost zero chance of briking.. I got my note clean, I mean I don't dare to put music and movies into it because then I don't dare to delete all those files... Will this brick my phone? I'm stock 4.0.4 rooted
Enviado desde mi GT-N7000 usando Tapatalk 2
Click to expand...
Click to collapse
It says big files shudn't be deleted. Though frankly speaking i have not seen any case brick by that, though we cant ignore comments from recognised developer.
But wat best idea i found to manage file is
Connect device with PC as mass storage and manage files from PC explorer. I believe that is safe way.
hagba said:
Obviously the culprit is wiping with CWM,I have factory Reset million times with no consequences at all,and just once with CWM was enough to Superbrick it,and yes I was on stock ROM.
Click to expand...
Click to collapse
That was your bad luck this time, otherwise both have same effect.

[GT-I9300] Compilation of issues and fixes

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