Re: pch_can: Data transmission stops after dropped packet

[Wolfgang Grandegger <wg@grandegger.com>]

[-- Attachment #1: Type: text/plain, Size: 4453 bytes --]

On 11/20/2012 10:05 PM, Wolfgang Grandegger wrote:
> Hi Michael,
> 
> On 11/20/2012 08:12 PM, Michael Pellegrini wrote:
>> Wolfgang Grandegger <wg <at> grandegger.com> writes:
>>
>>>>
>>>> However, everything isn't fixed yet.  After sending a handful of messages, 
>> the 
>>>> CAN interface hits the same problem that started this thread.  My 
>> application 
>>>> prints the error "No buffer space available" and the only way to recover is 
>> an 
>>>> interface reset via "ifconfig can0 down" followed by "ifconfig can0 up".
>>>
>>> Could you please send the output of "candump any,0:0,#FFFFFFFF" while
>>> sending the messages. Do they go out to the bus? Also "ip -d -s link
>>> show can0" would be useful.
>>
>> candump produced no output while my application was running and trying to send
>> messages.  Furthermore, the lack of output from candump suggests that messages
>> aren't being received as well.  There is another CAN device on the bus and I can
>> confirm, using a CAN monitor tool on another PC, that it is actively sending
>> messages.
>>
>> Upon starting my application, 16 messages are transmitted on the bus (confirmed
>> via the external CAN monitor tool) which candump does not report.  Then
>> transmission stops.  This lines up with the output of "ip -d -s link show can0",
>> shown below:
> 
> I'm a bit confused. Where is the application running? On this
> PCH-System? Or does an external node send messages, which are not
> received by the PCH-C_CAN?
> 
>> At startup:
>>
>> 4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
>>     link/can
>>     can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
>>     bitrate 250000 sample-point 0.875
>>     tq 500 prop-seg 3 phase-seg1 3 phase-seg2 1 sjw 1
>>     c_can: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
>>     clock 50000000
>>     re-started bus-errors arbit-lost error-warn error-pass bus-off
>>     0          0          0          0          0          0
>>     RX: bytes  packets  errors  dropped overrun mcast
>>     0          0        0       0       0       0
>>     TX: bytes  packets  errors  dropped carrier collsns
>>     0          0        0       0       0       0
>>
>> After transmission stops:
>>
>> 4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
>>     link/can
>>     can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
>>     bitrate 250000 sample-point 0.875
>>     tq 500 prop-seg 3 phase-seg1 3 phase-seg2 1 sjw 1
>>     c_can: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
>>     clock 50000000
>>     re-started bus-errors arbit-lost error-warn error-pass bus-off
>>     0          0          0          0          0          0
>>     RX: bytes  packets  errors  dropped overrun mcast
>>     0          0        0       0       0       0
>>     TX: bytes  packets  errors  dropped carrier collsns
>>     0          0        0       0       0       0
>>
>> After transmission stops & interface is reset:
>>
>> 4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
>>     link/can
>>     can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
>>     bitrate 250000 sample-point 0.875
>>     tq 500 prop-seg 3 phase-seg1 3 phase-seg2 1 sjw 1
>>     c_can: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
>>     clock 50000000
>>     re-started bus-errors arbit-lost error-warn error-pass bus-off
>>     0          0          0          0          0          0
>>     RX: bytes  packets  errors  dropped overrun mcast
>>     0          0        0       0       0       0
>>     TX: bytes  packets  errors  dropped carrier collsns
>>     0          0        0       16      0       0
>>
>> The best I can tell, the 16 messages which are successfully transmitted on the
>> bus are considered dropped by the driver.
> 
> OK, we still have a problem with TX and RX, most likely with interrupts.
> Could you please send a message on the PCH-System executing
> "cansend can0 123#abcdef":
> 
> - Does "candump any,0:0,#FFFFFFFF" report anything.
> 
> - Does the message show up on the bus (visiable to another node or
>   analyser)?
> 
> - Does the interrupt count increase? Check output of /proc/interrupts.
> 
> I will prepare an instrumented driver tomorrow.

Could you please try the attached c-can-pci-v4.tar.bz2. I'm puzzled why
MSI does not get enabled. What does "lspci -vv" list for that device?

Wolfgang.



[-- Attachment #2: c-can-pci-v4.tar.bz2 --]
[-- Type: application/x-bzip, Size: 12142 bytes --]