1092002 - [Flame][Dialer][V188] Dialing a number will crash, forcing battery pull

Status: VERIFIED FIXED

(Firefox OS Graveyard :: GonkIntegration, defect)

Description

[Tony Chung [:tchung]]

Tested on a M-c build created from jenkins, that bundles the v188 binaries.   As a result, the dialer just crashes and turns whitescreen, with no ADB access.  

This doesnt reproduce when testing m-c against v180 binaries.

Logcat isnt very useful, since it just disconnects.   This requires a battery pull to restore.

See screencast for whitescreen.   http://youtu.be/9J9HnUCcavs

logcat:
*****
10-30 21:56:21.807: D/wpa_supplicant(959): RX ctrl_iface - hexdump(len=11): 53 49 47 4e 41 4c 5f 50 4f 4c 4c
10-30 21:56:21.807: D/wpa_supplicant(959): wlan0: Control interface command 'SIGNAL_POLL'
10-30 21:56:21.817: D/wpa_supplicant(959): nl80211: survey data missing!
10-30 21:56:26.807: D/wpa_supplicant(959): RX ctrl_iface - hexdump(len=11): 53 49 47 4e 41 4c 5f 50 4f 4c 4c
10-30 21:56:26.807: D/wpa_supplicant(959): wlan0: Control interface command 'SIGNAL_POLL'
10-30 21:56:26.817: D/wpa_supplicant(959): nl80211: survey data missing!
10-30 21:56:31.807: D/wpa_supplicant(959): RX ctrl_iface - hexdump(len=11): 53 49 47 4e 41 4c 5f 50 4f 4c 4c
10-30 21:56:31.807: D/wpa_supplicant(959): wlan0: Control interface command 'SIGNAL_POLL'
10-30 21:56:31.817: D/wpa_supplicant(959): nl80211: survey data missing!
10-30 21:56:36.797: D/wpa_supplicant(959): RX ctrl_iface - hexdump(len=11): 53 49 47 4e 41 4c 5f 50 4f 4c 4c
10-30 21:56:36.797: D/wpa_supplicant(959): wlan0: Control interface command 'SIGNAL_POLL'
10-30 21:56:36.807: D/wpa_supplicant(959): nl80211: survey data missing!
10-30 21:56:39.227: W/AudioFlinger(206): Thread AudioOut_2 cannot connect to the power manager service
10-30 21:56:39.227: W/AudioFlinger(206): Thread AudioOut_2 cannot connect to the power manager service
10-30 21:56:39.227: E/AudioFlinger(206): no wake lock to update!
10-30 21:56:39.247: W/AudioPolicyManager(206): setPhoneState() setting same state 0
10-30 21:56:39.327: W/AudioFlinger(206): Thread AudioOut_2 cannot connect to the power manager service
10-30 21:56:39.327: E/AudioFlinger(206): no wake lock to update!
10-30 21:56:39.327: D/audio_hw_primary(206): select_devices: out_snd_device(2: speaker) in_snd_device(0: )
10-30 21:56:39.327: D/hardware_info(206): hw_info_append_hw_type : device_name = speaker
10-30 21:56:39.327: D/ACDB-LOADER(206): ACDB -> send_audio_cal, acdb_id = 14, path =  0
10-30 21:56:39.327: D/ACDB-LOADER(206): ACDB -> send_adm_topology
10-30 21:56:39.327: D/ACDB-LOADER(206): ACDB -> ACDB_CMD_GET_AUDPROC_COMMON_TOPOLOGY_ID
10-30 21:56:39.327: D/ACDB-LOADER(206): ACDB -> send_asm_topology
10-30 21:56:39.337: D/ACDB-LOADER(206): ACDB -> ACDB_CMD_GET_AUDPROC_STREAM_TOPOLOGY_ID
10-30 21:56:39.337: D/ACDB-LOADER(206): ACDB -> send_audtable
10-30 21:56:39.337: D/ACDB-LOADER(206): ACDB -> ACDB_CMD_GET_AUDPROC_COMMON_TABLE
10-30 21:56:39.337: D/ACDB-LOADER(206): ACDB -> AUDIO_SET_AUDPROC_CAL
10-30 21:56:39.337: D/ACDB-LOADER(206): ACDB -> send_audvoltable
10-30 21:56:39.337: D/ACDB-LOADER(206): ACDB -> ACDB_CMD_GET_AUDPROC_GAIN_DEP_STEP_TABLE
10-30 21:56:39.337: D/(206): Failed to fetch the lookup information of the device 0000000E 
10-30 21:56:39.337: E/ACDB-LOADER(206): Error: ACDB AudProc vol returned = -19
10-30 21:56:39.337: D/ACDB-LOADER(206): ACDB -> AUDIO_SET_AUDPROC_VOL_CAL
10-30 21:56:39.337: D/ACDB-LOADER(206): ACDB -> send_afe_cal
10-30 21:56:39.337: D/ACDB-LOADER(206): ACDB -> ACDB_CMD_GET_AFE_COMMON_TABLE
10-30 21:56:39.337: D/ACDB-LOADER(206): ACDB -> AUDIO_SET_AFE_CAL
10-30 21:56:41.817: D/wpa_supplicant(959): RX ctrl_iface - hexdump(len=11): 53 49 47 4e 41 4c 5f 50 4f 4c 4c
10-30 21:56:41.817: D/wpa_supplicant(959): wlan0: Control interface command 'SIGNAL_POLL'
10-30 21:56:41.827: D/wpa_supplicant(959): nl80211: survey data missing!
10-30 21:56:42.037: I/Gecko(2691): ###################################### forms.js loaded
10-30 21:56:42.057: I/Gecko(2691): ############################### browserElementPanning.js loaded
10-30 21:56:42.067: I/Gecko(2691): ######################## BrowserElementChildPreload.js loaded
10-30 21:56:43.787: D/audio_hw_extn(206): audio_extn_get_parameters: returns 
10-30 21:56:43.787: I/str_params(206): key: 'all_call_states' value: ''
10-30 21:56:43.797: D/audio_hw_extn(206): audio_extn_get_parameters: returns 
10-30 21:56:43.797: I/str_params(206): key: 'all_call_states' value: ''
10-30 21:56:43.797: D/audio_hw_extn(206): audio_extn_get_parameters: returns 
10-30 21:56:43.797: I/str_params(206): key: 'all_call_states' value: ''
10-30 21:56:43.797: D/audio_hw_extn(206): audio_extn_get_parameters: returns 
10-30 21:56:43.797: I/str_params(206): key: 'all_call_states' value: ''
10-30 21:56:43.797: D/audio_hw_extn(206): audio_extn_get_parameters: returns 
10-30 21:56:43.797: I/str_params(206): key: 'all_call_states' value: ''
10-30 21:56:43.797: D/audio_hw_extn(206): audio_extn_get_parameters: returns 
10-30 21:56:43.797: I/str_params(206): key: 'all_call_states' value: ''
10-30 21:56:43.807: D/audio_hw_primary(206): adev_set_parameters: enter: vsid=281022464;call_state=2
10-30 21:56:43.807: D/voice_extn(206): update_call_states is_in_call:0 voice_device_set:0, mode:0
10-30 21:56:43.807: D/audio_hw_extn(206): audio_extn_set_anc_parameters: anc_enabled:0
10-30 21:56:43.807: E/audio_a2dp_hw(206): adev_set_parameters: ERROR: set param called even when stream out is null
10-30 21:56:43.837: D/audio_hw_primary(206): adev_set_mode mode 2
10-30 21:56:43.837: D/audio_hw_primary(206): out_set_parameters: enter: usecase(0: deep-buffer-playback) kvpairs: fm_volume=0.0000000000
10-30 21:56:43.837: D/audio_hw_extn(206): audio_extn_set_anc_parameters: anc_enabled:0
10-30 21:56:43.837: D/audio_hw_fm(206): audio_extn_fm_set_parameters: set_fm_volume usecase
10-30 21:56:43.837: D/audio_hw_fm(206): fm_set_volume: (0.000000)
10-30 21:56:43.857: D/audio_hw_primary(206): out_set_parameters: enter: usecase(0: deep-buffer-playback) kvpairs: fm_volume=0.0000000000
10-30 21:56:43.857: D/audio_hw_extn(206): audio_extn_set_anc_parameters: anc_enabled:0
10-30 21:56:43.857: D/audio_hw_fm(206): audio_extn_fm_set_parameters: set_fm_volume usecase
10-30 21:56:43.857: D/audio_hw_fm(206): fm_set_volume: (0.000000)
10-30 21:56:44.037: D/audio_hw_primary(206): out_set_parameters: enter: usecase(0: deep-buffer-playback) kvpairs: routing=1
10-30 21:56:44.037: D/audio_hw_primary(206): select_devices: out_snd_device(6: voice-handset) in_snd_device(0: )
10-30 21:56:44.057: D/hardware_info(206): hw_info_append_hw_type : device_name = speaker
10-30 21:56:44.057: D/hardware_info(206): hw_info_append_hw_type : device_name = voice-handset
10-30 21:56:44.057: D/ACDB-LOADER(206): ACDB -> send_audio_cal, acdb_id = 7, path =  0
10-30 21:56:44.057: D/ACDB-LOADER(206): ACDB -> send_adm_topology
10-30 21:56:44.057: D/ACDB-LOADER(206): ACDB -> ACDB_CMD_GET_AUDPROC_COMMON_TOPOLOGY_ID
10-30 21:56:44.057: D/ACDB-LOADER(206): ACDB -> send_asm_topology
10-30 21:56:44.057: D/ACDB-LOADER(206): ACDB -> ACDB_CMD_GET_AUDPROC_STREAM_TOPOLOGY_ID
10-30 21:56:44.057: D/ACDB-LOADER(206): ACDB -> send_audtable
10-30 21:56:44.057: D/ACDB-LOADER(206): ACDB -> ACDB_CMD_GET_AUDPROC_COMMON_TABLE
10-30 21:56:44.057: D/ACDB-LOADER(206): ACDB -> AUDIO_SET_AUDPROC_CAL
10-30 21:56:44.057: D/ACDB-LOADER(206): ACDB -> send_audvoltable
10-30 21:56:44.057: D/ACDB-LOADER(206): ACDB -> ACDB_CMD_GET_AUDPROC_GAIN_DEP_STEP_TABLE
10-30 21:56:44.057: D/(206): Failed to fetch the lookup information of the device 00000007 
10-30 21:56:44.057: E/ACDB-LOADER(206): Error: ACDB AudProc vol returned = -19
10-30 21:56:44.057: D/ACDB-LOADER(206): ACDB -> AUDIO_SET_AUDPROC_VOL_CAL
10-30 21:56:44.057: D/ACDB-LOADER(206): ACDB -> AUDIO_SET_AFE_CAL
10-30 21:56:44.127: D/voice_extn(206): update_calls: enter:
10-30 21:56:44.127: D/voice_extn(206): update_calls: cur_state=1 new_state=2 vsid=10c01000
10-30 21:56:44.127: D/voice_extn(206): update_calls: INACTIVE -> ACTIVE vsid:10c01000
10-30 21:56:44.127: D/voice(206): start_call: enter usecase:voice-call
: E/(): Device disconnected


Repro:
1) install 2.2 m-c jenkins build that packages v188 binaries

Gaia-Rev        8ae6598f3ab7b0c34ac42a73083ddb74266affba
Gecko-Rev       https://hg.mozilla.org/users/nthomas_mozilla.com/mozilla-central/rev/d4fab3f7782b
Build-ID        20141030203020
Version         36.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141030.201724
FW-Date         Thu Oct 30 20:17:37 EDT 2014
Bootloader      L1TC10011880

2) launch dialer, and dial a number
3) Verify whitescreen crash, and need to pull battery

Expected:
- call goes through, no crash.

Comment 1

[Tony Chung [:tchung]]

The link to the full flash build i mentioned above is at:  https://drive.google.com/a/mozilla.com/file/d/0ByC1WGFz4NMDY0ZfVUdBcTNkUjQ/view?usp=sharing. 

Qawanted to have someone else see if this can be reproduced on another flame.

Comment 2

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

triage: this is major issue that breaks usability.

Comment 3

[Johan Lorenzo [:jlorenzo]]

Reproduced with the build you provided. I'm checking a more recent build.

Comment 4

[Parul Mathur [:pragmatic] - out of office - please ni? [:bajaj] instead]

Able to reproduce exactly as described in Comment #0 with the same build flashed on top on v188 base image.

Cannot make an outgoing call. After dialing the number, the screen turns white. The phone needs to be rebooted by taking out its battery.

Gaia-Rev        8ae6598f3ab7b0c34ac42a73083ddb74266affba
Gecko-Rev       https://hg.mozilla.org/users/nthomas_mozilla.com/mozilla-central/rev/d4fab3f7782b
Build-ID        20141030203020
Version         36.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141030.201724
FW-Date         Thu Oct 30 20:17:37 EDT 2014
Bootloader      L1TC00011880

Comment 5

[Johan Lorenzo [:jlorenzo]]

No crash to report when you shallow flash gecko and gaia (master) on top of vanilla v188.

I am able to reproduce the issue when I receive a phone call, but not when I use the headphone. I think this is because we use the voice-headset output. 
> 10-30 21:56:44.057: D/hardware_info(206): hw_info_append_hw_type : device_name = voice-handset

Comment 6

[Johan Lorenzo [:jlorenzo]]

I needed to get the root access to check if libaudioroute.so upgraded in bug 1034147 was related, so I pushed the boot.img from the vanilla v188 to my device. After that, no more crash when placing a phone call.

Comment 7

[Tony Chung [:tchung]]

This is looking more and more like the v188 binaries in the pvtbuild is messing with the v188 base.   

