Hi, On 07/12/2016 04:51 PM, Luiz Augusto von Dentz wrote: ... >> >> HOW TO REPRODUCE: >> >> It's simple, do some high payloads which makes lot tx/rcv traffic on both sides: >> >> Node A: >> >> ping6 $IP_NODEB%6lo0 -s 60000 >> >> Node B: >> >> ping6 ff02::1%6lo0 > > Im not sure I understand what you are trying to do with a packet of > 60Kb, the l2cap_chan can most likely only do 1280 bytes and even with 60Kb is just some incredible high value to produce on both sides tx/rx data. The other side will normally send some "defragmentation failure" icmp messages. This value is just to produce the high traffic, not practice payload. > fragmentation this will consume the credits quicker than we can > receive more so it will eventually starting buffering until it gets > stuck. Note that it is probably still receiving credits but we This is exactly what I like to do. Produce a lot of data to kill L3 layer, but this should not kill the L2 layer. Killing the L2 layer is what's happend here. If I do a lot of data on e.g. tcp traffic and the tcp connection will be closed -> that's fine for me but afterwards starting a new L3 connection should be still working. This is not the case here, I can kill L2 layer and nothing works anymore, because L2 running into deadlock. > probably have so much data buffered that all the credits are consumed > almost immediately after receiving, or you don't see -EAGAIN more than > once? > My example shows that we transmit some data on both nodes, that is important to check the l2cap_chan_send return type. When I do that above and running into the deadlock the IPv6 connection runs "NS" messages only, because it still can send on L3 layer but the L2 layer is killed -> I get -EAGAIN in l2cap_chan_send always on both nodes because tx_credits are on both nodes zero and will not be incremented again. So far I know these tx_credits will be incremented only if somebody sends something again, right? This will never be the case again and I am stucked in a deadlock which should not be there. to your question: "or you don't see -EAGAIN more than once" I see -EAGAIN always at calling l2cap_chan_send on both nodes. I think I can wait forever, after an year I still see "-EAGAIN" when calling l2cap_chan_send. Nevertheless, I will try to hit the deadlock (-EAGAIN) on both nodes so nobody transmits anything anymore. Then waiting six hours and look if still -EAGAIN is there on both nodes. I will report again here, after that time it should working again, but I don't believe that. - Alex -- 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
