Device shuts down after Bluetooth has been on for several hours to several days

Bug Reports
#1

REPRODUCIBILITY: 75% (often)
OSVERSION: 4.5.0.21
HARDWARE: Sony Xperia 10 II - Dual SIM - xqau52 - xqau52 - 1.0.0.21 - aarch64
UI LANGUAGE: English (US) (user: en_US, os: en_US.utf8)
REGRESSION: yes (since: 4.5.0.19 - aarch64)

DESCRIPTION:

When Bluetooth is enabled in system settings, the phone will eventually shut down. Or it might crash, restart and timeout waiting for disk unlock. I’m not sure since I’ve never been watching when it happened. The time between activating Bluetooth and the shutdown seems to be at least 2 or 3 hours and less than 3 days. Times are vague because I only notice phone has shut down when I try to unlock it tje next time I need it. This behavior is new in 4.5.0.21. When it isn’t shutting down, Bluetooth behaves no better or worse than previous release -I’d initially been investigating the Bluetooth connection issue with my car I’d reported earlier when this new issue arose.

PRECONDITIONS:

Sfos 4.5.0.21 installed. Bluetooth on.

STEPS TO REPRODUCE:

  1. Upgrade to 4.5.0.21
  2. Enable Bluetooth
  3. Use the phone normally while waiting for it to shut down - don’t turn it off intentionally during this time.

EXPECTED RESULTS:

Phone keeps working until intentionally shut down.

ACTUAL RESULTS:

Phone shuts off spontaneously eventually.

MODIFICATIONS:

  • Patchmanager: no
  • OpenRepos: yes
  • Chum: yes
  • Other: none specified

ADDITIONAL INFORMATION:

I suspect the connection to Bluetooth because the phone only shuts down when Bluetooth is on, but the seemingly random time between activation and the shutdown also leaves room for doubt. I don’t think it’s a new hardware failure because the bug hasn’t appeared when not running Bluetooth. I freely admit the connectuon souds odd, but there doesn’t seem to be anytging else that correlates with the issue occuring.
Device Owner User: defaultuser
Home Encryption: enabled

the initial version of this bug report was created using Bugger 0.9.10+git1
1 Like
#2

Just to get it out of the way: it’s not a low battery shutdown, right?

#3

Maybe a kernel oops or something alike.

Can you enable persistent journalling, and dump the just-before-reboot/crash logs?

#4

Right. Every time I rebooted – sometimes needing the hard-reset button combo – the battery has been at 60% or better.

#5

Seems a bit odd since the changelog / release notes from 4.5.0.19 to 4.5.0.21 do not mention bluetooth.

1 Like
#6

  1. OK, right now I’ve got the phone collecting kernel logs in the event of Fatal messages. JIC anything happens when I’m not expecting if and maybe it’ll be enlightening if it does.

  2. Reading the docs, it looks like the Persistent log collection should be initiated right before attempting to provoke the fault, so I’ll have to wait to poke that bear until my wife and I are in earshot of each other. She really doesn’t like me to be unreachable, and will let me know what she thinks of my “nerd phone” if I don’t answer.

@emva I searched the changelog for anything about Bluetooth, since I was hoping to see something related to hands free profile and the weird connect issue I was having. Seeing nothing, I didn’t expect any changes, but I still wanted to test if anything got better, worse, or different. What I certainly didn’t expect in any case was to get a guru meditation.

2 Likes
#7

Okay, I’ve done Round #1 of the persistent logs process and am activating Bluetooth . . . let’s see if anything happens tonight.

#8

I got the phone to shut down late this morning. Had to do the Round #2 of gather-logs.sh over ssh after getting home since the home screen keeps showing the spinning spinny thing of patience and I can’t open up the drawer of applications further than the top 4 quick access apps. Persistent logs are packed up in a gz.

Anyone got an idea of what should I look for in the logs for further troubleshooting?

#9

So the timeline goes: turned on Bluetooth about 16:16 on August 22 and it shut down sometime between 11:00 and 11:35 on August 24, that’s around 43 hours or so if I’m ciphering right.

I definitely needed the hard reset key combo of holding the volume-up and power buttons to restart. Battery was at 88% after reboot. The spinning patience spinner and the lack of application drawer opening thing persisted until I did a normal power off/power on. After that phone operation seems normal.

#10

did you find anything unusual in the logs befor the shutdown?

#11

I didn’t see anything, but I’m not completely sure what I’m searching for. No entries in logcat after turning on Bluetooth on the 22nd thru powering the phone back on on the morning of the 24th. Nothing in journal.

BTW, I’ve had Bluetooth off almost the entire time since August 24 – I used headphone sunglasses for a short time at the pool to listen to online radio – and no shutdowns in that time period.

#12

OK, a little more information. It’s a lockup/freeze not a shutdown.

Since upgrading to x.x.x.24, I periodically turn on Bluetooth to use headphones or to attempt to use the car speaker. And if I forget to turn it off, it will still eventually cause the device to unintendedly shut down.

Well, I got the bug to show up more quickly the latest time, and this time I could see that the phone hadn’t shut down but had actually locked up. I got a message waiting notification (the blue light) before the problem occurred, and hadn’t acknowledged it yet, so I found the light on steady but the phone unresponsive. Plugging it in to computer USB got nothing and regular power down didn’t turn it off. So, I guess this explains why I need to do the volume up/power/three buzz maneuver before restarting: it’s not dead but somehow still powered up but locked. And pining for the fjords, of course.

1 Like
#13

What would the device normally do when you connect it via USB? show as MTP?

I guess I’m asking if you have SSH enabled, or even telnet (I’m sure somebody can find how to enable it for official devices).

Since this is bluetooth related, it does sound like a kernel issue, but I seldom think that a kernel would loop without crashing and restarting. It sounds more plausible to be userland crashing and bringing down some important stuff with it, be it lipstick, mce or whatever. It could still be reachable via SSH…

2 Likes
#14

Thanks for the ideas!

I’ve got the USB behavior set to “ask when connected” which I guess is the least helpful setting for this circumstance. That’s a good idea to try SSH-ing into the device when it’s locked. I hadn’t thought of that, but then again, I thought it was off, not locked until this last incident. I suppose I’ll change the USB mode before I poke the bear next time. I also now wonder if wifi would be possibly still working in “locked” state.

#15

Some more data . . .

I had the problem again, this time at home where I “control the horizontal and vertical” on the network, so I could investigate a little more. It was accidental, since I’d left Bluetooth on after a car ride, so I didn’t have USB set to Developer Mode but rather “Ask” mode.

I can now say that the device is running and non-responsive rather than shut down. I could see the phone on my wifi network, but could not SSH into it. I could also connect it by USB to computer but didn’t see anything on the phone or computer status. I know I had an incoming call during the outage, but the phone didn’t alert me and also the paired Amazfit on my desk didn’t indicate incoming call either. As before, it required the two-button power-off reset to shut device down from locked up condition.

#16

Happened again. I had just been on a Bluetooth call and left Bluetooth turned on. Next time I pulled the phone our of my pocket and tried to wake with the power button, the LED came on green and turned off again, less than a full second, I think. I don’t remember seeing that before, but I coulda missed it. I had USB set to developer mode and was near a PC, so I plugged it in. The LED came on briefly red, then turned off and the “bootloader unlocked” screen appeared followed by the Sony logo then the “charging while off” animation. I’m about to boot normally . . . and normal boot works, didn’t need the two finger salute this time.