yashsingh1/xdaforums huggingface dataset:
[Galaxy S III General] danarama:
Thats a good point raised there about the source. Its not a good thing if anyone on stock had SDS though so.....I think I will add a poll for stock users who had SDS just to see if anyone got SDS on those kernels as stock.

https://dl.dropbox.com/u/20471345/SUroot/SGS3/ELLC_boot.img

ELLC if anyone wants it.
[Galaxy S III General] glaudrem:
Not very sure, but I suposse ELL4 is the unbranded UK phone and ELLA may be Unbranded Germany phone. I cannot find official firmware list post but I remember having read something like that.

Anyway, many thanks to you and Rob for all your hard work. Lot of users, including me, are actually more relieved and understand this f*****g issue better now.
[Galaxy S III General] Rob2222:
Checked. XXELLC kernel also contains the strings. So we can assume it also contains the fix already.

BR

Rob
[Galaxy S III General] danarama:
UK went from ELL4 to ELLA
[Galaxy S III General] suspktu:
LL1 fix check

hello Rob2222. Can u please check if the LL1 kernel has the fix? I attached it below. Thanks
[Galaxy S III General] thekoRngear:
Someone who is with the affected emmc chip and accessed the emmc with lots of flash with staying most of the time with the custom stuffs and passed over 4/5 months. In this case, I guess, it now cannot guarantee 100% for sure?
[Galaxy S III General] Rob2222:
Done. Already contains it.

VTU00M <4>%s: movi operation is failed

Checked kernels so far:

XXELL1/XXELL4/XXELL5/XXELL6/XXELLC and XXELLA

BR

Rob
[Galaxy S III General] Z3US911:
oho plz don't count my vote i did it by chance :x :(
[Galaxy S III General] danarama:
I'm wondering now what update 7 actually is. All 4.1.2?

4.1.1 source has been used for a while already anyway...

Interested to see how far back this goes. ELKC?
[Galaxy S III General] MIKEMON:
Yes, it is very interesting??
[Galaxy S III General] bobmatu:
sorry in I9300XXELLB there isn't the fix????
[Galaxy S III General] Rob2222:
XXELLB I didn't checked yet.

If you have a download link to the kernel only or if you can attach it to a post, I can check it.

But I would bet, it has the fix already in like the other XXELL* kernels.

BR

Rob
[Galaxy S III General] linezero:
the revolt rom nightly has the SDS fixed kernel now :D
[Galaxy S III General] vostikan:
where confirmations that ELL4 ELL5 are safe? ? whether means it that ELL6 - official firmware is also safe?
[Galaxy S III General] Rob2222:
Maybe read the 10 posts above you question....

http://xdaforums.com/showthread.php?p=36586668#post36586668

BR

Rob
[Galaxy S III General] danarama:
Hi everyone, thanks for all your updates on things like this...

Please can you call include:

Link to thread

Version that includes fix
[Galaxy S III General] danarama:
Rob, please can you tell me how you're grepping the string? Ie what tools you're using and what format / file you're working with.

I have abootimg to extract the zImage but not sure where I'm going next as I don't really touch kernels.

Ubuntu 12.10
[Galaxy S III General] Artiphyst:
Can you check as well this one please.

https://www.dropbox.com/s/ubh29jpgxj31njf/I9300XXELL6_boot.img
[Galaxy S III General] betovanbuuren:
Link:http://xdaforums.com/showthread.php?t=2080039

Nightly version with SDS fix : ReVolt JB Nightly 20130111
[Galaxy S III General] Oranav:
A few insights about the alleged fix:

- As far as I know, only 16GB models have died. This seems to be an indication that it is indeed a problem with the eMMC chip.

- According to the moviNAND specs, they issue a vendor-specific MMC command to enter debug mode, then they patch its RAM.

- They write "10 B5 03 4A 90 47 00 28 00 D1 FE E7 10 BD 00 00 73 9D 05 00" to 0x40300; they also write "E3 F7 89 FD" to 0x5C7EA.

