High battery drain with bluetooth headset connected about local_manifests HOT 44 CLOSED

Any news with the latest build?

from local_manifests.

I have the same problem with 20131108 build on mango.

Battery drain doesn't begin at boot if bluetooth is on, but only when a device is connected; but turning off bluetooth doesn't stop the device battery from draining afterwards. A reboot alleviates the problem until you connect any device.

from local_manifests.

Almost the same here with smultron and build 20131108.
High battery drain if BT headset is connected. At least it stops if BT is disabled.

from local_manifests.

Sorry, my mistake again. Drain stops indeed when bluetooth is turned off.
Still present with the last nightly, 20131112.

from local_manifests.

Maybe this is a solution?: https://jira.cyanogenmod.org/browse/QSDB-7

Found out it is not a solution, as this patch seems to be applied already.
:-(

from local_manifests.

Hi,
I´m got a Mango on 10.2-20131112 and i´m expiriencing the same issues:
Battery draining while BTheadset connection an also draining goes on after disconnection.
Turning off an on bluetooth seems to stop the drain.
Android OS is reportet as no.1 battery consumer. While phone isn´t going to deepsleep, WLdetector showing "suspend_backoff" causing Wakelocks.

from local_manifests.

avelos156 commented 2 months ago
Hello Mike,

As described above by burny1s. One comment though. In my case, the BT symbol does not always stay blue after I leave the car. It depends. In the rare case that it stays blue, my mobile will definately crash after a while.. And I have noticed (although I'm not 100% sure) that draining starts when I enter the car (i.e. once the devices get paired).

Some links for logs below. It contains a reproduction of the battery drain issue. Hopefully it's what you need.
https://dl.dropboxusercontent.com/u/38633490/LX%20Logs/BetterBatteryStats-2013-10-01_103807319.txt
https://dl.dropboxusercontent.com/u/38633490/LX%20Logs/dmesg-2013-10-01_103807862.txt
https://dl.dropboxusercontent.com/u/38633490/LX%20Logs/logcat-2013-10-01_103807697.txt

Best regards,
Konstantinos

avelos156 commented a month ago
Reading the changelog, bluetooth stack is a work in progress. Just to let you know that with the cm10.2-20131013 nightly, I have enabled bluetooth on my device (anzu) for about half a day without any pairing. Battery drain, according to betterbatterystats, was about 3.2%/h without any apparent reason. Drilling down the menus, I couldn't locate anything that would indicate the bluetooth as the source of the drain. However, when I deactivated bluetooth, draining stopped. For your convenience, I have taken some new logs from betterbatterystats. You may find them here:

https://dl.dropboxusercontent.com/u/38633490/LX%20Logs/BetterBatteryStats-2013-10-15_084427876.txt
https://dl.dropboxusercontent.com/u/38633490/LX%20Logs/dmesg-2013-10-15_084428333.txt
https://dl.dropboxusercontent.com/u/38633490/LX%20Logs/logcat-2013-10-15_084428179.txt

from local_manifests.

With holidays and some spare time ahead what can I do to help in fixing this?

from local_manifests.

Well I didn't have time to look into this, I was busy fixing a lot of other stuff. First thing to try is updating msm_serial_hs kernel driver from newer codeaurora kernels (that worked for some other devices a few months ago)

If you can build from sources you can test that.

from local_manifests.

Can't repoduce on Haida, latest RC build.

Device : Sony MW600, normal and acceptable battery drain when headset on - no drain when headset off + BT on.

from local_manifests.

Happy new year,

I used the time to setup a build environment. I can build and flash now.
While now investigating the drain further I noticed that dmesg gives me a warning that there is a wakup interrupt msm_hs_wakup still pending and that it will not go to deep sleep. This message comes from pm.c where a check is included if the devices can go to deep sleep.
It checks for a bit (IRQS_PENDING) in an internal interrupt structure.
Does someone know how I can reset this bit, so that the interrupt is not marked pending anymore?

from local_manifests.

@lanmarc77 I have updated the msm_serial_hs driver but I don't have the time to test it. Would you be able to test the new changes if I update the kernel source on github?

from local_manifests.

@mikeNG I definitely will. Thank you.

from local_manifests.

changes are already up

from local_manifests.

on it...

from local_manifests.

build from last night

1. using a BT headphone: works well
2. turning off BT and headphone: drain <1%
3. turning on BT (but not HP): drain ±10%
4. turning off BT again: drain ±5%

I will try to get meaningful logs / data

from local_manifests.

Finally CM11 compiled (should get a faster machine). But no luck. The problem even got worse.
CM10.2 does not go into sleep mode after the first BT device connected. CM11 does not even goto sleep mode once BT was enabled independent if a device was connected or not.
dmesg shows the same message in CM11 as in CM10.2:
Wakeup IRQ 264 msm_hs_wakeup pending, suspend aborted

from local_manifests.

@mikeNG I see there were a bunch of msm_serial_hs related changes in the 3.4 kernel tree a couple days ago. any plans for a new build soon so we can test them?

from local_manifests.

new 10.2 build is already out & 11.0 builds are rolling

from local_manifests.

Hi @ALL
I just flashed the new build, but no news due bluetooth draining problem. Same as before. Haevy drain after first BT connection.
I´m using Llama to restart BT after last disconnection.

Thanks for your work!

from local_manifests.

On CM10.2-RELEASE I could work around this problem by automatically disabling and re-enabling Bluetooth after the connection to my car was lost (using Llama).
On CM10.2-20140207 the battery drain starts as soon as Bluetooth is enabled without ever having connected to a device. This is pretty annoying because now I have to remember to enable Bluetooth manually before getting into my car (holding a mobile phone in one's hand while driving is illegal here).
Any ideas or plans to fix this? Reverting to the behaviour of CM10.2-20131204-RELEASE would be fine by me.

from local_manifests.

I can still confirm that bug on latest (today) nightlies with this kernel. My Xperia Ray drained over 40% within 4 hours with headset paired, but without calls.

from local_manifests.

Is this somehow related to BLE?

from local_manifests.

Please try latest build and provide logs if this still happens

from local_manifests.

Still present using cm-11-20140517-UNOFFICIAL-LegacyXperia-urushi.zip.
If you want logs so let me know please what kind of logs and how to get them.

from local_manifests.

I can also confirm that this problem persists on Mango as well on 20140512 build.

http://enveraltin.com/tmp/dmesg.gz
http://enveraltin.com/tmp/logcat.gz

I'm testing it with a stereo bluetooth headset if that makes any difference, I also have a Sony Smartwatch SW2 connected but it seems like the headset is the killer. SW2 doesn't change much, but when I get the headset connected Android OS jumps to the top of the battery consumer list with 20% or more.

from local_manifests.

Hola,

What's with the 'rpcrotuer_smd_xprt'? It's the worst offender, apparently.

shell@mango:/data $ cat /proc/wakelocks                                        
name    count   expire_count    wake_count  active_since    total_time  sleep_time  max_time    last_change
"PowerManagerService.WakeLocks" 296 0   0   0   2919569480508   2526621736225   2482104299360   6113409406436
"alarm" 371 0   0   0   6250884945  4789123629  255706787   6113314008483
"KeyEvents" 1272    0   0   0   2515655551  382537846   636627197   6106488324890
"alarm_rtc" 2   0   0   0   2655029 0   1556397 250811144710
"power-supply"  41  0   0   0   263822894   208343513   11413574    6078806348574
"wl1271_wake"   6649    0   0   0   7099456593  3662445181  354492187   6077588941365
"rpc_reply" 103 0   0   0   70922605    18341065    35034181    5684008893737
"rpc_read"  131 0   0   0   15136641    8514400 488281  5684008222350
"rpcrotuer_smd_xprt"    3219    0   0   0   404899566   85784912    8358482 5684007978209
"power-supply"  114 0   0   0   57311944    50506599    1159668 5504348432310
"rpc_reply" 113 0   0   0   13610826    12207033    1708984 5504347699889
"rpc_read"  120 0   0   0   12023882    10467535    335694  5504347547301
"mmc1"  0   0   0   0   0   0   0   0
"main"  8   0   0   0   791964273462    0   336372690158    5308485120580
"PowerManagerService.Broadcasts"    14  0   0   0   20451080369 9854858404  7403991700  5308034772678
"qcril" 586 0   0   0   1465440514  90148927    301635741   5308011243626

from local_manifests.

Testing something new in the next build: LegacyXperia/android_kernel_semc_msm7x30@b720011

In my tests, battery drained about 3% per hour with BT headset paired

from local_manifests.

Unfortunately the 20140604 mango build doesn't help. But audio skips are
gone, cheers for that one ;)

Is there anything I can do to help?

Enver

from local_manifests.

Oh wow, that Android OS thing was probably unrelated to bluetooth problem. I did a reboot and noticed no more battery drain. Apparently this problem is gone :)

Thanks!

from local_manifests.

Unfortunatelly, I can't confirm that it was resolved on cm-11-20140604-UNOFFICIAL-LegacyXperia-urushi.zip. I charged phone to 100%, restarted and let it for an hour and half just with bluetooth and gsm on. Otherwise I didn't use it. Nothing was connected to the bluetooth, just it was on. The results are:
Time: 1h39m
Battery dropped: 100%->92%
In baterry stats: Android OS 75%, keep awake 1h39
In BetterBatteryStats: kernel wakelock: msm_serial_hs_dma 1h39m

from local_manifests.

My question is: what is the point in leaving BT enabled with no paired devices?

from local_manifests.

The point in my case is entering one of my cars and have it automatically connect to my phone. Otherwise I have to enable bluetooth manually as soon as someone calls me or I want to call someone. Which is illegal in Germany while driving.

from local_manifests.

The point is that when you have no paired devices, BT keeps scanning for nearby devices and battery will drain. I don't think there is a solution for that. We already did whatever we could, I am pretty sure we can't improve anything else

from local_manifests.

Just enable BT before you enter your car

from local_manifests.

That's like saying "just get up from the couch" when someone complains that his TV remote does not work.

The stock ROMs do NOT have this issue, and the CM10.2-RELEASE build from december or so only shows the issue once a BT device was actually connected. The scanning alone does not seem to be the problem.

from local_manifests.

When the devices are around so they will get connected automatically without further intervention.
For example: I enter the car and the phone connects automatically to the radio once the car is started so that I can use the handsfree or play music from the phone. It would be annoying to find out that I forgot to turn on the BT only when I drive and someone calls. In addition when the car radio gets connected so it triggers the AutoGuard.

from local_manifests.

Well, if you find a better solution, propose it. I have been trying to fix BT for over a year and this is the best I can do for now.
Mind that I never use BT and I had to purchase a BT headset just for testing.

Stock rom has nothing to do with my builds. All the drivers are 100% different and the ICS ones cannot be used of course.

I understand this is an issue for some people but I am sick of being literally the only person trying to resolve issues like this for months and have a bunch of people demanding fixes in the bugtracker & in the forums

from local_manifests.

There is actually 1 last thing to try, I can post some test kernels here if you want

from local_manifests.

@dlastov
Im still on cm10.2 facing this problem. I´m using Llama as a woraround.
It is turning on bluetooth when leaving known Wifi´s and turning of BT while entering known Wifi´s
Also I´m leting it restart BT after disconecting from Bt-devices.
Maybe this could help you.

from local_manifests.

Thanks a lot anyway. This ROM is certainly much better than the stock ICS. A half year ago I was willing to buy a new phone and eventually I decided to give a last chance to it by rooting and trying some utilities like Mount2SD. Eventually I ended up with your ROM and probably that will extend the life of my phone by another year at least.

Llama, yes I use it too, somehow it does not work 100%, but it is acceptable workaround :-)

from local_manifests.

@mikeNG I'd be very happy to test it.

from local_manifests.

@mikeNG No offense meant. I am very grateful for your work - if this can't be fixed, so be it. LXperia is still a thousand times better than the stock ROM.
I have been living with it for five months now and I am getting used to the workarounds like Llama.

from local_manifests.

First couple of days with 20140620 seemed ok, but now every time I turn BT on it's msm_serial_hs_dma wakelock, and it stays there until I turn BT off and reboot. The phone (mango) never goes to deep sleep and discharges in 2-3 hours. I use it with Pebble all the time. I'd be happy to test experimental kernels.
Also, and I do apologise for posting something you've probably already seen, seeing how you've been fighting with this bug for months, and which may be irrelevant, but just in case:

http://permalink.gmane.org/gmane.linux.serial/4617
http://blog.cryptomilk.org/2012/05/

from local_manifests.