[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4744AD8B.2000908@ccr.jussieu.fr>
Date: Wed, 21 Nov 2007 23:13:31 +0100
From: Bernard Pidoux <pidoux@....jussieu.fr>
To: Alexey Dobriyan <adobriyan@...il.com>, ralf@...ux-mips.org
CC: davem@...emloft.net, netdev@...r.kernel.org
Subject: Inconsistent lock state and possible irq lock inversion dependency
detected in ax25.ko
Hi,
I am practicing intensively AX25 packet radio that uses ax25.ko together
with mkiss, crc16, netrom, and rose modules using two PIII CPU Linux
machines with 2.6.23.8 kernel.
On the first Linux machine I did not validate kernel hacking and AX25
applications are running 100% of the time without serious problems.
On the second machine I validated kernel hacking and sooner or later I
get exactly the same message after a connect timeout expires :
[ INFO: inconsistent lock state ]
The error seems to reside around ax25_disconnect+0x46/0xaf [ax25] that
is called when an AX25 connect timeout or a connection failure occurs.
Connect timeout is probably activating
ax25_std_heartbeat_expiry+0x19/0xd3 [ax25]
The message is only displayed once on a boot session.
Ralf Baechle explained to me that ax25 code is very buggy and spinlocks
difficult to trace.
However, as the cause of error is clearlHowever, as the cause of error
is clearly identified and the y identified and the reported address is
constant I suspect that an experienced programmer (which I am not) could
trace the problem.
Moreover, I had the opportunity to catch a different message, that was
longer than usual, and seem more explicit :
[ INFO: possible irq lock inversion dependency detected ]
Although the symptom is different it is related to the same origin :
fpac/4933 just changed the state of lock:
(slock-AF_AX25){--..}, at: [<d8be3312>] ax25_disconnect+0x46/0xaf [ax25]
Whatever the running application is the inconsistent lock state could be
observed with ax25_call, flexd, fpac ax25 application programms.
Please find attached a few reports captured from dmesg after each event.
Could someone look at the listing and identify the origin of the problem
,if unique ?
Thanks.
Bernard Pidoux
View attachment "inconsistent_locks_report" of type "text/plain" (21621 bytes)
Powered by blists - more mailing lists