[B2G][Bluetooth]Making a call while paired to a bluetooth headset causes the device to become unresponsive

RESOLVED FIXED in Firefox OS v1.4

Status

Firefox OS
Bluetooth
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: astole, Assigned: shawnjohnjr)

Tracking

({regression, smoketest})

unspecified
2.0 S1 (9may)
ARM
Gonk (Firefox OS)
regression, smoketest

Firefox Tracking Flags

(blocking-b2g:1.4+, b2g-v1.4 verified, b2g-v2.0 fixed)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
Created attachment 8435071 [details]
logcat

While making a call with a bluetooth headset paired, the device freezes and it can only be restarted by taking the battery out. This issue occurs whether making a call from dialer or contacts. Also, the call is completed, but sound is heard through the device instead of the bluetooth headset.

Repro Steps:
1) Update a Flame to BuildID: 20140605000203
2) Pair with a bluetooth headset
3) Make a call using the dialer or from contacts

Actual:
The device enters an unresponsive state.

Expected:
The call is completed and the device does not become unresponsive.

1.4 Environmental Variables:
Device: Flame 1.4 MOZ
BuildID: 20140605000203
Gaia: 1f238df7ac68a73a4ceb27391a204c800f38ab1c
Gecko: a7b7f1b579cc
Version: 30.0
Firmware Version: v10G-2

Repro frequency: 2/2, 100%
See attached: logcat, video

Comment 1

4 years ago
The issue didn't reproduce on yesterday's 1.4 Flame, doesn't reproduce on today's trunk either 
- the user makes a call while having BT headset paired w/o issues, able to terminate a call and device will stay in normal state.

Flame master m-c
BuildID: 20140605040202
Gaia: d2cfef555dabab415085e548ed44c48a99be5c32
Gecko: 51b428be6213
Version: 32.0a1
v10G-2

'Qawanted' team - please find a regression window on 1.4 Flame. Thanks.
blocking-b2g: --- → 1.4?
Keywords: qaurgent, regression, regressionwindow-wanted
QA Contact: jmercado
Initial Regression Window - Mozilla B2g30 1.4 Flame Engineering:

Last working:
Environmental Variables:
Device: Flame
BuildID: 20140604091218
Gaia: 3ba540532e9cce206b1dd26d70d58c18c1f6af92
Gecko: 5166878df1b0
Version: 30.0

First Broken:
Environmental Variables:
Device: Flame
BuildID: 20140604094817
Gaia: 3ba540532e9cce206b1dd26d70d58c18c1f6af92
Gecko: 84e6e8ab08f1
Version: 30.0


Last working gaia / First broken gecko - Issue occurs - Indicates a Gecko issue
Gaia: 3ba540532e9cce206b1dd26d70d58c18c1f6af92
Gecko: 84e6e8ab08f1


First broken gaia / Last working gekko - Issue does not occur
Gaia: 3ba540532e9cce206b1dd26d70d58c18c1f6af92
Gecko: 5166878df1b0


1.4 Mozilla Flame Pushlog: http://hg.mozilla.org/releases/mozilla-b2g30_v1_4/pushloghtml?fromchange=5166878df1b0&tochange=84e6e8ab08f1


I was unable to locate this issue in either Mozilla Inbound or B2g-inbound for the Flame.  I believe that this issue began in April, but April Flame builds were not recognizing Sim cards preventing me from calling out to reproduce this issue. 
This issue also does not occur on Buri, preventing me from switching to that instead.
Keywords: qaurgent, regressionwindow-wanted
Broken by either bug 993255 or bug 990467.

Szu-Yu - Can you backout whichever patch caused this?
Flags: needinfo?(szchen)
Jason,

We could fix it. It seems that one of the corresponding patch is missed.


Shawn, 

