| 2019-01-07 15:25:18 |
Paul Larson |
bug |
|
|
added bug |
| 2019-01-16 12:03:35 |
Paolo Pisati |
description |
Using the core18 image from http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/
Kernel snap: 4.15.0-39.42 (72)
rfkill shows there is an hci0 device:
$ rfkill list
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
But bluetoothctl does not detect any controller:
$ sudo bluetoothctl
08:58 Agent registered
08:58 [bluetooth]# list
[...no output...]
If you revert to the 4.4 kernel [4.4.0-1106.111 (76)] it works:
$ sudo bluetoothctl
[NEW] Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
Agent registered
[bluetooth]# list
Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
[bluetooth]# show
Controller 00:00:00:00:5A:AD
Name: BlueZ 5.47
Alias: BlueZ 5.47
Class: 0x00000000
Powered: no
Discoverable: no
Pairable: yes
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (00005005-0000-1000-8000-0002ee000001)
UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)
UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb)
UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d052F
Discovering: no |
Impact:
Upon boot, no hci device is available to userspace, thus bluetooth communication is not possible.
Defect analysis:
The root of the problem lies in these two patches:
$ git log --online drivers/bluetooth/btqcomsmd.c
...
766154b Bluetooth: btqcomsmd: retrieve BD address from DT property
6e51811 Bluetooth: btqcomsmd: Add support for BD address setup
...
Qualcomm engineer found that btqcomsmd had no BD address burned in (nor via ROM, neither internally) and it was always coming up with the same address, probably derived from manufacturer ID and / or chip ID.
To fix this, they pushed the burden of generating a unique per-board BD address to the Qualcomm bootloader and make it pass down via DTB to the live kernel - and if no address was present in the DTB, the hci was left unconfigured.
Fix:
So *technically* speaking, the kernel is correct in this case, it's our dragonboard image (e.g. Ubuntu Core) that doesn't extract the generated BD address from the Qualcomm bootloader and pass it down to the kernel.
On the other hand, having Bluetooth working out of the box (even with a dummy address), is a nice feature to have, so i slightly modified Qualcomm's code introduced in the two above patches, and made the lack of DB address in DTB non fatal:
if DTB_has_BD_address()
read_BD_addr_and_apply_it()
else
default_back_to_dummy_addr()
end if
And surrounded the modification in #ifdef...#endif brackets to keep it local.
How to test:
By default, on a patched kernel, the hci device will have a default address:
ubuntu@dragon410c:~$ hcitool dev
Devices:
hci0 00:00:00:00:5A:AD
the address " 00:00:00:00:5A:AD" might vary per board, but will be consistent after every reboot.
The other option is to specify a custom address via dtb, e.g. using uboot to manipulate the dtb - we assume the dtb ws loaded in memory at ${fdt_addr}:
dragonboard410c => fdt addr ${fdt_addr}
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
compatible = "qcom,wcnss-bt";
};
dragonboard410c => fdt resize
dragonboard410c => fdt set /soc/wcnss/smd-edge/wcnss/bt/ local-bd-address [ 55 44 33 22 11 00 ]
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
local-bd-address = [55 44 33 22 11 00];
compatible = "qcom,wcnss-bt";
};
then proceed with the rest of the boot process and check hci:
$ hcitool dev
Devices:
hci0 00:11:22:33:44:55
In both cases, blueooth work afterward, and can be used to communicate with other devices:
ubuntu@dragon410c:~$ hcitool scan
Scanning ...
C0:BD:54:12:4E:D1 My dummy device
Regression potential:
None, the fix is surronded with #ifdef...#endif thus it doesn't exist outside of it.
--
Using the core18 image from http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/
Kernel snap: 4.15.0-39.42 (72)
rfkill shows there is an hci0 device:
$ rfkill list
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
But bluetoothctl does not detect any controller:
$ sudo bluetoothctl
08:58 Agent registered
08:58 [bluetooth]# list
[...no output...]
If you revert to the 4.4 kernel [4.4.0-1106.111 (76)] it works:
$ sudo bluetoothctl
[NEW] Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
Agent registered
[bluetooth]# list
Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
[bluetooth]# show
Controller 00:00:00:00:5A:AD
Name: BlueZ 5.47
Alias: BlueZ 5.47
Class: 0x00000000
Powered: no
Discoverable: no
Pairable: yes
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (00005005-0000-1000-8000-0002ee000001)
UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)
UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb)
UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d052F
Discovering: no |
|
| 2019-01-16 12:10:58 |
Paolo Pisati |
attachment added |
|
0001-UBUNTU-SAUCE-btqcomsmd-introduce-BT_QCOMSMD_HACK.patch https://bugs.launchpad.net/ubuntu/+source/linux-snapdragon/+bug/1810797/+attachment/5229614/+files/0001-UBUNTU-SAUCE-btqcomsmd-introduce-BT_QCOMSMD_HACK.patch |
|
| 2019-01-16 12:11:16 |
Paolo Pisati |
attachment added |
|
0002-UBUNTU-Config-arm64-snapdragon-BT_QCOMSMD_HACK-y.patch https://bugs.launchpad.net/ubuntu/+source/linux-snapdragon/+bug/1810797/+attachment/5229615/+files/0002-UBUNTU-Config-arm64-snapdragon-BT_QCOMSMD_HACK-y.patch |
|
| 2019-01-16 12:11:24 |
Paolo Pisati |
nominated for series |
|
Ubuntu Bionic |
|
| 2019-01-16 12:24:48 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2019-01-16 12:24:49 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Joseph Salisbury |
| 2019-01-16 14:44:53 |
Paolo Pisati |
bug task added |
|
linux (Ubuntu) |
|
| 2019-01-16 14:45:43 |
Paolo Pisati |
linux-snapdragon (Ubuntu): status |
New |
Invalid |
|
| 2019-01-16 15:00:06 |
Ubuntu Kernel Bot |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2019-01-16 15:42:34 |
Paolo Pisati |
description |
Impact:
Upon boot, no hci device is available to userspace, thus bluetooth communication is not possible.
Defect analysis:
The root of the problem lies in these two patches:
$ git log --online drivers/bluetooth/btqcomsmd.c
...
766154b Bluetooth: btqcomsmd: retrieve BD address from DT property
6e51811 Bluetooth: btqcomsmd: Add support for BD address setup
...
Qualcomm engineer found that btqcomsmd had no BD address burned in (nor via ROM, neither internally) and it was always coming up with the same address, probably derived from manufacturer ID and / or chip ID.
To fix this, they pushed the burden of generating a unique per-board BD address to the Qualcomm bootloader and make it pass down via DTB to the live kernel - and if no address was present in the DTB, the hci was left unconfigured.
Fix:
So *technically* speaking, the kernel is correct in this case, it's our dragonboard image (e.g. Ubuntu Core) that doesn't extract the generated BD address from the Qualcomm bootloader and pass it down to the kernel.
On the other hand, having Bluetooth working out of the box (even with a dummy address), is a nice feature to have, so i slightly modified Qualcomm's code introduced in the two above patches, and made the lack of DB address in DTB non fatal:
if DTB_has_BD_address()
read_BD_addr_and_apply_it()
else
default_back_to_dummy_addr()
end if
And surrounded the modification in #ifdef...#endif brackets to keep it local.
How to test:
By default, on a patched kernel, the hci device will have a default address:
ubuntu@dragon410c:~$ hcitool dev
Devices:
hci0 00:00:00:00:5A:AD
the address " 00:00:00:00:5A:AD" might vary per board, but will be consistent after every reboot.
The other option is to specify a custom address via dtb, e.g. using uboot to manipulate the dtb - we assume the dtb ws loaded in memory at ${fdt_addr}:
dragonboard410c => fdt addr ${fdt_addr}
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
compatible = "qcom,wcnss-bt";
};
dragonboard410c => fdt resize
dragonboard410c => fdt set /soc/wcnss/smd-edge/wcnss/bt/ local-bd-address [ 55 44 33 22 11 00 ]
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
local-bd-address = [55 44 33 22 11 00];
compatible = "qcom,wcnss-bt";
};
then proceed with the rest of the boot process and check hci:
$ hcitool dev
Devices:
hci0 00:11:22:33:44:55
In both cases, blueooth work afterward, and can be used to communicate with other devices:
ubuntu@dragon410c:~$ hcitool scan
Scanning ...
C0:BD:54:12:4E:D1 My dummy device
Regression potential:
None, the fix is surronded with #ifdef...#endif thus it doesn't exist outside of it.
--
Using the core18 image from http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/
Kernel snap: 4.15.0-39.42 (72)
rfkill shows there is an hci0 device:
$ rfkill list
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
But bluetoothctl does not detect any controller:
$ sudo bluetoothctl
08:58 Agent registered
08:58 [bluetooth]# list
[...no output...]
If you revert to the 4.4 kernel [4.4.0-1106.111 (76)] it works:
$ sudo bluetoothctl
[NEW] Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
Agent registered
[bluetooth]# list
Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
[bluetooth]# show
Controller 00:00:00:00:5A:AD
Name: BlueZ 5.47
Alias: BlueZ 5.47
Class: 0x00000000
Powered: no
Discoverable: no
Pairable: yes
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (00005005-0000-1000-8000-0002ee000001)
UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)
UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb)
UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d052F
Discovering: no |
Impact:
Upon boot, no hci device is available to userspace, thus bluetooth communication is not possible.
Defect analysis:
The root of the problem lies in these two patches:
$ git log --online drivers/bluetooth/btqcomsmd.c
...
766154b Bluetooth: btqcomsmd: retrieve BD address from DT property
6e51811 Bluetooth: btqcomsmd: Add support for BD address setup
...
Qualcomm engineer found that btqcomsmd had no BD address burned in (nor via ROM, neither internally) and it was always coming up with the same address, probably derived from manufacturer ID and / or chip ID.
To fix this, they pushed the burden of generating a unique per-board BD address to the Qualcomm bootloader and make it pass down via DTB to the live kernel - and if no address was present in the DTB, the hci was left unconfigured.
Fix:
So *technically* speaking, the kernel is correct in this case, it's our dragonboard image (e.g. Ubuntu Core) that doesn't extract the generated BD address from the Qualcomm bootloader and pass it down to the kernel.
On the other hand, having Bluetooth working out of the box (even with a dummy address), is a nice feature to have, so i slightly modified Qualcomm's code introduced in the two above patches, and made the lack of DB address in DTB non fatal.
And surrounded the modification in #ifdef...#endif brackets to keep it local.
How to test:
By default, on a patched kernel, the hci device will have a default address:
ubuntu@dragon410c:~$ hcitool dev
Devices:
hci0 00:00:00:00:5A:AD
the address " 00:00:00:00:5A:AD" might vary per board, but will be consistent after every reboot.
The other option is to specify a custom address via dtb, e.g. using uboot to manipulate the dtb - we assume the dtb ws loaded in memory at ${fdt_addr}:
dragonboard410c => fdt addr ${fdt_addr}
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
compatible = "qcom,wcnss-bt";
};
dragonboard410c => fdt resize
dragonboard410c => fdt set /soc/wcnss/smd-edge/wcnss/bt/ local-bd-address [ 55 44 33 22 11 00 ]
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
local-bd-address = [55 44 33 22 11 00];
compatible = "qcom,wcnss-bt";
};
then proceed with the rest of the boot process and check hci:
$ hcitool dev
Devices:
hci0 00:11:22:33:44:55
In both cases, blueooth work afterward, and can be used to communicate with other devices:
ubuntu@dragon410c:~$ hcitool scan
Scanning ...
C0:BD:54:12:4E:D1 My dummy device
Regression potential:
None, the fix is surronded with #ifdef...#endif thus it doesn't exist outside of it.
--
Using the core18 image from http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/
Kernel snap: 4.15.0-39.42 (72)
rfkill shows there is an hci0 device:
$ rfkill list
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
But bluetoothctl does not detect any controller:
$ sudo bluetoothctl
08:58 Agent registered
08:58 [bluetooth]# list
[...no output...]
If you revert to the 4.4 kernel [4.4.0-1106.111 (76)] it works:
$ sudo bluetoothctl
[NEW] Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
Agent registered
[bluetooth]# list
Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
[bluetooth]# show
Controller 00:00:00:00:5A:AD
Name: BlueZ 5.47
Alias: BlueZ 5.47
Class: 0x00000000
Powered: no
Discoverable: no
Pairable: yes
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (00005005-0000-1000-8000-0002ee000001)
UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)
UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb)
UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d052F
Discovering: no |
|
| 2019-01-16 15:43:55 |
Paolo Pisati |
description |
Impact:
Upon boot, no hci device is available to userspace, thus bluetooth communication is not possible.
Defect analysis:
The root of the problem lies in these two patches:
$ git log --online drivers/bluetooth/btqcomsmd.c
...
766154b Bluetooth: btqcomsmd: retrieve BD address from DT property
6e51811 Bluetooth: btqcomsmd: Add support for BD address setup
...
Qualcomm engineer found that btqcomsmd had no BD address burned in (nor via ROM, neither internally) and it was always coming up with the same address, probably derived from manufacturer ID and / or chip ID.
To fix this, they pushed the burden of generating a unique per-board BD address to the Qualcomm bootloader and make it pass down via DTB to the live kernel - and if no address was present in the DTB, the hci was left unconfigured.
Fix:
So *technically* speaking, the kernel is correct in this case, it's our dragonboard image (e.g. Ubuntu Core) that doesn't extract the generated BD address from the Qualcomm bootloader and pass it down to the kernel.
On the other hand, having Bluetooth working out of the box (even with a dummy address), is a nice feature to have, so i slightly modified Qualcomm's code introduced in the two above patches, and made the lack of DB address in DTB non fatal.
And surrounded the modification in #ifdef...#endif brackets to keep it local.
How to test:
By default, on a patched kernel, the hci device will have a default address:
ubuntu@dragon410c:~$ hcitool dev
Devices:
hci0 00:00:00:00:5A:AD
the address " 00:00:00:00:5A:AD" might vary per board, but will be consistent after every reboot.
The other option is to specify a custom address via dtb, e.g. using uboot to manipulate the dtb - we assume the dtb ws loaded in memory at ${fdt_addr}:
dragonboard410c => fdt addr ${fdt_addr}
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
compatible = "qcom,wcnss-bt";
};
dragonboard410c => fdt resize
dragonboard410c => fdt set /soc/wcnss/smd-edge/wcnss/bt/ local-bd-address [ 55 44 33 22 11 00 ]
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
local-bd-address = [55 44 33 22 11 00];
compatible = "qcom,wcnss-bt";
};
then proceed with the rest of the boot process and check hci:
$ hcitool dev
Devices:
hci0 00:11:22:33:44:55
In both cases, blueooth work afterward, and can be used to communicate with other devices:
ubuntu@dragon410c:~$ hcitool scan
Scanning ...
C0:BD:54:12:4E:D1 My dummy device
Regression potential:
None, the fix is surronded with #ifdef...#endif thus it doesn't exist outside of it.
--
Using the core18 image from http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/
Kernel snap: 4.15.0-39.42 (72)
rfkill shows there is an hci0 device:
$ rfkill list
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
But bluetoothctl does not detect any controller:
$ sudo bluetoothctl
08:58 Agent registered
08:58 [bluetooth]# list
[...no output...]
If you revert to the 4.4 kernel [4.4.0-1106.111 (76)] it works:
$ sudo bluetoothctl
[NEW] Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
Agent registered
[bluetooth]# list
Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
[bluetooth]# show
Controller 00:00:00:00:5A:AD
Name: BlueZ 5.47
Alias: BlueZ 5.47
Class: 0x00000000
Powered: no
Discoverable: no
Pairable: yes
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (00005005-0000-1000-8000-0002ee000001)
UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)
UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb)
UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d052F
Discovering: no |
Impact:
Upon boot, no hci device is available to userspace, thus bluetooth communication is not possible.
Defect analysis:
The root of the problem lies in these two patches:
$ git log --online drivers/bluetooth/btqcomsmd.c
...
766154b Bluetooth: btqcomsmd: retrieve BD address from DT property
6e51811 Bluetooth: btqcomsmd: Add support for BD address setup
...
Qualcomm engineer found that btqcomsmd had no BD address burned in (nor via ROM, neither internally) and it was always coming up with the same address, probably derived from manufacturer ID and / or chip ID.
To fix this, they pushed the burden of generating a unique per-board BD address to the Qualcomm bootloader and make it pass down via DTB to the live kernel - and if no address was present in the DTB, the hci was left unconfigured.
Fix:
So *technically* speaking, the kernel is correct in this case, it's our dragonboard image (e.g. Ubuntu Core) that doesn't extract the generated BD address from the Qualcomm bootloader and pass it down to the kernel.
On the other hand, having Bluetooth working out of the box (even with a dummy address), is a nice feature to have, so i slightly modified Qualcomm's code introduced in the two above patches, and made the lack of DB address in DTB non fatal.
And surrounded the modification in #ifdef...#endif brackets to keep it local.
How to test:
By default, on a patched kernel, the hci device will have a default address:
ubuntu@dragon410c:~$ hcitool dev
Devices:
hci0 00:00:00:00:5A:AD
the address " 00:00:00:00:5A:AD" might vary, but will be consistent after every reboot.
The other option is to specify a custom BD address, e.g. using uboot to manipulate the dtb - we assume the dtb was loaded in memory at ${fdt_addr}:
dragonboard410c => fdt addr ${fdt_addr}
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
compatible = "qcom,wcnss-bt";
};
dragonboard410c => fdt resize
dragonboard410c => fdt set /soc/wcnss/smd-edge/wcnss/bt/ local-bd-address [ 55 44 33 22 11 00 ]
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
local-bd-address = [55 44 33 22 11 00];
compatible = "qcom,wcnss-bt";
};
then proceed with the rest of the boot process and check hci:
$ hcitool dev
Devices:
hci0 00:11:22:33:44:55
In both cases, blueooth work afterward, and can be used to communicate with other devices:
ubuntu@dragon410c:~$ hcitool scan
Scanning ...
C0:BD:54:12:4E:D1 My dummy device
Regression potential:
None, the fix is surronded with #ifdef...#endif thus it doesn't exist outside of it.
--
Using the core18 image from http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/
Kernel snap: 4.15.0-39.42 (72)
rfkill shows there is an hci0 device:
$ rfkill list
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
But bluetoothctl does not detect any controller:
$ sudo bluetoothctl
08:58 Agent registered
08:58 [bluetooth]# list
[...no output...]
If you revert to the 4.4 kernel [4.4.0-1106.111 (76)] it works:
$ sudo bluetoothctl
[NEW] Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
Agent registered
[bluetooth]# list
Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
[bluetooth]# show
Controller 00:00:00:00:5A:AD
Name: BlueZ 5.47
Alias: BlueZ 5.47
Class: 0x00000000
Powered: no
Discoverable: no
Pairable: yes
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (00005005-0000-1000-8000-0002ee000001)
UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)
UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb)
UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d052F
Discovering: no |
|
| 2019-01-16 15:44:24 |
Paolo Pisati |
description |
Impact:
Upon boot, no hci device is available to userspace, thus bluetooth communication is not possible.
Defect analysis:
The root of the problem lies in these two patches:
$ git log --online drivers/bluetooth/btqcomsmd.c
...
766154b Bluetooth: btqcomsmd: retrieve BD address from DT property
6e51811 Bluetooth: btqcomsmd: Add support for BD address setup
...
Qualcomm engineer found that btqcomsmd had no BD address burned in (nor via ROM, neither internally) and it was always coming up with the same address, probably derived from manufacturer ID and / or chip ID.
To fix this, they pushed the burden of generating a unique per-board BD address to the Qualcomm bootloader and make it pass down via DTB to the live kernel - and if no address was present in the DTB, the hci was left unconfigured.
Fix:
So *technically* speaking, the kernel is correct in this case, it's our dragonboard image (e.g. Ubuntu Core) that doesn't extract the generated BD address from the Qualcomm bootloader and pass it down to the kernel.
On the other hand, having Bluetooth working out of the box (even with a dummy address), is a nice feature to have, so i slightly modified Qualcomm's code introduced in the two above patches, and made the lack of DB address in DTB non fatal.
And surrounded the modification in #ifdef...#endif brackets to keep it local.
How to test:
By default, on a patched kernel, the hci device will have a default address:
ubuntu@dragon410c:~$ hcitool dev
Devices:
hci0 00:00:00:00:5A:AD
the address " 00:00:00:00:5A:AD" might vary, but will be consistent after every reboot.
The other option is to specify a custom BD address, e.g. using uboot to manipulate the dtb - we assume the dtb was loaded in memory at ${fdt_addr}:
dragonboard410c => fdt addr ${fdt_addr}
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
compatible = "qcom,wcnss-bt";
};
dragonboard410c => fdt resize
dragonboard410c => fdt set /soc/wcnss/smd-edge/wcnss/bt/ local-bd-address [ 55 44 33 22 11 00 ]
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
local-bd-address = [55 44 33 22 11 00];
compatible = "qcom,wcnss-bt";
};
then proceed with the rest of the boot process and check hci:
$ hcitool dev
Devices:
hci0 00:11:22:33:44:55
In both cases, blueooth work afterward, and can be used to communicate with other devices:
ubuntu@dragon410c:~$ hcitool scan
Scanning ...
C0:BD:54:12:4E:D1 My dummy device
Regression potential:
None, the fix is surronded with #ifdef...#endif thus it doesn't exist outside of it.
--
Using the core18 image from http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/
Kernel snap: 4.15.0-39.42 (72)
rfkill shows there is an hci0 device:
$ rfkill list
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
But bluetoothctl does not detect any controller:
$ sudo bluetoothctl
08:58 Agent registered
08:58 [bluetooth]# list
[...no output...]
If you revert to the 4.4 kernel [4.4.0-1106.111 (76)] it works:
$ sudo bluetoothctl
[NEW] Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
Agent registered
[bluetooth]# list
Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
[bluetooth]# show
Controller 00:00:00:00:5A:AD
Name: BlueZ 5.47
Alias: BlueZ 5.47
Class: 0x00000000
Powered: no
Discoverable: no
Pairable: yes
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (00005005-0000-1000-8000-0002ee000001)
UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)
UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb)
UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d052F
Discovering: no |
Impact:
Upon boot, no hci device is available to userspace, thus bluetooth communication is not possible.
Defect analysis:
The root of the problem lies in these two patches:
$ git log --online drivers/bluetooth/btqcomsmd.c
...
766154b Bluetooth: btqcomsmd: retrieve BD address from DT property
6e51811 Bluetooth: btqcomsmd: Add support for BD address setup
...
Qualcomm engineer found that btqcomsmd had no BD address burned in (nor via ROM, neither internally) and it was always coming up with the same address, probably derived from manufacturer ID and / or chip ID.
To fix this, they pushed the burden of generating a unique per-board BD address to the Qualcomm bootloader and make it pass down via DTB to the live kernel - and if no address was present in the DTB, the hci was left unconfigured.
Fix:
So *technically* speaking, the kernel is correct in this case, it's our dragonboard image (e.g. Ubuntu Core) that doesn't extract the generated BD address from the Qualcomm bootloader and pass it down to the kernel.
On the other hand, having Bluetooth working out of the box (even with a dummy address), is a nice feature to have, so i slightly modified Qualcomm's code introduced in the two above patches, and made the lack of BD address in DTB non fatal.
And surrounded the modification in #ifdef...#endif brackets to keep it local.
How to test:
By default, on a patched kernel, the hci device will have a default address:
ubuntu@dragon410c:~$ hcitool dev
Devices:
hci0 00:00:00:00:5A:AD
the address " 00:00:00:00:5A:AD" might vary, but will be consistent after every reboot.
The other option is to specify a custom BD address, e.g. using uboot to manipulate the dtb - we assume the dtb was loaded in memory at ${fdt_addr}:
dragonboard410c => fdt addr ${fdt_addr}
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
compatible = "qcom,wcnss-bt";
};
dragonboard410c => fdt resize
dragonboard410c => fdt set /soc/wcnss/smd-edge/wcnss/bt/ local-bd-address [ 55 44 33 22 11 00 ]
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
local-bd-address = [55 44 33 22 11 00];
compatible = "qcom,wcnss-bt";
};
then proceed with the rest of the boot process and check hci:
$ hcitool dev
Devices:
hci0 00:11:22:33:44:55
In both cases, blueooth work afterward, and can be used to communicate with other devices:
ubuntu@dragon410c:~$ hcitool scan
Scanning ...
C0:BD:54:12:4E:D1 My dummy device
Regression potential:
None, the fix is surronded with #ifdef...#endif thus it doesn't exist outside of it.
--
Using the core18 image from http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/
Kernel snap: 4.15.0-39.42 (72)
rfkill shows there is an hci0 device:
$ rfkill list
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
But bluetoothctl does not detect any controller:
$ sudo bluetoothctl
08:58 Agent registered
08:58 [bluetooth]# list
[...no output...]
If you revert to the 4.4 kernel [4.4.0-1106.111 (76)] it works:
$ sudo bluetoothctl
[NEW] Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
Agent registered
[bluetooth]# list
Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
[bluetooth]# show
Controller 00:00:00:00:5A:AD
Name: BlueZ 5.47
Alias: BlueZ 5.47
Class: 0x00000000
Powered: no
Discoverable: no
Pairable: yes
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (00005005-0000-1000-8000-0002ee000001)
UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)
UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb)
UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d052F
Discovering: no |
|
| 2019-01-16 15:46:15 |
Paolo Pisati |
description |
Impact:
Upon boot, no hci device is available to userspace, thus bluetooth communication is not possible.
Defect analysis:
The root of the problem lies in these two patches:
$ git log --online drivers/bluetooth/btqcomsmd.c
...
766154b Bluetooth: btqcomsmd: retrieve BD address from DT property
6e51811 Bluetooth: btqcomsmd: Add support for BD address setup
...
Qualcomm engineer found that btqcomsmd had no BD address burned in (nor via ROM, neither internally) and it was always coming up with the same address, probably derived from manufacturer ID and / or chip ID.
To fix this, they pushed the burden of generating a unique per-board BD address to the Qualcomm bootloader and make it pass down via DTB to the live kernel - and if no address was present in the DTB, the hci was left unconfigured.
Fix:
So *technically* speaking, the kernel is correct in this case, it's our dragonboard image (e.g. Ubuntu Core) that doesn't extract the generated BD address from the Qualcomm bootloader and pass it down to the kernel.
On the other hand, having Bluetooth working out of the box (even with a dummy address), is a nice feature to have, so i slightly modified Qualcomm's code introduced in the two above patches, and made the lack of BD address in DTB non fatal.
And surrounded the modification in #ifdef...#endif brackets to keep it local.
How to test:
By default, on a patched kernel, the hci device will have a default address:
ubuntu@dragon410c:~$ hcitool dev
Devices:
hci0 00:00:00:00:5A:AD
the address " 00:00:00:00:5A:AD" might vary, but will be consistent after every reboot.
The other option is to specify a custom BD address, e.g. using uboot to manipulate the dtb - we assume the dtb was loaded in memory at ${fdt_addr}:
dragonboard410c => fdt addr ${fdt_addr}
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
compatible = "qcom,wcnss-bt";
};
dragonboard410c => fdt resize
dragonboard410c => fdt set /soc/wcnss/smd-edge/wcnss/bt/ local-bd-address [ 55 44 33 22 11 00 ]
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
local-bd-address = [55 44 33 22 11 00];
compatible = "qcom,wcnss-bt";
};
then proceed with the rest of the boot process and check hci:
$ hcitool dev
Devices:
hci0 00:11:22:33:44:55
In both cases, blueooth work afterward, and can be used to communicate with other devices:
ubuntu@dragon410c:~$ hcitool scan
Scanning ...
C0:BD:54:12:4E:D1 My dummy device
Regression potential:
None, the fix is surronded with #ifdef...#endif thus it doesn't exist outside of it.
--
Using the core18 image from http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/
Kernel snap: 4.15.0-39.42 (72)
rfkill shows there is an hci0 device:
$ rfkill list
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
But bluetoothctl does not detect any controller:
$ sudo bluetoothctl
08:58 Agent registered
08:58 [bluetooth]# list
[...no output...]
If you revert to the 4.4 kernel [4.4.0-1106.111 (76)] it works:
$ sudo bluetoothctl
[NEW] Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
Agent registered
[bluetooth]# list
Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
[bluetooth]# show
Controller 00:00:00:00:5A:AD
Name: BlueZ 5.47
Alias: BlueZ 5.47
Class: 0x00000000
Powered: no
Discoverable: no
Pairable: yes
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (00005005-0000-1000-8000-0002ee000001)
UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)
UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb)
UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d052F
Discovering: no |
Impact:
Upon boot, no hci device is available to userspace, thus bluetooth communication is not possible.
Defect analysis:
The root of the problem lies in these two patches:
$ git log --online drivers/bluetooth/btqcomsmd.c
...
766154b Bluetooth: btqcomsmd: retrieve BD address from DT property
6e51811 Bluetooth: btqcomsmd: Add support for BD address setup
...
Qualcomm engineer found that btqcomsmd had no BD address burned in (nor via ROM, neither internally) and it was always coming up with the same address, probably derived from manufacturer ID and / or chip ID.
To fix this, they pushed the burden of generating a unique per-board BD address to the Qualcomm bootloader and make it pass down via DTB to the live kernel - and if no address was present in the DTB, the hci was left unconfigured.
Fix:
So *technically* speaking, the kernel is correct in this case, it's our dragonboard image (e.g. Ubuntu Core) that doesn't extract the generated BD address from the Qualcomm bootloader and pass it down to the kernel.
On the other hand, having Bluetooth working out of the box (even with a dummy address), is a nice feature to have, so i slightly modified Qualcomm's code introduced in the two above patches, and made the lack of BD address in DTB non fatal:
if BD_is_present_in_DTB()
read_BD_and_apply_setup()
else
let_hci_core_generate_BD()
end if
And surrounded the modification in #ifdef...#endif brackets to keep it local.
How to test:
By default, on a patched kernel, the hci device will have a default address:
ubuntu@dragon410c:~$ hcitool dev
Devices:
hci0 00:00:00:00:5A:AD
the address " 00:00:00:00:5A:AD" might vary, but will be consistent after every reboot.
The other option is to specify a custom BD address, e.g. using uboot to manipulate the dtb - we assume the dtb was loaded in memory at ${fdt_addr}:
dragonboard410c => fdt addr ${fdt_addr}
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
compatible = "qcom,wcnss-bt";
};
dragonboard410c => fdt resize
dragonboard410c => fdt set /soc/wcnss/smd-edge/wcnss/bt/ local-bd-address [ 55 44 33 22 11 00 ]
dragonboard410c => fdt print /soc/wcnss/smd-edge/wcnss/bt/
bt {
local-bd-address = [55 44 33 22 11 00];
compatible = "qcom,wcnss-bt";
};
then proceed with the rest of the boot process and check hci:
$ hcitool dev
Devices:
hci0 00:11:22:33:44:55
In both cases, blueooth work afterward, and can be used to communicate with other devices:
ubuntu@dragon410c:~$ hcitool scan
Scanning ...
C0:BD:54:12:4E:D1 My dummy device
Regression potential:
None, the fix is surronded with #ifdef...#endif thus it doesn't exist outside of it.
--
Using the core18 image from http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/
Kernel snap: 4.15.0-39.42 (72)
rfkill shows there is an hci0 device:
$ rfkill list
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
But bluetoothctl does not detect any controller:
$ sudo bluetoothctl
08:58 Agent registered
08:58 [bluetooth]# list
[...no output...]
If you revert to the 4.4 kernel [4.4.0-1106.111 (76)] it works:
$ sudo bluetoothctl
[NEW] Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
Agent registered
[bluetooth]# list
Controller 00:00:00:00:5A:AD BlueZ 5.47 [default]
[bluetooth]# show
Controller 00:00:00:00:5A:AD
Name: BlueZ 5.47
Alias: BlueZ 5.47
Class: 0x00000000
Powered: no
Discoverable: no
Pairable: yes
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb)
UUID: Vendor specific (00005005-0000-1000-8000-0002ee000001)
UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)
UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb)
UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb)
Modalias: usb:v1D6Bp0246d052F
Discovering: no |
|
| 2019-01-16 15:46:33 |
Paolo Pisati |
attachment added |
|
0001-UBUNTU-SAUCE-btqcomsmd-introduce-BT_QCOMSMD_HACK.patch https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1810797/+attachment/5229695/+files/0001-UBUNTU-SAUCE-btqcomsmd-introduce-BT_QCOMSMD_HACK.patch |
|
| 2019-01-16 15:46:47 |
Paolo Pisati |
attachment added |
|
0002-UBUNTU-Config-arm64-snapdragon-BT_QCOMSMD_HACK-y.patch https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1810797/+attachment/5229696/+files/0002-UBUNTU-Config-arm64-snapdragon-BT_QCOMSMD_HACK-y.patch |
|
| 2019-01-16 17:05:42 |
Joseph Salisbury |
removed subscriber Joseph Salisbury |
|
|
|
| 2019-01-16 17:07:37 |
Joseph Salisbury |
bug |
|
|
added subscriber Joseph Salisbury |
| 2019-01-16 17:08:00 |
Joseph Salisbury |
removed subscriber Joseph Salisbury |
|
|
|
| 2019-01-16 17:09:11 |
Joseph Salisbury |
bug |
|
|
added subscriber Joseph Salisbury |
| 2019-01-17 15:03:43 |
Taihsiang Ho |
bug |
|
|
added subscriber Taihsiang Ho |
| 2019-01-21 14:31:44 |
Stefan Bader |
bug task added |
|
linux (Ubuntu Bionic) |
|
| 2019-01-21 14:31:44 |
Stefan Bader |
bug task added |
|
linux-snapdragon (Ubuntu Bionic) |
|
| 2019-01-21 14:31:56 |
Stefan Bader |
linux-snapdragon (Ubuntu Bionic): status |
New |
Invalid |
|
| 2019-01-21 14:32:03 |
Stefan Bader |
linux (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2019-01-22 19:42:56 |
Seth Forshee |
linux (Ubuntu): status |
Incomplete |
Fix Committed |
|
| 2019-01-28 01:04:37 |
Khaled El Mously |
linux (Ubuntu Bionic): status |
New |
Fix Committed |
|
| 2019-01-28 14:13:00 |
Stefan Bader |
nominated for series |
|
Ubuntu Cosmic |
|
| 2019-01-28 14:13:00 |
Stefan Bader |
bug task added |
|
linux (Ubuntu Cosmic) |
|
| 2019-01-28 14:13:00 |
Stefan Bader |
bug task added |
|
linux-snapdragon (Ubuntu Cosmic) |
|
| 2019-01-28 14:13:10 |
Stefan Bader |
linux (Ubuntu Cosmic): importance |
Undecided |
Medium |
|
| 2019-01-28 14:13:15 |
Stefan Bader |
linux (Ubuntu Cosmic): status |
New |
Fix Committed |
|
| 2019-01-28 14:13:52 |
Stefan Bader |
linux-snapdragon (Ubuntu Cosmic): status |
New |
Invalid |
|
| 2019-02-04 14:46:37 |
Launchpad Janitor |
linux (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2019-02-11 11:06:32 |
Brad Figg |
tags |
patch |
patch verification-needed-cosmic |
|
| 2019-02-15 14:42:51 |
Brad Figg |
tags |
patch verification-needed-cosmic |
patch verification-needed-bionic verification-needed-cosmic |
|
| 2019-02-19 15:46:23 |
Paul Larson |
tags |
patch verification-needed-bionic verification-needed-cosmic |
patch verification-done-bionic verification-needed-cosmic |
|
| 2019-03-05 15:00:44 |
Launchpad Janitor |
linux (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-03-05 15:00:44 |
Launchpad Janitor |
cve linked |
|
2018-18397 |
|
| 2019-03-05 15:00:44 |
Launchpad Janitor |
cve linked |
|
2018-19854 |
|
| 2019-03-05 15:00:44 |
Launchpad Janitor |
cve linked |
|
2019-6133 |
|
| 2019-03-06 10:49:37 |
Launchpad Janitor |
linux (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
| 2019-03-06 10:49:37 |
Launchpad Janitor |
cve linked |
|
2018-16880 |
|
| 2019-05-14 19:04:02 |
Launchpad Janitor |
linux-snapdragon (Ubuntu Bionic): status |
Invalid |
Fix Released |
|
| 2019-05-14 19:04:02 |
Launchpad Janitor |
cve linked |
|
2017-5715 |
|
| 2019-05-14 19:04:02 |
Launchpad Janitor |
cve linked |
|
2017-5753 |
|
| 2019-05-14 19:04:02 |
Launchpad Janitor |
cve linked |
|
2017-5754 |
|
| 2019-05-14 19:04:02 |
Launchpad Janitor |
cve linked |
|
2018-12126 |
|
| 2019-05-14 19:04:02 |
Launchpad Janitor |
cve linked |
|
2018-12127 |
|
| 2019-05-14 19:04:02 |
Launchpad Janitor |
cve linked |
|
2018-12130 |
|
| 2019-05-14 19:04:02 |
Launchpad Janitor |
cve linked |
|
2018-16884 |
|
| 2019-05-14 19:04:02 |
Launchpad Janitor |
cve linked |
|
2018-3620 |
|
| 2019-05-14 19:04:02 |
Launchpad Janitor |
cve linked |
|
2018-3639 |
|
| 2019-05-14 19:04:02 |
Launchpad Janitor |
cve linked |
|
2018-3646 |
|
| 2019-05-14 19:04:02 |
Launchpad Janitor |
cve linked |
|
2019-3874 |
|
| 2019-05-14 19:04:02 |
Launchpad Janitor |
cve linked |
|
2019-3882 |
|
| 2019-05-14 19:04:02 |
Launchpad Janitor |
cve linked |
|
2019-9500 |
|
| 2019-05-14 19:04:02 |
Launchpad Janitor |
cve linked |
|
2019-9503 |
|
| 2019-07-24 21:34:05 |
Brad Figg |
tags |
patch verification-done-bionic verification-needed-cosmic |
cscc patch verification-done-bionic verification-needed-cosmic |
|
