Re: What are you doing if the TX buffer overflows?

["Heinz-Jürgen Oertel" <oe@port.de>]

Hallo Oliver,
Danke für Deine Antwort.

> 
> Hello Heinz,
> 
> On 17.09.2012 15:58, Heinz-Jürgen Oertel wrote:
> 
> >
> > is there a way to empty the tx buffer ?
> 
> 
> Usually the buffer does not get empty due to a problem of the CAN controller
> and/or the CAN network.

I know :-)

> 
> So even if you could flush the queue the CAN controller is probably still
> stuck with his processed frame.

At least the SJA1000 (I'm using most often)
allows to abort a pending transmission.

> 
> Setting the interface to DOWN and UP again re-initializes the CAN controller
> and flushes all the queues.
> 
> This would work - but all open sockets would get a notification of the
> interface went down.

May be in my current case this is acceptable.

> 
> Btw. IIRC there's a IFLA_CAN_RESTART functionality to kick the CAN controller
> if it got stuck. It can by triggered by a netlink message. This is the same
> configuration interface that's used to set the bittiming:
> 
> http://lxr.linux.no/#linux+v3.5.4/include/linux/can/netlink.h#L103
> 
> But i have currently no source code example as i always use the 'ip' tool from
> the iproute2 package to configure my CAN interfaces:
> 
> http://lxr.linux.no/#linux+v3.5.4/Documentation/networking/can.txt#L646
> 
> Following that documentation
> 
>         ip link set can0 type can restart
> 
> should do it for 'can0'.
> 
> > Or read out the occupied size of it
> > to get the mumber of CAN frames waiting for transmission?
> 
> 
> I'll take a look, if there's a programming interface to get this value.
> Or is this request obsolete now after my answer above?

No. This is still of interest.
Knowing if the transmit queue is mostly empty is a good thing.
Otherwise the application is sending to fast,
or a lot of higher priority messages are on the network.
> 
> Regards,
> Oliver
> 

Thanks for your effort.
Regards
    Heinz