yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Android Development] thracemerin:
Radios never come with changelogs so hard to say for sure, but to my knowledge the radio has nothing at all to do with WiFi, and the radio controller (msm_hsic_host) is still in the kernel so other than potentially increasing signal and therefore link speed which would shorten awake time, I doubt it.
[Nexus 4 Android Development] thesebastian:
In the last week I woke up 2 days with SIM card LOCKED message screen and needed to restart the phone in order to be able to unlock SIM card.

Have been using:

- SuperSU

- Google JDQ39

- hsic_fix_nexus4_wlan_prima_323119.zip

- Vibrator "amp" file manually changed from 70 to 100 after booting the phone.

I don't know if the kernel has something to do with it but just wanted to mention it, in case I'm not the only one.
[Nexus 4 Android Development] thracemerin:
A few people have mentioned this in the past, but I can't for the life of me figure out what's causing it as I'm unable to reproduce it. If it happens again see if you can grab me a logcat.
[Nexus 4 Android Development] markd0wn:
Yep, seems like that didn't change WiFi indeed. Just got the classic wake-screen-and-receive-a-15-minute-old-notification. Back to v6..
[Nexus 4 Android Development] markd0wn:
Is this significant in any way?
[Nexus 4 Android Development] thesebastian:
Today i had another bug (this time it's something about AIRPLANE Mode)....Maybe this has nothing to do with the kernel.

This is my 1st logcat, it could be a totally fail. (I assume it's safe to upload this, otherwise tell me please).

Problem:

- My N4 lost the signal.....(Only the 2G/3G signal, WiFi still working fine).

- Tried to call a person --> Message: Airplane mode is enabled.

- Tried to disable Airplane Mode and before get the signal...it's automatically enables again (without removing WiFi).

So i was trapped in a LOOP with Airplane mode until restart my N4.

P.S.:

> I never enabled Airplane Mode, it was done automatically.

> To create the logcat i connected the phone --> "adb logcat > airplane.txt" ---> reproduced the bug.

> This is not the 1st time i have this issue.
[Nexus 4 Android Development] Zaldi00:
To create logcat, try to install terminal Emulator to play store. Then open window on terminal and write :logcat>/sdcard/logcat .txt, or in this case: logcat -b radio>/sdcard/logcatradio.txt

For me, this is more comfortable.

************Nexus7 ***********
[Nexus 4 Android Development] Shaky156:
You are aware that you havent turned on arp offloading?
[Nexus 4 Android Development] thracemerin:
What?
[Nexus 4 Android Development] Shaky156:
In configuration file hostarpoffload =0

Arp offloading is basically switched off :s
[Nexus 4 Android Development] thracemerin:
Yes, ARP offloading doesn't work properly with the firmware that is currently on this version of the Atheros chip, this is why the Prima drivers don't fully solve the problem, the solution in v6 is a different solution entirely.
[Nexus 4 Android Development] Shaky156:
Have you attempted to switch on arp offloading in configuration then implement arp oflloading @ kernel level including the arp offloading suspend fix? Afaik it should work n shouldnt require a firmware change although i have read theres an error somewhere that doesnt allow any newer wifi firmwares that is placed on the system to be used/read

---------- Post added at 07:43 PM ---------- Previous post was at 07:29 PM ----------

Quoted as xda wouldnt allow it earlier
[Nexus 4 Android Development] thracemerin:
The fix I implemented just sends ARP requests to the OS instead of trying to handle them on the chip, thats what gEnableSuspend=2 does, it just puts the chip to sleep instead of enabling the Multicast/Broadcast packet filter, when an ARP request comes in it wakes Android up to respond instead of being blocked (default behavior) or being handled improperly (behavior of the chip when ARP offload is implemented as in the new Prima drivers)
[Nexus 4 Android Development] Shaky156:
I see, ill give it a shot if i have some time tonight to enable arp offloading, its a serious issue and has been bugging me for the past three months, ive saw the google report, its appauling, google should have atleast released a small update to fix this, its a major issue, i got a message at 4 oclock in the morning instead of 3, if someones gna wake me up atleast the phone should wake me up on time!
[Nexus 4 Android Development] thracemerin:
The issue is in the actual Atheros firmware, for some reason it jumbles up the MAC address when it responds, if you want to see how I've explained it fairly extensively in the thread. The problem is, it's not on the kernel or OS level, it's on the chip firmware level and we don't have access to that layer or any updates to it without the assistance of the vendors as that isn't open source software, so we need Qualcomm/LG/Google to push a new Atheros firmware that solves this issue with the next iteration of Android, before that there is little you can do unless you are exceptional at pulling the firmware off the wlan chip and hex editing it, but given that there is no reference document, etc... even an attempt is likely to brick your device or at the very least break your wlan permanently.

If you are going to try to fix it, there are kernels in here with the new Prima wlan drivers installed that will allow you to test what happens when ARP offload is working as Qualcomm intended.
[Nexus 4 Android Development] Shaky156:
Did you copy the whole prima wlan drivers or just implement the fix?
[Nexus 4 Android Development] franciscofranco:
[MENTION=4303511]thracemerin[/MENTION] can you take a look at my git and check the hsic patches I merged. Did you test those? Some users were complaining about the controller being reset too often after I rebased and merged all your hsic patches (thank you for that). I merged some semi-obvious hsic patches from CAF msm-3.4 branch in hope to remove that controller being reset, but since you've spent more time on this matter than me I would like to know your take on the patches I just merged. Thanks!
[Nexus 4 Android Development] thracemerin:
[MENTION=3292224]franciscofranco[/MENTION] I've been following your thread (since I follow all the kernel threads to some degree or another) and if you went wrong I don't see where you would have, I'm wondering if the people having issues are using the .33 or older radio for LTE on T-Mo in the US or one of the Canadian providers that provides Band IV LTE because I know that when I did this on my device I had all sorts of random radio drops and resets and other such weirdness until I reverted back to the newer modems, I can't say for sure the radio is the problem but with my limited anecdotal testing I would look at that as a cause.
[Nexus 4 Android Development] thracemerin:
Both I cherry picked just the ARP offload related fixes into the current driver and completely replaced the entire Prima driver tree, both end up with the same ARP response issue.
[Nexus 4 Android Development] -sandro-:
should this work instead on the s4 i9505? I upgraded to this phone and I now have msm host wakelocks.
[Nexus 4 Android Development] Teadious:
I'm having terrible android os wake lock .. Is this normal for the kernel?
[Nexus 4 Android Development] Zaldi00:
For me, te notifications works perfectly with cm10.1 and kernel stock, but when the screen goes off, it's impossible connect with airdroid from pc.

Can you try this?

Enviado desde mi Nexus 4 usando Tapatalk 2
[Nexus 4 Android Development] Teadious:
Well, I don't know what the problem was, but it seems to have passed now.. Weird stuff
[Nexus 4 Android Development] Shaky156:
I see ive created the thread, its under original development
[Nexus 4 Android Development] thesebastian:
In my case...Im just fine with thracemerin's kernel with latest prima drivers. I never worried about Mac address issues.

So I'm going to keep this Kernel until 4.3 Kernel.
[Nexus 4 Android Development] thracemerin:
For those of you who love prima updates, I pushed a new one to http://goo.im/devs/thracemerin/mako/hsic_fix should be available shortly.
[Nexus 4 Android Development] markd0wn:
By the way, I forgot to ask, but is there a recommendation regarding the 'Wi-Fi optimization' setting (default=on in latest CM nightlies) when using v6 (gEnableSuspend=2)? I currently leave it ticked but I'm wondering if it's better to turn it off (was suggested in some older threads).

If it matters, I'm also using Push Notification Fixer which changes the heartbeat interval (I set it at 3 minutes for both wifi/mobile data) and seems to help with (not-as-often-occurring) cases of mobile data delays.

At this point I'll be happy if android 4.3 (or whatever the next version is) will ONLY fix all of these issues, so one could finally just use default .ini settings & default wifi settings & won't need to use third-app applications or change any intervals. That fix will probably overshadow any other fix/addition. I hope that day is near..
[Nexus 4 Android Development] thracemerin:
I've always left it as default without experiencing any trouble.
[Nexus 4 Android Development] kara mustafa:
Can I set gEnableSuspend to 2 with cm 10.1 stock rc4 kernel? or it will break something?
[Nexus 4 Android Development] thracemerin:
Should work on any kernel as far as I know, it might not if you use one that has modified WiFi drivers, but the stock CM one doesn't.
[Nexus 4 Android Development] thesebastian:
Thanks. I installed it. For now its working fine.
[Nexus 4 Android Development] thracemerin:
Good, cuz you may have noticed that it was built by my other buildbot (Wolverine) for some reason instead of my main one (Phoenix) so it's good to know that it still worked :)
[Nexus 4 Android Development] kara mustafa:
I discovered that in rc4 gsuspend is set to 2 by default. Possible?

And what is differences between v6 and cm 10.1 stock kernel?
[Nexus 4 Android Development] thracemerin:
Yeah, Arcee (the CM mako maintainer) and I have been talking about that stuff, I guess he decided to try that setting by default on CM which is awesome, if its set like that I'd stick with the CM kernel.
[Nexus 4 Android Development] kara mustafa:
Thanks ! You are quick!:)
[Nexus 4 Android Development] markd0wn:
Google updated binaries for Nexus 4 from JDQ39 to JDQ39E (still 4.2.2) - https://developers.google.com/android/nexus/drivers#makojdq39

Is the Wi-Fi driver different than what it was before? any chance it could help?

EDIT: Apparently, while the page was updated and the 'title' of the Nexus 4 changed from 'Nexus 4 binaries for Android 4.2.2 (JDQ39)' to 'Nexus 4 binaries for Android 4.2.2 (JDQ39 to JDQ39E)', no files were actually changed. A cached page from last week says the MD5 of qcom's binaries was 1d5618958b9c5e322012e175b1bac552, and that's still the case in the new page as well. The other binaries also have the same MD5's.
[Nexus 4 Android Development] markd0wn:
[MENTION=4303511]thracemerin[/MENTION], just a heads up - for the first time since 3/11/13, WCNSS_cfg.dat has now been updated with v3.2.3.128A.
[Nexus 4 Android Development] thracemerin:
Saw that, but I'm out of town again this weekend, I'll see what I can do about getting a build up ASAP.
[Nexus 4 Android Development] quiro91:
how much does this makes battery life on 3G better?
[Nexus 4 Android Development] markd0wn:
Yet another WCNSS_cfg.dat update...
[Nexus 4 Android Development] jbrizz:
Sounds like the wifi ARP bug might finally be fixed.

http://xdaforums.com/showthread.php?p=39295700#post39295700

http://xdaforums.com/showthread.php?t=2272140
[Nexus 4 Android Development] thesebastian:
That's not too old?
[Nexus 4 Android Development] thracemerin:
Given that we've been using the new prima drivers in this thread for a long time and have proven that they have problems and that those problems exist in both versions that you chose to link, I'm not certain how your links are even relevant to this thread. Neither link you posted has anything new or different to contribute to the problem, and neither actually fix the problem long term, on the other hand the solution in this thread works most of the time and doesn't introduce any additional problems, thanks for your input though.
[Nexus 4 Android Development] jbrizz:
Sorry, I should have looked at the date more carefully. I guess this is the one which returns the incorrect MAC address.
[Nexus 4 Android Development] thracemerin:
Upon further reflection I may have come off more jerkish than I intended, but the statement remains true. No offense was intended.
[Nexus 4 Android Development] thesebastian:
Did you tried the latest Prima driver? Maybe its fixed the MAC issue...Who knows....

(Yup. I want a new Kernel)
[Nexus 4 Android Development] thracemerin:
Alright :cowboy:
[Nexus 4 Android Development] thracemerin:
Course I say this and now it won't build.....:confused:

What a pain.
[Nexus 4 Android Development] jbrizz:
None taken :) and I appreciate the good work. _m+ is the best N4 kernel I've used!
[Nexus 4 Android Development] Shaky156:
https://dl.dropboxusercontent.com/u/58024932/prima.zip
[Nexus 4 Android Development] MementoMoriM:
This kernel is working well? I see drivers wearing cousin and I have notifications problems. Greetings!

