Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

[Kernel][GPL] msm_hsic_host wakelock fix (Now with WiFi notification fix!)

OP thracemerin

16th February 2013, 05:53 AM   |  #191  
thracemerin's Avatar
OP Recognized Contributor
Flag Toronto
Thanks Meter: 5,823
 
5,458 posts
Join Date:Joined: Oct 2011
Donate to Me
More
Quote:
Originally Posted by sotong

I agree with you, it must be my set up because it does not make sense also. Could be a random coincidence. Is there a quicker way to test this (i read about pinging etc) instead of waiting several minutes when the phone is in standby?

Edit: You are correct. Just sent a gmail to my phone (on V1) and nothing came in There goes my short-lived joy! Or gmail is having issues also.

I guess that they more or less confirmed in this thread: http://forum.xda-developers.com/show....php?t=2072930 that Google did not fix the WiFi notification issue, so I don't think it's you, blame Google.
The Following 2 Users Say Thank You to thracemerin For This Useful Post: [ View ]
17th February 2013, 12:55 AM   |  #192  
thracemerin's Avatar
OP Recognized Contributor
Flag Toronto
Thanks Meter: 5,823
 
5,458 posts
Join Date:Joined: Oct 2011
Donate to Me
More
New build in post 2 (see there for changelog)

I added a couple more CAF patches and used the data fix that Faux123 used in his enhanced stock kernel instead of the one I used previously, I want to see what happens with this as it relates to the wakelock and data use to see how it goes, if it doesn't work I'll install my previous solution.

Happy Flashing.
The Following 2 Users Say Thank You to thracemerin For This Useful Post: [ View ]
17th February 2013, 05:00 PM   |  #193  
chrone's Avatar
Senior Member
Flag Surabaya
Thanks Meter: 390
 
1,027 posts
Join Date:Joined: May 2012
More
Quote:
Originally Posted by thracemerin

New build in post 2 (see there for changelog)

I added a couple more CAF patches and used the data fix that Faux123 used in his enhanced stock kernel instead of the one I used previously, I want to see what happens with this as it relates to the wakelock and data use to see how it goes, if it doesn't work I'll install my previous solution.

Happy Flashing.

i'm testing your v3 right now, will post the log tomorrow now after full day use.
no need to test v1 since it's the same as stock and i've posted the bbs log above, right?
17th February 2013, 05:22 PM   |  #194  
thracemerin's Avatar
OP Recognized Contributor
Flag Toronto
Thanks Meter: 5,823
 
5,458 posts
Join Date:Joined: Oct 2011
Donate to Me
More
Quote:
Originally Posted by chrone

i'm testing your v3 right now, will post the log tomorrow now after full day use.
no need to test v1 since it's the same as stock and i've posted the bbs log above, right?

Yeah v1 is the same as stock.
The Following User Says Thank You to thracemerin For This Useful Post: [ View ]
17th February 2013, 06:40 PM   |  #195  
floepie's Avatar
Senior Member
Flag Amsterdam
Thanks Meter: 396
 
1,840 posts
Join Date:Joined: Feb 2006
More
Quote:
Originally Posted by sotong

That is correct. I just did further testing again:

1. Flash back to stock 4.2.2 kernel. Wait 5 mins. Sent gmail to my phone. Notification did not come in until i turn the screen on.
2. Flash to your V1 kernel. Wait 5 mins. Sent gmail again, and i got the notification almost immediately.

I am also puzzled as to why this is happening. But i am not complaining! Will test your V2 now. Thanks for your efforts

Sending yourself a gmail turns out to be a very poor test. Invariably, if I send myself an email, notification delays are very random, and this has been confirmed by others on this board. However, getting emails from 3rd parties is much more reliable for delay testing. It may have something to do with "loopback" settings on the router. In any case, if you have a router which flushes its ARP cache every couple minutes, you will get delays (up to 15 minutes) because Google hasn't updated the wifi driver to offload ARP broadcast requests. They decided battery life was more important, so they chose to drop requests entirely when the screen is off.

Fortunately, if you have a dd-wrt router, you can set a static IP address from the router to get around this issue.
Last edited by floepie; 17th February 2013 at 06:44 PM.
The Following User Says Thank You to floepie For This Useful Post: [ View ]
17th February 2013, 06:42 PM   |  #196  
thracemerin's Avatar
OP Recognized Contributor
Flag Toronto
Thanks Meter: 5,823
 
