yashsingh1/xdaforums huggingface dataset:
[General Omni Discussion] cgx:
Maybe some dev could look at:

https://github.com/omnirom/android_...d9#diff-af783c15a64987d602576f24319e58fcR1216

The code modification

+#ifdef CONFIG_WIMAX_CMC

+	if (!err)

+#else

+	if (!err && (host->caps2 & MMC_CAP2_POWEROFF_NOTIFY))

+#endif

looks suspect to me, maybe a merge error?

The resulting code is now:

/*
* If the host supports the power_off_notify capability then
* set the notification byte in the ext_csd register of device
*/
if ((host->caps2 & MMC_CAP2_POWEROFF_NOTIFY) &&
((card->ext_csd.rev >= 5) && CHECK_PON_ENABLE)) [B]{[/B]
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
EXT_CSD_POWER_OFF_NOTIFICATION,
EXT_CSD_POWER_ON,
card->ext_csd.generic_cmd6_time);
if (err && err != -EBADMSG)
goto free_card;
#ifdef CONFIG_WIMAX_CMC
if (!err)
#else
if (!err && (host->caps2 & MMC_CAP2_POWEROFF_NOTIFY))
#endif
/*
* The err can be -EBADMSG or 0,
* so check for success and update the flag
*/
if (!err)
card->poweroff_notify_state = MMC_POWERED_ON;
[B]}[/B]

Looking back a couple of revisions, maybe the intention was something like: (The extra if (!err) was already there a couple a revisions earlier)

/*
* If the host supports the power_off_notify capability then
* set the notification byte in the ext_csd register of device
*/
if ((host->caps2 & MMC_CAP2_POWEROFF_NOTIFY) &&
((card->ext_csd.rev >= 5) && CHECK_PON_ENABLE)) [B]{[/B]
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
EXT_CSD_POWER_OFF_NOTIFICATION,
EXT_CSD_POWER_ON,
card->ext_csd.generic_cmd6_time);
if (err && err != -EBADMSG)
goto free_card;
[B]}[/B]

#ifdef CONFIG_WIMAX_CMC
if (!err)
#else
if (!err && (host->caps2 & MMC_CAP2_POWEROFF_NOTIFY))
#endif
/*
* The err can be -EBADMSG or 0,
* so check for success and update the flag
*/
if (!err)
card->poweroff_notify_state = MMC_POWERED_ON;

But it is still weird...
[General Omni Discussion] bassmanitram:
Confirmed on N7000 (Galaxy Note intl)

After tearing my hair out for a couple of days I was pointed to this - and can confirm that as of Omnirom 9th February, these symptoms are most definitely present on my N7000. Furthermore, some comments seem to indicate that the perpetual problems of copying files between my desktop and the device, and of, say, attempting to run commands like "tar" on sdcard directories may also be attributable, at their root, this problem.

So happy it's not me going mad or my device dying!

It seems a summary of the state might be in order. From what I can tell from the comments,

This is to do with probable timing issues in the FUSE daemon used to mount the sdcard(s). The card(s) get(s) "randomly" unmounted?

It appears to only affect devices based upon Exynos 4210 chipsets

There is a possible fix described by gerrit omnirom org 5307. The comments indicate that, if successful, the individual commits of changes relating to the patch will be published. The status as of today indicates that the patch is still being reviewed.

There are reports that messing with the CPU governor, IO Scheduler, and read-ahead values can alleviate the problem, though there doesn't appear to be any consensus on what and how much to change, or the effect it has (understandably since the symptoms are non-deterministic).

It appears that increasing debugging in the FUSE driver hides the problem (bad idea, I'm sure, but would that be a short-term work-around for public use?)

Is that a fair summary - please correct as you see fit.
[General Omni Discussion] glhfggnore:
Music playing report

Hello everyone,

I am here to report that after installing latest beta dorimanx kernel with fuse daemon patch I've been listening to my music without any problems.

It is the second day counting already.

I also set read ahead buffer size to 2560 kb gov ondemand io scheduler to noop.

I hope it will help. I don't know why gerrit https://gerrit.slimroms.net/#/c/3557/ is considered as not fixing the issue with music player. It seems, that changes to https://gerrit.slimroms.net/#/c/3557/1/rootdir/init.smdk4210.rc implemented in latest dorimanx fixed the issue whatsoever, and I am really glad for it. My intuition tells me that music player is stable now for me!!! Yeeepee!!!!

My rom is Pound rom 21/01/2014.

I am on i9100 sgs2

---------- Post added at 09:38 PM ---------- Previous post was at 09:05 PM ----------

Some people report music player still stops.

Just as I've mentioned before I suggest to try increasing read ahead buffer size.
[General Omni Discussion] lerkin:
Don't know about music, but heavy file operations still hangs with latest dorimanx's. Didn't change buffer and governors/schedulers.
[General Omni Discussion] glhfggnore:
Update 2

Earlier I've encountered file copy problems. I have found file copying process halted on files containing in its name characters other that English. I've renamed them all. Maybe this is what is causing problems with file read while copying and music play.
[General Omni Discussion] lerkin:
I have hangs while copying cm nightlies.
[General Omni Discussion] glhfggnore:
What app do you use for copying? I've had problems on renaming files with es explorer. But with default cm file manager file renaming was successful. I think there can be a connection between this operations. Maybe in code, some apps use "light" commands / procedures for copying unlike default "heavy" programmed file manager which use more stable commands to copy? I dunno though yet. :/
[General Omni Discussion] kl0ndike:
There are two different memory storage types - Internal & External. Everyone should test freezing separately, because this patch has been applied to the external sd card only.
[General Omni Discussion] glhfggnore:
Somehow this patch fixed things for me playing all my music from internal sdcard. If it fixes only external sdcard, then maybe this patch didn't patch anything at all for me and my past three days of stable work is just my random luck? It is a Russian roulette bug so we can expect everything. I was just so excited about all this things working.
[General Omni Discussion] Entropy512:
Thing is, the card is not getting unmounted. So any commits related to it getting mounted/unmounted are not going to fix this issue. (They will fix some storage status issues). Also, OpenDelta NEVER USED THE EXTERNAL CARD and was having issues with the INTERNAL card which, as others have commented, that didn't change.

The FUSE daemon is completely hanging with a deadlock. This is completely different from "unmounting"

However there's an upstream commit from aosp/master that could possibly have an effect, although reading the commit message it shouldn't.

Also, while some people got lucky with that shotgun commit, others appear to be having issues.

Don't think that the MMC commit related to wimax_cmc is relevant - the underlying MMC is just working fine (if you go to the underlying storage, you can read/write/copy files without issues.)
[General Omni Discussion] cookm75:
I've had this problem occurring every day using PlayerPro, Google music and Apollo.

But have been using Winamp for last 3 weeks and it has not happened once so far.
[General Omni Discussion] Entropy512:
Attached are i777 and n7000 test kernels with:

https://gerrit.omnirom.org/#/c/5307/

This patchset needs much more testing to identify whether it is a step in the right direction or not. Even if it causes other issues, I need dmesg logs of those issues and logcat entries with details if they cause problems for you.

More importantly, I need info as to whether it helps with FUSE deadlocks.
[General Omni Discussion] kl0ndike:
Could you make a kernel-build for the latest cm11 i9100 nightly? I'm ready and able to help with tests.
[General Omni Discussion] lerkin:
+1!
[General Omni Discussion] doctor_droid:
Thats kinda bad to ask.. Its omni not cm... Flash omni and then help..if u really want to help..
[General Omni Discussion] lerkin:
I mean test omni kernel for i9100, of course.
[General Omni Discussion] billyJ:
Why it's bad it's the same issue and the more people testing it the better. I don't see a reason for starting a war.

Galaxy S2 running CyanFox KK 4.4.2 with Tapatalk
[General Omni Discussion] doctor_droid:
Nothing like a war here my friend ..

Its a condition apply..

It's like make this for this rom and then i will help.. I guess its too lazy to help...

Also u think entropy is too free to release a cm compatible version?

Why just nt simply flash omni n test? Btw these discussions are irrelevant to the topic..
[General Omni Discussion] bassmanitram:
Extreme workaround hack (with government health warnings!)

You know those commercials for drugs where they list so many serious side effects you wonder if it's worth taking the drug in the first place?

Well, this is one of those. (So much so I feel mildly irresponsible posting it).

BUT it MAY help your music playing problems while more capable kernel developers try to figure out the real fix to the FUSE deadlock problem. It works at the moment for me on my N7000. But I suggest you only try this if you know what you're doing and reliable long-duration music playback is critical for you.

You will need:

A rooted device (well, OK, that's a given!)

A good file manager that allows you to do hacky stuff in root mode - particularly remount the root file system and change folder permissions. I use FX.

Expectations of weird, possibly critical, side-effects

The process is simple - but (in the absence of a system init script to do it for you) it needs to be done on every reboot:

Open your file manager

Remount the root file system read-write

Change the permissions of /mnt/media_rw so "g" (group) has "r" (read) and "x" (execute/traversal) permissions. Do the same for "o" (others).

Remount the root file system as read-only

Pray

(The same things can be done from a terminal emulator in root mode - but I'm not going to detail that here - if you are an adequately experienced Linux (super)user you'll be able to figure it out if you need to.)

Your media cards (sdcard0 and sdcard1 on my N7000) will now appear TWICE in those music players that allow you to pick where your music library is. The difference is that the /mnt/media_rw version goes through the tried and tested "real" filesystem driver for the card rather than the FUSE driver (which is where the problems are). So now you switch your music library location from the /storage mount to the /mnt/media_rw mount and IN THEORY you won't have the music-stop problem.

The side effects - potential ones are duplicate files in your system media library, confusion in apps that try to access all mounted media, security breaches etc. etc. kl0ndike reports adverse effects for Text-to-speech.

As I said, THIS IS AN EXTREME HACK with possible horrors lying in wait for anyone who uses it - but, at the moment, it works for me on my N7000 and (being a musician who uses his device for practice) has avoided the need to revert back to a Jelly Bean ROM (for now).

A final word - if you are just applying this see if it works for "fun" (i.e. reliable music playback is not your primary concern) then I'd encourage you to try Entropy's alpha fix instead, and help him figure out if it's gonna work (see post #73).

Martin
[General Omni Discussion] zeitferne:
I just flashed from recovery over my existing (CM default) kernel, rebooted and everything was fine. Maybe your download is damaged? MD5 of the ZIP should be d41190d1378d7e0f7f2cb8b6ba6ca1aa.
[General Omni Discussion] notabenem:
TC says it's all right.

FR-kernel-cm-11-20141115-SNAPSHOT-M12-Lanchon-20141218-i9100.md5:
OK: FR-kernel-cm-11-20141115-SNAPSHOT-M12-Lanchon-20141218-i9100.zip

Errors: 0
OK: 1, not found: 0, read error: 0, wrong checksum: 0

The android robot is wiggling its ears for >20 mins now. And blinking...

Edit: Kernel wipe did not help, had to revert to the previous kernel (Gustavo). Will do a full backup and then factory reset.
[General Omni Discussion] jnetode:
So far I could not reproduce the issue as well.

Tried 1 and 4 processes.
[General Omni Discussion] cdrivex4:
That make 3 so far with no errors including me. ah ah ah. FR kernel + FPbug2 is goood, with screen on no errors like before (within 30 seconds)..unpluging/pluging power after short(5seconds) or long (3 mins) nothing...even if screen goes off...uptime 25mins so far no error, whereas before you were looking at seconds for the error to pop up....time for some serious audio playback testing...
[General Omni Discussion] snow:
Bug is gone!!! :D You are a wizard! It seems 4 persons were not able to reproduce the bug with your kernel (me, [MENTION=5948587]zeitferne[/MENTION], [MENTION=3824270]jnetode[/MENTION], [MENTION=5665605]cdrivex4[/MENTION])!
[General Omni Discussion] grzwolf:
5 with no errors on FR kernel + FPbug2.
[General Omni Discussion] Acid0057:
[MENTION=4141005]Lanchon[/MENTION] would that fr kernel be okay to use on a Nov or Dec nightly from cm11? If so I'll give it a test here too.

Sent from my GT-I9100 flowing on SwiftKey in Tapatalk
[General Omni Discussion] drdays:
Also confirm no corruption on FPBug 2 process with screen off for 1 hour.
[General Omni Discussion] zeitferne:
HTH
[General Omni Discussion] Acid0057:
Thanks! Installing later today. If I have the previous music bug fix in system would that affect testing?

Sent from my GT-I9100 flowing on SwiftKey in Tapatalk
[General Omni Discussion] zeitferne:
This only patches the sdcard daemon, and thus doesn't affect testing with Lanchon's FPBug App, but it would of course affect tests that depend on playing music/copying files.
[General Omni Discussion] Lanchon:
thanks guys, this is great!! pheww... that was a *****

i'll clean up and post everything later cause i'm busy now, but here's what did it:

on SMP arm (eg: our case, multicore), the FPU state is saved eagerly on context switch out and restored lazily on context switch in. a given time slice starts with the FPU disabled, and only if the process later touches the FPU during the slice, the kernel restores the state in a trap (and only then it will have to save the state when the slice is up).

the state is saved in ram but also left there in the disabled FPU registers. it may happen that when the kernel decides to restore the FPU state saved in ram to a given disabled FPU, by chance the state it wants to load is already present in there. to take advantage of this lucky situation, the kernel tracks the leftover state in the disabled FPUs and optimizes the load away when it can prove that it's not needed. (the trap is still needed to enable the FPU, so the time saved is really not that much.)

in our case somehow the tracking fails (across power management state changes, or during CPU migration of tasks, or who knows), the wrong decision is made and the state is not restored when it's actually needed. FR has a bunch of mainline fixes for FPU corruption cases (same as MG8), but the change that did away with this problem is simply disabling this state restore optimization and always load the state from ram.

this looks like a full fix. it does have a performance impact, but only for processes that use the FPU, and only when they are running FPU-uncontested in a core. in any case, i'd guess the performance impact of affected processes is probably less than 1%.

now i'd really like someone with a 4412 device (eg: S3 international) to properly test FPBug2.apk (screen off) and verify that it's truly not affected.

---------- Post added at 02:22 PM ---------- Previous post was at 02:16 PM ----------

this is a CM kernel, no reason it should work in Omni

that's right!

---------- Post added at 02:28 PM ---------- Previous post was at 02:22 PM ----------

i'm curious as to the performance impact, see if it's worth the effort to restore the optimization.

if somebody wants to test:

after reboot please run antutu 2 or 3 times with each kernel (FR and MG8) and report

thanks!!!
[General Omni Discussion] cdrivex4:
Realise FR was just to fix music bug hunt, but anyone else notice phone network being dropped completely after the flash.. Or is it just me.have to say it's been cool listening to music again without jetaudio not dying didn't notice no calls or texts.

What happens next for nightly cm11?

sent from my gt-i9100
[General Omni Discussion] zeitferne:
Funny, my phone lost the network connection yesterday and I had to restart (could not even *enter* flight mode) but right now, with the FR kernel, all is well.

EDIT: "Just" to fix the music bug hunt?! :D That was a hell of a hunt that Lanchon might just have ended here!

Why might? I'm playing devils advocate here: So we now know that the vfp module missed some important powerstate notification, and we have a good workaround for this. But maybe this is not the fault of the vfp module, but of some other module (hotplug?) that fails to send the notification, or sends it at the wrong time. If that was the case, other modules that also depend on such notifications could be affected too.

EDIT2: Thinking about it, its almost definitely not the vfp module's fault, since the same module works fine on 4412. Could still be that instead of wrong notifications, the FPU on the 4210 does not meet the vfp modules assumptions, i.e. loses state when it shouldn't.
[General Omni Discussion] Entropy512:
Yeah. Whether his fix is the final one - don't know.

But he's made a LOT of progress towards finding root cause and is closer than anyone has ever been. At least from an Omni perspective, Lanchon's work means "there's a chance of 5.0 if a maintainer shows up" as opposed to "even if a maintainer shows up, no 5.0 nightlies until this gets fixed"
[General Omni Discussion] notabenem:
Good to read this.

And just in case that no one will volunteer, what would be the best choice out of the current flagship phones for running Omni (Lollipop) - something like a "long term good choice for Omni"?
[General Omni Discussion] zeitferne:
Yeah, definitely! :)

Thank you [MENTION=4141005]Lanchon[/MENTION]! The patched sdcard was already really helpful from a pragmatic point of view, and now it seems like I can finally start to trust my phone again. Even if maybe not the final one, this kernel is definitely a breakthrough!
[General Omni Discussion] Entropy512:
Right now... Oppo devices are our best supported devices and I expect that to continue. Sony devices are hit-and-miss - many of the Omni team love Sony devices, but their 6-month product cycle combined with inconsistent availability in many regions has hurt them. There's also the fact that honestly, their stock firmwares are really damn solid. My daily driver for the past month has been a bone-stock (no root, no bootloader unlock) Z3. At some point I'll work on Omni for it, but I don't have the time right now. (I need to sort out some fundamental things in my life that are non-Android related first.)

Although I'm not sure if I'd go for the N3, that device is... meeeeeh. It's the first Oppo I've put ZERO effort into daily-drivering. (I at least used the R819 for a week, I would've used it for longer if not for MTK.)
[General Omni Discussion] notabenem:
Patch collection

Zeitferne and Lanchon,

For the sake of completeness, could both of you please post all the patches/cherry picked GIT commits (with hyperlinks) that you applied to the kernel (even though they did not fix the FPU corruption) ? Apparently there are a lot of things that were just lurking undetected with who knows what kind of side-effects (fixed or unfixed). Hopefully kernel/device maintainers will find this knowledge valuable.

---------- Post added at 10:21 PM ---------- Previous post was at 10:18 PM ----------

Any experiences with the OnePlus One?
[General Omni Discussion] Lanchon:
hi and sorry for the absence

this evening i kicked off my build bot and now im uploading kernels here:

https://www.androidfilehost.com/?w=files&flid=22854

but first thing's first, the source patches are there too. my changes are extremely simple, but i did them over MG8 and unfortunately they depend on it. i guess it'd be trivial to rebase them on the standard kernels but i don't see the point since the MG8 changes are welcome anyway. i won't do it but you can.

the now unused hardware state tracking machinery could be disabled and optimized away, but i don't know the kernel and i don't want to risk introducing a bug. there are even a couple of assembler instructions i could've eliminated around my edit, but since i don't know a word of arm assembler i chose not to make any unnecessary changes that could have unexpected side effects; unexpected for me at least.

---------- Post added at 05:49 AM ---------- Previous post was at 05:27 AM ----------

but i did that already. it's here:

http://xdaforums.com/showpost.php?p=57577303&postcount=775
[General Omni Discussion] notabenem:
For clarification for the unaware: what is MG8?
[General Omni Discussion] Lanchon:
lol, this:

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

http://xdaforums.com/showthread.php?p=57577303
[General Omni Discussion] notabenem:
Me looking like an idiot. And maybe I am, because I've read all those posts. So for Omni, one would have to take all your patches on top of CM-M12-Snapshot, and replay/port them to Omni kernel. Right?
[General Omni Discussion] j1gga84:
So this patch must be implemented in kernels (if you use others than this one) and NOT in ROM, correct?

regards
[General Omni Discussion] AndDiSa:
[MENTION=4141005]Lanchon[/MENTION] looks very good so far. I merged your patch with my cm-kernel and no vfp bug so far . Thank you very much for your fantastic work!
[General Omni Discussion] zeitferne:
A kernel is a part of every ROM.
[General Omni Discussion] Lanchon:
sorry i was half asleep last night and in the end never said anything useful! :(

it'd be best to find out why the state reload optimization is failing and fix it instead of disabling it. and disabling it has a small performance impact. even so, i think that we should get this merged into cm, omni, etc asap.

to do that:

1) test for a couple of days obviously

2) use FPBug1/2/4 to verify that 4412 devices running cm or omni are really not affected. anyone with and S3 or Note 2 (international) could do it.

3) assuming that 4412s are not affected, we should disable the optimization conditionally to the soc being 4210.

if we just apply the patch as is we would be disabling the optimization for all, 4412 included. the patch includes 8 merges from mainline and those should be ok on both socs. but my change should be conditional and right now isn't.

4) we should probably also test the resulting kernel on a 4412 device at least once.

so as it is, this is not ready to be merged IMO.

---------- Post added at 11:22 AM ---------- Previous post was at 11:18 AM ----------

yes, affects kernel only

i think it's too early to merge!

both of you please read my last post :)

EDIT: i mean this one!! jeez do i hate XDA's auto-merging of posts!
[General Omni Discussion] Acid0057:
Well thank you for all your hard work lanchon and the testers! Glad we're so close to a final kernel fix.

Once it's finalized are you planning on adding it to your trim kernel lanchon?

Sent from my GT-I9100 flowing on SwiftKey in Tapatalk
[General Omni Discussion] Lanchon:
of course! i can do that now since those kernels are 4210-only.
[General Omni Discussion] zeitferne:
I already have a suspect again: CONFIG_CPU_PM, which was introduced by ab10023e and is used by the vfp module in 746a9d196 seems not to be enabled, and I also don't know how to enable it: Although both SUSPEND and CPU_IDLE are enabled, make menuconfig does not show it in the menu (if you search for it it displays it with =n), and when I enable it by editing the config file manually, make menuconfig simply erases the line again. It's also not defined in KERNEL_OBJ/include/generated/autoconf.h and KERNEL_OBJ/kernel/cpu_pm.o is missing.

What is more, I don't see that the newly defined notifiers being called from anywhere. Are we missing (architecture specific?) commits that actually call them?

EDIT: Ahahahaha! https://github.com/torvalds/linux/commits/746a9d1963f1c7a3cd22662065d7dcd3d93ee62e

EDIT2: Ok, the calls are there (I suppose), implemented with core_initcall. But there are indeed two important commits missing (especially the second looks absolutely vital):

6f3eaec8: cpu_pm: call notifiers during suspend

1fb90263: ARM: Enable CPU_PM notifiers on ARM machines.

EDIT3: Still did not do the trick.