• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[Important] Sudden Death (SDS) - Don't use older than Android 4.1.2 or CWM 6.0.3.x

Status
Not open for further replies.
Search This thread

danarama

Senior Member
Aug 22, 2010
31,283
18,814
Oxenhope, West Yorkshire, UK
Latest Thread update

This section is to alert returning readers to new sections or information as they are added. New readers, please start at "Introduction"


  • 17th Jul 2013 - Added Googy-Max. I thought this thread was dead
  • 21st Jun 2013 - Request: Please don't ask if x.x.x (new release) has SDS fix. See "***" at end of post 1.
  • 19th Jun 2013 - Added Official CWM Link in safe recoveries (Please only use links provided)
  • 18th May 2013 - Revised "Stock section" to be more succinct
  • 13th May 2013 - Added Devil kernel to safe list
  • 3rd May 2013 - Added more about SDS v half SDS in the "What do we think we know" section
  • 12th Apr 2013 - tried to distinguish between Fix 1 and Fix 2
  • 6th Mar 2013 - Added ICS boaotloader to "Other links"
  • 25th Feb 2013 - Added "Other Links" section at end of post 1
  • 26th Jan 2013 - Update on bootloader requirement, courtesy of AndreiLUX
  • Previous: Added Speedmod K2-5 Test 1 Kernel
  • Previous: Added quotes around the fixed items for visual prominence

Introduction

Hi All,

I am seeing a lot of Buzz about the Sudden Death issue and recent fixes identified by AndreiLux and implemented into his Kernel here:
http://forum.xda-developers.com/showthread.php?t=1691401 so please take a moment to thank him.

Unfortunately as there seems to be some uncertainty about what is or is not covered by the Fix, I have put this thread together to eliviate some of the many off topic questions posed by members in development threads, which is unfair on the developers.

So what do we think know?

Please be aware, this is not related to the Exynos Memory security issue.

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. There is still no evidence that the latest sboot bootloader addresses this issue.

Although we are still not quite 100% Certain this will prevent all S3's suffering the SDS (Predisposition to the fault etc), to the best of our knowledge it does. Even if it does not fully fix it, its closer to a fix and safer than older versions, so if its within your means to do so, an update would be advised. Please don't panic. If it's going to happen, it's going to happen and that's that. It will be repaired under warranty. I had to use a Bold 9000 for 7 days whilst mine was repaired :)

SDS seems to manifest in 2 distinct ways.

1) Complete eMMC failure. This usually happens over night whilst on charge* - The LED may be lit but the phone will not wake. Subsequent removal of the battery will turn off the LED. You will never get the LED back on. The phone will never turn on again. It needs to go to a service centre and have the motherboard replaced

* Being on Charge is NOT the cause. This is a writing to memory issue and it is more likely to happen when teh device is awake rather than in deep sleep. When the S3 is on charge, it holds a wake lock (so remains awake) throughout the entire charging period, meaning SDS is more likely to occur when on charge This does not mean you should avoid charging your phone. If it's going to happen, it's going to happen

2) Half SDS as it has not-so-affectionately become known. This tends to be more of a boot loop of the Samsung boot splash. the eMMC is partially wiped out. You cannot boot into android or recovery. It fails at the boot screen, but the screen does turn on none-the-less. The only; thing you can do is top boot into Download mode.

One problem Half SDS has is that the information download mode uses to show the status as "Official" appears to be wiped out by the bug, leaving your status as "Custom". This can leave you in a precarious position as this is what Samsung uses to establish warranty validity. You may also see your product field is blank.

Please help me maintain this list by identifying fixes as and when released, Please post the Link and Version number of anything with this fix implemented

How do I check my eMMC?

Using the EMMC check app from play, you can see if your eMMC is the VTU00M 0XF1 (affected chip).

Please note:

1) We only need this app to check the version.

2) Nothing you see in this app will change once you apply a fix. It simply gives you the version. If you expect 0xf1 to change to something else, you are mistaken. Only replacing the motherboard will do that.

What do I need to be "Safe"?

