Hi Tim, > Yes, confirmed with gatttool. I used 3 terminals with one running btmon and the other 2 gatttool. I started btmon then ran gatttool on one terminal starting the notifications. Then I started another gatttool in another terminal and that new one then showed the results of both devices while the first gatttool stopped displaying any new notifications. You can see in the btmon that the values are coming from 2 different connection handles but the results are all coming through the 2nd gatttool. Here's the outputs using 3 terminals connected to the device (first listing was connected first): > > So it's perfectly clear: This all works fine on an x86 machine, but is an issue on ARM you must be hitting some non obvious race condition. My first guess is that we have some sort of unaligned access somewhere that ends up that we put the data into the wrong L2CAP channel. Can you have a look at Documentation/dynamic-debug-howto.txt and enable the debug section for the bluetooth.ko kernel module. I wonder if we see something fishy in there. In the end we have to trace the whole flow of the packets and figure out at which point this ended up being send to the wrong channel. Do you have the chance to run bluetooth-next tree for testing purposes? I rather debug this against the latest tree. I have no ARM platform lying around. So you have to be my test subject ;) Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
