drivers/bluetooth/btusb.c | 9 +++++++++ 1 file changed, 9 insertions(+)
Some Qualcomm Bluetooth controllers, e.g., QCNFA765 send debug packets
as ACL frames with header 0x2EDC. The kernel misinterprets these as
malformed ACL packets, causing repeated errors:
Bluetooth: hci0: ACL packet for unknown connection handle 3804
This can occur hundreds of times per minute, greatly cluttering logs.
On my computer, I am observing approximately 7 messages per second
when streaming audio to a speaker.
For Qualcomm controllers exchanging over UART, hci_qca.c already
filters out these debug packets. This patch is for controllers
not going through UART, but USB.
This patch filters these packets in btusb_recv_acl() before they reach
the HCI layer, redirecting them to hci_recv_diag().
Tested on: Thinkpad T14 gen2 (AMD) with QCNFA765, kernel 6.16.9
Signed-off-by: Pascal Giard <pascal.giard@etsmtl.ca>
---
drivers/bluetooth/btusb.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 5e9ebf0c5312..900400646315 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -68,6 +68,9 @@ static struct usb_driver btusb_driver;
#define BTUSB_ACTIONS_SEMI BIT(27)
#define BTUSB_BARROT BIT(28)
+/* Qualcomm firmware debug packets header */
+#define QCA_DEBUG_HEADER 0x2EDC
+
static const struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
{ USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
@@ -1229,6 +1232,12 @@ static int btusb_recv_intr(struct btusb_data *data, void *buffer, int count)
static int btusb_recv_acl(struct btusb_data *data, struct sk_buff *skb)
{
+ /* Drop QCA firmware debug packets sent as ACL frames */
+ if (skb->len >= 2) {
+ if (get_unaligned_le16(skb->data) == QCA_DEBUG_HEADER)
+ return hci_recv_diag(data->hdev, skb);
+ }
+
/* Only queue ACL packet if intr_interval is set as it means
* force_poll_sync has been enabled.
*/
--
2.51.0
Hi Pascal,
On Fri, Oct 3, 2025 at 4:59 PM Pascal Giard <evilynux@gmail.com> wrote:
>
> Some Qualcomm Bluetooth controllers, e.g., QCNFA765 send debug packets
> as ACL frames with header 0x2EDC. The kernel misinterprets these as
> malformed ACL packets, causing repeated errors:
>
> Bluetooth: hci0: ACL packet for unknown connection handle 3804
>
> This can occur hundreds of times per minute, greatly cluttering logs.
> On my computer, I am observing approximately 7 messages per second
> when streaming audio to a speaker.
>
> For Qualcomm controllers exchanging over UART, hci_qca.c already
> filters out these debug packets. This patch is for controllers
> not going through UART, but USB.
>
> This patch filters these packets in btusb_recv_acl() before they reach
> the HCI layer, redirecting them to hci_recv_diag().
>
> Tested on: Thinkpad T14 gen2 (AMD) with QCNFA765, kernel 6.16.9
>
> Signed-off-by: Pascal Giard <pascal.giard@etsmtl.ca>
> ---
> drivers/bluetooth/btusb.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 5e9ebf0c5312..900400646315 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -68,6 +68,9 @@ static struct usb_driver btusb_driver;
> #define BTUSB_ACTIONS_SEMI BIT(27)
> #define BTUSB_BARROT BIT(28)
>
> +/* Qualcomm firmware debug packets header */
> +#define QCA_DEBUG_HEADER 0x2EDC
> +
> static const struct usb_device_id btusb_table[] = {
> /* Generic Bluetooth USB device */
> { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
> @@ -1229,6 +1232,12 @@ static int btusb_recv_intr(struct btusb_data *data, void *buffer, int count)
>
> static int btusb_recv_acl(struct btusb_data *data, struct sk_buff *skb)
> {
> + /* Drop QCA firmware debug packets sent as ACL frames */
> + if (skb->len >= 2) {
> + if (get_unaligned_le16(skb->data) == QCA_DEBUG_HEADER)
> + return hci_recv_diag(data->hdev, skb);
> + }
Well it turns out that handle 0x2EDC is actually a valid handle, so we
can't just reclassify these packets just because Qualcomm thinks that
it could reserve it for its own, so this needs to be using
classify_pkt_type to reclassify the packets to the handle 0x2EDC to
HCI_DIAG_PKT for the models affected.
> /* Only queue ACL packet if intr_interval is set as it means
> * force_poll_sync has been enabled.
> */
> --
> 2.51.0
>
--
Luiz Augusto von Dentz
Dear Luiz,
Le lun. 6 oct. 2025, à 13 h 21, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> a écrit :
>
> Hi Pascal,
>
> On Fri, Oct 3, 2025 at 4:59 PM Pascal Giard <evilynux@gmail.com> wrote:
> >
> > Some Qualcomm Bluetooth controllers, e.g., QCNFA765 send debug packets
> > as ACL frames with header 0x2EDC. The kernel misinterprets these as
> > malformed ACL packets, causing repeated errors:
> >
> > Bluetooth: hci0: ACL packet for unknown connection handle 3804
> >
> > This can occur hundreds of times per minute, greatly cluttering logs.
> > On my computer, I am observing approximately 7 messages per second
> > when streaming audio to a speaker.
> >
> > For Qualcomm controllers exchanging over UART, hci_qca.c already
> > filters out these debug packets. This patch is for controllers
> > not going through UART, but USB.
> >
> > This patch filters these packets in btusb_recv_acl() before they reach
> > the HCI layer, redirecting them to hci_recv_diag().
> >
> > Tested on: Thinkpad T14 gen2 (AMD) with QCNFA765, kernel 6.16.9
> >
> > Signed-off-by: Pascal Giard <pascal.giard@etsmtl.ca>
> > ---
> > drivers/bluetooth/btusb.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > index 5e9ebf0c5312..900400646315 100644
> > --- a/drivers/bluetooth/btusb.c
> > +++ b/drivers/bluetooth/btusb.c
> > @@ -68,6 +68,9 @@ static struct usb_driver btusb_driver;
> > #define BTUSB_ACTIONS_SEMI BIT(27)
> > #define BTUSB_BARROT BIT(28)
> >
> > +/* Qualcomm firmware debug packets header */
> > +#define QCA_DEBUG_HEADER 0x2EDC
> > +
> > static const struct usb_device_id btusb_table[] = {
> > /* Generic Bluetooth USB device */
> > { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
> > @@ -1229,6 +1232,12 @@ static int btusb_recv_intr(struct btusb_data *data, void *buffer, int count)
> >
> > static int btusb_recv_acl(struct btusb_data *data, struct sk_buff *skb)
> > {
> > + /* Drop QCA firmware debug packets sent as ACL frames */
> > + if (skb->len >= 2) {
> > + if (get_unaligned_le16(skb->data) == QCA_DEBUG_HEADER)
> > + return hci_recv_diag(data->hdev, skb);
> > + }
>
> Well it turns out that handle 0x2EDC is actually a valid handle, so we
> can't just reclassify these packets just because Qualcomm thinks that
> it could reserve it for its own, so this needs to be using
> classify_pkt_type to reclassify the packets to the handle 0x2EDC to
> HCI_DIAG_PKT for the models affected.
Thank you for considering my patch. Based on your comment, I had a
look at how btintel.c uses classify_pkt_type, and I think I understand
what you are expecting of me.
Before I submit a new version, should I go very narrow (just the
VID:PID=0x0489:0xe0d0 I know for certain has the issue) or should I
lump in all modules with the WCN6855 chip? The latter seems somewhat
reasonable to me given how hci_qca.c does it (even broader).
Therefore, I'm thinking of reusing BTUSB_QCA_WCN6855.
Thanks,
-Pascal
--
Homepage (http://pascal.giard.info)
École de technologie supérieure (http://etsmtl.ca)
Hi Pascal,
On Tue, Oct 7, 2025 at 10:16 AM Pascal Giard <evilynux@gmail.com> wrote:
>
> Dear Luiz,
>
> Le lun. 6 oct. 2025, à 13 h 21, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> a écrit :
> >
> > Hi Pascal,
> >
> > On Fri, Oct 3, 2025 at 4:59 PM Pascal Giard <evilynux@gmail.com> wrote:
> > >
> > > Some Qualcomm Bluetooth controllers, e.g., QCNFA765 send debug packets
> > > as ACL frames with header 0x2EDC. The kernel misinterprets these as
> > > malformed ACL packets, causing repeated errors:
> > >
> > > Bluetooth: hci0: ACL packet for unknown connection handle 3804
> > >
> > > This can occur hundreds of times per minute, greatly cluttering logs.
> > > On my computer, I am observing approximately 7 messages per second
> > > when streaming audio to a speaker.
> > >
> > > For Qualcomm controllers exchanging over UART, hci_qca.c already
> > > filters out these debug packets. This patch is for controllers
> > > not going through UART, but USB.
> > >
> > > This patch filters these packets in btusb_recv_acl() before they reach
> > > the HCI layer, redirecting them to hci_recv_diag().
> > >
> > > Tested on: Thinkpad T14 gen2 (AMD) with QCNFA765, kernel 6.16.9
> > >
> > > Signed-off-by: Pascal Giard <pascal.giard@etsmtl.ca>
> > > ---
> > > drivers/bluetooth/btusb.c | 9 +++++++++
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > > index 5e9ebf0c5312..900400646315 100644
> > > --- a/drivers/bluetooth/btusb.c
> > > +++ b/drivers/bluetooth/btusb.c
> > > @@ -68,6 +68,9 @@ static struct usb_driver btusb_driver;
> > > #define BTUSB_ACTIONS_SEMI BIT(27)
> > > #define BTUSB_BARROT BIT(28)
> > >
> > > +/* Qualcomm firmware debug packets header */
> > > +#define QCA_DEBUG_HEADER 0x2EDC
> > > +
> > > static const struct usb_device_id btusb_table[] = {
> > > /* Generic Bluetooth USB device */
> > > { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
> > > @@ -1229,6 +1232,12 @@ static int btusb_recv_intr(struct btusb_data *data, void *buffer, int count)
> > >
> > > static int btusb_recv_acl(struct btusb_data *data, struct sk_buff *skb)
> > > {
> > > + /* Drop QCA firmware debug packets sent as ACL frames */
> > > + if (skb->len >= 2) {
> > > + if (get_unaligned_le16(skb->data) == QCA_DEBUG_HEADER)
> > > + return hci_recv_diag(data->hdev, skb);
> > > + }
> >
> > Well it turns out that handle 0x2EDC is actually a valid handle, so we
> > can't just reclassify these packets just because Qualcomm thinks that
> > it could reserve it for its own, so this needs to be using
> > classify_pkt_type to reclassify the packets to the handle 0x2EDC to
> > HCI_DIAG_PKT for the models affected.
>
> Thank you for considering my patch. Based on your comment, I had a
> look at how btintel.c uses classify_pkt_type, and I think I understand
> what you are expecting of me.
>
> Before I submit a new version, should I go very narrow (just the
> VID:PID=0x0489:0xe0d0 I know for certain has the issue) or should I
> lump in all modules with the WCN6855 chip? The latter seems somewhat
> reasonable to me given how hci_qca.c does it (even broader).
> Therefore, I'm thinking of reusing BTUSB_QCA_WCN6855.
I'm afraid you will need to figure it out, probably only qualcomm
folks can tell which chips use this logic, also is it always enabled
to send debug information or that requires a vendor command to enable
debug traces to be sent using that handle?
> Thanks,
>
> -Pascal
> --
> Homepage (http://pascal.giard.info)
> École de technologie supérieure (http://etsmtl.ca)
--
Luiz Augusto von Dentz
Hi Luiz,
Le mar. 7 oct. 2025, à 10 h 46, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> a écrit :
>
> Hi Pascal,
>
> On Tue, Oct 7, 2025 at 10:16 AM Pascal Giard <evilynux@gmail.com> wrote:
> >
> > Dear Luiz,
> >
> > Le lun. 6 oct. 2025, à 13 h 21, Luiz Augusto von Dentz
> > <luiz.dentz@gmail.com> a écrit :
> > >
> > > Hi Pascal,
> > >
> > > On Fri, Oct 3, 2025 at 4:59 PM Pascal Giard <evilynux@gmail.com> wrote:
> > > >
> > > > Some Qualcomm Bluetooth controllers, e.g., QCNFA765 send debug packets
> > > > as ACL frames with header 0x2EDC. The kernel misinterprets these as
> > > > malformed ACL packets, causing repeated errors:
> > > >
> > > > Bluetooth: hci0: ACL packet for unknown connection handle 3804
> > > >
> > > > This can occur hundreds of times per minute, greatly cluttering logs.
> > > > On my computer, I am observing approximately 7 messages per second
> > > > when streaming audio to a speaker.
> > > >
> > > > For Qualcomm controllers exchanging over UART, hci_qca.c already
> > > > filters out these debug packets. This patch is for controllers
> > > > not going through UART, but USB.
> > > >
> > > > This patch filters these packets in btusb_recv_acl() before they reach
> > > > the HCI layer, redirecting them to hci_recv_diag().
> > > >
> > > > Tested on: Thinkpad T14 gen2 (AMD) with QCNFA765, kernel 6.16.9
> > > >
> > > > Signed-off-by: Pascal Giard <pascal.giard@etsmtl.ca>
> > > > ---
> > > > drivers/bluetooth/btusb.c | 9 +++++++++
> > > > 1 file changed, 9 insertions(+)
> > > >
> > > > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > > > index 5e9ebf0c5312..900400646315 100644
> > > > --- a/drivers/bluetooth/btusb.c
> > > > +++ b/drivers/bluetooth/btusb.c
> > > > @@ -68,6 +68,9 @@ static struct usb_driver btusb_driver;
> > > > #define BTUSB_ACTIONS_SEMI BIT(27)
> > > > #define BTUSB_BARROT BIT(28)
> > > >
> > > > +/* Qualcomm firmware debug packets header */
> > > > +#define QCA_DEBUG_HEADER 0x2EDC
> > > > +
> > > > static const struct usb_device_id btusb_table[] = {
> > > > /* Generic Bluetooth USB device */
> > > > { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
> > > > @@ -1229,6 +1232,12 @@ static int btusb_recv_intr(struct btusb_data *data, void *buffer, int count)
> > > >
> > > > static int btusb_recv_acl(struct btusb_data *data, struct sk_buff *skb)
> > > > {
> > > > + /* Drop QCA firmware debug packets sent as ACL frames */
> > > > + if (skb->len >= 2) {
> > > > + if (get_unaligned_le16(skb->data) == QCA_DEBUG_HEADER)
> > > > + return hci_recv_diag(data->hdev, skb);
> > > > + }
> > >
> > > Well it turns out that handle 0x2EDC is actually a valid handle, so we
> > > can't just reclassify these packets just because Qualcomm thinks that
> > > it could reserve it for its own, so this needs to be using
> > > classify_pkt_type to reclassify the packets to the handle 0x2EDC to
> > > HCI_DIAG_PKT for the models affected.
> >
> > Thank you for considering my patch. Based on your comment, I had a
> > look at how btintel.c uses classify_pkt_type, and I think I understand
> > what you are expecting of me.
> >
> > Before I submit a new version, should I go very narrow (just the
> > VID:PID=0x0489:0xe0d0 I know for certain has the issue) or should I
> > lump in all modules with the WCN6855 chip? The latter seems somewhat
> > reasonable to me given how hci_qca.c does it (even broader).
> > Therefore, I'm thinking of reusing BTUSB_QCA_WCN6855.
>
> I'm afraid you will need to figure it out, probably only qualcomm
> folks can tell which chips use this logic, also is it always enabled
> to send debug information or that requires a vendor command to enable
> debug traces to be sent using that handle?
I went with lumping in all WCN6855 chips. I have not sent any command
to enable debug traces, so my understanding is that this is the
default behavior on at least some controllers.
I have sent a new version of the patch for your consideration, where I
have tried to follow the approach you suggested.
Thanks again!
-Pascal
© 2016 - 2026 Red Hat, Inc.