Daniel Schnell wrote: > 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.
...or some overwritten memory: The block size is encoded in each heap chunk. Looks to me like we do not check for its sanity with a magic number or so, do we? Would be a nice debug feature. Someone around who's bored (rhetoric question)? > >>> 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 ? Everything is possible. Some smart script hacker could grab the info from the 2.6 files, reformat it, and merge it into the central(!) help file of 2.4. Just takes someone to do the work, as usual... :) > >>> 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 ? None of the services you use from the POSIX skin, only named stuff like mqueues or semaphores. > >>> - 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. There is some further overhead involved. > >> 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 ? > Play with all those modified limits in the kernel config. Does changing / reverting-to-default any of them modify the problem as well? Might give further hints where to dig. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
