Phone vibrates randomly, turns on flash

[jessesmith]

I am running a Meizu Pro 5 with Ubuntu version 15.04 r14.

Problem description: About once a week, on a seemingly random time/date, the phone will vibrate and turn on the rear flash. While the vibrating stops after a few seconds, the flash remains on until the phone is powered off. Turning off the display does not disable the flash's light.

This behaviour happens with the default settings and with the vibrate feature disabled for calls & messages. Notifications are turned off for all apps, apart from system settings.

The phone indicates no missed calls or messages and there are no new notifications when the vibrate/flash event occurs. The battery still has plenty of charge and the phone is not plugged in. There are no automatic crash reports filed during these events.

This vibrate & flash event happens about once a week, so far always between the hours of 2:00am and 7:30am. This means the phone wakes me up in the middle of the night about once a week for no apparent reason.

Expected behaviour: Unless a call or message is coming in, the phone should remain silent during the night.

Further information and tests can be provided upon request.

[Michał Sawicz (saviq)]

This happened to me a few times indeed, unfortunately I've no idea how to reproduce that or what's causing it.

One thing for sure is that unity8 isn't. It also seems to be hardware-specific, no other device has done that.

When this happens to you again, will you please post the contents of /var/log/syslog and the output from:

$ adb shell /system/bin/logcat

Maybe it will shed some light...

[Michał Sawicz (saviq)]

FWIW, you can turn the flash off with the camera or flashlight apps.

[Daniel van Vugt (vanvugt)]

Can you check in System Settings to see if there are updates available? System Updates indeed could wake the phone up on a daily basis depending on what channel you have installed. So that would explain the vibration and it always happening daily around the same time.

The flash coming on during a notification could be a separate bug.

[Daniel van Vugt (vanvugt)]

Sorry, you said once a week :P

[jessesmith (jessefrgsmith)]

I checked to see if software updates might be available. Each time the phone did its vibrate + flash event there were no software updates available.

[jessesmith (jessefrgsmith)]

Michal, you asked for some log data. Would the log info you want survive a reboot? I basically rebooted the phone right after the bug triggered the vibrate/light event. But the phone hasn't been used much since the reboot. I powered it off in the morning to avoid further issues. Would the log files be of any use? If not I'm going to have to leave the phone on (in another room) and hope it gets triggered again during the night.

[jessesmith (jessefrgsmith)]

I have a copy of the syslog file which includes records from the time when the vibrate/light bug occurred. Bear with me, please, the syslog on its own is around 18MB.

http://resonatingmedia.com/logs/syslog.txt

The vibrate/light bug happened at approximately August 9th at 02:21. You can see a gap starting at 02:22:21 when I shut off the phone and then the log jumps ahead to August 9th at 09:08:57 when I powered on the device again. That gap is how I found the point at which I noticed the problem and turned off the phone to stop the light from shinning.

Around the time the bug is triggered there is a log entry which reads: "Aug 9 02:21:50 ubuntu-phablet powerd[2426]: set brightness 20". It is my guess that is either the screen or the flashlight coming on and would have happened at the same moment the vibration occurred.

Not sure if the logcat output will be useful here or not, but I am including it too. This logcat data is from the next day, after the phone had been rebooted.

http://resonatingmedia.com/logs/logcat.txt

If I can be of further help tracking down the cause/solution, please let me know.

[Stefan Mikulaj (stefanmikulaj-k)]

I can confirm that this has happpened on my Pro 5 as well.
I noticed low camera light (yellow light) and phone vibrating.
I had to reboot to stop it.

[jessesmith (jessefrgsmith)]

Would disabling the vibration feedback fix this issue? For example, there is this tutorial [1] that explains how to disable keyboard feedback vibrations. Would disabling vibration feedback also prevent the phone from vibrating for any reason at all? Or is the linked tutorial only useful for disabling keyboard vibration feedback?

At this point I'm willing to try some workaround hacks if there is no long-term solution.

[1] http://askubuntu.com/questions/422518/disable-vibration-when-pressing-key-on-ubuntu-touch#472992

[Pat McGowan (pat-mcgowan)]

From the log it seems the modem processor crashed, and the camera LED was explicitly turned on when the CP was reset, why I haven't a clue.

[John McAleely (john.mcaleely)]

@abeato, does the log look like it confirms pmcgowan's theory in #10?

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

@john.mcaleely, Pat is completely right. The modem resets, and after that there is a process called "cbd" which detects this and does:

echo 20000 > /sys/class/timed_output/vibrator/enable
echo enable > /sys/class/leds/torch0/hwen
echo enable > /sys/class/leds/torch0/enable
echo on > /sys/class/leds/torch0/onoff

to start the party. This seems to be a fascinating debugging technique from Samsung to detect modem resets. The problem is that they forgot to remove this from their production code.

Solving this should be a simply matter of removing these calls. cbd looks like the process that loads modem firmaware and controls its booting.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

See also bug #1612381 .

[jessesmith (jessefrgsmith)]

Thank you for the positive update, Alex. Does this mean the next update (I think it's r15) will include the fix for this bug?

[Pat McGowan (pat-mcgowan)]

change status until the device tarball lands in the image

[John McAleely (john.mcaleely)]

@jessesmith - yes, if it continues through QA, it will land in 13 (the
milestone will change from 13 on this bug if that's not true).

On 15 August 2016 at 17:35, Pat McGowan <email address hidden> wrote:

> change status until the device tarball lands in the image
>
> ** Changed in: turbo
> Status: Confirmed => Fix Committed
>
> ** Changed in: canonical-devices-system-image
> Status: Fix Committed => In Progress
>
> ** Changed in: canonical-devices-system-image
> Milestone: None => 13
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1611374
>
> Title:
> Phone vibrates randomly, turns on flash
>
> Status in Canonical System Image:
> In Progress
> Status in turbo:
> Fix Committed
>
> Bug description:
> I am running a Meizu Pro 5 with Ubuntu version 15.04 r14.
>
> Problem description: About once a week, on a seemingly random
> time/date, the phone will vibrate and turn on the rear flash. While
> the vibrating stops after a few seconds, the flash remains on until
> the phone is powered off. Turning off the display does not disable the
> flash's light.
>
> This behaviour happens with the default settings and with the vibrate
> feature disabled for calls & messages. Notifications are turned off
> for all apps, apart from system settings.
>
> The phone indicates no missed calls or messages and there are no new
> notifications when the vibrate/flash event occurs. The battery still
> has plenty of charge and the phone is not plugged in. There are no
> automatic crash reports filed during these events.
>
> This vibrate & flash event happens about once a week, so far always
> between the hours of 2:00am and 7:30am. This means the phone wakes me
> up in the middle of the night about once a week for no apparent
> reason.
>
>
> Expected behaviour: Unless a call or message is coming in, the phone
> should remain silent during the night.
>
> Further information and tests can be provided upon request.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1611374/+
> subscriptions
>

[Pat McGowan (pat-mcgowan)]

Turbo device tabrall landed Aug 29 but the change set didn't call out this fix, assuming it was in there