yashsingh1/xdaforums huggingface dataset:
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
function sraPrint()
{
su -c dmesg > /sdcard/dmesg.out
echo "Head of kernel log:"
head -n3 /sdcard/dmesg.out
echo "Head of resume action:"
firstLine=$(grep "msm_pcie_enable: RC0: entry" /sdcard/dmesg.out | head -n1)
echo ${firstLine}
echo "Tail of resume action:"
grep "msm_pcie_enable: RC0: entry" /sdcard/dmesg.out | tail -n1
echo "Tail of kernel log:"
tail -n3 /sdcard/dmesg.out
lastLine=$(tail -n2 /sdcard/dmesg.out | head -n1)
printf "\n"
echo "All resume action with cause:"
egrep "Resume caused by|msm_pcie_enable: RC0: entry" /sdcard/dmesg.out
echo "Recent suspend abortion reasons:"
grep "active wakeup source:" /sdcard/dmesg.out
echo "DHD host wake interrupt count: $(grep \"msmgpio 122\" /proc/interrupts | awk '{print $2}')"
echo "DHD wakes in current dmesg: $(grep \"Resume caused by msmgpio-122\" /sdcard/dmesg.out | wc -l)"
echo "DHD host wakes:"
grep dhdpcie_host_wake /sdcard/dmesg.out

grep -i dtim /sdcard/dmesg.out | tail -n5

# get the count per sec
start=$(echo ${firstLine} | sed -ne "s:^\[\([0-9. ]*\)\] \(.*\):\1:gp")
count=$(grep "msm_pcie_enable: RC0: entry" /sdcard/dmesg.out | wc -l)
if [[ -n "${start}" ]] && [[ ${count} -ne 0 ]]
then
start=${start#[ ]*}
start=${start%.*}
end=$(echo ${lastLine} | sed -ne "s:^\[\([0-9. ]*\)\] \(.*\):\1:gp")
end=${end#[ ]*}
end=${end%.*}
echo "Seconds per wake since first wake: $(((end-start)/count)), with end=${end}, start=${start}, count=${count}"
fi
}
[HTC 10 Guides, News, & Discussion] devsk:
Do you have the 'wc' output also? There were 3 commands in there. From the output, it looks like its not as often as 1 second that I see. So, we have something here. Note that suspend resume will happen normally as packets arrive for wifi. Its the frequency with which the wakeups happen and for what reason, that matters.

I am sort of stumped by the syntax error you are getting in the script. Let me dig more.
[HTC 10 Guides, News, & Discussion] devsk:
Can you try commenting that 'awk' line out? like this:

# echo "DHD host wake interrupt count: $(grep "msmgpio 122" /proc/interrupts | awk '{print $2}')"

Basically, put a '#' in front of the line.

Also, remove the \ character you added before. I think that was not an issue.

What is interesting is that I don't see this issue...:(
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
Here you go. Uptime included as well.
[HTC 10 Guides, News, & Discussion] devsk:
Lets close this TMOUS update conversation, it is looking interesting. After that, I will update to 0.10 sources from flar and attach here.
[HTC 10 Guides, News, & Discussion] devsk:
Its about the same as before...:( Let's see if the script works this time without the 'awk' line. That output will be interesting.
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
Same error.
[HTC 10 Guides, News, & Discussion] devsk:
Darn! Let's remove that line, and try again one last time. This time, pls attach a screenshot of the run for me to see the commands and actual error.
[HTC 10 Guides, News, & Discussion] Haldi4803:
~.~ somehow when restoring a system image in TWRP I broke m Phone. Can't activate WiFi in Airplane Mode anymore :(

So first Test will be Standby drain with WiFi Off.
[HTC 10 Guides, News, & Discussion] devsk:
Let's try an attached file instead of copy&pasting the text...may be Windows is copying some weird characters (the line feed and carriage return characters are invisible) while copy&pasting and those characters are creating a problem in Linux. Please download the attached script and source.
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
Sorry, I had to go eat dinner. My guess is Chrome did something and I was planning on testing that theory by booting to a live CD but you posted that in the mean time.

To make sure I didn't have anymore issues, I used ES Downloader and then ES File Explorer to rename the script.

It didn't make a log but I attached a screenshot.
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
Can you run the uptime command? That's pretty insane...

I'm about to backup my boot.img and flash the test kernel and see what the result is with that.

Both the test kernel and the T-Mobile kernel have the same BCM driver so let's see the difference.

shell@htc_pmewl:/ $ md5sum /system/etc/firmware/fw_bcm4359.bin

md5sum /system/etc/firmware/fw_bcm4359.bin

fe486a7437473cbd8f895fbe25a224f0 /system/etc/firmware/fw_bcm4359.bin
[HTC 10 Guides, News, & Discussion] Johnny424:
I am reading and trying to catch up with this thread as quickly as I can. I am using the unlocked 10 on AT&T network

Is the Wi-Fi issue mainly causing wakelocks and battery drain issue for most?

Or are most having crappy Wi-Fi connection short distances from their router?

Or more like both connected, I have had the phone for less then 24 hours but I most definitely notice the funky Wi-Fi behavior inconsistent, speed and connection drop issues.

My phone is complete stock not rooted, s-on

Let me know if there's any logs that I can pull to help
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
I've attached the test and stock.

Test - 1:00:15 up time

T-Mobile 1.81.531.1 - 1:03:57 up time

I'm going to redo the T-Mobile result, it doesn't seem right... 4KB log vs 36KB?!
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
I've had both... My Note 5 held a signal all the way down to the basement and my 10 drops out in the kitchen... But the battery drain is the main concern.

There are tests throughout this thread, look at the last few posts.
[HTC 10 Guides, News, & Discussion] jollywhitefoot:
I have the latter but not the former. This thread is about the wakelocks
[HTC 10 Guides, News, & Discussion] Johnny424:
I will keep an eye on the battery, don't think 22 hours is enough reliable cycle data. But within the first few hours I noticed the **** for Wi-Fi signal for sure
[HTC 10 Guides, News, & Discussion] devsk:
Something is odd...in TMO one, there is never a single suspend aborted. Leave it to idle for 30 mins at least to engage all kinds of action.
[HTC 10 Guides, News, & Discussion] devsk:
Note to self: never ask people to cut&paste text into a shell script over the net. Windows and Mac do things with end of line character which Linux does not like.

Thanks for persisting...:) You are as stubborn as I am.
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
I just left it for an hour. Results attached with uptime right after to show you. This is a very clean kernel compared to the noisy ones in the past.

Lol. I'm stubborn, persistent, and a problem solver. Its even in my astrology lol.
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
That was after I rebooted, installed your fix again, then rebooted again and restored the boot image to make sure it wasn't something funky. This T-Mobile kernel is doing something very differently compared to all past kernels.

I am also very methodical in my testing. Both of them were tested in the same spot, both of them running after a fresh boot, both of them plugged in and charged so I could immediately go to adb shell and run the script and both of them very close in total time (its brutal not to touch my phone for hours by the way!). Same router, same network on the router, its as close to ideal conditions as I could get.

---------- Post added at 11:40 PM ---------- Previous post was at 11:14 PM ----------

I'm going to have to do this one more time. It wasn't catching anything because I didn't set the path. *facepalm* Soooo... back in an hour. Maybe editing the first post to give a link to your patched kernel and then adding in the info on how to do this test would be helpful. The reason the path didn't set? I copied all four lines from Chrome which is also why it never output anything. It has to be either manually typed or copied line by line exactly. Either vB or Chrome are adding characters that are messing it up even if it looks like the commands are being applied. I did a quick test with copying just the PATH line and it showed the wakes. Moral of the story: Type everything by hand!
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
Nope... Here's the whole thing. Every command in the log. Its still nothing compared to the previous kernels.
[HTC 10 Guides, News, & Discussion] INDIAN-MAfIA:
Here
[HTC 10 Guides, News, & Discussion] Haldi4803:
Woahwoahwoah stop right there....

What just happened?

I made a short Siesta on my Couch, and it didn't drain any WiFi?

Simply by being connected to the WiFi from the Devolo Powerline Adapter and not my Router!

I know what you're gonna say now "But look at the mobile Network, of course it drains more." Well nope I've had WiFi Off mobile only, no simcard, and it drained 1% in 2 hours, and that was with 5 minutes SoT included!

Advanced Testing inc....
[HTC 10 Guides, News, & Discussion] Jump1ng:
With [MENTION=4684315]flar2[/MENTION] releasing 0.10 ElementalX will we get an updated version with the WIFI fix or not? I like that there is colour control in it so quite keen on getting it installed.
[HTC 10 Guides, News, & Discussion] Haldi4803:
That's the good one.

Grrr.... 200 Chars too long...

http://pastebin.com/n2dEresB
[HTC 10 Guides, News, & Discussion] devsk:
yes, later today.
[HTC 10 Guides, News, & Discussion] Genetic517:
Will this fix delay exchange push email? It's really the only notification I have that must come in on time. I'd love to use this fix
[HTC 10 Guides, News, & Discussion] devsk:
One of the problems with BBS output is percentage numbers are based on the time spent waiting for the wakelock, which is very misleading representation of how much battery is used during that wait, because one component of kernel can consume more battery in 1m than another in 1hr based on how much CPU spinning they do.

From your output:

Resume caused by pmic-0x0 0x61 0x1

This is the most common reason for wakeup. That's RTC alarm firing very often. So, once the wakeups by DHD oob are removed, the system is using very quick RTC based alarms to wake system up every few seconds. I need to track this timer in the kernel code and slow it down a bit. I am very sure if we can track this and fix it, it will help tremendously. Unless its a bad hardware generating spurious interrupts every so often, in which case, we will have no solution in kernel code but in the chip firmware.
[HTC 10 Guides, News, & Discussion] devsk:
Make sure this works properly with stock, because I have doubts about that with HTC 10, at least with the affected phones. Make sure mobile data is disabled when you do this experiment because if wifi goes bonkers, it will use the data interface to send/receive pkts if mobile data is ON.

In my testing, its unreliable already and the test fix does not affect it. But some people have reported otherwise. One thing to note is that this is a very complex problem with so many factors affecting it. So, its utmost important that you be methodical in testing what you need.
[HTC 10 Guides, News, & Discussion] Genetic517:
I currently have no delays with exchange. Do you know if flar is planning on releasing a version with and without the fix? [MENTION=4684315]flar2[/MENTION] ?
[HTC 10 Guides, News, & Discussion] grega_slo:
Please don`t incorporate this workaround in perfectly good kernel.

I don`t want delays on my skype or mail or whatever.
[HTC 10 Guides, News, & Discussion] devsk:
Do you have delays with the fix?

I am not pushing this change in Ex kernel until we completely have a handle on the situation. I think I understand it a bit better but there is a still some work that needs to happen. As you can see from the posts in this thread, this is a complex problem. It will take time.
[HTC 10 Guides, News, & Discussion] devsk:
In that case, you are well set to test the fix and repeat your experiment.

It will be good to get a good report output before you even attempt to install the test kernel. Can you please provide one for me? We need to see if we have this issue in your report.
[HTC 10 Guides, News, & Discussion] Haldi4803:
Okay... Switched from Devolo to Swisscom AP.

Battery Drain increased from 0.7% to 2.2%/h

http://pastebin.com/MRbVv2GB
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
Holy crap...

Check these shots and the log [MENTION=1416236]devsk[/MENTION]...

Here's the uptime... I think its safe to say its been addressed in the T-Mobile kernel...

root@htc_pmewl:/ # uptime

uptime

up time: 14:17:24, idle time: 04:53:33, sleep time: 12:50:02

I turned it on and went to power and it said I had 8 days (!) remaining!
[HTC 10 Guides, News, & Discussion] Haldi4803:
That's why i like the Battery Historian, but that thing is not really a Help right now -.-

A: Most energy is unaccounted -.-

B: Stuff that happens often doesn't happen for long....

C: Kernel Wakelocks are unknown:
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
You can also take screenshots of the BBS CPU page.
[HTC 10 Guides, News, & Discussion] Haldi4803:
Not necesary as this is also in Battery Historian :)

Sorted by User time?

Or System Time?
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
No, you want to see the time it spent in each individual state. Look at my CPU screenshot. 94% was in deep sleep, 4% was at 307MHz. That leaves 2% in other states on a phone that was mostly idle for the whole 13 hours. If you have an idle phone pegging higher CPU clocks, its going to drain the battery faster and those are what you want to eliminate.
[HTC 10 Guides, News, & Discussion] Haldi4803:
BBS only shows the small clusters ;) therefore it's useless.

Another problem is stats of the big cores get reset every time the phone enters Deep sleep.

So it's impossible to get accurate stats.
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
It's better than nothing. Your drain is absolutely unreal. Generally speaking, the little cores are going to be the ones used during wakelocks anyway.
[HTC 10 Guides, News, & Discussion] devsk:
So, the log was taken immediately after waking the device from an extended sleep? The reason I ask is because of no suspend aborts recorded in the recent dmesg output on that phone at all. That's only possible if the output was taken when the phone's screen was on for a while (few mins is all it takes for kernel log to be overwritten, particularly when HTC has enabled all kinds of excessive logging).

So, as hard as it is to leave the phone unused for 20-30 mins and then run the command, that's what we need to be sure. Also, make sure data is off before you turn the screen off.
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
I woke up and took the screenshots, then plugged it in and posted here. It wasn't on long enough to purge the log and of you look at the one I posted last night it only had one suspend abort in just over an hour.

That was with Wi-Fi on all night. Even just looking at the 0.6%/hr battery drain proves that this kernel almost eliminates the issue. I usually lose 20% in 8 hours...
[HTC 10 Guides, News, & Discussion] devsk:
Yeah. Another reason for suspend aborts missing is that the firmware and the kernel are doing the right thing and actually not aborting a suspend cycle, which is an extremely expensive operation. So, if you ran the command right after waking the phone, I think we finally have a kernel which is not aborting suspend cycles.

