It is a know symptom of SDS.
https://play.google.com/store/apps/details?id=net.vinagre.android.emmc_check&hl=en download this app and take a screenshot. Please don't post if your phone is not showing any symptoms.
are they trying to fix something on the background ??
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:
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.
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.
So far all of them were running other kernels.
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.
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
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.
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.
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...)
Don't make definitive claims you have no evidence to support.
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.
All of the symptoms and behavior pointed this way.
