Hi
> > >
> > > 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.
The place i look is in proc/rtcan/rtcan2/info. The mode is empty.
Always. I don;t set the mode in the application and on running
rtcanrecv I don't specify loopback.
What else can I do to make certain there is no listen_only mode on?
> 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.
See above. I'm not convinced.
If its any consolation I have not seen that message for a while. But
of course I have debug messages turned off in the kernel config now.
> > 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.
I think the messag overflowing is over now with the larger buffer and
the reduced baudrate. I have discovered that the 1ms was not 1ms when
the baudrate was at 1MB/s so that could have been the major cause for
the overflowing.
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.
This can be confirmed.
> 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.
Have checked. My application neatly alsways has 1 entry there and when
stopped the entry neatly dissapears. I only have a single bind.
But the message overflowing is over.
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 done this now. I have a thrid rt task called task3 which is
also set to run periodically only I have placed the blocking recv
function in there. This function puts all messages into a buffer of my
own which I read with a light read function from the 1ms task. See
later
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.
Ok. I can activate it again but before I deactivated it, the overflow
problem was over. See above.
Probably because the overflows still take place but are not reported any more.
No. Certain about this. I will reconfirm becaause I have saved the
other kernel and modules so I can easily reload them. But I just
wanted to be sure that the messages were not the cause of the
fluctuations.
> The flipping can controller is still starting up in passive mode and I
> don;t know why.
How do you get this information?
cat/proc/rtcan/rtcan2/info.
Quickly reverting to current state of affairs. I now do use the
blocking call and I have the same behaviour. It is impossible that I
have overflowing buffers now, yet when I turn the encoder shaft the
period times of task 1 and task2 fluctuate. task 3 is violating its
task time all the time because obviously it is stuck in the loop in
which I am continuously calling the blocking receive function.
There is no obvious process that is taking up a lot of CPU time, I can
see that there is system activity when I rotate the encoder shaft. I
have no idea how this is possible.
Maybe the violating task 3 is generating messages (which cannot be
seen because dmesg remains quiet and I have not disabled general rt
xenomai messages) but if that is the case why only when I let my node
send messages when I am rotating the shaft?
Are there any CAN errors that I can check for that might be causing
this? The idea that you had yesterday regarding the acknowledge? I
have run out of ideas, hope you have some.
I will turn on the debug messaging again since that clearly was not the problem.
Regards,
Roland
--
Sebastian
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
