yashsingh1/xdaforums huggingface dataset:
[Android Software Development] Alahdal:
Hi hg42..

First, I would like to thank you from the deepest of my heart for reviving my note :).

However, I have the problem of freezing hangs which is killing me :(.

I have flashed your partition scanners i.e. the infinitely and "Find_Brick_Start". For the infinitely, I have left it until the 50th check and nothing was wrong. While when I tried the other scanner, the mobile reboots when the scanner reach 700+ MB.

Could you advise, what would be the problem and what is the solution. Please.

Update: Now reboot comes when scanning reaches at 800+. However, it is quite long time now since last freeze :) ... "Touch Wood :) " around 6 hours now.
[Android Software Development] aDEO:
moved...
[Android Software Development] hg42:
I redirected my answer to PIT thread
[Android Software Development] hg42:
thanks for the links, looks like it may fit my problem, will try when spare time suddenly appears :)
[Android Software Development] hg42:
ok, in the mean time I think the "indefinite" scanner probably will always run as good as the "once" scanner.

As I said above, *if* your problem has to do with bricked blocks, it probably is triggered by writing files.

This is the only time the wear leveler gets into the play (because it randomly assigns real blocks to logical blocks).

Starting from this assumption, if I were in your situation, I would check with the find_brick_start and find_brick_end tools if the bricked block numbers are changing.

If my speculative theory about the wear leveler randomly assigning bad blocks to write requests applies to your case, the phone would freeze in that moment and after a reboot a read on the same block would probably freeze the phone again.

So after a freeze the find_brick_* tools may find a different brick start or brick end block number as before.

If it always stays the same, I would put my theory in question.
[Android Software Development] Alahdal:
How could you get logcat running in recovery mode. I am facing a problem. ADB devices command lists the device. However, logcat is giving me an error "/sbin/sh: exec: line 1: logcat: not found".

I am running CM10 based ROM on Galaxy Note.
[Android Software Development] hg42:
tannykim probably didn't use logcat.

I assume he copied manually, because mmcblOp* is written with the letter O instead of a zero.

The recovery log is on /cache/recovery.

logcat probably doesn't exist in recovery (which is a mini linux).
[Android Software Development] Alahdal:
Update:

I have flashed the second file (120820-225556-emmc_find_brick_end) and device reboots after 2800 (I don't know exactly at which point).

Then from both files (Start & End), the following is the result:

Start: Reboots after 700

End: Reboots after 2800

The bricked block(s) should be within the 2100.

What should I do now? and How?

PS. I have used the standard 16g PIT file to repartition.
[Android Software Development] hg42:
as I noticed my calculation in a former post was wrong, because the blocks have 512 bytes each.

so 700MB - 2800MB (assuming these numbers are for working blocks).

This is block 1400000 - 5600000 so this would mean this pit should be ok:

N7000_16GB_Q1_20110914-patched-regain-0262144-kB.pit
unused 548864 5414912 = 2707456 kB
11 FACTORYFS 5963776 1744896 = 872448 kB
[Android Software Development] Alahdal:
Sorry, but I want to reconfirm to avoid any further issue. Should I flash attached file? What is next, should I flash a new ROM? Stock? Custom?

EDIT: btw, I have ESF backup before Brick. Will this help?
[Android Software Development] hg42:
hmm, which PIT did you flash first? If it was the standard pit, this is ok.

You could then regain 262144kB with the attached PIT, but I think it's not worth the hassle of reinstalling etc.

I would first make the phone running stable.

What about the freezes? did they occur again?

efs backup probably will not help with freezes (but you never know).
[Android Software Development] Alahdal:
Yes, I flashed the standard one.. I haven't flashed the patched pit yet, I will do this after 30 minutes. Then I will let you know about the freezing.
[Android Software Development] hg42:
as I said, there is no need to repartition now. The patched-standard works. You loose 256MB, but that's not much.

I would first look into stability.

When you want to install your next ROM you may think of changing the pit again.

What I meant were the freezes you reported before. Then you didn't have any for 6 hours.

I am asking if they returned after that post.
[Android Software Development] tannykim:
That was not from the Logcat.

I found it showed me same massage so I wrote that down manually.^^
[Android Software Development] Alahdal:
OK. Got it.

Yes, the freeze and random reboot is back again :(
[Android Software Development] tannykim:
Base on my experience, I think your theory will be most possible with my case. Now I am little used to have freeze, so whenever I have issue with hang and freeze, I keep restarting my phone until it is not freeze. However, I still can not use my phone as normal, so I might have to dig more about your theory. Is there any way I can fix the wear leveler set up same block to use so I can avoid bad blocks?

---------- Post added at 01:49 PM ---------- Previous post was at 01:46 PM ----------

You might have same case as mine.

Whenever I found good spot to put my OS file with new PIT files, I can facing random hang and freeze.

Even thought I check with bad partitions, my now I am believing bad partition is moving on my case.
[Android Software Development] Alahdal:
Is there away to prevent these bad blocks to be accessed for reading nor writing.
[Android Software Development] hg42:
I thought a little more about my theory.

First, I think we should find out, if it really fits the observations.

I am not sure if we can speak of bad blocks in the sense that these are damaged in the physical layer so that they would suddenly occur when assigned to the logical layer.

From what I read, there are arguments against this theory:

* the problem seems to be in the wear leveler assignment algorithm

(so probably not in the physical memory cells)

* it looks like Samsung has an internal procedure, which can repair the damage

(not easy enough for end user, because he needs an JTAG service afterwards)

Perhaps we should do some tests.

All users having the problem should write down how each test runs.

This will also allow us to differentiate different problems.

As a main goal we should try to reproducible trigger a freeze (or shutdown) by simple operations.

This will help to understand what's going on.

When does a freeze occur, when does a shutdown occur.

Any suggestions?
[Android Software Development] Alahdal:
From what I faced, I can see the freeze occurs when an application does writing operation like saving a file. While reboot occurs randomly.

However, with CM10 based ROM "PARANOIDANDROID" in my case, the occurrence of freeze and reboot is very low.

I think this is because the ROM use very limited space comparing to stock ROMs.
[Android Software Development] hg42:
I heard this reason several times, but I don't see how it fits.

At first, ROM size is directly related to system partition usage.

But the space used in system partition shouldn't be a problem, because /system is mounted read only. Nobody writes to this partition.

If the emmc infinite scanner doesn't freeze (reading every block many many times), why should the ROM freeze while reading /system?

Beyond that, the size may also be related to the amount of apps and other code provided by the ROM.

Because the read operation is tested thoroughly by the scanner, the difference should be in write usage of /data and internal sd.

Now, what differences between ROMs come to mind according to this?

* logging: some ROMs continuously write to a log file, some have this disabled

* services: some ROMs have more of them and these may write some data

* apps: which are running and writing frequently?

* any other?

Following that, I think I should create another scanner, that continuously fills writable partitions with files and deletes them afterwards.

If this freezes, hopefully you have a file which covers a bad block. So, if that file isn't deleted, you have bound that block to it and it will not be used again.

Ok...I'll look what I can do...
[Android Software Development] hg42:
@tannykim and others:

Something is still unclear to me:

if your phone randomly shuts down, does it do it suddenly and immediately?

Or may it be a freeze followed by a shutdown after some time?
[Android Software Development] hg42:
emmc-scanner update: signed zips again (hopefully)

I updated the zips, which are hopefully correctly signed now (thanks Mario1968).

Please report...
[Android Software Development] hg42:
emmc_scan_write.zip

added a write scanner to the first post for experiments, please see in the thread starter.
[Android Software Development] Alahdal:
I have just downloaded the write scanner. However, is there any risk of flashing it. :) :(
[Android Software Development] hg42:
If you run the write scanner, I think it's count should run in multiples of the whole flash memory size (e.g. until x*16000MB for a N7000 16GB).

If it freezes -> bingo.

Then after a reboot into recovery, you should have a file named ~emmc~bricked~XXXXXXXX on your internal sd (XXXXXXXX being a number).

Each time the scanner is started it looks for these files and continues with the next count.

So, hopefully, in theory, you will gather all bad blocks (or wear leveler problems in files).

If you don't get a freeze after several multiples of the flash memory size my theory or the algorithm may be wrong.
[Android Software Development] Alahdal:
I have flashed the file, i will report tomorrow with the result... Time to sleep.
[Android Software Development] Mario1968:
Happy to help you:)

Thank you

Mario

Inviato dal mio Galaxy S2 con Tapatalk2®

XWLPF Stock

Siyah 4.1 beta 6

Jkay V14.1
[Android Software Development] Alahdal:
I could not sleep :D. Is it possible to reach this number of MB or there is something wrong. See attached
[Android Software Development] hg42:
I already wrote it in the OP...

It's not related to partition sizes.

It only tells how much MB were written by repeatedly creating new files.
[Android Software Development] tannykim:
I do not know I can help on this but here is what happen on my GN.

I will state "Hang" -> it is actually not freeze and shutting down. It just stop doing anything but whenever I push screen lock button display turn off and when I push the lock button again display turn on but not locked [I know it has little delay to process lock but even I wait for 20-30sec it still not lock] so it freeze. with normal GN operation, when apps or something wrong with ROM and freeze, it automatically restart the APPS or ROM. However in my case it just hang and after while screen locked nothing on the display until I hold power button and restart the phone. It happen sometimes when I restart the phone or when I switch from one app to the other apps, also when I open contact or gallery. It happen usually beginning of start-up process. my solution was just keep restarting until I did not have any freeze on start-up process. Whenever it turn on without freeze some apps does not have previous setting [user date gone]. Also, it works fine until I start install APPS. Now I am using my note in minimum condition [calls / chrome].

I am still searching and studying about this issue.

Also, with my 7yr semiconductor work, program can not create physical damage on chips... so I do not think it is physical damage related issue. I thought Kernel as like ghost for PC, but I think there is something more than this on android device. Anyone have idea on this?
[Android Software Development] hg42:
I simply wanted to know if the shutdowns may be a follow up of a freeze (which is a known random behavior of the emmc brick, that is the flask chip locks up and after some time a watchdog or something restarts the phone).

If the shutdown is in the middle of some activity, it would be something different.

because the freeze happens in the flash memory, all processes not using this memory can continue (e.g. some services e.g. event handlers like for the power button). Processes using the flash memory will wait for the chip, so they freeze.

how long did you wait as a maximum?

If you wait e.g. 5 minutes, does it shutdown?

these seem to be situations with accesses to flash memory

may be because writes of user data were interupted while frozen and shutting down.

This may be the /cache, which is mainly be used while installation (apk file and creating dalvik cache).

That depends. E.g. software can overheat chips together with bad cooling design.

Also many chips contain settings/firmware/etc nowadays.

These may get changed by software, which looks like physical damage to the outer world.

In emmc brick the wear leveler firmware has a bug, which leads to damaged administration structures, which looks like physical damaged blocks (but isn't really).
[Android Software Development] tannykim:
Thank you for the information hg42,

I am not sure how I can find safe spot for my GN to install....

Also, is there any way we can change wear leveler firmware? In your theory, it has bug to made wrong administration structure. Even we had brick, there was no physical damage on the Chip.

BTW for your shut down question.

I did wait more than 30min but I was afraid to have over heat so I force to restart.

Whenever I did freeze and restart process, GN got heat up so when I feel hot on GN I unplug battery to protect GN.

I am going to study more about wear leveler and I will need to find the way to fix.

I am still believe there is nothing we can not fix.

Thank you hg42
[Android Software Development] Mario1968:
Hi tannykim, I've read in S2 thread that the Samsung tech have a tool for program the firmware of the bad emmc chip (0x19), but after that the device need to be jtagged because can't handle a completely empty Emmc (situation came after the new emmc firmware flash), so they decided to not release this tool:(

I hope they find a solution to automate the flash of new firmware on emmc then flash a bootloader that permit the device to enter in download mode, all of this in one power cycle without reboot:thumbup:

Mario

Inviato dal mio Galaxy S2 con Tapatalk2®

XWLPF Stock

Siyah 4.1 beta 6

Jkay V14.1
[Android Software Development] Alahdal:
Today, I had 2 times freeze both during using Camera. for the second one I left the mobile for around 15 minutes, nothing happened. I manually shut down the mobile and for the 1st start after the freeze the mobile froze again at the boot. I had to restart. Then works fine.
[Android Software Development] tannykim:
That is what my GN do too.

I have to use this until GN2 show up.

However, if you do not use smart phone and just using phone [talk only] you will not have many issues

Cheers!!!!:eek:
[Android Software Development] Alahdal:
I am a smartphone addict and I've started losing my temper due to this hangs and freeze. However, I cannot afford a new mobile/model :(.

---------- Post added at 08:12 AM ---------- Previous post was at 08:09 AM ----------

Hi Mario.

Could you share the link for that topic. I have a JTAG box and I am ready for this exercise.
[Android Software Development] Mario1968:
Hi iT iS Me, this is the link of the post I've read about a fix from Samsung:

http://xdaforums.com/showthread.php?p=28416723

hope this help

Mario

Inviato dal mio Galaxy S2 con Tapatalk2®

XWLPF Stock

Siyah 4.1 beta 6

Jkay V14.1
[Android Software Development] Alahdal:
The Questions is: Is it safe to apply this on Galaxy Note.
[Android Software Development] Mario1968:
I think is better to ask directly on that thread.

I've a galaxy S2, not a note, but from what I've read around these devices are pretty similar in hardware specs.

Sorry

Mario

Inviato dal mio Galaxy S2 con Tapatalk2®

XWLPF Stock

Siyah 4.1.1

Jkay V14.1
[Android Software Development] marwanxx:
I'm hoping this 120824-220105-emmc_scan_write.zip could help revive my P6800. I'm unable to flash any ROM via CWM or Odin. But still can flash the CWM Recovery and it works. I'm using this right now. Still can't boot up my P6800. Please....
[Android Software Development] hg42:
Look at the pit thread mentioned in the OP.

I just updated the pit thread with new pits and easier instructions now taking advantage of the emmc scanner to find the brick area and select the correct pit.
[Android Software Development] serpent2005:
Hi hg42, a few months ago I fell victim to the eMMC brick bug. I used your tutorial and PIT files to eventually get my phone working again, but I ended up with about 5 GB of space left on my internal SD. I used your *-emmc_find_brick_start.zip and *-emmc_find_brick_end.zip and pits-N7000_16GB.zip with the instructions in the OP and now I have 9GB of free space. Thank you for all your hard work to help us get the most from our device after we fall victim to the bug. :D:D:good:
[Android Software Development] aletheus:
i've got a p6800 (gTab 7.7 international 3g) and i LOVE it, then this happened... :-/

i've spent two weeks trying to sort out, read, and re-read these instructions and have been slowly but surely making sense of things. i just wanted to let you know per your OP that it does seem like the bug is a moving target... one time i flash the original pit file, run your scanner, the 'bad sector' is in one place (p10 aka /data)--1759-4292, and now it's at 3045-4923.

hg42, could you possibly read through our thread in the gTab forums and talk to androguide.fr about how to streamline our superbrick recovery guide?

its located here: http://xdaforums.com/showthread.php?t=1862294
[Android Software Development] Fear345:
While using emmc_find_brick_start it was scanning fine until it got to block 2082mb then started running slow, it takes about 20 seconds to scan a 1mb block, is this normal ?
[Android Software Development] hg42:
I'm sorry, I have no spare time for reading another thread.

Regarding the moving bad blocks.

I would note all detected brick starts and ends and try to skip them all.

Perhaps you are lucky and the brick stays in a certain range forever.

Please report how it goes on...
[Android Software Development] hg42:
No, that's not normal.

I would assume some emmc problem starts there.

It's possible that it's another weird behavior of the emmc brick.

So I would treat it as bricked block(s).
[Android Software Development] Alahdal:
I have taken my mobile for maintenance 2 days ago and today I collect it.

As far as I remember the total space of internal memory after the brick was around 8GB, I notice the total space is 11.07 after maintenance. Does it mean the mobile is fixed.

Same total space was checked in some other devices.

Thanks.
[Android Software Development] hg42:
The internal sd had 11gb before the brick, indeed...

I would check with all available tools:

- parted: no hole in partition table?

- emmc bug check app

- emmc scanner

- dd if=/dev/block/mmcblk0 of=/dev/null
[Android Software Development] Fear345:
I cant get my head around which pit file i need, my bad blocks starts at 2179mb and ends at 6411mb which pit file do i need ?
[Android Software Development] hg42:
In other words you need a file named *-brick-between-HOLE_START-and-HOLE_END-* with

HOLE_START < BRICK_START and

HOLE_END > BRICK_END

so that the hole completely covers the brick area.

here you have BRICKSTART = 2179mb and BRICK_END = 6411mb

any file with the first number less than 2179 and second number greater than 6411 should do.
[Android Software Development] Daruka:
I am running RocketRom v11 with Hydracore 4.3 kernel.

Everything works fine NOW, but when I went from GB to ICS ROM, I had lots of problems.

Then I used 'Triangle Away'' to get rid of triangle but now when I boot phone I have a small green line that says ''logo_jpg draw failed'' and then it goes into the normal boot.

My phone is rooted and all programs work well with the root including Root Explorer.

I am a bit confused on the ''internal and external storage '' thing

When I go into recovery and flash a ROM or zip file my choices are ''choose zip from SD card'' or ''chose zip from internal SD card''

In my case, when I choose ZIP from SD card it goes to my EXTERNAL CARD. When I choose ZIP from Internal card , it reads my INTERNAL SD CARD.

Can your app scan with these settings? I notice that kernels like Speedmod changes these things around.
[Android Software Development] chleoj:
@hg42

Is this intended for Samsung device only or for every android OS device? I've got bricked HTC MyTouch4G which they called having the bad emmc plague,

could this tool would help reviving my device....if yes, then how? Can you guide me please..thanks.
[Android Software Development] JFizDaWiz:
now my phone is bricked (from the ICS bug I'm assuming) to the point where the phone doesn't even turn on or vibrate when holding in the power button, I'm assuming it's safe to say that this will not fix that problem and it's completely dead, right? no where near home to test this.
[Android Software Development] hg42:
your sentence is a bit confusing, too :)

I think you mean sd = really external and *external* sd = really internal?

And yes, that happend to me, too. I also mention this in my PIT thread.

The reason is that the recovery has to be configured to the same int/ext assignment like the ROM itself.

Some ROM devs seem to have exchanged the assignment but didn't also exchange it for the recovery.

And cm9 chose to have a system setting for that, so it's dependent on the user, but the recovery doesn't have such a setting.

Btw. TWRP recovery also has a setting to switch this.

My scanner will work on the internal flash memory. It uses information from /proc and /sys to find out which device is the emmc.

This is independent from those difficulties.
[Android Software Development] hg42:
the tool is initially intended for only a few Samsung devices.

I only test it on my Samsung Galaxy Note N7000.

Apart from that, it will probably work on other devices.

But it depends on the block device tree etc.

Trying the read scanners should be harmless. The worst thing wo0uld be it cannot find the block device or the partitions.

The write scanner is for special purposes only, so you will not use it anyways.

You could first check with an app called emmc brickbug check. From what I read, it's intended for Samsung, I would assume it has a different algorithm to find the emmc device, may be it is simply a fixed device name (usually /dev/block/mmcblk0).

My scanners use information from /proc and /sys to find the emmc device. So you may have more luck with these.

The algorithm is generally intended for any android device, but because there are so many different approaches how to arrange the emmc in the block device tree, it's still only a guess. I personally know only my own Samsung device, so all others are pure theory derived from logical thinking.

So, just try it...it will not harm...
[Android Software Development] hg42:
the scanner is only a tool to find out *where* the brick is located (start+end).

You can use the emmc brickbug check app (see link in previous post) to determine if you really have the emmc brick.

EDIT: sorry, you can*not* if your phone doesn't start...

Or you directly use my "find brick" scanners, which do essentially the same, but a lot faster (but to be really sure, the app will be better).

My PIT thread linked at the beginning of the OP (and currently in my signature) should/may help you if you have got the brick.

But note, it's not a repair, it's only a workaround, just read the thread for more info.

Btw. if your phone doesn't get into recovery, it may be another kind of brick, or you have two kinds of bricks at the same time.

Try things like removing battery for >10 sec, Vol-Up + Home + Power until it reaches recovery etc.

There are other threads for this...
[Android Software Development] Daruka:
I installed the brick bug check app from the Market.

I downloaded this app to check that I have eemc bug or not.its showing that brick bug? Yes insane chip. Does it mean i have emmc bug on my note?