-
Notifications
You must be signed in to change notification settings - Fork 277
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
Multiple clients crashes bluetooth stack: Bluetooth: hci0: Opcode 0x200e failed: -16 #1500
Comments
If things are going wrong in the kernel, there isn't much we can do in Bleak. I would suggest logging Bluetooth traffic with |
Where do these rules come from?
Is this covered by always using In your code it is possible that the event loop runs |
I think I gathered these from various comments and examples throughout the project. Please correct me if any of those are wrong or not true.
Yes. As far as I understand my own code, Anyway, I have abandoned any attempts to parallelize my polling, as I'm already having a hard time to get this to work reliably in a strictly serial way, see issue #1507... |
What does Your snippet does the following.
It's possible for aux to be in the event loop more than once, that means that multiple tasks can be on |
I apologize, I minimized my code to share the example in this issue and accidentally took out too much code; the Like I said, I should have simplified this example even more, the problem also occurs without running the asyncio task from the Having said all this: I'm still sure any abuse or wrong API usage from userspace should result in the kernel/driver/firmware getting confused beyond repair, but that's another store. Thanks,, |
Can you modify your code snippet to be the minimal example that shows the problem? |
FYI, calling Polling with |
Right, I'll have to take care of that.
Sure, I'm aware of that - my example is just lousy. Shall I close this issue and reopen if/when I reproduce with a simpler and more compact program? |
Sounds good. So far, this sounds more like a hardware issue than a Bleak issue. |
Is it a problem if multiple tasks For example, event loop runs task1 which runs |
Yes, it seems that is a reliable way to trigger this problem. My example code was messy though, so if I find the time to get this running again I'll come up with a more simple snippet. Closed for now. |
Should that work though? Why doesn't it work? Because the backend can't handle multiple connection requests at the same time??? If that's the case can How do backends handle when multiple processes call connect at the same time? |
I'm not sure what causes the limitation, but the "two clients" examples jumps through hoops to make sure only one https://github.com/hbldh/bleak/blob/develop/examples/two_devices.py#L40-L41 |
It can be an OS limitation like BlueZ returning "operation already in progress" errors. Or it can be a hardware limitation like the issue here.
I would rather leave it up to the user in case they want a different behavior, like getting a busy error instead of just waiting a indefinite amount of time. If we changed it now, I think it would break a lot of people's code that depend on the current behavior.
They probably don't handle it well since it was never really designed to do that (since it often doesn't work at the OS level anyway). |
Thanks for explaining and sorry if I missed the documentation on this.
Is that what happens? Why not handle a busy error instead of using the lock in the two_devices.py example? |
The busy error is specific to the BlueZ backend. The lock works cross-platform - and avoids the error in the first place. |
It only avoids the error if another process doesn't use Bluetooth. |
There can be a new class with the new behaviour and when you use the new class you opt in to the new behaviour. |
python3-bleak
packageDescription
I have a simple python script that has the task to poll a large number of devices (50 to 100). I want to optimize the process by not serializing all connects + polls + disconnects, see below.
The result is that the bluetooth stack on my rpi crashes. Clients are no longer disconnecting and scanning never terminates.
kernel logs show:
Not able to power off/on as well:
Also tested with an external USB bluetooth dongle, same results.
What I Did
, the procedure I have now is:
This works pretty much ok but is rather slow as there is only one active client connection at a time.
I understand that doing multiple connects in parallel is no recommended (yes I have looked at the two-devices example), but having multiple connections established should be fine. This is what I changed my code to now, effectively this serializes the
connect()s
, but allows the polling and disconnect to run async:As far as I know, this should abide to all the rules:
I also tried to postpone the scanning until all the active clients have disconnecetd, but to no avail.
Minimal workable example is not easy since there is a large number of specific devices involved.
Logs
BLEAK_LOGGING=1
log attached (sorry for the newlines, this was copy/pasted from a scrollback buffer)debug-log.txt
Code
Below is the code as I run it now, albeit stripped a bit from error handling and the protocol details that are not relevant:
The text was updated successfully, but these errors were encountered: