[Galaxy S III General] Entropy512:
You won't. These are HIGHLY proprietary to Samsung's storage people.

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.

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.

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.

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.