yashsingh1/xdaforums huggingface dataset:
[Nexus 6  Original Android Development] Franzie3:
[MENTION=3357040]Imoseyon[/MENTION] I had an issue today that im not sure was kernel related or not. Prior to 1.7 i was on 1.6 and had paired my bluetooth headphones (motorola sd-10) and everything worked fine. I flashed 1.7 yesterday and used them again this morning but the phone would not connect. I ended up deleting and repairing. Now then maybe 10 minutes into my morning work out at the gym the phone rebooted on its own. Came back after about 3 minutes and had no signal whatsoever. it took roughly 5 minutes to catch a singal but then had the exclamation point inside the signal bars. I rebooted again and all was fine. I did save a logcat from the app alogcat just after the phone rebooted on its on. My current setup is Pure Shamu 3.94 with LK1.7 and dt2w set to 1. no changes in vibration or anything else.

the logcat only gave me 1 line, not sure if it will help or not...
[Nexus 6  Original Android Development] Imoseyon:
Hmmm boy do I have questions for you :p

1) I've been watching the audit logs pretty closely and I haven't seen a single deny entry about this. What do the deny entries look like for this? Source process, source context, target context, etc.

2) What happens if you just set selinux to permissive mode?

3) What is the fix you used? Restorecon on the cpu sysfs files in ramdisk?
[Nexus 6  Original Android Development] Imoseyon:
Hmm you're right it didn't help. :) Can you try to pull a dmesg output next time? In fact, what's best is to pull all files from /sys/fs/pstore next time it reboots (immediately after it reboots). Also, please let me know if it happens again. thanks.
[Nexus 6  Original Android Development] Franzie3:
sorry bit noobish on it. how can i get you that info?? I'll def keep an eye on it, i found it odd to begin with.
[Nexus 6  Original Android Development] duffman452001:
Any chance you could add in an option to enable the charging LED?

EDIT: Nevermind I see it is already supported
[Nexus 6  Original Android Development] natezire71:
Do this in Terminal Emulator app:

su
dmesg >/mnt/sdcard/dmesg.txt
logcat -d -v time >/mnt/sdcard/logcat.txt

It will be stored in the root of your storage ("sdcard")
[Nexus 6  Original Android Development] sykopompos:
It actually doesn't show in the auditd, the only reason I know about it is because of the other nexus devices where it was added and I was looking around the file system and saw the contexts were wrong when I noticed funny errors randomly pop up in the dmesg so since I'm working on a couple apps and the file manager has a restorecon option, I restoreconed it and it changed to what it should be (matched my n4 and n5)

Permissive mode doesn't effect things if they are the wrong context. Permissive still runs in the confines of selinux so if something is not right, then it permissive will do nothing about it.

The change is simple, in your init it is one line, restore_recursive the CPU folder
[Nexus 6  Original Android Development] Imoseyon:
Hmmm so there's no way to reliably reproduce issue or even confirm that it's happening. What are some of the "funny errors" you see in dmesg? Before I make the change I'd love to see it in action and confirm the fix as well.
[Nexus 6  Original Android Development] sykopompos:
The biggest one I noticed was the CPU afline core IRQ errors and the changes in the logcat that things aren't running all on one thread

This is the same change on hammerhead

https://android-review.googlesource.com/#/c/101800/

You will find it on the other nexus devices also.

It happens to the whole CPU folder so I restorecon the whole cpufreq folder to account for other governors.

Note, this just fixes wrong context being thrown onto it and doesn't change anything other then setting it back to what it is supposed to be
[Nexus 6  Original Android Development] Imoseyon:
Interesting, hammerhead fix is only for ondemand but you're saying it happens to other governors too. The IRQ affine errors are not related to Selinux but perhaps there's a cause and effect due to hotplug issues. Let me take a look at this soon. We can move any further discussion to PM - thanks!
[Nexus 6  Original Android Development] sykopompos:
No problem and once I did the restorecon on that folder, they all went away here
[Nexus 6  Original Android Development] Yank555:
I wouldn't mind reading on, it sure is a development discussion ;)

JP.

Sent from my Nexus 6 running Yank555.lu SlimLP 5.0.2 LRX22G on Yank555.lu v0.43 kernel.
[Nexus 6  Original Android Development] Imoseyon:
Haha ok.

1) So far I did confirm that the file contexts for the governor sysfs nodes are indeed wrong.

What we want:

imoseyon@leankernel:/lk2/shamu/lk.ramdisk$ grep sysfs_devices file_contexts
/sys/devices/system/cpu(/.*)? u:object_r:sysfs_devices_system_cpu:s0

What we get after init:

root@shamu:/sys/devices/system/cpu/cpufreq # ls -Z
drwxr-xr-x root root u:object_r:sysfs:s0 interactive

2) You can fix this behavior by adding restorecon_recursive:

diff --git a/lk.ramdisk/init.shamu.power.rc b/lk.ramdisk/init.shamu.power.rc
index ba5bd35..ebc9da3 100755
--- a/lk.ramdisk/init.shamu.power.rc
+++ b/lk.ramdisk/init.shamu.power.rc
@@ -92,3 +92,5 @@ on property:dev.bootcomplete=1
write /sys/module/cpu_boost/parameters/input_boost_freq 1497600
write /sys/module/cpu_boost/parameters/input_boost_ms 40
write /dev/cpuctl/apps/cpu.notify_on_migrate 1
+
+ restorecon_recursive /sys/devices/system/cpu/cpufreq

root@shamu:/sys/devices/system/cpu/cpufreq # ls -Z
drwxr-xr-x root root u:object_r:sysfs_devices_system_cpu:s0 interactive

3) However the above did not get rid of the IRQ affine messages (at least for me). Which kinda makes sense since those messages themselves are benign in nature, IMO. But we should still fix the file contexts because it could potentially cause other issues.

4) However again, the restorecon_recursive fix in init does not really fix the issue if you change governor. When you change your governor, the kernel removes and recreates the sysfs nodes, and the wrong file contexts get set again. There are several different ways to address this - I'm looking into that.
[Nexus 6  Original Android Development] old_fart:
I just want to speak up and say the battery life is better for me. Thx !

.

Is the kernel ( in some way ) in charge of when the device takes a photo ? . I'll be in photo bug mode and I'll nick the volume rocker ever so slightly and wham ! . . . . I've got a severely out of focus shot of my pant leg . . . ( again )
[Nexus 6  Original Android Development] oak:
I try other kernels and they are quite good too, but I always come back to LK. The battery/performance can't be beat.... In my opinion.

It is good to have a Nexus, development is excellent.
[Nexus 6  Original Android Development] Imoseyon:
Hmm you mean when you take a photo using the volume rocker your focus is off? Sorry I cannot reproduce...
[Nexus 6  Original Android Development] Cy_n_ic:
Not a heavy use day for me today but 1.7 seems on par with what i would expect to be an outstanding cycle. Certainly no complaints
[Nexus 6  Original Android Development] mclisme:
Are all different types of gestures (DT2W, S2W) to wake the screen a hit'n'miss for other people as well? It only works 1 time out of 3, maybe 4. I look a bit ridiculous in front of others when I repeatedly swipe or double-tap a black screen and nothing happens :p I guess it's a Lollipop thing?
[Nexus 6  Original Android Development] old_fart:
It is my experience that when you're using the new and improved replacement code made by the kernel developers . . . it's double or triple better ! . Sounds like your settings are in-correct. . . Tell us how you see what they are and then how you've switched them.

And it's possible your old s/w is corrupting lk 1.7 ?
[Nexus 6  Original Android Development] mclisme:
Don't know what you mean by old s/w corrupting the kernel... I'm on stock 5.0.1 and I change the settings through lkconfig. I could make a video showing that DT2W is working 1/3 times and S2W almost doesn't work at all (unless I'm supposed to be swiping over a very specific area of the screen) but I just came across other people complaining about the same thing in other discussions. One even suggests it should be "triple-tap" for it to work properly. I don't say I've not messed up with flashing in the past but that's something pretty straight-forward. I flashed 1.7 over 1.6, no wipes. Was I supposed to do something more?
[Nexus 6  Original Android Development] warrenis1234:
+1
[Nexus 6  Original Android Development] old_fart:
I ( personally ) have had an old s/w install interfere with a new s/w install. I had a thermal regulator glitch that I only got rid of by doing a factory reset and reload all. *** Don't wipe internal memory *** But [MENTION=3110798]WugFresh[/MENTION]'s NRT made it easy.

.

This is a rapid tap, correct ? Yes, there are probable 'lots' of people than have made youtube videos on this subject already . . .

.

You're on stock 5.01 . hmm . I wonder if this tap improvement starts working ( needs ) the 5.02 fixes ? ? ? . I don't believe so.

Are you rooted with twrp ? A nandroid backup is a easy / piece_of_cake thing. . Then you can try a custom rom ? . Or [MENTION=426561]scrosler[/MENTION]'s rom ?

---------- Post added at 09:11 AM ---------- Previous post was at 09:02 AM ----------

I apologize for being confusing and making no sense . . . It's the sensitivity of the rocker ( for me ) . . . My hands, I have a light touch. I'm not a piano mover !
[Nexus 6  Original Android Development] mclisme:
I'm sorry but you don't make much sense and what you're telling me is all too general. "New code is better than the old", "Is this a rapid tap?", "maybe needs 5.0.2" I just wanted to hear from other leankernel's users that do actually use screen gestures for waking the device if it is working properly or not. ALso, what does a custom rom have to do with this issue?
[Nexus 6  Original Android Development] jjhiza:
I'm curious as to how you're trying to activate tap to wake. I've found that if you use the power button to turn the screen off, and lock the phone, double tap to wake works immediately afterwards. However, if you let the screen time out, and lock on its own (15, 30 seconds or whatever), you'll need to wait that specified amount of time - for the screen to lock - before tap to wake will operate properly. If you don't wait, then yes, it seems to require multiple taps before the feature will work.
[Nexus 6  Original Android Development] old_fart:
Yes, I actually use screen gestures for a couple weeks now and they work great . . .

No, I do not use the stock rom. Stopped using that one two months ago . . . I am currently using [MENTION=2906672]dsmitty166[/MENTION]'s euphoria rom with pa_Gapps.
[Nexus 6  Original Android Development] Cy_n_ic:
I use sweep2wake and have for quite awhile. It works just fine. I believe most issues stem from the users technique in attempt to make it work. Sit down for a while and learn how it responds best to your input. How hard and how fast to tap. Where to start a swipe and where to stop, again how much pressure to apply and how to do this comfortably and without thinking as to not look a fool in front of colleagues.
[Nexus 6  Original Android Development] mclisme:
All valid points. I've actually just tried a few scenarios and I found that every time it did not work was basically down to the tap being: a) too quick b) too slow c) immediately after the screen turning off. I think I got it in the end but it feels like the time window for the tap to work is narrower than in other devices I've had. I guess this is a good thing in that it's more difficult to wake by mistake. I'll practice some more.
[Nexus 6  Original Android Development] shelooga:
i only have the native double tap to wake enabled, and thats via the ROM (pure 3.94) not kernel, so perhaps my post is useless but i thought id chime in.

i find that it responds only under "ideal conditions"*

*meaning on a flat surface hitting the center of the screen; with the right duration between taps so long as theyre brief (under .5s by my fingers time) yields the appropriate response: screen on.

deviation from that (long taps, slight tilt of the phone because of its angularity, slight drag of my finger[be it perspiration, haste, laziness, drunkness, uncertainty which app .1 second ago i wanted]) causes me to have to double tap twice, or essentially uselessly but quicker-ly triple tap, or no response. sometimes ive tapped 5 times but it doesnt wake, but i can almost guarantee it was caused by sloppiness in the tap, or rocking of the phone. maybe the occasional wake delay (ive double tapped, got no response, double tapped, and my camera opens[this would be bc i have no lockscreen, and nova is set to double tap camera; ie 4 taps wakes the phone, then opes the camera. albeit under a delay])

i imagine if it were sensitive to pick up any form of every double tap, id never be able to lift it without the screen waking, which is why i think that it is pretty specifically calibrated for a mundane-not always convenient style of double tap

hope this helps, but it probably just hurt
[Nexus 6  Original Android Development] old_fart:
I agree with you that the 'sweep' up or down of the finger is better and more reliable that the tap method. . I believe I read where one of the senior developers admitted that the sweep is his preferred way.
[Nexus 6  Original Android Development] Imoseyon:
Hmmm I don't use gesture control myself so I'm not familiar with the issue being described.

But if I were to guess? Perhaps the phone is in deeper sleep state and an extra effort may be needed to wake up the screen. If so that's preferred, otherwise you'd be seeing some battery drain. :)
[Nexus 6  Original Android Development] franciscofranco:
Do you think this sensor_ind wakeup that we're seeing is caused by wrong selinux context/domain on the sensors? I can't seem to find that wakelock anywhere. If you look at CM's sepolicy repo you'll see a bunch policies for sensors and location and what-not. The only way I can get rid of the lock on my device is to remove location permission from most of the apps because they seem to be stuck running some kind of location based operation and it gets stuck there. Even stopping sensors.qcom service the lock doesn't leave by any chance.

