The name of bluetooth isn't consistent with default when get it via "hciconfig get name".

[sunxiaohuix]

root@edison:~# hciconfig get name hci0: Type: BR/EDR Bus: UART BD Address: 00:43:34:B1:13:58 ACL MTU: 1021:8 SCO MTU: 64:1 Name: 'BCM43340B0 37.4 MHz WLBGA_iTR Intel Edison-0122-N'

root@edison:~# bluetoothctl [NEW] Controller 00:43:34:B1:13:58 edison [default] [NEW] Device D6:1D:96:48:30:4F Designer Mouse

archermind@archermind-Z97X-UD7-TH:/media$ hcitool scan Scanning ... 00:43:34:B1:13:58 edison

[markwattier]

I could not duplicate this problem. It always shows 'edison' for the name. My phone ( the Galaxy Grand Prime on the list ) also shows 'edison' for the name.

Do you have more detailed instructions for duplicating this problem?

root@edison:~# bluetoothctl [NEW] Controller 98:4F:EE:04:62:36 edison [default] [bluetooth]# scan on Discovery started [CHG] Controller 98:4F:EE:04:62:36 Discovering: yes [NEW] Device 90:59:AF:14:64:E0 Go Wireless Temp [CHG] Device 90:59:AF:14:64:E0 RSSI: -76 [NEW] Device AC:EE:9E:05:49:0A AC-EE-9E-05-49-0A [CHG] Device AC:EE:9E:05:49:0A RSSI: -77 [CHG] Device AC:EE:9E:05:49:0A RSSI: -87 [CHG] Device 90:59:AF:14:64:E0 RSSI: -85 [NEW] Device 38:2D:E8:21:24:0A Galaxy Grand Prime [bluetooth]# exit [DEL] Controller 98:4F:EE:04:62:36 edison [default] root@edison:~# hciconfig get name hci0: Type: BR/EDR Bus: UART BD Address: 98:4F:EE:04:62:36 ACL MTU: 1021:8 SCO MTU: 64:1 Name: 'edison' root@edison:~#

[sunxiaohuix]

I reproduce the issue with new image contain fowllowing patches. https://github.com/01org/edison-linux/issues/15 https://github.com/01org/edison-linux/issues/14

archermind@archermind-Z97X-UD7-TH:/media$ ssh root@192.168.2.15 Warning: Permanently added '192.168.2.15' (ECDSA) to the list of known hosts. root@edison:~# rfkill unblock bluetooth root@edison:~# bluetoothctl [NEW] Controller 00:43:34:B1:13:58 edison [default] [bluetooth]# power on Changing power on succeeded [CHG] Controller 00:43:34:B1:13:58 Powered: yes [bluetooth]# scan on Discovery started [CHG] Controller 00:43:34:B1:13:58 Discovering: yes [bluetooth]# exit [DEL] Controller 00:43:34:B1:13:58 edison [default] root@edison:~# hciconfig get name hci0: Type: BR/EDR Bus: UART BD Address: 00:43:34:B1:13:58 ACL MTU: 1021:8 SCO MTU: 64:1 Name: 'BCM43340B0 37.4 MHz WLBGA_iTR Intel Edison-0122-N'

[markwattier]

This problem occurs after a reboot but not after a power cycle. I have chased this into bluetooth-rfkill-event, where after reboot it does not execute brcm_patchram_plus during boot, because of a difference in the flags set in the rfkill add event that it processes during boot. It does execute brcm_patchram_plus after a power cycle. This utility invokes an ioctl call to the kernel to execute a HCIUARTSETPROTO command which is important for setting up bluetooth for operation.

I cannot duplicate this problem in the rootfs that we have been using for our development. We have been using Yocto branch jethro, with a detached HEAD at 8a3deca4a4dae430e5434c2f082a4b46bfd5188a. This is not the same as the one used in the build used by the QA team. That one appears to be based on yocto branch dizzy which is much older.

[zhenmingx]

Upgrading bluez5 to '5.33' could solve this issue.

[chenchux]

@zhenmingx Please paster your patch here, thanks~

@sunxiaohuix Please apply zhenming's patch, and re-test this issue again. If fixed, please close this issue, thanks~

[sunxiaohuix]

The issue cannot be reproduced now.

[chenchux]

Please find patch here.

0001-bluez5-update-bluez5-to-5.33.patch