yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Android Development] socali:
That's what I understood from the source code, and what prompted me to try this setting. I assumed McastBcastFilter is messing up the MAC address by mistake or by design, and was thinking that avoiding will give better results.

Following my (ongoing) tests today I think the phone is now reporting longer wake times for several reasons, one of them is handling network traffic it did not handle before.

I will update here soon.
[Nexus 4 Android Development] thracemerin:
Ill try to explain this as best I can.

When the McastBcastFilter is enabled and ARP offload is enabled, the ARP packets are not handed off to Android while the OS is in deep sleep, they are instead handled within the riva chip itself. This is where the problem lies, the riva chip is responding incorrectly to MAC address requests, but the Android OS itself is not awake.

By switching gEnableSuspend to 2, you are essentially bypassing the flag for McastBcastFilter and the hostArpOffload flags and sending everything to Android for handling, now what this did do was prove that it is in fact the riva chip's fault that there is a problem with ARP offload, and it has to be fixed at the proprietary firmware level, something we can't access. Given that it appears that CodeAurora/Qualcomm hasn't made an attempt to fix this it leads me to believe we have either bad or weird riva chips in our devices, neither is a good thing, but it means there is no chance it can get fixed without Google and Qualcomm.

It makes more sense in my head, but hopefully that explains it somewhat.
[Nexus 4 Android Development] thracemerin:
I'm going to leave this here, if you are having troubles with v5, try this:

Post 2!

I have no further comment on this build, for now no change log will be posted because I'd like unbiased opinions. (@Mods: the sources are on my github, I just want to try and run a blind test, if I need to elaborate on which sources I will be happy to upon request)

Again, please run this for a while and post a BBS dumpfile or kernel wakelock screen along with Deep Sleep/Awake time. (My threat from the v5 post remains in effect)

All the rest of the other stuff that applies to my kernels, applies here.

I do ask for this particular test that nobody screw with any of the firmware files especially WNCSS_qcom_cfg.ini as it will skew my test results.

Thanks.

Edit: if you really want to dig you can probably find the details that I'm omitting, but if you are so inclined I would prefer that you not post them in the thread.
[Nexus 4 Android Development] johnxarma:
this if full kernel like v5??
[Nexus 4 Android Development] BlueFlame4:
I don't know why people keep asking this. Everything you flash here is a full kernel ofc.
[Nexus 4 Android Development] thracemerin:
To be honest with you, if you went from v5 directly to the old hsic version without flashing the revert first I'm surprised WiFi worked at all because it shouldn't have, the firmwares should have been incompatible enough that in my experience WiFi should just be unavailable.
[Nexus 4 Android Development] thracemerin:
They want to be able to use their custom kernel and have the fix because:

1) they hate stock colors

2) they hate mpdecision

3) they want lower clock speeds

4) they want different i/o schedulers

5) they want different tcp congestion control

6) they want sound controls

7) i could continue this list forever probably, but you get the idea.

:p
[Nexus 4 Android Development] thesebastian:
But in general they hate stock colors. Lol
[Nexus 4 Android Development] thracemerin:
If there were better colors that didn't make my IPS panel look like an AMOLED display, I might agree with them, but at the moment I don't.
[Nexus 4 Android Development] itsita:
Well, after flashing v6, it took about 1 minute for the nexus to connect to the WiFi, but after that no drops till now.

Apart from that, smooth as always.
[Nexus 4 Android Development] socali:
Solution for Gray WiFi Bars, Mangled MAC and WiFi Notification

Following my discovery of gEnableSuspend=2 as a potential solution for the for Gray WiFi bars and Mangled MAC address in ARP, I spent the last couple of days running multiple tests in different network environments with different config options in order to identify the optimal solution.

Here's a summary of my findings:

1) Enable Suspend:

gEnableSuspend=3 (McastBcastFilter) - mangles the MAC address, prevents communicating with the device when it's asleep. In post 0406 builds, it gets even worse as WiFi bars turn gray and you need to restart wifi.

gEnableSuspend=1 (Standby) - disconnects the device from the router, which is not the desired outcome.

gEnableSuspend=2 (DeepSleep) - keeps MAC address intact, responds to ping and keep wifi active (best option).

2) ARP Offload:

Throughout my testing, I could not prove that ARP offload is actually working and handling requests instead of the driver. No matter what configuration of gEnableSuspend, McastBcastFilter, and hostArpOffload I used. At this point, I doubt any ARP offload setting actually avoids wakelocks on the device!

3) Awake and wakelock differences:

I did notice the following behavior differences in a very "noisy" WiFi area (my workplace):

CM10.1 0405 had about 5% lower awake times than 0414. However, with both builds and all config combinations the awake times were 55%-65%.

Although CM10.1 0405 had much higher msm_hsic_host percentages (up to 20%), 0414 had much higher suspend_backoff percentages instead (up to 25%).

I'm assuming the higher awake times on 0414 is due to the higher suspend_backoff rates.

4) Conclusion:

The best overall configuration in terms of higher awake time and lower suspend_backoff is CM 10.1 0405 with gEnableSuspend=2, McastBcastFilter=3, and hostArpOffload=0.

As a reference, this gave me comparable or better results than HTC Sensation with CM10-nightly.

All measurements vary greatly based on the amount of "noise" in the wifi you are connected to.
[Nexus 4 Android Development] thracemerin:
I'm beginning to think you're right here, waiting on further testing of my secret changes in v6 before I post my findings on this :)
[Nexus 4 Android Development] socali:
2Wire Noise

While testing possible causes and solutions, I was surprised to find out that 2Wire routers keep sending two ARP requests to the entire DHCP block every 20 seconds. This keeps devices awake and wifi network busy for no reason.

After some googling, I found out that this has been "by design" for quite a few years with 2Wire routers. I've setup a separate AP with an old Linksys I have and my phones are now getting much better sleep. :)
[Nexus 4 Android Development] thracemerin:
Some routers do some very strange things, windows also tends to send out random packets to all nodes unless you disable some services that are on by default (i can't remember which ones, ill look it up).
[Nexus 4 Android Development] darkamikaze:
Hmm maybe it's AOKP that's causing my lack of deep sleep then?

lol my test isn't exactly deep but .. I'm using CPU Spy.

I start the app, reset timings. Immediately turn off screen. I leave it off for about 10min.

My deep sleep is like 2min and time at 384Mhz is roughly 7~ so maybe 70~80% of the time it's not sleeping X-x. Battery Drain seems to be fine though.. I'll keep testing
[Nexus 4 Android Development] thracemerin:
Which version? If it's v5, try v6, if it's v6 see below.

Can you get better battery stats and post the kernel wakelock screen or a dump file? if you don't want to use the paid version from the store, you can use the one that's on XDA.
[Nexus 4 Android Development] mobilehavoc:
If this is true then why do we need a CAF kernel? This will work with even stock kernel since the OS is handling ARP. Seems all we need is the cfg file and nothing else? I thought the only reason you needed the CAF kernel was if you're using ARP offload.
[Nexus 4 Android Development] thracemerin:
There is the potential we don't, but this is also a workaround and may in some conditions result in bad battery life, that's why we're looking at all possible angles.
[Nexus 4 Android Development] DenyDarko:
Newer WLAN version from prima 3.2.3.103a

Nothing interesting related to the ARP issue as far as I can see tho
[Nexus 4 Android Development] thesebastian:
Thracemerin,

This is so obvious (I assume you already know this) but if there is something you want to report to Qualcomm regarding Nexus 4. You have the email addresses of the developers @Qualcomm.com on the prima GIT.
[Nexus 4 Android Development] thracemerin:
Yeah, nothing I can see that will help our situation at the moment. I'm beginning to think the problem is in the low level firmware on the chip that controls WiFi and BT on this device which may require Google or LG to get something together to fix it too, I'm not sure.

It looks like Google is pushing some updates to 4.2.2 to AOSP (JDQ39E) at the moment but nothing that gives me any hope with regard to this issue. Seems to be regulatory stuff related to WiFi channels.

I'm aware, I'm talking to some people via various channels, nothing thats worth reporting has been accomplished on this front, not to say it won't, these things take time. (As a side note here: Please do not email CAF or Qualcomm devs about this issue, I encourage using the official bug reporting channels that are available, bothering devs will not get this sorted out any more quickly and may divert their attention and/or increase their frustration. Not saying anyone did, but if anyone in this thread was thinking about it, don't.)

Again, for those on earlier versions, I would like you to try v6, I moved it to Post 2, I just want to see if the changes that I made cause significant battery drain or not. If not, it may be the best solution for the moment.
[Nexus 4 Android Development] jakejm79:
Couple of things here, running your hsic_fix_nexus4_4.2.2v1.zip fix and then just changing gEnableSuspend=2 in the cfg file on completely stock 4.2.2 and I get the following:

This was with light usage, I was out in my driveway for about 1/2 the time but normally get a weak wifi signal there so I believe it was connected for all but about 2 hours of that time. I get push notifications right away when on wifi now and never have before.