I think that we also have to uplift bug 994411 to v1.4.
The issue here is occurred after we uplifted bug 993255 and bug 990467 (pending MO mechanism).
Flags: needinfo?(szchen) → needinfo?(shuang)
(In reply to Szu-Yu Chen [:aknow] from comment #4)
> Jason,
> 
> We could fix it. It seems that one of the corresponding patch is missed.

I don't want a fix here - I want a backout. We simply cannot cause high risk patch churn in the 1.4 codebase at this point in the release - we're greatly jeopardizing our relationship with other partners that have quality schedules in mind that we must hit in the general 1.4 codebase. QA is also in reduced QA support for 1.4 at this point, so we can't take anything risky into 1.4 at this point.

Ken - I really need the backout here of both bug 993255 and bug 990467. Do my points above make sense?
Flags: needinfo?(kchang)

Comment 6

4 years ago
I worry that we do backout today and we may be asked to land this again next week. Let's see what Ivan say, then we can decide what is the next step.
Flags: needinfo?(kchang)

Comment 7

4 years ago
(In reply to Jason Smith [:jsmith] from comment #5)
>....
> Ken - I really need the backout here of both bug 993255 and bug 990467. Do
> my points above make sense?
 
Instead of backing out the bug 993255 and bug 990467, I'd rather like to ask for QA's help to test the patch in bug 994411 with v1.4 locally first. If all green, let's uplift the patch 994411 to fix the issue.

If we back out the bug 993255 and bug 990467, it means the ECC call cannot be made in v1.4. It does not make sense to me to leave ECC bug in v1.4 because it is the basic function of a phone.

What do you think?
Flags: needinfo?(shuang)
(In reply to Ivan Tsay (:ITsay) from comment #7)
> (In reply to Jason Smith [:jsmith] from comment #5)
> >....
> > Ken - I really need the backout here of both bug 993255 and bug 990467. Do
> > my points above make sense?
>  
> Instead of backing out the bug 993255 and bug 990467, I'd rather like to ask
> for QA's help to test the patch in bug 994411 with v1.4 locally first. If
> all green, let's uplift the patch 994411 to fix the issue.
> 
> If we back out the bug 993255 and bug 990467, it means the ECC call cannot
> be made in v1.4. It does not make sense to me to leave ECC bug in v1.4
> because it is the basic function of a phone.
> 
> What do you think?

QA does not have staffing right now to support full blown testing support of 1.4 at this point. 1.4 is in reduced QA support, so we only take patches into 1.4 generally that are critical blockers with manageable risk.

If the patch is risky & needed for a partner in 1.4, then they should uplift the patch onto their own 1.4 branch, not the general 1.4 branch. We should not risk destabilizing the general 1.4 release this point.
Lawrence - Can you weigh in here on your opinion on this matter?
Flags: needinfo?(lmandel)
The policy is that any change that causes a regression should be backed out. If one of bug 993255 or bug 990467, both of which landed on 1.4 on Wed, have caused this patch, the offending patch should be backed out.

Not(In reply to Ivan Tsay (:ITsay) from comment #7)
> Instead of backing out the bug 993255 and bug 990467, I'd rather like to ask
> for QA's help to test the patch in bug 994411 with v1.4 locally first. If
> all green, let's uplift the patch 994411 to fix the issue.

Backout, get the tree green, fix and test, and then reland when you're ready.
 
> If we back out the bug 993255 and bug 990467, it means the ECC call cannot
> be made in v1.4. It does not make sense to me to leave ECC bug in v1.4
> because it is the basic function of a phone.

To be clear, backing out does not mean that these bugs cannot be fixed in 1.4. It does mean that the fix that landed is not good and needs more work before it can be again considered for approval to land on 1.4.
Flags: needinfo?(lmandel)
per comment 10 - please prep a backout to get the smoketests passing again
Flags: needinfo?(kchang)
Flags: needinfo?(szchen)

Updated

4 years ago
blocking-b2g: 1.4? → 1.4+

Comment 12

4 years ago
Eric, can you find someone to work on this? Thanks.
Flags: needinfo?(echou)
Created attachment 8436619 [details] [diff] [review]
Rollback bug 993255 and bug 990467
Flags: needinfo?(szchen)
I am now running on try server for the 'rollback' patch and will update the result when it finished.

Comment 15

4 years ago
(In reply to Jason Smith [:jsmith] from comment #11)
> per comment 10 - please prep a backout to get the smoketests passing again
Sorry. Based on comment 10, I am afraid that I have a different conclusion from yours. I agree with comment 10,
we must provide a good patch for 1.4. but currently, this bug is not from bad patches. This root cause of this 
bug is that we don't uplift patch of bug 994411 in 1.4. If we uplift that patch, this bug will be fixed. 
Moreover, those bugs have been landed in master for almost 2 months. I don't see any side effect having been 
cropping up in master. Therefore, I think bug 994411, bug 993255, and bug 990467 are good to uplift to 1.4.

So for me, the only question is whether we want to fix these bugs in 1.4. If not, backing out bug 993255 and bug 
990467 is a right method. If yes, I don't see any benefit of backing out bug 993225 and bug 990467.

Kevin, I saw the patch of bug 994411 for 1.4 was ready. However, bug 994411 is not a 1.4+ bug now. I wonder who
can make the final call for this? Should we fix these bugs in 1.4?
Flags: needinfo?(khu)
Flags: needinfo?(kchang)
Flags: needinfo?(echou)

Comment 16

4 years ago
Thanks for the information, Ken. It's very clear. I also checked bug 994411. In this case, I agreed with you to uplift 994411 to fix this bug rather than backing them out.
Flags: needinfo?(khu)

Updated

4 years ago
Depends on: 994411
https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/0ed9bc2696aa
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-b2g-v1.4: --- → fixed
Resolution: --- → FIXED
Assignee: nobody → shuang
status-b2g-v2.0: --- → fixed
Target Milestone: --- → 2.0 S1 (9may)

Comment 18

4 years ago
Verified Fixed in 1.4 - the user makes a call while having BT headset paired w/o issues, able to terminate a call and device will stay in normal state.

Flame 1.4
BuildID: 20140610000204
Gaia: 57c6a24f7c7d16aac132f3cecd3ff9ee8d53cf78
Gecko: 54a7aa1a0423
Version: 30.0
V10G-2
status-b2g-v1.4: fixed → verified
You need to log in before you can comment on or make changes to this bug.