1032233 - [Flame][2.1] After rebooting in airplane mode, time and date can be all wrong [Manual Time Setting]

Status: RESOLVED FIXED

(Firefox OS Graveyard :: GonkIntegration, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

STR:
- Switch Airplane Mode on
- Restart
- Date or Time or both can be wrong.
(- set them manually right in Settings, and restart, they are wrong again, at least occasionally)

Comment 1

[Dylan Oliver [:doliver]]

I'm able to reproduce something like this with an OpenC running 2.0. If I turn on airplane mode and restart, it always resets the time to 1:52am. 

And earlier today with a Flame running 2.1 I did several restarts and got a seemingly random time with each restart, but I'm not able to reproduce this consistently.

Comment 2

[Jason Smith [:jsmith]]

QA Wanted to branch check.

Comment 3

[Mark Banner (:standard8)]

Do you have automatic time setting turned on? I see this but only when it is turned on. This feels related to bug 1032101.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

You can't set time/date if the automatic time setting is on. So
(- set them manually right in Settings, and restart, they are wrong again, at least occasionally) wouldn't be possible.

Comment 5

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Triage: +, although this is not a Settings app bug.

We have seen various bugs from dogfooders around incorrect time and so far nobody is able to identify who is at fault here, because this is extremely hard to reproduce, even for QA. I recommend we implement something in Gecko that will make a persistent log on time and timezone change, and we can start debug from it.

Comment 6

[Asa Dotzler [:asa]]

This is *not* hard for me to reproduce. What can I do to help pinpoint the source of the problem. I can repeat this consistently on a Flame with the 122 build of v1.3.

Comment 7

[Asa Dotzler [:asa]]

Steps

1. Flash 122 build of 1.3
2. Set correct time manually
3. Wait for "Set Automatically" to be available (it seems to not be available all of the time? maybe wifi wasn't up yet?)
4. Switch to set automatically
5. Put phone in airplane mode and restart

Result: both date and time are wrong. 

Re-enable set automatically and the date and time are corrected.  

Set Automatically goes crazy when there's no network access is my theory.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #2)
> QA Wanted to branch check.

comment 7 answers this - reproduces on 1.3. We need to do a device check here as well.

Comment 9

[Karl Thiessen [:kthiessen, he/him]]

This one bit me, not even during a restart, but just enabling USB debugging.  Time jumped about 22 hours into the future, and I had to toggle "Set automatically" off and back on to restore the time.

I'm on a Flame running 2.0, Git commit 43226cf5, dated 2014-07-01 21:46:43.

Comment 10

[Mark Banner (:standard8)]

Note: Based on comments 0 - 5 I think this bug is for the case where you're not touching set automatically at all - it sometimes varies if you're in flight mode.

I think Bug 1032101 covers more accurately the set time automatically case.

Comment 11

[Eric Kramer [:Kramer]]

This issue does NOT repro on Buri 2.1, Buri 2.0 Buri 1.4 or Buri 1.3. (I was able to repro the issue on Flame using the steps on Comment 7)

Buri Master (2.1)
BuildID: 20140623073039
Gaia: bd5065ced020014df5fd45259fba1ac32d65673b
Gecko: 335b6610fe0c
Version: 33.0a1 (Master) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Buri 2.0
BuildID: 20140702063010
Gaia: 085cdbf16dfd5249786016ac8ceafa1a54e88497
Gecko: a6e69640a00b
Version: 32.0a2 (2.0) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Buri 1.4
BuildID: 20140702160204
Gaia: 5f5a05e454960872d6d7766f322e1ce837de7458
Gecko: 137f0fa03d4a
Version: 30.0 (1.4) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0


Buri 1.3
BuildID: 20140702223056
Gaia: e08beb0297aff472b5c84437e9d7eaf8c0400a29
Gecko: cecdb4197b6e
Version: 28.0 (1.3) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0

Comment 12

[Dave Hylands [:dhylands]]

I flashed the 122 base image (and just that) and I wasn't able to reproduce the problem.

As soon as I flashed master (using ./flash.sh) I was able to reproduce the problem (and the year went back to 1970).

This suggests that something we're flashing is breaking the RTC.

What I did:
 - went into settings - verified date and time were correct
 - put phone into airplane mode
 - did a power off
 - did a power on

Comment 13

[Michael Vines [:m1] [:evilmachines]]

Try putting the blobs in /system/b2g/distribution/bundles/b2g_time back after the ./flash.sh

Comment 14

[Mark Banner (:standard8)]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #13)
> Try putting the blobs in /system/b2g/distribution/bundles/b2g_time back
> after the ./flash.sh

So far, this seems to have fixed my time issues in bug 1032101, that seem related. I've never reproduced the airplane mode issue.

As a summary I:

Flashed v122 with ./flash.sh

Then:

adb remount && adb shell stop b2g && adb pull /system/b2g/distribution/bundles/b2g_time && adb shell start b2g

Then from the B2G_Flash_Tools repo:

./flash_pvt -w

and shallow (gecko + gaia) flashed latest master. Finally:

adb remount && adb shell stop b2g && adb push {b2g_time.so,chrome.manifest,timeservice.js} /system/b2g/distribution/bundles/b2g_time && adb shell stop b2g

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

I copied those files to distribution/bundles/b2g_time, but doesn't help.
Time and date are still random after reboot.

Comment 16

[Ting-Yu Chou [:ting] (away)]

On Flame I saw this when change date/time from Settings app:

  <6>[  314.408413] alarm_set_rtc: Failed to set RTC, time will be lost on reboot

which AdjustSystemClock() is trying to write to RTC, but it is failed because of:

  qcom,qpnp-rtc-write = <0>;

And when boot up I saw:

  <6>[    4.604549] qcom,qpnp-rtc qpnp-rtc-f4511000: setting system clock to 1970-01-09 03:12:53 UTC (702773)

which rtc_hctosys() set system time to what RTC has.

At the 1st boot after |./flash.sh|, I saw date is called with a correct date/time to set system time, I am still checking where is this form.

Comment 17

[Dave Hylands [:dhylands]]

The flash.sh script sets the phone's time to match the host time.

https://github.com/mozilla-b2g/B2G/blob/master/flash.sh#L44

Comment 18

[Ting-Yu Chou [:ting] (away)]

So user's setting will be gone after reboot since RTC can't be overwritten. I tried to update kernel with "qcom,qpnp-rtc-write = <1>;" in kernel/arch/arm/boot/dts/msm-pm8110.dtsi, but the device can't boot up, it shows a gray screen.

I am not sure what is our backup plan if HAL AdjustSystemClock() is failed updating RTC, and the device can't reach NITZ or SNTP.

BTW, there's another path (not automatic update) sets system time:

  http://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/RadioInterfaceLayer.js#3516

Comment 19

[Ting-Yu Chou [:ting] (away)]

I tried also the suggestion in comment 13, but coulnd't push to /system/b2g, it is read only.

Comment 20

[Mark Banner (:standard8)]

(In reply to Mark Banner (:standard8) from comment #14)
> adb remount && adb shell stop b2g && adb push
> {b2g_time.so,chrome.manifest,timeservice.js}
> /system/b2g/distribution/bundles/b2g_time && adb shell stop b2g

That last part should have been:

adb remount && adb shell stop b2g && adb push . /system/b2g/distribution/bundles/b2g_time/. && adb shell start b2g

However, after more testing, I'm not 100% convinced this is working when I thought it was when I wrote comment 14, but it does seem far improved.

Comment 21

[Dave Hylands [:dhylands]]

And after following comment 20, I see this in logcat:

> 04:00:00.001 296/296          QC-time-services  D   Lib:time_genoff_operation: pargs->base = 2
> 04:00:00.001 296/296          QC-time-services  D   Lib:time_genoff_operation: pargs->operation = 1
> 04:00:00.001 296/296          QC-time-services  D   Lib:time_genoff_operation: pargs->ts_val = 0
> 04:00:00.001 296/296          QC-time-services  E   Lib:time_genoff_operation: Connection failed !!
> 04:00:00.001 296/296                     Gecko  I   Error reading system time
> 04:00:00.001 296/296                     Gecko  I   Error unable to set time. Time will be lost after reboot

Comment 22

[Michael Vines [:m1] [:evilmachines]]

Did you remove the time_daemon from the original device image?

Comment 23

[Dave Hylands [:dhylands]]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #22)
> Did you remove the time_daemon from the original device image?

Not that I removed it, but it wasn't in my image. When I did:

adb root && adb remount && adb push backup-flame/system/bin/time_daemon /system/bin && adb shell chmod 0755 time_daemon

then things started to work. I could set the time in airplane mode, do a restart and it would startup with the correct time.

Comment 24

[Dave Hylands [:dhylands]]

Attachment: Add time_daemon and b2g_time

I tried this patch (from device/t2m/flame) and things work better, but it doesn't always "stick".

On several occaisons, the phone came up with the wrong timezone, and one time it came up as 1970.

Now those times, I wasn't in airplane mode, but I also don't have a SIM and wasn't connected to Wifi.

So here's what I observe.

If I use this patch and remove the call to update_time from flash.sh then what I see is this:

./flash.sh - sets time to the timestamp of out/target/product/flame/system.img (i.e. build time)

If I ./flash.sh and restart, the time stays the same.
If I ./flash.sh and change the timezone and restart, the date reverts to 1970
If I ./flash.sh and just change the time and restart, the date reverts to 1970

So far, the only way I can get the date/time to stick is to do:
./flash.sh
set the date & time & restart
set the date & time a second time and restart

Comment 25

[Dave Hylands [:dhylands]]

Oh yeah - I just realized that I have the FTU app configured off in my build. I'll need to turn it back on and see how things behave.

Comment 26

[Michael Vines [:m1] [:evilmachines]]

(In reply to Dave Hylands [:dhylands] from comment #25)
> Oh yeah - I just realized that I have the FTU app configured off in my
> build. I'll need to turn it back on and see how things behave.

Ah, you might be suffering from bug 1000352

Comment 27

[Dave Hylands [:dhylands]]

I tried flashing with FTU enabled.
I entered the date and time in the FTU app
I restarted and the date/time reverted to the build date/time.

I went into settings, set the date/time again, restarted, and the date came up in 1970.

I went into settings, set the date/time for a 3rd time, and the date came up correctly.

So there seems to be some improvement with this patch, but there is definitely an issue getting the date/time set for the first time.

I'm going to put my WIP patch up for review.

Comment 28

[Michael Wu [:mwu]]

Do we need b2g_time.so?

The rest of the patch looks fine.

Comment 29

[Dave Hylands [:dhylands]]

(In reply to Michael Wu [:mwu] from comment #28)
> Do we need b2g_time.so?
> 
> The rest of the patch looks fine.

I tested without it and it seems to be working the same as with it. The manifest doesn't mention it, so I don't think its needed.

Comment 30

[Dave Hylands [:dhylands]]

Attachment: Add time_daemon and b2g_time v2

Comment 31

[Dave Hylands [:dhylands]]

Attachment: Add time_daemon and b2g_time v3

Uploaded the correct patch this time.

Comment 32

[Dave Hylands [:dhylands]]

https://github.com/dhylands/device-flame/commit/8de92236d5cb9d6533aede86e5388c76909f983f

Comment 33

[Dave Hylands [:dhylands]]

So this patch resolves at least a portion of the issue. Once the year reverts to 1970, then I can set the date in airplane mode and it stays across reboots.

There are obviously other issues.

Comment 34

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/device-flame/commit/897b4d8aa61b48208e3aa16171eef672895d3b11

Comment 35

[Kartikaya Gupta (email:[e-mail])]

For anybody who arrives at this bug because their local flame build is busted, read this:

https://groups.google.com/forum/#!msg/mozilla.dev.b2g/lMXyMgBrYuk/zIThdST0efAJ

Comment 36

[Shally Li（leave from Mozilla）]

This issue has been failed verified on Flame 2.1.
See attachment: verify_v2.1.MP4 and logcat_0841.txt
Reproduce rate: 1/6(Once)

Repro STR:
1.Disable "Set automatically" in Settings/Date&Time.
**It is "Asia,Chongqing,2014/12/04 16:26".
2.Change time as "16:23".
3.Turn on airplane mode.
**Wifi and SIM signal will disappear,and airplane mode icon will display on the title bar. 
4.Restart device.
**It changes as "America,New York,2014/06/02 08:41".And the "Set automatically" icon will disappear after restart.


This issue has been successfully verified on Flame v2.0.
See attachment: verified_v2.0.mp4.
Reproduce rate: 0/5

Flame 2.0 versions:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/29222e215db8
Build-ID        20141203000201
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141203.034550
FW-Date         Wed Dec  3 03:46:01 EST 2014
Bootloader      L1TC00011880

Flame 2.1 versions:
Gaia-Rev        dbaf3e31c9ba9c3436e074381744f2971e15c7bf
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ebce587d2194
Build-ID        20141203001205
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141203.034907
FW-Date         Wed Dec  3 03:49:18 EST 2014
Bootloader      L1TC00011880

Comment 37

[Shally Li（leave from Mozilla）]

Attachment: logcat_0841.txt

Comment 38

[Shally Li（leave from Mozilla）]

Attachment: verify_v2.1.mp4

Comment 39

[Shally Li（leave from Mozilla）]

Attachment: verified_2.0.MP4

Comment 40

[William Hsu [:whsu]]

I will check the results later.
NI?whsu

Comment 41

[William Hsu [:whsu]]

This bug seemed to happen on specific device because Eric cannot reproduce it on Buri and Shally can reproduce it on Flame.

--- -- - --- -- - --- -- - --- -- - --- -- -
Hi, Shally,

Good Job.
May I have your help?
You seemed to be able to reproduce this bug after patch landed on v2.1 and v2.0.
Could you please try to reproduce this bug on latest Flame v2.2, v2.1, and v2.0 ( with Base image v188 ) to see if it still happens?

If you still can reproduce it, please file a new bug and note the bug number here.
Many thanks.



Cheers,
William

Comment 42

[Shally Li（leave from Mozilla）]

(In reply to William Hsu [:whsu] from comment #41)
> Could you please try to reproduce this bug on latest Flame v2.2, v2.1, and
> v2.0 ( with Base image v188 ) to see if it still happens?
> 
> If you still can reproduce it, please file a new bug and note the bug number
> here.
> Many thanks.

Hi William,
 
    I can repro this bug of Comment 36 on Flame v2.0&2.1&2.2,I will note the new Bug ID later.

Comment 43

[Shally Li（leave from Mozilla）]

Hi William,
 
    The new Bug ID is 1119178.

Comment 44

[Gabriela [:gaby2300]]

Could someone please tell me why I don't have access to bug 1119178? Is it a security thing?

Comment 45

[Shally Li（leave from Mozilla）]

(In reply to Gabriela [:gaby2300] from comment #44)
> Could someone please tell me why I don't have access to bug 1119178? Is it a
> security thing?

Sorry,now you can see it.

Comment 46

[William Hsu [:whsu]]

(In reply to Shally from comment #43)
> Hi William,
>  
>     The new Bug ID is 1119178.

Hi, Shally,

You did a great job.
Thank you very much! :)

Comment 48

[Gabriela [:gaby2300]]

(In reply to Shally from comment #45)
> (In reply to Gabriela [:gaby2300] from comment #44)
> > Could someone please tell me why I don't have access to bug 1119178? Is it a
> > security thing?
> 
> Sorry,now you can see it.

Yes, now I can see it. Thanks!