[Bug report] Music player stops playing music from sd after some time

[cdrivex4]

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

[/COLOR]i'm still waiting for these answers....

[/COLOR]

yes it is, very. STD is just a standard CM kenrel. any chance you might be confusing it with V1?



you also had trouble with STD? or only with V1?
​

[/QUOTE]

Yes I did, at least I think I did see below.

Renamed the kernels 001-004 each required three screenshots in total...

installed kernel..let it boot, let the cpu calm down a bit, ran apk..turned off screen though on some of them the error came up even before turning off the screen...3 screenshots..reboot nxt kernel till end.

Only used Fpbug2.apk

So 001a,b,c - 004a,b,c for the last released kernel..

Hope it helps a bit, took great care to ensure pictures are in order.

sent from my gt-i9100

 

[Lanchon]

installed kernel..let it boot, let the cpu calm down a bit, ran apk..turned off screen though on some of them the error came up even before turning off the screen...3 screenshots..reboot nxt kernel till end.

thanks a lot! unfortunately you are still not telling me the only thing i wanted to know lol!! which is this

which kernel(s) failed with the screen on?

(someone said STD but that *must* be wrong)

 

[notabenem]

I'm pretty sure there is some additional Android specific magic going on when you turn off/on the screen, e.g. wakelocks, early/late suspend/resume.

AFAIK, one of the big differences between 2.3.x and 4.0.x was that Android 4 used OpenGL to compose the windows/layers. Gingerbread used plain 2d canvas. So one of the theories could also be, that this bug was there even in Gingerbread, but did not have chance to manifest itself, because the graphics were not used for regular work, only for games (and no Power Management kicked in while playing games).
But this is pure theory at this point.

 

[cdrivex4]

thanks a lot! unfortunately you are still not telling me the only thing i wanted to know lol!! which is this

which kernel(s) failed with the screen on?

(someone said STD but that *must* be wrong)

Nope not wrong..have done the following..
With screen on ( as in thumbing around to prevent sleep)
001 aka STD
002 aka V0
003 aka V1
004 aka V0X

All exhibit the previous error...u don't actually have to wait as long as 3 mins.... u really want more screenshots..

sent from my gt-i9100

 

[zeitferne]

With screen on ( as in thumbing around to prevent sleep)
All exhibit the previous error...u don't actually have to wait as long as 3 mins.... u really want more screenshots..

Have you changed any settings like the default CPU scheduler? Or do you use any "power saving" apps, wakelock killer, or something like that?
At least with the default kernel I was not able to reproduce the issue while the screen was on.

 

[cdrivex4]

Have you changed any settings like the default CPU scheduler? Or do you use any "power saving" apps, wakelock killer, or something like that?
At least with the default kernel I was not able to reproduce the issue while the screen was on.

Cpu scheduler ondemand, cfq, as per $aybe previous post bout graphic I have 16 bit transparency enabled.

Checking start up apps the only thing I have on is Cool Tools, greenify is installed but I turned that off as I seemed to have high battery usage.

Edit;
Didn't really think about it but there is clean master installed, but i don't have it autokill anything..prefer to choose what I kill..

Crap...plot thickens...I had greenify on it was set up to hibernate winamp and real racing 3 apps on screen off, so disabled greenify completely, rebooted an installed the STD kernel...low on juice at this point 20%...so I go back to bedroom plug in charger still waiting this time waiting longer....un plug the charger even though the screen is on...it displays the error the instant I un plug the cable.....repeating this by clearing app cache,force stop an run again within 6 seconds or so of removing the cable it errors...

Can someone else try this..its 0100hrs for me I think I'll turn in.

sent from my gt-i9100

 

[toroid]

hi,
I have n7000 with cyanogen mod 11-20141205-NIGHTLY-n7000, original kernel from the nightly

I get the bug everytime before 30s after screen off, pc plugged in, even in airplane mode.

 

[Entropy512]

I'm pretty sure there is some additional Android specific magic going on when you turn off/on the screen, e.g. wakelocks, early/late suspend/resume.

Yeah. I know historically, hotplug has often interfered with the sysfs online/offline logic in a way that causes them to often not work as expected. System load is fundamentally higher when the screen is on - vsync interrupts, etc. Lots of processes go to sleep when the screen turns off.

Most specifically, if you actually offlined CPU0 when the screen was on, you would've seen the system crash/go bat**** insane. I'm 95%+ positive it's impossible for the 4210 to offline core 0 without going into a complete system suspend state. (more specifically, the only times I've ever seen core 0 turned off when core 1 was on due to bad hotplugging logic was guaranteed to cause an unusable system...)

 

[notabenem]

Most specifically, if you actually offlined CPU0 when the screen was on, you would've seen the system crash/go bat**** insane. I'm 95%+ positive it's impossible for the 4210 to offline core 0 without going into a complete system suspend state. (more specifically, the only times I've ever seen core 0 turned off when core 1 was on due to bad hotplugging logic was guaranteed to cause an unusable system...)

Strange. When I go to Settings/Performance, I can see the clock freq of both CPUs. If I don't do anything on that screen, CPU1 often goes to "offline". While on that screen, if I execute the echo 0 > ... I see immediately CPU1 offline, but many times in a second it's back online, until it decides that it really does not have any work to do and goes offline.
Based on this observation I assumed that the echo command would turn off the CPU at least for a fragment of a second while Lanchon's test APK is running.

Evidence that my theory is correct. While running the bug detector (2 threads) I started an adb shell with the following script:

while :; do sleep 2; echo -n "FREQ1: "; cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq; echo -n "FREQ2: "; cat /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq;done

The output was the following (note: during these lines the screen was still on):

FREQ1: 1200000
FREQ2: 1200000
FREQ1: 200000
FREQ2: tmp-mksh: cat: /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq: No such file or directory
FREQ1: 200000
FREQ2: tmp-mksh: cat: /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq: No such file or directory
FREQ1: 200000
FREQ2: tmp-mksh: cat: /sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq: No such file or directory

I'd say hotplugging is happening even with the screen on. I am getting more and more confident, that the IRQ problems on offline CPU and such do not have much to do with our problem here (but it's good we have the commits to fix them).

Edit: I realized you're speaking about core0. The question is, on which CORE does the apk start.

 

[ajislav]

i'm still waiting for these answers....
.....
yes it is, very. STD is just a standard CM kenrel. any chance you might be confusing it with V1?

I am one of the guys who reported corruption with screenon., fpbug2
Yes it was the STD kernel but it might have been due other reasons (see * below)
I tried to reproduce the issue, but unsuccessfully.
I can confirm the issue exists with screenoff on all 3 initially posted kernels: STD, V0, V1 with fpbug2

* what I think was the sequence which lead to my seeing the error with screenon:
install STD kernel
check for bug with fpbug1
uninistall fpbug1 and install fpbug2
test for bug with fpbug2
.... something something
test for bug again with fpbug2 -> bingo
in other words, I did not reboot...

 

[Lanchon]

could someone please try to reproduce the bug on this CM11 kernel?

thank you!!

 

[ajislav]

Crap...plot thickens...I had greenify on it was set up to hibernate winamp and real racing 3 apps on screen off, so disabled greenify completely, rebooted an installed the STD kernel...low on juice at this point 20%...so I go back to bedroom plug in charger still waiting this time waiting longer....un plug the charger even though the screen is on...it displays the error the instant I un plug the cable.....repeating this by clearing app cache,force stop an run again within 6 seconds or so of removing the cable it errors...

Can someone else try this..its 0100hrs for me I think I'll turn in.

sent from my gt-i9100

I could not reproduce at first, but then it happened. Confirmed. Will test with the latest kernel and report back.

 

[ajislav]

MG8 kernel fpbug2 shortly after unplugging from charger

 

[Lanchon]

MG8 kernel fpbug2 shortly after unplugging from charger

thanks! no need to post those horrible numbers anymore, just knowing it fails is enough.

EDIT: actually, its useful to see that its the same kind of corruption. but it's enough with the first snapshot

 

[Lanchon]

MG8 has these mainline commits merged:
https://github.com/torvalds/linux/commit/f8f2a8522a88aacd62a310ce49e8dac530d1b403
https://github.com/torvalds/linux/commit/19dad35fe0f10df8f0524f98037469e3a0dd1ec2
https://github.com/torvalds/linux/commit/ab10023e0088d5075354afc7cb9e72304757dddd
https://github.com/torvalds/linux/commit/746a9d1963f1c7a3cd22662065d7dcd3d93ee62e
https://github.com/torvalds/linux/commit/2498814fcb3068f19b82b1519b4038721f61af43
https://github.com/torvalds/linux/commit/ff9a184cfb6542bef98aff1789481284e122a4b3
https://github.com/torvalds/linux/commit/56cb248428ead13a6b423ed3f3cf9e4aa01244b1
https://github.com/torvalds/linux/commit/384b38b66947b06999b3e39a596d4f2fb94f77e4

issues that can cause VFP corruption and should probably be merged in the kernel anyway. unfortunately they are not the cause of the corruption at hand.

 

[notabenem]

Lanchon, can you please change the apks so that at least one of the processes is forced to start on CPU1? I am trying to eliminate a simple context move between CPUs to be the cause of the corruption. The theory would be that for ajislav the processes start on CPU1 and get moved to CPU0 when he unplugs the charger.
I have tried to play with "busybox taskset -p 2 PID" but without much succcess. If CPU1 is offline, I can't set this mask. When it comes back online, all the processes have a CPU Mask of 3. At this pont it's possible to set mask "2", but I don't think it's effective. I've never seen CPU1 as the last processor this process ran on, based on the output of cat /proc/PID/stat.

In my case the corruption appears always "after a sleep of >10.000 us". Assuming this means the phone was in deep sleep during that time and got woken up by random alarm..

 

[Lanchon]

Lanchon, can you please change the apks so that at least one of the processes is forced to start on CPU1? I am trying to eliminate a simple context move between CPUs to be the cause of the corruption. The theory would be that for ajislav the processes start on CPU1 and get moved to CPU0 when he unplugs the charger.
I have tried to play with "busybox taskset -p 2 PID" but without much succcess. If CPU1 is offline, I can't set this mask. When it comes back online, all the processes have a CPU Mask of 3. At this pont it's possible to set mask "2", but I don't think it's effective. I've never seen CPU1 as the last processor this process ran on, based on the output of cat /proc/PID/stat.

In my case the corruption appears always "after a sleep of >10.000 us". Assuming this means the phone was in deep sleep during that time and got woken up by random alarm..

you can shell to your phone and start the native executable manually, check the sources.

 

[Lanchon]

could someone please try to reproduce the bug on this CM11 kernel?

FR has changes in MG8 plus workaround for possible context tracking issues

thank you!!

 

[zeitferne]

could someone please try to reproduce the bug on this CM11 kernel?

So far, I could not reproduce the issue with this kernel, even after a restart. But I won't become euphoric before others confirm

 

[notabenem]

could someone please try to reproduce the bug on this CM11 kernel?
FR has changes in MG8 plus workaround for possible context tracking issues

I must be doing something wrong. Flashed the kernel, but I am stuck at the boot animations screen (rest of the system is still Omni, no data-wipe)