Also, just to be sure: wifi on, data off, wifi power optimization on, wifi always ON during sleep, sync enabled. These were the settings all night, right?

I wish you had given me an output from before you updated to TMO firmware...:) That way we could declare victory for sure. But this is a very good lead.
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
I always leave 4G data set to pick up if Wi-Fi is dropped but it was connected to my router all night. Not a single KB was used on the mobile network. All other settings as described.

As far as reporting before, I did, just not the thorough output because the computer was down but with the huge drain I had, it would have been obvious what that log was full of.
[HTC 10 Guides, News, & Discussion] devsk:
[MENTION=3056043]Haldi4803[/MENTION]: I took your 2 outputs and ran some analysis on them. You have 2 routers, one advertising DTIM of 1 and the other DTIM of 3. But you have sort of mixed them up a bit.

As expected, DTIM 3 is better than DTIM 1 because it leads less beacon traffic. Also, these routers may be closer or far from the phone and/or transmitting with different power (dbm values in one spot will help).

But here is what the data tells us:

For some reason, there are long gaps of no activity in the dmesg for the good run with DTIM 3. So, the data is not super clean but it does show at high level that router settings can affect how often the phone wakes up or does not go to sleep because of router beacons.
[HTC 10 Guides, News, & Discussion] devsk:
Can you please post the whole 'dmesg' after leaving the phone idle for 15-20 mins? Just the dmesg output copied to a file like

