roland Tollenaar wrote: > Hi > > On 3/6/07, Sebastian Smolorz <[EMAIL PROTECTED]> wrote: > > roland Tollenaar wrote: > > > And i get these messages in dmessage. > > > > > > Assertion failed! drivers/xenomai/can/rtcan_raw.c:rtcan_tx_push:171 > > > dev->tx_socket == 0 > > > (3) TX skb still in use > > > > Why are you trying to send loopback messages? > > I'm not. Of that I am certain.
The above kernel message states it clearly. Something on your computer is trying to send loopback messages. The above message can *only* appear if loopback is activated. So please investigate this issue and switch it off. > > Please strip your application > > > down to the actual problematic situation. That means, remove all sending > > code and deactivate CONFIG_XENO_DRIVERS_CAN_LOOPBACK. > > It takes 2 hours to rebuild the kernel and all the modules. 2 hours?? Why? > I hope > this is not a kernel setting. loopback and listenonly capability is > set in the kernel but I am not using it at the moment. But it is > usefull for testing and it should not be a problem if not turned on? So far you are right. > It is NOT turned on. See above. I'm not convinced. > > > We don't need it here. > > Please ensure that you open only one socket and bind it once. > > I have ensured. I am 100000% certain that it is only called once. I > have not touched rtcanrecv either. Then please do me a favour and only start rtcanrecv when your CAN node is sending. rtcanrecv is known to work. There should not be a socket buffer overflow. > The only possibility is that if I > start the application multimple times that the old binds do not get > undone. What must I do to ensure that they are? How can I check for > this? cat /proc/xenomai/rtdm/open_fildes shows you all open descriptors. If there are some of then although your application is not running then do echo 0 > /proc/xenomai/rtdm/open_fildes for closing FD 0, echo 1 > /proc/xenomai/rtdm/open_fildes for closing FD 1, etc. > > Start a RT > > > thread that does nothing else than receiving CAN messages with a blocking > > call inside a while(1)-loop. > > I cannot use blocking mode unless I cahnge the design intent of my > program. In that case I will run recv in blocking mode, write the > messages to a buffer of my own and perform my read on my own buffer. I > suggested doing this from the start but Wolfgang made me aware of the > DONTWAIT flag. If I have to resort to the other method it will be > because there is something wrong with rtcan recv functionality in non > blocking mode. I suggested blocking mode only for testing purpose. I don't say that you can't use DONTWAIT. But if you want to find your bug your application should be as simple as possible. > > I have now recompiled the kernel + modules with larger buffer AND no > debug messaging (XENO_CAN_DEBUG something or other disabled). I have > reduced the output of the node to give so few messages that the buffer > overflow does not occurr anymore. As I said in a previous mail, disabling the DEBUG option does not make the overflows disappear, only their reporting. If your really want to solve your issue then you should activate it again. > > I am STILL getting fluctuations in period time when I turn the encoder > shaft. A little bit better than it used to be but not something I > would call real-time. Probably because the overflows still take place but are not reported any more. > The flipping can controller is still starting up in passive mode and I > don;t know why. How do you get this information? -- Sebastian _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
