yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Android Development] kaiser_tytnii:
Re: [Kernel][GPL][anykernel][WIP] msm_hsic_host wakelock fix

Awesome kernel! Thanks for fixing something all those so call great dev couldn't solve!! Thanks!!!

The only thing that I could comment about against Franco kernel is the fact that this kernel drops faster on WiFi and screen on time drains faster than Franco, but hey stand by time on 3g is great!!!
[Nexus 4 Android Development] thracemerin:
Well, the performance should be like stock without the 3G related wake locks, so it's using mpdecision which is known to drain the battery much harder than auto hotplug which is the solution most of the kernel devs have gone to, if you're looking for a kernel with some of those battery features the latest motley experimental includes the changes for hsic wake locks from my repo.
[Nexus 4 Android Development] kaiser_tytnii:
Re: [Kernel][GPL][anykernel][WIP] msm_hsic_host wakelock fix

Thanks for your tip! I'm trying it out now as i type thanks!
[Nexus 4 Android Development] Harsh:
Re: [Kernel][GPL][anykernel][WIP] msm_hsic_host wakelock fix

I had this fixed since December end... So don't talk about devs.

Sent from my Nexus 4
[Nexus 4 Android Development] thracemerin:
Re: [Kernel][GPL][anykernel][WIP] msm_hsic_host wakelock fix

I never said you didn't, you were the one who found the magic formula of CAF patches that worked first.
[Nexus 4 Android Development] _motley:
Well, don't forget that the actual devs that fixed this particular problem are working directly with the hardware over at code aurora (Hemant Kumar, Pavankumar Kondeti, Ofir Cohen, Jack Pham etc.). This is a development source repo for Google and Qualcomm. The devs here, including me, are just merging in their precious changes after we find what works.

Thanks for your work on this guys, good work by Harsh for bringing in all the right patches to test and study. And good work by thracemerin for providing a stock+ model with the changes. Franco and faux have also been putting out alphas and betas with these commits and their threads have provided tremendous feedback on this subject. Good work to all, and thanks to Code Aurora for having their awesome git available for us to cherrypick from.