As soon as I saw this "10 B5", I suspected this is THUMB code (looks like a common PUSH) -- and I was right:

ROM:00040300 PUSH {R4,LR}
ROM:00040302 LDR R2, =0x59D73
ROM:00040304 BLX R2
ROM:00040306 CMP R0, #0
ROM:00040308 BNE locret_4030C
ROM:0004030A
ROM:0004030A loc_4030A ; CODE XREF: ROM:loc_4030Aj
ROM:0004030A B loc_4030A
ROM:0004030C ; ---------------------------------------------------------------------------
ROM:0004030C
ROM:0004030C locret_4030C ; CODE XREF: ROM:00040308j
ROM:0004030C POP {R4,PC}
ROM:0004030C ; ---------------------------------------------------------------------

They call the (THUMB) function at 0x59D73. If it returns 0, they halt. (Hey Samsung, shouldn't we avoid sudden deaths?)

My guess is that this function used to do the opposite before: halt if the value isn't 0 - hence the bug.

Also, the code at 0x5C7EA calls our function:

ROM:0005C7EA BL 0x40300

Maybe it used to call another (buggy) function before?

Anyway, it would be really nice to dump its RAM and see exactly what has changed.

I've found some code to read the moviNAND RAM; will do this later.

* I wanted to post this in the developer discussion forum. Apparently, I don't have permissions :(
[Galaxy S III General] mjb:
As has been said MANY times already, Charging has nothing to do with SDS. It's common for it to happen during charging because it holds a wakelock, and your phone can be active while charging (so, in essence, it's busier while charging than when you're using it).

This is what I've been telling you - the fix has been present for some time, so we don't actually know if either:

1) It doesn't actually fix SDS, as it's not targeted at fixing SDS

2) It is targeted at SDS, but it's broken.

Given 2), as we don't have the exact source for stock kernels, we don't know if any changes have been made, and if the code in Update7 is an improvement that *DOES* actually fix SDS.

So, completely unknown, and it may be that we're all panicking about getting a fix onto our devices that's going to do nothing, and we'll get SDS anyway.

The oldest Kernel I have checked is LJ5, which doesn't have the fix.

So closing the window between LJ5 and LL4 would be wise - and I see that has started.

1) Use split_bootimg.pl (google) to extract the kernel from the image (the rest is initramfs).

2) Use a hex editor to remove everything up to the gzip header (0x1f, 0x8b)

3) zcat the resulting file - this is the decompressed kernel.

4) run strings on the kernel, grep for interesting things.
[Galaxy S III General] :
10 questions:

8 = is my phone safe?/check this

2 = useful info.

Please read OP and you will be able to answer those 8 questions, and might even contribute with 2 useful posts.
[Galaxy S III General] gchindi:
Here is a situation n i need someone to clarify please...

I bought sgs3 around may 2012 (1 month after release in the UK), i bought it from a common friend, when i got it, it was locked to orange uk, i got it unlocked after buying unlock codes from a online retailer...after this i started using it on O2 sim without any issues, i have flashed quite a few roms via odin n have rooted n have played with the benefits of rooting the phone..

My question is, if i face SDS, can i claim warranty with Samsung? At the moment im using ELLA UK rom, full stock, recognisable on KIES for future updates.. :)

Pls throw some light on this situation if any unexpected sds strikes my sgs3..

TIA..
[Galaxy S III General] T0xic4u:
What happens if your S3 dies??

1. Full dead

2. Half dead, only download Mode accessable

Do you think they are able to see that you removed SIM-Lock if your S3 isn't able to Boot anymore?

Taper di Tap with my S3 @179 days
[Galaxy S III General] rlorange:
I think it's fair to say that the Sudden Death is very much a probability/random thing.

It's probably NOT something that happens inevitably given enough time rather every time a vulnerable operation is performed there is a small risk that the corruption will occur on affected chips.

We may never know what this probability is or even if certain unmarked batches are more likely or not. But the evidence points to this being random with a probability associated with it.

It doesn't seem like there is an expiry time or some sort of wear leading to an inevitable failure. It may seem this way because SD has suddenly started for many devices at the same time but this is explained by probability of random failure if affected devices all have a similar risk probability and all begin their life pretty much at the same time.

If the problem really was inevitable and result of some hidden cumulative damage (wear) then no mere software patch is likely to save chips "on the brink"

Presumably if your emmc hasn't died you are lucky. and Samsungs "magic" code simply avoids whatever operations are the risky ones hard-coded into the chip firmware.

Unfortunately if emmcs keep failing post-patch we will probably never know if those chips really did sustain some kind of cumulative damage pre-patch dooming them to failure OR if Samsung's patch simply didn't work.

Time will tell... remember a couple of post-patch SD's on patched firmware doesn't validate either scenario for the obvious reason that once a sudden death occurs how can we find out what caused it? Presumably there are many other ways an SD could happen?

If post-patch SD's start happening in numbers then we can all start FREAKING OUT again ;)
[Galaxy S III General] Rob2222:
-open boot.img in hex editor

-search for first occurance of hex string 1f8b (gzip header) around address 0x4000-0x5000

-delete everything from address 0 until before 1f8b (so that the file begins with 1f8b)

-search for hex string 001f8b (should be in the last 20% of the file)

-let the 00 stay and delete everything from this 1f8b including 1f8b to the end of the file

-save the rest as kernel.gz

-unzip the file with 7zip

Thats it. Now you can open it with a hex viewer and make a string (text) search for VTU00M.

@ORANAV:

Which tool youre using for decompiling?

BR

Rob
[Galaxy S III General] mjb:
If it was a random/probability thing as you suggest, then failures would be seen infrequently from day one, at a fairly steady pace.

Since failures are coming thick and fast now, it's more likely to be a bug in the wear leveller as described by Entropy512. This would mean that your last statement is quite incorrect - and that a 'mere' software patch will save chips "on the brink".
[Galaxy S III General] danarama:
Bit unsure by 2. Is that a range?

Not having much luck with this. Surely 7zip doesn't do anything special that Archive Manager cant do on Ubuntu... So I assume I'm doing something wrong with the headers as it errors when I try to extract the kernel from kernel.gz
[Galaxy S III General] mjb:
yeah - from byte 0 up to (but not including) the gzip header of the resulting boot.img-kernel file generated by split-bootimg.pl. You can just edit boot.img directly as explained by Rob if you wish.

Basically the boot.img file is a combination of a compressed kernel and an initrd (also compressed) that is decompressed on the fly as it's booted. What we're removing from the start of the kernel image is the decompression code that's run directly on the device. (basically an embedded gzip decompression tool, that puts the decompressed data into RAM and executes it).

The idea is that you are extracting the section of boot.img that is the compressed kernel. we're doing this by finding the gzip headers for the kernel, and the initrd, and removing the bits before and after, respectively.

You need to end up with:

0xf1 0x8b .................................. 0x00

You can find that 0x00 by looking for the gzip header of the initrd immediately following (so it would be: 0x00 0xf1 0x8b)

Once you have the result, rename to kernel.gz , and in a shell, execute "gunzip kernel.gz".
[Galaxy S III General] Oranav:
This is not decompiling (binary -> pseudo-code), this is disassembling (binary -> assembly).

I'm using IDA Pro.
[Galaxy S III General] danarama:
Thanks very much, its this bit that made all the difference. I tried zcat which I believe is gunzip -c but no dice.

