Closed Bug 1057589 Opened 10 years ago Closed 9 years ago

[System] Time is not preserved after restarting device.

Categories

(Firefox OS Graveyard :: Vendcom, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

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

VERIFIED FIXED
2.1 S3 (29aug)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: Marty, Assigned: aus)

References

Details

(Keywords: regression, smoketest, Whiteboard: [POVB])

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
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)
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.
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.
I believe this is the same issue as reported in bug 1048154.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
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
Resolution: DUPLICATE → ---
[Blocking Requested - why for this release]: Smoketest blocking regression.
blocking-b2g: --- → 2.0?
blocking-b2g: 2.0? → 2.0+
aus, quick check to see if you investigating this as well ?
Flags: needinfo?(aus)
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)
Status: REOPENED → ASSIGNED
Flagging qawanted to see if this reproduces with the kitkat base image.
I could not reproduce this issue on the v165 KitKat Base image.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
(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
Closed: 10 years ago10 years ago
Resolution: --- → DUPLICATE
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]
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?]
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)
Blocks: 1069863
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
Closed: 10 years ago9 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.