* Warning from drvlib.c:1349 rtdm_mutex_timedlock @ 2019-09-13 14:58 Per Oberg 2019-09-13 15:02 ` Jan Kiszka 0 siblings, 1 reply; 5+ messages in thread From: Per Oberg @ 2019-09-13 14:58 UTC (permalink / raw) To: xenomai 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] [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 ]--- ------------------------------------------------------------------------------------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Warning from drvlib.c:1349 rtdm_mutex_timedlock 2019-09-13 14:58 Warning from drvlib.c:1349 rtdm_mutex_timedlock Per Oberg @ 2019-09-13 15:02 ` Jan Kiszka 2019-09-13 15:54 ` Per Oberg 0 siblings, 1 reply; 5+ messages in thread From: Jan Kiszka @ 2019-09-13 15:02 UTC (permalink / raw) To: Per Oberg, xenomai 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. 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Warning from drvlib.c:1349 rtdm_mutex_timedlock 2019-09-13 15:02 ` Jan Kiszka @ 2019-09-13 15:54 ` Per Oberg 2019-09-13 16:00 ` Jan Kiszka 0 siblings, 1 reply; 5+ messages in thread From: Per Oberg @ 2019-09-13 15:54 UTC (permalink / raw) To: Jan Kiszka; +Cc: xenomai ----- 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Warning from drvlib.c:1349 rtdm_mutex_timedlock 2019-09-13 15:54 ` Per Oberg @ 2019-09-13 16:00 ` Jan Kiszka 2019-09-13 17:49 ` Per Oberg 0 siblings, 1 reply; 5+ messages in thread From: Jan Kiszka @ 2019-09-13 16:00 UTC (permalink / raw) To: Per Oberg; +Cc: xenomai On 13.09.19 17:54, Per Oberg wrote: > > ----- 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? Yes, the driver is broken. > > 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....) This depends. If the open code needs to synchronize only with other non-RT paths, normal Linux locks are fine. If there is the need to sync with the interrupt handler or some of the _rt callbacks, rtdm_lock & Co. is needed. Do you need anything special from that driver, or would the standard CAN drivers with socket model that we have also for (some) Peak hardware work? From QA perspective, upstream is usually better than vendor drivers. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Warning from drvlib.c:1349 rtdm_mutex_timedlock 2019-09-13 16:00 ` Jan Kiszka @ 2019-09-13 17:49 ` Per Oberg 0 siblings, 0 replies; 5+ messages in thread From: Per Oberg @ 2019-09-13 17:49 UTC (permalink / raw) To: Jan Kiszka; +Cc: xenomai Please visit us at: [ http://www.wolframmathcore.com/ | wolframmathcore.com ] or [ http://www.wolfram.com/ | wolfram.com ] ----- Den 13 sep 2019, på kl 18:00, Jan Kiszka jan.kiszka@siemens.com skrev: > On 13.09.19 17:54, Per Oberg wrote: > > ----- 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? > Yes, the driver is broken. >> 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....) > This depends. If the open code needs to synchronize only with other non-RT > paths, normal Linux locks are fine. If there is the need to sync with the > interrupt handler or some of the _rt callbacks, rtdm_lock & Co. is needed. > Do you need anything special from that driver, or would the standard CAN drivers > with socket model that we have also for (some) Peak hardware work? From QA > perspective, upstream is usually better than vendor drivers. We used to use the xenomai socket driver but had to switch because our preferred hardware was upgraded. The old hardware was SJA1000 compatible but it was replaced by a custom implementation when they switched to CAN fd (my loose interpretation, not theirs). Other than that I like that * For netdev version there is a way to sync netdev id with hardware ids. Very useful, although not RT compatible * The chardev interface passes on some info not available through the netdev interface > Jan > -- > Siemens AG, Corporate Technology, CT RDA IOT SES-DE > Corporate Competence Center Embedded Linux Per Öberg ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-09-13 17:49 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-09-13 14:58 Warning from drvlib.c:1349 rtdm_mutex_timedlock Per Oberg 2019-09-13 15:02 ` Jan Kiszka 2019-09-13 15:54 ` Per Oberg 2019-09-13 16:00 ` Jan Kiszka 2019-09-13 17:49 ` Per Oberg
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.