Enviado por MementoMoriM desde un Nexus 4
[Nexus 4 Android Development] markd0wn:
3rd firmware update in less than 30 days. Dozens of changes in the past few hours, including:

Update the interface files for prima/pronto -- The wlan driver fails to load due to the recent changes in the firmware api folder. Update the interface files for both prima and pronto.

Test MC thread when HAL stop times out -- We have seen numerous instances where HAL stop times out, and it is possible that FW has responded to HAL Stop, and while unloading the driver MC thread is not processing these messages. Or MC thread itself is not responding. So now during those instances, we will post a message to SYS to see if MC thread is handling this properly. Also make sure that the SMD re-open ready indication is logged by default.

Enable GTK rekey offload -- Earlier case supplicant was handling GTK rekeying even when wlan suspended thus wlan host had to come out from the sleep for GTK rekeying. with this change, support for GTK offload has been added so that firmware will take care of GTK rekey when wlan is in suspend mode.

Fix for wake lock issue -- Before scan wlan acquires wake lock. Due to race condition between disconnect command from HDD and linkteardown from PE, SME is stuck in scan and wake lock is not being released, which results in kernel panic .Avoid the race condition.

Add NSOffload INI Param and issue NSOffload request to FW -- Addition of configure FW with NSOffload feature if driver contains IPv6 address. Issues Offload requests to FW for every IPv6 address assigned to the interface and introduces new INI param for controlling NSOffload

MC/BC Filter cleanup -- Removing hdd_dynamic_mcbcfilter_t and introducing a new variable inside hdd context configuredMcastBcastFilter which contains the current value of MC/BC filter. By default initialized with INI value and changed accordingly whenever MC/BC filter is set using IOCTL or ARPOffload is being set.

Host Offload Cleanup -- Adding a central function to control all the offloads supported in our driver. It can enable/disable all the offloads when called with respective flag (ARPOffload/GTKOffload/NSOffload)

I think this sounds a bit more promising than previous changes, what do you think [MENTION=4303511]thracemerin[/MENTION]?
[Nexus 4 Android Development] thracemerin:
Seems great, the new prima won't build though.
[Nexus 4 Android Development] Shaky156:
I can get it running, once my stupid pc boots up, just noticed the new commits by caf, they were created 2 months ago and commited now, sounds like 4.3 is close to release since theyre fixing vital problems
[Nexus 4 Android Development] BlueFlame4:
Yeah, it is rumoured that it will be announced on 10th July. Sounds reasonable since Motorola just introduced a teaser for the Moto X. :)

Sent from my Gameboy Color
[Nexus 4 Android Development] Shaky156:
Thatll most likely be a msm8974 device since google have kernel 3.8 or something close to that cant remember and they are working on a msm8974 defconfig aka snapdragon800. Anywayx pc takin time to fix to cnt do much yet, hopefully soon
[Nexus 4 Android Development] thesebastian:
Do you think nexus 4 will reach 3.8 kernel? Or no way?
[Nexus 4 Android Development] thracemerin:
Very very low chance unless someone on XDA manages to port it.
[Nexus 4 Android Development] BlueFlame4:
Hi thracemerin,

