* Kernel Bluetooth Protocol Stack Problem @ 2019-10-08 8:34 hongyi mao 2019-10-08 8:41 ` Marcel Holtmann 0 siblings, 1 reply; 5+ messages in thread From: hongyi mao @ 2019-10-08 8:34 UTC (permalink / raw) To: linux-bluetooth Hi, Currently we have found a problem when using the kernel Bluetooth protocol stack. Bluetooth hardware: support BR/BLE USB Client Module Kernel version: 3.18.20 The problem: our host received the HCI_EV_CONN_REQUEST event, in this event call hci_conn_add () and create a struct hci_conn, then the host will send HCI_OP_ACCEPT_SYNC_CONN_REQ command in the event processing. However, according to the Bluetooth protocol core_v5.0 description, the host will then receive a Command Status event or Synchronous Connection Complete event or Connection Complete event for the link, which will include Connection_Handle and the link parameters if the setup is successful. However, the host did not receive these events for the link. Hdev->rx_work workqueue is still working to collect events. After a period of time, the host receives an HCI_EV_CHANNEL_SELECTED event, which is to operate the hci_conn->amp_mgr structure, but the host has not received any events containing any information in the structure, this structure has not been created, so the kernel appears oops Thanks and Best Regards! Hongyi Mao ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Kernel Bluetooth Protocol Stack Problem 2019-10-08 8:34 Kernel Bluetooth Protocol Stack Problem hongyi mao @ 2019-10-08 8:41 ` Marcel Holtmann [not found] ` <CACokStd_VLLP=dc+v=MZXpYF+Pw57f0Cma3-HSrXz5_PdiyRfw@mail.gmail.com> 0 siblings, 1 reply; 5+ messages in thread From: Marcel Holtmann @ 2019-10-08 8:41 UTC (permalink / raw) To: hongyi mao; +Cc: Bluez mailing list Hi Hongyi, > Currently we have found a problem when using the kernel Bluetooth > protocol stack. > > Bluetooth hardware: support BR/BLE USB Client Module > > Kernel version: 3.18.20 > > The problem: our host received the HCI_EV_CONN_REQUEST event, in this > event call hci_conn_add () and create a struct hci_conn, > then the host will send HCI_OP_ACCEPT_SYNC_CONN_REQ command in the > event processing. > However, according to the Bluetooth protocol core_v5.0 description, > the host will then receive a Command Status event or Synchronous > Connection Complete event or Connection Complete event for the link, > which will include Connection_Handle and the link parameters if the > setup is successful. > However, the host did not receive these events for the link. > Hdev->rx_work workqueue is still working to collect events. > After a period of time, the host receives an HCI_EV_CHANNEL_SELECTED > event, which is to operate the hci_conn->amp_mgr structure, > but the host has not received any events containing any information > in the structure, this structure has not been created, so the kernel > appears oops > > Thanks and Best Regards! please create a binary trace with btmon -w trace.log and I can have a look at it. However if your BR/EDR/LE controllers sends AMP controller events, something is wrong with your controller. Regards Marcel ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <CACokStd_VLLP=dc+v=MZXpYF+Pw57f0Cma3-HSrXz5_PdiyRfw@mail.gmail.com>]
* Re: Kernel Bluetooth Protocol Stack Problem [not found] ` <CACokStd_VLLP=dc+v=MZXpYF+Pw57f0Cma3-HSrXz5_PdiyRfw@mail.gmail.com> @ 2019-10-10 3:43 ` Marcel Holtmann 2019-10-10 8:27 ` hongyi mao 0 siblings, 1 reply; 5+ messages in thread From: Marcel Holtmann @ 2019-10-10 3:43 UTC (permalink / raw) To: hongyi mao; +Cc: Bluez mailing list Hi Hongyi, > My use scenario: the peripheral is a BLE thermometer and > hygrometer,and the data of the thermometer and hygrometer is stored in > the BLE Advertising packet. > the host sends the LE Set Scan Enable Command to the local controller, > and then the host receives the le_meta_event and parses the data in > the BLE Advertising packet. > > The problem occurred: the host side received other events besides > le_meta_event, such as HCI_EV_INQUIRY_COMPLETE event, > HCI_EV_CONN_REQUEST event, HCI_EV_CHANNEL_SELECTED event..., the > reason for receiving these events may be BR/EDR/LE controllers wrong > or other, this We are investigating. > > However, I think that when the host receives the HCI_EV_CONN_REQUEST > event according to the procedure described in kernel, > Hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb) > ->hci_conn_request_evt(struct hci_dev *hdev, struct sk_buff *skb) > ->conn = hci_conn_add(hdev, ev->link_type, &ev->bdaddr,HCI_ROLE_SLAVE); > ->hci_send_cmd(hdev, HCI_OP_ACCEPT_CONN_REQ, sizeof(cp), &cp); or > hci_send_cmd(hdev, HCI_OP_ACCEPT_SYNC_CONN_REQ, sizeof(cp),&cp); > The host should receive the HCI_EV_CONN_COMPLETE event or the > HCI_EV_SYNC_CONN_COMPLETE event, > but we did not receive it. Or the host receives the > HCI_EV_CONN_COMPLETE event or HCI_EV_SYNC_CONN_COMPLETE, but > ev->status != 0; > The result is that the data for conn->handle is not updated, conn->handle=0. > > Next, the host may receive other events, such as > HCI_EV_CHANNEL_SELECTED event, HCI_EV_PHY_LINK_COMPLETE event, > HCI_EV_PHY_LINK_COMPLETE event..., > but we did not receive an event that can update the struct hci_conn data. > For example, the host receives the HCI_EV_CHANNEL_SELECTED event next. > Hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb) > ->hci_chan_selected_evt(struct hci_dev *hdev, struct sk_buff > *skb);//but ev->phy_handle=0; > ->hcon = hci_conn_hash_lookup_handle(hdev, ev->phy_handle);//host will > find struct hci_conn because conn->handle=0 ev->phy_handle=0,hcon != > NULL > ->amp_read_loc_assoc_final_data(hdev, hcon); > ->set_bit(READ_LOC_AMP_ASSOC_FINAL, &mgr->state); //host did not > receive any other events to update the data in hcon, mgr = NULL > > This situation will lead to kernel oops > > This problem can also occur when the host receives other events. As > long as the event ev->phy_handle=0, the struct hci_conn is found, > and the uninitialized data in the struct hci_conn is manipulated in > the event, this problem will occur. > > Maybe this problem is a controller error, but I think the kernel stack > should take this usage scenario into consideration. > The attachment trace.log is the hci log we grab.The trace.log may not > have caught this situation, but this situation requires a long test to > appear. what kind of hardware is this? < HCI Command: Read Local Version Information (0x04|0x0001) plen 0 > HCI Event: Command Complete (0x0e) plen 12 Read Local Version Information (0x04|0x0001) ncmd 1 Status: Success (0x00) HCI version: Bluetooth 4.1 (0x07) - Revision 0 (0x0000) LMP version: Bluetooth 4.1 (0x07) - Subversion 602 (0x025a) Manufacturer: Qualcomm (29) < HCI Command: Read BD ADDR (0x04|0x0009) plen 0 > HCI Event: Command Complete (0x0e) plen 10 Read BD ADDR (0x04|0x0009) ncmd 1 Status: Success (0x00) Address: C8:02:8F:04:89:1B (Nova Electronics (Shanghai) Co., Ltd.) Is this some sort of new USB dongle from Qualcomm? The problem is not Channel Selected event. That is just a symptom. The problem is that the hardware is sending garbage or you uncovered a bug in the driver or the USB controller. > HCI Event: Unknown (0xaf) plen 168 aa b1 32 13 56 7b dd 4d 68 d2 ec 2b 0e b6 3e 2b ..2.V{.Mh..+..>+ 02 01 03 01 b8 63 5a d0 83 0c 1f 1e ff 06 00 01 .....cZ......... 09 20 02 3c 26 fe 29 8d b4 89 26 03 37 3d 5c 23 . .<&.)...&.7=\# 8e ba 27 b6 41 c3 d2 2d 9b 7f b5 3e 2b 02 01 03 ..'.A..-...>+... 01 7a f7 04 dd a4 20 1f 1e ff 06 00 01 09 20 00 .z.... ....... . 0e 5f f0 72 0f 3b ea 9b ae ba 77 fa 41 35 4d 7a ._.r.;....w.A5Mz 3f 7b 28 18 9a bb 39 b1 3e 29 02 01 03 01 fb 6e ?{(...9.>).....n 54 04 1f 39 1d 1c ff 06 00 01 09 21 0a 61 76 81 T..9.......!.av. ad 16 28 44 45 53 4b 54 4f 50 2d 4a 4a 38 36 35 ..(DESKTOP-JJ865 34 30 c1 3e 2b 02 01 03 01 79 03 3f 35 8e 01 1f 40.>+....y.?5... 1e ff 06 00 01 09 20 02 ...... . > HCI Event: Unknown (0x6b) plen 233 87 d9 8b 41 cf 02 af a8 aa b1 32 13 56 7b dd 4d ...A......2.V{.M 68 d2 ec 2b 0e b5 3e 2b 02 01 03 01 7a f7 04 dd h..+..>+....z... a4 20 1f 1e ff 06 00 01 09 20 00 0e 5f f0 72 0f . ....... .._.r. 3b ea 9b ae ba 77 fa 41 35 4d 7a 3f 7b 28 18 9a ;....w.A5Mz?{(.. bb 39 b2 3e 29 02 01 03 01 fb 6e 54 04 1f 39 1d .9.>).....nT..9. 1c ff 06 00 01 09 21 0a 61 76 81 ad 16 28 44 45 ......!.av...(DE 53 4b 54 4f 50 2d 4a 4a 38 36 35 34 30 c1 3e 2b SKTOP-JJ86540.>+ 02 01 03 01 a3 f8 96 8c 85 25 1f 1e ff 06 00 01 .........%...... 09 20 02 7f 31 9e b5 d1 76 45 f0 77 95 eb e7 5a . ..1...vE.w...Z 93 38 cc 88 20 5c 58 62 d2 af ab 3e 2b 02 01 03 .8.. \Xb...>+... 01 79 03 3f 35 8e 01 1f 1e ff 06 00 01 09 20 02 .y.?5......... . 6b e9 87 d9 8b 41 cf 02 af a8 aa b1 32 13 56 7b k....A......2.V{ dd 4d 68 d2 ec 2b 0e b6 3e 2b 02 01 03 01 7a f7 .Mh..+..>+....z. 04 dd a4 20 1f 1e ff 06 00 01 09 20 00 0e 5f f0 ... ....... .._. 72 0f 3b ea 9b ae ba 77 fa r.;....w. > HCI Event: Channel Selected (0x41) plen 53 invalid packet size 4d 7a 3f 7b 28 18 9a bb 39 b3 3e 2b 02 01 03 01 Mz?{(...9.>+.... 79 03 3f 35 8e 01 1f 1e ff 06 00 01 09 20 02 6b y.?5......... .k e9 87 d9 8b 41 cf 02 af a8 aa b1 32 13 56 7b dd ....A......2.V{. 4d 68 d2 ec 2b Mh..+ So maybe this is missing a firmware download that has bug fixes. You might need to examine the Windows driver. Regards Marcel ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Kernel Bluetooth Protocol Stack Problem 2019-10-10 3:43 ` Marcel Holtmann @ 2019-10-10 8:27 ` hongyi mao 2019-10-16 19:08 ` Marcel Holtmann 0 siblings, 1 reply; 5+ messages in thread From: hongyi mao @ 2019-10-10 8:27 UTC (permalink / raw) To: Marcel Holtmann; +Cc: Bluez mailing list Hi Marcel, Marcel Holtmann <marcel@holtmann.org> 于2019年10月10日周四 上午11:44写道： > > Hi Hongyi, > > > My use scenario: the peripheral is a BLE thermometer and > > hygrometer,and the data of the thermometer and hygrometer is stored in > > the BLE Advertising packet. > > the host sends the LE Set Scan Enable Command to the local controller, > > and then the host receives the le_meta_event and parses the data in > > the BLE Advertising packet. > > > > The problem occurred: the host side received other events besides > > le_meta_event, such as HCI_EV_INQUIRY_COMPLETE event, > > HCI_EV_CONN_REQUEST event, HCI_EV_CHANNEL_SELECTED event..., the > > reason for receiving these events may be BR/EDR/LE controllers wrong > > or other, this We are investigating. > > > > However, I think that when the host receives the HCI_EV_CONN_REQUEST > > event according to the procedure described in kernel, > > Hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb) > > ->hci_conn_request_evt(struct hci_dev *hdev, struct sk_buff *skb) > > ->conn = hci_conn_add(hdev, ev->link_type, &ev->bdaddr,HCI_ROLE_SLAVE); > > ->hci_send_cmd(hdev, HCI_OP_ACCEPT_CONN_REQ, sizeof(cp), &cp); or > > hci_send_cmd(hdev, HCI_OP_ACCEPT_SYNC_CONN_REQ, sizeof(cp),&cp); > > The host should receive the HCI_EV_CONN_COMPLETE event or the > > HCI_EV_SYNC_CONN_COMPLETE event, > > but we did not receive it. Or the host receives the > > HCI_EV_CONN_COMPLETE event or HCI_EV_SYNC_CONN_COMPLETE, but > > ev->status != 0; > > The result is that the data for conn->handle is not updated, conn->handle=0. > > > > Next, the host may receive other events, such as > > HCI_EV_CHANNEL_SELECTED event, HCI_EV_PHY_LINK_COMPLETE event, > > HCI_EV_PHY_LINK_COMPLETE event..., > > but we did not receive an event that can update the struct hci_conn data. > > For example, the host receives the HCI_EV_CHANNEL_SELECTED event next. > > Hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb) > > ->hci_chan_selected_evt(struct hci_dev *hdev, struct sk_buff > > *skb);//but ev->phy_handle=0; > > ->hcon = hci_conn_hash_lookup_handle(hdev, ev->phy_handle);//host will > > find struct hci_conn because conn->handle=0 ev->phy_handle=0,hcon != > > NULL > > ->amp_read_loc_assoc_final_data(hdev, hcon); > > ->set_bit(READ_LOC_AMP_ASSOC_FINAL, &mgr->state); //host did not > > receive any other events to update the data in hcon, mgr = NULL > > > > This situation will lead to kernel oops > > > > This problem can also occur when the host receives other events. As > > long as the event ev->phy_handle=0, the struct hci_conn is found, > > and the uninitialized data in the struct hci_conn is manipulated in > > the event, this problem will occur. > > > > Maybe this problem is a controller error, but I think the kernel stack > > should take this usage scenario into consideration. > > The attachment trace.log is the hci log we grab.The trace.log may not > > have caught this situation, but this situation requires a long test to > > appear. > > what kind of hardware is this? > > < HCI Command: Read Local Version Information (0x04|0x0001) plen 0 > > HCI Event: Command Complete (0x0e) plen 12 > Read Local Version Information (0x04|0x0001) ncmd 1 > Status: Success (0x00) > HCI version: Bluetooth 4.1 (0x07) - Revision 0 (0x0000) > LMP version: Bluetooth 4.1 (0x07) - Subversion 602 (0x025a) > Manufacturer: Qualcomm (29) > < HCI Command: Read BD ADDR (0x04|0x0009) plen 0 > > HCI Event: Command Complete (0x0e) plen 10 > Read BD ADDR (0x04|0x0009) ncmd 1 > Status: Success (0x00) > Address: C8:02:8F:04:89:1B (Nova Electronics (Shanghai) Co., Ltd.) > > Is this some sort of new USB dongle from Qualcomm? > > The problem is not Channel Selected event. That is just a symptom. The problem is that the hardware is sending garbage or you uncovered a bug in the driver or the USB controller. > > > HCI Event: Unknown (0xaf) plen 168 > aa b1 32 13 56 7b dd 4d 68 d2 ec 2b 0e b6 3e 2b ..2.V{.Mh..+..>+ > 02 01 03 01 b8 63 5a d0 83 0c 1f 1e ff 06 00 01 .....cZ......... > 09 20 02 3c 26 fe 29 8d b4 89 26 03 37 3d 5c 23 . .<&.)...&.7=\# > 8e ba 27 b6 41 c3 d2 2d 9b 7f b5 3e 2b 02 01 03 ..'.A..-...>+... > 01 7a f7 04 dd a4 20 1f 1e ff 06 00 01 09 20 00 .z.... ....... . > 0e 5f f0 72 0f 3b ea 9b ae ba 77 fa 41 35 4d 7a ._.r.;....w.A5Mz > 3f 7b 28 18 9a bb 39 b1 3e 29 02 01 03 01 fb 6e ?{(...9.>).....n > 54 04 1f 39 1d 1c ff 06 00 01 09 21 0a 61 76 81 T..9.......!.av. > ad 16 28 44 45 53 4b 54 4f 50 2d 4a 4a 38 36 35 ..(DESKTOP-JJ865 > 34 30 c1 3e 2b 02 01 03 01 79 03 3f 35 8e 01 1f 40.>+....y.?5... > 1e ff 06 00 01 09 20 02 ...... . > > HCI Event: Unknown (0x6b) plen 233 > 87 d9 8b 41 cf 02 af a8 aa b1 32 13 56 7b dd 4d ...A......2.V{.M > 68 d2 ec 2b 0e b5 3e 2b 02 01 03 01 7a f7 04 dd h..+..>+....z... > a4 20 1f 1e ff 06 00 01 09 20 00 0e 5f f0 72 0f . ....... .._.r. > 3b ea 9b ae ba 77 fa 41 35 4d 7a 3f 7b 28 18 9a ;....w.A5Mz?{(.. > bb 39 b2 3e 29 02 01 03 01 fb 6e 54 04 1f 39 1d .9.>).....nT..9. > 1c ff 06 00 01 09 21 0a 61 76 81 ad 16 28 44 45 ......!.av...(DE > 53 4b 54 4f 50 2d 4a 4a 38 36 35 34 30 c1 3e 2b SKTOP-JJ86540.>+ > 02 01 03 01 a3 f8 96 8c 85 25 1f 1e ff 06 00 01 .........%...... > 09 20 02 7f 31 9e b5 d1 76 45 f0 77 95 eb e7 5a . ..1...vE.w...Z > 93 38 cc 88 20 5c 58 62 d2 af ab 3e 2b 02 01 03 .8.. \Xb...>+... > 01 79 03 3f 35 8e 01 1f 1e ff 06 00 01 09 20 02 .y.?5......... . > 6b e9 87 d9 8b 41 cf 02 af a8 aa b1 32 13 56 7b k....A......2.V{ > dd 4d 68 d2 ec 2b 0e b6 3e 2b 02 01 03 01 7a f7 .Mh..+..>+....z. > 04 dd a4 20 1f 1e ff 06 00 01 09 20 00 0e 5f f0 ... ....... .._. > 72 0f 3b ea 9b ae ba 77 fa r.;....w. > > HCI Event: Channel Selected (0x41) plen 53 > invalid packet size > 4d 7a 3f 7b 28 18 9a bb 39 b3 3e 2b 02 01 03 01 Mz?{(...9.>+.... > 79 03 3f 35 8e 01 1f 1e ff 06 00 01 09 20 02 6b y.?5......... .k > e9 87 d9 8b 41 cf 02 af a8 aa b1 32 13 56 7b dd ....A......2.V{. > 4d 68 d2 ec 2b Mh..+ > > So maybe this is missing a firmware download that has bug fixes. You might need to examine the Windows driver. > > Regards > > Marcel > My bluetooth module with IDS is: ID 0cf3:e500 Qualcomm Corp.Qualcomm Atheros QCA9377-7 Yes, I admit that the problem is that the hardware is sending garbage or uncovered a bug in the driver or the USB controller. We are solving the problem of the hardware or driver or the USB controller. But I think that no matter harware error or a bug in the driver or the USB controller, our host receives garbage, it should not cause oops in the kernel, should we have a countermeasure? When this abnormality occurs, prevent the kernel Oops occurred. When the host receives the HCI_EV_CONN_REQUEST event, but the connection fails, conn->handle does not update conn->handle=0,struct conn is not free and hardware is still sending garbage. This situation may lead to kernel oops. Thanks and Best Regards! Hongyi Mao ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Kernel Bluetooth Protocol Stack Problem 2019-10-10 8:27 ` hongyi mao @ 2019-10-16 19:08 ` Marcel Holtmann 0 siblings, 0 replies; 5+ messages in thread From: Marcel Holtmann @ 2019-10-16 19:08 UTC (permalink / raw) To: hongyi mao; +Cc: Bluez mailing list Hi Hongyi, >>> My use scenario: the peripheral is a BLE thermometer and >>> hygrometer,and the data of the thermometer and hygrometer is stored in >>> the BLE Advertising packet. >>> the host sends the LE Set Scan Enable Command to the local controller, >>> and then the host receives the le_meta_event and parses the data in >>> the BLE Advertising packet. >>> >>> The problem occurred: the host side received other events besides >>> le_meta_event, such as HCI_EV_INQUIRY_COMPLETE event, >>> HCI_EV_CONN_REQUEST event, HCI_EV_CHANNEL_SELECTED event..., the >>> reason for receiving these events may be BR/EDR/LE controllers wrong >>> or other, this We are investigating. >>> >>> However, I think that when the host receives the HCI_EV_CONN_REQUEST >>> event according to the procedure described in kernel, >>> Hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb) >>> ->hci_conn_request_evt(struct hci_dev *hdev, struct sk_buff *skb) >>> ->conn = hci_conn_add(hdev, ev->link_type, &ev->bdaddr,HCI_ROLE_SLAVE); >>> ->hci_send_cmd(hdev, HCI_OP_ACCEPT_CONN_REQ, sizeof(cp), &cp); or >>> hci_send_cmd(hdev, HCI_OP_ACCEPT_SYNC_CONN_REQ, sizeof(cp),&cp); >>> The host should receive the HCI_EV_CONN_COMPLETE event or the >>> HCI_EV_SYNC_CONN_COMPLETE event, >>> but we did not receive it. Or the host receives the >>> HCI_EV_CONN_COMPLETE event or HCI_EV_SYNC_CONN_COMPLETE, but >>> ev->status != 0; >>> The result is that the data for conn->handle is not updated, conn->handle=0. >>> >>> Next, the host may receive other events, such as >>> HCI_EV_CHANNEL_SELECTED event, HCI_EV_PHY_LINK_COMPLETE event, >>> HCI_EV_PHY_LINK_COMPLETE event..., >>> but we did not receive an event that can update the struct hci_conn data. >>> For example, the host receives the HCI_EV_CHANNEL_SELECTED event next. >>> Hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb) >>> ->hci_chan_selected_evt(struct hci_dev *hdev, struct sk_buff >>> *skb);//but ev->phy_handle=0; >>> ->hcon = hci_conn_hash_lookup_handle(hdev, ev->phy_handle);//host will >>> find struct hci_conn because conn->handle=0 ev->phy_handle=0,hcon != >>> NULL >>> ->amp_read_loc_assoc_final_data(hdev, hcon); >>> ->set_bit(READ_LOC_AMP_ASSOC_FINAL, &mgr->state); //host did not >>> receive any other events to update the data in hcon, mgr = NULL >>> >>> This situation will lead to kernel oops >>> >>> This problem can also occur when the host receives other events. As >>> long as the event ev->phy_handle=0, the struct hci_conn is found, >>> and the uninitialized data in the struct hci_conn is manipulated in >>> the event, this problem will occur. >>> >>> Maybe this problem is a controller error, but I think the kernel stack >>> should take this usage scenario into consideration. >>> The attachment trace.log is the hci log we grab.The trace.log may not >>> have caught this situation, but this situation requires a long test to >>> appear. >> >> what kind of hardware is this? >> >> < HCI Command: Read Local Version Information (0x04|0x0001) plen 0 >>> HCI Event: Command Complete (0x0e) plen 12 >> Read Local Version Information (0x04|0x0001) ncmd 1 >> Status: Success (0x00) >> HCI version: Bluetooth 4.1 (0x07) - Revision 0 (0x0000) >> LMP version: Bluetooth 4.1 (0x07) - Subversion 602 (0x025a) >> Manufacturer: Qualcomm (29) >> < HCI Command: Read BD ADDR (0x04|0x0009) plen 0 >>> HCI Event: Command Complete (0x0e) plen 10 >> Read BD ADDR (0x04|0x0009) ncmd 1 >> Status: Success (0x00) >> Address: C8:02:8F:04:89:1B (Nova Electronics (Shanghai) Co., Ltd.) >> >> Is this some sort of new USB dongle from Qualcomm? >> >> The problem is not Channel Selected event. That is just a symptom. The problem is that the hardware is sending garbage or you uncovered a bug in the driver or the USB controller. >> >>> HCI Event: Unknown (0xaf) plen 168 >> aa b1 32 13 56 7b dd 4d 68 d2 ec 2b 0e b6 3e 2b ..2.V{.Mh..+..>+ >> 02 01 03 01 b8 63 5a d0 83 0c 1f 1e ff 06 00 01 .....cZ......... >> 09 20 02 3c 26 fe 29 8d b4 89 26 03 37 3d 5c 23 . .<&.)...&.7=\# >> 8e ba 27 b6 41 c3 d2 2d 9b 7f b5 3e 2b 02 01 03 ..'.A..-...>+... >> 01 7a f7 04 dd a4 20 1f 1e ff 06 00 01 09 20 00 .z.... ....... . >> 0e 5f f0 72 0f 3b ea 9b ae ba 77 fa 41 35 4d 7a ._.r.;....w.A5Mz >> 3f 7b 28 18 9a bb 39 b1 3e 29 02 01 03 01 fb 6e ?{(...9.>).....n >> 54 04 1f 39 1d 1c ff 06 00 01 09 21 0a 61 76 81 T..9.......!.av. >> ad 16 28 44 45 53 4b 54 4f 50 2d 4a 4a 38 36 35 ..(DESKTOP-JJ865 >> 34 30 c1 3e 2b 02 01 03 01 79 03 3f 35 8e 01 1f 40.>+....y.?5... >> 1e ff 06 00 01 09 20 02 ...... . >>> HCI Event: Unknown (0x6b) plen 233 >> 87 d9 8b 41 cf 02 af a8 aa b1 32 13 56 7b dd 4d ...A......2.V{.M >> 68 d2 ec 2b 0e b5 3e 2b 02 01 03 01 7a f7 04 dd h..+..>+....z... >> a4 20 1f 1e ff 06 00 01 09 20 00 0e 5f f0 72 0f . ....... .._.r. >> 3b ea 9b ae ba 77 fa 41 35 4d 7a 3f 7b 28 18 9a ;....w.A5Mz?{(.. >> bb 39 b2 3e 29 02 01 03 01 fb 6e 54 04 1f 39 1d .9.>).....nT..9. >> 1c ff 06 00 01 09 21 0a 61 76 81 ad 16 28 44 45 ......!.av...(DE >> 53 4b 54 4f 50 2d 4a 4a 38 36 35 34 30 c1 3e 2b SKTOP-JJ86540.>+ >> 02 01 03 01 a3 f8 96 8c 85 25 1f 1e ff 06 00 01 .........%...... >> 09 20 02 7f 31 9e b5 d1 76 45 f0 77 95 eb e7 5a . ..1...vE.w...Z >> 93 38 cc 88 20 5c 58 62 d2 af ab 3e 2b 02 01 03 .8.. \Xb...>+... >> 01 79 03 3f 35 8e 01 1f 1e ff 06 00 01 09 20 02 .y.?5......... . >> 6b e9 87 d9 8b 41 cf 02 af a8 aa b1 32 13 56 7b k....A......2.V{ >> dd 4d 68 d2 ec 2b 0e b6 3e 2b 02 01 03 01 7a f7 .Mh..+..>+....z. >> 04 dd a4 20 1f 1e ff 06 00 01 09 20 00 0e 5f f0 ... ....... .._. >> 72 0f 3b ea 9b ae ba 77 fa r.;....w. >>> HCI Event: Channel Selected (0x41) plen 53 >> invalid packet size >> 4d 7a 3f 7b 28 18 9a bb 39 b3 3e 2b 02 01 03 01 Mz?{(...9.>+.... >> 79 03 3f 35 8e 01 1f 1e ff 06 00 01 09 20 02 6b y.?5......... .k >> e9 87 d9 8b 41 cf 02 af a8 aa b1 32 13 56 7b dd ....A......2.V{. >> 4d 68 d2 ec 2b Mh..+ >> >> So maybe this is missing a firmware download that has bug fixes. You might need to examine the Windows driver. >> >> Regards >> >> Marcel >> > > My bluetooth module with IDS is: > ID 0cf3:e500 Qualcomm Corp.Qualcomm Atheros QCA9377-7 > > Yes, I admit that the problem is that the hardware is sending garbage > or uncovered a bug in the driver or the USB controller. > We are solving the problem of the hardware or driver or the USB controller. > > But I think that no matter harware error or a bug in the driver or the > USB controller, our host receives garbage, > it should not cause oops in the kernel, should we have a countermeasure? > When this abnormality occurs, prevent the kernel Oops occurred. > > When the host receives the HCI_EV_CONN_REQUEST event, but the connection fails, > conn->handle does not update conn->handle=0,struct conn is not free > and hardware is still sending garbage. > This situation may lead to kernel oops. you try to fix one symptom and still have to deal with all the other ones. Find a firmware for your hardware in the Windows driver or ask Qualcomm to fix this crappy device. It is plain and simple broken hardware. Regards Marcel ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-10-16 19:08 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-08 8:34 Kernel Bluetooth Protocol Stack Problem hongyi mao
2019-10-08 8:41 ` Marcel Holtmann
[not found] ` <CACokStd_VLLP=dc+v=MZXpYF+Pw57f0Cma3-HSrXz5_PdiyRfw@mail.gmail.com>
2019-10-10 3:43 ` Marcel Holtmann
2019-10-10 8:27 ` hongyi mao
2019-10-16 19:08 ` Marcel Holtmann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).