Roland Tollenaar wrote: > Hi > >>> There is definitely something between the two that is not right. >>> >> >> In 9 of 10 cases (if not more): timing. Running both alone doesn't >> expose some timing issue (race) or transient overload. I can't help with >> EML complaints, maybe the FMTC guys have an idea what can trigger this >> and how to debug it. > Out of interest, what timing exactly? These two systems (rtcan and eml) > run separately, they don;t need to access the same address space or > otherwise share resources that would require timing? What am I not > understanding?
The share the same CPU? Varying the load can re-order the execution order in otherwise independent components. > > >>>>>>> RTnet:rtskb allocation from real-time cache failed. >>> Could I get some tips as to what I can do about this? I seem to get >>> it even when I do not have rtcan activity running in my application >>> and (because I am clueless) I would like to prevent this message >>> which may signify the root of the problem. >> >> You have created the socket for some/all EML activity from primary mode >> of some Xenomai thread, > 100% correct. > > > thus network buffer allocation is ought to run >> against the real-time rtskb pool - which is by default empty :p. See >> README.pools from the RTnet documentation on this. > > >> I don't have the EML design at hand, but you might be able to avoid this >> by initialising before creating the shadow task or by explicitly > In fact this is what I tried initially. IT does not work at all. so I > ended up initializing in the thread. Problem? Not necessarily. But it would have been nice to report the other issue as well, because maybe there is something to be fixed (either in the code or in the docs). Initialisation almost always happens in non-RT context, and you shouldn't be force to do this under RT constraints. If this is an RTnet and/or EML problem, please report it on the related lists! > > Is this allocation possibly the cause of the problem or is the rtnet > warning harmless? At least it is not related to rtcan in any manner > because it appears even if rtcan is not activated in the application. Did you set the rtskb_cache_size module parameter for the rtnet.ko? Did you choose it appropriately large so that buffer pool do not exhaust if RTnet is blocked by other system activity? Again, check the documentation. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