You know, as soon we have something like this fixed, the next version of the kernel from Google is sure to drop soon with the same fixes. Seem like that is how it goes LOL.
[Nexus 4 Android Development] thracemerin:
This is why I love Android and this community specifically, the open source nature allows all of us to work together (even if we aren't officially one big team) to solve the problems and make our devices better, if you don't like everything that's in someone's kernel you can make your own with the stuff you want. Its one of the reasons I can't understand being locked into an iPhone or Windows Phone and having to wait for Apple or Microsoft to get around to fixing things and making necessary improvements.
[Nexus 4 Android Development] Chochiwpg:
If you want it done right, do it yourself. Or there is probably someone very talented who has probably already done it and provided their service/fix to the community to take advantage. Sharing is caring is the best way I can describe Android. Love it and will never change for the competition. :good:
[Nexus 4 Android Development] DenyDarko:
With v6
[Nexus 4 Android Development] MotoRaph:
I checked v6 again and can say that it works good. The difference to v3 is that the notifications arrive later when it was sleeping for a longer time. Then i have to wait about 10 seconds which is of course ok.
[Nexus 4 Android Development] thracemerin:
I'm fairly sure that even under a perfect scenario there may be a little delay on the notifications, but as long as you actually get them while the phone is in deep sleep with the screen off, then you should be good :)
[Nexus 4 Android Development] thracemerin:
suspend_backoff may be completely unrelated, it may also be due to a lot of broadcast/multicast packets waking up your phone as it attempts to go back to sleep. Most likely repeated hits to the phone from broadcast and multicast packets, that's why this isn't a perfect fix. I would say that you would have the same results on the same network under the same conditions with either v6 or the CM stock with the modification.
[Nexus 4 Android Development] peterperfect:
thracemerin,

Do you plan to continue catching up to prima last version? I think they are on v3.2.3.104
[Nexus 4 Android Development] thracemerin:
At the moment it doesn't solve the problem, I built with v104 today and the bad MAC issue is still there so I see no point in releasing it. I am keeping up with developments on it though.
[Nexus 4 Android Development] markd0wn:
Question regarding a possible bypass (but nowhere near an actual solution)...

Would it be better in terms of battery life/speed of receiving notifications, to leave WiFi on in general, but, change the setting to 'never keep wifi on during sleep'? What exactly is the behavior in that scenario?

I'm guessing that as soon as the screen goes off - WiFi disables itself temporarily, phone then switches to mobile data, and once you wake the phone up/unlock, WiFi will quickly connect again?

If that is the case, and you have the play store set up to not update apps automatically (or only update via WiFi), that means that the mobile data will essentially be used only to receive notifications, and as soon as you turn the screen on, WiFi will kick in. Am I right in that assumption? If so, I'll consider just using the revert-to-stock-behavior-entirely zip, and just let it be on mobile data when I don't use the phone and go back to WiFi when I do -- I doubt a massive amount of mobile data will be consumed for notifications only...
[Nexus 4 Android Development] thracemerin:
Yeah, you could do as you suggest, this was one workaround that was suggested a long time ago ands it does solve the issue with delayed notifications.

I haven't noticed that v6 consumes a lot more battery than stock however.
[Nexus 4 Android Development] Zaldi00:
Which version is compatible with cm10.1?

************Nexus7 ***********
[Nexus 4 Android Development] tylercarter:
v6 is what you want. :highfive:
[Nexus 4 Android Development] thracemerin:
Looks like codeaurora pushed an interesting ARP related patch to the jb-mr2-dev branch and bumped the version to 3.2.2.6a, sadly I'm out of town a few days and have no access to my build boxes, so if anyone can and wants to build it to see, you can fork my jb-prima branch and replace the prima with the new version, if not I'll have a new build for you early next week. Since I can't build it I have no idea if it fixes our problems or not, but here's hoping.
[Nexus 4 Android Development] tylercarter:
*fingers crossed*
[Nexus 4 Android Development] markd0wn:
Wondering if we should get our hopes up... in simple english this basically sounds like "ARP offload didn't work when phone was sleeping, now it does" which sounds promising.
[Nexus 4 Android Development] thracemerin:
That's what it looks like to me too, but I won't know till I can test it.
[Nexus 4 Android Development] jpierce1987:
I'm running cyanogenmod 10.1 M3 and flashed the wifi fix version. Its much better than it was, but I'm still getting this wakelock quite a bit. I was getting around 2.5 hours of the wakelock, now its down to about 30 minutes or so... I noticed the other day that after a while it moved to "deletedwakelock" but its still draining my battery, just not as much. I'd like to help, what info do you need from my phone, and how do I get it?
[Nexus 4 Android Development] thracemerin:
PowerManagerService is the combined total of all your partial wakelocks which are all the apps that are keeping your phone awake, that's not completely out of the ordinary.

deletedwakelock happens when you have a WiFi related wakelock and then turn WiFi completely off.

Nothing in that screen shot points to a severe problem in my experience, it looks relatively normal to me.
[Nexus 4 Android Development] markd0wn:
In case somebody is interested:

- Default values in the new WCNSS_qcom_cfg.ini are:

gEnableSuspend=3

McastBcastFilter=3

hostArpOffload=1

- Values that have been removed (present in v6, removed in new .ini):

# Disable RSSI FW filtering

gEnableFWRssiMonitoring=0

#Configure the RSSI gap that will be used to partition/categorize width of each individual category (aka bucket).

gRssiCatGap=10

- Values that exist in both .ini's, but have been changed in the new .ini:

FastTransitionEnabled=1 (was set to 0 in v6's .ini)

gNeighborLookupThreshold=76 (was set to 60 in v6's .ini)

gNeighborReassocThreshold=81 (was set to 75 in v6's .ini)

FastRoamEnabled=1 (was set to 0 in v6's .ini)

RoamRssiDiff=3 (was set to 0 in v6's .ini)

And finally...

- New values (not present in v6's .ini, appears in new .ini):

# 802.11h support

g11hSupportEnabled=1

# Scan Timing Parameters

gPassiveMaxChannelTimeConc=110

gPassiveMinChannelTimeConc=60

gActiveMaxChannelTimeConc=27

gActiveMinChannelTimeConc=20

gRestTimeConc=100

gNumChanCombinedConc=1

# If the RSSI of any available candidate is better than currently associated AP by at least gImmediateRoamRssiDiff, then being to roam immediately (without registering for reassoc threshold).

# NOTE: Value of 0 means that we would register for reassoc threshold.

gImmediateRoamRssiDiff=10

#If set to 0, MCC is not allowed.

gEnableMCCMode=1

# 1=enable STBC; 0=disable STBC

gEnableRXSTBC=1

# Enable Active mode offload

gEnableActiveModeOffload=1

#Enable Scan Results Aging based on timer

#Timer value is in seconds

#If Set to 0 it will not enable the feature

gScanAgingTime=0

#Enable Power saving mechanism Based on Android Framework

#If set to 0 Driver internally control the Power saving mechanism

#If set to 1 Android Framwrok control the Power saving mechanism

isAndroidPsEn=0

#disable LDPC in STA mode if the AP is TXBF capable

gDisableLDPCWithTxbfAP=1
[Nexus 4 Android Development] thracemerin:
Yeah, but don't switch the values if you're running v6 because you need the patches that are associated with the new values or they may cause you more problems than good.

Especially the ARP offload stuff because the prima in v6 doesn't support ARP offload at all.
[Nexus 4 Android Development] markd0wn:
Yeah I was just comparing out of curiosity, wasn't planning on testing it without the actual new version. Waiting for a properly built new version with those changes.
[Nexus 4 Android Development] kszaq:
jb_mr2? That sounds like a JellyBean 4.3 on the way! :)

I'll merge the v3.2.2.6a and let you know how it works for me tomorrow.
[Nexus 4 Android Development] thracemerin:
They've been using the jb-mr2 branch for ages, same place that 3.2.2.2 came from, so I wouldn't read a version bump for android from it, but anything is possible.

If this fixes the bad MAC issue it would awesome though, so let me know :D
[Nexus 4 Android Development] kszaq:
I didn't notice that. Thank for the info!

I used gEnableSuspend=3, McastBcastFilter=3 and hostArpOffload=1 and the MAC issue is still present with v3.2.2.6a drivers. :(
[Nexus 4 Android Development] BlueFlame4:
Have you added all those new lines posted before to the .ini?

Sent from my Gameboy Color
[Nexus 4 Android Development] thracemerin:
Damn :(
[Nexus 4 Android Development] jpierce1987:
Ummm, thats interesting. My wifi stayed off, as I work out doors throughout the state, and don't have access to wifi. I had no wifi. I kept checking my battery stats to see if the kernel was working, and the msm_hsic wakelock kept rising.. It got up to around 33 minutes. I checked again shortly after that, and had 33 minutes of deletedwakelock and 1 minute of the msm_hsic_host wakelock... at least on my phone, msm and deletedwakelocks are just swapping places. I've never had deletedwakelocks on my phone, and now they are literally the same amount as the previously stored amount for the msm wakelock. even right now, i'm checking and its now 24 minutes of deletedwakelocks, and only 18s of msm_hsic... earlier when i checked, i had around 19 minutes of msm_hsic. I know my account makes me look like a noob, but i've been flashing phones for a long time now, and i'm keeping up with bbs. I'm having a legit issue here, and presented all the info i could, and told you that i would gladly upload anything else needed that could help figure out any bugs with this kernel that would be causing this wakelock to just be reclassified to deletedwakelocks. It is much much less now, though. On the stock CM kernel i had around 3 hours of the msm wakelock, now its down to around 30-40 minutes, so its much better... but I use only gsm data durring the week, no wifi at work and i work 16 hour days. Since a lot of people with this wakelock are using combined gsm/wifi, or some only using wifi, I can help track down the issue using only gsm data without wifi. I've understood that under wifi the issue has been fixed completely, its just the gsm data now causing issues... and thats all i use during the week.
[Nexus 4 Android Development] thracemerin:
msm_hsic_host is the bus controller for the 3G modem, what you are seeing is the time held during start up, data transfer, standby and then suspend, the process is not a short period especially if your 3G signal is not ideal as the data transfer takes longer. I've done pretty much everything I can to reduce this wake lock without causing issues with 3G data (stalls, hangs, lockups whatever people want to call them), there is little more that can be done in this regard without modifications to the baseband itself, and since that is closed source we have to wait for Google and LG to work those out.

As for why its switching between msm_hsic_host and deleted_wake_locks, I don't know, deleted_wake_locks is the catchall for wakelocks that the system no longer knows their source, like I said this generally happens when you have WiFi related wakelocks and then turn WiFi off since the host controller goes offline and the information about it is purged. I suppose this could happen on the msm_hsic bus as well, but I haven't personally seen it.
[Nexus 4 Android Development] jpierce1987:
Okay, thanks. Could have something to do with the service area I'm in, constant changes from 4g, edge and no service... I'm just going to try my hardest to ignore it for now... I'm going to be getting a new phone soon anyways...
[Nexus 4 Android Development] thracemerin:
The switch from 3G/4G to Edge might be causing the msm_hsic_host wakelocks to be recategorized as deleted_wake_lock because of the interface change. The wake lock can be further reduced by increasing time between syncs, removing apps that sync that you don't need, disabling Google now and location services if you don't need them, etc... anything that transfers data via mobile network will cause this, it happens on other devices too but the N4 is less efficient at handling it than some and its much easier to see it, on a lot of devices this stuff is hidden in other wakelocks that are less obvious. In general the 2 biggest drainers for most users on smart phones are screen and 3G/4G connectivity.

In your specific situation where its jumping between the various modes, this likely means that you have weak or very weak signal which means that even if it shows 3G or 4G the speed is probably very slow, it will also take longer for the phone to negotiate the tower connections and receive the tower pings and handoffs which will also increase your msm_hsic wakelock. Given this I'm not sure that another phone would solve the problem but it might, its more likely to be solved with a different provider that has better coverage in the areas you frequent most.
[Nexus 4 Android Development] thesebastian:
In general which network consumes more battery on the N4?

- 3G with latest modem.

- 4G with .33 modem.

I don't have 4G on my country :(
[Nexus 4 Android Development] thracemerin:
Well, the N4 doesn't have an optimized LTE antenna in it so I'd assume running LTE is probably harder on the battery than anything else, but I haven't done much testing.

Generally from most to least its:

4G/LTE

3G/HSPA

2G/Edge

WiFi

But a good 4G connection could burn less than a crappy 2G connection.
[Nexus 4 Android Development] Proda:
Hi,

A question:

I installed this fix a month ago. It was version v3 at that time.

Tested it with CM10.1 for a while, didn't notice any changes. Then I tried another kernel, and eventually wanted to back to CM10.1 again. So I did factory reset, clear cache, installed CM10.1 + gapps. And since then I did couple of nightly updates.

But do I still have this fix v3 included in my phone or not?

If I do have it, do I need to apply unfix.zip from this thread in order to have clean CM10.1?

Or should I just leave it and install v6. If there are some better results with it?

Thanks.

Sent from my Nexus 4
[Nexus 4 Android Development] thracemerin:
If you are on the stock CM kernel right now, all you need is v6, if you aren't, reflash the CM10.1 zip, then v6.
[Nexus 4 Android Development] thesebastian:
PRIMA project re-appeared.

There is a new ARP commit, 7 hours ago.

https://www.codeaurora.org/gitweb/e...it;h=20c4c04277387a798653b93626b02493ebd0dc25
[Nexus 4 Android Development] peterperfect:
Looks good!

[MENTION=4303511]thracemerin[/MENTION], hope you get back to your build machines soon :)
[Nexus 4 Android Development] markd0wn:
Fingers crossed (again) for this new fix :)
[Nexus 4 Android Development] thracemerin:
Bad news, same patch as the one we tested for 3.2.2.6, just merged later into master.
[Nexus 4 Android Development] markd0wn:
Too bad. I've seen two more since but I doubt they're helpful to our issue:
[Nexus 4 Android Development] thracemerin:
I'll build master when I get back (probably Monday) and we'll see.
[Nexus 4 Android Development] apex88:
Hi there, thanks for the effort, heres my input:

i was on CM+franco, i flashed the v6 kernel and it did fix the notification delay issue, however it decreased the performance of the device drastically, i felt it immediately and run benchmarks, i got extremely low scores : antutu : ~5300, quadrant : ~1360, way lower then old devices, switched back to franco kernel and got the next scores: antutu ~21000, quadrant: ~5100.

But with franco kernel i get notification delays.
[Nexus 4 Android Development] BlueFlame4:
Do you feel those delays in daily use or are they just numbers? I mean, this is basically the stock kernel, so it's not as optimized as custom kernels ofc.
[Nexus 4 Android Development] apex88:
Yeah i felt it immediately, very rough, not smooth experience, everything was very slow, apps opening very slow, delays on every button.

On stock i was getting 16000/4000 (antutu/quadrant) if i remember correctly
[Nexus 4 Android Development] BlueFlame4:
Well, that's not normal at all. Franco uses a different kernel layout and you have to flash a reset kernel or your ROM again before moving to another kernel. Have you done this? :) I don't feel lags at all here on my phone.
[Nexus 4 Android Development] NYZack:
I had a similar experience leaving Franco's kernel. As has been said, Franco alters files outside of boot.img in his kernel (and the ramdisk as well, though I don't understand that), so you have to flash a reset kernel that resets *all* of the altered system files to go back to stock (or other kernels). Not all reset kernels are created equal, since they don't all flash all necessary files. I found that the reset kernel in the Motley kernel thread was very complete: http://xdaforums.com/attachment.php?attachmentid=1737875&d=1361118181

---------- Post added at 09:12 AM ---------- Previous post was at 09:00 AM ----------

This is Motley's thread (not trying to divert attention from the topic at hand, but it has and explains the reset kernel):

http://xdaforums.com/showthread.php?t=2021437
[Nexus 4 Android Development] thracemerin:
Franco uses a custom ramdisk that disables mpdecision and thermald, both are required for this kernel to work correctly, if you come from Franco you need to flash a reset kernel or dirty flash your ROM to get mpdecision and thermald back before flashing this or you will have very bad performance as you'll be stuck on single core.
[Nexus 4 Android Development] apex88:
A nandroid restore to stock rom+ kernel will do?
[Nexus 4 Android Development] thracemerin:
That should work, there is a reset kernel in motley's thread op that'll do it as well. Or you can flash v3 (which is some pages back) and then v6 should do it too.
[Nexus 4 Android Development] jpierce1987:
Thanks. Yeah, Verizon has better coverage in the area, less dropped calls too! I've been thinking about switching, just didn't want to mention it on here b/c everyone gets very heated and passionate about service providers (LOL) but in the area I work in, ATT just updated the towers about 6 months ago from Edge, but the coverage isn't any better, nor is the amount of dropped calls (15-30/day) I have noticed a massive difference in time spent on this wakelock, though, thanks to you! Something about that area, I guess, was causing 1.5-3 hours of that wakelock, and sometimes it would get hot and need a reboot to solve it! I am a regular rebooter as it is... My last device was a samsung, so I made a habit of rebooting as soon as I get to work, once I pull it off the car charger (b/c of the samsung charger wakelock) and I also use reboot scheduler to reboot while I'm sleeping, after everything updates, podcasts download and titanium backup(to phone and dropbox) I've automated a lot of this with a combination of apps, mostly Tasker... But, as many issues as I have in that area, no matter what phone I use (except for an old school nokia, which has no issues anywhere!) I think its time to ditch ATT... Its hard to say good bye to unlimited data, though... But, if you can't use it....... lol. I wish Nokia would make an Android phone! It would have 2gb of ram, a 41mp camera, a shiny skin very similar to stock, GREAT SERVICE and CALL QUALITY and an AMAZING battery life! If only we could force them to make a high end android phone! Oh, and it would need either 64GB or an sd card.... If Nokia ever makes an android phone, I'm pre ordering that mofo!!! And I don't ever pre order, so thats huge!
[Nexus 4 Android Development] compuguy1088:
A dirty flash is just re-flashing the ROM (or a new nightly) over what you currently have. This will restore the rom's stock mpdecision and thermald?
[Nexus 4 Android Development] BlueFlame4:
Yes.
[Nexus 4 Android Development] thracemerin:
Well, v3.2.3.108 and v3.2.2.7 continue to exhibit the MAC address issues :crying:

Hopefully someone can solve this properly one of these days :fingers-crossed:
[Nexus 4 Android Development] markd0wn:
Too bad... I'll keep hoping for a solution, eventually it'll have to come!

Speaking of which, I see arcee posted an update regarding the CM builds since the issue is not really resolved:

Does that mean that the next nightlies will simply return to stock configuration/no ARP patch, and therefor the WiFi fix won't be needed anymore when using a custom kernel? (e.g. flashing cm -> franco will result in proper WiFi performance with delayed notifications - like stock?)

If that's the case, I assume it could now cause problems for people who use custom kernels who did implement the ARP patches, since if I understand correctly, the fix was needed because CM implemented ARP patches and franco did not, so if CM now reverts it, we'll have a backward situation where CM doesn't have the patches yet some custom kernels do.

Regardless of the WiFi fix zip which returns stock behavior - which may or may not be 'needed' in the next nightlies if ARP thingy is reverted - I assume for us v6 users there will be no change either way, right? As in, if I'm currently flashing latest nightly -> v6 -> franco, that process will remain the same regardless of whether or not CM reverts the ARP patches...
[Nexus 4 Android Development] CMNein:
markd0wn, it's already been reverted: https://github.com/CyanogenMod/andr...mmit/edb8299df7b33f8fee2f91a1007a7f8bae792c8d

Not something that will show on Gerrit.