The "Fix" is actually a preventative measure. It cannot revive a "dead" device. It has to be applied before failure.

To be 100% safe, you need:

  • A bootloader with fixes**
    [*]A Recovery with a fixed kernel
    [*]A Fixed kernel to run Android

If you are a normal user only using official releases (no custom ROMs, Kernels or recoveries) then we treat you as "Stock" - read on.

Lets get to it... Where is it fixed?


Stock:

All 4.1.2 official releases (stock) include a Kernel, bootloader and recovery with the Update 7 "Fixes" (or newer) applied. If you have 4.1.2, officially consider yourself "Safe".***

Stock (but rooted):

If you rooted a 4.1.2 stock ROM, you will still be safe, however - if you changed to a custom kernel or recovery, you need to look at the below custom sections to ensure your kernel or recovery are listed as safe.

The below official kernels were tested, but we no longer need to test. All 4.1.2 (stock) kernels and newer have fixes.

  • XXELKC
  • XXELL1
  • XXELL4
  • XXELL5
  • XXELL6
  • XXELLA
  • XXELLB
  • XXELLC

Fix v1

Please note, you may experience freezes and /or reboots using a Fix v1 ROM (Well actually kernel that is included in this ROM). Essentially any Stock 4.1.2 ROM between:

LKC and MA2
Which means:
2012 November revision 12 and 2013 January Revision 2

...may experience freezes due to the way the fix works. This is annoying but better a freeze than a motherboard replacement.

Fix v2

From what appears to be Update 8 sources (MB1 onwards), the fix seems to be much better with far fewer freezes. I haven't included the MR* vodafone ROMS because who knows? They don't follow the standard naming convention. All I can say is MR2 came out when MBx was around (B = February) but is still only fix v1

People who have never rooted need not read any further. Essentially, if you have an official, never rooted 4.1.2 ROM, you're "safe"

-------------------------------------------------------------------

Custom ROMs which include a ROM specific and dedicated kernel (including fixes):
These are custom ROMs that have their own kernel that is not flashable separately. This means it is not packaged with a kernel from the "Custom Kernels" section. If you have the version specified or newer, you are "safe"

