Went to samsung today .... Like I said I think that the system status that changed to custom after die (was official before) will be a problem. Mainly because beside me there was 3 guys with the same problem....I think samsung will use all they can void warranty) I had one report before die complaining it was not available the update via kies for 4.1.2.... I called again before leave the phone to ask what they will do since there is no 4.1.2 available for my phone. At the beginning he said they know there is a problem but only for root devices. Then he said that the firmware from the carrier 4.1.1 can have a problem...at least that is my situation. I have no idea about why the system status changed ...binaries are ok.... If someone has information that help me to argue I will appreciate. They ask one week to fix... I would like to be ready ... First argument will be they should check when I left there so how can I know they tried to flash something and that changed but maybe would not be enough. Thanks .
**Ultimate GS3 sudden death thread**
- Thread starter Obagleyfreer
- Start date
R: **Ultimate GS3 sudden death thread**
http://xdaforums.com/showthread.php?t=2096045
Inviato dal mio GT-N7100 con Tapatalk 2
http://xdaforums.com/showthread.php?t=2096045
Inviato dal mio GT-N7100 con Tapatalk 2
Are they voiding your warranty cause the system status changed to custom? I thought this happens to all S3 that suffer Sudden death which can access download mode? Is the device name blank also?
I don't think you will get problems. It is completely NORMAL that in the "half" sudden death case, where the bootloader/download mode still works, the system status switches to custom.
Even on the Note 2 (has SD-Problem, too) it switches to exact that state:
http://xdaforums.com/showthread.php?p=35977007#post35977007
I assume the bootloader checkes some system files and swiches then to official.
But cause of the eMMC is half broken and the bootloader can't check that files, it stays on custom.
BR
Rob
@Rob does binary count reset to No after sudden death also or does it still show the count if I rooted and did not use Triangle away app
Long way for a fix yet, no point in giving false hope to people just puts devs under pressure that are working hard out on it.
Sent from my GT-I9300 using Tapatalk 2
In the "half" sudden death case the counter swiches "automatically" to 0/no. You didn't need to run triangle away before sudden death.
I assume the counter value is stored in the part of eMMC that is not readable by the bootloader after "half" sudden death and so the bootloader shows 0/no.
BR
Rob
well I read some people out of xda complaining samsung did that
http://www.geekzone.co.nz/forums.asp?forumid=97&topicid=111571
To say that system status custom means the device was root sounds like the defense of samsung keep saying there is no problem in non root devices.
That is why I went myself and left a letter saying I was running offical carrier firmware (which is true.. didn´t say anythink about root (was not before die) or download mode info because by now I have no idea what are these things
and asking for a new device with 4.1.2 which is not available for my carrier but is for unbranded phone). I even asked if they needed I could wait they try to fix or check something (I knew they would not, even having techincals there, and they really didn´t...only checked for physical aspects).I have no experience with samsung warranty service here, but many dramas with LG, so I need to be ready.
AW: **Ultimate GS3 sudden death thread**
@aalvico:
Yes, normally system status custom is the correct indicator for a rooted phone.
BUT in case of "half" sudden death system status switches to custom even if the phone was never! rooted.
And yes, when the service center does not know this fact, this can lead to their assumption, that the phone was rooted even if is was not rooted.
German service centers know it now, that custom & product name empty = half sudden death.
BR
Rob
@aalvico:
Yes, normally system status custom is the correct indicator for a rooted phone.
BUT in case of "half" sudden death system status switches to custom even if the phone was never! rooted.
And yes, when the service center does not know this fact, this can lead to their assumption, that the phone was rooted even if is was not rooted.
German service centers know it now, that custom & product name empty = half sudden death.
BR
Rob
Fix does no good when my phone is already dead.
Sent from my GT-P7510 using Tapatalk 2
Last edited:
I have a strange behavior on my phone.
It started freezing after 2 weeks since i received the updated (custom stock). So i left it and after 20 minutes of waiting it went on normally. But the problem was it happens every hour or so.
The strange think about my case was, it only happened while mobile data connection or wifi was turned on. Wifi not that often as when mobile data connection was used. So turning off data connection prevented my phone from freezing but that was no solution for me cause then i could go back to some 1900 cellphones lol :laugh:
I decided to go to custom rom (CyanogenMod 10.1) and then it does not happen again for 2 weeks. The it started to freeze again 2 days ago.
Even with CyanogenMod it's the same behavior that it only freezes with data connection on.
Anyone has some advice for me ?
Cheers,
Dark Smile
It started freezing after 2 weeks since i received the updated (custom stock). So i left it and after 20 minutes of waiting it went on normally. But the problem was it happens every hour or so.
The strange think about my case was, it only happened while mobile data connection or wifi was turned on. Wifi not that often as when mobile data connection was used. So turning off data connection prevented my phone from freezing but that was no solution for me cause then i could go back to some 1900 cellphones lol :laugh:
I decided to go to custom rom (CyanogenMod 10.1) and then it does not happen again for 2 weeks. The it started to freeze again 2 days ago.
Even with CyanogenMod it's the same behavior that it only freezes with data connection on.
Anyone has some advice for me ?
Cheers,
Dark Smile
Guys - is there a way to fully brick the phone to send it in service and get the motherboard replace. I just can't stand the freezes!!!
I have a strange behavior on my phone.
It started freezing after 2 weeks since i received the updated (custom stock). So i left it and after 20 minutes of waiting it went on normally. But the problem was it happens every hour or so.
The strange think about my case was, it only happened while mobile data connection or wifi was turned on. Wifi not that often as when mobile data connection was used. So turning off data connection prevented my phone from freezing but that was no solution for me cause then i could go back to some 1900 cellphones lol :laugh:
I decided to go to custom rom (CyanogenMod 10.1) and then it does not happen again for 2 weeks. The it started to freeze again 2 days ago.
Even with CyanogenMod it's the same behavior that it only freezes with data connection on.
Anyone has some advice for me ?
Cheers,
Dark Smile
Sorry dude,
It might stop freezing and it might die. Mine died after downgrading via kies to 4.1.1 about a week later.
Nothing you can do about it. Prey if you are religious.
check out this thread: http://xdaforums.com/showthread.php?t=2122346
---------- Post added at 11:50 AM ---------- Previous post was at 11:47 AM ----------
Guys - is there a way to fully brick the phone to send it in service and get the motherboard replace. I just can't stand the freezes!!!
Downgrade to 4.1.1 and wait.
keep in mind it might be a Semi-Brick, which means problems with the warranty.
As far as I know, yes. The old phone state doesn't matter anything.
In "half" sudden death case it switches to empty/no/official/custom, don't matter what it was before "half" sudden death.
BR
Rob
---------- Post added at 11:12 AM ---------- Previous post was at 11:10 AM ----------
I decided to go to custom rom (CyanogenMod 10.1) and then it does not happen again for 2 weeks. The it started to freeze again 2 days ago.
Even with CyanogenMod it's the same behavior that it only freezes with data connection on.
Anyone has some advice for me ?
Cheers, Dark Smile
Please try this and report back here or in this thread:
http://xdaforums.com/showthread.php?p=37976063#post37976063
BR and good luck
Rob
@Aero_med:
I'll pay
First suggestion is working, everytime it freezes i wait for about 20 (+/- 10) minutes and then it keeps on working. I try the dummy file generator this evening and give feedback.
Thanks,
Dark Smile
I'll pay
First suggestion is working, everytime it freezes i wait for about 20 (+/- 10) minutes and then it keeps on working. I try the dummy file generator this evening and give feedback.
Thanks,
Dark Smile
Dead GS3
Welp,
My phone just suddenly died yesterday, in the middle of the day right after I locked the phone. Got the phone around July 31 so it's just about on the 6mo mark. Rooted with the latest CleanROM(4.1.1).
Contacted Samsung and it would have taken at least 10days turn around time, 2 days Fedex to Texas, then 5-7 business days for the actual repair. NO way I can function without a phone for that long.
Instead I contact VZW and they overnighted a replacement which I'll get today for the expedited cost of $12.99. Talked to the tech handling my case and they're not fully aware of the issue(so they say), despite Samsung officially acknowleding it.
Which leads to my question why most are going directly to Samsung for their warranty repair when VZW will honor the 1year mftr's, who will ship you a replacement. This question only applies to those who got their phones from their cellular provider. Don't most offer this kind of service?
cheers
Welp,
My phone just suddenly died yesterday, in the middle of the day right after I locked the phone. Got the phone around July 31 so it's just about on the 6mo mark. Rooted with the latest CleanROM(4.1.1).
Contacted Samsung and it would have taken at least 10days turn around time, 2 days Fedex to Texas, then 5-7 business days for the actual repair. NO way I can function without a phone for that long.
Instead I contact VZW and they overnighted a replacement which I'll get today for the expedited cost of $12.99. Talked to the tech handling my case and they're not fully aware of the issue(so they say), despite Samsung officially acknowleding it.
Which leads to my question why most are going directly to Samsung for their warranty repair when VZW will honor the 1year mftr's, who will ship you a replacement. This question only applies to those who got their phones from their cellular provider. Don't most offer this kind of service?
cheers
Well this thread is about the international version (i9300), but interesting that your Verizon version died.
Is yours a Gt-I9300 I did not know Verizon even sold the international phone only the dual core models?
Edit: never mind..... I live in Alaska and got excited because yours was being repaired in Texas but re-read your post you have a Verizon Galaxy S3 not the Same (those Dual core models are not affected by sudden death different insides)
Last edited:
Yeah. I've personally called Samsung US who pointed me to Samsung UK (because I have an i9300). The US staff told me their repair center in Texas doesn't repair international models because they don't have the parts, which is a valid reason.
Similar threads
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
You won't. These are HIGHLY proprietary to Samsung's storage people.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.
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.
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.
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.
Correct, although we could add a printk to kernels to print out the info.
Correct.
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.
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.
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
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...)
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
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.
Just like Superbrick.Nothing can fix an SDS because the phone is already dead.
But to prevent it, yes it seems. One of those at this moment.
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.Samsung haven't fixed the super brick bug yet
Sent from my GT-I9100 using Tapatalk 2
Unknown. Often flaws like this are firmware-dependent.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
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.
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.Theoretically if you have the same chip, you are candidate for sds sometime....
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
If you have VTU00M fwrev 0xf1 flash, you are probably at risk. I9305 is too new to tell
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.
Unknown. Right now any device with VTU00M flash is at risk - but how high the risk is we don't know.
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.
Bull****. You have ZERO evidence to substantiate this claim.
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.
If it's a wear leveller bug, there's a possibility fixed wear leveller firmware might "repair" damage to the internal data structures.
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.
Don't make definitive claims you have no evidence to support.27
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
I have yet to see any such reports... The one report I've seen of an XXELLA failure was XXELLA system + Siyah.
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.
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.
