-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Bluetooth: Host: Add missing bt_tx_irq_raise()
#77054
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bluetooth: Host: Add missing bt_tx_irq_raise()
#77054
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
|
@jori-nordic does this need backporting to 3.7.1? |
The regression was introduced during the 3.7 stabilization I'd say it does. |
|
@jori-nordic this needs a rebase now |
6a06331
710b0ca to
6a06331
Compare
|
What's the babblesim CI test failure? |
|
alwa changed the hierarchy of compile.sh. I'll move it in 2sec. |
Verifies that we don't leak connection references when the peer goes out of range whilst we are fragmenting and sending data to the controller. Signed-off-by: Jonathan Rico <[email protected]>
Trigger the TX processor on connection teardown. When a disconnection happens before the controller has acknowledged some ACL fragments the host has sent, we run `process_unack_tx()` to free those unacknowledged buffers and their associated TX contexts. The problem is that the TX processor still holds a reference to the conn object. That reference is not released until the TX processor is triggered again and figures out that the connection is invalid. Signed-off-by: Jonathan Rico <[email protected]>
6a06331 to
4a1dc14
Compare
| Execute "${test_exe}" -v=${verbosity_level} -s=${simulation_id} -d=0 -rs=420 -testid=dut \ | ||
| -argstest log_level 3 | ||
| Execute "${test_exe}" -v=${verbosity_level} -s=${simulation_id} -d=1 -rs=69 -testid=peer \ | ||
| -argstest log_level 3 >/dev/null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
>/dev/null
was this left due to an oversight? (note you should be able to set the verbosity to 0 and get nothing but warnings out of a device)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oversight at first, but then realized logs from the other device are not useful. So I left it there.
I'll use the -v switch next time, sorry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nothing to be sorry about
Fixes #76951