dmesg > /sdcard/dmesg.txt

That will be very useful. I just want to be sure that this is a good kernel.

Also, you are using a router which is doing a DTIM of 3. That's interesting! Was this the same router that you got the drain with earlier without any settings changed?

I am sorry about all these questions and pokings...As you can tell, I am excited about this development and I want to be sure...:D
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
I can do that. Do you want me to dump my current dmesg with -c before I set the phone down so you get a clean log?

And yes it's the same router. Trendnet TEW-812DRU running on the AC network.
[HTC 10 Guides, News, & Discussion] devsk:
Yeah, resetting the buffer will help but I think in 15-20 mins, the buffer will recyle anyway. But yes, sure.
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
Here you go. I tried clearing it but based on the size I'm betting that didn't work.
[HTC 10 Guides, News, & Discussion] devsk:
Are you sure this is after setting the phone down for 15-20 mins? It has the beginning at:

$ head /tmp/dmesg_wifi_issue_fixed.txt
[15137.470197] c2 3389 PM: late suspend of devices complete after 8.739 msecs

and end at:

$ tail -n1 /tmp/dmesg_wifi_issue_fixed.txt
[15210.065431] c2 424 [TP]:Screen:F[01]:Up, X=1333, Y=2457, Wx=0, Wy=0, Z=0, IM=2, CIDIM=0, Freq=0, NS=1

That's just 15210-15137=73 seconds worth of dmesg.

Moreover, there are aborted suspends in this dmesg:

$ grep "active wakeup source:" /tmp/dmesg_wifi_issue_fixed.txt
[15139.664901] c3 3389 last active wakeup source: qpnp_fg_sanity_check
[15143.714194] c2 3389 active wakeup source: PowerManagerService.WakeLocks
[15145.625541] c2 3389 last active wakeup source: qpnp_fg_update_temp
[15146.033350] c2 3389 active wakeup source: wlan_rx_wake
[15169.513223] c1 3389 last active wakeup source: qpnp_fg_sanity_check
[15174.555191] c3 3389 last active wakeup source: qpnp_fg_sanity_check
[15179.642389] c2 3389 active wakeup source: event6
[15179.642513] c2 3389 active wakeup source: PowerManagerService.WakeLocks
[15179.642544] c2 3389 active wakeup source: KeyEvents

So, I am confused now! There is no consistency between your earlier data and current dmesg.

But your wakes are less often (1 every 4 seconds) and suspend aborts are (1 every 8 seconds), which are more expensive. Compare them to Haldi's data, and we can see its better. But its far from perfect.
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
Yeah I left the phone alone for 18 minutes. I don't know if it dumped the log later or what. This whole thing is baffling. I don't know what else I can contribute if the device isn't even being consistent. Maybe it really is just a damn hardware issue that doesn't always show itself?
[HTC 10 Guides, News, & Discussion] devsk:
ah...that's the TMO one that EtherealRemnant is using.

I think there is enough interaction between the kernel and the firmware, particularly with respect to this bug, that you will need to update everything.
[HTC 10 Guides, News, & Discussion] devsk:
We will know tomorrow morning if its a one off or actually fixed. Please wifi on, data off ...and so on tonight.
[HTC 10 Guides, News, & Discussion] devsk:
Looking at the 2 firmware zips from 1.81 TMO and 1.80 US Unlocked, the pmic-8996-1.img has an update in the TMO zip.

$ strings pmic-8996-1.img.1|tail -1
hTCVer 1.0.1-r01201.1-g0985ffb.135
$ strings pmic-8996-1.img|tail -1
hTCVer 1.0.1-r01201.1-g661021f.136

which may allude to the fact that HTC did do something regarding power management on the qcom chips in HTC 10. Whether that's the fix or not, we don't know but its looking promising.

One of the things I noticed in the dmesg from EtherealRemnant was that there were no spurious gic-xxx wakeups other than the desired ones (like DHD oob wake, fingerprinter wake and infrequent RTC alarm wakes). So, this is very promising!!
[HTC 10 Guides, News, & Discussion] DoctorB0NG:
Thanks for working on this, guys. It's much appreciated!
[HTC 10 Guides, News, & Discussion] Snah001:
While testing the new MaximusHD Rom for the -10- the overnight battery figures are ok.

With Wifi, LTe, BT and4 mail push accounts running it lost over 8 hours 0,4% per hour.

Used latest ElementalX kernel with PnP and Thermal tweaks from Ivicask added to it.
[HTC 10 Guides, News, & Discussion] Haldi4803:
Jep,

Kernel Alone doesn't do anything.

http://pastebin.com/fpMbZLLB

And all pics from BBS (with CPU ;) )

Yeah... Saw that file too....

Power Management of integrated circuit from sd820...

But as the T-Mobile Version has another Baseband I did not want to flash a Firmware.zip especially since my Taiwan 709 unit does not have an official ruu with Stock Software and I have no idea how to backup all these Partitions like aboot and stuff. :(
[HTC 10 Guides, News, & Discussion] _-..zKiLLA..-_:
This issue doesn't make any sense. Some days I can have basically no wlan wake issue (without leaving wifi off) and the next it can be the 2 to the top of the list. So sparatic >.<
[HTC 10 Guides, News, & Discussion] devsk:
[MENTION=609933]EtherealRemnant[/MENTION]: what does it show this morning?
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
Here ya go.

For some reason the script isn't showing interrupted suspends. And yes I dumped dmesg first then ran sraPrint since it dumps the dmesg file.

This is definitely the longest I've been able to get my phone to work on Wi-Fi though. It would have been totally dead with the old kernel by now.
[HTC 10 Guides, News, & Discussion] devsk:
What does BBS show? The report doesn't have any aborted suspends, which is good. It has wakes but only of the pcie bus and not the full system resumes, which is again good.
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
Here's my BBS. Lots of wake when it should be sleeping which is really nothing new, my Note5 did it too, and lots of wlan_rx_wake yet the battery life is still much better. Comparable to what I got with Wi-Fi off when screen is off.
[HTC 10 Guides, News, & Discussion] jollywhitefoot:
Almost 3.5 hours of wlan_rx_wake is insane.

I've been following this thread for a while and wondered if the RUU fixed the issue temporarily.

Also, is it possible a rogue or misconfigured app is causing the wlan wakes?

I think my posts show that I clearly have the profile of someone who should be experiencing wlan wakes but my battery stats look really good. I had hoped [MENTION=1416236]devsk[/MENTION] would have verified the logs that I posted, but I guess he had enough people to work with on the issue.

Anyway, I hope you guys figure this out. Let me know if I can help.
[HTC 10 Guides, News, & Discussion] EtherealRemnant:
Well I didn't have those wakes until I used Facebook Messenger yesterday and this game I play called Scatter Slots so I'm not sure that they're kernel problems but rather most likely app problems. Either way my battery life is almost on par with Wi-Fi on with the screen off which will save me data and could save me 15 bucks a month if it continues.

There's a script in the first post of the thread. If you want to help, run those commands and post the log :)