On 2012-10-16 15:43, Michał Geszkiewicz wrote: > W dniu 16.10.2012 12:50, Jan Kiszka pisze: >> On 2012-10-16 12:05, Michał Geszkiewicz wrote: >>> W dniu 16.10.2012 11:30, Jan Kiszka pisze: >>>> On 2012-10-16 10:40, Michał Geszkiewicz wrote: >>>>> Hello >>>>> >>>>> I'm adding rtnet support to linuxcnc. (kernel 2.6.38.8, rtai 3.9, >>>>> rtnet >>>>> 0.9.13, linuxcnc 2.6.0) >>>>> rtnet is inited in init_module section (open, set timeout, connect) >>>>> and >>>>> rest of transmition is done in rt task. >>>>> It's basically working but I can't get rid of one assertion: >>>>> >>>>> RTDM: assertion failed at >>>>> /home/toudi/realtime/rtai-3.9/addons/rtdm/../rtdm/rtdm_driver.h:574 >>>>> (CONTEXT_IS_LOCKED(context)) >>>>> >>>>> what I'm doing wrong? >>>> Hard to tell without a more precise trace of what is going on in your >>>> system. However, that assertion is not triggered by RTnet code but some >>>> other RTDM driver or some local patches of yours (there is no >>>> rtdm_context_lock in RTnet). >>>> >>>> Jan >>>> >>> There are no modifications in rtai or rtnet source code. This assertion >>> shows only after rt_dev_send/recv functions regardless of context >>> managing or not and if it's called from kernel context or rt context. >>> Linuxcnc is using single 1ms period rt task, and there is no context >>> managing in linuxcnc rt layer, so maybe this makes these assertions >>> along with rtnet layer. >> Please provide a stack backtrace to the assertion (e.g. >> show_stack(NULL,NULL)). Maybe linuxcnc calls that RTDM service from >> somewhere (grep'ing for it may also be a good idea). >> >> And please do not drop the mailing list from CC. >> >> Jan >> >> > (sorry for empty CC, I've missed it) > > rtai_rtdm was disabled in rtai used by linuxcnc,
RTAI's RTDM layer is obviously NOT disabled, see below. > so I'm sure only my > code is using it. > Show_stack just after ASSERT line > > > [ 108.602727] RTDM: assertion failed at > /home/toudi/realtime/rtai-3.9/addons/rtdm/../rtdm/rtdm_driver.h:574 > (CONTEXT_IS_LOCKED(context)) > [ 108.602731] f09a1e3c f0920c00 00000000 f09a1eb0 f09a1e58 c0105f3b > c06b6095 f09a1e90 > [ 108.602737] f95414d2 f9548e04 f9548e30 0000023e f9548b68 cf3c5aa8 > 00000000 00000200 > [ 108.602743] f0920c00 00000200 00000007 00000001 f83c2a18 f09a1ef4 > f83c21b0 00000000 > [ 108.602748] Call Trace: > [ 108.602757] [<c0105f3b>] ? show_stack+0x1b/0x20 > [ 108.602764] [<f95414d2>] ? __rt_dev_ioctl+0xf2/0x270 [rtai_rtdm] > [ 108.602769] [<f83c21b0>] ? init_module+0x109/0x38c [hm2_eth] > [ 108.602775] [<c01a0d6d>] ? ftrace_process_locs+0x15d/0x260 > [ 108.602778] [<c019d824>] ? tracepoint_module_notify+0x24/0x30 > [ 108.602783] [<c0594633>] ? notifier_call_chain+0x43/0x60 > [ 108.602786] [<c0101045>] ? do_one_initcall+0x35/0x180 > [ 108.602789] [<f83c20a7>] ? init_module+0x0/0x38c [hm2_eth] > [ 108.602793] [<c0179d76>] ? sys_init_module+0x116/0x1010 > [ 108.602805] [<c0102fa8>] ? sysenter_do_call+0x12/0x16 No RTnet in the traces. Unless it's nothing you wrote, I think you should ask at RTAI and/or linuxcnc for assistance. No clue what they do, but something is likely fairly broken there. Writing kernel based applications is, well, hairy anyway. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
