Kernel issue - Bricked By a Stunner Rom version

Status
Not open for further replies.
Search This thread

gedster314

Senior Member
Sep 7, 2007
935
126
Oxnard, Ca
I've tried every version of stunner and had very little issues. I'm consistently going back and fourth between Milka's CM9 and Stunner.

I second trying the jig. It's just some resistors jumping 2 pins on the micro usb connector. It's cheap, easy and only requires a trip to Radioshack. I've jigged my Epic4gtouch. Look through he reset the triangle counter with a jig. You may gain some flashing insights. I have done some jtag work before too but on routers and cable modems but not phones. Jtag requires a special computer interface and on the note probably requires soldiering to small locations. Nothing about jtag is difficult but does require following instructions exactly.
 

FirstNoobToBrickHisPhone

Senior Member
Sep 15, 2009
887
96
I'm guessing Stunner Rom really Stuns your phone.
1139482_o.gif


YYYEEEEEEEEEEEEEEAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
 
  • Like
Reactions: Zamboney

MR.change

Senior Member
Nov 9, 2011
532
123
Baghdad
The problem is not ICS but the Install Script. The same problem occured on a custom kernel...
well either ways I'm not flashing a beta into my phone

it's very tempting and the wait is killing me ,but I'm not about to risk murduring my 3 weeks old Note ;)

better wait for sammy to release source code and then ICS custom ROMs will quickly become safe to flash
 

emuX

Senior Member
Sep 2, 2009
368
77
Well what would you recommend I do from here though? I want to get this fixed as soon as possible.

First off, I wouldn't panic. How bricked is it?

Can you get it into download mode? If you can then you might be able to re-flash a stock ROM. Check out this excellent thread by Dr Ketan: http://xdaforums.com/showthread.php?p=20963718

Hopefully its not as bricked as you think.

I have rooted and installed ICS Stunner and thought I'd bricked it at one point. I managed to get back into dload mode, re-flash a stock ROM and start again.

In case you didn't know, you may be able to get into CWM recovery by holding volume up, power and home buttons on boot.

Good luck.
 

SpyderTracks

Senior Member
Jan 13, 2007
2,890
558
London
First off, I wouldn't panic. How bricked is it?

Can you get it into download mode? If you can then you might be able to re-flash a stock ROM. Check out this excellent thread by Dr Ketan: http://xdaforums.com/showthread.php?p=20963718
I have rooted and installed ICS Stunner and thought I'd bricked it at one point. I managed to get back into dload mode, re-flash a stock ROM and start again.

I would second this, a hard brick is hard to do, I hope you have a soft brick and are able to recover. Hard brick means you've short circuited your memory chips or supply board and that takes a jolt. If not, you're soft bricked and can easily recover with pc odin or otherwise. Wish u the best.

Sent from my GT-N7000 using xda premium
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
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 ;)
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
 
Last edited:

remixtech

Senior Member
Mar 15, 2009
424
133
Lille
www.mevaere.fr
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

So all ics leak kernel are very dangerous ??


Envoyé depuis mon GT-N7000 avec Tapatalk
 

Scorbion

Senior Member
May 6, 2005
257
20
Riyadh
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

So the chance that u get a hard brick only happens during flashing a rom with affected kernels, am I right??
 

rkick07

Member
Aug 12, 2010
43
1
I am running stunner at the moment no problems.

Have you used PC or mobile odin ?

i originally rooted my phone and flashed it using odin on the PC. I've had criskelo installed with no problems as well as romwo( i think its called like that) now i want to flash V2 of criskelo but it does not load it just sits there. and when i try to re flash V1 the yellow status bar like runs of the screen and just sits there also..
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
So the chance that u get a hard brick only happens during flashing a rom with affected kernels, am I right??

No:
Wiping when running an affected kernel
Restoring Nandroid when running an affected kernel (wipes first)
Flashing something to /system when running an affected kernel (most flashes wipe /system first)
Unconfirmed but likely: Wiping in 3e recovery with an affected kernel, deleting a large file with an affected kernel

The initial flash of an affected kernel won't cause a problem as the flashing is done by an existing good kernel (unless you flash from another broken kernel of course) - it's USING the affected kernel that causes problems.

Not everyone hardbricks - some people wind up with some of their partitions becoming unusable - a lot of I9100 people that flashed Siyah 3.1rc6 have problems with /data for example.
 

brockyneo

Senior Member
Jan 17, 2010
3,683
397
In The Matrix
No:
Wiping when running an affected kernel
Restoring Nandroid when running an affected kernel (wipes first)
Flashing something to /system when running an affected kernel (most flashes wipe /system first)
Unconfirmed but likely: Wiping in 3e recovery with an affected kernel, deleting a large file with an affected kernel

The initial flash of an affected kernel won't cause a problem as the flashing is done by an existing good kernel (unless you flash from another broken kernel of course) - it's USING the affected kernel that causes problems.

Not everyone hardbricks - some people wind up with some of their partitions becoming unusable - a lot of I9100 people that flashed Siyah 3.1rc6 have problems with /data for example.

Wow so basically leave ics alone till official release mmmm I was starting to love stunner rom too
 

iakovl

Senior Member
Jun 1, 2010
1,292
80
36
Tibirias
www.iopanel.net
so... if i use LP5 kernel on my stunner 1.4.19 right now (afraid to kill = i dont upgrade)
will i kill the Gnote if i try to go 1.4.26.1
and will i kill it if i do Darky's resurrection?
 
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 16
    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.
    8
    I am still unsure what kernels are a problem or is it all N7000 ICS roms

    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.
    7
    But these kernels were not supposed to get outside of their labs ? Did they ?
    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.

    my understanding is that there is a problem in the way the exynos hardware handles the trim function, not the function itself.
    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
    6
    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 ;)
    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
    5
    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.