Project

General

Profile

Actions

Bug #162

closed

"INFO: possible recursive locking detected"

Added by Linus Lüssing over 11 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
Start date:
08/04/2012
Due date:
% Done:

0%

Estimated time:

Description

Using a 3.4.0 kernel (Linux mesh-node1 3.4.0 #1 SMP PREEMPT Thu Jul 19 20:17:49 BST 2012 i686 GNU/Linux) in kvm with a few debug options and two nodes A and B connected via a single interface results in the attached traces as soon as A tries to ping B. After a 750ms lag the ICMP packets travel through fine though.
Tried batman-adv v2011.3.0, v2012.0.0 and master 3fdeaa6bfb404311b73a689e984672161403a0c2, all with the same issue (the attached traces are from the master branch).


Files

node-A-calltrace (4.38 KB) node-A-calltrace Anonymous, 08/04/2012 03:44 PM
node-B-calltrace (4.29 KB) node-B-calltrace Anonymous, 08/04/2012 03:44 PM
lock.log (4.96 KB) lock.log Antonio Quartulli, 08/27/2012 09:28 AM
Actions #2

Updated by Linus Lüssing over 11 years ago

Simon Wunderlich wrote:

https://patchwork.open-mesh.org/project/b.a.t.m.a.n./patch/1345361393-8759-1-git-send-email-sven@narfation.org/

This patch should fix the problem. Can you confirm?

Confirmed. Works like a charm.

Actions #3

Updated by Antonio Quartulli over 11 years ago

Hello, I'm sorry but I hit this stack trace again while testing latest master...

My setup is made up by 4 VMs interconnected like a chain (node1<->node2<->node3<->node4).
I get the stack trace when I ping node 1 from a client bridged in node 2.

By the way this is strange because I remember that the bug went away while testing Simon's patch. Maybe something added later has recreated the problem? I'll try to bisect.

Actions #4

Updated by Linus Lüssing over 11 years ago

Hm, just noticed that with v2012.4.0 I'm having these messages again. Were those patches (commit:b8f86c91faeb816168ecbdac0a355f316781ba77, commit:e27bb6fa916451e9eaced16e7c21d5b71a3b7f30) accidentally forgotten to be included in v2012.4.0 or were they kept back on purpose due to this issue still being reproducable in certain scenarios even with these patches?

Actions #5

Updated by Anonymous over 11 years ago

These patches are non-critical and therefore were applied on top of master. As result, these patches were now sent to David and will be part of the 2012.5.0 release.

Actions #6

Updated by Antonio Quartulli over 11 years ago

  • Status changed from New to Resolved
Actions #7

Updated by Antonio Quartulli over 10 years ago

  • Status changed from Resolved to Closed
Actions #8

Updated by Sven Eckelmann about 7 years ago

  • Target version set to 2013.0.0
Actions

Also available in: Atom PDF