Re: Warning from drvlib.c:1349 rtdm_mutex_timedlock

[Per Oberg <pero@wolfram.com>]

----- Den 13 sep 2019, på kl 17:02, Jan Kiszka jan.kiszka@siemens.com skrev:

> On 13.09.19 16:58, Per Oberg via Xenomai wrote:
> > Dear all

>> I'm trying to figure out the significance and meaning of the following warning,
>> see [1] below . It's from when using the peak-linux-driver for their CAN
> > devices.

>> This warning happens every time my software opens or closes a rtdm/pcanx device.
>> I briefly touched upon this when talking to peak about other issues and got the
> > impression that they hadn't seen it themselves.

>> Everything is working just fine with full speed and real time performance so
>> there is no major problems that I can see. I use Yocto and thus have a quite
>> complicated build setup which can perhaps make things slip through, so I was
>> wondering if error in build flags could be the reason for this warning. The
>> code calls a library (pcanlib) which in turn makes the syscall, so I was
> > thinking that perhaps there be a problem with the linking of this library?

> > Any ideas?


> > [1]
> > ------------------------------------------------------------------------------------------------------------------------------------------------------
>> [357740.718504] WARNING: CPU: 1 PID: 1993 at
>> /usr/src/kernel/kernel/xenomai/rtdm/drvlib.c:1349
> > rtdm_mutex_timedlock+0x43/0x2f0
>> [357740.718505] Modules linked in: pcan(O) rtudp rtipv4 intel_powerclamp
>> intel_rapl i915 coretemp rt_igb e1000e rtnet video fan thermal_sys [last
> > unloaded: pcan]
>> [357740.718516] CPU: 1 PID: 1993 Comm: pcanfdtst Tainted: G W O
> > 4.9.90-xeno-cobolt #1
>> [357740.718517] Hardware name: Default string Default string/SKYBAY, BIOS
> > 5.0.1.1 04/18/2016
> > [357740.718518] I-pipe domain: Linux
>> [357740.718519] ffffc90005e0fd18 ffffffff81446e18 0000000000000000
> > 0000000000000000
>> [357740.718522] ffffffff81bb1370 ffffc90005e0fd58 ffffffff810785d1
> > 0000054505e0fdb0
>> [357740.718524] ffff880262a93000 ffff88024a342800 0000000000000002
> > ffff880262a93380
> > [357740.718527] Call Trace:
> > [357740.718530] [<ffffffff81446e18>] dump_stack+0xbf/0xe7
> > [357740.718533] [<ffffffff810785d1>] __warn+0xe1/0x100
> > [357740.718534] [<ffffffff810786bd>] warn_slowpath_null+0x1d/0x20
> > [357740.718536] [<ffffffff81170c43>] rtdm_mutex_timedlock+0x43/0x2f0
> > [357740.718538] [<ffffffff81170f02>] rtdm_mutex_lock+0x12/0x20
> > [357740.718542] [<ffffffffa06ab2ee>] pcan_open_nrt+0x6e/0x130 [pcan]

> You are taken a sleepy RT lock (mutex) over a non-RT context (open). That does
> not work.

> Either use a rtdm_lock_t or a different context.

So, definitely something in the driver-code then? 

I'm guessing that open is always non-rt and therefore a rtdm_lock should be used? (I remember seeing that in the peak-can code, but wrapped in ifdefs depending on build case....)

> Jan

> > [357740.718543] [<ffffffff8116c913>] __rtdm_dev_open+0x123/0x360
> > [357740.718545] [<ffffffff81205ce3>] ? getname_flags+0x53/0x190
> > [357740.718547] [<ffffffff81178c30>] ? get_timespec+0x70/0x70
> > [357740.718548] [<ffffffff81178c5a>] CoBaLt_open+0x2a/0x40
> > [357740.718550] [<ffffffff81188472>] ipipe_syscall_hook+0x112/0x350
> > [357740.718552] [<ffffffff810842cb>] ? recalc_sigpending+0x1b/0x50
> > [357740.718555] [<ffffffff8110acb8>] __ipipe_notify_syscall+0xc8/0x190
> > [357740.718556] [<ffffffff8110adaa>] ipipe_handle_syscall+0x2a/0xb0
> > [357740.718558] [<ffffffff81001c3d>] do_syscall_64+0x2d/0xf0
> > [357740.718561] [<ffffffff818dffbe>] entry_SYSCALL_64_after_swapgs+0x58/0xc6
> > [357740.718562] ---[ end trace 8c611fed369f2a4c ]---
> > ------------------------------------------------------------------------------------------------------------------------------------------------------


> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

Per Öberg