03-26-2012 11:32 AM
A guy I know showed me ICS on his AT&T Samsung Galaxy S II Skyrocket running Android 4.0 / ICS. I checked for updates, but I don't have any updates. Did AT&T release it or not? Is there something wrong with my phone?
06-12-2012 9:07 AM
06-12-2012 9:21 AM - edited 06-12-2012 9:29 AM
Neither the SHG-I717 nor the SGH-I727 are on any site I can find concerning the brick bug. The 727 is the Skyrocket. The t989 is a Galaxy S II. The Galaxy S II has a different radio and processor in it than the 717 and 727. If you have used the brick bug detector put out by chainfire you would know that it checks the processor model to determine if you're at risk. You people keep putting this crap on here could be ruining someone else's chance of getting either a Skyrocket or Note which are perfectly fine phones. Do your research. Reading is fundemental.
Reading IS fundamental. Do YOUR research. You clearly have not done your research, nor have you read.
You obviously don't understand the nature of the bug, since Chainfire's app checks NOTHING about the processor model. You are 100% DEAD WRONG in your claim that it does. It checks the eMMC (storage) chip model and firmware. Recent events (as in - confirmed brickings) have indicated that the eMMC model/fwrev present in the I727 and T989 is affected. (I717 is, however, safe - all units so far have reported VYL00M fwrev 0x25 which is known to be safe.)
I've been manually checking model/fwrev of multiple devices since long before Chainfire's app was released - Much of his "affected/not affected" list came from data compiled by myself, sfhub, and garwynn on XDA.
You seem to claim to know so much more about this issue than I do - How many Samsung devices are you a Cyanogenmod co-maintainer of? (2 here) How many times have you been credited for your research on this issue by articles on the XDA portal regarding it? (I'm credited in two of three posts.)
For a while, it was assumed that Samsung was only shipping defective eMMC chips in Exynos-based devices, but since then, we've had confirmation that:
1) Tegra2-based Tab 10.1 units have been seen to contain the defective eMMC chip. Fortunately, Honeycomb kernels appear to block erase commands from hitting the chip just like Gingerbread ones do. pershoot is applying "extra paranoia" and adding extra changes to make sure ERASE commands are fully disabled though to the Tab 10.1 CM9 kernels.
2) Multiple Qualcomm-based devices, including the I727 and T989, have a previously unknown but now confirmed defective eMMC chip, AND the ICS leaks for these devices allow erase commands through to the chip - there have been confirmed bricking events. For example, http://review.cyanogenmod.com/#/c/17326/ was written by one of the people doing the Cyanogenmod bringup for Skyrocket - who bricked when using a leak kernel as a new base for recovery.
3) The OMAP4-based I9100G, although so far, no kernels have appeared that allowed ERASE commands through to the chip or codeworkx is just lucky (I haven't had time to review the MMC driver of the t1 kernel yet)
4) Some OMAP4-based Kindle Fires have an 8GB Samsung flash chip which has been confirmed as vulnerable to the bug (M8G2FA fwrev 0x11). Others have a Toshiba flash chip with is not defective.
06-12-2012 12:00 PM
Also http://forum.xda-developers.com/showthread.php?t=1693704 is also useful.
http://forum.xda-developers.com/showpost.php?p=27074278&postcount=69 is also useful - It identifies which kernels are safe/unsafe for devices that have defective eMMC chip. (Even with the defective eMMC chips, you're safe if the kernel you are running doesn't fire ERASE commands at the chip. I727 and I777 leaks are unsafe - all known I777 custom kernels are safe due to being based off of the safe I9100 Update4 source base.)
06-12-2012 1:11 PM
Good discussion all but please keep it courteous. I don't want to have to kill a good thread because of how people talk to each other in it.
06-12-2012 2:31 PM
I am unable to edit my previous post, but one thing to note: Confirmation of brickings with I727/T989 leaks is recent news (as in I first found out Friday afternoon.)
Also, there are rumors that the official OTA for T989 might have a kernel fix so that it won't trigger the defect. I won't have time until tonight to review their source code to see if they rendered the kernel safe.