Closed Bug 1007598 Opened 6 years ago Closed 6 years ago

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

Categories

(Firefox OS Graveyard :: RIL, defect, critical)

Other
Other
defect
Not set
critical

Tracking

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

RESOLVED FIXED
blocking-b2g 1.3T+
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)

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%.
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)
Duplicate of this bug: 1002838
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: 6 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.
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+
Whiteboard: [sprd309452][partner-blocker] → [sprd309452][partner-blocker][sprd340024]
Thanks everybody for kindly help.
Flags: needinfo?(janjongboom)
Flags: needinfo?(janjongboom)
Duplicate of this bug: 1010091
You need to log in before you can comment on or make changes to this bug.