The only strange thing is the my MAC address for wifi is different now, and I don't mean same numbers in a different order, I mean it is completely different, xx:xx:xx:xx:6E:1B now where as before it was xx:xx:xx:xx:F5:83

Weirdly it shows the following info for my current MAC:

CIMSYS Inc

CIMSYS Inc

#301,Sinsung-clean BLDG,140, Nongseo-Ri,Kiheung-Eup

Yongin-City Kyunggi-Do 449-711

KOREA, REPUBLIC OF

and for my previous one:

LG Electronics

60-39, Kasan-dong, Gumcheon-Gu

Seoul 153-801

KOREA, REPUBLIC OF

Anyway all I know is that I have great HSIC wakelock performance, I get all my push notifications almost immediately whether on wifi or mobile data and my battery life is as good as it normally is.
[Nexus 4 Android Development] mobilehavoc:
Just curious why this would be better than enabling broadcasts in the filter? Can someone post a cfg file for suspend = 2 only as a zip? I can't root because I have corp email but I have custom recovery. Thanks!
[Nexus 4 Android Development] jakejm79:
Try flashing the v6 wlan fix in the post 2.
[Nexus 4 Android Development] mobilehavoc:
I don't want the whole kernel and new PRIMA...just the cfg. That's all that should be needed. I'll try to do it with adb from recovery.
[Nexus 4 Android Development] thracemerin:
Flash v6.