dan@dan-Latitude-E6410:~/Documents/Boot$ grep -i -a "VTU00M" ELKC_kernel
VTU00M<4>%s: movi operation is failed
[Galaxy S III General] Scarface1991:
I would be very interested in the reports of the people who voted that they had a SD on XXELLA. So far I have read only one report where a S3 died while having installed a Custom ROM that is based on XXELLA (UltimaROM 8.1.1). Of course the most interesting thing is what Kernel he was using in combination with that ROM. I already asked him that in the Ultimate SD Thread, let`s see what he has to say. Here is his Story:

Edit: Now in the text he also says that Odin showed a response to his phone. If you have a SD Odin shouldn`t be recognizing your phone or am I wrong here?
[Galaxy S III General] danarama:
I never tried to connect via odin when I had the SDS issue. Even the LED failed to work on AC though....

1 person did say they answered by accident however.

No one has posted anything about their poll answers though so those results as they are are pretty useless
[Galaxy S III General] Spitspit:
Yes I'm covered. Ty :cool:

Envoyé depuis mon GT-I9300 avec Tapatalk
[Galaxy S III General] Scarface1991:
I`m gonna try to find out more about the story I posted above. I just hope that he was using Siyah or some other Kernel without the fix. Or maybe it wasn`t a SD at all but some other failure, we will see...

However if he was using a Stock XXELLA Kernel and it was a SD then this is pretty alarming.
[Galaxy S III General] danarama:
Any official 4.1.2 build SDS will take the wind out of everyone's sail I think
[Galaxy S III General] migz012788:
alright. just to clarify everything. this is how it goes. im on full stock ELLA rom from OTA. so there is a fix on its stock kernel, and stock recovery right?? because i want to be on full stock as possible..
[Galaxy S III General] s_o_r_e_n:
Ehhh the same question on and on...In first post U have the answer for Ur question. The answer is also on every other page in this thread. Both The stock recovery and kernel from ELLA have the fix.

Wysyłane z mojego GT-I9300 za pomocą Tapatalk 2
[Galaxy S III General] Rob2222:
Why that? There were older JB builds that doesn't contain the fix.

Sourcecode Update 5 and 6 were Jelly Bean and didn't have the fix.

BR

Rob
[Galaxy S III General] danarama:
Don't forget 4.1.1 is JB too. I'm talking about 4.1.2

4.1.2's first release was Poland, XXELKC, which came back positive for the string you've been using to identify the "fix".
[Galaxy S III General] jin1992:
oh my which means i flash custom kernels and recoveries for nuthing if xxelkc contained the fix already.

if so what all this hype about ella build being the one to fix sds?
[Galaxy S III General] danarama:
I guess because:

1: ELLA came out as a quick update with no new features so most likely security patches and bug fixes

2: The update 7 sources were shortly released after ELLA...

I don't know for a fact why ELLA was thought initially to have the fixes but that's where it all started in the Perseus thread and here we are today :)
[Galaxy S III General] rlorange:
Yes you are Absolutely right. Statistics I embarassingly muddled up completely! So the exact opposite conclusion of my post.

There is some kind of wear going on if it WAS random then we would have seen a steady trickle depending on probability... thanks for the correction my reasoning was sound but I got muddled to the conclusion. That's my dislexia coming out.
[Galaxy S III General] migz012788:
so there is no update 7 fix on ELLA?
[Galaxy S III General] SYRK.CORP:
Sotmax's rom include a fixed kernel (yank kernel) too
[Galaxy S III General] :
Does anybody know when a patched CWM recovery will be released? :confused:
[Galaxy S III General] SYRK.CORP:
http://xdaforums.com/showthread.php?t=2002953
[Galaxy S III General] :
Official CWM...
[Galaxy S III General] sam77744:
means stock recovery?
[Galaxy S III General] danarama:
Yes, all 4.1.2 kernels seem to have the fix in.
[Galaxy S III General] quebec1:
j installe emmc brick check, i launch it, and after j must launch brick bug, for see my chip?

sorry for my english
[Galaxy S III General] migz012788:
Yes!! Hehe. Because i want to stay stock. :)
[Galaxy S III General] brouwerchris:
For everybody on full stock XXELLA rooted through CF-Auto-Root XXELLA stock recovery is replaced by stock recovery installed by CF-Auto-Root.

