If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED FIXED in Firefox OS v2.0

Status

Firefox OS
GonkIntegration
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: smaug, Assigned: dhylands)

Tracking

(Blocks: 1 bug)

unspecified
2.0 S6 (18july)
x86_64
Linux
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.0+, b2g-v1.3 wontfix, b2g-v1.3T wontfix, b2g-v1.4 affected, b2g-v2.0 fixed, b2g-v2.1 fixed)

Details

Attachments

(4 attachments, 2 obsolete attachments)

(Reporter)

Description

3 years ago
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)
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.
blocking-b2g: --- → 2.0?
Component: General → RIL
QA Wanted to branch check.
Keywords: qawanted

Updated

3 years ago
Component: RIL → Gaia::Settings
Do you have automatic time setting turned on? I see this but only when it is turned on. This feels related to bug 1032101.
(Reporter)

Comment 4

3 years ago
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.
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.
blocking-b2g: 2.0? → 2.0+
Component: Gaia::Settings → General

Updated

3 years ago
Component: General → GonkIntegration

Comment 6

3 years ago
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

3 years ago
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.

Updated

3 years ago
Keywords: qawanted
(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.
Keywords: qawanted
status-b2g-v1.3: --- → affected
status-b2g-v2.0: --- → affected
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.
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.
Summary: [Flame][2.1] After rebooting in airplane mode, time and date can be all wrong → [Flame][2.1] After rebooting in airplane mode, time and date can be all wrong [Manual Time Setting]
See Also: → bug 1032101
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: ekramer
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
(Assignee)

Comment 12

3 years ago
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
Try putting the blobs in /system/b2g/distribution/bundles/b2g_time back after the ./flash.sh
(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
Blocks: 1032101
(Reporter)

Comment 15

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

Updated

3 years ago
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
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.
(Assignee)

Comment 17

3 years ago
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
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
I tried also the suggestion in comment 13, but coulnd't push to /system/b2g, it is read only.
(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.
(Assignee)

Updated

3 years ago
See Also: → bug 1037141
(Assignee)

Comment 21

3 years ago
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
Did you remove the time_daemon from the original device image?
(Assignee)

Comment 23

3 years ago
(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.
(Assignee)

Comment 24

3 years ago
Created attachment 8454176 [details] [diff] [review]
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
(Assignee)

Comment 25

3 years ago
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.
(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
(Assignee)

Comment 27

3 years ago
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.
(Assignee)

Updated

3 years ago
Attachment #8454176 - Flags: review?(mwu)

Comment 28

3 years ago
Do we need b2g_time.so?

The rest of the patch looks fine.
(Assignee)

Comment 29

3 years ago
(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.
(Assignee)

Comment 30

3 years ago
Created attachment 8454579 [details] [diff] [review]
Add time_daemon and b2g_time v2
Assignee: nobody → dhylands
Attachment #8454176 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8454176 - Flags: review?(mwu)
Attachment #8454579 - Flags: review?(mwu)
(Assignee)

Comment 31

3 years ago
Created attachment 8454581 [details] [diff] [review]
Add time_daemon and b2g_time v3

Uploaded the correct patch this time.
Attachment #8454579 - Attachment is obsolete: true
Attachment #8454579 - Flags: review?(mwu)
Attachment #8454581 - Flags: review?(mwu)

Updated

3 years ago
Attachment #8454581 - Flags: review?(mwu) → review+
(Assignee)

Comment 32

3 years ago
https://github.com/dhylands/device-flame/commit/8de92236d5cb9d6533aede86e5388c76909f983f
(Assignee)

Comment 33

3 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
v2.0: https://github.com/mozilla-b2g/device-flame/commit/897b4d8aa61b48208e3aa16171eef672895d3b11
status-b2g-v1.3: affected → wontfix
status-b2g-v1.3T: --- → wontfix
status-b2g-v1.4: --- → affected
status-b2g-v2.0: affected → fixed
status-b2g-v2.1: --- → fixed
Target Milestone: --- → 2.0 S6 (18july)
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

Updated

3 years ago
Blocks: 1069863

Updated

3 years ago
No longer blocks: 1069863
Depends on: 1069863
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
status-b2g-v2.0: fixed → verified
Flags: needinfo?(hlu)
Created attachment 8531958 [details]
logcat_0841.txt
Created attachment 8531962 [details]
verify_v2.1.mp4
Created attachment 8531967 [details]
verified_2.0.MP4

Comment 40

3 years ago
I will check the results later.
NI?whsu
Flags: needinfo?(hlu) → needinfo?(whsu)

Comment 41

3 years ago
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
Flags: needinfo?(whsu) → needinfo?(lixia)
(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.
Flags: needinfo?(lixia)
status-b2g-v2.0: verified → fixed
Hi William,
 
    The new Bug ID is 1119178.
Flags: needinfo?(whsu)
See Also: → bug 1119178
Could someone please tell me why I don't have access to bug 1119178? Is it a security thing?
(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

3 years ago
(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! :)
Flags: needinfo?(whsu)

Updated

3 years ago
Duplicate of this bug: 1119178
(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!
You need to log in before you can comment on or make changes to this bug.