Closed Bug 1007598 Opened 12 years ago Closed 12 years ago

[tarako] device has no response after adding a group call using BT headset

Categories

(Firefox OS Graveyard :: RIL, defect)

Product:
Firefox OS Graveyard
Component:
RIL
Platform:
Other
Other
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(blocking-b2g:1.3T+, b2g-v1.3T verified, b2g-v1.4 fixed)

Status:
RESOLVED FIXED
Project Flags:
blocking-b2g 1.3T+
Tracking Flags:
Tracking Status
b2g-v1.3T --- verified
b2g-v1.4 --- fixed

People

(Reporter: angelc04, Assigned: etienne)

References

Details

(Whiteboard: [sprd309452][partner-blocker][sprd340024])

Attachments

(6 files, 1 obsolete file)

dialer.log
517.36 KB, text/plain
Details
hang around 11:29.
696.66 KB, text/x-log
Details
hang around 11:43
608.79 KB, text/x-log
Details
Gaia PR against master
46 bytes, text/x-github-pull-request
gsvelto
: review+
Details | Review
Gaia PR against 1.3t
46 bytes, text/x-github-pull-request
Details | Review
Gaia PR against 1.4
46 bytes, text/x-github-pull-request
bajaj
: approval-gaia-v1.4+
Details | Review
Attached file adb logcat (obsolete) —
Steps to reproduce --------------------------------------------------------------- 1. Pair device with a BT headset 2. Make a call using test device 3. After call connection is established, add a new call --> Device has no response at all. Attached adb logcat, test starts: 05-08 18:35:48.790 Test build --------------------------------------------------------------------------- Gaia 6badae6610fc111403a24755795e82a675c7c88f Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/5c33164eb0ca BuildID 20140507164001 Version 28.1 ro.build.version.incremental=eng.cltbld.20140507.201830 ro.build.date=Wed May 7 20:18:37 EDT 2014
blocking-b2g: --- → 1.3T?
Attached file dialer.log —
New log. Test starts: 05-08 18:47:16.325 BTW, making group call without BT headset works fine.
Attachment #8419309 - Attachment is obsolete: true
1.3t+, we can reproduce it 100%.
status-b2g-v1.3T: --- → affected
Flags: needinfo?(ttsai)
Flags: needinfo?(kkuo)
Whiteboard: [sprd309452][partner-blocker]
Flags: needinfo?(sku)
strace -i -p 85 [40074e08] msgget(0x1, 0xbea7d940, 0x47303800, 0x477b5220) = 0 [40074e08] msgget(0x1, 0xbea7d940, 0x80000000, 0x1) = 0 [40074e08] msgget(0x1, 0xbea7d910, 0x4734d000, 0) = 0 [40074e08] msgget(0x1, 0xbea7d8e8, 0x448dc804, 0) = 0 [40074e08] msgget(0x1, 0xbea7d940, 0x47303800, 0x477b5220) = 0 [40074e08] msgget(0x1, 0xbea7d940, 0x80000000, 0x1) = 0 [40074e08] msgget(0x1, 0xbea7d910, 0x4734d000, 0) = 0 [40074e08] msgget(0x1, 0xbea7d8e8, 0x448dc804, 0) = 0 [40074e08] msgget(0x1, 0xbea7d940, 0x47303800, 0x477b5220) = 0 [40074e08] msgget(0x1, 0xbea7d940, 0x80000000, 0x1) = 0 [40074e08] msgget(0x1, 0xbea7d910, 0x4734d000, 0) = 0 [40074e08] msgget(0x1, 0xbea7d8e8, 0x448dc804, 0) = 0 [40074e08] msgget(0x1, 0xbea7d940, 0x47303800, 0x477b5220) = 0 [40074e08] msgget(0x1, 0xbea7d940, 0x80000000, 0x1) = 0 [40074e08] msgget(0x1, 0xbea7d910, 0x4734d000, 0) = 0 [40074e08] msgget(0x1, 0xbea7d8e8, 0x448dc804, 0) = 0 [40074e08] msgget(0x1, 0xbea7d940, 0x47303800, 0x477b5220) = 0 [40074e08] msgget(0x1, 0xbea7d940, 0x80000000, 0x1) = 0 [40074e08] msgget(0x1, 0xbea7d910, 0x4734d000, 0) = 0 [40074e08] msgget(0x1, 0xbea7d8e8, 0x448dc804, 0) = 0 [40074e08] msgget(0x1, 0xbea7d940, 0x47303800, 0x477b5220) = 0 [40074e08] msgget(0x1, 0xbea7d940, 0x80000000, 0x1) = 0 [40074e08] msgget(0x1, 0xbea7d910, 0x4734d000, 0) = 0 [40074e08] msgget(0x1, 0xbea7d8e8, 0x448dc804, 0) = 0 [40074e08] msgget(0x1, 0xbea7d940, 0x47303800, 0x477b5220) = 0 40070000-40085000 r-xp 00000000 1f:0b 315 /system/lib/libm.so Size: 84 kB Rss: 0 kB Pss: 0 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 0 kB Referenced: 0 kB Anonymous: 0 kB AnonHugePages: 0 kB Swap: 4 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Locked: 0 kB
I think this is BT headset specific since I can reproduce using Jabra Talk, but not Jabra BT2045. As I know Jabra talk support A2DP but Jabra BT2045 does not.
Attached file hang around 11:29. —
Flags: needinfo?(sku)
Attached file hang around 11:43 —
05-09 11:43:54.123 90 195 W audio_hw_primary: vplayback write over result is 0,frame_size is 4 in frames 1600, out frames 290 05-09 11:43:54.123 90 195 W audio_hw_primary: vplayback out_write call_start(1) call_connected(1) ...in.... 05-09 11:43:54.283 90 195 W audio_hw_primary: vplayback write over result is 0,frame_size is 4 in frames 1600, out frames 290 05-09 11:43:54.283 90 195 W audio_hw_primary: vplayback out_write call_start(1) call_connected(1) ...in.... 05-09 11:43:54.443 90 195 W audio_hw_primary: vplayback write over result is 0,frame_size is 4 in frames 1600, out frames 291 05-09 11:43:54.443 90 195 W audio_hw_primary: vplayback out_write call_start(1) call_connected(1) ...in.... 05-09 11:43:54.523 90 195 W audio_hw_primary: vplayback write over result is 0,frame_size is 4 in frames 1600, out frames 290 05-09 11:43:54.523 90 195 W audio_hw_primary: vplayback out_write call_start(1) call_connected(1) ...in.... 05-09 11:43:54.683 90 195 W audio_hw_primary: vplayback write over result is 0,frame_size is 4 in frames 1600, out frames 290 05-09 11:43:54.683 90 195 W audio_hw_primary: vplayback out_write call_start(1) call_connected(1) ...in.... 05-09 11:43:54.843 90 195 W audio_hw_primary: vplayback write over result is 0,frame_size is 4 in frames 1600, out frames 290 05-09 11:43:54.843 90 195 W audio_hw_primary: vplayback out_write call_start(1) call_connected(1) ...in.... 05-09 11:43:55.003 90 195 W audio_hw_primary: vplayback write over result is 0,frame_size is 4 in frames 1600, out frames 291 05-09 11:43:55.003 90 195 W audio_hw_primary: vplayback out_write call_start(1) call_connected(1) ...in.... 05-09 11:43:55.163 90 195 W audio_hw_primary: vplayback write over result is 0,frame_size is 4 in frames 1600, out frames 290 05-09 11:43:55.163 90 195 W audio_hw_primary: vplayback out_write call_start(1) call_connected(1) ...in.... 05-09 11:43:55.243 90 195 W audio_hw_primary: vplayback write over result is 0,frame_size is 4 in frames 1600, out frames 290 05-09 11:43:55.243 90 195 W audio_hw_primary: vplayback out_write call_start(1) call_connected(1) ...in.... 05-09 11:43:55.403 90 195 W audio_hw_primary: vplayback write over result is 0,frame_size is 4 in frames 1600, out frames 290 05-09 11:43:55.403 90 195 W audio_hw_primary: vplayback out_write call_start(1) call_connected(1) ...in.... 05-09 11:43:55.563 90 195 W audio_hw_primary: vplayback write over result is 0,frame_size is 4 in frames 1600, out frames 291 05-09 11:43:55.563 90 195 W audio_hw_primary: vplayback out_write call_start(1) call_connected(1) ...in.... 05-09 11:43:55.723 90 195 W audio_hw_primary: vplayback write over result is 0,frame_size is 4 in frames 1600, out frames 290 05-09 11:43:55.723 90 195 W audio_hw_primary: vplayback out_write call_start(1) call_connected(1) ...in.... 05-09 11:43:55.883 90 195 W audio_hw_primary: vplayback write over result is 0,frame_size is 4 in frames 1600, out frames 290 05-09 11:43:55.883 90 195 W audio_hw_primary: vplayback out_write call_start(1) call_connected(1) ...in.... 05-09 11:43:55.913 90 190 W audio_hw_primary: call start, Get CMD(13) from cp, paras_size:0 devices:0x2 mode:0 05-09 11:43:55.913 90 190 E audio_hw_primary: :VBC_CMD_HAL_CLOSE IN. 05-09 11:43:55.913 90 190 W audio_hw_primary: VBC_CMD_HAL_CLOSE, try lock 05-09 11:43:55.913 90 190 W audio_hw_primary: VBC_CMD_HAL_CLOSE, got lock 05-09 11:43:56.903 86 1024 W AudioTrack: obtainBuffer timed out (is the CPU pegged?) 0x43e27b00 user=00044c00, server=00043300 05-09 11:43:57.903 86 1024 W AudioTrack: obtainBuffer timed out (is the CPU pegged?) 0x43e27b00 user=00044c00, server=00043300 05-09 11:43:58.913 86 1024 W AudioTrack: obtainBuffer timed out (is the CPU pegged?) 0x43e27b00 user=00044c00, server=00043300 05-09 11:43:59.913 86 1024 W AudioTrack: obtainBuffer timed out (is the CPU pegged?) 0x43e27b00 user=00044c00, server=00043300 05-09 11:44:00.913 86 1024 W AudioTrack: obtainBuffer timed out (is the CPU pegged?) 0x43e27b00 user=00044c00, server=00043300 05-09 11:44:01.913 86 1024 W AudioTrack: obtainBuffer timed out (is the CPU pegged?) 0x43e27b00 user=00044c00, server=00043300 05-09 11:44:02.913 86 1024 W AudioTrack: obtainBuffer timed out (is the CPU pegged?) 0x43e27b00 user=00044c00, server=00043300 05-09 11:44:03.913 86 1024 W AudioTrack: obtainBuffer timed out (is the CPU pegged?) 0x43e27b00 user=00044c00, server=00043300 05-09 11:44:04.913 86 1024 W AudioTrack: obtainBuffer timed out (is the CPU pegged?) 0x43e27b00 user=00044c00, server=00043300 05-09 11:44:05.883 90 195 W audio_hw_primary: vplayback write over result is 0,frame_size is 4 in frames 1600, out frames 290
I found kernel was normal. app processes were normal. I still heard sound of the call, which mean call/audio/bt were all normal. But the screen was stuck and no response to touchscreen and key input. b2g took 95% CPU time , checked by top command using gdb to debug b2g, got some stacks It seemed b2g was doing reflow in a endless loop(not sure about this) If calling DumpJSStack(), b2g crashed. #0 0x40fa2dce in ~nsRefPtr (this=0xbe9a523c, __in_chrg=<value optimized out>) at ../../dist/include/nsAutoPtr.h:886 #1 ~nsFont (this=0xbe9a523c, __in_chrg=<value optimized out>) at /home/ffos/yingxu/6821/gecko/gfx/src/nsFont.cpp:103 #2 0x41662748 in nsLayoutUtils::GetFontMetricsForStyleContext (aStyleContext=<value optimized out>, aFontMetrics=0xbe9a52a4, aInflation=1) at /home/ffos/yingxu/6821/gecko/layout/base/nsLayoutUtils.cpp:2640 #3 0x416934da in ComputeLineHeight (aStyleContext=0x43871d50, aBlockHeight=<value optimized out>, aFontSizeInflation=1) at /home/ffos/yingxu/6821/gecko/layout/generic/nsHTMLReflowState.cpp:2440 #4 nsHTMLReflowState::CalcLineHeight (aStyleContext=0x43871d50, aBlockHeight=<value optimized out>, aFontSizeInflation=1) at /home/ffos/yingxu/6821/gecko/layout/generic/nsHTMLReflowState.cpp:2463 #5 0x416935ac in nsHTMLReflowState::CalcLineHeight (this=<value optimized out>) at /home/ffos/yingxu/6821/gecko/layout/generic/nsHTMLReflowState.cpp:2452 #6 0x4167852e in nsBlockReflowState (this=0xbe9a53f8, aReflowState=..., aPresContext=<value optimized out>, aFrame=<value optimized out>, aTopMarginRoot=true, aBottomMarginRoot=true, aBlockNeedsFloatManager=true, aConsumedHeight=0) at /home/ffos/yingxu/6821/gecko/layout/generic/nsBlockReflowState.cpp:109 #7 0x41676dea in nsBlockFrame::Reflow (this=0x470c1d40, aPresContext=0x46a54000, aMetrics=..., aReflowState=..., aStatus=@0xbe9a57b0) at /home/ffos/yingxu/6821/gecko/layout/generic/nsBlockFrame.cpp:1017 #8 0x4167020e in nsAbsoluteContainingBlock::ReflowAbsoluteFrame (this=<value optimized out>, aDelegatingFrame=0x46fa4750, aPresContext=0x46a54000, aReflowState=..., aContainingBlock=..., aConstrainHeight=true, aKidFrame=0x470c1d40, aStatus=@0xbe9a57b0, aOverflowAreas=0xbe9a5b7c) at /home/ffos/yingxu/6821/gecko/layout/generic/nsAbsoluteContainingBlock.cpp:415 #9 0x416706b6 in nsAbsoluteContainingBlock::Reflow (this=<value optimized out>, aDelegatingFrame=0x46fa4750, aPresContext=0x46a54000, aReflowState=..., aReflowStatus=@0xbe9a5b14, aContainingBlock=..., aConstrainHeight=true, aCBWidthChanged=true, aCBHeightChanged=true, aOverflowAreas=0xbe9a5b7c) at /home/ffos/yingxu/6821/gecko/layout/generic/nsAbsoluteContainingBlock.cpp:137 #10 0x41683b94 in nsFrame::ReflowAbsoluteFrames (this=0x46fa4750, aPresContext=0x46a54000, aDesiredSize=<value optimized out>, aReflowState=..., aStatus=@0xbe9a5b14, aConstrainHeight=true) at /home/ffos/yingxu/6821/gecko/layout/generic/nsFrame.cpp:4211 #11 0x416884e6 in nsFrame::FinishReflowWithAbsoluteFrames (this=0x46fa4750, aPresContext=0x0, aDesiredSize=..., aReflowState=..., aStatus=@0xbe9a5b14, aConstrainHeight=<value optimized out>) at /home/ffos/yingxu/6821/gecko/layout/generic/nsFrame.cpp:4178 #12 0x4167a4e8 in nsCanvasFrame::Reflow (this=0x46fa4750, aPresContext=0x46a54000, aDesiredSize=..., aReflowState=..., aStatus=@0xbe9a5b14) at /home/ffos/yingxu/6821/gecko/layout/generic/nsCanvasFrame.cpp:582 #13 0x4167ca04 in nsContainerFrame::ReflowChild (this=<value optimized out>, aKidFrame=0x46fa4750, aPresContext=0x46a54000, aDesiredSize=..., aReflowState=..., aX=0, aY=0, aFlags=3, aStatus=@0xbe9a5b14, aTracker=0x0) at /home/ffos/yingxu/6821/gecko/layout/generic/nsContainerFrame.cpp:962 #14 0x4168e866 in nsHTMLScrollFrame::ReflowScrolledFrame (this=0x46fa4928, aState=0xbe9a5c0c, aAssumeHScroll=<value optimized out>, aAssumeVScroll=<value optimized out>, aMetrics=0xbe9a5b50, aFirstPass=true) at /home/ffos/yingxu/6821/gecko/layout/generic/nsGfxScrollFrame.cpp:459 #15 0x4168eb1c in nsHTMLScrollFrame::ReflowContents (this=0x46fa4928, aState=0xbe9a5c0c, aDesiredSize=<value optimized out>) at /home/ffos/yingxu/6821/gecko/layout/generic/nsGfxScrollFrame.cpp:557 #16 0x4168ffa4 in nsHTMLScrollFrame::Reflow (this=0x46fa4928, aPresContext=<value optimized out>, aDesiredSize=..., aReflowState=..., aStatus=@0xbe9a60e4) at /home/ffos/yingxu/6821/gecko/layout/generic/nsGfxScrollFrame.cpp:795 #17 0x4167ca04 in nsContainerFrame::ReflowChild (this=<value optimized out>, aKidFrame=0x46fa4928, aPresContext=0x46a54000, aDesiredSize=..., aReflowState=..., aX=0, aY=0, aFlags=0, aStatus=@0xbe9a60e4, ---Type <return> to continue, or q <return> to quit--- aTracker=0x0) at /home/ffos/yingxu/6821/gecko/layout/generic/nsContainerFrame.cpp:962 #18 0x416b12f8 in ViewportFrame::Reflow (this=0x46fa4298, aPresContext=0x46a54000, aDesiredSize=..., aReflowState=..., aStatus=@0xbe9a60e4) at /home/ffos/yingxu/6821/gecko/layout/generic/nsViewportFrame.cpp:222 #19 0x41627bca in PresShell::DoReflow (this=0x46a19a60, target=0x0, aInterruptible=<value optimized out>) at /home/ffos/yingxu/6821/gecko/layout/base/nsPresShell.cpp:8148 #20 0x4162b47c in PresShell::ProcessReflowCommands (this=0x46a19a60, aInterruptible=false) at /home/ffos/yingxu/6821/gecko/layout/base/nsPresShell.cpp:8304 #21 0x4162c0d6 in PresShell::FlushPendingNotifications (this=0x46a19a60, aFlush=...) at /home/ffos/yingxu/6821/gecko/layout/base/nsPresShell.cpp:4055 #22 0x41625a96 in PresShell::FlushPendingNotifications (this=<value optimized out>, aType=<value optimized out>) at /home/ffos/yingxu/6821/gecko/layout/base/nsPresShell.cpp:3901 #23 0x413c09d6 in nsDocument::FlushPendingNotifications (this=0x48433800, aType=Flush_Layout) at /home/ffos/yingxu/6821/gecko/content/base/src/nsDocument.cpp:7199 #24 0x413e1bf6 in mozilla::dom::Element::GetPrimaryFrame (this=0x47d307e0, aType=Flush_Content) at /home/ffos/yingxu/6821/gecko/content/base/src/Element.cpp:1579 #25 0x413e3a4a in mozilla::dom::Element::GetBoundingClientRect (this=0x47d307e0) at /home/ffos/yingxu/6821/gecko/content/base/src/Element.cpp:653 #26 0x410aa60c in getBoundingClientRect (cx=0x42d82320, obj=..., self=0x47d307e0, args=...) at /home/ffos/yingxu/6821/objdir-gecko/dom/bindings/ElementBinding.cpp:1197 #27 0x43d11404 in ?? () #28 0x43d11404 in ?? ()
(gdb) set print elements 0 (gdb) p nsXPConnect::gSelf->GetCurrentJSContext() $1 = (struct JSContext *) 0x436197c0 (gdb) printf "%s", xpc_PrintJSStack(0x436197c0,0,0,0) 0 localized() ["app://callscreen.gaiamobile.org/gaia_build_defer_index.js":126] 1 ll10n_get() ["app://callscreen.gaiamobile.org/gaia_build_defer_index.js":9] 2 ut_addEllipsis() ["app://callscreen.gaiamobile.org/gaia_build_defer_index.js":124] 3 hc_formatPhoneNumber() ["app://callscreen.gaiamobile.org/gaia_build_defer_index.js":243] 4 lookupContact() ["app://callscreen.gaiamobile.org/gaia_build_defer_index.js":239] 5 findCallback() ["app://callscreen.gaiamobile.org/gaia_build_defer_index.js":62]
Hi all, After use gdb to dump javascript stack, it looks like bug 1002838 comment 14
Severity: normal → critical
Flags: needinfo?(timdream)
Flags: needinfo?(etienne)
I have no more information to contribute.
Flags: needinfo?(timdream)
After more tests, I found that this only happens when the second call ended immediately. 1. Call to A 2. Call to B -> Call Ended immediately (you can make B switch off signal) --> Device freeze If the second call can make out, then there is no such problem Hope this information helps.
Add more information, I use Jabra bt headset and has 30%~50% chance to reproduce it. (In reply to pcheng from comment #14) > After more tests, I found that this only happens when the second call ended > immediately. > > 1. Call to A > 2. Call to B -> Call Ended immediately (you can make B switch off signal) > --> Device freeze > > If the second call can make out, then there is no such problem > > Hope this information helps.
Here is the key to reproduce this bug. 1. BT headset with A2DP 2. Second call ended immediately. Not sure why sometimes we cannot make out call, call status directly become Call Ended after I tap on Dial button. Maybe operator network unstable?
I'm still unable to reproduce, tested with various bluetooth headset. So I'm trying "simulate" various race conditions to reproduce the issue thanks to the detailed stack. I'll update the bug as soon as I find anything.
Flags: needinfo?(etienne)
Doesn't look exactly like the video, but by faking a very long call number that get's disconnected before the mozContact request finishes I get a blocked b2g process at 96% CPU. Progress \o/ Not a 100% I'm reproducing the exact same issue but it's well worth a patch + test, will upload one soon.
Assignee: nobody → etienne
Attached file Gaia PR against master —
The 1.3t version is coming.
Attachment #8420111 - Flags: review?(gsvelto)
Attached file Gaia PR against 1.3t —
Let me know if it helps :)
Flags: needinfo?(pcheng)
The duplicate bug 1002838 was marked as blocker, according to Etienne this is reproducible with an infinite loop.
blocking-b2g: 1.3T? → 1.3T+
Comment on attachment 8420111 [details] [review] Gaia PR against master This LGTM but shouldn't we be removing the object entirely after we've called remove() to prevent other similar races? I mean, it seems to me that we could enter a similar loop in other methods so a more robust solution would be to prevent such calls entirely. I may be wrong on this though so I'll leave the decision to you (in case file a follow up after landing this).
Attachment #8420111 - Flags: review?(gsvelto) → review+
Hi! Kai-Zhen, Could you help to verify Etienne's solution on site? Thanks -- Keven
Flags: needinfo?(kkuo) → needinfo?(kli)
I try many times with the BT handset in my hand, I can't reproduce follow comment 0. The person work on this isn't in office today. I can't verify the patch right now. I'll follow up and update this on Monday.
Flags: needinfo?(kli)
(In reply to Gabriele Svelto [:gsvelto] from comment #22) > Comment on attachment 8420111 [details] [review] > Gaia PR against master > > This LGTM but shouldn't we be removing the object entirely after we've > called remove() to prevent other similar races? I mean, it seems to me that > we could enter a similar loop in other methods so a more robust solution > would be to prevent such calls entirely. I may be wrong on this though so > I'll leave the decision to you (in case file a follow up after landing this). .remove() is badly named and we actually need the object around a bit longer after calling it to display the "call ended" message :/
Landed on master: https://github.com/mozilla-b2g/gaia/commit/8a82d479a04817dbd10eb219457e85722f7fc1bd
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
(In reply to Etienne Segonzac (:etienne) from comment #25) > .remove() is badly named and we actually need the object around a bit longer > after calling it to display the "call ended" message :/ I see, maybe something like finalize() would be more appropriate? Also providing documentation for the functions in that file would help a lot.
The fix hasn't been included in build 20140511164002. I will test on next build. Keep needinfo on me.
(In reply to pcheng from comment #29) > The fix hasn't been included in build 20140511164002. I will test on next > build. Keep needinfo on me. Pcheng, Can you check the gaia commit version of build 20140511164002? I think you can get it with check_versions.sh of QA tools.
I could not reproduce this bug following the same steps on today's build. Gaia 90b7f328526626072fa2eeb0664c9b3243b5a2af Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/56e7dd0eec94 BuildID 20140512164003 Version 28.1 ro.build.version.incremental=eng.cltbld.20140512.200303 ro.build.date=Mon May 12 20:03:11 EDT 2014
Flags: needinfo?(pcheng)
Flags: needinfo?(ttsai)
Hi Etienne, Do you think this issue affect v1.4? Thanks!
Flags: needinfo?(etienne)
(In reply to Ivan Tsay (:ITsay) from comment #32) > Hi Etienne, > > Do you think this issue affect v1.4? Thanks! Yes, as soon as bug 990003 get's uplifted.
Flags: needinfo?(etienne)
(In reply to Etienne Segonzac (:etienne) from comment #17) > I'm still unable to reproduce, tested with various bluetooth headset. > So I'm trying "simulate" various race conditions to reproduce the issue > thanks to the detailed stack. > I'll update the bug as soon as I find anything. the cause is this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1015896
Verified fixed on the Tarako v1.3T MOZ ril. Environmental Variables: Device: Tarako 1.3T BuildID: 20140602014001 Gaia: 335486c42498fa7a93c21e4d6121199728602ab8 Gecko: 55e4d83019e5 Version: 28.1 Firmware Version: SP6821a-Gonk-4.0-4-29 Bluetooth group call functions as expected.
status-b2g-v1.3T: fixed → verified
Dear etienne, As the bug 990003 in comment 33 had already been uplifted, please help land the patch into the branch v1.4 for we have reproduced the same issue. Thank you very much:)
Flags: needinfo?(etienne)
Blocks: 990003
Flags: needinfo?(etienne)
Attached file Gaia PR against 1.4 —
NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] [Bug caused by] (feature/regressing bug #): 990003 [User impact] if declined: potential infinite loop rendering the phone unusable until reboot [Testing completed]: classic call test, the patch has been on master an 1.3t for month without any hickups [Risk to taking this patch] (and alternatives if risky): small change with unit test, low [String changes made]: none
Attachment #8479888 - Flags: approval-gaia-v1.4?
Thanks a lot for Etienne's kindly help. Hi Wayne, I feel sorry to trouble you but it's indeed an urgent block issue for SPRD. Could you please help to set approval-gaia-v1.4+ for us? Thank you.
Flags: needinfo?(wchang)
Attachment #8479888 - Flags: approval-gaia-v1.4? → approval-gaia-v1.4?(bbajaj)
Flags: needinfo?(wchang)
Attachment #8479888 - Flags: approval-gaia-v1.4?(bbajaj) → approval-gaia-v1.4+
status-b2g-v1.4: ? → affected
Whiteboard: [sprd309452][partner-blocker] → [sprd309452][partner-blocker][sprd340024]
Thanks everybody for kindly help.
Flags: needinfo?(janjongboom)
Flags: needinfo?(janjongboom)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: