FORUMS
Remove All Ads from XDA

Discussion thread for /data EMMC lockup/corruption bug

5,342 posts
Thanks Meter: 7,233
 
By sfhub, Senior Member on 9th May 2012, 01:08 PM
Post Reply Email Thread
30th May 2012, 04:52 PM |#401  
Inactive Recognized Developer
Thanks Meter: 2,835
 
Donate to Me
More
Quote:
Originally Posted by sfhub

You can put the workaround in either place, each has positives and negatives. I suggest you take both approaches.

If you do the workaround int he kernel mmc driver, all Recovery and update-binary executables (even if not recompiled/relinked) will no longer trigger the issue *IF* they are repacked with the new kernel.

However in the case that Samusng didn't place their workaround in the kernel mmc driver, you are then forcing everyone to use a "recompiled" kernel to get the "safe" feature, rather than having the flexibility to use "repacked" stock kernels. Some people prefer "repacked" stock kernels.

If you do the workaround in libext4_utils.a, there are 2 ways you can go about it:
1) just use the pre-existing GB binaries for Recovery and update-binary. This doesn't even need a recompile. This doesn't even need ICS source.
2) put the workaround in the ICS libext4_utils.a. You don't need to make changes in 2-4 places. You just need to make the one change in wipe.c mentioned earlier, then *relink* your existing Recovery and update-binary against the patched libext4_utils.a. There is no need to "fork" Recovery or update-binary, since you just make the change once at the lowest "user-space" level code.

The advantage of the workaround in Recovery and update-binary, is it will work with any kernel (even the existing "unsafe" ones) and you can do it right now, even without needing to access any ICS source code.

You would need to have the people who put together kernel images start using the GB-based Recovery binary and also instruct the people putting together ROM packages to use the GB-based update-binary, the latter is something most ROM developers already do on E4GT, except possibly the AOSP/AOKP folks.

If you opt for the source code change, you are going to fork a file somewhere, either a build make file or some include file in the case of the mmc driver workaround, or a single function in wipe.c. It is no more or less difficult to maintain a fork of the build make file as it is to maintain a fork of wipe.c.

We already know having the workaround in Recovery and update-binary coupled with an "unsafe" kernels that do mmc_erase() works fine as most of us have been running this way since the beginning. We never heard of these EMMC lockup/superbricks in GB and the "workaround" in GB was essentially placed in Recovery and update-binary, because the kernel had MMC_CAP_ERASE enabled.

So why don't you just do both methods? That addresses the most situations and gives the most flexibility in producing "safe" environments.


you are right

and u have pointed out the pros and cons for the 2 approaches clearly

i am pleased with respects (hope i say this correctly)
 
 
30th May 2012, 06:47 PM |#402  
Member
Thanks Meter: 10
 
More
eMMC Bug with ICS + Samsung Note
Hey guys, sorry to interrupt you... I have been reading a lot of threads to gather some information about the issue I am having, and it seems like it has to do with the eMMC issue+ICS+Wipe. My Samsung Galaxy Note has not been bricked yet, but it's acting weird and I suspect some issues with some of the blocks.

This is what I did:

1. Upgrade from GB to ICS using Mobile Odin. I have backed up everything using CWM, Titanium Backup and a tool named BackupEverything (to recover text messages/sms, bookmarks, call log). Before upgrading I wiped everything from within CWM.

2. Downgrade to GB again, wiping the device from within CWM and using CWMs backup. I had to do this because this stupid tool BackupEverything did not correctly backup my bookmarks, texts and calllog.

3. Upgrade back to ICS, wiping the device from Within CWM and using CWMs backup.

Everything has been working so far. However, just recently I wanted to backup my device again, but the backup process always aborts at some point (nearly towards the end of the /system partition), and the device boots.

My questions:

1. Could it be that the eMMC bug affected me?

2. I read that this bug ONLY happens if you wipe your device in ICS directly, or in CWM, but ONLY if CWM 5.5+ later has been used because it really tries to null the blocks, whereas older version just mark the partitions clean (kind of soft format)

3. If the eMMC bug affects me...
a. can I easily fix this afterwards? Is there any hope for it?
b. if not... then I'd like Samsung to repair this device, because the fuc*ed up. But I have to clean the device completely (incl. removing CWM+root), and brick it in such a way that they have to replace the device.

Basically I am trying to gather some more definite statements about the cause. For a novice like me it is incredibly frustrating reading so many posts (I literally spent hours!) and contradicting statements.

Thanks for your time, and of course any help is appreciated!
30th May 2012, 07:07 PM |#403  
garwynn's Avatar
Retired Forum Moderator / Inactive Recognized Developer / XDA Portal Team
Flag NE Ohio
Thanks Meter: 8,731
 
Donate to Me
More
Quote:
Originally Posted by niko26

1. Could it be that the eMMC bug affected me?

Possible if #2 or #3 was CWM based on an ICS kernel. Then again you may have gotten lucky.

If you can try a stock ODIN One-Click (GB version preferred) and see if goes through. If you get stuck at /system every time you're probably affected. (According to what I've read on the Note's issues this seems to be the partition affected.)

Quote:
Originally Posted by niko26

2. I read that this bug ONLY happens if you wipe your device in ICS directly, or in CWM, but ONLY if CWM 5.5+ later has been used because it really tries to null the blocks, whereas older version just mark the partitions clean (kind of soft format)

What we've found is that the kernel that CWM or recovery is based on appears to be how you can tell. ICS builds have a new erase feature that doesn't agree with the eMMC and causes it to lock up (freeze) - GB didn't have this as it wasn't introduced until HC.

Quote:
Originally Posted by niko26

3. If the eMMC bug affects me...
a. can I easily fix this afterwards? Is there any hope for it?
b. if not... then I'd like Samsung to repair this device, because the fuc*ed up. But I have to clean the device completely (incl. removing CWM+root), and brick it in such a way that they have to replace the device.

a) At the moment replacement is the way to go. You can temporarily repartition to restore use but even the guy who has made the custom PIT file (hg42) is not suggesting this for long term use.

b) This seems to be the sticking point right now because Samsung has told others that it won't do so on custom builds. If you had done this on pure stock without CWM you'd probably have an easy case.

What most people have been doing with the E4GT is flashing what they can of a stock build and then taking it to Sprint and asking them to exchange/replace - and then using insurance as a fallback. Don't know what options you have but might help.

And one last thing - if you're on the AT&T note you can ignore this post. Every sample we saw said the I717 is on the new eMMC revision and should not be able to be affected by what we're discussing here.

Hope that helps!
The Following 2 Users Say Thank You to garwynn For This Useful Post: [ View ] Gift garwynn Ad-Free
30th May 2012, 07:14 PM |#404  
Member
Thanks Meter: 10
 
More
Thanks a lot for your help, garwynn!
Quote:

If you can try a stock ODIN One-Click (GB version preferred) and see if goes through.

Is there any other way how to verify whether any blocks have been affected?
30th May 2012, 07:32 PM |#405  
garwynn's Avatar
Retired Forum Moderator / Inactive Recognized Developer / XDA Portal Team
Flag NE Ohio
Thanks Meter: 8,731
 
Donate to Me
More
Quote:
Originally Posted by niko26

Thanks a lot for your help, garwynn!

Is there any other way how to verify whether any blocks have been affected?

If it is the bug poking around in the affected area will cause the device to freeze.
30th May 2012, 08:37 PM |#406  
Member
Thanks Meter: 1
 
More
Quote:
Originally Posted by niko26

Is there any other way how to verify whether any blocks have been affected?

(don't do this if you are beginer)
in terminal or adb as root
dd if=/dev/block/mmcblk0 of=/dev/null bs=1024 & watch -n 1 kill -USR1 $!
It will read whole emmc till the end. Watch will update you about the progress every sec at the end you need to press CTRL-C to kill watch.
(hope mmcblk0 is on note the emmc).

As beginer
You boot into CWM and run backup. It will finish or lockup (if it finishes you likely ok, if it fails, I would sugest the dd if=.... .
The Following User Says Thank You to monoko For This Useful Post: [ View ] Gift monoko Ad-Free
30th May 2012, 08:57 PM |#407  
Member
Thanks Meter: 10
 
More
Quote:
Originally Posted by garwynn

If it is the bug poking around in the affected area will cause the device to freeze.

Do you mean poke as on the Commodore/CBM C64's PEEK and POKE?

In other words.. is it sufficient to read the blocks (PEEK(x)) or do I need to write the blocks (POKE(X))?

Quote:
Originally Posted by monoko

(don't do this if you are beginer)
in terminal or adb as root
dd if=/dev/block/mmcblk0 of=/dev/null bs=1024 & watch -n 1 kill -USR1 $!
It will read whole emmc till the end. Watch will update you about the progress every sec at the end you need to press CTRL-C to kill watch.
(hope mmcblk0 is on note the emmc).

As beginer
You boot into CWM and run backup. It will finish or lockup (if it finishes you likely ok, if it fails, I would sugest the dd if=.... .

Here is the funny thing, I already tried dd'ing, it went through fine. However, CWM and backup does *not* finish.
30th May 2012, 10:24 PM |#408  
Member
Thanks Meter: 1
 
More
I din't see yet the bug myself.. but All reports in this thread are saing if you Access invalid block it will freeze. So if dd is ok (till end of the device), thant I would expect you don't have the corrupted flash internals
about backup freeze I would guess some other corruption. Kernel should complain. You can try to triger the problem an look at log
tar --exclude=sys --exclude=proc -cvf /dev/null /
(backup of / to /dev/null (except /sys /proc )
and check log with
dmesg

tested on i777
30th May 2012, 11:56 PM |#409  
Member
Thanks Meter: 10
 
More
Hm, I didn't get any error report. Still don't understand why backup in CWM aborts with a reboot of the device
31st May 2012, 12:13 AM |#410  
Member
Thanks Meter: 1
 
More
Unless someone responds, I don't thing you affected and we should not continue in this thread, as well I have no idea why is cwm crashing on you. I can try to help you, but I would do some sort of "SAFE ERASE" and/or REFLASH. And continue somewhere else as in this thread. Be careful about the ERASE.
31st May 2012, 04:01 AM |#411  
garwynn's Avatar
Retired Forum Moderator / Inactive Recognized Developer / XDA Portal Team
Flag NE Ohio
Thanks Meter: 8,731
 
Donate to Me
More
Did you try using an ODIN one-click instead of CWM? I'll bet that will get you back to a safe point - then reload CWM and try again.
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes