**Ultimate GS3 sudden death thread**

Search This thread

prashant.ks000

New member
Dec 21, 2012
1
0
Bangalore
Ultimate GS3 sudden death

What happened: All problem started after I updated phone to Android 4.1.1. on 22nd November, 2012. Dont know if it was mere co incidence of really on of the reason behind dying. Update had many bugs so had to get the new Jelly Bean updated again from Service center this time. After that phone worked fine for two days and when I was on my foreign trip, it stated to hang or freeze in middle of any work or during tranzition from one app to another. I had to pull out and put back the battery to restart it. On the day before dying, it hanged about 8-9 time and on the next day it hanged for one final time. After that it never restarted and it would freeze on boot screen. I had to remove battery to turn it off.

I gave phone to the service center and they took one week to fix it. This was seriously disappointing episode.

What ROM/Firmware:
What kernel:
OC or UV:
Where phone was made: Korea
Where battery was made: Korea
 

qazibasit

Senior Member
Mar 24, 2012
884
114
I am glad my note never experienced such issues. And for those with rooted s3 with custom roms, i have a question for you , "dont you people have any triangle away and binary counter reset apps for your phones?"

Sent from my GT-N7000 using xda app-developers app
 

justruss

Member
Jul 24, 2009
36
45
Just wanted to note that I sent my dead phone to Samsung (Germany) and they replaced the main board and sent it back within about a week. Not bad. Now I hope it doesn't happen again...
 

firstknightfirst

Senior Member
Jun 1, 2012
63
1
checking in...

I have the same problem... usually when i unlock the phone nothing happens all it needs is a reboot. But this time it doesn reboot the last thing felt that it was hot. I was having scramble with friend on and it went to sleep on its own or i put it to sleep by pressing power off. So in to SC and out come a replaced motherboard.

Rooted at that time ICS with checkrom. siyah kernel then. no change made ....

International S3 (Malaysia)
 
Last edited:

babblerx

Senior Member
Aug 20, 2007
188
30
This has happened to me as well

Just to add to the list (in the vague hope that Samsung might admit there is an issue)...

My phone died on 10/12/12 after being on charge overnight. Alarm went off at correct time (5.20am!!), took phone off charge and it cam out of standby, put it back into standby, shoved it in my pocket during half hour drive to work. At work, took it out of pocket to put on silent only to find it was completely dead.

Took it to Phones4U same day sho sent it off to repair centre and gave me repair tracking URL. It's taken a little longer than I would have liked to get sorted (though just under 2 weeks isn't too bad), but got an email from repair centre this morning saying the main board had been replaced and it will be sent back to my local Phones4U asap.

All in all, not too bad service wise, but it would have been nicer if it hadn't happened in the first place.

Just for info...my phone was purchased in June, only ever used stock ROM (with any updates always done vie KIES), running stock JB when it died.

Rich
 

Albin0

Member
Jan 19, 2010
14
0
46
Kragujevac
Happened to me with international version of SGS3. Phone was 3 months old.Never rooted,never flashed ,never charged with anything else than Samsung's original charger.Warranty wasn't voided.Put on charger on about 25-30 % battery.It just died over night during charging.No led flashing,no sign of life at all.Battery/SD removal trick didn't work.Battery swap with new one (stock original never used before-still on 40% factory charge) didn't work also.Carrier's SC replaced motherboard and shipped it back with JB 4.1.1 stock FW,took them 3 weeks to insert new MB into phone and ship it back.Fairly quick considering malfunction type.Carrier replced MB without any charge,under warranty with same IMEI as before malfunction.

FW was stock 4.04 last updated on 22nd August via OTA( pda I9300XXBLH1 csc I9300OXFBLH1 )
Kernel -stock
Root - none
Flash counter - 0
Production place - no idea
Battery production place -no idea (stock battery)
Carrier - VIP Serbia
 

gboydroid

