yashsingh1/xdaforums huggingface dataset:
[General Omni Discussion] Entropy512:
what the ****?

None of this makes sense, those variables shouldn't be getting clobbered unless we have a compiler bug...
[General Omni Discussion] FrodgE:
Yep formatted both. Personally I haven't had any problems but other users have experienced some issues. I don't understand how changing the underlying file system could have any impact on applications as the storage method should be handled by the OS and be transparent to the app. It's not like we're talking about symlinks or anything fancy like that.
[General Omni Discussion] UtkarshGupta:
Not tested - http://xdaforums.com/showthread.php?t=2684188

It is meant to restore full access to sdcard. Maybe it fixes the issues you guys are having.
[General Omni Discussion] bassmanitram:
Reformat your cards to exFAT - basically "fixes" the problem (fix in quotes because it DOESN'T fix the root cause, and as no-one can explain WHY it "fixes" the problem anyway, other than introducing different timings to those of FAT file systems, it can't be considered a bona fide fix, only a statistically encouraging workaround - but I haven't had a freeze in two weeks with exFat, either for music-listening or for file copies)

---------- Post added at 03:13 PM ---------- Previous post was at 03:07 PM ----------

SMDK4210s are relatively antique - so a special case? :)
[General Omni Discussion] AA1973:
No. Unfortunately, it doesn't fix it.

I did look up platform.xml upfront and it was already set.
[General Omni Discussion] cgx:
Yeah... But what makes it so weird is the random and relatively rare occurrence.

I'm starting to wonder if it all is really related to the original dmesg correlation way back:

http://xdaforums.com/showpost.php?p=50135593&postcount=28

Interrupt happening during the pread64 syscall could mess up the two variables if they are stored in registers for example and the interrupt handler did not restore everything correctly. Also the corrupted variables are both 64 bits, maybe they are somehow different from the other variables...

This would also somehow explain why this mostly seems to happen when screen is off. The link_pm_irq_handler seems to be doing something related to pm_wakeup and if the device is already awake, maybe the function behaves differently.
[General Omni Discussion] Entropy512:
Although the above results indicate that patch isn't it...

I'm wondering if this is somehow related to an ancient kernel compiled with newer GCC...

https://gerrit.omnirom.org/#/c/5307/ primarily focused on updating fuse and anything that "came with" fuse updates.

Maybe it's fs/read_write.c - although the only change to pread64() is updates to the macros...

This is really making no sense... Something is really horribly wrong, I don't think it's specific to Exynos4 itself unless we have some unhandled cache or CPU errata...
[General Omni Discussion] bleggy:
is it necessary to format internal to exfat? I'd rather just the ext sd card, since thats where I keep 100% of my music.
[General Omni Discussion] cgx:
Please read my above post first if you missed it.

http://xdaforums.com/showpost.php?p=51261947&postcount=265

Anyway, tried again combining the kmsg log to the fuse trace log with more debugging. Unfortunately at least the link_pm_irq_handler prints do not seem to occur simultaneously with the failure. Still maybe something similar with other interrupts could happen, just nothing is outputted to kernel log at this point.

Not entirely sure about the log timing though, it was made by piping kmsg and strace to a fifo and then the fifo output to log file. Maybe there is some buffering happening somewhere
[General Omni Discussion] NaminatoR1254jaime.sier:
Has somebody tested the -bind commands suggested by [MENTION=3590131]bassmanitram[/MENTION] ?
[General Omni Discussion] Tann San:
No, I just did my external and it works fine.
[General Omni Discussion] Red_Vex:
The commit of today in cm11 is somehow related? I'm referring to s2 Mount unmount sd card
[General Omni Discussion] Entropy512:
no, we already have that commit and have had it for a while, it is not related
[General Omni Discussion] Entropy512:
hmm... Samsung's modem drivers tend to be the most likely to fail with newer GCC variants - maybe we have something that's not quite 4.7-ready. And yeah you're right that the corrupted variables are both 64 bits which is interesting - the one 32-bit variable there always seems to survive. Would be interesting to see if building the kernel with 4.6 changes things or maybe there's a cache handling errata we're missing in the "unified" kernel that was in the old Samsung 4210 kernel...
[General Omni Discussion] cookiepuppy:
Hi guys, I have galaxy s2, I'm using a KK rom built by [MENTION=1372722]victorator[/MENTION], aokp based , in this rom I had no music bug issue at all.

I think he used mix of files from CM and AOKP cause there was no official KK version by aokp for galaxy s2

Maybe you guys can find the differences .
[General Omni Discussion] rocholaroca:
ART or Dalvik

Are you using ART or Dalvik?
[General Omni Discussion] cookiepuppy:
Dalvik, and I used gustavo kernel 22.2.14 build, but today I'm testing music with stock kernel.
[General Omni Discussion] D4rK.F0rcE:
I would be happy to test this kernel, in case somebody builds one.
[General Omni Discussion] Entropy512:
Completely irrelevant here. This is a really low-level issue.

I will look into attempting a kernel with GCC 4.6 later this week.
[General Omni Discussion] bleggy:
well, running an exfat external sd card is working perfectly. no noticeable problems.
[General Omni Discussion] UtkarshGupta:
Anyone tried this - http://www.xda-developers.com/android/fix-external-storage-handling-with-xposed-module/ ? I keep music in internal storage so obviously can't
[General Omni Discussion] AA1973:
Will try that. A question about Google Play Music.internal

On my Tablet Galaxy Tab2 p5100 GSM, I am able to choose storage location between internal and external SD.

On the Note N7000 this option does not even exist.

On the Note, it looks like this.

Apparently, Google Play Music doesn't recognize any SD card.

Attached are the screens of the tablet where I can choose the storage location ("Speicherort")
[General Omni Discussion] NaminatoR1254jaime.sier:
AFAIK, its the same commit that was merged way back for Kitkat roms that allows access to ext sd card. Nevertheless, Im going to try kitkat again for the 1st time in two weeks so Im gonna make use of that to test the module.
[General Omni Discussion] AA1973:
Not necessary. What it does, is nothing else than adding media_rw to WRITE_MEDIA_STORAGE, which is already in platform.xml
[General Omni Discussion] Azeazezar:
Here is a thought:

Do we use the fuse for accessing an ext4 partition?

After formatting the external SD ext4 my problems with the music player seem (no crashes this past week) to have stopped.

If anyone can confirm the same results, i will do the same to my internal SD and ignore this bug for now.
[General Omni Discussion] elitewarrior:
Not to sound rude or anything but have you read even a single page apart from the first one?
[General Omni Discussion] Azeazezar:
Actually, yes.

Page 28 and 29

After that i wrongly concluded This was the level of progress. Glad i was wrong.

Thanks for making me look a little harder.

Well, considering people have good results with exFAT, I am assuming that ext4 works just as well.
[General Omni Discussion] bleggy:
I'd rather use ext4, personally, rather than exfat. try a full ext4 setup & get back to us.
[General Omni Discussion] Azeazezar:
It is done. First impression: all seems good.

Second impression: It is read-only for whatever reason.

exfat for now.
[General Omni Discussion] SomeFormOFhuman:
Hey guys, I flashed Markox89's CM11 and I've decided to take the test plunge with my 64GB class 10 card formatted as ExFat and running for a week now - and every night I ran PowerAMP throughout the night for 8 hours to test it thoroughly. And the next thing I know it, the music is still playing. I have also deleted and transferred large movie files and the operations have been fantastic. I can say formatting to ExFat seems to have "solved" the music bug as a workaround. I initially thought it would only work for 32GB cards as I once formatted my 64GB SDXC card as ExFat and my phone won't read it unless if I format it to FAT32. But as of now, it works as I'm inclined to think CM has implemented native ExFat into their code.

So yes, to all who use 64GB cards on their S II, just saying you can rest easy with ExFat, because we all know to make a 64GB card work in our phones you'll need to format it as FAT32, and 64GB cards aren't technically "supported" according to Samsung. Just make sure you get a ROM that has native ExFat support.

Anyway though I'm pretty sure someday someone will unmask the real root cause behind it; I'd like to know it as well. :good:
[General Omni Discussion] elitewarrior:
Someone correct me if I am wrong but I will attempt to summarize the contents of the thread..

---------------------------

First I want to say that the problem being discussed in this thread is NOT the permission based problems that are being brought up since the the KitKat release. All of that stuff pertains to stock firmware and custom ROMs derived from AOSP do NOT have this issue. These ROMs have tweaked permissions that pretty much means that the changes in KitKat aren't a problem (as far as permissions are concerned). If you have problems with apps being able to access your SD card then this is what you have and this thread isn't for you.

---------------------------

So here is whats going on in this thread. Performing read/write operating on an SD card or external SD card on the Exynos 4210 family of devices will result in what ever app started the operation to hang until the phone is rebooted. This is especially evident in music players. A side effect of this is massive battery drain.

From what Entropy512 and cgx have been able to figure out so far, the root of this problem seems to be from a low level interrupt which messes up some key variables. This means it can't be fixed by some 3rd party app or modifying an XML file. It might be fixed by building the kernel with an older compiler but we don't know so far.

While the problem can't be solved yet, there are 2 alternatives to avoid this bug. The first is to downgrade to 4.3 which is actually quite stable and working perfectly fine. The second is to reformat the SD card partitions to exFat. So far there have been no reported problems of our devices and exFat partitions.

---------------------------

I might have fudged up some of the technical details but the key take away points are there :P.

---------------------------

Edit: Apparently converting your SD card partitions to exFat introduces some new issues, mainly with restoring (and I would assume creating) nandroid backups and maybe a problem with certain GPS apps (I am not too sure about this..).
[General Omni Discussion] Red_Vex:
Tnx...
[General Omni Discussion] j1gga84:
Has this:

http://www.xda-developers.com/android/fix-external-storage-handling-with-xposed-module/

something to do with "our" problem?

regards
[General Omni Discussion] razkal1:
Nope im pretty sure that's just for permissions

Sent from whereever iam...
[General Omni Discussion] D4rK.F0rcE:
Did you, by any chance, forgot to push out the kernel? :P
[General Omni Discussion] Azeazezar:
[MENTION=3532399]Red_Vex[/MENTION]

No. However using it for your internal SD messes up something. It will become read only.
[General Omni Discussion] Red_Vex:
Maybe if we got A LOT of luck the upcoming 4.4.3 version may resolve the issue.:eek:
[General Omni Discussion] NaminatoR1254jaime.sier:
& [MENTION=4478126]elitewarrior[/MENTION]

Discussed a few pages back, ExFat brings in issues from other stuff (a GPS app and restoring a nandroid in recovery the latter which IMO is more important than music.

Enviado desde mi GT-I9100 mediante Tapatalk
[General Omni Discussion] elitewarrior:
Thanks for the info. I have updated my post :).
[General Omni Discussion] cyril279:
[MENTION=4478126]elitewarrior[/MENTION],

I'm not sure it's worth citing one users trouble restoring nandroids from sdcards using CWMR. The use of CWMR is likely the issue, TWRP (Omni's native recovery) fully supports ExFat.

We would have heard a lot more about nandroid creation/restore issues by now. I'm not experiencing ANY nandroid restore/backup issues, and I have both internal and external sd partitions exfat formatted.

I think your original post nailed it.
[General Omni Discussion] Entropy512:
Had a business trip at the beginning of this week, so I was packing/out of town for a while.

Nope. At this point it's pretty much 100% oddball kernel or compiler bug the likes of which I've never seen before.
[General Omni Discussion] fiz:ik:
I don't know if mentioned here before, but I found a little solution which worked fine on both Galaxy S2s I own:

http://xdaforums.com/showpost.php?p=51400894&postcount=2415
[General Omni Discussion] Red_Vex:
Copy of Lot of files like restore of tb backup still is a problem
[General Omni Discussion] fiz:ik:
With "works fine" I meant to say that you can listen to music properly. No solution for copying big files
[General Omni Discussion] cgx:
If you want to have a workaround until this bug is properly fixed, try the attached flashable zip.

Warning: tested on i9100 variant only.

Warning2: since we are dealing with an obscure memory/variable corruption bug, it is possible that something else goes wrong with the workaround.

To go back to original, flash your rom zip again (it will overwrite the sdcard binary)

For me, this workaround fixes any issues and the file copy testcase I have used to debug this bug has now been passing several times and across reboots

What this workaround does:

$ git diff sdcard.c
diff --git a/sdcard/sdcard.c b/sdcard/sdcard.c
index 989ca00..67e5910 100644
--- a/sdcard/sdcard.c
+++ b/sdcard/sdcard.c
@@ -1214,9 +1214,10 @@ static int handle_read(struct fuse* fuse, struct fuse_handler* handler,
const struct fuse_in_header* hdr, const struct fuse_read_in* req)
{
struct handle *h = id_to_ptr(req->fh);
- __u64 unique = hdr->unique;
+ volatile __u64 vars64[2];
+ vars64[0] = hdr->unique;
__u32 size = req->size;
- __u64 offset = req->offset;
+ vars64[1] = req->offset;
int res;

/* Don't access any other fields of hdr or req beyond this point, the read buffer
@@ -1224,15 +1225,15 @@ static int handle_read(struct fuse* fuse, struct fuse_handler* handler,
* saves us 128KB per request handler thread at the cost of this scary comment. */

TRACE("[%d] READ %p(%d) %u@%llu\n", handler->token,
- h, h->fd, size, offset);
+ h, h->fd, size, vars64[1]);
if (size > sizeof(handler->read_buffer)) {
return -EINVAL;
}
- res = pread64(h->fd, handler->read_buffer, size, offset);
+ res = pread64(h->fd, handler->read_buffer, size, vars64[1]);
if (res < 0) {
return -errno;
}
- fuse_reply(fuse, unique, handler->read_buffer, res);
+ fuse_reply(fuse, vars64[0], handler->read_buffer, res);
return NO_STATUS;
}

update: made the update script a bit safer
[General Omni Discussion] FrodgE:
Nice.

Any thoughts yet why pread64 trashes unique ? Buffer overflow somewhere in the depths of the kernel ?
[General Omni Discussion] cgx:
Well, at the moment I'm thinking the workaround forces the variables to memory. In normal case the compiler may optimize by allocating the variables on cpu registers, and it seems that this is where the corruption happens. Something is not restoring the cpu registers properly during context switch or interrupt. I have not verified any of this yet, but I plan to disassemble the code to see what the code is actually doing.
[General Omni Discussion] FrodgE:
My C is pretty rusty, but I did find this nice explanation:

http://www.barrgroup.com/Embedded-Systems/How-To/C-Volatile-Keyword

Compiler optimisations is an interesting thought but specifying the variable as volatile seems to actually do the opposite to what you're trying to achieve ? (not challenging, just asking & learning !)
[General Omni Discussion] cgx:
The volatile may not actually do anything, I think the array type is more important. I just threw the volatile there to confuse the compiler and not try to optimize the variables more. (If it's volatile, assumption is that it must reside somewhere in memory since general purpose register cannot really be volatile, as nothing else can access it when this task's context is active)
[General Omni Discussion] lerkin:
Щ

Thank you very much, our genius!

Update : unfortunately dropsync hang during uploading.

Still thank you for your effort.
[General Omni Discussion] m4dm4xi:
Same on my side....

That is wierd however.

Because Titanium and Avast Antivirus reproducable stop without the patch...

With the patch it now seems to work without a problem.

Just Dropsync is still having problems...

I´ll have to see wether it´s a Dropsync problem?

Nevertheless, great work cgx! Thank you
[General Omni Discussion] cgx:
Thanks for the reports! The dropsync hang might be a related or different bug, in the worst case the workaround isn't yet 100%

If it seems that people still have problems with this workaround applied, I'll try to add debug mode to see if it's the same corruption is still happening somehow.

There might be also some issue applying the update, this could be checked for example by md5sum through adb:

$ adb shell md5sum /system/bin/sdcard

9eeec83ef36de0071f0be685fb17fb79 /system/bin/sdcard

The md5sum should match above.

Please test and share success/failure, this might help narrowing down the real fix for this bug.
[General Omni Discussion] lerkin:
Yeah, md5 is correct, script works correctly.
[General Omni Discussion] Prashanthme:
will this address the media server drain?
[General Omni Discussion] m4dm4xi:
I believe in some cases it might.

I have seen it occasionally that media server srvice hang on my device and after restart worked again.

This may have had the bug adressed by cgx as cause.

The only way to find out is trying the patch and then giving feedback.

On my side I´m having a lot more stable phone and no problem with media scanner anymore since I installed the patch.
[General Omni Discussion] Prashanthme:
Cool... Let me try it once then :)
[General Omni Discussion] tnfenster:
Seems to work for me
[General Omni Discussion] elitewarrior:
I have been using CM 10.2 (that's Android 4.3 equivalent) just to avoid this nasty bug and I upgraded last night in order to test out [MENTION=3995045]cgx[/MENTION] patch. It was a dirty flash (meaning I didn't clear my old /data or /system, I just installed CM 11, gapps 4.4 and the sdcard patch) and I don't know if this patch is the final solution but it is most definitely a step in the right direction (more like 2 or 3, this is awesome). I forced my self to not touch my phone for the majority of the day, played music for 2 hours, then let my phone sit idle for a while to see if there was any battery drain. Results were amazing and I will let you see for your selves:

And after a bit of idling:

I should mention I am using CM11 but since this actually an i9100 4.4x problem and not an i9100 Omni 4.4x I hope it is ok for me to post this here.

Thank you cgx and [MENTION=591147]Entropy512[/MENTION] :laugh:. I can finally start using 4.4
[General Omni Discussion] MainstreamStereotype:
For me, playing music with Spotify still doesn't work (the md5-sum is correct) :confused:
[General Omni Discussion] clumsy:
Hi, I'm using a modified slimkat rom with this patch included (see http://forum.slimroms.net/topic/1781-sdcardfuse-issues-fixed-need-testers/) on a SGSII I9100 and got advised, that my issues could be related to the topic here...

not sure if it's related to the same issue, but my problem described in the other thread seems to have "changed" (read: improved) with this rom/patch, but not completely solved...

In short: the problem I experienced is, that after a reboot the mediascanner stopped more or less exactly 1 minute after the display shut off. if you have a "top" running in a shell, you can clearly see that the android.process.media suddenly goes from roughly 20% cpu to 0% and stays "frozen". in lsof you can see, that it just freezes at a (random) file and keeps it open... various side-effects from that (eg. ext-sd gallery is not visible, other processes starve, backups get stuck, etc.)

mediascanner behaviour is still the same... the only obvious difference I can see is, that it takes longer after the screen off until it freezes (2 instead of 1 min) and it now seems to crash always at reading a directory and not a file anymore (as far as I understand lsof output)... so also here seemded to change something.

Unfortunately it completely locks up the directory, so if any other application (including a shell) is accessing this directory, it just fails, eg. runs into timeouts and can't display the contents anymore... so it really seems to lock the directory entry.....

process state from then on stays as follows:

u0_a5 2528 1857 256148 41428 ffffffff 4013a6b0 S android.process.media

and never wakes up again.

also treid it after a clean wipe and factory reset... happns always the same.

need to say, that I have multiple GB of picts and movies on the external SD (64GB) so a "full" scann takes about 10min.

I can prevent this, by keeping the phone awake (screen on). then the android.process.media scans until finished.

tried hard to track the issue down (lots of straces, debugs, etc), I'm happy to provide more information if needed...
[General Omni Discussion] Kirsebaer:
This bug is present on Cyan Fox as well so I skipped to Carbon Rom, hoping they had it solved. Well they don't and I had to play my music through ES explorer. However, after I turned on the DSP settings in the DSP manager, I haven't had any issue since with my regular music player.

Just an FYI.
[General Omni Discussion] dahias:
Wink

I'm following this thread for weeks now because this bug is really annoying me...

After your post I had to try it: Dirty flash from cm nightly cm-11-20140312 to cm nightly cm-11-20140407, flashed your zip directly afterwards and rebootet.

I copied several gigabytes from the internal to the external sd card and from these memories to my PC using WiFi. These copy processes always stopped before, but NOW IT WORKS !!! :good::good::good:

Thank you for your investigated time on this issue, I hope these changes find their way to the cm11 rep.

:o
[General Omni Discussion] rocholaroca:
I can confirm that this patch is working great on my SGSII with Aosb_kk_1.3.2_i9100 ROM. Running on ART.

I move all my music files from the internal card to the external Sdcard with no problems. (before it was impossible).

Now I will test the music...

Thank you!!! Thank you!!! Thank you!!!
[General Omni Discussion] Entropy512:
I'm still going to attempt to see if just switching the compiler to gcc 4.6 helps things... Because if registers are getting clobbered, god only knows what other weird problems we might have.
[General Omni Discussion] jl10101:
That's what I was wondering about, surely other things will be affected..Will you be uploading a test script/kernel by any chance? :good: Great work so far everyone, seems like we are seeing a bit of light on this prob :victory:
[General Omni Discussion] lerkin:
New dropsync update fixes some "SD card write issue on samsung/Kitkat". Gonna test that out.

Edit: AAAND got a hang on scheduled titanium backup Backup job :) (with cgx workaround flashed)