Mwu, viralwang, Aosmond:  do you guys have more insight what is happening here?   comment 5 confirms that shallow flashing GG is not reproducing the crash.

Comment 8

[Oliver Nelson [:oliverthor]]

This issue DID NOT REPRO on the 2.2 Master KK builds performed on flame devices today:
Results: Dialer input register and call connects, no crash
** Note: pvtbuilds from today are utilizing v180 binaries **
Repro: 0/5

Environmental Variables:
----------------------------------------------
Device: Flame 2.2 [Full Flash]
BuildID: 20141031061804
Gaia: a07994714f0552f89801d6097982308d8b0a1ee1
Gecko: 6bd2071b373f
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Device: Flame 2.2 [Full Flash]
BuildID: 20141031040201
Gaia: 8ae6598f3ab7b0c34ac42a73083ddb74266affba
Gecko: e0b505a37b1c
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
----------------------------------------------

Comment 9

[Andrew Osmond [:aosmond] (he/him)]

The utility list included in the boot.img is minimal, so I don't think this is related to bug 1034147. I skimmed over the differences between the init.rc/etc files but nothing caught my eye for voice calling or radios. Perhaps there are kernel changes we are missing...?

Comment 10

[Michael Wu [:mwu]]

We updated the kernel pretty recently.

Maybe we should start updating other repos to LNX.LF.3.5.2.1_1 ?

Comment 11

[Nick Thomas [:nthomas] (UTC+12)]

Is there any chance the file lists in 
 https://github.com/mozilla-b2g/device-flame/blob/kitkat/extract-files.sh
need to be updated for v188 ? I'm wondering if we get this crash with an incomplete binary extraction, leading to some mis-linking at build time, and a runtime crash   *waves hands vigorously*

Comment 12

[Tony Chung [:tchung]]

