Re: [PATCH v2 1/4] can: dev: Consolidate and unify state change handling.

[Wolfgang Grandegger <wg@grandegger.com>]

On Wed, 22 Oct 2014 12:48:11 +0000, Andri Yngvason
<andri.yngvason@marel.com> wrote:
> On mið 22.okt 2014 12:30, Wolfgang Grandegger wrote:
>> On Wed, 22 Oct 2014 11:48:26 +0000, Andri Yngvason
>> <andri.yngvason@marel.com> wrote:
>>> On þri 21.okt 2014 15:21, Wolfgang Grandegger wrote:
>>>>>>>> To see if the state changes occur as expected could you please
>> record
>>>>>>>> error message traces with candump for the following two
scenarios:
>>>>>>>>
>>>>>>>> 1. send messages with cangen
>>>>>>>>    disconnect the cable
>>>>>>>>    reconnect the cable after a while until the error active state
>> is
>>>>>>>>    reached.
>>> After cleaning up my mess, this is the output for the disconnected
cable
>>> test:
>>>  (000.000000)  can1  20000004   [8]  00 08 00 00 00 00 60 00  
>> ERRORFRAME
>>>         controller-problem{tx-error-warning}
>>>         error-counter-tx-rx{{96}{0}}
>>>  (000.003953)  can1  20000004   [8]  00 20 00 00 00 00 80 00  
>> ERRORFRAME
>>>         controller-problem{tx-error-passive}
>>>         error-counter-tx-rx{{128}{0}}
>>>  (005.959170)  can1  20000002   [8]  03 00 00 00 00 00 00 00  
>> ERRORFRAME
>>>         lost-arbitration{at bit 3}
>> I'm missing an error warning message here... at least on the SJA1000
it's
>> triggered.
> I found this peculiar as well. However, I don't get the warning without
the
> patch applied either.

Yes, because reporting decreasing state changes are not (yet) supported.

> Then I just get:
> root@x86-20140911-072109:~# candump -td -e can1,0~0,#FFFFFFFF | tee
> candump.log                                                          
>  (000.000000)  can1  20000004   [8]  00 08 00 00 00 00 60 00  
ERRORFRAME
>         controller-problem{tx-error-warning}
>         error-counter-tx-rx{{96}{0}}
>  (000.002425)  can1  20000004   [8]  00 20 00 00 00 00 80 00  
ERRORFRAME
>         controller-problem{tx-error-passive}
>         error-counter-tx-rx{{128}{0}}
> 

Could you please include the messages in the trace as well
(using "any,0:0,#FFFFFFFF").

>>
>>>  (000.428328)  can1  20000004   [8]  00 40 00 00 00 00 5F 00  
>> ERRORFRAME
>>>         controller-problem{back-to-error-active}
>>>         error-counter-tx-rx{{95}{0}}
>>>
>>>>>>>>>> 2. set restart-ms=100
>>>>>>>>>>    send messages with cangen
>>>>>>>>>>    provoke a bus-off short-circuiting CAN low and high
>>>>>>>>>>    remove the short-circuit
>>>>>>>>>>
>>> Shorting the can bus yields a loop like this:
>>>  (044.014170)  can1  20000004   [8]  00 20 00 00 00 00 88 00  
>> ERRORFRAME
>>>         controller-problem{tx-error-passive}
>>>         error-counter-tx-rx{{136}{0}}
>>>  (000.003175)  can1  20000040   [8]  00 00 00 00 00 00 7F 00  
>> ERRORFRAME
>>>         bus-off
>>>         error-counter-tx-rx{{127}{0}}
>>>  (000.099664)  can1  20000100   [8]  00 00 00 00 00 00 00 00  
>> ERRORFRAME
>>>         restarted-after-bus-off
>>>  (000.097246)  can1  20000004   [8]  00 20 00 00 00 00 88 00  
>> ERRORFRAME
>>>         controller-problem{tx-error-passive}
>>>         error-counter-tx-rx{{136}{0}}
>>>  (000.003160)  can1  20000040   [8]  00 00 00 00 00 00 7F 00  
>> ERRORFRAME
>>>         bus-off
>>>         error-counter-tx-rx{{127}{0}}
>>>  (000.099602)  can1  20000100   [8]  00 00 00 00 00 00 00 00  
>> ERRORFRAME
>>>         restarted-after-bus-off
>> And the restart does come when the short-circuit is gone?
>>
> No, in fact the bus keeps restarting until the short-circuit is gone.
> 
> Note that I'm using peak_pci. It's sja1000 but maybe there is something
> different?

No, because it's a memory mapped SJA1000 chip. What do you see with
"dmesg"
assuming that CONFIG_CAN_DEV_DEBUG is enabled.

Wolfgang.