On Wed, Nov 13, 2013 at 07:32:09AM +0900, Marcel Holtmann wrote: > > 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. thanks, Dave -- 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
