51 bytes, text/x-github-pull-request
|Details | Review | Splinter Review|
51 bytes, text/x-github-pull-request
|Details | Review | Splinter Review|
5.84 MB, video/mp4
Gaia fadfafa17f5175203b8b9457bfb95e5816f54f58 Gecko https://hg.mozilla.org/mozilla-central/rev/75fe3b8f592c BuildID 20140728160201 Version 34.0a1 Device Flame STR: 1. Go to Settings -> Bluetooth 2. Press Rename my device to rename, ex "Flame A" 3. Paired another phone and a BT headset (show on paired devices area) 4. Reboot device 5. Go to Settings -> Bluetooth check Expected result: 1. Device name should still be "Flame A" 2. All paired devices are still exist on paired devices area Actual result: 1. Device name change back to default name 2. All paired devices are gone
Can you confirm the bluetooth address of the device be consistent?
This happened many times the specific partition been erased and cause bluetooth address be changed everytime after booting up.
Yes, the bluetooth address changed after reboot device.
You might need to ask PM to restore that partition. :( I cannot help much about this problem. There is a partition storing bluetooth address, if that partition is gone, random address will be generated every time.
Hi Francis, Could we fix this issue?
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.1?
hi ashiue, i can not reproduce this issue on base image V123 (v 1.3), my Flame's BT is still named as ''Flame A'' and paired device still exist. it's hard to convince me that this is a vendor issue, since shipping build doesn't have this issue. it could be related to m-c you have flashed. loop Taipei QA mike.
QA Wanted for branch checks.
I used the STR in Comment 0 to reproduce this bug. Issue did not reproduce using either "Restart and Power Off" to reset the connected device. I tested the listed build (20140728160201) and all branches listed below. Issue DOES NOT occur on Flame 2.1, 2.0, 1.4, and Buri 2.1 Device: Flame Master Build ID: 20140804041427 Gaia: af9a0a24fb9f4c5ced3602bc14053bd49b136344 Gecko: 71497ed2e0db Version: 34.0a1 (Master) Firmware Version: v122 ------------------------------------------------------------- Device: Flame 2.0 Build ID: 20140804060132 Gaia: 4ab7384db7aee130be165a699472cc19405a4456 Gecko: 5e94ab16ec71 Version: 32.0 (2.0) Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 ------------------------------------------------------------- Build ID: 20140730110705 Gaia: 142953262d2cb031e3db217206edc3507580b0df Gecko: 3c780088aae4 Version: 30.0 (1.4) Firmware Version: v122 User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0 ------------------------------------------------------------- Device: Buri Master Build ID: 20140804041427 Gaia: af9a0a24fb9f4c5ced3602bc14053bd49b136344 Gecko: 71497ed2e0db Version: 34.0a1 (Master) Firmware Version: v1.2device.cfg User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [COM=Bluetooth] → [COM=Bluetooth] [QAnalyst-Triage?]
status-b2g-v1.3: --- → unaffected
status-b2g-v1.4: --- → unaffected
status-b2g-v2.0: --- → unaffected
status-b2g-v2.1: --- → unaffected
comment 7 and comment 9 indicate this issue is a no-repro. It might be appropriate to close as works-for-me or it also might be specific to the BT device being used by the reporter.
QA Whiteboard: [COM=Bluetooth] [QAnalyst-Triage?] → [COM=Bluetooth] [QAnalyst-Triage+]
QA Whiteboard: [COM=Bluetooth] [QAnalyst-Triage+] → [COM=Bluetooth] [QAnalyst-Triage+][lead-review+]
After checking again, this is not a vendor issue since this problem only happens when full flash pvt build.
Hi Vance, I remembered you have checked with partner about this. Any idea? Maybe now full flash pvt build can cause that partition been erased?
https://bugzilla.mozilla.org/show_bug.cgi?id=1017442#c19 Yes, looks like some old Flame devices will have this issue once you flash the device from a older software version to a newer one. Due to the difference of partition table, the traceability partition will be wiped out hence the BT Mac address will be gone. As a result, each time the device boot up, it will generate a new BT MAC address. So youlong, my questions for you are: 1. Can we fix in the later release that if during the first boot up, we find that there is no BT MAC address in the traceability partition, we generate a new BT MAC address and permanently write that into traceability partition? 2. I assume that all the flame devices end users buy from the website will have permanent BT MAC address, right? Thanks! Vance
Based on Comment 14, this is something depend on flame firmware.
This required our partner to provide response anyway. And I think we shall probably track on bug 1017442 due to this might be related to proprietary code.
ok, I just followed the same STR after flashing the latest base image and everything works as expected. Bluetooth address didn't change after reboot and paired devices were still there as well. Alison, mind checking again? If this is the case, IMHO this is a partner specific issue.
This issue always reproduce when full flash our image. According to Shawn's finding, this issue might caused by flashing pvt userdata partition.
(In reply to ashiue from comment #18) > This issue always reproduce when full flash our image. According to Shawn's > finding, this issue might caused by flashing pvt userdata partition. Thanks, Alison. I talked to Viral from Gonk team about this and we had done certain tests last week. However we can't still find a rule of how this happen. Since it's not related to Gaia/Gecko/Gonk Bluetooth, I'm going to re-assign the component to GonkIntegration. Besides, hand over to Viral for keeping track of this.
Component: Bluetooth → GonkIntegration
Created attachment 8471277 [details] [review] Bug 1045504 - add trace_util in extract-files.sh to load BT MAC address
Attachment #8471277 - Flags: review?(kli)
Explainer from Viral: trace_util (which is under /system/bin) will load traceability partition MAC address data section to /data/param/*. This is why after erasing userdata partition, we don't have static address, because in our PVT build /system/bin/trace_util is missing. However, the original build is with trace_util, so address and config under /data/param will be generated whenever boot-up.
Comment on attachment 8471277 [details] [review] Bug 1045504 - add trace_util in extract-files.sh to load BT MAC address This is a partner's util. We need to extract it.
Attachment #8471277 - Flags: review?(kli) → review+
Note: It also depends on kernel module which handles mac address.
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #24) > Note: It also depends on kernel module which handles mac address. We need to merge kernel change anyway.
Here's my test result about the boot.img: 1) t2m zimage + t2m ramdisk + moz dt => good 2) t2m zimage + moz ramdisk + moz dt => bad 3) moz zimage + t2m ramdisk + moz dt => good 4) moz zimage + moz ramdisk + moz dt => bad It looks like our ramdisk make the BT address abnormal Need more time to find out the difference. Note: the t2m part means the images we have in v123 release. the moz part means the images we build after ./config.sh flame
Created attachment 8475778 [details] [review] Bug 1045504 - add trace_util in extract-files.sh to load BT MAC address(v2) Hi Seinlin, I should also update init.target.rc to make trace_util works. Could you please help to review the updated patch? Thanks.
Comment on attachment 8475778 [details] [review] Bug 1045504 - add trace_util in extract-files.sh to load BT MAC address(v2) It looks good. I left comment on github, could you update the PR before check-in? Thanks!
Attachment #8475778 - Flags: review?(kli) → review+
Already update the PR for check-in.
status-b2g-v1.4: unaffected → affected
status-b2g-v2.0: unaffected → affected
status-b2g-v2.1: unaffected → affected
[Blocking Requested - why for this release]: Without this fix "WiFi MAC/BT MAC/IMEI" will use a random value in every boot.
blocking-b2g: 2.1? → 1.4?
Status: NEW → RESOLVED
Last Resolved: 5 years ago
status-b2g-v2.1: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S3 (29aug)
(In reply to Kai-Zhen Li from comment #30) > [Blocking Requested - why for this release]: > Without this fix "WiFi MAC/BT MAC/IMEI" will use a random value in every > boot. This is a low risk fix and only need to be merged into flame device config.
Summary: [Bluetooth] Device could not keep BT's rename and paired devices after reboot → [flame][Bluetooth] Device could not keep BT's rename and paired devices after reboot
[Blocking Requested - why for this release]: For flame only
blocking-b2g: 1.4? → 2.0?
FWIW, POVB on the whiteboard pretty much guarantees this won't get uplifted on our end...
Sorry to make you confused. This is Flame specific source code. Supposedly, it should from partner side but now, it is hosted and maintained on our github by ourselves for some reason. Remove POVB from whiteboard as we need to uplift this fix to v2.0 branch.
status-b2g-v2.0: affected → fixed
[Blocking Requested - why for this release]: Flame manifest is also available in v1.4 branch and it is used to do comparison test. If this fix can be uplifted to v1.4 will be better.
blocking-b2g: 2.0+ → 1.4?
KaiZhen, can you take care of 1.4 as you suggested. Thanks
blocking-b2g: 1.4? → 1.4+
init.target.rc doesn't exist on the v1.4 branch, so I guess that makes the uplift a bit more involved.
Also, per the changes being announced today, this will need approval-gaia-v1.4 requested on it before it can land (even though it has blocking status).
Duplicate of this bug: 1062061
Created attachment 8483335 [details] [review] the is PR for v1.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 #): N/A [User impact] if declined: Without this fix "WiFi MAC/BT MAC/IMEI" will use a random value in every boot. [Testing completed]: Yes. verified on flame [Risk to taking this patch] (and alternatives if risky): Low [String changes made]: None
Attachment #8483335 - Flags: approval-gaia-v1.4?
Attachment #8483335 - Flags: approval-gaia-v1.4? → approval-gaia-v1.4+
status-b2g-v1.4: affected → fixed
Verified on: [master] Gaia 72262d054ffa5d0d2b5a0033f713149281511aea Gecko https://hg.mozilla.org/mozilla-central/rev/4f2cac8d72da BuildID 20140917160215 Version 35.0a1 [v2.1] Gaia 379e68fe729a684fa2fcddb30ea1e65508db73e1 Gecko https://hg.mozilla.org/releases/mozilla-aurora/rev/7ff763eb328b BuildID 20140918000204 Version 34.0a2 [v2.0] Gaia 31434a3949556171f3565ca47ac2b44e810e95e6 Gecko https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/cfedc95605d4 BuildID 20140918000201 Version 32.0 [v1.4] Gaia efa2b8cb095407df942fee7732a5547c7034ef9b Gecko https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/a7f7eaf3f682 BuildID 20140918000205 Version 30.0
Status: RESOLVED → VERIFIED
Created attachment 8529617 [details] Verify_Video_Flame.MP4 This issue has been verified successfully on Flame 2.0 & 2.1. See attachment: Verify_Video_Flame.MP4 Reproducing rate: 0/10 Flame v2.0 version: Gaia-Rev f9d6e3d83c3922e9399a6c27f5ce4cdd27bdfd05 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/45112935086f Build-ID 20141126000203 Version 32.0 Flame v2.1 version: Gaia-Rev db2e84860f5a7cc334464618c6ea9e92ff82e9dd Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/211eae88f119 Build-ID 20141126001202 Version 34.0
status-b2g-v2.0: fixed → verified
status-b2g-v2.1: fixed → verified
You need to log in before you can comment on or make changes to this bug.