[Q] Improper WiFi sleep policy behaviour, any idea on fixing this ?

[InfX]

Despite setting the WiFi sleep policy to "never", HD2 becomes unpingable when the screen goes off, causing applications such as Fring/Skype/etc to lose connection. After turning the screen back on, the WiFi reconnects, and does it rather quickly, but having it off while the screen off meaning no incoming Fring/Skype calls possible on WiFi.

Any ideas ?

NOTE: i am currently using this build.

 

[wilderwind]

Same problem. Wi-Fi goes to sleep when screen goes off, even if Wi-Fi tethering is running. It's a reason of losing connection via Wi-Fi tethering. BUT! If at least one network service is active (ping, for example), Wi-Fi doesn't goes to sleep. I think that some of background services (Wi-Fi routing!) stops or becomes idle when screen goes off. It's a priority or policy bug, maybe... Not in a particular ROM, but in Android OS.

Using MDJ's CyanogenMod 7 NAND ROM (Android 2.3.2 Gingerbread).

 

[shahnowaz]

or may be in power saving option check there .it looks like it saving your battery power.

 

[jose makalolot]

or may be in power saving option check there .it looks like it saving your battery power.

It is not power saving options because it also happens to my mdj 2.6 build with battery full. Power saving starts on 15% on my battery and also wifi and background data has been unchecked.

When this happens, no email updates, voip, and other app updates that needs data(because mobile data is intermittent in my area).

 

[rafpigna]

yeah, actually happens with all builds
I solved with this app, enabling all workarounds
http://www.appbrain.com/app/wi-fi-keep-alive/com.shantz.wifikeepalive

 

[InfX]

Enabling all workarounds would keep the device fully awake, this is not really a solution.

Tbh, this issue smells like a power management related bug in a wifi module/driver.

Also, if you google a bit, you can see it being talked about on nexus one, mentioning cyamogen roms as ones not having this issue.

Any idea what module/driver is responsible for wifi ? Is it a part of the kernel ? Or is it a module we may try replacing ?

 

[tageeboy]

yeah, actually happens with all builds
I solved with this app, enabling all workarounds
http://www.appbrain.com/app/wi-fi-keep-alive/com.shantz.wifikeepalive

Thanks much, just installed.

 

[InfX]

The offending driver seems come in a separate module, "bcm4329.ko". Here is a Nexus One thread mentioning the issue on one of the Nexus One stock builds, and actually presenting an updated module for that stock build.

Since HD2 uses the very same BCM4329 chip, it should be possible to compile the updated module for an HD2 kernel.

Any kernel guys up to the task ?

 

[rafpigna]

The offending driver seems come in a separate module, "bcm4329.ko". Here is a Nexus One thread mentioning the issue on one of the Nexus One stock builds, and actually presenting an updated module for that stock build.

Since HD2 uses the very same BCM4329 chip, it should be possible to compile the updated module for an HD2 kernel.

Any kernel guys up to the task ?

We need the commit used to do the change. I looked at the thread and found a commit but I dont think that is the right one.. Anyway I will try to see if can be included in my kernel asap and check if the situation improves.

 

[rafpigna]

We need the commit used to do the change. I looked at the thread and found a commit but I dont think that is the right one.. Anyway I will try to see if can be included in my kernel asap and check if the situation improves.

I checked, and the fix is already there... So at this point I think this is not our problem. I will try to address this to markinus or danijel that are far more experienced than me in kernel stuff

 

[InfX]

I checked, and the fix is already there... So at this point I think this is not our problem. I will try to address this to markinus or danijel that are far more experienced than me in kernel stuff

Maybe, just maybe, it's already fixed in your latest kernel, that uses the latest code base ? Note that i did NOT try & check it with every kernel available, i've only checked this with one that came with the build i am using (i think it was MDJ there, newer version uses yours, but i am not yet running it).

Anyone using latest rafpinga kernel, can you please test and respond ?

 

[InfX]

Update, rafpigna 1.7 installed, identical WiFi behaviour.

 

[mishik]

Looks like this is the solution for Desire:
http://forum.xda-developers.com/showthread.php?t=752856
Hopefully someone could adopt this to HD2.

 

[InfX]

Nice... Rafpigna, the diffs are at this post, can you apply and compile the patched "bcm4329.ko" for us to try ?

Sorry for being too dumb to do it myself, i just never ever happened to compile a linux kernel, not even once in my entire life

 

[rafpigna]

Nice... Rafpigna, the diffs are at this post, can you apply and compile the patched "bcm4329.ko" for us to try ?

Sorry for being too dumb to do it myself, i just never ever happened to compile a linux kernel, not even once in my entire life

It's not our problem

Note: This isn't related to the sleep mode wifi disconnections caused by MAC addresses that don't begin 00, so far as i'm aware that's been patched for a while now. Wifi remains connected fine in standby mode, but the throughput is only suitable for very light traffic.

 

[InfX]

I know its not our problem, but this may still be our solution. Our problem, seemingly, starts when the driver it going down into the deepest power saving state it can. It is supposed to sustain connectivity in it, though, but it seemingly doesn't. Avoiding this deepest state (PM_MAX) may solve the problem while having little to no side effects. Well, obviously, i do understand it's going to consume more power with WiFi on, but its better than being unable to keep it on at all.

Again, i know this is not exactly our problem, but again, this CAN be our solution anyway.

 

[mishik]

I know its not our problem, but this may still be our solution. Our problem, seemingly, starts when the driver it going down into the deepest power saving state it can. It is supposed to sustain connectivity in it, though, but it seemingly doesn't. Avoiding this deepest state (PM_MAX) may solve the problem while having little to no side effects. Well, obviously, i do understand it's going to consume more power with WiFi on, but its better than being unable to keep it on at all.

Again, i know this is not exactly our problem, but again, this CAN be our solution anyway.

I think it's definitely worth a try...

 

[linj]

I think it's definitely worth a try...

Hello!

Unfortunately, I have tried this (to my detriment; I have code due tomorrow still!), and basically replaced the equivalent of this in the RAF 1.7 code (dhd_cdc.c and wl_iw.c have the PM_MAX vs PM_FAST thing).

My zImage came out almost a whole MB smaller (probably a toolchain thing), but the wifi problem while sleeping still exists, at least the symptoms that are linked in http://code.google.com/p/cyanogenmod/issues/detail?id=2403 with the similar fix of PM_MAX vs PM_FAST. That is to say, if I open the terminal and ping google.com, when the screen is off I get 300ms pings and when the screen is on I can get 3ms pings.

This happens whether I change PM_MAX or PM_FAST.

So this isn't the fix for what it's supposed to fix (or maybe I'm doing it wrong, toolchain's wrong, something), but I'll give it a few days to figure out whether my wifi drops more or less. Hopefully less.

(My symptoms are that, on campus, I have no problems with wifi, but sometimes if I leave the wifi zone and then come back, it'll report still having an IP lease and everything, but all pings and connectivity-type things such as web browsing will time-out. Not sure if this is what is being discussed here, but I thought it might help!)

Thanks,
Jeff

PS If you want the zip just to give it a spin, pm me or I might attach it here. That said, it might break everything! No obvious problems on my phone yet, though, so...

EDIT!: Of course, I invite anyone (especially rafpigna; perhaps you've tested this already?) to double check my work. It's possible I might've misplaced something!

I didn't do anything advanced; just pick up the CodeSourcery toolchain (free) for ARM (not GNU/Linux) and then install it on a Linux machine (it's possible with Windows, probably, but it'll be harder with the RAF build.sh). Then, make sure you have make and gcc packages on your Linux machine and then put your sources in the right directory and then try running the build.sh! rafpigna documents his work very well. Thanks rafpigna!

 

[InfX]

Did you remember to actually replace the .ko module, not just zimage ?

 

[linj]

Hello,

Did you remember to actually replace the .ko module, not just zimage ?

Of course.