Closed
Bug 876308
Opened 11 years ago
Closed 7 years ago
[FOTA]system update package can not be download successfully, download process will be blocked for long time
Categories
(Firefox OS Graveyard :: General, defect, P1)
Tracking
(blocking-b2g:-)
People
(Reporter: song.shenyang, Unassigned, NeedInfo)
Details
(Whiteboard: [fxos:media])
Attachments
(6 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.63 Safari/537.31 Steps to reproduce: 1) boot up the system 2) Check system updates: Settings->device infomation->Check for updates 3) try to download update package Actual results: the package can not be download successfully, download process will be blocked for long time Expected results: the package should be download successfully.
The network is fine, and the download process will be blocked. Cancel and resume, the download process will continue. Here is the output of |adb logcat -v time | grep SVC| 05-26 23:03:53.611 I/Gecko ( 111): *** AUS:SVC Checker: checkForUpdates, force: false 05-26 23:03:53.641 I/Gecko ( 111): *** AUS:SVC Checker:getUpdateURL - update URL: http://firefox.ztems.com/prerelease/\ roamer2/18.0/20130527062017/update.xml 05-26 23:03:53.641 I/Gecko ( 111): *** AUS:SVC Checker:checkForUpdates - sending request to: http://firefox.ztems.com/\ prerelease/roamer2/18.0/20130527062017/update.xml 05-26 23:03:53.651 I/Gecko ( 111): *** UTM:SVC TimerManager:notify - notified @mozilla.org/updates/update-service;1 05-26 23:03:55.000 I/Gecko ( 111): *** AUS:SVC Checker:onProgress - 559/559 05-26 23:03:55.010 I/Gecko ( 111): *** AUS:SVC Checker:onLoad - request completed downloading document 05-26 23:03:55.020 I/Gecko ( 111): *** AUS:SVC Checker:getUpdateURL - update URL: http://firefox.ztems.com/prerelease/\ roamer2/18.0/20130527062017/update.xml 05-26 23:03:55.020 I/Gecko ( 111): *** AUS:SVC Checker:onLoad - number of updates available: 1 05-26 23:03:55.030 I/Gecko ( 111): *** AUS:SVC gCanApplyUpdates - testing write access /data/local/update.test 05-26 23:03:55.030 I/Gecko ( 111): *** AUS:SVC gCanApplyUpdates - able to apply updates 05-26 23:03:55.050 I/Gecko ( 111): *** AUS:SVC UpdateService:_selectAndInstallUpdate - prompting because silent instal\ l is disabled 05-26 23:04:06.150 I/Gecko ( 111): *** AUS:SVC Creating Downloader 05-26 23:04:06.150 I/Gecko ( 111): *** AUS:SVC UpdateService:_downloadUpdate 05-26 23:04:06.150 I/Gecko ( 111): *** AUS:SVC readStringFromFile - file doesn't exist: /data/local/updates/0/update.s\ tatus 05-26 23:04:06.150 I/Gecko ( 111): *** AUS:SVC readStatusFile - status: null, path: /data/local/updates/0/update.statu\ s 05-26 23:04:06.160 I/Gecko ( 111): *** AUS:SVC UpdateManager:_loadXMLFileIntoArray: XML file does not exist 05-26 23:04:06.160 I/Gecko ( 111): *** AUS:SVC UpdateManager:_loadXMLFileIntoArray: XML file does not exist 05-26 23:04:06.190 I/Gecko ( 111): *** AUS:SVC readStringFromFile - file doesn't exist: /data/local/updates/0/update.s\ tatus 05-26 23:04:06.190 I/Gecko ( 111): *** AUS:SVC readStatusFile - status: null, path: /data/local/updates/0/update.statu\ s 05-26 23:04:06.200 I/Gecko ( 111): *** AUS:SVC Downloader:downloadUpdate - downloading from http://firefox.ztems.com/p\ rerelease/roamer2/18.0/20130527062017/update.mar to /data/local/updates/0/update.mar 05-26 23:04:06.661 I/Gecko ( 111): *** AUS:SVC Downloader:onStartRequest - original URI spec: http://firefox.ztems.com\ /prerelease/roamer2/18.0/20130527062017/update.mar, final URI spec: http://firefox.ztems.com/prerelease/roamer2/18.0/2013\ 0527062017/update.mar 05-26 23:04:06.701 I/Gecko ( 111): *** AUS:SVC Downloader:onProgress - progress: 10695/8653808 05-26 23:04:07.221 I/Gecko ( 111): *** AUS:SVC Downloader:onProgress - progress: 205167/8653808 05-26 23:04:07.752 I/Gecko ( 111): *** AUS:SVC Downloader:onProgress - progress: 610095/8653808 05-26 23:04:08.252 I/Gecko ( 111): *** AUS:SVC Downloader:onProgress - progress: 1053327/8653808 05-26 23:06:08.259 I/Gecko ( 111): *** AUS:SVC Downloader: cancel 05-26 23:06:08.279 I/Gecko ( 111): *** AUS:SVC Downloader:onProgress - progress: 1200000/8653808 05-26 23:06:08.299 I/Gecko ( 111): *** AUS:SVC Downloader:onStopRequest - original URI spec: http://firefox.ztems.com/\ prerelease/roamer2/18.0/20130527062017/update.mar, final URI spec: http://firefox.ztems.com/prerelease/roamer2/18.0/20130\ 527062017/update.mar, status: 2152398850 05-26 23:06:08.299 I/Gecko ( 111): *** AUS:SVC Downloader:onStopRequest - status: 2152398850, current fail: 0, max fai\ l: 20, retryTimeout: 30000 05-26 23:06:08.299 I/Gecko ( 111): *** AUS:SVC Downloader:onStopRequest - setting state to: downloading 05-26 23:06:08.339 I/Gecko ( 111): *** AUS:SVC Downloader: cancel 05-26 23:06:08.339 I/Gecko ( 111): *** AUS:SVC Creating Downloader 05-26 23:06:08.339 I/Gecko ( 111): *** AUS:SVC UpdateService:_downloadUpdate 05-26 23:06:08.349 I/Gecko ( 111): *** AUS:SVC readStatusFile - status: downloading, path: /data/local/updates/0/updat\ e.status 05-26 23:06:08.349 I/Gecko ( 111): *** AUS:SVC Downloader:_selectPatch - found existing patch with state: downloading 05-26 23:06:08.349 I/Gecko ( 111): *** AUS:SVC Downloader:_selectPatch - resuming download 05-26 23:06:08.349 I/Gecko ( 111): *** AUS:SVC readStatusFile - status: downloading, path: /data/local/updates/0/updat\ e.status 05-26 23:06:08.349 I/Gecko ( 111): *** AUS:SVC Downloader:downloadUpdate - interruptted update 05-26 23:06:08.359 I/Gecko ( 111): *** AUS:SVC readStringFromFile - file doesn't exist: /data/local/updates/0/update.l\ ink 05-26 23:06:08.359 I/Gecko ( 111): *** AUS:SVC getFileFromUpdateLink linkFile.path: /data/local/updates/0/update.link,\ link: null 05-26 23:06:08.359 I/Gecko ( 111): *** AUS:SVC Downloader:downloadUpdate - resuming with patchFile /data/local/updates\ /0/update.mar 05-26 23:06:08.359 I/Gecko ( 111): *** AUS:SVC Downloader:downloadUpdate - downloading from http://firefox.ztems.com/p\ rerelease/roamer2/18.0/20130527062017/update.mar to /data/local/updates/0/update.mar 05-26 23:06:08.560 I/Gecko ( 111): *** AUS:SVC Downloader:onStartRequest - original URI spec: http://firefox.ztems.com\ /prerelease/roamer2/18.0/20130527062017/update.mar, final URI spec: http://firefox.ztems.com/prerelease/roamer2/18.0/2013\ 0527062017/update.mar 05-26 23:06:08.610 I/Gecko ( 111): *** AUS:SVC Downloader:onProgress - progress: 1210636/8653808 05-26 23:06:09.110 I/Gecko ( 111): *** AUS:SVC Downloader:onProgress - progress: 1456876/8653808 05-26 23:08:09.117 I/Gecko ( 111): *** AUS:SVC Downloader: cancel 05-26 23:08:09.127 I/Gecko ( 111): *** AUS:SVC Downloader:onProgress - progress: 1500000/8653808 05-26 23:08:09.157 I/Gecko ( 111): *** AUS:SVC Downloader:onStopRequest - original URI spec: http://firefox.ztems.com/\ prerelease/roamer2/18.0/20130527062017/update.mar, final URI spec: http://firefox.ztems.com/prerelease/roamer2/18.0/20130\ 527062017/update.mar, status: 2152398850 05-26 23:08:09.157 I/Gecko ( 111): *** AUS:SVC Downloader:onStopRequest - status: 2152398850, current fail: 0, max fai\ l: 20, retryTimeout: 30000 05-26 23:08:09.157 I/Gecko ( 111): *** AUS:SVC Downloader:onStopRequest - setting state to: downloading 05-26 23:08:09.197 I/Gecko ( 111): *** AUS:SVC Downloader: cancel 05-26 23:08:09.197 I/Gecko ( 111): *** AUS:SVC Creating Downloader 05-26 23:08:09.197 I/Gecko ( 111): *** AUS:SVC UpdateService:_downloadUpdate 05-26 23:08:09.207 I/Gecko ( 111): *** AUS:SVC readStatusFile - status: downloading, path: /data/local/updates/0/updat\ e.status 05-26 23:08:09.207 I/Gecko ( 111): *** AUS:SVC Downloader:_selectPatch - found existing patch with state: downloading 05-26 23:08:09.207 I/Gecko ( 111): *** AUS:SVC Downloader:_selectPatch - resuming download
software infomation: buildid: 20130526124824 QC RIL version: "ro.build.firmware_revision=V1.01.00.01.019.116" gaia commit: 26d9430 Merge pull request #9982 from crdlc/bug-867045-v2 gecko commit: 5f6aa96 Bug 875933 - Add m.youtube.com to the STS preloaded list r=sicking, a=tef+
|
||
Comment 3•11 years ago
|
||
>05-26 23:04:08.252 I/Gecko ( 111): *** AUS:SVC Downloader:onProgress - progress: 1053327/8653808
>05-26 23:06:08.259 I/Gecko ( 111): *** AUS:SVC Downloader: cancel
>05-26 23:06:08.279 I/Gecko ( 111): *** AUS:SVC Downloader:onProgress - progress: 1200000/8653808
The download progress seems to stop for about 2 minutes until cancel. I found there are two pauses in the log that stopped at 1.2MB and 1.5MB. I could not tell if the progress is stopped by system hang or by no network traffic.
@songsy, did you press stop download when you found the download progress stopped for a while? could you attach the full logcat file on this bug?Flags: needinfo?(song.shenyang)
|
||
Comment 4•11 years ago
|
||
Song shenyang, another question: did you have SD card inserted when performing this test?
> @songsy, did you press stop download when you found the download progress
> stopped for a while? could you attach the full logcat file on this bug?
Hi, Shih-Chiang
I dont press to stop download.
I think the "Cancel" you found in the log is caused by the appdownloadmanager itself. I guess it tried some times and at last cancel and restart to download again.
I have attached the full logcat output.
Thanks
|
||
Comment 9•11 years ago
|
||
flagging for tef triage, assuming the download stopping is not user-initiated
Status: UNCONFIRMED → NEW
blocking-b2g: --- → tef?
Ever confirmed: true
|
||
Comment 10•11 years ago
|
||
It seems that the download is being canceled by the update watchdog after exceeding the number of retries [1]. For what I can see in the code at [2] if the watchdog timer is fired the download is paused and auto-restarted unless the max number of retries is exceeded [3]. The watchdog timer is restarted with each onProgress event received (I'm guessing) from the update service [4], so firing the watchdog timer is caused by the absence of onProgress events for more than 12 seconds [5]. I can see from the logs that you are using a WiFi connection since the radio declares to be offline (searching). Could this be caused by a crappy WiFi connection? Have you tried with a more reliable connection? I'm tempted to say that this is the expected behavior for an update download with a bad and unstable connection. Adding Marshall and Dave in CC. [1] https://mxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#476 [2] https://mxr.mozilla.org/mozilla-central/source/b2g/components/UpdatePrompt.js#531 [3] https://mxr.mozilla.org/mozilla-central/source/b2g/components/UpdatePrompt.js#579 [4] https://mxr.mozilla.org/mozilla-central/source/b2g/components/UpdatePrompt.js#601 [5] https://mxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js#475
Flags: needinfo?(dhylands)
|
|
||
Updated•11 years ago
|
Flags: needinfo?(marshall)
|
|
||
Comment 11•11 years ago
|
||
(In reply to Fernando Jiménez Moreno [:ferjm] (needinfo instead of CC, please) from comment #10) > onProgress events for more than 12 seconds [5]. s/12 seconds/2 minutes.
|
||
Comment 12•11 years ago
|
||
So yeah - it definitely looks like the watchdog timer is firing over and over again. The interesting thing is that there is always an onProgress right after the timer fires. This makes me wonder if maybe something else is sucking up all of the CPU, and maybe that's what's impeding the progress.
Flags: needinfo?(dhylands)
|
|
||
Comment 13•11 years ago
|
||
Well, the onProgress events are received 2 minutes before the timer fires, which seems correct. Take a look at the times of the logs: 05-27 16:51:39.418 I/Gecko ( 110): *** AUS:SVC Downloader:onProgress - progress: 543855/8803028 05-27 16:53:39.415 I/Gecko ( 110): UpdatePrompt: Download watchdog fired 05-27 16:53:40.876 I/Gecko ( 110): *** AUS:SVC Downloader:onProgress - progress: 1205765/8803028 05-27 16:55:40.873 I/Gecko ( 110): UpdatePrompt: Download watchdog fired 05-27 16:55:41.794 I/Gecko ( 110): *** AUS:SVC Downloader:onProgress - progress: 1400788/8803028 05-27 16:57:41.811 I/Gecko ( 110): UpdatePrompt: Download watchdog fired 05-27 16:57:42.612 I/Gecko ( 110): *** AUS:SVC Downloader:onProgress - progress: 1677532/8803028 05-27 16:59:42.619 I/Gecko ( 110): UpdatePrompt: Download watchdog fired 05-27 16:59:43.440 I/Gecko ( 110): *** AUS:SVC Downloader:onProgress - progress: 2011732/8803028 05-27 17:01:43.447 I/Gecko ( 110): UpdatePrompt: Download watchdog fired 05-27 17:01:44.808 I/Gecko ( 110): *** AUS:SVC Downloader:onProgress - progress: 2642252/8803028 05-27 17:03:44.835 I/Gecko ( 110): UpdatePrompt: Download watchdog fired
|
|
||
Comment 14•11 years ago
|
||
Nevermind, I misread your previous comment.
|
||
Comment 15•11 years ago
|
||
Don't think we should block on this one if the user can recover from the problem
Whiteboard: [tef-triage]
|
||
Comment 16•11 years ago
|
||
tef+ until someone confirms comment 15 (the update progresses as expected with only minor delay in normal user scenarios). Dave - can you confirm?
Assignee: nobody → dhylands
blocking-b2g: tef? → tef+
|
|
||
Comment 17•11 years ago
|
||
I tried flashing https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18_v1_0_1-unagi/2013/05/2013-05-26-23-02-02/ to my unagi, but when I tried to perform an update it failed due to something on the update server. Do we have a server somewhere with 1.0.1 stuff where we can test updates?
|
|
||
Comment 18•11 years ago
|
||
(In reply to Dave Hylands [:dhylands] from comment #17) > I tried flashing > https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla- > b2g18_v1_0_1-unagi/2013/05/2013-05-26-23-02-02/ to my unagi, but when I > tried to perform an update it failed due to something on the update server. > > Do we have a server somewhere with 1.0.1 stuff where we can test updates? what's the update channel after you flash that build say? if it's beta, then you just need to update app.update.url to nightly and then try again. it should pick up the 1.0.1 nightly ota url.
blocking-b2g: tef+ → tef?
|
|
||
Updated•11 years ago
|
blocking-b2g: tef? → tef+
|
|
||
Comment 19•11 years ago
|
||
(In reply to Tony Chung [:tchung] from comment #18) > (In reply to Dave Hylands [:dhylands] from comment #17) > > I tried flashing > > https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla- > > b2g18_v1_0_1-unagi/2013/05/2013-05-26-23-02-02/ to my unagi, but when I > > tried to perform an update it failed due to something on the update server. > > > > Do we have a server somewhere with 1.0.1 stuff where we can test updates? > > what's the update channel after you flash that build say? if it's beta, > then you just need to update app.update.url to nightly and then try again. > it should pick up the 1.0.1 nightly ota url. It shows unagi/1.0.1/default (in the settings app). What's the procedure for updating app.update.url? (I normally rebuild to do this type of thing, and I don't use pre-flashed images much)
|
||
Comment 20•11 years ago
|
||
batch update on tef+ milestones. partner to make a final on 6/3 Asia time. TEF+ needs to be resolved by 6/3 to be in the final build. thanks
Target Milestone: --- → 1.0.1 IOT3 (3jun)
|
||
Comment 21•11 years ago
|
||
What should be done now that June 3rd Asia time has passed?
|
||
Comment 22•11 years ago
|
||
:mwu, is this something you can look into since dhylands is out this week?
Flags: needinfo?(mwu)
|
|
||
Comment 23•11 years ago
|
||
mwu is not available to look at this one. Tony, have you been able to reproduce at all? Per comment #15 we won't block on this if the user can recover, but it doesn't sound like we know the answer yet.
Flags: needinfo?(mwu) → needinfo?(tchung)
|
|
||
Comment 24•11 years ago
|
||
(In reply to Dylan Oliver [:doliver] from comment #23) > mwu is not available to look at this one. > > Tony, have you been able to reproduce at all? Per comment #15 we won't block > on this if the user can recover, but it doesn't sound like we know the > answer yet. i'll take a look at this tomorrow. keep in mind that i would have to use the Buri partner build to test this, since mozilla isnt hosting the fota updates for these devices. I'll leave a note if i can reproduce, but we still need a platform engineer to analyze the logcats.
Flags: needinfo?(tchung)
|
|
||
Comment 25•11 years ago
|
||
(In reply to Tony Chung [:tchung] from comment #24) > (In reply to Dylan Oliver [:doliver] from comment #23) > > mwu is not available to look at this one. > > > > Tony, have you been able to reproduce at all? Per comment #15 we won't block > > on this if the user can recover, but it doesn't sound like we know the > > answer yet. > > i'll take a look at this tomorrow. keep in mind that i would have to use the > Buri partner build to test this, since mozilla isnt hosting the fota updates > for these devices. I'll leave a note if i can reproduce, but we still need > a platform engineer to analyze the logcats. Swaroopa is looking into this now. She has a 2013-05-30 TEF build that she's looking to see if can reproduce, since we couldnt locate the 5/26 build reported in comment 2.
|
||
Comment 26•11 years ago
|
||
|
|
||
Comment 27•11 years ago
|
||
Tried to reproduce the bug and the download update was successful. But the phone hangs/blocked when trying to install the updates. Steps: 1)Download the updates 2)Click on Install. once the download is complete 3) The phone reboots for updates installation. 4)Initially the progress of the installation can bee seen and later the phone hangs at "Alcatel onetouch" screen 5)Log click on the start button to restart the phone does'nt work. Even after removing and replacing the battery, the phone is hanged on the screen "Alcatel onetouch" screen
Flags: needinfo?(marshall)
|
||
Comment 28•11 years ago
|
||
That's the wrong phone.
|
|
||
Comment 29•11 years ago
|
||
This is my mistake. i read this bug as the Buri device, since i didn't know who the reporter is nor was their any clarify which phone it was found on. I'll reflash a Ikura device now with a version matching comment 2, and get it QA'd. still bothers me that we had FOTA issues on the Buri device in comment 27. We will file a seperate bug to track this.
|
|
||
Comment 30•11 years ago
|
||
Retested the bug on the correct phone. The download of the update does crash. But could recover from the crash and the phone is still usable. Attached the logs.
|
|
||
Comment 31•11 years ago
|
||
|
|
||
Comment 32•11 years ago
|
||
Looking at the logs for comment 30, it appears to have downloaded the update (which seems quite small - only 187 Kbytes), and then the network went offline. I didn't see any evidence in the logs of the crash (not saying it didn't happen, just saying I don't see anything reported). I also don't see the message that says that it rebooted into recovery mode (maybe it crashed before this). I manually downloaded the update, and it appears to be an incremental style update, which means that it will only apply properly to a partiular image. Where can the base image be acquired from?
|
|
||
Comment 33•11 years ago
|
||
I appears that the original update (reported in th logcat from comment 8) is 8.8Mb which suggests that the update done in comment 30 was using a different base image. The update from comment 8 appears to have ben done using a base of 20130528000457 The update from comment 30 appears to have been done using a base of 20130526124824 Not sure if its relevant, just reporting, what I observed from the logs
|
||
Comment 34•11 years ago
|
||
It doesn't seem like anyone's been able to show that this issue ever puts a phone in an unrecoverable state. If that's the case, then per Daniel in comment 15 we should tef- this bug. Anyone disagree?
|
||
Updated•11 years ago
|
blocking-b2g: tef+ → tef?
|
|
||
Comment 35•11 years ago
|
||
(In reply to Johnny Stenback (:jst, jst@mozilla.com) from comment #34) > It doesn't seem like anyone's been able to show that this issue ever puts a > phone in an unrecoverable state. If that's the case, then per Daniel in > comment 15 we should tef- this bug. Anyone disagree? Our partners are performing their own FOTA update testing, so I don't disagree. That being said, I would love to hear that comment 30 resulted in an updated phone. If not, we still haven't had a successful FOTA update internally in the last week, which would be very alarming.
|
|
||
Comment 36•11 years ago
|
||
I'm still waiting for my ikura phone to show up. I was able to successfully perform a FOTA update on my unagi running 1.0.1, and I didn't observe any issues.
|
|
||
Comment 37•11 years ago
|
||
My ikura phone showed up, but the touch screen driver in the image doesn't seem to match whats on the phone, so my touch screen doesn't work (the touch screen isn't broken - since it was working in the gb base image). I can't try to reproduce without a working phone.
|
|
||
Comment 38•11 years ago
|
||
So I got the touch screen working again. I flashed the P752D04_MOVISTAR_FOR_PARTENER_20130526 image and tried to perform an update. It seemed to do a regular update (and not a FOTA). I observed a crash, which I believe is this crash report: https://crash-stats.mozilla.com/report/index/73ae7c37-aa26-490a-942e-d520f2130614 In logcat, I saw: 13:54:15.930 621/621 Gecko I *** AUS:SVC Downloader:onProgress - progress: 139289/187183 13:54:15.990 621/640 Adreno200-EGLSUB I <CreateImage:991>: Android Image 13:54:15.990 621/640 Adreno200-EGLSUB I <GetImageAttributes:1200>: RGBA_8888 13:54:16.070 621/621 Gecko I *** AUS:SVC Downloader:onProgress - progress: 187183/187183 13:54:16.080 621/621 Gecko I *** AUS:SVC Downloader:onStopRequest - original URI spec: http://firefox.ztems.com/prerelease/packages/roamer2/18.0/20130526124824/update.mar, final URI spec: http://firefox.ztems.com/prerelease/packages/roamer2/18.0/20130526124824/update.mar, status: 0 13:54:16.080 621/621 Gecko I *** AUS:SVC Downloader:onStopRequest - status: 0, current fail: 0, max fail: 20, retryTimeout: 30000 13:54:16.080 621/621 Gecko I *** AUS:SVC Downloader:_verifyDownload called 13:54:16.080 621/621 Gecko I *** AUS:SVC Downloader:_verifyDownload downloaded size == expected size. 13:54:16.120 621/621 Gecko I *** AUS:SVC Downloader:_verifyDownload hashes match. 13:54:16.140 621/621 Gecko I *** AUS:SVC Downloader:onStopRequest - setting state to: pending 13:54:16.170 621/621 Gecko I *** AUS:SVC gCanStageUpdates - able to stage updates because we'll use the service 13:54:16.170 621/621 Gecko I *** AUS:SVC UpdateService:applyUpdateInBackground called with the following update: Firefox 18.0 13:54:16.230 621/640 Adreno200-EGLSUB I <CreateImage:991>: Android Image 13:54:16.230 621/640 Adreno200-EGLSUB I <GetImageAttributes:1200>: RGBA_8888 13:54:16.280 621/628 Gecko I About to crash: fanotify_event_metadata read error. 13:54:16.360 977/978 GeckoUpdater I Progress [ ===== ] 13:54:16.360 977/978 GeckoUpdater I Progress [ ========== ] (so the line of significance is this one: About to crash: fanotify_event_metadata read error. I saw it crash twice, and both times I got the same fanotify error. The first time logcat looked like: 13:46:52.540 110/110 Gecko I *** AUS:SVC Downloader:onProgress - progress: 187183/187183 13:46:52.560 110/110 Gecko I *** AUS:SVC Downloader:onStopRequest - original URI spec: http://firefox.ztems.com/prerelease/packages/roamer2/18.0/20130526124824/update.mar, final URI spec: http://firefox.ztems.com/prerelease/packages/roamer2/18.0/20130526124824/update.mar, status: 0 13:46:52.560 110/110 Gecko I *** AUS:SVC Downloader:onStopRequest - status: 0, current fail: 0, max fail: 20, retryTimeout: 30000 13:46:52.560 110/110 Gecko I *** AUS:SVC Downloader:_verifyDownload called 13:46:52.570 110/110 Gecko I *** AUS:SVC Downloader:_verifyDownload downloaded size == expected size. 13:46:52.590 110/110 Gecko I *** AUS:SVC Downloader:_verifyDownload hashes match. 13:46:52.610 110/110 Gecko I *** AUS:SVC Downloader:onStopRequest - setting state to: pending 13:46:52.640 110/110 Gecko I *** AUS:SVC gCanStageUpdates - able to stage updates because we'll use the service 13:46:52.640 110/110 Gecko I *** AUS:SVC UpdateService:applyUpdateInBackground called with the following update: Firefox 18.0 13:46:52.690 110/288 Adreno200-EGLSUB I <CreateImage:991>: Android Image 13:46:52.690 110/288 Adreno200-EGLSUB I <GetImageAttributes:1200>: RGBA_8888 13:46:52.750 110/280 Gecko I About to crash: fanotify_event_metadata read error. 13:46:52.780 617/617 GonkAutoMounter I Mounted /system partition as read-write 13:46:52.880 617/619 GeckoUpdater I Progress [ ===== ] 13:46:52.880 617/619 GeckoUpdater I Progress [ ========== ] 13:46:53.391 617/619 GeckoUpdater I Progress [ ============================ ] 13:46:53.411 617/619 GeckoUpdater I Progress [ =============================================== ] 13:46:53.441 617/619 GeckoUpdater I Progress [ ================================================ ] 13:46:53.471 617/619 GeckoUpdater I Progress [ ================================================== ] So the error doesn't appear to be directly related to update, although its most likely that performing an update is somehow triggering the problem. I'm going to try and do my own build and see if I can reproduce the problem.
|
|
||
Comment 39•11 years ago
|
||
Hmm. When I rebooted the phone it came up with a splash screen that just says FTM in the middle. I haven't seen this before. Does anybody know what it means?
|
|
||
Comment 40•11 years ago
|
||
The FTM screen was caused by user error. When I rest the phone in my right hand and put my index finger on the power button, my middle finger naturally rests on the volume down button. When I go to hit the power button, then I naturally squeeze the phone and this caused the volume down + power to be pressed, which causes the FTM screen. I also looks like the fanotify problem was caused by bug 874148 which is already fixed in the latest build (I couldn't reproduce). I tried regular updates and FOTA updates, and both seemed to work fine.
|
|
||
Comment 41•11 years ago
|
||
I continued to have touchscreen driver issues on my phone, having to reinstall the touchscreen firmware a couple of times. It would work for a while, and then start failing, sometimes a power cycle would fix it, and sometimes not. For the case where power cycling didn't fix it, I needed to reupdate the touchscreen driver. I also heard that there was a version of the touchscreen driver which consumed alot of CPU. If that particular version were installed, it would explain what we're seeing here.
|
|
||
Comment 42•11 years ago
|
||
This did not end up being an issue during partner testing, so we decided not to block.
blocking-b2g: tef? → -
|
||
Comment 43•11 years ago
|
||
Well, I've similar problem, but because my update installer is requesting non-existing XML file. All updates end with error => is this URL correct or how can I force ZTE Open to use different update server?? I/Gecko ( 113): *** AUS:SVC Checker:checkForUpdates - sending request to: http://firefox.ztems.com/prerelease/roamer2/18.0/20130621152332/update.xml What should I do, or is it correct? (which I doubt somehow) Thx for reply.
|
||
Comment 44•11 years ago
|
||
(In reply to Marek Raida from comment #43) I have the same issue than in previous comment 43, but with an other build ID (20130531232151). It means that the update description file in http://firefox.ztems.com/prerelease/roamer2/18.0/20130621152332/ is missing. I'll contact ZTE as updates are not managed by Mozilla. (I've checked by whois ztems.com is owned by ZTE)
|
||
Comment 45•11 years ago
|
||
Hi, I've reproduced again this issue this morning, doing an upgrade from 1.0.1 to 1.1 with zte open (both commercial versions in Spain). I've a sample that seems quite easy to reproduce with. Can any of the ZTE colleagues to take a look on the logs? Thanks! David
|
|
||
Updated•11 years ago
|
Flags: needinfo?(zhang.baisheng)
|
|
||
Comment 46•10 years ago
|
||
Added [fxos:media] whiteboard for bugs assigned to me so that they can be triaged/prioritized, etc.
Whiteboard: [tef-triage] → [fxos:media]
|
|
||
Comment 47•8 years ago
|
||
Not working on FxOS any more, so removing myself as assignee
Assignee: dhylands → nobody
|
|
||
Updated•7 years ago
|
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•