Hi Dave, >>> Here's the info I found in the logs, it looks like this was the only bluetooth socket. >>> >>> fd[195] = domain:31 (PF_BLUETOOTH) type:0x5 protocol:2 >>> Setsockopt(1 d 2134000 8) on fd 195 >> >> this is a bit confusing. Protocol 2 is actually SCO, but the stack trace shows RFCOMM. > > Sorry, mixed up two separate runs. In the log above, the stack trace is actually.. > > [<ffffffffa0492dca>] bt_sock_wait_state+0xda/0x240 [bluetooth] > [<ffffffffa04c86d8>] sco_sock_release+0xb8/0xf0 [bluetooth] > [<ffffffff815cb1ff>] sock_release+0x1f/0x90 > [<ffffffff815cb282>] sock_close+0x12/0x20 > > >>> ./trinity -P PF_BLUETOOTH -l off -c setsockopt >>> >>> let it run a few seconds, and then ctrl-c. The main process will never exit. >>> >>> 5814 pts/6 Ss 0:00 | \_ bash >>> 5876 pts/6 S+ 0:00 | | \_ ./trinity -P PF_BLUETOOTH -l off -c setsockopt >>> 5877 pts/6 Z+ 0:00 | | \_ [trinity] <defunct> >>> 5878 pts/6 S+ 0:01 | | \_ [trinity-main] >>> >>> $ sudo cat /proc/5878/stack >>> [<ffffffffa04397a2>] bt_sock_wait_state+0xc2/0x190 [bluetooth] >>> [<ffffffffa0847a75>] rfcomm_sock_shutdown+0x85/0xb0 [rfcomm] >>> [<ffffffffa0847ad9>] rfcomm_sock_release+0x39/0xb0 [rfcomm] > > So it seems it affects both SCO and RFCOMM. > >> What kernel did you run this against? It is a shot in the dark, but can you try linux-next quickly. >> There was a socket related fix for the socket options where we confused RFCOMM vs L2CAP struct sock. > > first noticed it on Linus' latest HEAD, and then reproduced it on 3.11.6 > I'll look at linux-next tomorrow. I looked through the code and only call bt_sock_wait_state when SOCK_LINGER and sk_lingertime is set. In that case we actually block until the socket state changes to BT_CLOSED. The only way I see this could happen is if you have a huge linger timeout and confused the socket state before. What is actually the list of system calls that you are throwing at this socket. 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