After CF-Auto-Root I flashed XXELLA stock recovery through Mobile Odin Pro.Where to check if XXELLA stock recovery has been installed. In cache>recovery>last-log ? And how to identify?
[Galaxy S III General] rockuan:
Hello i downloaded the app eMMC check and i have "VTU00M 0XF1" (im wrong or that is the affected one?) and the app says: brick bug? No, safe chip.

So my phone is from the first waves of stock, 16 gb and VTU00M 0XF1 but im not affected? is the app right?
[Galaxy S III General] Fearxpc:
From the 1. post:

How do I check my eMMC?

Using the EMMC check app from play, you can see if your eMMC is the VTU00M 0XF1 (affected chip).

Please note:

1) this app is for the S2. Use it ONLY to check the version.

2) nothing you see in this app will change once you apply a fix. It simply gives you the version. If you expect 0xf1 to change to something else, you are mistaken. Only replacing the motherboard will do that.

It means you are affected cause of VTU00M and 0XF1. That's the important info from the app!
[Galaxy S III General] pickandwhammy:
Have quoted this thread for more information on this compilation thread.
[Galaxy S III General] louie875:
Hi I just wanted to know how this SDS occurs, as over the past 3 days or so my phones keeps freezing. As in no matter what buttons i push or if i try to lock the device nothing happens, ive had 3 android phones and i have never seen it completely lock up like that. Last night it did it 3 times within about 15 minutes. Does this sound like my phone is on its way out ?
[Galaxy S III General] danarama:
I dont really know enough about the "data corruption" to be able to tell you what the symptoms are. All I'll say is it could be.

What are the details of your phone? It may be its something else.

ROM?

Rooted?

Kernel?

Chip?
[Galaxy S III General] danarama:
Boot into recovery (from off hold Vol UP + Home then press power). It will be obvious if you have CWM or not.

Thanks for this. I'm not sure what to do with this though. The ROMs section is really only for ROMs that have their own dedicated kernel that cannot be flashed separately...

Let me think about this one.
[Galaxy S III General] louie875:
Stock Rom XELLA

Not currently rooted (has been rooted)

Kernel: 3.0.31-742798

Chip is VTU00M

FwRev: 0xf1
[Galaxy S III General] nhariamine:
Do what the OP said to do to prevent SDS, because ur witnessing the last symptoms of SDS and u should immediatly update ur kernel and recovery.
[Galaxy S III General] danarama:
If its running the original kernel still, you have the fixes already.

If you're experiencing lock ups, there are quite a few other things you can try. As that's off topic though, maybe create a new thread in the q&a section seeking advice.

Of course if it is sds, please do let me know
[Galaxy S III General] zadusimple:
Now that XELLC has been released , i would really aprreciate if the OP can update the 1st post with the answers to the below questions:

1. Does XELLC Rom or kernel contain the fix too? If yes, has anything changed.

2. If we update to XELLC ROM , Can we still keep on using the perseus kernel b4? (which contains fix from XELLA)

3. Is there any difference between the bootloaders of XELLC and XELLA roms? (i know boot loader is irrelevant for SDS)

Please advise.

Regards

ZADU
[Galaxy S III General] T0xic4u:
XELLC Kernel was/is on this list for many hours. And why shouldn't work Perseus with it???

Taper di Tap with my S3 @180 days
[Galaxy S III General] Oranav:
I did a little reversing of XXELLA's bootloader (sboot.bin). I didn't found any trace of eMMC firmware patching;

This is a bit strange, since the bootloader does have its own machinery for handling eMMC writes (e.g. download mode or T32 fuse to download from SD card to eMMC).

Note that there could be a patch which I somehow missed.