5,458 posts
Join Date:Joined: Oct 2011
Donate to Me
More
Quote:
Originally Posted by floepie

Sending yourself a gmail turns out to be a very poor test. Invariably, if I send myself an email, notification delays are very random, and this has been confirmed by others on this board. However, getting emails from 3rd parties is much more reliable for delay testing. It may have something to do with "loopback" settings on the router.

True, but the WiFi issue is definitely not fixed, I tested it using the ping method. If I used a PC that hadn't previously connected to the phone while the screen was off, the pings timed out, as soon as I turned the screen on they'd work until the ARP timed out, then it would go back to time out.
Last edited by thracemerin; 17th February 2013 at 06:44 PM.
The Following User Says Thank You to thracemerin For This Useful Post: [ View ]
17th February 2013, 09:15 PM   |  #197  
Senior Member
Thanks Meter: 113
 
800 posts
Join Date:Joined: Jan 2010
Theracemerin, having upgraded to 4.2.2 (CM10.1 2/16) and using you v3 fix, my wakelock performance isn't as good (about 30 mins over 10 hours of sleep with wifi on) when compared to the older v2 (for 4.2.1 built 2/4) version I was using before. Hopefully you can add the rest of your fixes you had for the 4.2.1 kernel to the 4.2.2 kernel.
The Following User Says Thank You to jakejm79 For This Useful Post: [ View ]
17th February 2013, 09:21 PM   |  #198  
thracemerin's Avatar
OP Recognized Contributor
Flag Toronto
Thanks Meter: 5,823
 
5,458 posts
Join Date:Joined: Oct 2011
Donate to Me
More
Quote:
Originally Posted by jakejm79

Theracemerin, having upgraded to 4.2.2 (CM10.1 2/16) and using you v3 fix, my wakelock performance isn't as good (about 30 mins over 10 hours of sleep with wifi on) when compared to the older v2 (for 4.2.1 built 2/4) version I was using before. Hopefully you can add the rest of your fixes you had for the 4.2.1 kernel to the 4.2.2 kernel.

You're absolutely right, it's not. Faux123s solution to the data problem was to decrease the USB bus suspend time by 20% from the original, my solution from 4.2.1 was to use the CAF patch that set it to 0 as soon as the data stopped, this caused a problem if the data stream stopped momentarily it would get permanently stuck. I added a few additional patches to make sure that this wouldn't happen if it were just a momentary stop in the stream, so Faux123s solution reduces the wakelock time, but not to the same degree as mine, his patch is safer from a data drop standpoint though.

Edit: The new HEAD in my git has all my old patches from 4.2.1, I'm running a few tests on it to make sure we're good to go before pushing a test release.
Last edited by thracemerin; 17th February 2013 at 09:24 PM.
The Following 2 Users Say Thank You to thracemerin For This Useful Post: [ View ]
17th February 2013, 09:26 PM   |  #199  
Senior Member
Thanks Meter: 113
 
800 posts
Join Date:Joined: Jan 2010
OK, that makes sense, I never really suffered from the data drop issue, maybe we could get a little more aggressive than just 20% (assuming you are saying it was reduced by 20% i.e. from 10 to 8 and not reduced to 20% i.e. from 10 to 2)

EDIT: OK sounds good, I will sit patiently.
The Following User Says Thank You to jakejm79 For This Useful Post: [ View ]
17th February 2013, 09:27 PM   |  #200  
thracemerin's Avatar
OP Recognized Contributor
Flag Toronto
Thanks Meter: 5,823
 
5,458 posts
Join Date:Joined: Oct 2011
Donate to Me
More
Quote:
Originally Posted by jakejm79

OK, that makes sense, I never really suffered from the data drop issue, maybe we could get a little more aggressive than just 20% (assuming you are saying it was reduced by 20% i.e. from 10 to 8 and not reduced to 20% i.e. from 10 to 2)

Yeah, 20% from original (ie 200->160).

See here: https://github.com/thracemerin/Mako/...7d20dd761e8526

I know it looks like I raised it from 0 to 160, but there was a previous patch that set it to 0 from 200 here: https://github.com/thracemerin/Mako/...f705ea8c812c3c
Last edited by thracemerin; 17th February 2013 at 09:30 PM.

The Following User Says Thank You to thracemerin For This Useful Post: [ View ]
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes