CAN transmit queue, revisited

CAN transmit queue, revisited

[Constantine Vetoshev]

I'm using SocketCAN on a project, and have run into trouble with error
recovery. Apologies if this topic has been covered recently, but with
gmane out of commission for newer content, I have found no other
archives of this mailing list to search through.

From everything I read and understand, once the transmit queue fills
up, there is no user-space way to clean it out other than restarting
the CAN network interface. This leaves me scratching my head about how
to recover from bus failures.

Suppose I have a (Linux) process which uses a CAN interface (CANtact
in my case) to talk to a bunch of peripheral devices, and the bus goes
off-line (say, power failure to the peripherals). The peripherals stop
acking all the packets my process has sent. The tx queue fills up
almost immediately with messages I'd been sending. Let's say I detect
this condition (it's pretty obvious, with write() calls setting errno
to ENOBUFS), stop sending, do some internal cleanup... and now what?
My application code can figure out if it needs to retransmit anything,
but even when the CAN peripherals go back online, it doesn't matter:
the tx queue is full, write() calls to it will fail, and I have to
kill the network interface to recover.

I found this post:
http://thread.gmane.org/gmane.linux.can/4167 — which suggests using
loopback and CAN_RAW_RECV_OWN_MSGS on the socket to send acks to
self-sent frames and thereby drain the tx queue. I tried it, and it
doesn't work. At least with non-blocking sockets. Is there
confirmation that this technique works at all? Before I go down the
road of hacking CAN's kernel modules to stop using the tx queue and
just using fire-and-forget to send every frame, is there a better way
around this?