Bluetooth: hci0: Frame reassembly failed (-84) #1150
Comments
|
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. |
|
@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. |
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. |
|
It stopped working for me too on my Raspberry Pi 3 after the update. |
|
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 My version is Linux hoobs 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l GNU/Linux. |
|
This worked for me: sudo rpi-update c50c65e52bad69e8fa7d6576d9e2399eade7faf6 |
|
Cool, is this workaround a regression to the previous version of the firmware ? |
|
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. |
|
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. |
|
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? |
|
@milou161185 I had to downgrade kernel to version 4.14.98 to fix this issue. |
|
I don't know where you got that commit hash, but it's wrong. Try |
|
thanks @pelwell but i try "sudo rpi-update 43fa687c" and i have the same error in the log |
|
|
1 : Linux raspberrypi 4.19.58-v7+ #1245 SMP Fri Jul 12 17:25:51 BST 2019 armv7l GNU/Linux |
Please paste the output of dmesg after booting. |
|
5 : Pi model 3B dmesg : [ 0.000000] Booting Linux on physical CPU 0x0 |
|
When your Pi has a marginal power supply (or too much load) as yours seems to, all sorts of errors can happen that wouldn't normally. |
|
a screen is connected to the pi, I will try by unplugging it to see if the messages are disappearing |
|
the error " Under-voltage detected! " is gone but I still have error messages "Bluetooth: hci0: Frame reassembly failed (-84)" with no screen connected |
|
Going back to your answer to question 3, an error like the one you are seeing is unlikely on an idle system. Which Bluetooth devices are connected? |
|
I use the bluetooth of pi as antenna for jeedom, so there is 2 nut connected |
|
by stopping the service making the connection between the pi and jeedom, no error ... I will therefore get closer to the forum jeedom, thank you for your help! |
|
What is a "nut"? Do you mean the Nut Mini device tracker? How large and CPU intensive is Jeedom? Unlike the later Bluetooth Pis, Pi 3B doesn't have flow control signals to the Bluetooth modem which means it can lose data under load. One option is to follow the suggestion I gave earlier to reduce the baud rate to the modem - edit /usr/bin/btuart and change the 921600 to 460800 (or 230400, 115200 etc.). Unless you are streaming audio it shouldn't be too restricting. |
|
thanks, i try this |
|
same problem :( |
|
I don't think this is an acceptable solution, but to help me understand the problem please try with 115200 if you haven't already. |
|
I'm in a similar boat with my 3B, using it to poll an airthings waveplus. I just applied the downgrade to 115200, and will see if that fixes the issue. |
|
Pi 3B was the first BT-capable Pi, and the earlier revisions (<=1.2) lack the flow control signals needed for reliable UART communication. Lowering the baudrate increases the tolerance to scheduling delays, but there is still a chance that some data will be lost, leading to the reassembly error. |
|
Model: RaspberryPi 3 dmesg command output: |
|
Which revision of Pi 3 ( |
Thanks |
|
Unfortunately that's one of the pre-flow-control revisions. You can follow my earlier advice of editing /usr/bin/btuart (e.g. to: or even: in order to see if the problem persists. |
|
Nothing, it continues, in the case of 115200, I can't even pair the device. On Pi4, is this not the case? Thanks |
|
I've got the exact same issue but on Pi4. I'm using the official power supply and I don't see any voltage warnings. |
|
I have pi3b v1.2 with home assistant I noticed that the if i stop home assistant, restart device, and after a while start HA - there is no problem 🤔 |
|
Could you try add |
looks like it worked |
|
Cool. I'm on the brink of changing the way the RPi BT modems are initialised, asking the kernel to provide the firmware rather than getting hciattach to do it. There are so many different devices and usage modes that it will take a lot of testing (miniuart mode is the worst), but it should happen eventually. |
|
The effect is even greater than I expected. This temperature graph very clearly shows how more stable the BLE began to work. Yesterday, the temperature update intervals were uneven and reached more than an hour. After I lowered the baud rate from 921600 to 460800 and wrote P.S. only change speed don't work for me |
|
Are you running an early Pi 3B? Or have you switched to mini-UART mode ( |
Pi 3 B v1.2 on stock Raspbian Lite with latest rpi-update. but i manual make bluez from sources v 5.65. bluetooth service start with UART mode not changed |
|
Much as I'd like to think the |
|
most likely it is. |
|
@pelwell, I tested different boot options today (with and without the only way to fix the problem is to run HA (in docker) manually via ssh after the system has fully booted. my HA runs in docker compose and start with system startup |
I have good news. I am an electronic engineer, it could be the power supply with problems or the plug... Or the mother plug from the PI. It is not relevant if you use the original power supply! I had this problem (Pi3) and took all the phone and tablet chargers in the house... Surprise! With 3 of them the same BT errors...(-84) Two instead were OK after 24 hours but also only one cable was OK |
ghost
mentioned this issue
|
Aug 08 05:50:35 am62xx-evm BT_keyfob[453]: Sent character: F even I have the same issues but my program works fine this isn't stopping my program it is running will this cause me an issue in long-term use? |
I'm also curious if this might cause issues. |
|
I am also seeing this when I plug monitor to raspberry pi 3 b+ "Bluetooth: hci0: Frame reassembly failed (-84)" HA version: 2024.9.2, and I saw the yale lock connection lost. However, I have fully shutdown the device(i.e. detach power) and cold restarted and saw everything working correctly. |
and others
After the last system upgrade of Raspbian to:
I am observing a problem with bluetooth, which, after some time, stops working. The kernel log shows repeating message
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:
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
f2fsfor 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.
The text was updated successfully, but these errors were encountered: