yashsingh1/xdaforums huggingface dataset:
[General Omni Discussion] cgx:
I can pretty reliably reproduce the bug by copying large (500M) test file from sdcard to ExtSdCard.

I have made a combined log file from "strace cp /sdcard/testfile1 /extSdCard/" and /proc/kmsg

For the three times I tried this, I got the following results:

-cp process is hung waiting a read to finish from /sdcard

-line "c0 mif: link_pm_irq_handler: gpio [HWK] get [0]" is output from kmsg

I don't know if this is a coincidence or might help narrowing the problem down.

I can provide the full logs if they might be useful

Log1:

write(14, "À\r³ájÔ\225\2247/¥¡)\2l\203îyI\3ãŒÁ]O×òF]Œ?B"..., 65536) = 65536

read(12, "Öö«\231ÿùÉ-j\235Ö$¥\0\31¥3µr\230à-cF¬\222x)¯P\24\16"..., 65536) = 65536

write(14, "Öö«\231ÿùÉ-j\235Ö$¥\0\31¥3µr\230à-cF¬\222x)¯P\24\16"..., 65536) = 65536

read(12,

<6>[ 118.988998] c0 mif: link_pm_irq_handler: gpio [HWK] get [0]

<6>[ 119.025216] c0 mif: link_pm_irq_handler: gpio [HWK] get [1]

<6>[ 119.065164] c0 mif: usb_port_resume: 1283, 4

<6>[ 119.071251] c0 mif: IPC-RX(13): 7f 0b 00 00 08 00 ff b2 07 06 03 67 7e

log2:

write(12, "/©}#¶4cÆOÑbÁýóÜiL¿zóQÞ;+\207\30]\16»³\0072"..., 65536<6>[ 102.026853] c0 sec-battery sec-battery: sec_bat_check_vf: Battery Health (1)

) = 65536

read(10, "\1háÒÔvZîN\200?\212\n,7V±§\217ä\nåV\210z\23F,d\23\7š"..., 65536) = 65536

write(12, "\1háÒÔvZîN\200?\212\n,7V±§\217ä\nåV\210z\23F,d\23\7š"..., 65536) = 65536

read(10, "õB\210þ\2235h«\207§L \230]-ìð*\3ÀÂwã\10õ\231YT\rÿ^n"..., 65536) = 65536

write(12, "õB\210þ\2235h«\207§L \230]-ìð*\3ÀÂwã\10õ\231YT\rÿ^n"..., 65536) = 65536

read(10,

<6>[ 107.629076] c0 mif: link_pm_irq_handler: gpio [HWK] get [0]

<6>[ 107.667018] c0 mif: link_pm_irq_handler: gpio [HWK] get [1]

<6>[ 107.705190] c0 mif: usb_port_resume: 1283, 4

log3:

read(12, "\23iAA§D\214dÞ¬i\223Iã\2k;ñ\234>\212èG5íUµWÎ¹Y·"..., 65536) = 65536

write(14, "\23iAA§D\214dÞ¬i\223Iã\2k;ñ\234>\212èG5íUµWÎ¹Y·"..., 65536) = 65536

read(12,

<6>[ 136.966064] c0 mif: link_pm_irq_handler: gpio [HWK] get [0]

<6>[ 136.996002] c0 mif: link_pm_irq_handler: gpio [HWK] get [1]

<6>[ 137.045449] c0 mif: usb_port_resume: 1283, 4

<6>[ 137.051215] c0 mif: IPC-RX(16): 7f 0e 00 00 0b 00 ff d6 07 01 03 ff 02 00 05 7e
[General Omni Discussion] pilgrim011:
I don't know if this will help, but I have just succesfully copied a file (~850MB) from internal SD to external and vice versa. Running latest Gustavo kernel from 08.02. Don't know about music - haven't got enough time to test that.
[General Omni Discussion] danyprasad:
Hi Guys

I am facing a small issue with my SGS2 with omni ROM. While transferring files when the screen get off the transfer process freezes and I have reboot my phone again to be detected by my PC.. This process occurs when used my phone as a portable media player. Please let me know how can I go ahead of this.
[General Omni Discussion] lerkin:
Testing Gustavo's kernel right now on cm 11. Copied 3 times 3 files of nightlies from sdcard1 to sdcard0 successfully, one schedule of dropsync done successfully too. This is promising. Will test further during uptime.

Edit. STILL HANGS.
[General Omni Discussion] :
I am using Dirty Unicorn v6 and also I am having this bug in all my multiple file copying attempts file sizes are 250 to 500mb they seem Ok when copying alone but together it freezes in the middle of the process. It does not matter that you copy sd to sd or sd to usb - usb to sd. I've tested different file managers got same results. Hoping future fixes.

GT-N7000...
[General Omni Discussion] bleggy:
are we really sure the file copying deal you guys describe is the same as the music playing bug of this thread?

I mean, the mp3s that I listen to are only 20mb or so each. And it still freezes up. File size doesnt seem to matter.
[General Omni Discussion] theBIGone:
For me the bug only surfaces when listening in spotify to local files, so files that where downloaded from my own music library. When listening to offline files downloaded from spotify, everything is working well.

Also Podcasts downloaded in podkicker work perfectly.
[General Omni Discussion] Thristle:
Changed i/o scheduler to bfq abd raised the sd card read ahead to 256k. Seems to be working better
[General Omni Discussion] lerkin:
Please test more and report
[General Omni Discussion] Wing2468:
I'm also on 2/06 nightly ATM. I listened to music off my external SD-Card for the whole Saturday and it was working fine.

FYI, the i9100 was and is running airplane mode all the time, and wifi was off when screen's off. When I have time, I'll put my SIM (currently in my i777 running CM10.1.3) in i9100 to see whether it makes a difference or not.
[General Omni Discussion] lerkin:
Please try copying really big files from one SD to another, or using USB mass storage.
[General Omni Discussion] Wing2468:
OK, connected my phone to a PC and attached as USB mass storage. Then,

1. copy a movie (~1.5GB) from PC to i9100's internal-SD

2. copy another movie (~1.9GB) from PC to i9100's external-SD

3. disconnect i9100 from PC

4. use OI File Manager to copy movie(1) from internal-SD to external-SD

5. watch both movies off external-SD using Gallery but only the first 5 minutes

6. watch movie(2) off external-SD using Gallery, this time the whole movie (~2 hours)

I didn't experience any freezes whatsoever! Like I mentioned before, my i9100 is still in Airplane Mode w/o a SIM.
[General Omni Discussion] lerkin:
Thanks, it is very interesting observation.
[General Omni Discussion] Tann San:
I hope you meant the zip from this post by cgx since I'm applying it now :fingers-crossed:
[General Omni Discussion] d3m0n1:
Is this applicable for n7000 as well (or just i9100)?

Thanks in advance,

d3m0n
[General Omni Discussion] tazmanyakerim13:
I hate this bug, i can't use my phone effectively since i started to use aosp roms!

I9100 neatrom aosp latest ;)
[General Omni Discussion] lerkin:
Fall back to cm-10.2.1-based Roms.
[General Omni Discussion] sharp87:
Formatted my both internal and external sd card to exfat and I have no issues regarding music bug or file copying bug...

CM11 Nightlies

Sent from my GT-I9100
[General Omni Discussion] lerkin:
I formatted ext4 for internal and exfat for external - still buggy.

Should try exfat - exfat too maybe.
[General Omni Discussion] tazmanyakerim13:
Lets give it a try, btw how can i learn the current fortmat of my phone, any ideas?

I9100 neatrom aosp latest ;)
[General Omni Discussion] bleggy:
there's no reason not to use these workarounds (exfat formatting and/or cgx's zip). they work. I've forgotten about this problem until I revisited this thread.
[General Omni Discussion] lerkin:
Unfortunately they do not work for all, for me exfat formatting with or without cgx's do not fix the problem. Fuse daemon still freezes while syncing with dropsync or copying large amount of data from\to PC.
[General Omni Discussion] bleggy:
weird. I have cgx for internal and exfat external and I can do all of that.

maybe its your ext4/cgx combo not working.
[General Omni Discussion] Tann San:
I'm still getting the problem since applying the patch, only my external is exFAT. For those that have also formatted the internal memory, did you format it all or repartition it? I thought I read somewhere that formatting all the internal to exFAT could cause different problems. I'm at the point where I'd do a total fresh install to not have this problem anymore but I'd be shouting out loud to do all that and find it still glitched :laugh:
[General Omni Discussion] bleggy:
I wonder what the difference is between those that have had success with the patch and those that haven't.

I dont use dropsync but I do copy files to/from my computer via wifi and I dl/up large files via ftp regularly, as well as move albums and podcasts around. before, this would freeze up my phone.

i777/latest omni/renders kernel
[General Omni Discussion] Entropy512:
All 4210 devices are identical with regards to this particular issue
[General Omni Discussion] FrodgE:
I've done both but for completely unrelated reasons. I wanted more application space so I repartitioned at the sacrifice of internal sdcard storage. Details here: [MOD][GUIDE]Partition your internal memory for better App management (Pit Files) For everyday usage BOTH my internal & external are formatted to exFat, rock solid. For debug purposes I pop in my fat32 formatted external sd and the problem occurs pretty quickly during file read.

So on that... debugging. I was going to hold off until I had something more substantial to report but since I'm logged in and typing I guess I'll continue...

I've tried a few things. Firstly there was the issue CGX raised about buffer overflow in various places throughout the kernel. I ran the same utility and put a whole heap of printk debug messages near those instances. Nothing. Yes the code is broken but that isn't the problem here. Next idea was to learn what GDB was and "complex dwarf expressions"... yeah I think I'll need to read up a bit more on that first. Tonight however I looked into the interrupts. For what it's worth I've noticed that each time unique is clobbered pread64 is interrupted by "irq 141, handler mshci_irq" or "irq 139, handler sdhci_irq". I expect it's probably more the isr system in general rather than the actual isr itself, but it's area to start looking into further...
[General Omni Discussion] AndDiSa:
Hmmm a bit strange ... I tried to provocate the bug but I didn't succeed. I've copied yesterday around 8GB from my external sdcard (formatted vfat) to the internal one using es file explorer. No problems at all.

The only difference to the 'standard' cm-11 build: I am using the sdcard.c ( system/core) from the AOSP, not the cyanogen one.
[General Omni Discussion] lerkin:
Why you use AOSP sdcard.c? How you came to it?

May be you could share AOSP sdcard.c here?
[General Omni Discussion] AndDiSa:
I've seen the discussion here some weeks ago and I was looking for differences between AOSP and CM because several people reported that the problem does only occur on CM and not on others. So I looked at the 'root' of all sources and compared it to the CM version.

Probably I was only very lucky because I do not listen for hours to music stored on my sdcard, but during the copy process I didn't had any problems.
[General Omni Discussion] lerkin:
Please upload the file, I would like to test.
[General Omni Discussion] AndDiSa:
Here you are ... ;)
[General Omni Discussion] lerkin:
Thanks. Where I should put the file?
[General Omni Discussion] d3m0n1:
This is only useful if you want to compile your own android build, so if you have no development tools set up, then it's a "no go".

br

d3m0n
[General Omni Discussion] lerkin:
Maybe some one can upload precompiled one? Why not?
[General Omni Discussion] Red_Vex:
As far ad i know that bug regard every kitkat version running on s2
[General Omni Discussion] FrodgE:
Hmmm are you sure that's unmodified ? It contains the workaround CGX posted back in #304. If you're running this code that could help explain why you can't reproduce the problem.

It's easy to point the finger at sdcard.c, especially when you can make a simple 1 line change that alters the compiler optimisations that are applied and the problem magically goes away (eg printing the address of unique). I dare say that simply turning off optimisations would "fix" the problem.

So, are these tweaks to sdcard.c:

1. An actual bug fix to a genuine problem in the daemon

2. A workaround that doesn't address the real root cause.

Personally I view them as #2 for a few reasons.

- I am going to assume, and yes it is an assumption so please correct me if I'm wrong, the same sdcard.c source is compiled for all devices with the same compiler optimisation settings and yet it's only these exynos devices that are experiencing this fault. In my mind that suggests a fault within device specific code rather than something that's common across multiple unaffected devices.

- The sdcard works fine the majority of the time and the diagnostics we've performed so far show the corruption occurring during a call that's external to the daemon.

- As a test I declared another __64 variable and hard coded it to 987654321, it also get's clobbered even though I don't use it for anything. If however I print out it's address the variable survives and only unique and offset get corrupted.

- I've added some kernel debug messages to pread64 and the IRQ handler. So far my logs show the corruption only occurring if pread64 is interrupted. I'm thinking that something isn't being restored correctly upon ISR completion.

I get this horrible feeling I need to start learning ARM assembler code (I haven't looked at assembler for near 15 years...). Unfortunately I haven't had the opportunity to look into this any more tonight and I'm going to struggle to get back into it till late next week. If I find anything interesting I'll post an update...

---------- Post added at 11:16 PM ---------- Previous post was at 11:14 PM ----------

This is also my understanding. If anyone knows otherwise please provide a reference.
[General Omni Discussion] Entropy512:
I agree with you that it's #2 - This seems to be some weird IRQ issue specific to 4210 devices. It doesn't even happen on Exynos 4412

Is it always a modem IRQ or do other IRQs also cause issues?
[General Omni Discussion] patrickph:
man h

Is this bug fixed now ? I hope we can has a bufree kitkat .
[General Omni Discussion] Entropy512:
Why ask a question with an obvious answer?

If the bug were fixed, someone would've said something here.
[General Omni Discussion] snow:
[MENTION=591147]Entropy512[/MENTION], maybe new Exynos DRM driver would be useful? :)

http://www.phoronix.com/scan.php?page=news_item&px=MTY1NDE

Maybe the calls of the specific function is too low? There's a maximum and/or minimum number of calls of the function?

In my opinion, maybe something is missing or is implemented wrong.

I'm just trying to help, so don't be so mean to me. :P
[General Omni Discussion] Twiq:
I don't think that would solve our problem..

CMIIW.. direct rendering manager is used mostly for GPU right? Therefore it affects video and screen casting stuffs right?

I can't see the link between DRM and fuse daemon.. But maybe thats just me, i'll leave it to the masters ?

Running 0522 Sabered SlimKat | DorimanX 10.43v111
[General Omni Discussion] Entropy512:
DRM is only useful for people running vanilla Linux (not Android) on Exynos4 chips.

It's likely useful (probably already in use) on Samsung's ARM Chromebooks, but not really anywhere else.
[General Omni Discussion] dudders007:
I have never experienced the music bug in resurrection remix roms... it only existed in 5.1.3 for me never in any other releases.. No1 even in the newest release.. :) I dunno y or how but i experienced this bug in almost every rom i used other than this one.
[General Omni Discussion] lerkin:
Checked - bug still there
[General Omni Discussion] Swaluw:
cant read folder data

After music stops, Mortplayer says "can't read folder data"...music is on ext. sd but that shouldnt matter

Also: sometimes processor stays in 1400Mhz state which drains battery like crazy which means it loses power even whlie plugged in !?!
[General Omni Discussion] Tann San:
I had the same thing with Mortplayer until I formatted my external SD to exFAT and moved all my audiobooks there, not had the Mortplayer problem for over a month now.

A while ago I wrote about how my phone battery was draining super fast but at random times. I assumed it was the bug this thread, my thinking being that something was trying to access a resource on the internal memory and then getting stuck in a loop when it conked out. When I had some free time I re-installed BetterBatteryStats I found that it seemed to be 2 things.

The first was that Fast Dormancy was enabled and I could tell that was a problem as I was seeing "secril_fd-interface" burning through my battery life via BetterBatteryStats. Unfortunately, the hidden menu dialer code no longer works so I had to Fast Dormancy Toggle from the play store. My phone's a Galaxy Note N7000 running OmniROM 4.4.3 and I'm with Orange/EE in the UK.

The second thing was that I turned off Settings->Location, I don't remember what it was labelled as in BBS but it was the next big offender after FD. I do use the location services when I'm out and about but now I just turn it on when needed.

Doing the above seems of solved my big battery drain issues although I now check BBS every few days just to make sure nothing else is being naughty.
[General Omni Discussion] dudders007:
How come i have never experienced it in the rom? I play atleast 2 hours o music everyday...
[General Omni Discussion] Tann San:
Maybe it's because of a difference in the MicroSD card speed, assuming you're playing tunes off your external and not internal memory.
[General Omni Discussion] Entropy512:
Yup. This bug is very timing-sensitive. There are a bunch of thinks that can mask it to varying degrees even though it's still there.
[General Omni Discussion] Swaluw:
ext / internal sd doesn NOT matter with regard to this random music stop issue

it doesnt matter
[General Omni Discussion] MauFerrusca:
No, no you're not. :rolleyes:
[General Omni Discussion] DJG0A:
This was a rhetorical question...
[General Omni Discussion] zavorrax:
Just my 2ç,

is there any way to get rid of the fuse stuff and mount the sd card using good old kernel space drivers just like previous android versions?

Z
[General Omni Discussion] Swaluw:
Music Player v5

I just started testing Music Player V5...seems to be having no random stops, except once, after i accidentally started apollo, it wouldnt open any maps, terminated immediately, even after a reboot. Had to reinstall, but still, no stops at all !!

Yes i tried several other players despite i alrdy read it wasnt worth the try...and indeed besides this one, none worked longer than like 5minutes...

MUSIC PLAYER V5 is tha shizz boys n girls

Edit: after several hours of listening to awful music, still no random stop. Could it be true? I dont care about the cause, i care about the solution!

Edit2: So I found a workaround solution and no replies/thanks at all (!) big lol :) O btw of course i store muzic on my ext sd..
[General Omni Discussion] NaminatoR1254jaime.sier:
No one is thanking you because the real real problem its still there and the use of other music players has been posted throughout the entire thread. The problem evolved from "music in sd card stops" to "sd card unmount" which is far more dangerous and important.