Care to chime in on this? I'm a noob with SELinux permission system, just guessing at this point.
[Nexus 6  Original Android Development] Imoseyon:
Hmm are you sure sensors_ind is a problem? I don't see it often in my top 10 wakeup sources, and when it shows up it take up very little time. I just checked and it woke up once in the last hour for less than 0.5 millisecond. I doubt it's an selinux issue though but i'll keep an eye on it.
[Nexus 6  Original Android Development] franciscofranco:
It's random, I didn't have it the first 2 weeks of having the N6, then it showed up, then it doesn't happen for a couple days, then it's back. You can see it being reported everywhere from users with 100% stock devices. When I had the lock I checked the processes that were consuming more load and sensors.qcom was up there. It doesn't show up otherwise.

About CPU-Boost and ondemand/conservative, there seems to be a race when accessing the policy when CPU-Boost is removing the boost from a thread migration while the governor is accessing the current policy (if the policy is the same on CPU-Boost and the governor eg. CPU3 on both). Is this what you saw when you before disabling CPU-Boost? There seem to be a couple patches upstream that fix a couple races, otherwise I'm not seeing how we can block the concurrent access (if I'm correct). Any idea?
[Nexus 6  Original Android Development] Imoseyon:
Yeah I've been trying to catch it in the act a bit but I haven't seen it yet. Sensor_ind wake source is not in the kernel - it's in /lib/hw/sensors.msm8084.so. I probably won't spend much more time on it. I think it's based on your usage, especially since it's coming from a ROM component.
[Nexus 6  Original Android Development] wrongway213:
So if Franco is calling himself a noob, consider me an infant:

Does this mean that the kernel we are using and the settings we apply to said kernel should not cause sensor_ind wakelock, or alleviate it either for that matter?

Edit: To clarify, I understand the wakelock is not caused by the kernel. I am just trying to confirm that what you're saying is that nothing that would be done to fix it would be on the kernel side of things is all.
[Nexus 6  Original Android Development] Imoseyon:
Well your custom kernel can still kill any wake source if it wants to. One way (although rather drastic), is for the kernel to inspect the name of the wake source and prevent it from being activated altogether. I would not recommend that method, unless you know for sure what impact that will have on your device and how it runs.
[Nexus 6  Original Android Development] franciscofranco:
Uh, can we kill it without a direct reference to the wakeup_source?
[Nexus 6  Original Android Development] doitright:
This really *is* crazy. But this isn't necessarily a fault with the hardware. Qualcomm seems to have a problem with finding intelligent coders for writing the kernel side of a lot of this. I came across some interesting stuff in looking for the cause;

http://xdaforums.com/showpost.php?p=50636931&postcount=633

"Bugfixes and a major speedup for the hardware random number generator driver"

The code he is referring to is https://github.com/DecimalMan/dkp/commits/dkp-3.4_4.4?page=66

... bunch of stuff he committed on Feb. 25, 2014. I don't know exactly where the code is from, the author is set to DecimalMan himself, did he write it?

We are expecting rng and crypto hardware to perform faster than any software implementation possibly could be. Not an unreasonable expectation, unless you put moron code in the middle that loads the CPU more than just doing the work in software.
[Nexus 6  Original Android Development] Smallsmx3:
Would switching to f2fs be better for n6?
[Nexus 6  Original Android Development] doitright:
No. This would be pointless and a bad idea in general.
[Nexus 6  Original Android Development] warrenis1234:
I'm so happy this conversation is really happening right now lol
[Nexus 6  Original Android Development] sykopompos:
Actually I have been chasing that bug for the past week with location and have it clear in my logcats.

It seems there is a bug with Qualcomm qmi-fw and permission is not getting granted to it.

I can post up the log if you guys want to see the exact logging but I believe it is ROM related.

I got a don't audit sepolicy running right now and the only hidden denial I found was a netd one

edit: logs

logcat on my frank rom, you can see the qmi spam (userdebug build)

http://pastebin.com/RedNWkXE

dmesg on stock kernel

http://pastebin.com/rQEmXkrf
[Nexus 6  Original Android Development] Imoseyon:
Oh hey I missed this. I worked on this really early while leankernel is still in beta so my memory on this is hazy. There may have been some sort of race condition, but the strange thing was that it does not induce a kernel panic. Disabling CPU-Boost definitely prevents those reboots for ondemand (dunno about conservative). In my kernel, if you choose ondemand cpu-boost automatically gets disabled. I think I may have tried a few updates from CAF or even tried to fix cpu-boost myself to no avail.