(don't read too much into this, just flash it.)
[Nexus 4 Android Development] mobilehavoc:
So I just successfully used ADB in CWM to overwrite my cfg.ini. I took the original stock 4.2.2 cfg file and all I changed is Suspend=2. That's it. Nothing else.

I'm going to test now and see if it makes any difference. I have your file on my sdcard to flash if needed. I know you want to blind test and all but I really don't want to flash new PRIMA drivers or use your kernel (which I'm sure is awesome). I'm happy running 4.2.2. bone stock with this minor edit.

Will report back.
[Nexus 4 Android Development] darkamikaze:
Hmm so tonight has been pretty solid. Updated to the aokp milestone and using v6.

Everything seems to be working fantastic!

Sent from my Nexus 4
[Nexus 4 Android Development] thracemerin:
Yeah, fairly sure there was something wrong with v5, the data so far suggests that v6 is producing good results.
[Nexus 4 Android Development] JAS_21:
This was using the v6 kernel with pretty heavy music streaming for several hours and a few calls and texts.
[Nexus 4 Android Development] thracemerin:
Seems pretty good, how does it compare to normal?
[Nexus 4 Android Development] JAS_21:
My battery seemed better than previous versions. I ran pandora for a few hours straight and I still lasted all day without plugging in to charge. I wish I had better stats, but i was just screwin around at work :)
[Nexus 4 Android Development] socali:
I agree. v6 is definitely the winner!

No gray WiFi bars, responds to ping when screen is off, low suspend_backoff (if at all, on very noisy wifis only), and better battery life than recent CM nightlies.

I'm happy my research is proving to be the right solution. I just hope CM will apply these changes to their nightly soon! :)

Edit: After comparing v6 against CM0405 again on a different WiFi network, for some reason I get much higher suspend_backoff with v6 than with CM0405. I don't really know what's causing this. :( We really need qcom to get a real fix for this! Either way, both are better than the current CM nightly.
[Nexus 4 Android Development] thracemerin:
Yeah, definitely a big thanks for the great find on that one :)

Edit: since the cat is sort of out of the bag on this anyway, v6 is the same as my hsic_fix kernel (built from the same git tree 'jb-hsic-rel' from https://github.com/thracemerin/Mako), the only thing I did was change the WCNSS_qcom_cfg.ini file to gEnableSuspend=2, that's it :)

Edit 2: @socali - I added a thanks to you in post 1 :)
[Nexus 4 Android Development] darkamikaze:
damn lol so one off number to pain us all...
[Nexus 4 Android Development] thracemerin:
The ultimate fix is to get the driver working the way it was intended, this is sort of a bypass fix which works well enough until someone at Qualcomm, LG or Google can solve it completely, but at least this solves the problem for now.
[Nexus 4 Android Development] jakejm79:
Thracemerin, any idea why MAC address (and apparently the manufacturer for the associated device) would have changed by enabling this fix? Not that it's a big deal, just wondering why.
[Nexus 4 Android Development] thracemerin:
No, that's pretty odd, in all the testing I've done I've never had my MAC address change, I don't think you need to worry about it though as long as everything else is working.
[Nexus 4 Android Development] jakejm79:
Yes it's very strange, not a big deal, just had to change the MAC in my routers DHCP table, just noticed it when my saved IP for the FTP file server was wrong, explains why I wasn't able to ping my phone but was still getting instant notifications. Actually I wonder if it has anything to do with the bug that people on CM10.1 were reporting after a certain nightly were they all got the same MAC address, since I switched to using stock from CM around the same time I noticed this. Maybe that explains why some people were experiencing the scrambled MAC address, if it was the incorrect one from a nightly rather than the inbuilt one.
[Nexus 4 Android Development] MotoRaph:
So which driver version has v6? 3.2.2.2?
[Nexus 4 Android Development] thracemerin:
v3.2.1.13, same as stock.
[Nexus 4 Android Development] MotoRaph:
Ok, thanks. Kernel v3 is the one which helps me with delayed notifications. New v6 has the effect, that messages arrive me only when I unlock the phone. I have a Fritz Box 7390.
[Nexus 4 Android Development] thracemerin:
Interesting, you're the first person to report that v6 didn't work for them, it could be your router.
[Nexus 4 Android Development] MotoRaph:
I know... Perhaps it can be the driver of v3 combined with the settings of v6 which helps then everyone? :confused:
[Nexus 4 Android Development] thracemerin:
v5 had a newer driver version and the settings from v6 and was behaving oddly, I'll see what I can do.
[Nexus 4 Android Development] MotoRaph:
Thank you for your work!
[Nexus 4 Android Development] BlueFlame4:
Yes, I can confirm this.

v6 killed everything for me - even the notifications on HSDPA. I have never ever experienced this before, but I guess you didn't change anything except Wifi settings, did you? Really weird...

v5 is working in 90% of the cases. v3 was working 100% though.

I'm not sure whether this is important so sorry if I spammed.

Router: Fritz Box 7112

Gonna try it in my University Wifi today.

Thank you very much for this work! Without you I would have sold my N4 again most probably , lol

Sent from my Gameboy Color
[Nexus 4 Android Development] johnxarma:
+1 to this. v3 worked perfect for me also!
[Nexus 4 Android Development] tabii:
v6, hsic wakelock seems high, this was all on wifi. No more wifi issue while screen off though.
[Nexus 4 Android Development] markd0wn:
Is there a flashable .zip that uses stock drivers and only changes gEnableSuspend to 2?

So you could flash latest CM nightly, then a zip that restores stock drivers with gEnableSuspend set to 2, then you can flash franco kernel? (like the wlan revert zip)

Is that what v6 does, or is v6 a full kernel like the others, one which you can't flash franco or other kernels over?
[Nexus 4 Android Development] OrrPenn18:
All kernels in this thread are full stand-alone modded kernels.
[Nexus 4 Android Development] markd0wn:
And not in this thread? wouldn't thracemerin now agree based on recent findings that such a zip (stock drivers+enable suspend set to 2) is the best solution currently available? If so, such a zip would be useful and possibly a better replacement for the current non-full kernel wlan_revert_cm.zip from post 2
[Nexus 4 Android Development] thracemerin:
Given what happened with v5 which included the ARP offload patches that are included in some kernels (CM, Air, PA, etc...) and the change that is in v6, I would say that it's best to use the full kernel solution in order to avoid problems, at least in the short term.

Plus, it appears that this doesn't solve it for everyone either, ugh.
[Nexus 4 Android Development] markd0wn:
Hmm, so if I want to use franco's kernel, using wlan_revert_cm prior to flashing it is still the best option?

Or, how about a wlan_revert_cm with the .ini changed to gEnableSuspend=2/McastBcastFilter=3/hostArpOffload=0? I think franco didn't include the ARP offload patches, so wouldn't that be 'better' than the current wlan_revert_cm?

I guess what I'm asking is - if I take the current wlan_revert_cm.zip, and change the .ini to the values I've written above, will that be an improvement over how wlan_revert_cm.zip currently works, assuming I use CM10.1 nightlies, than flash the revert zip, then flash franco?
[Nexus 4 Android Development] thracemerin:
You can flash v6, then flash franco, should work fine, emphasis on should :)
[Nexus 4 Android Development] markd0wn:
Thanks, will try that now and from now on and see if there's any improvement. Will just change my daily process of CM10->revert->franco to CM10->v6->franco.
[Nexus 4 Android Development] thracemerin:
I'm not guaranteeing it will work, but I see no reason why it wouldn't. Worst case, it breaks your WiFi completely and you have to go back to your old method, but that's unlikely.
[Nexus 4 Android Development] thracemerin:
On a completely unrelated note:

I've had a bunch of people PM me various questions with relation to v6 and other fixes that are floating around the forums. I'll try to answer this as best I can for everyone.

The fixes in various kernels (PA, CM, Air, matr1x, etc...) are the ARP offload patch that was used here in some of the earlier versions v1-v4, this patch has an issue where when the phone is in deep sleep it responds to ARP requests with a bad MAC address which results in broken direct connect (WiFi direct, Air Droid, etc...) and potentially some other issues. In order for this fix to work, the McastBcastFilter has to be set to 0, for kernels without this fix that can be a problem on networks with heavy packet traffic especially heavy multicast and broadcast traffic as the phone will wake up on every packet which can result in severe battery drain. In order to solve this there is a fix in the CM Q&A thread that has been floated elsewhere also written by me, this simply does the same thing as the wlan_revert from Post 2 in this thread, but also flashes a stock CM kernel that doesn't have the ARP offload functionality included.

The fix in this thread (v6 currently) is just the hsic fix kernel with a modification to the WCNSS_qcom_cfg.ini file to set gEnableSuspend to 2, this can be done on any other kernel by modifying the value in this file with a root file explorer, but I warn you that doing it to a kernel other than this one may have unexpected consequences and is untested by me (if they have the patch described above as my v5 did, it may behave very badly), so for this reason I can't recommend it, but that doesn't mean it won't work.

Hopefully this alleviates some confusion. I agree with most people who are confused that the word "fix" seems to refer to at least 3 different things and possibly more, which is kind of unfortunate.
[Nexus 4 Android Development] markd0wn:
Just flashed (cm_mako-04-18-2013-linaro.zip -> hsic_fix_nexus4_wlan_v6.zip -> franco.Kernel-nightly-r125.zip). It 'works' in the sense that nothing exploded, the phone booted, and there are no immediate issues (WiFi is working).
[Nexus 4 Android Development] thracemerin:
Always good when your phone doesn't burst into flames after a flash :p
[Nexus 4 Android Development] thracemerin:
Re: [Kernel][GPL][anykernel][WIP] msm_hsic_host wakelock fix

Flash any other kernel in recovery.
[Nexus 4 Android Development] Euler MD:
Say I applied it to the stock kernel, can i flash a clean version of the stock kernel to revert?
[Nexus 4 Android Development] deltatux:
Doesn't seem to work with Franco kernel r34, I flashed the Anykernel version of this fix and it just sits at the Google logo for 5 minutes. I'm running it with XenonHD 2.0 ROM.

Did I flash the wrong version?

deltatux
[Nexus 4 Android Development] thracemerin:
Franco uses a non-stock ramdisk that seems to only work on his kernel, you need to either flash one of the reset kernels that are around the forums or use fastboot to flash the stockboot.img.
[Nexus 4 Android Development] thracemerin:
Yup
[Nexus 4 Android Development] deltatux:
Sorry, I just got my device so I'm not sure about device specific stuff. I came from the Nexus S and didn't have to do any of those before so I'm not sure what reset kernels or the stockboot.img you're talking about.

Any pointers would be appreciated.

Thanks,

deltatux
[Nexus 4 Android Development] Euler MD:
+3

I hope the any-kernel solution works for franco...

IT DOESN'T WORK.
[Nexus 4 Android Development] thracemerin:
Flash this first: http://xdaforums.com/attachment.php?attachmentid=1550949&d=1355107145
[Nexus 4 Android Development] diegocr:
Thanks!

I have try it on cm10.1 (20130117) and now 3G seems to work well. :fingers-crossed:

Flashed zip file with TWRP
[Nexus 4 Android Development] deltatux:
Basically I have to flash the stock kernel to use this fix? Would it work with the Matr1x kernel? Not a fan of using mpdecision.

Cheers,

deltatux
[Nexus 4 Android Development] thracemerin:
This replaces the kernel, kernels are pre-compiled binaries by the time you flash them, you can't add this fix dynamically to another kernel, what you can do is flash the latest motley kernel experimental version which includes these fixes and uses auto hotplug instead of mpdecision.
[Nexus 4 Android Development] deltatux:
Oh, thought this was like loadable module or something. Guess not. I think I might just wait to see if Franco will merge this fix to his kernel, if not, then I'll flash a kernel with this fix. Without the fix, it's not that big of a deal since my battery life is alright.... for now :p

Thanks anyways.

Cheers,

deltatux