Samsung working on Emmc brick fix

Search This thread
By:
Advanced…
A

abhijit038

Senior Member
Sep 24, 2010
67
14
They would only make any endeavour if the bug is present in stock Roms ,which seems unlikely.Apparently Samsung has already tested their Stock Roms and the results were negative.

---------- Post added at 12:22 AM ---------- Previous post was at 12:19 AM ----------

There is a similar thread about this topic http://xdaforums.com/showthread.php?t=1679829
 
M

mdrjr

Senior Member
May 5, 2008
76
64
39
SP
A

abhijit038

Senior Member
Sep 24, 2010
67
14
mdrjr said:
The SuperBrick bug does affect stock rom.
Click to expand...
Click to collapse
Oh..I meant stock NON ROOTED Rom.Incidentally, I tested it myself. I have wiped my phone from factory recovery for over 20 times; I am on ZSLPF.
By the way, there hasn't been an incident reported so far where a person on stock non rooted ICS ROM bricked his phone.Even Samsung dev. were unable to reproduce the bug.Please refer to the link.aforementioned in my last post.
 
PoisonWolf

PoisonWolf

Senior Member
Feb 8, 2009
2,166
274
abhijit038 said:
Oh..I meant stock NON ROOTED Rom.Incidentally, I tested it myself. I have wiped my phone from factory recovery for over 20 times; I am on ZSLPF.
By the way, there hasn't been an incident reported so far where a person on stock non rooted ICS ROM bricked his phone.Even Samsung dev. were unable to reproduce the bug.Please refer to the link.aforementioned in my last post.
Click to expand...
Click to collapse

When you wiped 20 so called times, did you wipe, boot into the rom, install apps or do a titanium restore, then go into recovery and then only wipe? Or did you simply hit wipe 20 consecutive times?
 
M

M3TALLICA

Senior Member
Nov 14, 2011
1,516
500
Great news.
Considering how slow samsung is on software updates, I think we'll get it in Q4 2012
cough...cough...

Thanks a lot Entropy, Chainfire and all other devs.
You guys are real heros. :)
 
  • Like
Reactions: Markuzy and niko26
P

panyan

Senior Member
Oct 4, 2010
1,214
224
XDA Forums
Boy124 said:
Great news.
Considering how slow samsung is on software updates, I think we'll get it in Q4 2012
cough...cough...

Thanks a lot Entropy, Chainfire and all other devs.
You guys are real heros. :)
Click to expand...
Click to collapse

I imagine this will be a priority because of the scope of affected devices and the possible backlash from this
 
A

abhijit038

Senior Member
Sep 24, 2010
67
14
PoisonWolf said:
When you wiped 20 so called times, did you wipe, boot into the rom, install apps or do a titanium restore, then go into recovery and then only wipe? Or did you simply hit wipe 20 consecutive times?
Click to expand...
Click to collapse
Yes, I did installed my 100+ usual apps in each case after a wipe. However, I didn't use titanium restore as it requires root.What I meant to say is that stock non-rooted ICS kernels released by samsung are apparently safe. I think we should all wait for some time until we get further insight into this problem.Perhaps then we can safely root our phones, and use CWM and all.
Talking about the so-called safe kernels, two people on franco r5 bricked their phones
http://xdaforums.com/showthread.php?p=27095985#post27095985
http://xdaforums.com/showthread.php?t=1696037
I guess the cause of bricking issue is not readily apparent as it appears to be(we have been blaiming stock ICS kernels till now).
 
Last edited:
wonsanim

wonsanim

Senior Member
Jan 25, 2007
1,548
97
Great News!I hope this come soon my device is running LQ2 but I don't like the risk:cool:
 
D

dbreloaded

Senior Member
Sep 2, 2010
69
12
London
What about if a stock unrooted ICS user boots into recovery and factory resets? Surely that could issue the bugged command and trigger the emmc corruption? I don't think its root that is the problem i think the problem is wiping data...

IF the devs have said that all ics kernels (ALL would include those unrooted and released by Samsung) are unsafe then I think we should take note (lol) of the expert warnings and not wipe our phones if ICS is installed and if u really must wipe follow the posts and revert back to gingerbread or alternative...

abhijit038 said:
Yes, I did installed my 100+ usual apps in each case after a wipe. However, I didn't use titanium restore as it requires root.What I meant to say is that stock non-rooted ICS kernels released by samsung are apparently safe. I think we should all wait for some time until we get further insight into this problem.Perhaps then we can safely root our phones, and use CWM and all.
Talking about the so-called safe kernels, two people on franco r5 bricked their phones
http://xdaforums.com/showthread.php?p=27095985#post27095985
http://xdaforums.com/showthread.php?t=1696037
I guess the cause of bricking issue is not readily apparent as it appears to be(we have been blaiming stock ICS kernels till now).
Click to expand...
Click to collapse
 
Last edited:
PoisonWolf

PoisonWolf

Senior Member
Feb 8, 2009
2,166
274
abhijit038 said:
Yes, I did installed my 100+ usual apps in each case after a wipe. However, I didn't use titanium restore as it requires root.What I meant to say is that stock non-rooted ICS kernels released by samsung are apparently safe. I think we should all wait for some time until we get further insight into this problem.Perhaps then we can safely root our phones, and use CWM and all.
Talking about the so-called safe kernels, two people on franco r5 bricked their phones
http://xdaforums.com/showthread.php?p=27095985#post27095985
http://xdaforums.com/showthread.php?t=1696037
I guess the cause of bricking issue is not readily apparent as it appears to be(we have been blaiming stock ICS kernels till now).
Click to expand...
Click to collapse

You're either lucky or a chunk of your internal NAND blocks are close to dead from the improper wear handling.

You're one person, a nobody on the internet, a metaphorical speck of dust. Yet you're trying to refute the claim against voices directly from Google that has spoken about the brickbug.

This problem has been verified on Google's side, what more do you need? For someone to brick your phone for you?
 
  • Like
Reactions: NuclearStrike, krazman325, ponlayookm and 3 others
L

letters_to_cleo

Senior Member
Jan 23, 2012
780
234
Portsmouth, N.H.
Hey let the guy speak for himself.

If he says that he hasn't brick his Note yet, then so be it. The last time I've checked here in XDA, we're still entitled to our opinions right? and nobody should try to impose or dictate one's judgment to another.

Categorically, I guess he maybe right in saying that the process or likely case your going to get that bug is for you to root your phone and upgrade to a Samsung Stock ICS (or custom ICS) and wiping your phone after. (It doesn't matter if you wipe it once or twice, the hardbrick bug can occur when you least expected it).

The process of just sticking to a non rooted Stock GB Note (even if you change GB ROMS and just sticking to GB all the time) would not get you in trouble of encountering the dreaded bug.
 
A

abhijit038

Senior Member
Sep 24, 2010
67
14
PoisonWolf said:
You're either lucky or a chunk of your internal NAND blocks are close to dead from the improper wear handling.

You're one person, a nobody on the internet, a metaphorical speck of dust. Yet you're trying to refute the claim against voices directly from Google that has spoken about the brickbug.

This problem has been verified on Google's side, what more do you need? For someone to brick your phone for you?
Click to expand...
Click to collapse

I guess you haven't referred to the link in my previous post.To support verity of my claim, I'd post it for you again http://xdaforums.com/showthread.php?t=1679829
May I add that hypothetical facts can never disrate credence in reality.
It might be possible that real-world tests are quite different from proposition.
Could you cite one case where a stock non-rooted user bricked his phone ? I think you couldn't.
Even if a user were to encounter a bug on non rooted stock, he'd have the warranty to get it repaired.
Why should he be paranoid about it, eh ?
Talking about your claim, it seems irrelevant in context.That one was for Galaxy nexus,isn't ? By the way,have you ever considered that architecture of two devices aren't same. There are many parameters which vary from device to device.
 
Last edited:
PoisonWolf

PoisonWolf

Senior Member
Feb 8, 2009
2,166
274
abhijit038 said:
I guess you haven't referred to the link in my previous post.To support verity of my claim, I'd post it for you again http://xdaforums.com/newreply.php?do=newreply&p=27164409
May I add that hypothetical facts can never disrate credence in reality.
It might be possible that real-world tests are quite different from proposition.
Could you cite one case where a stock non-rooted user bricked his phone ? I think you couldn't.
Even if a user were to encounter a bug on non rooted stock, he'd have the warranty to get it repaired.
Why should he be paranoid about it, eh ?
Talking about your claim, it seems irrelevant in context.That one was for Galaxy nexus,isn't ? By the way,have you ever considered that architecture of two devices aren't same. There are many parameters which vary from device to device.
Click to expand...
Click to collapse

Thanks for acknowledging. Enough said.

I'll talk to you again in a few months once subsequent Samsung Official ICS ROMs disable MMC_ERASE or the chain that makes the bug possible.

Till then, keep believing that the bug doesn't exist.
 
A

abhijit038

Senior Member
Sep 24, 2010
67
14
PoisonWolf said:
Thanks for acknowledging. Enough said.

I'll talk to you again in a few months once subsequent Samsung Official ICS ROMs disable MMC_ERASE or the chain that makes the bug possible.

Till then, keep believing that the bug doesn't exist.
Click to expand...
Click to collapse
Don't get me wrong. I didn't intend to say that Samsung kernels are without flaws. Perhaps after injection of root the bug becomes apparent Even I'd love to see bug free kernel.Even Samsung people are ready for help . Here is the link to the thread http://xdaforums.com/showthread.php?t=1679829
 
Last edited:
musashiro

musashiro

Senior Member
Jul 1, 2011
718
86
Tarlac
Come on.. the bug exists. after all the technical stuff investigated and even google engineer is involved, you are still claiming that your little experiment proves otherwise. Do you want this thread to be cleaned by a mod as well?

Sent from my GT-N7000 using XDA
 
A

abhijit038

Senior Member
Sep 24, 2010
67
14
musashiro said:
Come on.. the bug exists. after all the technical stuff investigated and even google engineer is involved, you are still claiming that your little experiment proves otherwise. Do you want this thread to be cleaned by a mod as well?

Sent from my GT-N7000 using XDA
Click to expand...
Click to collapse

Yes, bug might be present,but I guess it's only after rooting that it becomes apparent and causes bricking. Nonetheless, it's only after trials and experimentation that we may conclude a credible hypothesis. So we should test under all scenarios.


Sent from my GT-N7000 using xda premium
 
L

letters_to_cleo

Senior Member
Jan 23, 2012
780
234
Portsmouth, N.H.
abhijit038 said:
Yes, bug might be present,but I guess it's only after rooting that it becomes apparent and causes bricking. Nonetheless, it's only after trials and experimentation that we may conclude a credible hypothesis. So we should test under all scenarios.


Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse

the bug is inherent already the moment you check and find out you have those
'MAG4FA, VYL00M, or KYL00M fwrev 0x12 || 0x19 < 0x25' (you can download the 'Gotbrickbug' app that ChainFire posted on another thread on this forum.

ROOTING DOES NOT IN NO WAY TRIGGER AND CAUSES THE BRICK. It is when your in Stock ICS with an ICS kernel and doing a full dalvik/wipe of your phone that your tantamount to encounter the hardbrick bug.

A credible test I can suggest on your part I say would be to flash your phone to stock Samsung ICS firmware, and with NO ROOT, see if you can fully wipe your phone over and over, let's say 15 times.

Let's check the outcome (after you've wiped your phone 15x) shall we?


Cheers,

:p
 
A

abhijit038

Senior Member
Sep 24, 2010
67
14
letters_to_cleo said:
the bug is inherent already the moment you check and find out you have those
'MAG4FA, VYL00M, or KYL00M fwrev 0x12 || 0x19 < 0x25' (you can download the 'Gotbrickbug' app that ChainFire posted on another thread on this forum.

ROOTING DOES NOT IN NO WAY TRIGGER AND CAUSES THE BRICK. It is when your in Stock ICS with an ICS kernel and doing a full dalvik/wipe of your phone that your tantamount to encounter the hardbrick bug.

A credible test I can suggest on your part I say would be to flash your phone to stock Samsung ICS firmware, and with NO ROOT, see if you can fully wipe your phone over and over, let's say 15 times.

Let's check the outcome (after you've wiped your phone 15x) shall we?


Cheers,

:p
Click to expand...
Click to collapse

I wouldn't be blathering about it, had I not done it by myself.
Please refer to my previous posts.I have already wiped my phone for 20 times on ZSLPF, having 100+ apps installed in each case.
I am on 0x19 too.

Sent from my GT-N7000 using xda premium
 
Last edited:
L

letters_to_cleo

Senior Member
Jan 23, 2012
780
234
Portsmouth, N.H.
abhijit038 said:
I wouldn't be blathering about it, had I not done it by myself.
Please refer to my previous posts.I have already wiped my phone for 20 times on ZSLPF, having 100+ apps installed in each case.
I am on 0x19 too.

Sent from my GT-N7000 using xda premium
Click to expand...
Click to collapse
so your main point of contention on this, is that you'll encounter the brick bug just by simply ROOTING your phone? Is that it?

have you lately tried changing ICS ROMS (still UNROOTED) and doing the full wipe again 20x? (if your main point as you say that just by ROOTING the phone causes the brickbug) then how about you give this a shot as well?

:cool:
 
You must log in or register to reply here.

Similar threads

dr.ketan
[24sept12]How to Root/Unroot Samsung Galaxy Note + CWM
Replies
3K
Views
2M
N
notauseranymore
hg42
PIT file method to revive your phone from a MMC_CAP_ERASE brick
Replies
1K
Views
422K
kraken77
kraken77
T
[REF] Samsung firmware naming convention and explanation
Replies
58
Views
270K
midoshbl1
midoshbl1
prabhu1980
  • Poll
Let's unbrick your phone - Guide (Soft Brick, Super Brick, Hard Brick, OTA Brick)
Replies
216
Views
182K
D
Deleted member 9635294
supercurio
  • Locked
Galaxy Note colour rendering issue: started working on it.
Replies
986
Views
226K
supercurio
supercurio

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 60
    E
    Entropy512
    I am sooo fried after the meeting. It was quite long.

    Bad news: It turns out that the repair process turns eMMC chips from "damaged" to "completely toast" pretty often. As a result Samsung understandly does not want to release the info to the "wild" as it can easily kill a device if used improperly. Example - if a user thinks they have eMMC damage when they don't, and then tries to repair it - they have a high likelihood of making the problem worse. I strongly recommended that they talk to the RIFFbox team and a few JTAG repair specialists so that at least they have a chance of bringing these devices back - JTAG repair services have the technical skills and equipment to make a reliable determine on whether to perform a "last resort" attempt of fully wiping/resetting the eMMC.

    Samsung is 100% certain that non-secure erase as implemented by their stock recovery is safe. I still have concerns that in rare cases it can do damage, but unfortunately, every user that has reported eMMC damage caused by stock recovery has either sent their device back for warranty service already, or fell silent when asked for more information. There are also simply not many reports of this - maybe 4-5 on Note, and 4-5 on other devices two weeks ago when a bunch of ICS updates went out to other devices. Without more evidence, there is simply nothing I can do here.

    There is of course, the issue of kernels permitting secure erase commands through when they shouldn't - I think they finally realize how many ways that a secure erase command can be triggered, and how it is critical that secure erase is blocked by the kernel. They are working on deploying a fix to newer kernels that will take secure erase commands and replace them with nonsecure erase, so at least protection will improve.

    I would feel more comfortable if erase commands were completely blocked, but there is simply not enough evidence of problems with non-secure erase to have Samsung change their opinion on its safety.

    What is interesting is that there seem to be a lot of issues with internal communication within Samsung. In some cases it could be language barrier issues. It was apparently never clear to my contact that this was seen as long ago as December/January by the Epic 4G Touch community. Also, at least some of their engineers are swearing up and down that MMC_CAP_ERASE has always been enabled in the I9100 - even though we know without any doubt that it has been absent in I9100 builds previous to XWLPM and XXLQ5. There's a possibility this may have been a miscommunication somewhere - because someone saw MMC_CAP_ERASE in sdhci.c, they said the kernel had it - but what matters is whether it is present in mshci.c

    In general, I think this whole mess is a no-win situation for everyone involved. The only really good thing to come out of it is - my contact at Samsung is working with the XDA administrators to open up more communication channels so that if something like this happens again, it'll be caught earlier.

    I still have a bunch of followup I need to do in terms of getting them some additional information... but for now, I'm exhausted.
    View
    51
    androidindian
    androidindian
    More info and source credits here, thanks to codeworkx https://plus.google.com/111398485184813224730/posts/21pTYfTsCkB.


    ATTENTION:
    We've contacted Samsung about the problem where performing a mmc erase could hardbrick your phone (i9100, i9100g, n7000, m250 - MAG4FA, VYL00M, and KYL00M with firmware revision 0x19 // T989 and I727 with fw rev 0x12) if it's having a faulty emmc chip.
    Read this thread for more informations about it: http://xdaforums.com/showthread.php?t=1644364

    They're working as hard as possible on a clean solution which will be ready soon.

    Please be patient and try to not flash any leaked kernels or kernels based on sources where MMC_CAP_ERASE is present.

    This app http://xdaforums.com/showpost.php?p=27014974&postcount=1 can be used to identify if your phone is affected or not.

    CM9 kernels are safe to flash.

    Please share!

    Update 14:56 CEST:
    Patches will be out in form of new official ROMs and also sourcecode releases after testing, which might take some time.
    Click to expand...
    Click to collapse

    New Clarifications by Entropy : http://xdaforums.com/showpost.php?p=28416723&postcount=403 - Must Read.

    To check whether your phone has the brick bug, download the Got Brickbug app from Chainfire: http://xdaforums.com/showthread.php?t=1693704

    Also do read the article on xda for more info.: http://www.xda-developers.com/android/samsung-diligently-working-towards-hardbrick-fix/
    View
    25
    E
    Entropy512
    Right now, things aren't entirely definite, but it looks like I am probably going to be having a face-to-face meeting with Samsung next week.

    They are unwilling to provide AdamOutler with what is required to repair devices with damaged bootloaders, but we at least will be slightly better off than we were before.

    This is what is currently being discussed since USB-booting (See Unbrickable Mod for Galaxy S1/Nexus S devices - We are missing a small but critical component for Unbrickable to be deployed on Galaxy S2 family devices) is not something they are willing to discuss even though I feel it is necessary to deploy a proper solution to end users.

    1) A solution will only be available for users whose devices can still boot a kernel. If a device has a damaged bootloader or the kernel partition is damaged, these devices will be unrepairable by users. It may become possible to recover these devices via JTAG.
    2) The solution will require wiping the chip, repartitioning, and then repopulating bootloaders all in one go. This is going to have a very high failure rate - after all, even merely overwriting the bootloaders in an OTA (see Captivate Froyo and T-Mobile Nexus S ICS upgrade fiascos) often can kill a device - we have to wipe the chip, power cycle the eMMC chip from the kernel and reinitialize the MMC subsystem, repartition the chip, then rewrite the bootloaders.

    The little bit of good news is that at least these devices will become recoverable via JTAG (which they currently are not). The bad news is that a reliable solution will not be deployable to end users - a partial unreliable one will be, but I fully expect it to fail and require JTAGging for many.

    I'm really pushing for more, but it's not looking good.

    So the summary right now:
    If your device boots but is missing chunks of storage, we will possibly be able to fully restore the device
    Devices in the category above that fail to fully repair will have all storage space back, but will require JTAG to boot again
    Devices that do not boot will still require JTAG, however it should become possible for JTAG shops to repair the damage
    View
    22
    E
    Entropy512
    An update: Our conference call last night went very well. I'm now 90% certain we will, at the very least, be able to turn "superbricks" into JTAG-recoverable "traditional hardbricks". Everyone is hopeful that some developers will be receiving this information sometime next week (do note that it is going to take some time to develop this information into a deployable solution - how long really depends on what I will discuss below.)

    This is of course not ideal, since it means the device is still bricked (but at least repairable using known methods), but we've made our case to Samsung why it is highly beneficial to everyone involved if the bits and pieces required to make Unbrickable Mod available for Exynos4 devices are provided. With that information, we will not only be able to fully recover "superbricked" devices to operational state, but will be able to recover many traditionally hardbricked devices to an operational state too. (Unfortunately, depending on the nature of traditional hardbricks, some may require resistor modifications to start the process. The "superbrick" recovery process fully wipes everything, so the device will USB-boot without any resistor mods.)

    One caveat: Right now, the process of recovering from a superbrick will ALSO nuke your EFS partition. EVERYONE who is able to should make a backup of their EFS partition to their PC (or at a bare minimum, an external SD card) ASAP! Those who have lost their EFS partition to Superbrick damage are in a unique and unfortunate situation, there are some possible paths for recovery here though that the ERD community, XDA admins, and a few others are looking into. The problem is that regenerating the EFS can change a phone's IMEI, which presents unique ethical and legal challenges.

    As to being stuck on GB - as long as you use a safe kernel (such as Speedmod, Franco's kernel, or the CM9 kernel) you should be fine.
    View
    17
    E
    Entropy512
    breckbit said:
    At least hardwareside, samsung keep on replacing bricked mobo´s with the same vulnerable eMMC chipset / 0x19 - as they did in my case. for my sake they replaced it as case of warranty.

    is there any possibility at all - in case samsung develope it - to update the eMMC firmware?!
    Click to expand...
    Click to collapse
    To my knowledge, not without fully wiping the chip, including the bootloaders. This will turn your phone from "superbrick" to "traditional hardbrick" - which is at least JTAG-recoverable. However Samsung will not release the information required to do this, nor will they give Mr. Sumrall permission it seems.

    prasad.adam said:
    At the moment, there is a mystery around extremely low failure rate on virgin stock ROM vis-a-vis rooted ROM.

    Entropy512 is working on unraveling the same. Hope he gets some concrete lead on the same. Patience till then.
    Click to expand...
    Click to collapse
    Yeah. I have the explanation why, the problem is I have been asked not to share it by the source. I'm in the process of drafting a response to said source that includes a bit of yelling... It explains why the damage rate is different between stock recovery and CWM - however the damage rate for stock recovery, while lower, is nonzero.


    abhijit038 said:
    Yes you are right my friend. NO ONE HAS bricked on official NON ROOTED ICS.
    When I ask for citation to add credence to their claim of Stock non ROOTED ICS being buggy, I always get blank response.


    Sent from my GT-N7000 using xda premium
    Click to expand...
    Click to collapse
    PRESENCE OF THE su BINARY IN SYSTEM DOES NOT MATTER. IT DOES *NOTHING* WHEN YOU ARE IN RECOVERY. ONLY KERNEL AND INITRAMFS MATTER THEN.

    You obviously don't even remotely understand how recovery works, such as the fact that everything in recovery runs directly from an initramfs image that is packed into the kernel itself. What is present in /system simply does not matter - if a brick happend with stock kernel and Samsung stock recovery, that is enough to prove that configuration is dangerous because the contents of /system do not matter. Especially not the presence of an su binary, considering that RECOVERY ALWAYS RUNS WITH ROOT PRIVELEGES!!!

    Arobase40 said:
    First, forgive for my english which if far from perfect and may not reproduce my real thoughts...

    The problem is even if one knows there is a emmc bug, nobody knows for sure where it's located and how if works, in order to reproduce the effect...
    I've tried to read all informations and posts about this bug but there were some many sparse threads, so it's hard to follow them all. ^^
    Click to expand...
    Click to collapse
    Bull****. We know where it's located and how it's triggered. It's in the flash chip, it's triggered by ERASE commands sent to the flash chip.

    I may be not an expert at emmc, but at least an "old" dev (but not yet retired ;) ) (and among other occupations), and that's the first time I encountered such a bug that causes intermittent flaw on the way a bug is supposed to be working. :D
    Click to expand...
    Click to collapse
    Considering even the Google engineer that described the bug said it's intermittent, this isn't a surprise.

    If was first explained the MMC_CAP_ERASE flag (and CONFIG_MMC_DISCARD, CONFIG_MMC_DISCARD_MERGE, and CONFIG_MMC_DISCARD_MOVINAND set) could be the true cause of the bug, but that doesn't explain why in the same condition GB doesn't cause bricked or corrupted devices, nor why removing the MMC_CAP_ERASE flag is not enough to solve the problem (except maybe with ICS for i9100, but why ICS and not GB ?) ???
    Click to expand...
    Click to collapse
    Please read before spouting utter and total bull****. It has already been explained by Mr. Sumrall why Gingerbread doesn't cause bricks - Gingerbread recoveries and update-binaries don't attempt to do wipe commands. That's how Chainfire has rendered recent CF-Root releases "safer" to use with affected kernels, and how CM9 has taken measures to reduce the chances of damage when flashing CM9 now that there is much more information about the bug.

    And you clearly are completely uninformed if you think MMC_CAP_ERASE removal doesn't protect from damage - there has not been a single incident of the bug triggering from someone confirmed to actually be running a "safe" kernel. The one person who bricked after flashing Franco R3 with Mobile Odin never verified the flash before dropping into recovery - and MO is rather notorious for occasionally failing to flash.

    It was also explained than erasing large files could also brick or corrupt some devices (only with internal or also with external storage ?), the reason I asked Entrophy, in another thread (Epic 4G Touch), why the MMC_CAP_ERASE flag was not removed from sdhci.c from latest ICS source code for i9100 and there was no problem... I now sdhci.c is dealing with external SD Card, and I haven't got time to develop my explanation not to study the whole source code, but I was wondering if it was using a complete different instructions set to do the erase/Trim operation or if at a time or another it was not also calling some instructions from emmc and so the incriminated firmware... Does that also mean there are 2 totally different source codes to deal with internal storage or external storage ??? ^^
    Click to expand...
    Click to collapse
    It was never "explained" that erasing large files could also brick - it was just speculated in the early days before Mr. Sumrall provided valuable information about the bug. Erasing large files is safe because none of our file systems are mounted with the "discard" flag. (Yeah, I need to update the PSA in this regard, it's a bit outdated now...)

    There are not two totally different source code bases to deal with internal and external storage - it's 90% common code. However the host driver is where there are differences, and the SDHCI host driver is only used for the external SD card and the wifi chip (SDIO). The internal storage is the MSHCI driver. The capabilities flags are in the source code for the host driver.

    This is just to explain that since "we" can't find a quick and reliable solution through the codes "yet", at least "we" could try to find indirect explanations by other means...
    Click to expand...
    Click to collapse
    You're severely misinformed if you think we can't find a quick and reliable protection solution... Preventing ERASE commands from reaching the chip is semi-reliable if done in userspace, and 100% reliable if done by blocking ERASE attempts in the kernel. (I consider failures to flash a safe kernel in the first place not to be a failure of the kernel itself.)
    View

New posts