Results 1 to 3 of 3

Thread: Is there a bug in 4.0.3 ICS??

  1. #1
    Junior Member
    Join Date
    Nov 2011

    Is there a bug in 4.0.3 ICS??

    In XDA, HTCmania and a lots of forums said that our firmware version of the eMMc chip has a bug. If you are in ICS 4.0.3., last LPY and LQ2,When you makes a wipe it write all whit 1, instead in ginger who wrotes 0, and when the system call any sector of the memory whit 1, then the chip crash and the Note Bricks.
    What you have to do is DONT WIPE ANYWAY
    Are in Samsung working on it??

  2. #2
    Junior Member
    Join Date
    Nov 2011
    Copy And Paste:

    It would be beneficial to provide more information on the brick bug to avoid some people getting unnecessarily scared (such as most I9100 users).

    This bug requires three things for you to be in danger, and ALL of these conditions must be met for danger:
    1) A defective eMMC chip/fwrev that is unable to handle eMMC ERASE commands (command 38) properly. (I'll provide a link with more detail on the nature of the bug later) - This condition is the one Chainfire's new app checks for. By the way, M8G2FA fwrev 0x11 (seen on some Kindle Fires) is also suspected of being defective.
    2) A recovery binary that attempts to erase partitions when formatting them. Most ICS recovery binaries fit in this category, most Gingerbread recoveries do not attempt to perform an erase operation so are safe. Note that also, an affected update-binary in a ZIP could be a cause of problems too. (e.g. flashing a firmware that has an ICS update-binary and formats the partition could cause a problem even with a "safe" recovery.) So a kernel can be repacked with a "safe" CWM (such as the most recent CF-Root releases) but it will still only be partially safe.
    3) A kernel that allows attempts to erase a partition to actually happen. (as opposed to reporting "not supported" and doing nothing.) - A common way of rendering a kernel safe is to remove MMC_CAP_ERASE from the capability flags in drivers/mmc/mshci.c

    As of June 6, 2012, this is what I know as far as kernels that meet condition 3:
    All GT-I9100 ICS leaks and official releases are SAFE (MMC_CAP_ERASE not present)
    All kernels based on GT-I9100 ICS Update4 sources are SAFE (MMC_CAP_ERASE not present) - This includes all CM9 nightlies for SGH-I777, GT-I9100, and GT-N7000
    All GT-N7000 ICS leaks are UNSAFE
    All GT-N7000 ICS official kernels are UNSAFE
    All kernels built from the GT-N7000 sources are UNSAFE unless the following condition is met:
    MMC_CAP_ERASE is removed from the capability flags in drivers/mmc/host/mshci.c - check the kernel features for this. Franco.kernel R3 and later and all Speedmod ICS releases are SAFE due to this.
    All SHW-M250S/K/L ICS kernels are suspected to be UNSAFE
    All SHW-M250S/K/L ICS source releases as of this date are UNSAFE (SHW-M250L Update4 was the cause of the SiyahKernel 3.1rc6 incident. Other Siyah releases are SAFE)
    All SPH-D710 ICS releases as of this date are UNSAFE - Rumor has it that the official OTA may have a fixed kernel, but it is recommended to consider this kernel UNSAFE until source code is released and can be reviewed.

    It's hard to get ALL of the cases and evaluate them, but in general in terms of levels of danger (As of June 6, 2012 - this could change with time):
    SPH-D710 users are in the most danger - They have no official ICS releases AND the I9100 Update4 source base can't be used to build a usable kernel for their device without major developer work
    GT-N7000 users are second on the list - They are the only ones outside of Korea to receive official ICS updates that trigger the eMMC firmware defect. However, I9100 Update4 sources required only minor work to create "safe" kernels, and developers know the proper procedure for rendering the official N7000 Update3 source drop "safe"
    SGH-I777 users are next - I777 leaks proved to be dangerous a month or so ago. However, the SGH-I777 required the least amount of work to be able to use the GT-I9100 Update4 source base, and as a result, with the exception of the leaks themselves, nearly all I777 ICS kernels are based off of safe source code bases.
    GT-I9100 users are in the least danger - No leak, official binary release, or source code release for this device has been dangerous. Only one I9100 kernel has ever proven dangerous and that was quickly pulled by its developer.

    I am not evaluating the SHW-M250S/K/L in the above list, as while I know their source and binaries are dangerous, the language/culture barrier means we have very little information on how this fiasco is panning out for those users.
    Samsung Galaxy S II (SGH-I777) -CM9, sometimes self-debloated/deodexed TW
    Samsung Galaxy Player 5.0 (YP-G70) - Stock system + my kernel
    Galaxy Tab 10.1 - Cyanogenmod 9
    Samsung Confuse 4G (SGH-I997) - Self-deodexed/debloated UCLB3 + my kernel

    Last devices - Huawei S7 and AT&T Tilt2 (RHOD300) running XDAndroid FRX06 (still have them collecting dust)

    My Github profile - Some Android stuff, some AVR stuff

    An excellent post on "noobs vs. developers"

    A few opinions on kernel development "good practices"

    [ Login above or register to see download links. ]

  3. #3
    Junior Member
    Join Date
    Nov 2011

    [ Login above or register to see download links. ]

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts