Hi Jan,
[EMAIL PROTECTED] wrote: > Maybe that bug is a symptom of some other scalability issue. I suppose so, too. >> +++ >> bash-2.05b# cat /proc/heap >> size=131072:used=134400:pagesz=512 >> +++ >> >> This looks odd. Either the output is misleading or we have used more >> resources than possible. But then I would expect that the Xenomai >> initialization routines (e.g. pthread_create(), rt_dev_open(), etc.) >> should return with an error. Either should be fixed, I suppose. > > Every services that allocates memory from the real-time heap should > fail now. If it doesn't (pthread_create is a good test candidate > here), we "only" face a statistics bug. Can you confirm that starting > further applications only increases the used counter but otherwise > works? I was running the cyclictest and the switchbench without problems at the same time and the /proc/xenomai/heap showed even a usage of 135 kBytes. So I assume that is a statistics bug. >> I configured Xenomai in the Kernel with the following values, but >> please bear in mind that was after I thought about a resource >> shortage: >> >> CONFIG_XENO_OPT_PIPE_NRDEV=320 > > This looks exceptional. Do you really use pipes that heavily? We do not use pipes at all. Just shooting around in the forest .... Which pipes are meant here actually ? Native Pipes ? Which effect does this option have if I did not compile in support for Pipes of the native API ? Again: a comprehensive description of these options would probably help. Is it possible to get these inside 2.4 Kernel as well ? >> CONFIG_XENO_OPT_REGISTRY_NRSLOTS=2560 > > Do you every have so many registered objects active in parallel? > Should be no problem, but I wonder if it is needed. Well per default it is set to 256. We are using more IPC objects. So I increased it by 10 times to be on the safe side. I do not know what actually can occupy a "registry slot". Explanation ? >> - I realized that when setting CONFIG_XENO_DRIVERS_RTCAN_RXBUF_SIZE >> to 131072, my application does not run. Which are the upper limits I >> can >> set for all the configurable Xenomai parameters ? > > That buffer is part of each CAN socket instance which is allocated > via kmalloc - hence the 132K limit here. But you shouldn't normally > need such large intermediate buffers when no CAN receiver gets > delayed unreasonably long. Right, the default of 1024 should be pretty enough, despite we had to increae it to 8096 not to get any receive socket buffer overflow messages. Investigation pending ... I understand that kmalloc has 132K limit. But if I allocate 131072 bytes this is within the limits of kmalloc I suppose. > It melts down that you will have to try to isolate the reason(s) for > unexpected behaviours. I suspect some internal buffer overrun that > causes all those ugly side effects. > > Can you try to scale your app down, remove features/service calls so > that subsystems can be excluded systematically? I feared you asked for that. Well yes, this will actually be the tough task to do, I suppose. Will need quite a time though. Until then: any debugging trick I could try as well ? Best regards, Daniel. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
