[Bug report] Music player stops playing music from sd after some time
- Thread starter pilgrim011
- Start date
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?
So this patch must be implemented in kernels (if you use others than this one) and NOT in ROM, correct?
regards
regards
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 ----------
both of you please read my last post
EDIT: i mean this one!! jeez do i hate XDA's auto-merging of posts!
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!
Well thank you for all your hard work lanchon and the testers! Glad we're so close to a final kernel fix.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
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
of course! i can do that now since those kernels are 4210-only.
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.
Last edited:
We call that find7op - The maintainers for that device are a bit inexperienced (although we have one more experienced one involved with 5.0) but since it's only minimal changes from find7, it doesn't need that much maintainer experience. That said, most of our focus is on the find7 and not find7op, it just happens to be "easy" thanks to our find7 work.
Yeah, I may actually dust off my n7000 and evaluate the patches and put them on Gerrit this weekend for further review/testing/work.
Yes
Interesting, could be useful to look at. I don't think we have a final fix YET - but we're REALLY damn close thanks to you and Lanchon.
I just had the opportunity to run the FPBug app on stock 4.1.2 and Lanchon was right: the corruption does happens there. Interestingly, it even happens when the screen is on.
---------- Post added at 06:19 PM ---------- Previous post was at 05:51 PM ----------
Using this diff
I printed to kmsg whenever the optimization you commented out was made and it got flooded, so it seems that the optimized path is taken more often than (at least I) expected.
---------- Post added at 06:19 PM ---------- Previous post was at 05:51 PM ----------
Using this diff
Code:
diff --git a/arch/arm/vfp/vfphw.S b/arch/arm/vfp/vfphw.S
index 2d30c7f..6910383 100644
--- a/arch/arm/vfp/vfphw.S
+++ b/arch/arm/vfp/vfphw.S
@@ -43,6 +43,19 @@
#endif
.endm
+ .macro DBGSTR2, str, arg1, arg2
+ stmfd sp!, {r0-r3, ip, lr}
+ mov r2, \arg2
+ mov r1, \arg1
+ add r0, pc, #4
+ bl printk
+ b 1f
+ .asciz "<4>VFP: \str\n"
+ .balign 4
+1: ldmfd sp!, {r0-r3, ip, lr}
+
+ .endm
+
.macro DBGSTR3, str, arg1, arg2, arg3
#ifdef DEBUG
stmfd sp!, {r0-r3, ip, lr}
@@ -125,7 +138,12 @@ vfp_reload_hw:
@ last loaded onto.
ldr ip, [r10, #VFP_CPU]
teq ip, r11
- beq vfp_hw_state_valid
+ beq vfp_skip_reload_hw
+ b vfp_reload_hw
+
+vfp_skip_reload_hw:
+ DBGSTR2 "state already valid, state=%p, CPU=%u", r4, r11
+ b vfp_hw_state_valid
vfp_reload_hw:
@ We're loading this threads state into the VFP hardware. Updateat the point where the state load would normally be bypassed you can verify that the state in hardware actually matches the state in ram and detect would be corruption as it happens and without FPBugX.apk. to do this it's easiest to save current state to a new area and compare both saved states.
this doesn't help me cause i don't have a device but it might help your debugging
---------- Post added at 03:29 PM ---------- Previous post was at 02:47 PM ----------
i can't look at this now, but i got 2 complete n00b questions: what is stopping us from merging most of mainline? and is there a tool to do this, some GUI that eases the process? i just used git and manually solved the .rej files in the past
---------- Post added at 03:31 PM ---------- Previous post was at 03:29 PM ----------
btw, i broke the news to users with a bit of history, hopefully they'll bite
http://forum.xda-developers.com/gal...ernel-fpbug-stable-4-x-kernel-galaxy-t2978088
I normally use git cherry-pick or git merge, so git inserts conflict markers directly into the files. There is also git mergetool, for which you can use e.g. meld or kdiff3 (or vimdiff
) but personally, I find these tools confusing as I don't know which change comes from where in the three windows that are then shown. Also, AFAIK, Dorimanx' Kernel has more mainline commits integrated than CM/Omni.EDIT: The trick to use git merge and cherry-pick is to add the official linux kernel as a remote to the 4412 kernel.
But I'm not a git expert either.
Last edited:
Dorimanx has 3.12 (and maybe even beyond) kernel, but it wasn't updated for more than a year. Guess it won't work out-of-the-box for Omni. I am very interested in reviving this kernel (and maybe even more), because it's a suitable candidate to have the bluetooth implementation replaced to that of BlueZ (needs kernel >3.9). That in turn would bring the now very much missing L2CAP support -> the phone could act as a bluetooth HID for your PC and let you use wii remotes, etc.
I don't have the time right now for all of that, but I ran the test once with your cm11 FPBug kernel, and it seems like it's the best i9100 antutu score ever, or something like that
:Attachments
Last edited:
lolI don't have the time right now for all of that, but I ran the test once with your cm11 FPBug kernel, and it seems like it's the best i9100 antutu score ever, or something like that
almost beats my opo!
look you should be glad it even finished the test, ok?
DorimanX has had only "unofficial" builds during the period you mentioned. They work pretty well with Omni, I've been using the combination for as long as official Omni builds were available for the i9100.
Can't post screenshot nor thread link - ten posts limitation...
Last edited:
most recent build of dorimanx is by @Computoncio github (with 2 commits behind dorimanx's)
i think he started merging 3.15 couple months ago, a while after dorimanx started focusing on LG G2 kernel development
the unofficial thread is this way
Last edited:
Afte a lot of try & error I finally managed to read the s0 (lower? half of d0) register in assembler, and printed a message when they do not match (and forced reloading of the registers (even when the message is not printed)). I also added printks to the hotplug and cpu_pm notifiers (also merged the two commits I mentioned). Then I ran the FPBug detector and my message got printed far more often than I expected (it also got printed before a few times).
Here are all relevant files: the patches, the kmsg and also a translation from assembler to ("pseudo")-C of the vfp_support_entry procedure, that I manually made (read: may contain errors).
As soon as the screen is turned off, it seems that the FPU register values of CPU0 (!) always get clobbered between the invocation of the vfp_support_entries. Noob question: Do the cores have separate FPU registers?
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone