Bluetooth: hci0: Frame reassembly failed (-84)

[risa2000]

After the last system upgrade of Raspbian to:

pi@hass:~ $ uname -a
Linux hass 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l GNU/Linux

I am observing a problem with bluetooth, which, after some time, stops working. The kernel log shows repeating message

Bluetooth: hci0: Frame reassembly failed (-84)

or sometimes also a stack dump (I do not have one right now).

The RPi is 3B the dmesg log is here: dmesg.log

The HCI configuration is:

pi@hass:~ $ hciconfig -a
hci0:   Type: Primary  Bus: UART
        BD Address: B8:27:EB:A1:A8:DE  ACL MTU: 1021:8  SCO MTU: 64:1
        UP RUNNING
        RX bytes:1733551 acl:20475 sco:1 events:67235 errors:0
        TX bytes:387061 acl:5214 sco:0 commands:27972 errors:0
        Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH SNIFF
        Link mode: SLAVE ACCEPT
        Name: 'hass'
        Class: 0x000000
        Service Classes: Unspecified
        Device Class: Miscellaneous,
        HCI Version: 4.1 (0x7)  Revision: 0x168
        LMP Version: 4.1 (0x7)  Subversion: 0x2209
        Manufacturer: Broadcom Corporation (15)

Now my BT usage is a bit specific. The main role for this RPi is running homeassistant, which means (among others) having: USB flash stick (with f2fs for logging), Z-Wave USB stick for home automation, Zigbee USB stick for home automation, and also using built-in BT for tracking BT hygrothermo devices.

Apart from that, I also (ab)use the built-in BT for controlling Valve's lighthouses. Both the hygrothermo devices and the lighthouses use BTLE protocol. HT devices are read-out every 2 minutes, the lighthouses (when running) are talked to every 20 seconds.

When I do not run the lighthouses there is no communication with them and the error seems far less likely to happen. When I run a VR session, and run the lighthouse control, after some time, the BT becomes unresponsive, the errors are logged in the kernel log and the only resolution is a reboot.

Before the last system (and I assume also the firmware) upgrade, the system worked, in the exactly same configuration, fine, for several months.

[pelwell]

The 3B doesn't have the flow control signals hooked up to the BT modem - we were short of pins - so it is possible for characters to get lost under load (especially interrupt load). What sort of data rate is typical for your application? If the rate is low, you may find that reducing the baud rate by editing /usr/bin/btuart gets a more stable connection.

[risa2000]

@pelwell I believe I can go with lower rate, my use is light and also nothing happens if one packet is lost.

What however bothers me (and I am not sure it is actually evident from the message as I am not familiar with BT) is not the intermittent corruption of the data, but the fact that BT becomes completely unresponsive.

This is what started to happen (I believe) with the latest update. I had some missed comms before, but then, the comm recovered the next time the connection was retried and it never led to the state where I need to reboot the RPi to get BT working again.

[J-Luc16]

built-in BT for tracking BT hygrothermo devices.

Same sort of application (temp+hygro for a plant dryer), same issue since the last kernel update (may ?) on my PI3,

I have put an USB dongle and it works, but I am not happy with this solution, the integrated BTLE of PI3 was stable for months before, now it crashes within one day or 2.

[GorkaMM]

It stopped working for me too on my Raspberry Pi 3 after the update.

[codyc1515]

I am having this issue as well and it's just continuous of the following.

[98613.228402] Bluetooth: hci0: SCO packet for unknown connection handle 23967
[98659.629015] Bluetooth: hci0: Frame reassembly failed (-84)
[98659.629051] Bluetooth: hci0: hardware error 0xc5

My version is Linux hoobs 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l GNU/Linux.

[codyc1515]

This worked for me:

sudo rpi-update c50c65e52bad69e8fa7d6576d9e2399eade7faf6

[J-Luc16]

Cool, is this workaround a regression to the previous version of the firmware ?

[pelwell]

There may be a related issue - #1017. I've found a driver/hardware bug with a simple workaround which I'm prepared to merge if the real fix doesn't appear soon.

[pelwell]

A real fix has been found and pushed to rpi-4.19.y - see raspberrypi/linux@9bf5cd2

Hopefully a firmware with the fix will be released in the next few days.

[milou161185]

hi, i have the same problem and the fix "sudo rpi-update c50c65e52bad69e8fa7d6576d9e2399eade7faf6" don't worked for me. Is the new firmware corrected available? If no, is there any other workaround?

[bieniu]

@milou161185 I had to downgrade kernel to version 4.14.98 to fix this issue.

[pelwell]

I don't know where you got that commit hash, but it's wrong. Try sudo rpi-update 43fa687c, which at least includes the patch.