Plus, a real real workaround was posted in page 35, 36, not sure.

Sorry if it sounds harsh, not my intention.
[General Omni Discussion] Entropy512:
Yup. There are tons of non-music use cases for the SD card, none of which changing a music player fixes.

Also, what's been discovered about the bug so far is indicative of some REALLY nasty underlying issues that are likely causing all sorts of other weird stability issues/behaviors throughout the rest of the system we can't predict. If an incoming interrupt during a pread64() call causes data in the function that called pread64() to get corrupted, something is VERY VERY WRONG.

These devices have a NASTY kernel bug, and nothing other than a solution to the root cause is a viable solution.

Since this doesn't affect the 4412 devices, I'm wondering if there was an ARM errata workaround in the Samsung 4210 sources that didn't make it in when 4210 support was merged into the 4412 kernel baseline. Unfortunately, there has been so much work done on the 4412 sources that reviving the old 4210 tree and trying to get it to even work with Omni to see if it helps would be a major effort. (but if the old 4210 sources work better, that gives people an idea of where to hunt for a solution.)
[General Omni Discussion] NaminatoR1254jaime.sier:
N7100 blobs and stuff were released. Saw something on the CM 11 thread (not the discussione one) on Galaxy S2 Development.

Does that help something to the matter?

Enviado desde mi GT-I9100 mediante Tapatalk
[General Omni Discussion] Entropy512:
Nope, since as I said in that post - for whatever reason this issue seems to ONLY affect the 4210 devices, not the 4412s. I have no idea why the 4412s aren't affected other than my guesses in the previous post.
[General Omni Discussion] NaminatoR1254jaime.sier:
my bad, I mistook Note for Note II haha

Enviado desde mi GT-I9100 mediante Tapatalk
[General Omni Discussion] spirohan:
Maybe i'm going to test it soon, but does someone know if there's still the issue on android "4.4.4" ?
[General Omni Discussion] NaminatoR1254jaime.sier:
Yes it does. Tested on CRom v 7.1 for i9100

Enviado desde mi GT-I9100 mediante Tapatalk
[General Omni Discussion] Entropy512:
4.4.4 only contained OpenSSL changes.

This is a kernel bug in Samsung's kernel that only affects Exynos 4210 devices, which haven't seen an update from Samsung since Android 4.1
[General Omni Discussion] bleggy:
how come the workarounds arent working for you guys? I havent had any trouble since formatting & flashing that zip a few months ago (and placing it in my flashafterupdate folder).
[General Omni Discussion] NaminatoR1254jaime.sier:
I used the w.a. on CRom 7.1 and mediascanner still ran forever.

Enviado desde mi GT-I9100 mediante Tapatalk
[General Omni Discussion] bleggy:
right. just wondering why that is and if the workarounds can be tweaked to include all.

i777 omnirom / exfat external sd / internal with cgx's zip. 100% success.
[General Omni Discussion] :
What about android L do you think there will be a major difference then kk that may surprisingly works as it was on jb.

GT-N7000...
[General Omni Discussion] Entropy512:
Not likely. Also, I'm leaning towards just dropping the 4210 devices from nightlies with L.

There just isn't anyone with enough spare time to fix the various bugs as it is.
[General Omni Discussion] :
GT-N7000...
[General Omni Discussion] dmrazor:
Guess it's safe to assume that this bug won't be fixed anymore. I'm sticking with CM10.1.3

Cheers,

Raz
[General Omni Discussion] Entropy512:
A possibility, but very small. It's not likely, unless possibly someone that did some of the digging into the problem who has more time for this device than I do takes a look to see if maybe the old CM smdk4210 tree had some ARM errata handling stuff not present in the merged smdk4412 tree (a while ago the 4210 devices were merged into the 4412 tree.)
[General Omni Discussion] zeitferne:
Also affected here.

So it seems that there is both a working version and a broken version. What stops us from bisecting? Is it that the bug takes so long to reproduce?
[General Omni Discussion] SkullDeath:
The bug is very random and enabling logging causes this issue to stop happening.

In summary, very tough to fix.
[General Omni Discussion] Entropy512:
There's no confirmed working version. If you reread what I stated, there is a SUSPICION that there might be something missing in the 4412 tree that is present in the old 4210 tree - but no confirmation this is actually the case as the 4210 tree ended with 4.1 or 4.2 and has never been used with 4.4.

Since the 4210 tree ended at 4.1 or 4.2, it's much harder to test it out with 4.4 to see if maybe it has something we're missing in the 4412 tree. (Which, despite its name, is now actually a combined 4210/4412 tree.)