I'd like to know something about this kernel thing and it would be awesome if you could help me. :) I don't quite understand why it is so hard to go to a higher Linux kernel version. I mean if I am on my Linux machine for example I can down- or upgrade to any kernel with little effort. Why is it so hard to run the Nexus 4 on a kernel different to 3.4?

Thanks in advance for your answer! :)

Blue
[Nexus 4 Android Development] thracemerin:
Android uses hacked up versions of the linux kernel couple that with the OEMs releasing drivers that are not forward compatible at all makes it a real chore to get anything working on kernel versions above the one released by the OEM (3.4 in the case of the N4). If Google or LG were willing to release proper drivers for 3.8 or 3.9 that would solve the problem, but since the device works fine (in their opinion) on the current kernel version I don't think this is very likely at all.
[Nexus 4 Android Development] BlueFlame4:
Thank you :) Does that mean the drivers aren't really open source but the devs just compile the binaries into their kernels? I thought Nexus 4 was 100% open source... I know that MPDecision and the Prima driver are closed source. How about other drivers?

So is the advantage of a Nexus device is that the OEMs release the (closed source) binaries which can be compiled into new kernels? How is it managed on other devices (HTC for example)? Sorry, don't want to hijack your thread - I'm sorry, if this gets too annoying :angel:
[Nexus 4 Android Development] thracemerin:
There are a few closed source drivers even for Nexus devices (found here: https://developers.google.com/android/nexus/drivers) but those drivers are released in a fully functional form so they can be incorporated into Android builds without hacks or modifications, non-nexus devices don't generally come with these drivers and the drivers are often modified in weird ways that prevent them from working in a plug and play fashion in an AOSP build, but all of this is more about building the OS rather than the kernel.

For the kernel, the drivers must be open source since all linux kernel components are licensed under GPLv2, but that doesn't mean that the kernel components provided by LG and others for the N4 are well coded or forward compatible so there are issues using these components in kernels other than 3.4 (won't compile, won't boot, broken functionality, etc...) many of these components would require a complete bottom up rewrite to actually work on 3.8 or 3.9 and since Google/LG think 3.4 is fine it's highly unlikely they would bother to waste time releasing a different version.
[Nexus 4 Android Development] thesebastian:
There are new updates. You could try now.

Is this related or nothing to do?

wlan: Fixed the compilation errors when enabling BUILD_DIAG_VERSION
[Nexus 4 Android Development] thracemerin:
Nope, there's a patch missing in the kernel that changed the WiFi data structures, but I can't find the patch on CAF anywhere.
[Nexus 4 Android Development] thesebastian:
Ok! No problem. Thanks anyway! :D
[Nexus 4 Android Development] markd0wn:
[MENTION=4303511]thracemerin[/MENTION], just out of curiosity, what happens if I get https://www.codeaurora.org/cgit/external/wlan/prima/snapshot/prima-3.2.3.143.tar.gz, take WCNSS_cfg.dat, WCNSS_qcom_cfg.ini and WCNSS_qcom_wlan_nv.bin from it, use those 3 files to overwrite the ones in hsic_fix_nexus4_wlan_v6.zip, and flash?

Would that be the same as having 3.2.3.143? or is doing this dangerous?
[Nexus 4 Android Development] thracemerin:
Nope, you'd have no wifi.
[Nexus 4 Android Development] markd0wn:
I had a feeling it wouldn't be that easy.. thanks :)
[Nexus 4 Android Development] jamesrt:
Hi [MENTION=4303511]thracemerin[/MENTION],

On <https://jira.cyanogenmod.org/browse/CYAN-558>, your last comment was along the lines that the gEnableSuspend=2 setting doesn't work 100%; but are we any closer to a "real" fix?

The reason I ask is that gEnableSuspend=2 was merged into the -RC branch; but hasn't been on the -nightly branch, which is what I'm running on my phone now.

Is there any point in asking on Jira for this to be merged into the -nightly branch, do you think?

At the end of the day, the workaround does work well (for me, at any rate!); and it would be nice to have a phone that "just worked"... This workaround is probably as good a fix as we're going to get until 4.3, surely?
[Nexus 4 Android Development] markd0wn:
From other threads it looks like in a very short while we're getting a 4.3 system dump with .83 radio. I guess we're about to find out if 4.3 is the answer to this frustrating issue.

Will 4.3 have delayed notifications fixed without MAC issue? will it even have newer prima drivers or solve it in a different way? will we be able to stop flashing fixes and just stick with default 4.3 wifi & default WCNSS_qcom_cfg.ini and stop using Push Notification Fixer (unless it doesn't hurt anyway)?

Answers hopefully soon.
[Nexus 4 Android Development] markd0wn:
Yep, 4.3 leak is now available (system so far, radio and bootloaders to follow soon). Someone claimed if you disable wifi optimization the phone responds to ping but I'm not sure how thorough the test was. Anyway, waiting to see which prima drivers it has and whether or not the issue is fixed/answers to the post above. Hoping for good news. Can do tests myself later if needed.
[Nexus 4 Android Development] markd0wn:
Meanwhile, prima v3.2.3.146 is out. Not sure if they fixed the issue regarding building, but here are some of the changes:

- Different short preamble capability in Beacon&Probe

- Fix for null pointer dereference

- Multicast Address Filter cleanup (Instead of calling wlan_hdd_set_filter, using sme_8023MulticastList to configure MC Address Filter list and not use up the filter IDs.

- Fix for wake_lock list corruption issue (Destroy wlan_wake_lock if WCNSS driver fail to downloads NV data)

- API changes for nv3 (Integrate changes made in firmware Pronto, Updated review comments)
[Nexus 4 Android Development] markd0wn:
I've flashed the leaked 4.3 MAKOZ20i bootloader, the leaked 4.3 .83 radio, wiped everything, flashed the actual 4.3 system dump, wiped everything again (except /system), and I'm gonna do some tests soon. Initial test of making sure IP isn't in ARP table and pinging 10 minutes after screen is off and unplugged, worked and it responded, but I'll do extra tests later and wait longer after screen is off. This is with default Wi-Fi settings so the optimization setting is on at this point.

Also, I'm not sure if there's a way for me to check which version of the prima drivers come with the 4.3 leak. However, by comparing old and new WCNSS_qcom_cfg.ini, it seems like 4.3 has this setting added and activated:

# Flag to enable Active mode offload

gEnableActiveModeOffload=1

Also, hostArpOffload is set to 1 and not 0, and the same goes for gEnableDFSChnlScan (set to 1, not 0).

Finally, these are added:

btcStaticLenLeBt=120000

btcStaticLenLeWlan=30000

gCountryCodePriority=1

gNumChanCombinedConc=255

Everything else seems identical.
[Nexus 4 Android Development] thracemerin:
Can't say for sure until the sources drop what changed, but you can verify the prima version by doing a 'dmesg | grep wlan' either in an adb shell or terminal emulator, probably needs to be run as root and it needs to be run shortly after reboot or shortly after you turn WiFi completely off and then on again.
[Nexus 4 Android Development] markd0wn:
Thanks. It says "wlan: loading driver v3.2.2.17".
[Nexus 4 Android Development] thesebastian:
And v3.2.1.13 is the 4.2.2 Driver.

One question....what kind of improvements could bring a bootloader update?