[System] Time is not preserved after restarting device.

VERIFIED FIXED in Firefox OS v2.0

Status

Firefox OS
Vendcom
VERIFIED FIXED
3 years ago
2 years ago

People

(Reporter: Marty, Assigned: aus)

Tracking

(Blocks: 2 bugs, {regression, smoketest})

unspecified
2.1 S3 (29aug)
ARM
Gonk (Firefox OS)
regression, smoketest
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)

Details

(Whiteboard: [POVB])

(Reporter)

Description

3 years ago
Description:
After long-pressing the power button, and selecting 'Restart,' the time has been changed to be inaccurate by several minutes or hours.  Usually, it is fast by 10-15 minutes, but can also be off by several (3 to 8) hours if the device is restarted multiple times.

Note: In the Date and Time settings, the date and time zone is still accurate.

This occurs both with and without a SIM inserted, and with or without a WiFi connection.

Repro Steps:
1) Update a Flame to 20140822000206
2) Note the Time displayed on the phone.
3) Long-press the power button, and select 'Restart'
4) Note the time on the lock screen when the device powers back up


Actual:
The time is significantly inaccurate


Expected:
The time is still accurate.

Environmental Variables:
Device: Flame 2.0
Build ID: 20140822000206
Gaia: 64b0c0ae60fdeac953a7e2a3c368d124bf848477
Gecko: 5075528d7241
Version: 32.0 (2.0)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


Notes: This issue occurs on both 512MB and 319MB memory


Repro frequency: >75%
Link to failed test case:


--------------------------------------------------------------------------------------

This issue DOES occur on Flame 2.1
Time is inaccurate after a device restart.

Environmental Variables:
Device: Flame Master
Build ID: 20140822040202
Gaia: afcdd36f13e75adcdebe57d842a277fd587faf28
Gecko: 0b9dd32d1e16
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
(Reporter)

Updated

3 years ago
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
[Blocking Requested - why for this release]:
Smoketest Regression of a core function of the phone.

Requesting a window.
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: qaurgent, regression, regressionwindow-wanted, smoketest
QA Contact: rpribble
When this happens does the time change to the correct time immediately after you unlock the device?  If so I've been seeing this on my Nexus 5 for months.
(Reporter)

Comment 3

3 years ago
We have seen this occur where the inaccurate time persists indefinitely while the device is on, and then the problem can compound after subsequent restarts.  We have also seen the issue where the time corrects itself about 30 seconds after boot-up, but this does not happen every time.  We see that the time does NOT recover after start up about 70% of the time.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Let's have the window focus on the issue where the inaccurate time persists indefinitely on the homescreen.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Updating with correct repro steps that I've been informed of and am now following.

Repro Steps:
1) Update a Flame to 20140822000206
2) Settings > Date & Time > Set the correct time zone
3) Note the Time displayed on the phone.
4) Long-press the power button, and select 'Restart'
5) Note the time on the lock screen when the device powers back up

Restarting regression window check.
(Assignee)

Comment 6

3 years ago
I believe this is the same issue as reported in bug 1048154.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1048154

Updated

3 years ago
Keywords: qaurgent, regressionwindow-wanted

Updated

3 years ago
blocking-b2g: 2.0? → ---
Aus & I discussed this offline - we think the bugs are related here, but they might not be exact dupes, since the STR involved in each bug is different. As a result, we're deciding to reopen the bug & mark the other bug as a see also.
Status: RESOLVED → REOPENED
Keywords: qaurgent, regressionwindow-wanted
Resolution: DUPLICATE → ---
See Also: → bug 1048154
[Blocking Requested - why for this release]:

Smoketest blocking regression.
blocking-b2g: --- → 2.0?

Updated

3 years ago
blocking-b2g: 2.0? → 2.0+
aus, quick check to see if you investigating this as well ?
Flags: needinfo?(aus)
(Assignee)

Comment 10

3 years ago
Indeed, I believe this is probably the same root cause as bug 1048154 so taking this one on as well.
Assignee: nobody → aus
Flags: needinfo?(aus)
Whiteboard: [systemsfe]
Target Milestone: --- → 2.1 S3 (29aug)
(Assignee)

Updated

3 years ago
Status: REOPENED → ASSIGNED
Flagging qawanted to see if this reproduces with the kitkat base image.
Keywords: regressionwindow-wanted → qawanted
I could not reproduce this issue on the v165 KitKat Base image.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Keywords: qaurgent
(In reply to Ghislain Aus Lacroix [:aus] from comment #10)
> Indeed, I believe this is probably the same root cause as bug 1048154 so
> taking this one on as well.

Given comment 12's testing I think you are definitely right. This is a vendor bug, so I'll kick the other bug out to vendcom.
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1048154
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
We found a vendor workaround, so moving this to fixed.
Component: Gaia::System → Vendcom
Resolution: DUPLICATE → FIXED
Whiteboard: [systemsfe] → [POVB]
status-b2g-v2.0: affected → fixed
status-b2g-v2.1: affected → fixed
(Reporter)

Comment 15

3 years ago
Verified Fixed. Issue no longer occurs when using the provided workaround script.
Time is preserved after restarting the device.

Environmental Variables:
Device: Flame 2.1
Build ID: 20140905000202
Gaia: 95e9b099aa89ded133e44014dd40b19dc0193c01
Gecko: 92a6bbdfd945
Version: 34.0a2 (2.1)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Flame 2.0
Build ID: 20140905000204
Gaia: 4627014cc5c5eeec894183866d4c57291302f8b8
Gecko: 2fae20afe1fa
Version: 32.0 (2.0)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
status-b2g-v2.0: fixed → verified
status-b2g-v2.1: fixed → verified
Flags: needinfo?(pbylenga)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
(In reply to Jason Smith [:jsmith] from comment #14)
> We found a vendor workaround, so moving this to fixed.

(In reply to Martin Shuman [:Marty] from comment #15)
> Verified Fixed. Issue no longer occurs when using the provided workaround
> script.
> Time is preserved after restarting the device.

Please can we have more details as to what the fix is, and how we get it on our Flames?

I, for one, haven't been dogfooding for several months, because of not having the correct date/time - and this also potentially resolves a few other bugs, but I can't test until I know how...
Blocks: 1048154, 1032101
Flags: needinfo?(mshuman)
Flags: needinfo?(jsmith)
See https://intranet.mozilla.org/QA/B2G_Tips_and_Tricks#latest_OEM_JellyBean_Base_Image:_v123_.2B_fonts
Flags: needinfo?(mshuman)
Flags: needinfo?(jsmith)

Updated

3 years ago
Blocks: 1069863

Updated

3 years ago
No longer blocks: 1069863
Depends on: 1069863
I am seeing this bug again in my Flame with 3.0. base image v18D and the 20150624160209 build. I can't update to a newer build because I'm not receiving OTA updates since then.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Same as the other, please don't re-open old bugs (especially verified fixed) but file new ones.
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago2 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
I'm sorry for that, I didn't know.
You need to log in before you can comment on or make changes to this bug.