CM7 Nightly Discussion Thread [Old, please use new thread]

[Guest simonckenyon]

i installed #13 and the battery lasted 24 hours.

i have wifi at home and use that.

i don't have wifi at work.

half way through the day i found out how to see what was using the battery (so i'm slow - ok?)

wifi seemed to be - so i turned it off.

this slowed down the battary consumption - but not by a lot

in any case - 24 horus seems like a good result

in the process of downloading #14

[Guest alex1alex2alex3alex4]

The Saunalahti RIL was also used in kallt_kaffe's JJ/Japanese Jellyfish Froyo ROM. See its first post, search for "Saunalahti". So I doubt that RIL lib alone is the problem (while of course that's not impossible).

Well, there was NO battery drain problem on JJ whatsoever, so ...

[Guest The Soup Thief]

Just noticed on the cm7 download page that the two handsets that got RC2 this morning (the CDMA Hero and the Crespo) both also have N14 for download

What's more, their N14 download files are the same size as their RC2 files

Shurely shome mishtake?

Edited March 8, 2011 by The Soup Thief

[Guest alex1alex2alex3alex4]

Just noticed on the cm7 download page that the two handsets that got RC2 this morning (the CDMA Hero and the Crespo) both also have N14 for download

What's more, their N14 download files are the same size as their RC2 files

Shurely shome mishtake?

I guess the nightly builds are kicked off automagically (for ALL devices), the RC ones manually selectively.

[Guest reluctant_traveller]

limiting or staggering the number of RC2 releases across devices may help to reduce the wall of bug reports slamming into the developers in one go..

[Guest Saransh Agarwal]

flashing it hope it works

YES IT WORKED YEHE

Edited March 8, 2011 by Saransh Agarwal

[Guest Saransh Agarwal]

Hey pls help google apps link now roking from where to download

I m without market n cannot wait to download apps

[Guest Quu]

The Saunalahti RIL was also used in kallt_kaffe's JJ/Japanese Jellyfish Froyo ROM. See its first post, search for "Saunalahti". So I doubt that RIL lib alone is the problem (while of course that's not impossible).

It was addon to stop roaming on Elisa's network. (saunalahti = elisa = saunalahti)

[Guest ootyposoo]

Hey pls help google apps link now roking from where to download

I m without market n cannot wait to download apps

Install gapps, there is link in the first post!

[Guest jayhix]

