Kernel issue - Bricked By a Stunner Rom version

A bit more information:
The way flash memory works, it needs to be erased before writing to it. This is a bit different than spinning magnetic disks, where you just overwrite it. Writing new data to a blank disk and writing data over existing data were identical in performance.

As a result, with magnetic disks, the classic way of deleting a file or formatting a partition was just to delete references to it - the actual file contents would still be there. On flash, this was not optimal for performance because writing to blank blocks is much faster than writing to a block that has info on it because that block must be blanked first.

Eventually, the TRIM command was added to various operating systems, such that when a partition was formatted or a file deleted, the OS could tell the flash controller that those blocks were no longer used and could be erased immediately. It makes the wear leveller's job easier to have a list of "unused" blocks.

I believe MMC_CAP_ERASE is related to TRIM (I haven't had time to figure out the exact differences) - even with TRIM disabled, it seems to make a difference. Gingerbread kernels and I9100 ICS kernels don't support TRIM or ERASE. ICS kernels for SHW-M250S/K/L support ERASE - and these seem to have a risk of hardbricking or permanent eMMC damage when you do a large ERASE - confirmed for a wipe in CWM and any operation that wipes first, suspected for wiping in 3e recovery of a non-repacked leak kernel that is affected, and I suspect a large file deletion (such as a video file of hundreds of megabytes) may also be risky - but I'm not sure.

It seems like ICS leaks for the Epic 4G Touch, AT&T Galaxy S II (SGH-I777), and the Galaxy Note (GT-N7000 and GT-I9220) have the same issue as the SHW-M250S/K/L kernels based on reports. Unfortunately leak kernels don't have source so there's no way to tell what changed, no way to know which ones are dangerous and which ones aren't. For this reason I don't trust any ICS leak kernels for the above devices.

This may be a problem only for a small percentage of users - 1%, 2%, maybe as high as 5% - who knows. Other people are fine with the affected kernels - for example Task650 and ktoonsez never had any issues with the UCLD3 leak kernel, but others hardbricked. gokhanmoral was able to wipe multiple times with SiyahKernel 3.1rc6 (based on SHW-M250L ICS sources instead of GT-I9100 ICS sources), but others hardbricked or experienced permanent damage when wiping.

Right now, MMC_CAP_ERASE seems to be the suspect - but no one can be entirely sure without:
Source code for leaks of affected devices that don't have source (Note, E4GT, I777)
Taking dangerous risks such as trying to reproduce the problem - if you reproduce it, it's time for a motherboard replacement.

The only thing we know for sure is that the GT-I9100 ICS leaks and official releases seem safe, as are kernels built from the I9100 Update4 source drop, as are all known Gingerbread kernels for any device.

copperdawgnc said:

I am still unsure what kernels are a problem or is it all N7000 ICS roms

Click to expand...

Click to collapse

Right now:
Any Gingerbread kernel is OK
The only current ICS kernel for N7000 that is built from I9100 source is DAFUQ (name might change with the next release... My Touchwizz kernels no longer can be considered "daily driver" since I usually run CM9). Others are welcome to fork my source if they wish.
Anything ICS-based that is a repack of a leak kernel is DANGEROUS.

I'll work with xplodWILD to get CM9 builds going soon, hopefully this weekend, using a kernel built from I9100 sources which seems to be safe.

milsabords said:

But these kernels were not supposed to get outside of their labs ? Did they ?

Click to expand...

Click to collapse

The SHW-M250S/K/L sources not only got out of the labs, but were officially released by Samsung.

This source code base and the SiyahKernel 3.1rc6 debacle over in the I9100 forums is the best "smoking gun" pointing to a kernel bug - When Siyah was rebased on the M250L sources with NO changes to recovery other than swapping /emmc and /sdcard, people started hardbricking in the exact same manner as the hardbricks encountered here - device freezing during a wipe followed by either damaged unusable partitions or a full hardbrick, with the device not being recoverable by JTAG recovery services.

When gokhanmoral returned to the I9100 update4 source base, using the exact same recovery - no more problems.

chill392 said:

my understanding is that there is a problem in the way the exynos hardware handles the trim function, not the function itself.

Click to expand...

Click to collapse

Yes, although it's actually a relative of TRIM (ERASE) that seems to be at play here. Samsung disabled TRIM in their latest M250L source base but it didn't solve the problem.

My guess is that there's a bug in the flash chip or the kernel routines for erasing a chip that only happens when a large number of blocks are erased simultaneously - which is why it usually happens during a wipe.

Hmm... crud... Looks like Gingerbread kernels support ERASE but are safe. Probably ERASE capability is interacting badly with something else... Great, this makes it harder to determine whether a future source drop is safe or not.

What we know:
It happens with current SHW-M250* sources
It never seems to happen with kernels built from the I9100 Update4 source base
It happens with leaks for this device, Epic 4G Touch, and SGH-I777 (AT&T GSII)
It typically happens during an operation (such as a wipe) that erases a very large block of data
Devices bricked in this way are so severely damaged that JTAG recovery is not able to fix them

What we don't know:
Exactly how it happens
How to determine a kernel is "safe" other than track record - this means that any future kernel release coming from Samsung could be dangerous, we have no way of knowing

letters_to_cleo said:

don't lower your hopes down, I've seen countless and numerous times of Bricked Notes being revived and restored thru JTAG. This process is the much low level process you can get of restoring your Note into it's normal process. I don't see why your Note can't be restored if it's done thru JTAG.

(Not unless you have a broken ICs or chipsets already, which contitutes a hardware failure and that's the time you may have to replace it.)

JTAG is trusted already and proven to restore almost all bricked Notes.

Just from my own experiences..

Cheers

Click to expand...

Click to collapse

However, there's mounting evidence that kernels from the following category can cause permanent damage to the eMMC chip, in a manner that JTAG recovery is not possible:
All Epic 4G Touch (SPH-D710) ICS leaks
All GT-N7000 ICS leaks
SGH-I777 UCLD3 ICS leak (likely all ICS leaks)
SHW-M250S/L/K official releases along with anything built from the source code for those releases
SiyahKernel 3.1rc6 for I9100 is in this category due to being built from SHW-M250L update4 sources - all other SiyahKernel releases should be fine.

Right now the suspicion is that it is due to Samsung enabling MMC_CAP_ERASE in the MMC driver for these kernels and the eMMC chip or Exynos hardware having some sort of flaw related to handling MMC ERASE commands (a performance feature that allows the wear leveler to erase a block in advance and flag it as such, rather than erase-before-write when writing), however this is not yet confirmed. The most likely situations that will cause damage are ones that involve a heavy MMC ERASE workload:
CWM wipes and Nandroid restores (which wipe first) - confirmed
Wipes in 3e recovery - suspected
Deletion of any large file during normal operation may also cause this to happen - suspected but not confirmed

Kernels that so far do not appear to be affected:
GT-I9100 ICS leaks
GT-I9100 ICS official releases
Anything built off of the GT-I9100 update4 source code release

every time i consider bumping to a Custom ICS I see a thread like this or some issue that is a showstopper for me.

I'm glad I haven't yet had ICS.