Re: pch_can: Data transmission stops after dropped packet

[Wolfgang Grandegger <wg@grandegger.com>]

Hi Casper,

On 11/15/2012 05:32 PM, Casper Mogensen wrote:
> Hi all
> 
> I have been working with the eg20t chipset and the pch_can driver a
> lot up until January this year, where the project i was working on
> unfortunately was shut down. There is a bug in the implementation,
> which causes the transmit buffers to fill up and all become
> unavailable. It happens randomly, but is easily triggered with a high
> load. I experienced the same problems as Michael.
> 
> I have not been working on it for a long time, so i don't recall the
> problem precisely, but as i remember there is two memory areas which
> is used for communication between the processor and the can core. One
> is used for receive, and one is used for transmit in the pch_can
> driver. When initiating a transmit, a flag is indicating that an
> interrupt must be generated upon transmit receive, if a transmit
> interrupt is handled during an ongoing transmit, then problems can
> occur.
> 
>>From pch_xmit in pch_can
> on line 940 in pch_can.c: can_put_echo_skb is called, which occupies
> the skb(which to my best knowledge, is the reason that you get a
> buffer overflow)
> on line 943 in pch_can.c: The transmit complete interrupt flag is
> written to the internal register (but not writing to the can core yet)
> on line 946 in pch_can.c: pch_can_rw_msg_obj is issued, which writes
> the internal registers to can core.
> 
> If the transmit completed handler has been running between lines 943
> or 946, the pch_tx_complete routine will clear the transmit interupt
> enable flag in priv->regs->ifregs[1] (same register is used in both),
> then you end up writing something the message to the core without
> transmit completed interrupt enabled, and with an occupied skb, then
> you eventually runs out of transmit buffers, as the skb's are free'd
> in pch_tx_complete, which is triggered by a transmit completed
> interrupt
> 
> I am a little rusty in this issue, as it is quite a long time ago i
> was working with it, but i hope the description is understandable :-)

Thanks for your info. This confirms that there is there is a bug
somewhere in the driver. Instead of chasing it, I prefer switching to
the C_CAN driver first.

Wolfgang.