If someone BinDiff'ed the new bootloader and the previous one we could see exactly what has been changed...
[Galaxy S III General] kmilof:
soy maybe is safe to asume that we could downgrade the bootloader to another one (ics one?), to prevent the red exclamation mark.

and another question to anyone who may anwser, in which scenarios the "Death" may come? xD, i really dont get that.

:good:
[Galaxy S III General] thegh0sts:
most cases seem to be when the phone is charging with the screen on standby and it's unable to wake from standby.
[Galaxy S III General] danarama:
Yes, at which point might I add that the bootloader is doing nothing.

If anyone is interested, I'm using ALE6 bootloader
[Galaxy S III General] thegh0sts:
i've gone back to the XXBLFB bootloader cos that's the baseband it came with.
[Galaxy S III General] kmilof:
So, it may be recommended to not charge the phone while is powered on? only powered off :D

:cyclops:
[Galaxy S III General] danarama:
No, I'm not going to recommend people change their habits. If it breaks it breaks. If you want to update to something with a fix, do so. But don't be so over protective that the phone dictates your usage and habits. Its supposed to be a tool not a hindrance ;)
[Galaxy S III General] Oranav:
Well, if there really isn't a patch in the latest bootloader (which we don't know yet for sure!), the only thing we can assume is that all bootloaders are dangerous and that we shouldn't use download mode at all.

While it may be true, if it really is a NAND problem, it's probably because:

A. The device spends a lot of time in this state (charging with screen on standby), so it's more likely to happen there;

B. It's on standby, and to wake up it tries to resume the NAND chip. The resume procedure fails, and the device can't continue to function.

So it really doesn't have anything to do with charging the phone. :)
[Galaxy S III General] pickandwhammy:
What has download mode got to do with nosy bootloaders?
[Galaxy S III General] kmilof:
Damn the bootloaders :eek:!

'till now im "safe", ill stay that way 'till more info appears.

Thanks for all your work guys :D love xda community
[Galaxy S III General] danarama:
No worries.

From what I read, the stock recovery with the official XXELLA hasn't been updated... If anyone can confirm this please?
[Galaxy S III General] hamer221:
I got omega v16 and stock ELLA kernel. But emmc check says that i got rev fw 0xf1. So am I still afected?
[Galaxy S III General] danarama:
If you're running a stock / repackaged ELLA Kernel, we believe you should be safe.
[Galaxy S III General] Karl978:
Great thread! Without panic, but only what we know so far.
[Galaxy S III General] vasilisf7:
I have flashed the philz recovery 4.0 and perseus newest kernel do I have to flash the new bootloader to so I am safe?

☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆

.GT I9300 ON STEROIDS!!!

.OMEGA ROM V36

.STOCK KERNEL

.MOTOMOtO00 THEME

.RAUB'S & VEGETA'S MODS
[Galaxy S III General] thekoRngear:
Nah. You already did what you would have to.
[Galaxy S III General] rafa6571:
Ok, so I'm in Stock 4.1.1 and I flash this morning perseus newest kernel. Do i have to flash the ELLA room or am I safe just with the kernel?
[Galaxy S III General] danarama:
Unless we find evidence that suggests the bootloader is involved, id recommend avoiding the latest sboot if possible
[Galaxy S III General] danarama:
Just kernel
[Galaxy S III General] Phil3759:
I can confirm both recovery.img and boot.img have same kernel after a binary comparison. I verified before repacking and releasing my recovery
[Galaxy S III General] danarama:
Oh interesting. In that case, the new sboot IS recommended?
[Galaxy S III General] :
Seems patch only makes the system try to repeat read/write operations until they succeed. Is this correct?
[Galaxy S III General] wooptarik:
(Deleted)
[Galaxy S III General] Phil3759:
That it seems no one has any idea...
[Galaxy S III General] mjb:
What's your reasoning for saying that?

---------- Post added at 10:10 AM ---------- Previous post was at 10:07 AM ----------

No. It makes small changes to the firmware when the eMMC is initialised at power on and resume. Nothing more.