Hi.
Thanks for the feedback. This is very weird and I can't explain why this would be. The only difference between v4.0a and v4.0b is that I reverted 2 commits. Both related to HZ and both with very small changes code wise. There should be no reason for this issue. So I'm at a loss.
nope. never had.
Understood,I have chosen a rather strange way of releasing builds. I commit and push all changes to the main "1.6_OC" repo (which is exactly the same as the 1500MHZ version minus the OC) Then choose changes that I feel are large enough to warrant a test build and release these. I have however started to create local branches for v4.0 and what will be v5.0 (which is the latest test version 4.0b) I will push these to my git and share the links in this post in a few. This should give some idea of my changes per build and perhaps help others with figuring out some issues.
Thanks,that is possible I suppose. I'm not real sure. I just don't know why this issue now. I will look over my commits and try to see. Also,strange that some had no reboot issues with v4.0a and some did. Also strange,but oh well.nope. never had.
If I remeber right the issue with "no data connection" and "no or unknown signal" first occured after you introduced "TCP congestions" (2.0) and was gone after you "Added the rest of the TCP congestions" (3.0). I only mention these TCP related changes because "no data connection" and "no or unknown signal" sounds like a network related problem.
I am very interested in what kind of settings you have if you manage to get 4 days out of a charge
i use greenify and ds battery saver and get 2 days max.
So strange how this issue doesn't effect everyone. This makes it more difficult to track down. I never had any reboots,well maybe 1 or 2 in months of using different versions of this kernel,until the last test version (4.0a). Since I reverted the HZ related commits I haven't had one in 2 days. Its just strange. Some obviously have had no issues,reboot wise,with any version,so I just don't know. I can't imagine that it's RR related. I know Oleggluk uses RR and while I haven't heard from him in a bit,he hasn't reported reboot issues to me. I will continue to try to look into this.
No, 4.0 worked fine. I only had really few random reboots, maybe one or two in total.. 4.0a and b crash after less than 5 minutes of use, in perticular when screen is locked for about 30 secs
OK,thank you. I'll have a look at the changes I've made since the last "official" release on here and see if anything jumps out at me that could perhaps be the cause. I'm still thinking something suspend related judging by the reboots occurring mostly with the screen off.
Wifi and/or mobile data only active when I need them (e.g. surfing the net).I am very interested in what kind of settings you have if you manage to get 4 days out of a charge
Anything but "deep sleep" should be on a low value (~5% max.).
I also had no reboots with v4.0b for now. But I also noticed higher battery drain with newest version.
Thanks a lot for the feedback guys. It's very appreciated! I also have not had a reboot with v4.0b. So even if the 2 commits relating to HZ that I reverted are not fully to blame,they were definitely a big part of the problem. No clue why battery drain would be higher. I will have a look when I have some time.
Wow. Core test v4b = 23.1 MB (24,257,091 bytes)
Hah,nope,but apparently I did. The only reason it would be that size is because I zipped up something else with v4.0b. More then likely another kernel zip. OopsWow. Core test v4b = 23.1 MB (24,257,091 bytes)
The core V5 = 10.0 MB (10,547,814 bytes)
Did I miss something?
Here are my logs. I'm on Selinux enforcing, does that make a difference?
Very strange. Again.thanks for the log. It is really appreciated. There is nothing at all there however that would explain this. If you are able to get the last kernel log after this happens it may be more helpful. I posted how to do this a few pages back in this thread. I don't see why SELinux set to enforcing would matter,but who knows. I can easily build and enforcing kernel to test this.Unfortunately, my phone still crashes seconds after locking the screen - even with v5.0
