Here's the a question. Can anyone with an idea about all this comment on whether the lags faced by user a little before sudden death will be gone too after samsungs firmware update for sudden death?
??
Here's the a question. Can anyone with an idea about all this comment on whether the lags faced by user a little before sudden death will be gone too after samsungs firmware update for sudden death?
yep they said TE]
and they probably will update the eMMC firmware ( maybe with the new bootloader )
Is there any death of 32gb models?
Sent from my GT-I9000 using xda app-developers app
and the old firmware don't have an old bootloader? or cyanogen don't have a parallel bootloader?
Yes the current btu release (today)apparently has sudden death fix via the bootloader.
the bootloader already in the device and Rom will not change it , u have to use Odin to get the new bootloader
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.
that are only rumors! only thing that's committed is that the exploit is fixed!
Gesendet von meinem GT-I9300 mit Tapatalk 2
I've been getting the lags, freezes, and crashes ever since Christmas, but XXELLA hasn't helped me, it's still doing it.Here's the a question. Can anyone with an idea about all this comment on whether the lags faced by user a little before sudden death will be gone too after samsungs firmware update for sudden death?
If this wear levelling problem already damaged our phones and shortens the lifetimes even if samsung brings a fix today.
Or that this is not the case.. and why this is not the case.
Not quite - if the wear levelling algorithm is poor, and is wearing out sectors unevenly, they may be dying early, and perhaps they're not getting marked as bad, which is why we're occasionally getting crashes or freezes, and the system attempts to write/read from bad sectors.Because simple: its broken or not broken...something like: "my memory is a little broken" doesnt happen.
So If your phone havnt died yet its fine
Because simple: its broken or not broken...something like: "my memory is a little broken" doesnt happen.
So If your phone havnt died yet its fine
Sent from my GT-I9300 using xda app-developers app
Not quite - if the wear levelling algorithm is poor, and is wearing out sectors unevenly, they may be dying early, and perhaps they're not getting marked as bad, which is why we're occasionally getting crashes or freezes, and the system attempts to write/read from bad sectors.
It could be fixed by properly marking those sectors as bad, but they'll always be bad, so yes, permanent wear which can't be repaired through software.
Not quite - if the wear levelling algorithm is poor, and is wearing out sectors unevenly, they may be dying early, and perhaps they're not getting marked as bad, which is why we're occasionally getting crashes or freezes, and the system attempts to write/read from bad sectors.
It could be fixed by properly marking those sectors as bad, but they'll always be bad, so yes, permanent wear which can't be repaired through software.
I realise that, but you said "its broken or not broken" - I was merely pointing out it's not quite as simple as that.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
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
I realise that, but you said "its broken or not broken" - I was merely pointing out it's not quite as simple as that.
IF this is the problem (we're only speculating still), then theoretically Samsung could fix the wear problem, mark the bad sectors as bad properly, and the problem shouldn't return. Therefore, it's not either "broken or not broken".
People might lose a few bytes/kilobytes/megabytes of their memory, but they shouldn't notice.
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.
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:I'd hazard a guess that it does - but I'd certainly like someone like Entropy to weigh in.
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.Is there a way to check if I already have any bad blocks on my eMMC?
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.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.
Correct, although we could add a printk to kernels to print out the info.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.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?
No. Seriously - READ. It is at this point unambiguously an eMMC firmware failure that has NOTHING to do with the charger.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
So far all of them were running other kernels.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.
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.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
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...)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?
the key in that post is the word "now". That post was made yesterday - the patch has been making the rounds and is getting integratedI 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?
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.Have you searched for it in older kernels? Why wouldn't that string appear also in those? If it does, then this means nothing.
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
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....
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.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???
Unknown. Right now any device with VTU00M flash is at risk - but how high the risk is we don't know.Is it true that all 16gigs phone will die soon one day?
Sent from a better Galaxy designed for humans!
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.but Samsung says that will fix the issue with fw update.....or not?
there is no fw going to write to the NAND?
Bull****. You have ZERO evidence to substantiate this claim.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.
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.so we can only wait for the new bootloader from Samsung .... :crying:
If it's a wear leveller bug, there's a possibility fixed wear leveller firmware might "repair" damage to the internal data structures.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
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...)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 ?!
Don't make definitive claims you have no evidence to support.[KIES]I9300XXELLA 4.1.2->EXYNOS BUG FIXED!!S3 SUDDEN DEATH FIXED!!Jan.02,2013
http://xdaforums.com/showthread.php?t=2077844
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?
I have yet to see any such reports... The one report I've seen of an XXELLA failure was XXELLA system + Siyah.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 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.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.
All of the symptoms and behavior pointed this way.How come you knew that SDS is related to eMMC (and specifically version VTU00M) before samsung released their code? What led to this assumption?