Senior Member
Oct 26, 2011
1,319
142
btw after reading your experiences im a bit scared :( hahaha

btw mine is manufactured @ vietnam :D
 

emreeken

Senior Member
Oct 12, 2010
101
23
Ankara
My phone died on tuesday. Not after a full night charge. I locked the screen, when I tried to unlock, it didn't. And after that, it didn't turn on. I did not root, and I was using stock 4.1.1. I gave it to the service center and am waiting for answer. (I'm in Turkey and unbranded. I bought it in July 16.)
 

hd779

Senior Member
Dec 17, 2010
113
17
I emailed Phone Arena about this yesterday, glad to see them pick up on it and let people know. Hopefully this makes the rounds and stirs somethin up. I just hope it doesn't get pushed aside on american based sites because it appears isolated to the international s3. Its in everyone's best interest to hold Samsung accountable, maybe
they will start improving quality control. This is my third phone in the galaxy line ; the captivate, us galaxy s2 and now international s3. If this phone fails then all three will have suffered a significant hardware issue , before the phone was even a year old. I took precaution and bought a warranty to cover the phone for a year since international devices have no warranty in America and I don't know anyone in Trinidad and Tobago. But suffice it to say the S4 better be so impressive I can forget about all the issues I have had with Sammy Phones
 
  • Like
Reactions: funb0b

MalboX

Member
Jan 23, 2008
9
1
Great if it spread over blogs. I hope it will make Samsung give us some insights!

My GS3 left the local repair center to the factory one last week (from Paris, France). No news since.
I made a call and was told that it "takes 3 or 4 weeks" and that "no tracking information is available". Great, thanks :mad:
And I still don't know if it will lead to a "free" repair or to a costs estimate only.

No infos/news at all from Samsung France (via Twitter or phone support). I used #gs3suddendeath each time.
 
Last edited:

b0gd4n

Senior Member
Jul 6, 2009
777
78
London
I just checked the Carphone Warehouse repair tracker...I just got fixed :D wohoo!

The tracker now says "great news! We've fixed your SAMSGHGLXYS3" - "preparing for delivery to store"

They did not call me to ask for any money (I had custom rom installed on it - so no warranty)...at least they did not ask me for money until now...hope they don't! :D
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
This is pure speculation. What if this is not accidental? What if some sicko is using the exynos exploit to kill S3s?

I don't actually believe that this is the case here but it certainly is technically possible and it's probably only a matter of time before somebody does attempt it.

Sent from my SGS3 using Tapatalk
ROM Sotmax Ultimate V10
Kernel Yank555.lu-V2.8c
There's no known way to cause damage like what is described intentionally on any GS3.

It is indeed possible to permanently destroy a GS2 device with only a few kilobytes of malicious payload now (abuse both Superbrick and exynos-abuse in one payload), but not a GS3.

Well that sucks. I assumed they'd fixed the issue and were replacing our mainboards with a later revision. Giving us back the same revision is just going to leave us with the same problem in 6 months isn't it? Or could this be one dodgy batch of NAND chips and there's nothing wrong with the mainboard per se?
Back during the Superbrick fiasco days, people were getting replacements with the exact same defective eMMC chip for many months.

another point i searched the net and found on a site mobiletechvideos.com about a JTAG repair don't know much about it but found the phone working after that JTAG repair but they are situated abroad don't know how they are gonna help us JTAG repair cost was $50 so cheaper may be.
what do u say?? and how do we go about the claim from samsung....plz keep me posted.u can pm me at gauravinvouge@gmail.com
If anyone can bring back a device, it would be Josh Groce at MTV. HOWEVER - based on some of the descriptions here, it sounds like the parts of the eMMC chip are in la-la land, and not even JTAG may be able to resurrect the device. Unfortunately, once your device has been JTAGed, Samsung can see that the JTAG pads were soldered to and reject service for that. (Lots of Superbrick victims got ****ed this way.)

now Im quite glad my S3 has the dual core instead of that quad core. That Exynos recently has proved itself nothing but trouble. probably the cause is the exynos.
I don't think so. It's starting to sound like an eMMC wear leveller defect to me... Samsung has an established track record of broken wear levellers at this point (see Superbrick).

All of the symptoms I'm seeing described (can enter download mode but DL mode can't do anything) indicate the main MMC flash region (mmcblk0) is toast, but the boot region (mmcblk0boot0) is still alive. If you read the JEDEC spec, there's some pretty low-level isolation between these regions and I don't think they share wear leveller data.

The thing is that in addition to having a different SoC, USA variants frequently will have somewhat different flash chips.

For example, international GS2 and Note1 devices were almost always VYL00M or MAG4FA fwrev 0x19 (bad). USA Note1 was Qualcomm AND it had VYL00M fwrev 0x25 (safe).

It would be nice to get some info on what flash chip was present in devices that died, but there's no way I can think of to do this without a variant of one of AdamOutler's recovery methods (SD that boots recovery or a kernel off of SD and pulls the NAND flash info - something like this won't be able to resurrect a device though based on the described symptoms.) Flash chips that haven't died aren't particularly useful unless people write it down and THEN post it IF their device dies. (Having people who are still alive post chip data will just clutter this thread with uselessness - only if some people write it down and THEN their device dies will the data be useful.)
 

shethsa

Senior Member
Dec 23, 2010
586
46
Mumbai
Someone sensible from Sammy India called me to reassure that they'll be taking a deep look at my damaged mobo and maybe, just maybe, it's not a case of water logging. I'm sure they're monitoring this site as well because I told them to. For now it's a new mobo and less $140 from my pocket.

Sent from my GT-I9300 using Tapatalk 2
 

InfX

Senior Member
May 1, 2008
886
218
... It's starting to sound like an eMMC wear leveller defect to me... Samsung has an established track record of broken wear levellers at this point (see Superbrick)...

That's what i am thinking too, do you have any details on the wear leveling in use? Starting from the basic things, such as, is it static or dynamic, ending with the details of the broken wear levelers you've mentioned? This thread has currently spooked me to the level i've rebind my external sd card to be used as an "internal" ones, in order to minimize the flash writes to some extent :(
 

etique57

Senior Member
Sep 19, 2010
138
12
My case:

GS3 I9300, rooted, WanamLite 5.0.

Left my phone on the table in the evening, battery probably got exhausted overnight. Never, ever came back to any sign of life. Not even a battery led when charging.

It is now gone in Warranty, waiting to get it back sometime next week. Hopefully they won't notice about the rooting.
 

msbmsb

Member
Jun 12, 2009
9
0
I posted my experience here on the 19th of Nov, not seeing this thread until just now (since mine is a US version).

What happened:
Just prior to the Jelly Bean OTA:
1. All the sensors stopped working - gyro, proximity, etc. They all stopped working. They wouldn't come back on a restart either. I was getting ready to try a factory reset when the Jelly Bean OTA came.
After updating to Jelly Bean:
2. Updated to Jelly Bean, sensors started working again, but the phone would randomly restart, in my pocket, just sitting there on the table...
3. On Saturday I used the phone a little, just like normal. About 45 minutes after making a call and not using the phone again, I noticed that the phone was dead. I plugged it in thinking something had drained the battery.
4. When trying to power it up, it would vibrate once, sometimes twice but the screen stayed black.
5. I tried taking the battery out for a while, replaced it and turned it on - it started booting up, but before fully initializing, rebooted again and then went black.
6. Once i got a charging screen when i plugged it in, but could never replicate.
7. Became totally hardbricked. Can't get into download mode, can't factory reset, nothing at all. No vibrate, nothing. I fully charged the battery to make sure, and nothing. It's totally dead and unresponsive.
8. On receiving the warranty replacement SG3, I tried turning on the original once more, as a test. To my surprise, after several days of being powered off, it came back up and seemed to be working fine. It ran normally for a day and a half, at which point it then began to reboot, after turning on the GPS for the first time (whether that's actually related or not is unknown, just a note). It would either reboot immediately on the first screen unlock, or it would reboot while booting up.
9. Fortunately, this did give me an opportunity to factory reset. For anyone suspecting it had something to do with a rogue app, the phone would reboot on the very first initialization screen, where you enter your gmail account info.
10. Returned original unit.

What ROM/Firmware:
Stock USA T-Mobile Jelly Bean

Purchased on July 6, died on Nov 16, so about 130 days time.
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 85
    **** SAMSUNG HAVE APPLIED A SUDDEN DEATH FIX VIA A SOFTWARE UPDATE****

    STOCK KERNEL: XXELKC AND NEWER

    STOCK RECOVERY: XXELKC AND NEWER

    ALSO ANY CUSTOM KERNEL AND RECOVERY THAT ARE BUILT FROM THE UPDATED SOURCES. THERE HAVE BEEN CASES OF SDS ON DEVICES THAT HAVE UPDATED BUT TO WHAT EXTENT THE DAMAGE WAS AT ALREADY BEFORE FLASHING WE DON'T KNOW.



    WHO'S AFFECTED?
    It seems that at the moment the only devices that have suffered from SDS are the 16GB version with:
    eMMC: VTU00M
    FW Rev: 0xF1


    To check your eMMC version download eMMC Brickbug Check from Google Play.
    What you want is the eMMC version and the FW Rev.



    THE FIX
    Samsung have now released a Sudden Death Fix via a patched Kernel and Recovery in latest firmware. Firmware Version: XXELKC

    Simply update OTA or download XXELKC firmware (or newer) from sammobile.com and flash using Odin.

    You need both the stock recovery and kernel installed for it to work properly, or a custom kernel and recovery built from the updated sources
    ie Latest Perseus Kernel and PhilZ Recovery are examples



    LINKS
    For more info about SDS, who could be effected and how to fix check out this awesome thread by rootSU

    For a detailed look at how the fix works check out this thread here.


    WARRANTY
    For those of you in Europe who have rooted your phone it appears that this doesn't void warranty. Check this thread for more info.
    Also this website could prove very handy for anyone with a European or UK handset that has died.
    40
    Just took a look at the diffs and i have to admit, i don't nearly get what this does. What are those "movi commands"? Where can one find a data-sheet to decode the magics? :(

    BTW, just took the kernel image from the WanamLite v5.3 CWM zip (that's what i am currently running), un-gz-ed it, and actually found the "movi operation is failed" error string in there. Good for me, i guess ;)

    AndreiLux, thanks A LOT for your research.
    You won't. These are HIGHLY proprietary to Samsung's storage people.

    I'd hazard a guess that it does - but I'd certainly like someone like Entropy to weigh in.
    Bah, I wish I could see what you quoted. As far as safety goes:
    90%+ chance that the change in Update7 is the fix.
    75% chance that XXELLA/4/etc have the fix (It's possible, but highly unlikely, that the string VTU00M would appear in the kernel without the fix.

    Is there a way to check if I already have any bad blocks on my eMMC?
    This isn't about bad blocks - this is about a firmware bug where a data structure gets suddenly corrupted. You can really only know "is it working" or "is it dead". The one exception seems to be that some people see odd performance issues just before death, similar to the issues people see when using PIT workarounds for Superbrick.

    Just as I said above, the low-level details of what's going on are HIGHLY proprietary to Samsung.
    The patch additionally checks that the firmware date is 2012/04/13 and only applies the commands then.

    So you need type: VTU00M revision: 0xf1 and internal firmware date of 2012/04/13 for the bug to have an effect. The date which eMMC brickbug checker reads is the production date as it seems.

    So there might be phones with VTU00M/0xf1 out there which are not affected, I don't know if that makes sense in regard that if the revision would even be the same then.
    Yeah. I'm wondering if we should add some printk()s to check what the date is. I'm curious if there are other dates floating around.

    No, the date shown in the eMMC app is the production date, the internal firmware date is something else and not possible to read out through normal methods.
    Correct, although we could add a printk to kernels to print out the info.

    eMMC app gives me: 05/2012
    but checking via the SSID gives me: 2012/06/09.
    So two different dates, but none of them is the internal firmware date, correct?
    Correct.

    Most phones died over night after charging. Since there are many defective chargers, can this be related to a faulty charger? For example, I have my sgs3 for about 6 months and a few days ago charging became very slow (didnt charge fully after whole night). I used HTC's charger and charging is nornal again. Ive seen that many sgs3 owners got problems with charger. Can some faulty chargers start charging very skow and others give too much electricty which burns internals?

    Sent from my GT-I9300 using xda app-developers app
    No. Seriously - READ. It is at this point unambiguously an eMMC firmware failure that has NOTHING to do with the charger.

    The ONLY connection with charging is this: CHARGING HOLDS A WAKELOCK. This means the device will do various tasks in the background that it wouldn't do in deep sleep, some of which perform I/O cycles on the eMMC.

    The patch to the MMC driver discovered in the Update 7 sources released by Samsung performs a procedure that is nearly identical to the fix for another mmc firmware bug in a different samsung device.

    The patch also includes some character strings which can be searched for in the binary kernel of XXELLA, as when code is compiled, strings are left as they are.

    The kernel from the XXELLA firmware DOES include these strings, so it's probably safe to assume that the kernel includes the code that performs the in-RAM fix to the mmc firmware.

    The fact that some people have reported that they've experienced SDS on the XXELLA ROM is interesting - none have confirmed 100% that they had the XXELLA kernel running (to the best of my knowledge). This means that for some reason they may have been running another kernel that doesn't have the patch.
    So far all of them were running other kernels.

    It's just like the people who claimed they Superbricked on stock recovery. Turns out that in their eyes, fakeflashing CWM from stock recovery was still in some twisted way stock recovery... It wasn't.

    I'm still confused. Some posts say lla kernel is safe others say you need Perseus. So which one is it

    Sent from my GT-I9300 using xda premium
    Perseus is 90% guaranteed to be safe (I'm not claiming 100% without a detailed technical explanation from Samsung. Even then I'm not claiming 100%, just like I refuse to guarantee that nonsecure erase is safe on Superbrick-vulnerable devices even though Samsung claims it is... As a result anything I release has eMMC TRIM/ERASE completely disabled for those devices.
    ELLA/4/etc are 75%+ guaranteed to be safe - since we THINK they have the same patch

    If i understood it correctly, we have an assumption? that because similar code is implemented in kernels for similar problems in other samsung phones, so that means we have the same problem in S3.
    If this is true then all or almost all 16GB phones are affected, as i didnt saw a phone with different emmc.(maybe some new phones have newer revision?)
    We are talking then for millions S3's that are going to die?
    Maybe this code then doesnt have to do anything with the "SDS issue" and is more of a precaution or even testing trying to figure out the problem from Samsung?
    Samsung's storage guys have a wide variety of chips/models. VTU00M 0xf1 is primarily seen in I9300 units, and almost all 16GB I9300s except very recent ones have it. Some other devices have it, but it isn't nearly as prevalent in other devices. My Note 10.1 has MAG4FB I think (need to check again...) In addition, there appears to be some additional identifying information beyond VTU00M 0xf1 that we haven't had time to collect data on yet (and developers need to make kernel patches to even allow this data to be collected...)

    I think that it's combination is the solution.

    according to this from 1st post:

    ...Kernels >v31 and beyond stock LLA are now the only truly protected ones.

    Can someone confirm this?
    the key in that post is the word "now". That post was made yesterday - the patch has been making the rounds and is getting integrated

    Have you searched for it in older kernels? Why wouldn't that string appear also in those? If it does, then this means nothing.
    That's something that needs to be checked... However if it appears in older kernels Samsung was violating the GPL with them as I'm fairly certain it is nowhere within the source.

    Nothing can fix an SDS because the phone is already dead. :D
    But to prevent it, yes it seems. One of those at this moment.
    Just like Superbrick.

    Samsung haven't fixed the super brick bug yet :p

    Sent from my GT-I9100 using Tapatalk 2
    On a small subset of affected devices they have - I9100s in HK apparently have Jellybean and that has their official fix. But so far, nearly all affected devices are still on ICS and they only put the fix in JB kernels.

    Just did a emmc check and I found out that my fwrev is oxf7 and the date is 11/2012... But I got the same chip like otherss... :(

    So am I on a safer side?

    Sent from my GT-I9300 using xda app-developers app
    Unknown. Often flaws like this are firmware-dependent.

    For example:
    VYL00M/KYL00M/MAG4FA fwrev 0x19 = Superbrick + 32kb-of-zeroes bug
    VYL00M/KYL00M/MAG4FA fwrev 0x25 = 32kb-of-zeroes bug only (immune to Superbrick)

    However for the above, we had confirmation from a trusted source (A Google engineer) that 0x19 had a bug with the symptoms we were seeing and that HE had seen it in GNex prototypes, and that 0x25 was "fixed" in regards to that bug (Superbrick). A fix for the bug in 0x25 is what led us to him.

    Theoretically if you have the same chip, you are candidate for sds sometime.... :(
    Not necessarily. I would put the status as "unknown". If you have VTU00M 0xf7 you're much less likely to have problems than 0xf1 - but with something like this guarantees cannot be made.

    Also: The fix patch was merged to CM10.1 source last night. So today's nightly should be safe. If it's not - no one is safe.
    30
    Will my i9305 die too, or only the i9300 is afected?
    If you have VTU00M fwrev 0xf1 flash, you are probably at risk. I9305 is too new to tell

    In today's SamMobile article, they say is a firm bug!!?????? In other words, sammy firm only have the bug?? If I use (no because my phone deaths on 12/27) aosp rom and custom kernel, bug not affect my device???
    No. In fact, there's nothing that indicates there is a bug in the bootloader/kernel/system firmware yet. Given the behavior of the problem and Samsung's past history, it's likely a bug in internal eMMC firmware (which can, at best be field-patched if it only involves a few bytes of microcode - major changes are not possible in the field.) This upcoming update likely contains a workaround for that eMMC bug.

    Look at the Superbrick bug - There was no underlying "bug" in any of Samsung's firmwares, except that they didn't block commands that would trigger a known bug in the underlying flash memory. Now, in any hardware without that bug, issuing secure erase commands is fine. The workaround for the bug is simple: Don't send secure erase commands to the damn chip.

    Is it true that all 16gigs phone will die soon one day?

    Sent from a better Galaxy designed for humans!
    Unknown. Right now any device with VTU00M flash is at risk - but how high the risk is we don't know.

    but Samsung says that will fix the issue with fw update.....or not?

    there is no fw going to write to the NAND?
    No one knows yet. If it's done in the kernel, we'll know EXACTLY what/how they fixed it and how to apply the fix to custom firmwares. If it's the bootloader, we won't know unless they explicitly states that they changed the bootloader to fix it. If it's in /system (HIGHLY unlikely) we might see something.

    Most likely place they'll fix this is the kernel with a variant of the Sumrall patch from last spring, OR an alteration to the MMC code in order to avoid doing something (we don't know what) that the chip doesn't like (this would be similar to how Superbrick is worked around). So far, every time Samsung has ever fixed or worked around an eMMC bug/defect, it's been in the kernel and not the bootloader. So everyone flashing this new bootloader is just making it more likely they'll be denied warranty support if their device dies.

    Yes the current btu release (today)apparently has sudden death fix via the bootloader.

    I recommend updating via pc odin as mobile odin won't fix the bootloader, Im already on samsung 4.1.2 release at christmas just downlaoding todays release.
    Bull****. You have ZERO evidence to substantiate this claim.

    so we can only wait for the new bootloader from Samsung .... :crying:
    And why do you think it's the bootloader? There's no evidence to say WHERE the fix will be applied because there isn't even any information about HOW the failures are occurring. Right now, I'd say it's most likely going to be a kernel fix.

    Yes but its like a chain reaction: if one component or sector dies mostly the other ones will follow. Freezes and hookups are those signs of hardware failure.

    As long if those symptoms doesnt apair you dont need to worry too much

    Sent from my GT-I9300 using xda app-developers app
    If it's a wear leveller bug, there's a possibility fixed wear leveller firmware might "repair" damage to the internal data structures.

    Can someone please explain... if it's a wear leveler, and thats a part of eMMC (as opposed to software-only wear leveling), how is it even possible to update it? Can one possibly update the eMMC microcode ?!
    Search before posting. I posted an example of how this has been done to Samsung eMMC chips in the past only 1-2 days ago. (Search this thread for Sumrall...)

    Minor eMMC microcode updates can be done at runtime. It's fairly safe since it apparently patches the firmware after it has loaded into volatile memory (and hence a power cycle removes the patch if it's misapplied). This is what the Galaxy Nexus patch for VYL00M/KYL00M/MAG4FA fwrev 0x25 did.

    Major eMMC microcode updates can't be done so easily, which is why the underlying Superbrick flaw was never fixed.


    [KIES]I9300XXELLA 4.1.2->EXYNOS BUG FIXED!!S3 SUDDEN DEATH FIXED!!Jan.02,2013

    http://xdaforums.com/showthread.php?t=2077844
    Don't make definitive claims you have no evidence to support.
    27
    Hi all,

    Assuming that there is no NAND degradation or similar and that SDS come for something specific, why over 90% of the deaths have come from the fourth month onwards? Why have not failed at 4 days or two weeks, for example? What is the secret component involved over time to fail?

    We will likely never know the specific secret component, but with knowledge of the behavior of eMMC, how it behaves, and how Samsung eMMCs have failed in the past, we can guess.

    The wear leveller keeps track of what memory blocks have been used and what haven't, and relocates blocks periodically to spread wear across the device. For example, if you write to the fourth block of the eMMC repeatedly, internally it'll map the fourth block to the 100th, then maybe the 150th, then 200th, etc...

    At some point, after a long time of operation, the wear leveller might reach a corner case where a bug is triggered - my guess would be an integer overflow or a signed vs. unsigned issue. For example, it's working with the 32767th instance of block 5, and tries to increment a counter to 32768 - but instead, gets -32768 instead because something is treating an unsigned int as signed. The next time it tries to work with that counter, BOOM - it crashes. Again, we don't know the exact nature of what's happening, but it's likely something along these lines.

    It's very similar to what happened with Superbrick on the GS2 - if you issued a secure erase command to erase memory that was in a certain specific state (I can't talk about what the exact state is, sorry... And no, there's no way to tell if the memory is in that state unless you're Samsung or you've Superbricked it.), the wear leveller would crash and leave behind corrupted data structures - any attempt to access these structures again would crash the wear leveller again. The symptom to the user was any attempt to access affected regions of the eMMC would cause the chip to hang.
    22
    Entropy512, thank you.
    How can you explain users that had XXELLA stock rom, and still suffered from SDS? There are more than one report of it.
    I have yet to see any such reports... The one report I've seen of an XXELLA failure was XXELLA system + Siyah.

    You are being unecessarilhy harsh here, especially considering that you are addressing people who are under the fear that their expensive phones will die on them suddenly. AdreiLux seems to be more skeptical regarding the possibility of the fix depending on the new bootloader as well. Calling names surely doesn't make you look smarter than the "idiots" who took a step -granted maybe rushed- towards a probable fix of a dreadful issue. And you may know much more than the average joe here, but you still have ZERO evidence that the new bootloader doesn't do anything at all that contributes to fixing the SDS, so you may have as well been nicer. Just my 2 cents.
    I have all of the evidence I need - I now have kernel source for a complete eMMC firmware patch. The fix is in the kernel, not in the bootloader. It's being patched in the EXACT same way as the GNex 32kb-of-zeros fix patch, which had zero bootloader involvement.

    The fact is that flashing a bootloader is a fundamentally dangerous operation, and flashing a bootloader with known regressions in functionality is 100% reckless and stupid.

    The fact is that Samsung has NEVER fixed a problem like this in the bootloader before. There was ZERO evidence pointing there. There was plenty of evidence (the GNex VYL00M/KYL00M/MAG4FA 0x25 patch) pointing to the fix being in the kernel when it came out.

    How come you knew that SDS is related to eMMC (and specifically version VTU00M) before samsung released their code? What led to this assumption?
    All of the symptoms and behavior pointed this way.
    1) Some devices were exhibiting "Superbrick-ish" behavior where certain eMMC regions were working and others were inaccessible
    2) It was ONLY happening on 16GB devices - this is the most obvious piece of evidence. If it weren't the eMMC, it would have been seen on 32/64GB devices
    3) It would be the third time in one year Samsung has ****ed up their wear leveller, their quality control is clearly crap in this regard.