guys asking about Gapps. download rom manager from the market then you can automatically update from your phone, thats what i do :(

works really well.

Edit, you probably need premium. and er also it doesnt seem to be working today! :/

Edited March 8, 2011 by jayhix

[Guest alex1alex2alex3alex4]

guys asking about Gapps. download rom manager from the market then you can automatically update from your phone, thats what i do :(

works really well.

... which you can't do without installing gapps first - catch 22 :(

[Guest jayhix]

... which you can't do without installing gapps first - catch 22 :(

haha fair point, but in future if you have it installed and choose check for updates it asks you if you want gapps too

[Guest css771]

Okay this may seem absurd at first. But I may have found a way to better battery life. Here goes.

I pulled the /proc/wakelocks from my phone which is on N13. Here is what I found: (Sorry I tried formatting it. But it's not working.)

------ KERNEL WAKELOCKS (/proc/wakelocks) ------

name count expire_count wake_count active_since total_time sleep_time max_time last_change

"rpcrotuer_smd_xprt" 11026 0 42 0 2613920126 946705057 75000006 10143503702533

"rpc_server" 5196 0 0 0 2816315111 1700220077 215005008 10143503322533

"rpc_reply" 5196 0 0 0 2611156746 1549975046 214976674 10143503319199

"rpc_read" 5196 0 0 0 729753361 498945026 3498334 10143503264199

"mmc_delayed_work" 5069 2 0 0 2863151658 84186659 724016669 10142360152537

"power-supply" 75 0 0 0 47504999 20716671 6743334 10140472779185

"power-supply" 12 0 0 0 112428335 105880001 105741667 10140472192518

"rpc_read" 363 0 0 0 31549990 0 3396667 10139977290853

"radio-interface" 61 0 0 0 71870243429 0 3680671716 10138515025859

"event3-198" 374 0 0 0 26961659 0 7596666 10137721569201

"PowerManagerService" 835 0 0 0 1057350602274 402664417240 539826611642 10137564095863

.....................

The log continues on. Now as can be seen here, rpcrotuer_smd_xprt, i.e. the first entry, is the only thing having a wake_count of 42. All the others in the log have 0 (Even ones not shown here.) Correspondingly, in the events log (adb logcat -b events), rpcrotuer_smd_xprt has caused wuite a few wakelocks.

Now the funny part, rpcrotuer is misspelt. In the config files of the kernel, it is always spelt as rpcrouter. So this looked suspicious.

In the kernel source, under arch/arm/mach-msm, there is the file rpcrouter_smd_xprt.c and its object file. In that file I found rpcrotuer_smd_xprt and corrected it to rpcrouter_smd_xprt. And then I compiled a new kernel incorporating this change. I've been experiencing better standby now.

And now, my /proc/wakelocks file looks like this:

------ KERNEL WAKELOCKS (/proc/wakelocks) ------

name count expire_count wake_count active_since total_time sleep_time max_time last_change

"mmc_delayed_work" 2115 0 0 0 767581652 25096658 724025002 4234343441216

"power-supply" 76 0 0 0 47008329 30908332 6661667 4234320466216

"PowerManagerService" 447 0 0 0 336642598226 57337362201 31443286671 4234244227880

"rpc_read" 6471 0 0 0 820113308 188041638 54985001 4234210729546

"rpcrouter_smd_xprt" 16517 0 68 0 4130173347 1264413377 74996672 4234210716212

"qcril" 391 0 0 0 1778955048 183208338 59861669 4234209184545

"rpc_reply" 343 0 0 0 790581692 185348338 32583334 4234208682878

"rpc_read" 753 0 0 0 1735016730 1659966708 338528346 4234208214545

"usb_mass_storage" 0 0 0 0 0 0 0 0

............................................

So there's no more rpcrotuer_smd_xprt anywhere to be seen. And nothing has registered a wake_count in the entire log. I've been running this kernel for over 10 hours now, and my standbt life has improved significantly.

Now just to see whether it's only me, I'm attaching the new kernel if anybody wants to try it. Want to confirm if standby time is mirroring the logs. Let me know if standby time improves anyhow.

md5sum:c482209d7ecebf9f6dd19d182a3dfb63

boot.img

Edited March 8, 2011 by css771

[Guest skymera]

Flashing now...

Edited March 8, 2011 by skymera

[Guest alex1alex2alex3alex4]

And now, my /proc/wakelocks file looks like this:

So there's no more rpcrotuer_smd_xprt anywhere to be seen. And nothing has registered a wake_count in the entire log. I've been running this kernel for over 10 hours now, and my standbt life has improved significantly.

Hmm, but the (now) rpcrouter still has a wake count in your 2nd log ?!?

"rpcrouter_smd_xprt" 16517 0 68

[Guest jayhix]

yeah but... ?

name count expire_count wake_count active_since

"rpcrouter_smd_xprt" 16517 0 68 0

edit: looks like we both spotted it? lol

Edited March 8, 2011 by jayhix

[Guest Victor von Zeppelin]

Okay this may seem absurd at first. But I may have found a way to better battery life. Here goes.

I pulled the /proc/wakelocks from my phone which is on N13. Here is what I found: (Sorry I tried formatting it. But it's not working.)

The log continues on. Now as can be seen here, rpcrotuer_smd_xprt, i.e. the first entry, is the only thing having a wake_count of 42. All the others in the log have 0 (Even ones not shown here.) Correspondingly, in the events log (adb logcat -b events), rpcrotuer_smd_xprt has caused wuite a few wakelocks.

Now the funny part, rpcrotuer is misspelt. In the config files of the kernel, it is always spelt as rpcrouter. So this looked suspicious.

In the kernel source, under arch/arm/mach-msm, there is the file rpcrouter_smd_xprt.c and its object file. In that file I found rpcrotuer_smd_xprt and corrected it to rpcrouter_smd_xprt. And then I compiled a new kernel incorporating this change. I've been experiencing better standby now.

And now, my /proc/wakelocks file looks like this:

So there's no more rpcrotuer_smd_xprt anywhere to be seen. And nothing has registered a wake_count in the entire log. I've been running this kernel for over 10 hours now, and my standbt life has improved significantly.

Now just to see whether it's only me, I'm attaching the new kernel if anybody wants to try it. Want to confirm if standby time is mirroring the logs. Let me know if standby time improves anyhow.

md5sum:c482209d7ecebf9f6dd19d182a3dfb63

Genius. Good job, and it's a silly error to have been made, but I guess it happens to everyone (it still says Cahngelog on the first post, I cba to cahnge it)

Typically, only day I didn't bring my USB calbe to college. Look forward to this when I'm back

[Guest Frankish]

Hmm, but the (now) rpcrouter still has a wake count in your 2nd log ?!?

"rpcrouter_smd_xprt" 16517 0 68

Err i thought the count was the fourth column which is 0 :S

EDIT:

No you're right...lack of sleep :(

Edited March 8, 2011 by Frankish

[Guest don_kamillo]

After flashing, my Blade doesn't see SD card...

[Guest alex1alex2alex3alex4]

yeah but... ?

name count expire_count wake_count active_since

"rpcrouter_smd_xprt" 16517 0 68 0

edit: looks like we both spotted it? lol

:(

I updated again (from N14) with the new boot.img, but that probably wasn't a good idea as subjectively

N14 by itself reduced battery drain, so I probably should have stayed there and monitor it for the day ...

So anyone on vanilla N14 - what are your findings ?

[Guest css771]

Hmm, but the (now) rpcrouter still has a wake count in your 2nd log ?!?

"rpcrouter_smd_xprt" 16517 0 68

Hmm that's right. here's another log I took just after I flashed the new kernel:

------ KERNEL WAKELOCKS (/proc/wakelocks) ------

name count expire_count wake_count active_since total_time sleep_time max_time last_change

"rpc_server" 401 0 0 0 232190025 62311671 149743330 788603848445

"rpc_reply" 401 0 0 0 215206670 50105014 149728331 788603843445

"rpc_read" 401 0 0 0 55338331 38256672 703334 788603801778

"rpcrouter_smd_xprt" 1403 0 3 0 456000020 74213336 74996672 788603766778

"mmc_delayed_work" 393 0 0 0 733613338 6645003 724025002 788290128446

"rpc_read" 26 0 0 0 5016671 4261667 4236667 786634610098

"PowerManagerService" 40 0 0 0 32697365095 2005610045 15300000006 771099131762

"alarm" 18 0 0 0 530941678 427998347 99326667 771062913428

"alarm_rtc" 1 0 0 0 7543333 7541666 7543333 216146711757

Well in practice I seem to have had better battery life today:

18h on standby, wifi on for about 15mins, a few calls and texts. And battery life's still at 58% whereas before it used to be around 20% or less.

Well, if your experience is the same, good. Or else, I'm sorry for the false alarm :( Did not mean to be a troll here :(

[Guest Krinyo]

It's not a false alarm, it's a bug, You've fixed... :(

[Guest css771]

It's not a false alarm, it's a bug, You've fixed... :(

Well not quite the bug I was hoping to fix. But I'm sure my English Profs will be very proud :(

[Guest ufoman]

I've posted this fix to the CM issue tracker.

[Guest AsusFreak]

:(

I updated again (from N14) with the new boot.img, but that probably wasn't a good idea as subjectively

N14 by itself reduced battery drain, so I probably should have stayed there and monitor it for the day ...

So anyone on vanilla N14 - what are your findings ?

Here are my results with N14:

name	   count	expire_count	wake_count	active_since	total_time	sleep_time	max_time	last_change

rpcrotuer_smd_xprt	7163	0	11	0	1567395076	483901695	451228342	8,48089E+12

4:21 hours of having N14: battery 81%

Edit: Sorry, did not see that it's not necessary anymore...

Edited March 8, 2011 by AsusFreak