I do not really understand what we are talking about. Are we talking about Linux select/accept or Xenomai select/accept? Why not using the
Linux select/accept. Using the blocking accept() would have changed the behaviour somewhat compared to the original design. Anyway, I think that doesn't actually matter much. I have meanwhile derived a much smaller RTDM driver kernel module, test application with blocking accept() ;) plus Makefile that do not depend on any particular external hardware anymore: A SPORT interface (SPORT1 receiver) is configured with internal clock and frame sync generation and so on itself generates a lot of interrupts, and this alltogether quite quickly reproduces the problem on my system. The files together are less than 1000 lines, 20kb. I'd really appreciate if you or someone could take a look at it and maybe try the code on his own bf537 system whether the same faults occur, and why. May I post the files here (as a zipped attachment? inline)? I've already uploaded a copy at
http://www.ixo.de/tmp/till20110228.tgz
If I can do anything to make it more comfortable to try this, please let me know. Short docs: The modt.c is derived from a larger "real" driver. I tried to strip much processing code from it. It doesn't configure the SPORT interface to really act reasonable anymore, just to generate a lot of interrupts, including overflow error interrupts. After putting the path to the kernel into the Makefile it should compile the module out-of-tree if you simply start "make". The test application "till" starts one thread that continously contacts the modt driver via ioctl. This ioctl does nothing but waits for an event that is raised by the interrupts. The original application uses this ioctl() to receive a pointer to a single received packet in mapped memory. I modified the original driver so that it just receives data in the same buffer where the original used a setup with a ring of several buffers. Another thread accept()s incoming connections on port 80 and emits a small chunk of text, enough to satisfy a simple wget. In the current configuration, the fault occurs immediately after loading the module and starting "till" on my system. Probably the SPORT configuration causes much too many interrupts, but the fault still exactly looks like what I experience in my real system. Previous setups required me to actually contact the server and get some data, e.g. with
while true; do wget http://host -O /dev/null ; done
1000x thanks for taking a look in advance... Kolja
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