Custom Kernels:
These kernels include the update 7 fixes (or newer). If you are rooted with a custom Kernel that is older than (or doesn't match) the versions below, you are not considered "safe"

Custom Recoveries:
Since the recovery uses a kernel too, to be "safe", the recovery's kernel must also be fixed.

Please be weary of CWM. It can be compiled by anyone which means we cannot guarantee all versions have the latest fixes. Please only download from the links posted above



Obviously, rooted users are probably more familiar with what to do. I don't really want to recommend non-techy people flash official firmwares if they are not comfortable doing it. There will be a fix on its way to you all soon anyway, so the worst that will happen is you are affected and you have to get your phone repaired...


For those who are technical but would prefer to follow an Odin flash guide for official firmware, read the appropriate section here:
http://forum.xda-developers.com/showthread.php?t=1671969

Recap

So to recap, if you checked you have VTU00M 0xf1 with EMMC check , you need to ensure:

  • If unrooted (never rooted / modded), you are on one of the "Stock" ROMs listed above
  • If rooted, you have one of the "Custom Kernels" OR "Custom ROMs including kernel" OR rooted "stock" with original kernel AND one of the "Custom recoveries" from the lists below

**Bootloader note

Download mode uses a bootloader packaged micro-kernel

It will only affect those who use download mode. Personally I am rooted so I don't use it so i'll be sticking with one that doesn't mess with the flash counter, however anyone who does use download mode should consider updating. Those who care more about flash counters and will stay with older bootloaders should avoid flashing anything in download mode

*** Please do not ask if newer builds (either not mentioned here, or newer than 4.1.2) include the fixes.

Samsung have a single repository of kernel source code. They continue to develop this code. When they add a fix, it's there forever in every new kernel built after the fix is added. Every fix is in new kernels automatically. They do not have a list of fixes they must add every time.

The only way a new kernel does not contain a fix is if it is manually (and specifically) removed from the source code. Can you think of any logical reason why they would do that?!

Other Links

Ultimate Unusual Freezing thread (The fix causes Freezing, possible solutions)
Ultimate SDS thread (Further discussion of the SDS issue)
ICS Bootloader for those who want to keep custom counter at 1
 
Last edited:

thekoRngear

Senior Member
Jul 25, 2012
725
230
Yank's kernel has the fix too, I think.

Two questions:
1. When boot into Download Mode- is it safe?
2. Someone said about charging the phone when it is off and off the wallsocket. How about the fix/security then?
 
Last edited:

mjb

Senior Member
Jan 20, 2005
93
28
Dunedin, NZ
It appears the fix is in some older kernels too, but there has definitely been instances of SDS on those, so it's possible that the fix found in update 7 is not the whole story.
 

danarama

Senior Member
Aug 22, 2010
31,283
18,814
Oxenhope, West Yorkshire, UK
It appears the fix is in some older kernels too, but there has definitely been instances of SDS on those, so it's possible that the fix found in update 7 is not the whole story.

Best we have right now is from Andrei stating it *looks* complete, but I agree we just cannot know everything for sure yet. I changed teh op to say "what do we think we know"
 
  • Like
Reactions: irfan99

montage mahal

Senior Member
Jul 6, 2012
51
19
Dublin
Its allways a risk to flash via odin. Anything could of happened during the flash. Am I goin crazy or does everyone not know that all ready. We allways flash at our own risk! Need to keep this issue real. Some people think they have a tickin time bomb in there pocket. Boom!

Sent from my GT-I9300 using xda premium
 

Phil3759

Inactive Recognized Developer
May 30, 2012
9,572
33,053
PhilZ Touch 4.00-b04

Download:
- odin: http://www.mediafire.com/file/3g6ke58rsvs3j8y/philz_touch_4.00-b04-i9300.tar.md5
- cwm: http://www.mediafire.com/file/m6z7wwrd20pd9ln/philz_touch_4.00-b04-i9300.zip


This version wouldn't have been pushed as I did not plan any updates of the binary before 4.00 Final. But since we needed a repack with XXELLA kernel and the code was ready for these changes, I pushed it.

Changes:
- Repack with XXELLA kernel supposed to be SDS safe
- Fix romname added to nandroid backups: now build.prop will be parsed instead of reading system properties
- Custom rom.zip scripts completely revised to add a bit of process progress (beta and will be completely revised in Final build)
 

danarama

Senior Member
Aug 22, 2010
31,283
18,814
Oxenhope, West Yorkshire, UK
Its allways a risk to flash via odin. Anything could of happened during the flash. Am I goin crazy or does everyone not know that all ready. We allways flash at our own risk! Need to keep this issue real. Some people think they have a tickin time bomb in there pocket. Boom!

Sent from my GT-I9300 using xda premium


Yes indeed but ts a real issue even if you never flash anything.
 

mjb

Senior Member
Jan 20, 2005
93
28
Dunedin, NZ
Best we have right now is from Andrei stating it *looks* complete, but I agree we just cannot know everything for sure yet. I changed teh op to say "what do we think we know"

Good.. I think the patch is complete too, but my concern is that we just don't know if this is addressing SDS, another fault, or just part of SDS and there is actually more to the problem than what this patch is "fixing".

I only say this due to finding the strings in the patch in older stock kernels, where people have experienced SDS.
 

danarama

Senior Member
Aug 22, 2010
31,283
18,814
Oxenhope, West Yorkshire, UK
Good.. I think the patch is complete too, but my concern is that we just don't know if this is addressing SDS, another fault, or just part of SDS and there is actually more to the problem than what this patch is "fixing".

I only say this due to finding the strings in the patch in older stock kernels, where people have experienced SDS.


Yep no worries. I have reworded the OP a little more to reflect. Please feel free to help me phrase it :)
 

alkanbw

Senior Member
Sep 17, 2012
78
27
I think that best solution is to flash PhilZ Touch 4.00-b04 as is based on XELLA (secure) and using XELLA reom with kernel or Perseus. PhilZ recovery works with exfat - Yank kernel not - so is for me useless
 
  • Like
Reactions: juicer.
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 270
    Latest Thread update

    This section is to alert returning readers to new sections or information as they are added. New readers, please start at "Introduction"


    • 17th Jul 2013 - Added Googy-Max. I thought this thread was dead
    • 21st Jun 2013 - Request: Please don't ask if x.x.x (new release) has SDS fix. See "***" at end of post 1.
    • 19th Jun 2013 - Added Official CWM Link in safe recoveries (Please only use links provided)
    • 18th May 2013 - Revised "Stock section" to be more succinct
    • 13th May 2013 - Added Devil kernel to safe list
    • 3rd May 2013 - Added more about SDS v half SDS in the "What do we think we know" section
    • 12th Apr 2013 - tried to distinguish between Fix 1 and Fix 2
    • 6th Mar 2013 - Added ICS boaotloader to "Other links"
    • 25th Feb 2013 - Added "Other Links" section at end of post 1
    • 26th Jan 2013 - Update on bootloader requirement, courtesy of AndreiLUX
    • Previous: Added Speedmod K2-5 Test 1 Kernel
    • Previous: Added quotes around the fixed items for visual prominence

    Introduction

    Hi All,

    I am seeing a lot of Buzz about the Sudden Death issue and recent fixes identified by AndreiLux and implemented into his Kernel here:
    http://forum.xda-developers.com/showthread.php?t=1691401 so please take a moment to thank him.

    Unfortunately as there seems to be some uncertainty about what is or is not covered by the Fix, I have put this thread together to eliviate some of the many off topic questions posed by members in development threads, which is unfair on the developers.

    So what do we think know?

    Please be aware, this is not related to the Exynos Memory security issue.

    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. There is still no evidence that the latest sboot bootloader addresses this issue.

    Although we are still not quite 100% Certain this will prevent all S3's suffering the SDS (Predisposition to the fault etc), to the best of our knowledge it does. Even if it does not fully fix it, its closer to a fix and safer than older versions, so if its within your means to do so, an update would be advised. Please don't panic. If it's going to happen, it's going to happen and that's that. It will be repaired under warranty. I had to use a Bold 9000 for 7 days whilst mine was repaired :)

    SDS seems to manifest in 2 distinct ways.

    1) Complete eMMC failure. This usually happens over night whilst on charge* - The LED may be lit but the phone will not wake. Subsequent removal of the battery will turn off the LED. You will never get the LED back on. The phone will never turn on again. It needs to go to a service centre and have the motherboard replaced

    * Being on Charge is NOT the cause. This is a writing to memory issue and it is more likely to happen when teh device is awake rather than in deep sleep. When the S3 is on charge, it holds a wake lock (so remains awake) throughout the entire charging period, meaning SDS is more likely to occur when on charge This does not mean you should avoid charging your phone. If it's going to happen, it's going to happen

    2) Half SDS as it has not-so-affectionately become known. This tends to be more of a boot loop of the Samsung boot splash. the eMMC is partially wiped out. You cannot boot into android or recovery. It fails at the boot screen, but the screen does turn on none-the-less. The only; thing you can do is top boot into Download mode.

    One problem Half SDS has is that the information download mode uses to show the status as "Official" appears to be wiped out by the bug, leaving your status as "Custom". This can leave you in a precarious position as this is what Samsung uses to establish warranty validity. You may also see your product field is blank.

    Please help me maintain this list by identifying fixes as and when released, Please post the Link and Version number of anything with this fix implemented

    How do I check my eMMC?

    Using the EMMC check app from play, you can see if your eMMC is the VTU00M 0XF1 (affected chip).

    Please note:

    1) We only need this app to check the version.

    2) Nothing you see in this app will change once you apply a fix. It simply gives you the version. If you expect 0xf1 to change to something else, you are mistaken. Only replacing the motherboard will do that.

    What do I need to be "Safe"?

    The "Fix" is actually a preventative measure. It cannot revive a "dead" device. It has to be applied before failure.

    To be 100% safe, you need:

    • A bootloader with fixes**
      [*]A Recovery with a fixed kernel
      [*]A Fixed kernel to run Android

    If you are a normal user only using official releases (no custom ROMs, Kernels or recoveries) then we treat you as "Stock" - read on.

    Lets get to it... Where is it fixed?


    Stock:

    All 4.1.2 official releases (stock) include a Kernel, bootloader and recovery with the Update 7 "Fixes" (or newer) applied. If you have 4.1.2, officially consider yourself "Safe".***

    Stock (but rooted):

    If you rooted a 4.1.2 stock ROM, you will still be safe, however - if you changed to a custom kernel or recovery, you need to look at the below custom sections to ensure your kernel or recovery are listed as safe.

    The below official kernels were tested, but we no longer need to test. All 4.1.2 (stock) kernels and newer have fixes.

    • XXELKC
    • XXELL1
    • XXELL4
    • XXELL5
    • XXELL6
    • XXELLA
    • XXELLB
    • XXELLC

    Fix v1

    Please note, you may experience freezes and /or reboots using a Fix v1 ROM (Well actually kernel that is included in this ROM). Essentially any Stock 4.1.2 ROM between:

    LKC and MA2
    Which means:
    2012 November revision 12 and 2013 January Revision 2

    ...may experience freezes due to the way the fix works. This is annoying but better a freeze than a motherboard replacement.

    Fix v2

    From what appears to be Update 8 sources (MB1 onwards), the fix seems to be much better with far fewer freezes. I haven't included the MR* vodafone ROMS because who knows? They don't follow the standard naming convention. All I can say is MR2 came out when MBx was around (B = February) but is still only fix v1

    People who have never rooted need not read any further. Essentially, if you have an official, never rooted 4.1.2 ROM, you're "safe"

    -------------------------------------------------------------------

    Custom ROMs which include a ROM specific and dedicated kernel (including fixes):
    These are custom ROMs that have their own kernel that is not flashable separately. This means it is not packaged with a kernel from the "Custom Kernels" section. If you have the version specified or newer, you are "safe"

    Custom Kernels:
    These kernels include the update 7 fixes (or newer). If you are rooted with a custom Kernel that is older than (or doesn't match) the versions below, you are not considered "safe"

    Custom Recoveries:
    Since the recovery uses a kernel too, to be "safe", the recovery's kernel must also be fixed.

    Please be weary of CWM. It can be compiled by anyone which means we cannot guarantee all versions have the latest fixes. Please only download from the links posted above



    Obviously, rooted users are probably more familiar with what to do. I don't really want to recommend non-techy people flash official firmwares if they are not comfortable doing it. There will be a fix on its way to you all soon anyway, so the worst that will happen is you are affected and you have to get your phone repaired...


    For those who are technical but would prefer to follow an Odin flash guide for official firmware, read the appropriate section here:
    http://forum.xda-developers.com/showthread.php?t=1671969

    Recap

    So to recap, if you checked you have VTU00M 0xf1 with EMMC check , you need to ensure:

    • If unrooted (never rooted / modded), you are on one of the "Stock" ROMs listed above
    • If rooted, you have one of the "Custom Kernels" OR "Custom ROMs including kernel" OR rooted "stock" with original kernel AND one of the "Custom recoveries" from the lists below

    **Bootloader note

    Download mode uses a bootloader packaged micro-kernel

    It will only affect those who use download mode. Personally I am rooted so I don't use it so i'll be sticking with one that doesn't mess with the flash counter, however anyone who does use download mode should consider updating. Those who care more about flash counters and will stay with older bootloaders should avoid flashing anything in download mode

    *** Please do not ask if newer builds (either not mentioned here, or newer than 4.1.2) include the fixes.

    Samsung have a single repository of kernel source code. They continue to develop this code. When they add a fix, it's there forever in every new kernel built after the fix is added. Every fix is in new kernels automatically. They do not have a list of fixes they must add every time.

    The only way a new kernel does not contain a fix is if it is manually (and specifically) removed from the source code. Can you think of any logical reason why they would do that?!

    Other Links

    Ultimate Unusual Freezing thread (The fix causes Freezing, possible solutions)
    Ultimate SDS thread (Further discussion of the SDS issue)
    ICS Bootloader for those who want to keep custom counter at 1
    14
    Added to post 1:

    What do I need to be "Safe"?

    • Do I need the Bootloader that comes with XXELLA? No - There is no evidence to suggest this fixes anything
    • Do I need an XXELLA / Update 7 fix Based Kernel? Yes - Kernel is where the fix is
    • Do I need an XXELLA based ROM? No - The Kernel is where the fix is
    • Do I need a Recovery with XXELLA / Update 7 fixes? Yes - Recovery uses a Kernel too so it also needs fixes
    14
    PhilZ Touch 4.00-b04

    Download:
    - odin: http://www.mediafire.com/file/3g6ke58rsvs3j8y/philz_touch_4.00-b04-i9300.tar.md5
    - cwm: http://www.mediafire.com/file/m6z7wwrd20pd9ln/philz_touch_4.00-b04-i9300.zip


    This version wouldn't have been pushed as I did not plan any updates of the binary before 4.00 Final. But since we needed a repack with XXELLA kernel and the code was ready for these changes, I pushed it.

    Changes:
    - Repack with XXELLA kernel supposed to be SDS safe
    - Fix romname added to nandroid backups: now build.prop will be parsed instead of reading system properties
    - Custom rom.zip scripts completely revised to add a bit of process progress (beta and will be completely revised in Final build)
    12
    I've patched Siyah 1.8.7 to export movi_ops via sysfs, so you can know whether your device is affected or not.
    Flash the attached kernel, then do "cat /sys/class/block/mmcblk0/device/movi_ops". 2 means affected, 0 means not, other values mean my code has a bug. :)
    Re-flash your everyday kernel afterwards. Don't use mine.

    I take no responsibility whatsoever if anything happens. Do it with your own responsibility.


    * I'm refactoring Samsung's code to use the mmc quirk mechanism properly (Linux conventions); after I'm done, I will submit this as a patch to the common kernels (Siyah, Perseus, CM etc.) and maybe to mainline, so you won't need a special kernel for this.
    12
    A few insights about the alleged fix:
    - As far as I know, only 16GB models have died. This seems to be an indication that it is indeed a problem with the eMMC chip.
    - According to the moviNAND specs, they issue a vendor-specific MMC command to enter debug mode, then they patch its RAM.
    - They write "10 B5 03 4A 90 47 00 28 00 D1 FE E7 10 BD 00 00 73 9D 05 00" to 0x40300; they also write "E3 F7 89 FD" to 0x5C7EA.

    As soon as I saw this "10 B5", I suspected this is THUMB code (looks like a common PUSH) -- and I was right:
    Code:
    ROM:00040300                 PUSH    {R4,LR}
    ROM:00040302                 LDR     R2, =0x59D73
    ROM:00040304                 BLX     R2
    ROM:00040306                 CMP     R0, #0
    ROM:00040308                 BNE     locret_4030C
    ROM:0004030A
    ROM:0004030A loc_4030A                               ; CODE XREF: ROM:loc_4030Aj
    ROM:0004030A                 B       loc_4030A
    ROM:0004030C ; ---------------------------------------------------------------------------
    ROM:0004030C
    ROM:0004030C locret_4030C                            ; CODE XREF: ROM:00040308j
    ROM:0004030C                 POP     {R4,PC}
    ROM:0004030C ; ---------------------------------------------------------------------
    They call the (THUMB) function at 0x59D73. If it returns 0, they halt. (Hey Samsung, shouldn't we avoid sudden deaths?)
    My guess is that this function used to do the opposite before: halt if the value isn't 0 - hence the bug.

    Also, the code at 0x5C7EA calls our function:
    Code:
    ROM:0005C7EA                 BL      0x40300
    Maybe it used to call another (buggy) function before?

    Anyway, it would be really nice to dump its RAM and see exactly what has changed.
    I've found some code to read the moviNAND RAM; will do this later.


    * I wanted to post this in the developer discussion forum. Apparently, I don't have permissions :(