(In reply to Nick Thomas [:nthomas] from comment #11)
> Is there any chance the file lists in 
>  https://github.com/mozilla-b2g/device-flame/blob/kitkat/extract-files.sh
> need to be updated for v188 ? I'm wondering if we get this crash with an
> incomplete binary extraction, leading to some mis-linking at build time, and
> a runtime crash   *waves hands vigorously*

Flagging :mwu in case he didnt see this.  Please help!  We need to have working builds on 2.1 and master with the v188 bits asap.

Comment 13

[viral [:viralwang]]

(In reply to Nick Thomas [:nthomas] from comment #11)
> Is there any chance the file lists in 
>  https://github.com/mozilla-b2g/device-flame/blob/kitkat/extract-files.sh
> need to be updated for v188 ? I'm wondering if we get this crash with an
> incomplete binary extraction, leading to some mis-linking at build time, and
> a runtime crash   *waves hands vigorously*

It looks like the crash comes from kernel change and no relative to extract-files.sh
v188 => good
v188 + moz kernel => bad
v188 + moz system/userdata => good

we're going to request partner to release their latest kernel code to us to fix this issue.

Comment 14

[Andrew Osmond [:aosmond] (he/him)]

Note that if something is indeed crashing, and we aren't receiving any stack traces in the logcat, the core dumps might be helpful in isolating the root cause. I would need is the build (same as in comment 1 although it needs to be a build which produced debug symbols) and the core files.

See this for more details:
https://developer.mozilla.org/en-US/Firefox_OS/Debugging/Debugging_B2G_using_gdb#Debugging_core_files

Comment 15

[Johan Lorenzo [:jlorenzo]]

I haven't been able to get a core dump even if I set persist.debug.coredump to all. I am not sure we're actually experiencing a crash. If the device is plugged when I receive the call, I can see a lot of storage devices pluging in and out on my linux.

Comment 16

[Tony Chung [:tchung]]

(In reply to viral [:viralwang] from comment #13)
> (In reply to Nick Thomas [:nthomas] from comment #11)
> > Is there any chance the file lists in 
> >  https://github.com/mozilla-b2g/device-flame/blob/kitkat/extract-files.sh
> > need to be updated for v188 ? I'm wondering if we get this crash with an
> > incomplete binary extraction, leading to some mis-linking at build time, and
> > a runtime crash   *waves hands vigorously*
> 
> It looks like the crash comes from kernel change and no relative to
> extract-files.sh
> v188 => good
> v188 + moz kernel => bad
> v188 + moz system/userdata => good
> 
> we're going to request partner to release their latest kernel code to us to
> fix this issue.

Wesly, can you reach out to vendor to get that kernel code?  i'm surprised we dont already have it.  In the meantime, what else do you suggest for us to track the v188+moz Kernel scenario?

Viral, in your opinion, until we get unblocked, which scenario makes more sense to test:
1) full flash pvtbuilds over v180 base
2) shallow flash pvtbuilds over v188 base

both scenarios arent perfect, and have pros and cons.  Until i get v188+moz Kernel, i'm not sure what else is the ideal situation to keep testing on.   Today, we are doing step 1 in QA.

Comment 17

[viral [:viralwang]]

(In reply to Tony Chung [:tchung] from comment #16)
> Viral, in your opinion, until we get unblocked, which scenario makes more
> sense to test:
> 1) full flash pvtbuilds over v180 base
> 2) shallow flash pvtbuilds over v188 base
> 
> both scenarios arent perfect, and have pros and cons.  Until i get v188+moz
> Kernel, i'm not sure what else is the ideal situation to keep testing on.  
> Today, we are doing step 1 in QA.
Hi Tony,

is that possible we can have use v188 as base and flash moz userdata.img/system.img (skip moz boot.img)?
if not I would like to take option (2) for our testing.
I think most developers will only do shallow flash after they update base image. it makes more sense to dig out any possible bug here.

Comment 18

[Johan Lorenzo [:jlorenzo]]

As the discussion is now around the kernel, I move this bug to GonkIntegration. If you think this is an error, please move it again.

Comment 19

[Gabriele Svelto [:gsvelto]]

FYI I'm seeing this too both on my dogfooding device (which is v188 + nightly OTA updates) and my development one (which is v188 + my personal master build flashed with ./flash.sh shallow).

Comment 20

[Dave Hunt [:davehunt] [he/him] ⌚BST]

(In reply to viral [:viralwang] from comment #17)
> (In reply to Tony Chung [:tchung] from comment #16)
> is that possible we can have use v188 as base and flash moz
> userdata.img/system.img (skip moz boot.img)?
> if not I would like to take option (2) for our testing.
> I think most developers will only do shallow flash after they update base
> image. it makes more sense to dig out any possible bug here.

For automation we should be able to skip flashing boot.img from pvtbuilds. That might resolve an issue we currently have in bug 1059857 that has regressed since switching back to shallow flashing.

Comment 21

[Wesly Huang (EPM)]

Checked w/ vendor and kernel code is already up to date, so maybe there is something else need to be updated like mentioned in comment#10?

Comment 22

[Kai-Zhen Li [:seinlin][:kli]]

Tony,

It is working fine with v180 base image + firmware from comment 1.

With v188 base image.

- I can reproduce this with the firmware from comment 1.

- But I can't reproduce with today build, (I made a full flash from m-c).
Gaia-Rev        5ae28ff11b982e2bd7d1aa097cda131536952bdc
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/a926116946f8
Build-ID        20141111160205
Version         36.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141111.191942
FW-Date         Tue Nov 11 19:19:51 EST 2014
Bootloader      L1TC00011880

Comment 23

[Kai-Zhen Li [:seinlin][:kli]]

Sorry, to correct comment 22. With V180 or V188.

- This can be reproduced, when firmware from comment 1 is used.

- This can't be reproduced, when today build (20141111160205) is used.

Comment 24

[Tony Chung [:tchung]]

(In reply to Kai-Zhen Li [:seinlin] from comment #23)
> Sorry, to correct comment 22. With V180 or V188.
> 
> - This can be reproduced, when firmware from comment 1 is used.
> 
> - This can't be reproduced, when today build (20141111160205) is used.

Thanks Kai-zhen.   Nick, is it possible for you to try regenerating us another test build with the latest full flash gecko/gaia with v188 backup flame binaries again?   It sounds like Kai-Zhen just tried a private build himself with the scenario we want, and wasnt able to reproduce the busted dialer issue.  I'd be happy to retest it when you have a link handy.   Thanks!

Comment 25

[Nick Thomas [:nthomas] (UTC+12)]

I've started a build, will email details when it's done.

Comment 26

[Nick Thomas [:nthomas] (UTC+12)]

Build details sent do tchung.

Comment 27

[Tony Chung [:tchung]]

(In reply to Nick Thomas [:nthomas] from comment #26)
> Build details sent do tchung.

Okay update for all.  the build has a busted boot.img so this bug still exists.  We can workaround it though, by reflashing boot.img over the test build and the problem goes away.   

Unfortunately, this is still a hack.   We can test this hack on full flash builds for now, but i'd prefer we wait for the correct fix.  If we want to fix bug 1085759 the right way, we need to have a working moz-kernel to be fixed by T2M.    Viral did some investigation, and found that their kernel has changed between v184 and v188, even though T2M denies anything had changed.

So Next steps:  The core dump of the v188 kernel diff has been sent back to T2M to analyze and fix.  Wesly has reached out to T2M for an update of the latest kernel code, and awaiting for them to deliver that over to Viral.  Once Viral gets that code, he estimates about a day to get it ported to mozilla again and handed over to releng to repackage.    Releng can then revisit bug 1085759 and try to spin pvtbuilds against v188 again (with the kernel fixes).     (nthomas to ETA on how long it would take to repackage).    

Pending Kernel delivery, I'm hoping we can get all this resolved next week.

Comment 28

[Tony Chung [:tchung]]

ni? on wesly to keep everyone updated when T2M has provided the kernel fixes.

Comment 29

[Nick Thomas [:nthomas] (UTC+12)]

I'm not sure what repackaging there is for us to do. If there is new code on github then the b2g-manifest will pick that up (or need adjusting if there is a fixed tag, or revision; cue viral/mwu), then it's another compile to test - a few hours to turn that around. If T2M also/instead provides a new base image then it's an extra hour or so.

Comment 30

[Tony Chung [:tchung]]

(In reply to Nick Thomas [:nthomas] from comment #29)
> I'm not sure what repackaging there is for us to do. If there is new code on
> github then the b2g-manifest will pick that up (or need adjusting if there
> is a fixed tag, or revision; cue viral/mwu), then it's another compile to
> test - a few hours to turn that around. If T2M also/instead provides a new
> base image then it's an extra hour or so.

Thanks for the estimation, Nick.   I guess repackaging isnt the right word then, but whatever i meant by rebuilding with T2M's fixed files.    Poking Viral and Wesly if there's an update yet.

Comment 31

[viral [:viralwang]]

update some process here.

Since we met kernel panic here and enter download mode (whitescreen) for debugging.
[   93.820126] msm_routing_ec_ref_rx_put EC ref rx 8 not valid
[   93.825999] Unable to handle kernel paging request at virtual address 5f6d736d
...
[   93.856625] PC is at strcmp+0x4/0x30
[   93.860181] LR is at soc_dapm_mux_update_power+0xa0/0x140
...
[   94.875558] [<c039bb04>] (strcmp+0x4/0x30) from [<c06aaafc>] (soc_dapm_mux_update_power+0xa0/0x140)
[   94.884579] [<c06aaafc>] (soc_dapm_mux_update_power+0xa0/0x140) from [<c06aaf4c>] (snd_soc_dapm_mux_update_power+0x48/0x70)
[   94.895691] [<c06aaf4c>] (snd_soc_dapm_mux_update_power+0x48/0x70) from [<c06c0bf4>] (msm_routing_ec_ref_rx_put+0x88/0x13c)
[   94.906803] [<c06c0bf4>] (msm_routing_ec_ref_rx_put+0x88/0x13c) from [<c06906d8>] (snd_ctl_ioctl+0xb00/0xbd4)
[   94.916698] [<c06906d8>] (snd_ctl_ioctl+0xb00/0xbd4) from [<c025d280>] (do_vfs_ioctl+0x84/0x5ac)
[   94.925465] [<c025d280>] (do_vfs_ioctl+0x84/0x5ac) from [<c025d814>] (sys_ioctl+0x6c/0x7c)
[   94.933710] [<c025d814>] (sys_ioctl+0x6c/0x7c) from [<c0105d20>] (ret_fast_syscall+0x0/0x30)

I think the key point is that we need updated kernel code for v188.
Some experiments here:
 
v188-1 (v188 kernel) => good
v188-1 + moz kernel  => bad
v188-1 + v184 kernel => bad
v184 + moz kernel    => good

After checking the kernel commit, I'm pretty sure that latest kernel partner provide on github still using v184 kernel. kernel commit of v184 is 508ee2d and v188 should be 89ac95e.

Comment 32

[Wesly Huang (EPM)]

Good work Viral!

As we mentioned in issue review meeting w/ T2M now they need to double check what's wrong in their source code sync., not only about Kernel's for this case but also all the rest. Let's see their feedback and I'll also follow w/ them later this week.

Comment 33

[viral [:viralwang]]

since we already update kernel code for v188 base image in bug 1101417, this issue should be fixed.
I already verified in my device.

Comment 34

[Joshua Mitchell (Inactive)]

Issue is resolved, removing action-request keywords

Comment 35

[Tony Chung [:tchung]]

This is fixed on nick's try build, which included the merge from bug 1101417.   leaving verifyme for now, until we have official pvtbuilds with this fix : bug 1085759

Comment 36

[Brogan Zumwalt [Inactive]]

Issue verified fixed on Flame 2.2

User can make outbound call without any crash

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141126040207
Gaia: 41b7be7c67167f367c3c4982ff08651d55455373
Gecko: 7bcc6573d204
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0