If I understand what you're saying, no I don't think so. This wakeup source does not originate from kernel.

Holy crap this guy wrote a lot of code and seems to be very familiar with cryptography. I know there are at least a few regular CAF contributors that are active on XDA (one of them even reached out to me).... As for hw_random, again I worked on this a while back but IIRC, hw_random doesn't get used much at all by default, so return on investment on that is low, IMO. I did do a bunch of random work in leankernel which should have some return on investment.

BTW, hw_random being slow goes way way back, and not necessarily specific to qualcomm: http://www.redhat.com/archives/rhl-devel-list/2004-August/msg00770.html

There is definitely a netd selinux problem, which was corrected in my ramdisk a while back. Source: netd, target: capability, permission: fsetid. I don't know if that is related to your qmi issue or not...

One of the first things I did when I first got my N6 was to convert /data to f2fs (manually painfully since there was no recovery support). I ran it that way for a day or so and ran some benchmarks. I didn't see any performance boost over ext4.
[Nexus 6  Original Android Development] franciscofranco:
Conservative and Ondemand share the same code path (cpufreq_governor.c). I picked these two today:

https://github.com/torvalds/linux/commit/6f1e4efd882eccca10bac45b77e14bcb4979dc54

https://github.com/torvalds/linux/commit/c5450db85b828d0c46ac8fc570fb8a51bf07ac40

I don't think disabling CPU-Boost altogether is a good idea.
[Nexus 6  Original Android Development] sykopompos:
That's the one that popped up while running the don't audit (you gotta be careful with hidden denials because some just look at different methods)

The qmi though is related to the GPS though so I gotta keep hunting that. I brought it up for the mention of the location bug though
[Nexus 6  Original Android Development] Imoseyon:
Ah I don't think I've seen those. I will take a look at them. Actually disabling cpu-boost in itself doesn't hurt. In fact, a lot of my leankernel users disable it across the board, and quite happy so by doing it.. By default it's enabled for all governors though, except for on-demand.

There should be a way to log those hidden denials within kernel - let me try to spend some time on that.
[Nexus 6  Original Android Development] sykopompos:
http://seandroid.bitbucket.org/AddressingHiddenDenials.html

That's how you do a don't audit kernel for finding those denials and is what I am running right now and only that netd one was the one that showed up so I need to dig around a bit more. Straight up permission denied normally isn't selinux but a missing etc/permissions XML to give it permission so I'm gonna look at that
[Nexus 6  Original Android Development] Imoseyon:
I actually made a quick kernel change to log dontaudit deny messages in dmesg. I might keep it this way for a while to catch all of them. :)

edit: already seeing a crap ton of denies
[Nexus 6  Original Android Development] andyx1985:
Hi,

I've noticed a bug that happens on this kernel and a few others. When launching some games in particular dragon quest 3. The system cannot mount the encrypted obb file. It gives me obbstatecode:21. This does not happen with stock which is why I'm surprised it happens on your kernel. Which is pretty much stock.
[Nexus 6  Original Android Development] Imoseyon:
Aside from some unusual selinux deny messages (which seem unrelated to your problem), I don't see anything interesting in dmesg. How about pull logcat when this happens?
[Nexus 6  Original Android Development] sykopompos:
Anything good? I fell asleep for a few hours
[Nexus 6  Original Android Development] inffy:
[MENTION=3357040]Imoseyon[/MENTION]

it seems CyanogenMOD has changed something in their newest commits as it seems that if user flashes a custom kernel CMs new theme manager will not open anymore and will only give FC errors.

Any idea what could be causing this?
[Nexus 6  Original Android Development] Mistertac:
Thought I read somewhere on Google+ that it will FC through the Settings menu but it works just fine through the app drawer?!

I haven't a clue myself I'm not on a ROM with Theme Chooser myself.

I'm sure you know more than I do anyways [emoji6]
[Nexus 6  Original Android Development] inffy:
FC also from the app drawer.
[Nexus 6  Original Android Development] Mistertac:
Well like I said... I figured you were on top of it just thought I'd mention that is all.
[Nexus 6  Original Android Development] sykopompos:
A ton of selinux changes for the theme manager and the services that it runs is what is causing that