* ti hecc rx frames out of order
@ 2016-12-02 19:43 Grim, Dennis
2016-12-04 13:07 ` Oliver Hartkopp
2017-01-05 9:10 ` Yegor Yefremov
0 siblings, 2 replies; 14+ messages in thread
From: Grim, Dennis @ 2016-12-02 19:43 UTC (permalink / raw)
To: linux-can
When running canfdtest on a TI AM3517 HECC, frames randomly appear out of order.
"can-utils" is current (cloned this week from github)
Linux kernel is 3.19.0.
From host (canfdtest -vv -g can0):
0078: [8] ed ee ef f0 f1 f2 f3 f4
0078: [8] ee ef f0 f1 f2 f3 f4 f5
0078: [8] ef f0 f1 f2 f3 f4 f5 f6
0078: [8] f0 f1 f2 f3 f4 f5 f6 f7
0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
Databyte 0 mismatch !
expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
Databyte 1 mismatch !
expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
Databyte 2 mismatch !
expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
Databyte 3 mismatch !
expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
Databyte 4 mismatch !
expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
Databyte 5 mismatch !
expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
Databyte 6 mismatch !
expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
Databyte 7 mismatch !
expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
Test messages sent and received: 507377
Exiting...
From ti hecc DUT (canfdtest -vv can2):
0077: [8] ed ee ef f0 f1 f2 f3 f4
0077: [8] ee ef f0 f1 f2 f3 f4 f5
0077: [8] ef f0 f1 f2 f3 f4 f5 f6
0077: [8] f1 f2 f3 f4 f5 f6 f7 f8
0077: [8] f2 f3 f4 f5 f6 f7 f8 f9
0077: [8] f0 f1 f2 f3 f4 f5 f6 f7 NOTE: this line is out of order
0077: [8] f3 f4 f5 f6 f7 f8 f9 fa
0077: [8] f4 f5 f6 f7 f8 f9 fa fb
0077: [8] f5 f6 f7 f8 f9 fa fb fc
From Peak PCAN-View:
99893) 594360.7 Rx 0077 8 ED EE EF F0 F1 F2 F3 F4
99894) 594361.1 Rx 0078 8 EC ED EE EF F0 F1 F2 F3
99895) 594361.6 Rx 0077 8 EE EF F0 F1 F2 F3 F4 F5
99896) 594362.1 Rx 0078 8 ED EE EF F0 F1 F2 F3 F4
99897) 594362.5 Rx 0078 8 EE EF F0 F1 F2 F3 F4 F5
99898) 594363.0 Rx 0078 8 EF F0 F1 F2 F3 F4 F5 F6
99899) 594363.5 Rx 0077 8 EF F0 F1 F2 F3 F4 F5 F6
99900) 594363.9 Rx 0077 8 F0 F1 F2 F3 F4 F5 F6 F7
99901) 594364.4 Rx 0078 8 F0 F1 F2 F3 F4 F5 F6 F7
99902) 594364.9 Rx 0077 8 F1 F2 F3 F4 F5 F6 F7 F8
99903) 594365.8 Rx 0077 8 F2 F3 F4 F5 F6 F7 F8 F9
99904) 594366.8 Rx 0077 8 F3 F4 F5 F6 F7 F8 F9 FA
99905) 594367.3 Rx 0078 8 F2 F3 F4 F5 F6 F7 F8 F9
99906) 594367.8 Rx 0078 8 F3 F4 F5 F6 F7 F8 F9 FA
99907) 594368.3 Rx 0077 8 F4 F5 F6 F7 F8 F9 FA FB
99908) 594368.7 Rx 0078 8 F1 F2 F3 F4 F5 F6 F7 F8 NOTE: this line is out of order
99909) 594369.2 Rx 0077 8 F5 F6 F7 F8 F9 FA FB FC
99910) 594369.7 Rx 0078 8 F4 F5 F6 F7 F8 F9 FA FB
99911) 594370.2 Rx 0077 8 F6 F7 F8 F9 FA FB FC FD
I'm looking at ti_hecc.c.
Any guidance would be very much appreciated.
Dennis
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ti hecc rx frames out of order
2016-12-02 19:43 ti hecc rx frames out of order Grim, Dennis
@ 2016-12-04 13:07 ` Oliver Hartkopp
2016-12-07 16:55 ` Grim, Dennis
2017-01-05 9:10 ` Yegor Yefremov
1 sibling, 1 reply; 14+ messages in thread
From: Oliver Hartkopp @ 2016-12-04 13:07 UTC (permalink / raw)
To: Grim, Dennis, linux-can
Hi Dennis,
On 12/02/2016 08:43 PM, Grim, Dennis wrote:
> When running canfdtest on a TI AM3517 HECC, frames randomly appear out of order.
>
> "can-utils" is current (cloned this week from github)
>
> Linux kernel is 3.19.0.
(..)
> From Peak PCAN-View:
> 99904) 594366.8 Rx 0077 8 F3 F4 F5 F6 F7 F8 F9 FA
> 99905) 594367.3 Rx 0078 8 F2 F3 F4 F5 F6 F7 F8 F9
> 99906) 594367.8 Rx 0078 8 F3 F4 F5 F6 F7 F8 F9 FA
> 99907) 594368.3 Rx 0077 8 F4 F5 F6 F7 F8 F9 FA FB
> 99908) 594368.7 Rx 0078 8 F1 F2 F3 F4 F5 F6 F7 F8 NOTE: this line is out of order
> 99909) 594369.2 Rx 0077 8 F5 F6 F7 F8 F9 FA FB FC
> 99910) 594369.7 Rx 0078 8 F4 F5 F6 F7 F8 F9 FA FB
> 99911) 594370.2 Rx 0077 8 F6 F7 F8 F9 FA FB FC FD
Please correct me if I'm wrong, but when you can see this out-of-order
issue on a different host with a different tool:
Doesn't this lead to the question of a TX out-of-order instead of a RX
out-of-order??
Regards,
Oliver
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: ti hecc rx frames out of order
2016-12-04 13:07 ` Oliver Hartkopp
@ 2016-12-07 16:55 ` Grim, Dennis
2016-12-10 14:11 ` Oliver Hartkopp
0 siblings, 1 reply; 14+ messages in thread
From: Grim, Dennis @ 2016-12-07 16:55 UTC (permalink / raw)
To: linux-can
> > When running canfdtest on a TI AM3517 HECC, frames randomly appear out of
> order.
> >
> > "can-utils" is current (cloned this week from github)
> >
> > Linux kernel is 3.19.0.
>
> (..)
>
> > From Peak PCAN-View:
>
> > 99904) 594366.8 Rx 0077 8 F3 F4 F5 F6 F7 F8 F9 FA
> > 99905) 594367.3 Rx 0078 8 F2 F3 F4 F5 F6 F7 F8 F9
> > 99906) 594367.8 Rx 0078 8 F3 F4 F5 F6 F7 F8 F9 FA
> > 99907) 594368.3 Rx 0077 8 F4 F5 F6 F7 F8 F9 FA FB
> > 99908) 594368.7 Rx 0078 8 F1 F2 F3 F4 F5 F6 F7 F8 NOTE: this line
> is out of order
> > 99909) 594369.2 Rx 0077 8 F5 F6 F7 F8 F9 FA FB FC
> > 99910) 594369.7 Rx 0078 8 F4 F5 F6 F7 F8 F9 FA FB
> > 99911) 594370.2 Rx 0077 8 F6 F7 F8 F9 FA FB FC FD
>
> Please correct me if I'm wrong, but when you can see this out-of-order issue on a
> different host with a different tool:
>
> Doesn't this lead to the question of a TX out-of-order instead of a RX out-of-
> order??
>
> Regards,
> Oliver
>
Thank you Oliver for your reply.
Pardon me for not providing a clearer description of the issue.
I believe that it is RX out-of-order.
Peak PCAN-View is a Windows application that can be used to monitor CAN bus activity.
When run as a host, the can-utils canfdtest application generates CAN frames with a fixed ID and with data byte values that monotonically increase by one on each successive frame. The lines marked with an * in the PCAN-View output below are frames generated by the host. Note that the data byte values increment monotonically from one frame to the next.
99893) 594360.7 Rx 0077 8 ED EE EF F0 F1 F2 F3 F4 *
99894) 594361.1 Rx 0078 8 EC ED EE EF F0 F1 F2 F3
99895) 594361.6 Rx 0077 8 EE EF F0 F1 F2 F3 F4 F5 *
99896) 594362.1 Rx 0078 8 ED EE EF F0 F1 F2 F3 F4
99897) 594362.5 Rx 0078 8 EE EF F0 F1 F2 F3 F4 F5
99898) 594363.0 Rx 0078 8 EF F0 F1 F2 F3 F4 F5 F6
99899) 594363.5 Rx 0077 8 EF F0 F1 F2 F3 F4 F5 F6 *
99900) 594363.9 Rx 0077 8 F0 F1 F2 F3 F4 F5 F6 F7 *
99901) 594364.4 Rx 0078 8 F0 F1 F2 F3 F4 F5 F6 F7
99902) 594364.9 Rx 0077 8 F1 F2 F3 F4 F5 F6 F7 F8 *
99903) 594365.8 Rx 0077 8 F2 F3 F4 F5 F6 F7 F8 F9 *
99904) 594366.8 Rx 0077 8 F3 F4 F5 F6 F7 F8 F9 FA *
99905) 594367.3 Rx 0078 8 F2 F3 F4 F5 F6 F7 F8 F9
99906) 594367.8 Rx 0078 8 F3 F4 F5 F6 F7 F8 F9 FA
99907) 594368.3 Rx 0077 8 F4 F5 F6 F7 F8 F9 FA FB *
99908) 594368.7 Rx 0078 8 F1 F2 F3 F4 F5 F6 F7 F8
99909) 594369.2 Rx 0077 8 F5 F6 F7 F8 F9 FA FB FC *
99910) 594369.7 Rx 0078 8 F4 F5 F6 F7 F8 F9 FA FB
99911) 594370.2 Rx 0077 8 F6 F7 F8 F9 FA FB FC FD *
When run as a device under test (DUT), the can-utils canfdtest application simply receives CAN frames and (optionally) outputs them to the console then increments the ID and each data byte value by one and sends them. Note that in the canfdtest DUT output below (for frames received from the canfdtest host) lines appear in order except for the line marked with *.
0077: [8] ed ee ef f0 f1 f2 f3 f4
0077: [8] ee ef f0 f1 f2 f3 f4 f5
0077: [8] ef f0 f1 f2 f3 f4 f5 f6
0077: [8] f1 f2 f3 f4 f5 f6 f7 f8
0077: [8] f2 f3 f4 f5 f6 f7 f8 f9
0077: [8] f0 f1 f2 f3 f4 f5 f6 f7 *
0077: [8] f3 f4 f5 f6 f7 f8 f9 fa
0077: [8] f4 f5 f6 f7 f8 f9 fa fb
0077: [8] f5 f6 f7 f8 f9 fa fb fc
Since the frames were sent in order by the canfdtest host but reported out of order by the canfdtest DUT, it seems that it is an RX issue.
I have been away for a few days but plan to investigate the issue now.
Any help with this issue would be most welcome.
Dennis
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ti hecc rx frames out of order
2016-12-07 16:55 ` Grim, Dennis
@ 2016-12-10 14:11 ` Oliver Hartkopp
2016-12-12 15:34 ` Grim, Dennis
0 siblings, 1 reply; 14+ messages in thread
From: Oliver Hartkopp @ 2016-12-10 14:11 UTC (permalink / raw)
To: Grim, Dennis, linux-can
On 12/07/2016 05:55 PM, Grim, Dennis wrote:
>>> When running canfdtest on a TI AM3517 HECC, frames randomly appear out of
>> order.
>>>
>>> "can-utils" is current (cloned this week from github)
>>>
>>> Linux kernel is 3.19.0.
>>
>> (..)
>>
>>> From Peak PCAN-View:
>>
>>> 99904) 594366.8 Rx 0077 8 F3 F4 F5 F6 F7 F8 F9 FA
>>> 99905) 594367.3 Rx 0078 8 F2 F3 F4 F5 F6 F7 F8 F9
>>> 99906) 594367.8 Rx 0078 8 F3 F4 F5 F6 F7 F8 F9 FA
>>> 99907) 594368.3 Rx 0077 8 F4 F5 F6 F7 F8 F9 FA FB
>>> 99908) 594368.7 Rx 0078 8 F1 F2 F3 F4 F5 F6 F7 F8 NOTE: this line
>> is out of order
>>> 99909) 594369.2 Rx 0077 8 F5 F6 F7 F8 F9 FA FB FC
>>> 99910) 594369.7 Rx 0078 8 F4 F5 F6 F7 F8 F9 FA FB
>>> 99911) 594370.2 Rx 0077 8 F6 F7 F8 F9 FA FB FC FD
>>
>> Please correct me if I'm wrong, but when you can see this out-of-order issue on a
>> different host with a different tool:
>>
>> Doesn't this lead to the question of a TX out-of-order instead of a RX out-of-
>> order??
>>
>> Regards,
>> Oliver
>>
>
> Thank you Oliver for your reply.
>
> Pardon me for not providing a clearer description of the issue.
>
> I believe that it is RX out-of-order.
>
> Peak PCAN-View is a Windows application that can be used to monitor CAN bus activity.
>
> When run as a host, the can-utils canfdtest application generates CAN frames with a fixed ID and with data byte values that monotonically increase by one on each successive frame. The lines marked with an * in the PCAN-View output below are frames generated by the host. Note that the data byte values increment monotonically from one frame to the next.
>
> 99893) 594360.7 Rx 0077 8 ED EE EF F0 F1 F2 F3 F4 *
> 99894) 594361.1 Rx 0078 8 EC ED EE EF F0 F1 F2 F3
> 99895) 594361.6 Rx 0077 8 EE EF F0 F1 F2 F3 F4 F5 *
> 99896) 594362.1 Rx 0078 8 ED EE EF F0 F1 F2 F3 F4
> 99897) 594362.5 Rx 0078 8 EE EF F0 F1 F2 F3 F4 F5
> 99898) 594363.0 Rx 0078 8 EF F0 F1 F2 F3 F4 F5 F6
> 99899) 594363.5 Rx 0077 8 EF F0 F1 F2 F3 F4 F5 F6 *
> 99900) 594363.9 Rx 0077 8 F0 F1 F2 F3 F4 F5 F6 F7 *
> 99901) 594364.4 Rx 0078 8 F0 F1 F2 F3 F4 F5 F6 F7
> 99902) 594364.9 Rx 0077 8 F1 F2 F3 F4 F5 F6 F7 F8 *
> 99903) 594365.8 Rx 0077 8 F2 F3 F4 F5 F6 F7 F8 F9 *
> 99904) 594366.8 Rx 0077 8 F3 F4 F5 F6 F7 F8 F9 FA *
> 99905) 594367.3 Rx 0078 8 F2 F3 F4 F5 F6 F7 F8 F9
> 99906) 594367.8 Rx 0078 8 F3 F4 F5 F6 F7 F8 F9 FA
> 99907) 594368.3 Rx 0077 8 F4 F5 F6 F7 F8 F9 FA FB *
> 99908) 594368.7 Rx 0078 8 F1 F2 F3 F4 F5 F6 F7 F8
> 99909) 594369.2 Rx 0077 8 F5 F6 F7 F8 F9 FA FB FC *
> 99910) 594369.7 Rx 0078 8 F4 F5 F6 F7 F8 F9 FA FB
> 99911) 594370.2 Rx 0077 8 F6 F7 F8 F9 FA FB FC FD *
>
> When run as a device under test (DUT), the can-utils canfdtest application simply receives CAN frames and (optionally) outputs them to the console then increments the ID and each data byte value by one and sends them. Note that in the canfdtest DUT output below (for frames received from the canfdtest host) lines appear in order except for the line marked with *.
>
> 0077: [8] ed ee ef f0 f1 f2 f3 f4
> 0077: [8] ee ef f0 f1 f2 f3 f4 f5
> 0077: [8] ef f0 f1 f2 f3 f4 f5 f6
> 0077: [8] f1 f2 f3 f4 f5 f6 f7 f8
> 0077: [8] f2 f3 f4 f5 f6 f7 f8 f9
> 0077: [8] f0 f1 f2 f3 f4 f5 f6 f7 *
> 0077: [8] f3 f4 f5 f6 f7 f8 f9 fa
> 0077: [8] f4 f5 f6 f7 f8 f9 fa fb
> 0077: [8] f5 f6 f7 f8 f9 fa fb fc
>
> Since the frames were sent in order by the canfdtest host but reported out of order by the canfdtest DUT, it seems that it is an RX issue.
>
> I have been away for a few days but plan to investigate the issue now.
>
> Any help with this issue would be most welcome.
Hi Dennis,
can you check whether this idea helps you in your setup:
http://marc.info/?l=linux-can&m=148007442317274&w=2
Regards,
Oliver
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: ti hecc rx frames out of order
2016-12-10 14:11 ` Oliver Hartkopp
@ 2016-12-12 15:34 ` Grim, Dennis
2016-12-12 17:01 ` Oliver Hartkopp
0 siblings, 1 reply; 14+ messages in thread
From: Grim, Dennis @ 2016-12-12 15:34 UTC (permalink / raw)
To: linux-can
> >>> When running canfdtest on a TI AM3517 HECC, frames randomly appear
> >>> out of
> >> order.
> >>>
> >>> "can-utils" is current (cloned this week from github)
> >>>
> >>> Linux kernel is 3.19.0.
> >>
> >> (..)
> >>
> >>> From Peak PCAN-View:
> >>
> >>> 99904) 594366.8 Rx 0077 8 F3 F4 F5 F6 F7 F8 F9 FA
> >>> 99905) 594367.3 Rx 0078 8 F2 F3 F4 F5 F6 F7 F8 F9
> >>> 99906) 594367.8 Rx 0078 8 F3 F4 F5 F6 F7 F8 F9 FA
> >>> 99907) 594368.3 Rx 0077 8 F4 F5 F6 F7 F8 F9 FA FB
> >>> 99908) 594368.7 Rx 0078 8 F1 F2 F3 F4 F5 F6 F7 F8 NOTE: this
> line
> >> is out of order
> >>> 99909) 594369.2 Rx 0077 8 F5 F6 F7 F8 F9 FA FB FC
> >>> 99910) 594369.7 Rx 0078 8 F4 F5 F6 F7 F8 F9 FA FB
> >>> 99911) 594370.2 Rx 0077 8 F6 F7 F8 F9 FA FB FC FD
> >>
> >> Please correct me if I'm wrong, but when you can see this
> >> out-of-order issue on a different host with a different tool:
> >>
> >> Doesn't this lead to the question of a TX out-of-order instead of a
> >> RX out-of- order??
> >>
> >> Regards,
> >> Oliver
> >>
> >
> > Thank you Oliver for your reply.
> >
> > Pardon me for not providing a clearer description of the issue.
> >
> > I believe that it is RX out-of-order.
> >
> > Peak PCAN-View is a Windows application that can be used to monitor CAN bus
> activity.
> >
> > When run as a host, the can-utils canfdtest application generates CAN frames
> with a fixed ID and with data byte values that monotonically increase by one on
> each successive frame. The lines marked with an * in the PCAN-View output
> below are frames generated by the host. Note that the data byte values increment
> monotonically from one frame to the next.
> >
> > 99893) 594360.7 Rx 0077 8 ED EE EF F0 F1 F2 F3 F4 *
> > 99894) 594361.1 Rx 0078 8 EC ED EE EF F0 F1 F2 F3
> > 99895) 594361.6 Rx 0077 8 EE EF F0 F1 F2 F3 F4 F5 *
> > 99896) 594362.1 Rx 0078 8 ED EE EF F0 F1 F2 F3 F4
> > 99897) 594362.5 Rx 0078 8 EE EF F0 F1 F2 F3 F4 F5
> > 99898) 594363.0 Rx 0078 8 EF F0 F1 F2 F3 F4 F5 F6
> > 99899) 594363.5 Rx 0077 8 EF F0 F1 F2 F3 F4 F5 F6 *
> > 99900) 594363.9 Rx 0077 8 F0 F1 F2 F3 F4 F5 F6 F7 *
> > 99901) 594364.4 Rx 0078 8 F0 F1 F2 F3 F4 F5 F6 F7
> > 99902) 594364.9 Rx 0077 8 F1 F2 F3 F4 F5 F6 F7 F8 *
> > 99903) 594365.8 Rx 0077 8 F2 F3 F4 F5 F6 F7 F8 F9 *
> > 99904) 594366.8 Rx 0077 8 F3 F4 F5 F6 F7 F8 F9 FA *
> > 99905) 594367.3 Rx 0078 8 F2 F3 F4 F5 F6 F7 F8 F9
> > 99906) 594367.8 Rx 0078 8 F3 F4 F5 F6 F7 F8 F9 FA
> > 99907) 594368.3 Rx 0077 8 F4 F5 F6 F7 F8 F9 FA FB *
> > 99908) 594368.7 Rx 0078 8 F1 F2 F3 F4 F5 F6 F7 F8
> > 99909) 594369.2 Rx 0077 8 F5 F6 F7 F8 F9 FA FB FC *
> > 99910) 594369.7 Rx 0078 8 F4 F5 F6 F7 F8 F9 FA FB
> > 99911) 594370.2 Rx 0077 8 F6 F7 F8 F9 FA FB FC FD *
> >
> > When run as a device under test (DUT), the can-utils canfdtest application simply
> receives CAN frames and (optionally) outputs them to the console then increments
> the ID and each data byte value by one and sends them. Note that in the canfdtest
> DUT output below (for frames received from the canfdtest host) lines appear in
> order except for the line marked with *.
> >
> > 0077: [8] ed ee ef f0 f1 f2 f3 f4
> > 0077: [8] ee ef f0 f1 f2 f3 f4 f5
> > 0077: [8] ef f0 f1 f2 f3 f4 f5 f6
> > 0077: [8] f1 f2 f3 f4 f5 f6 f7 f8
> > 0077: [8] f2 f3 f4 f5 f6 f7 f8 f9
> > 0077: [8] f0 f1 f2 f3 f4 f5 f6 f7 *
> > 0077: [8] f3 f4 f5 f6 f7 f8 f9 fa
> > 0077: [8] f4 f5 f6 f7 f8 f9 fa fb
> > 0077: [8] f5 f6 f7 f8 f9 fa fb fc
> >
> > Since the frames were sent in order by the canfdtest host but reported out of
> order by the canfdtest DUT, it seems that it is an RX issue.
> >
> > I have been away for a few days but plan to investigate the issue now.
> >
> > Any help with this issue would be most welcome.
>
> Hi Dennis,
>
> can you check whether this idea helps you in your setup:
>
> http://marc.info/?l=linux-can&m=148007442317274&w=2
>
> Regards,
> Oliver
Thank you.
I will gladly try your idea. However, it appears to address an issue related to SMP systems. The TI AM3517 is single core. Would you expect your idea to have any impact for single core?
Also, the TI AM3517 HECC device driver uses NAPI.
Dennis
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ti hecc rx frames out of order
2016-12-12 15:34 ` Grim, Dennis
@ 2016-12-12 17:01 ` Oliver Hartkopp
2016-12-12 17:17 ` Grim, Dennis
0 siblings, 1 reply; 14+ messages in thread
From: Oliver Hartkopp @ 2016-12-12 17:01 UTC (permalink / raw)
To: Grim, Dennis, Marc Kleine-Budde; +Cc: linux-can
On 12/12/2016 04:34 PM, Grim, Dennis wrote:
> I will gladly try your idea. However, it appears to address an issue related to SMP systems. The TI AM3517 is single core. Would you expect your idea to have any impact for single core?
No.
> Also, the TI AM3517 HECC device driver uses NAPI.
Ugh!
@Marc: When this is a NAPI driver - what could be the problem then?
Is NAPI probably the root cause of the o-o-o issue here?
Regards,
Oliver
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: ti hecc rx frames out of order
2016-12-12 17:01 ` Oliver Hartkopp
@ 2016-12-12 17:17 ` Grim, Dennis
2016-12-12 18:46 ` Wolfgang Grandegger
0 siblings, 1 reply; 14+ messages in thread
From: Grim, Dennis @ 2016-12-12 17:17 UTC (permalink / raw)
To: linux-can
> > I will gladly try your idea. However, it appears to address an issue related to
> SMP systems. The TI AM3517 is single core. Would you expect your idea to have
> any impact for single core?
>
> No.
>
> > Also, the TI AM3517 HECC device driver uses NAPI.
>
> Ugh!
>
> @Marc: When this is a NAPI driver - what could be the problem then?
>
> Is NAPI probably the root cause of the o-o-o issue here?
>
> Regards,
> Oliver
I should add that the hardware that I'm using for test also has two memory-mapped SJA1000 controllers. I'm using the Linux mainlined SJA1000 platform device driver. That driver does not use NAPI.
The same test that generates o-o-o errors on the TI HECC runs for days without o-o-o errors.
This leads me to believe that the issue that I'm seeing is in NAPI or possibly the TI HECC driver.
Dennis
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ti hecc rx frames out of order
2016-12-12 17:17 ` Grim, Dennis
@ 2016-12-12 18:46 ` Wolfgang Grandegger
2016-12-12 19:11 ` Wolfgang Grandegger
0 siblings, 1 reply; 14+ messages in thread
From: Wolfgang Grandegger @ 2016-12-12 18:46 UTC (permalink / raw)
To: Grim, Dennis, linux-can
Hello Dennis,
I had a closer look to the ti_hecc driver...
Am 12.12.2016 um 18:17 schrieb Grim, Dennis:
>>> I will gladly try your idea. However, it appears to address an issue related to
>> SMP systems. The TI AM3517 is single core. Would you expect your idea to have
>> any impact for single core?
>>
>> No.
>>
>>> Also, the TI AM3517 HECC device driver uses NAPI.
At a first glance, access to HECC_CANMIM seems racy. It's modified in
the interrupt handler for TX and in ti_hecc_rx_poll() for RX. It may
happen, that the wrong RX mailbox is enabled... even if that's not yet
obvious too me. For a quick check, you could try the patch below:
diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
index 680d1ff..fc4b6c2 100644
--- a/drivers/net/can/ti_hecc.c
+++ b/drivers/net/can/ti_hecc.c
@@ -649,9 +649,11 @@ static int ti_hecc_rx_poll(struct napi_struct *napi, int quota)
if (hecc_read(priv, HECC_CANRMP) == 0) {
napi_complete(napi);
/* Re-enable RX mailbox interrupts */
+ spin_lock_irqsave(&priv->mbx_lock, flags);
mbx_mask = hecc_read(priv, HECC_CANMIM);
mbx_mask |= HECC_TX_MBOX_MASK;
hecc_write(priv, HECC_CANMIM, mbx_mask);
+ spin_unlock_irqrestore(&priv->mbx_lock, flags);
}
return num_pkts;
@@ -776,9 +778,9 @@ static irqreturn_t ti_hecc_interrupt(int irq, void *dev_id)
mbx_mask = BIT(mbxno);
if (!(mbx_mask & hecc_read(priv, HECC_CANTA)))
break;
+ spin_lock_irqsave(&priv->mbx_lock, flags);
hecc_clear_bit(priv, HECC_CANMIM, mbx_mask);
hecc_write(priv, HECC_CANTA, mbx_mask);
- spin_lock_irqsave(&priv->mbx_lock, flags);
hecc_clear_bit(priv, HECC_CANME, mbx_mask);
spin_unlock_irqrestore(&priv->mbx_lock, flags);
stats->tx_bytes += hecc_read_mbx(priv, mbxno,
Wolfgang.
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: ti hecc rx frames out of order
2016-12-12 18:46 ` Wolfgang Grandegger
@ 2016-12-12 19:11 ` Wolfgang Grandegger
2016-12-14 18:44 ` Grim, Dennis
0 siblings, 1 reply; 14+ messages in thread
From: Wolfgang Grandegger @ 2016-12-12 19:11 UTC (permalink / raw)
To: Grim, Dennis, linux-can
Hello,
Am 12.12.2016 um 19:46 schrieb Wolfgang Grandegger:
> Hello Dennis,
>
> I had a closer look to the ti_hecc driver...
>
> Am 12.12.2016 um 18:17 schrieb Grim, Dennis:
>>>> I will gladly try your idea. However, it appears to address an issue related to
>>> SMP systems. The TI AM3517 is single core. Would you expect your idea to have
>>> any impact for single core?
>>>
>>> No.
>>>
>>>> Also, the TI AM3517 HECC device driver uses NAPI.
>
> At a first glance, access to HECC_CANMIM seems racy. It's modified in
> the interrupt handler for TX and in ti_hecc_rx_poll() for RX. It may
> happen, that the wrong RX mailbox is enabled... even if that's not yet
> obvious too me. For a quick check, you could try the patch below:
>
> diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
> index 680d1ff..fc4b6c2 100644
> --- a/drivers/net/can/ti_hecc.c
> +++ b/drivers/net/can/ti_hecc.c
> @@ -649,9 +649,11 @@ static int ti_hecc_rx_poll(struct napi_struct *napi, int quota)
> if (hecc_read(priv, HECC_CANRMP) == 0) {
> napi_complete(napi);
> /* Re-enable RX mailbox interrupts */
> + spin_lock_irqsave(&priv->mbx_lock, flags);
> mbx_mask = hecc_read(priv, HECC_CANMIM);
> mbx_mask |= HECC_TX_MBOX_MASK;
> hecc_write(priv, HECC_CANMIM, mbx_mask);
> + spin_unlock_irqrestore(&priv->mbx_lock, flags);
> }
>
> return num_pkts;
> @@ -776,9 +778,9 @@ static irqreturn_t ti_hecc_interrupt(int irq, void *dev_id)
> mbx_mask = BIT(mbxno);
> if (!(mbx_mask & hecc_read(priv, HECC_CANTA)))
> break;
> + spin_lock_irqsave(&priv->mbx_lock, flags);
> hecc_clear_bit(priv, HECC_CANMIM, mbx_mask);
> hecc_write(priv, HECC_CANTA, mbx_mask);
> - spin_lock_irqsave(&priv->mbx_lock, flags);
> hecc_clear_bit(priv, HECC_CANME, mbx_mask);
> spin_unlock_irqrestore(&priv->mbx_lock, flags);
> stats->tx_bytes += hecc_read_mbx(priv, mbxno,
>
There are two more critical locations where HECC_CANMIM is modified.
Should be protected in a similar way:
diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
index 680d1ff..aa48253 100644
--- a/drivers/net/can/ti_hecc.c
+++ b/drivers/net/can/ti_hecc.c
@@ -532,10 +532,10 @@ static netdev_tx_t ti_hecc_xmit(struct sk_buff *skb, struct net_device *ndev)
netif_stop_queue(ndev);
}
hecc_set_bit(priv, HECC_CANME, mbx_mask);
- spin_unlock_irqrestore(&priv->mbx_lock, flags);
hecc_clear_bit(priv, HECC_CANMD, mbx_mask);
hecc_set_bit(priv, HECC_CANMIM, mbx_mask);
+ spin_unlock_irqrestore(&priv->mbx_lock, flags);
hecc_write(priv, HECC_CANTRS, mbx_mask);
return NETDEV_TX_OK;
@@ -649,9 +649,11 @@ static int ti_hecc_rx_poll(struct napi_struct *napi, int quota)
if (hecc_read(priv, HECC_CANRMP) == 0) {
napi_complete(napi);
/* Re-enable RX mailbox interrupts */
+ spin_lock_irqsave(&priv->mbx_lock, flags);
mbx_mask = hecc_read(priv, HECC_CANMIM);
mbx_mask |= HECC_TX_MBOX_MASK;
hecc_write(priv, HECC_CANMIM, mbx_mask);
+ spin_unlock_irqrestore(&priv->mbx_lock, flags);
}
return num_pkts;
@@ -776,9 +778,9 @@ static irqreturn_t ti_hecc_interrupt(int irq, void *dev_id)
mbx_mask = BIT(mbxno);
if (!(mbx_mask & hecc_read(priv, HECC_CANTA)))
break;
+ spin_lock_irqsave(&priv->mbx_lock, flags);
hecc_clear_bit(priv, HECC_CANMIM, mbx_mask);
hecc_write(priv, HECC_CANTA, mbx_mask);
- spin_lock_irqsave(&priv->mbx_lock, flags);
hecc_clear_bit(priv, HECC_CANME, mbx_mask);
spin_unlock_irqrestore(&priv->mbx_lock, flags);
stats->tx_bytes += hecc_read_mbx(priv, mbxno,
@@ -798,9 +800,11 @@ static irqreturn_t ti_hecc_interrupt(int irq, void *dev_id)
/* Disable RX mailbox interrupts and let NAPI reenable them */
if (hecc_read(priv, HECC_CANRMP)) {
+ spin_lock_irqsave(&priv->mbx_lock, flags);
ack = hecc_read(priv, HECC_CANMIM);
ack &= BIT(HECC_MAX_TX_MBOX) - 1;
hecc_write(priv, HECC_CANMIM, ack);
+ spin_unlock_irqrestore(&priv->mbx_lock, flags);
napi_schedule(&priv->napi);
}
}
Wolfgang.
^ permalink raw reply related [flat|nested] 14+ messages in thread
* RE: ti hecc rx frames out of order
2016-12-12 19:11 ` Wolfgang Grandegger
@ 2016-12-14 18:44 ` Grim, Dennis
2016-12-15 7:45 ` Wolfgang Grandegger
0 siblings, 1 reply; 14+ messages in thread
From: Grim, Dennis @ 2016-12-14 18:44 UTC (permalink / raw)
To: linux-can
> Hello,
>
> Am 12.12.2016 um 19:46 schrieb Wolfgang Grandegger:
> > Hello Dennis,
> >
> > I had a closer look to the ti_hecc driver...
> >
> > Am 12.12.2016 um 18:17 schrieb Grim, Dennis:
> >>>> I will gladly try your idea. However, it appears to address an
> >>>> issue related to
> >>> SMP systems. The TI AM3517 is single core. Would you expect your
> >>> idea to have any impact for single core?
> >>>
> >>> No.
> >>>
> >>>> Also, the TI AM3517 HECC device driver uses NAPI.
> >
> > At a first glance, access to HECC_CANMIM seems racy. It's modified in
> > the interrupt handler for TX and in ti_hecc_rx_poll() for RX. It may
> > happen, that the wrong RX mailbox is enabled... even if that's not yet
> > obvious too me. For a quick check, you could try the patch below:
> >
> > diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
> > index 680d1ff..fc4b6c2 100644
> > --- a/drivers/net/can/ti_hecc.c
> > +++ b/drivers/net/can/ti_hecc.c
> > @@ -649,9 +649,11 @@ static int ti_hecc_rx_poll(struct napi_struct *napi, int
> quota)
> > if (hecc_read(priv, HECC_CANRMP) == 0) {
> > napi_complete(napi);
> > /* Re-enable RX mailbox interrupts */
> > + spin_lock_irqsave(&priv->mbx_lock, flags);
> > mbx_mask = hecc_read(priv, HECC_CANMIM);
> > mbx_mask |= HECC_TX_MBOX_MASK;
> > hecc_write(priv, HECC_CANMIM, mbx_mask);
> > + spin_unlock_irqrestore(&priv->mbx_lock, flags);
> > }
> >
> > return num_pkts;
> > @@ -776,9 +778,9 @@ static irqreturn_t ti_hecc_interrupt(int irq, void *dev_id)
> > mbx_mask = BIT(mbxno);
> > if (!(mbx_mask & hecc_read(priv, HECC_CANTA)))
> > break;
> > + spin_lock_irqsave(&priv->mbx_lock, flags);
> > hecc_clear_bit(priv, HECC_CANMIM, mbx_mask);
> > hecc_write(priv, HECC_CANTA, mbx_mask);
> > - spin_lock_irqsave(&priv->mbx_lock, flags);
> > hecc_clear_bit(priv, HECC_CANME, mbx_mask);
> > spin_unlock_irqrestore(&priv->mbx_lock, flags);
> > stats->tx_bytes += hecc_read_mbx(priv, mbxno,
> >
>
> There are two more critical locations where HECC_CANMIM is modified.
> Should be protected in a similar way:
>
> diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c index
> 680d1ff..aa48253 100644
> --- a/drivers/net/can/ti_hecc.c
> +++ b/drivers/net/can/ti_hecc.c
> @@ -532,10 +532,10 @@ static netdev_tx_t ti_hecc_xmit(struct sk_buff *skb,
> struct net_device *ndev)
> netif_stop_queue(ndev);
> }
> hecc_set_bit(priv, HECC_CANME, mbx_mask);
> - spin_unlock_irqrestore(&priv->mbx_lock, flags);
>
> hecc_clear_bit(priv, HECC_CANMD, mbx_mask);
> hecc_set_bit(priv, HECC_CANMIM, mbx_mask);
> + spin_unlock_irqrestore(&priv->mbx_lock, flags);
> hecc_write(priv, HECC_CANTRS, mbx_mask);
>
> return NETDEV_TX_OK;
> @@ -649,9 +649,11 @@ static int ti_hecc_rx_poll(struct napi_struct *napi, int
> quota)
> if (hecc_read(priv, HECC_CANRMP) == 0) {
> napi_complete(napi);
> /* Re-enable RX mailbox interrupts */
> + spin_lock_irqsave(&priv->mbx_lock, flags);
> mbx_mask = hecc_read(priv, HECC_CANMIM);
> mbx_mask |= HECC_TX_MBOX_MASK;
> hecc_write(priv, HECC_CANMIM, mbx_mask);
> + spin_unlock_irqrestore(&priv->mbx_lock, flags);
> }
>
> return num_pkts;
> @@ -776,9 +778,9 @@ static irqreturn_t ti_hecc_interrupt(int irq, void *dev_id)
> mbx_mask = BIT(mbxno);
> if (!(mbx_mask & hecc_read(priv, HECC_CANTA)))
> break;
> + spin_lock_irqsave(&priv->mbx_lock, flags);
> hecc_clear_bit(priv, HECC_CANMIM, mbx_mask);
> hecc_write(priv, HECC_CANTA, mbx_mask);
> - spin_lock_irqsave(&priv->mbx_lock, flags);
> hecc_clear_bit(priv, HECC_CANME, mbx_mask);
> spin_unlock_irqrestore(&priv->mbx_lock, flags);
> stats->tx_bytes += hecc_read_mbx(priv, mbxno, @@ -798,9
> +800,11 @@ static irqreturn_t ti_hecc_interrupt(int irq, void *dev_id)
>
> /* Disable RX mailbox interrupts and let NAPI reenable them */
> if (hecc_read(priv, HECC_CANRMP)) {
> + spin_lock_irqsave(&priv->mbx_lock, flags);
> ack = hecc_read(priv, HECC_CANMIM);
> ack &= BIT(HECC_MAX_TX_MBOX) - 1;
> hecc_write(priv, HECC_CANMIM, ack);
> + spin_unlock_irqrestore(&priv->mbx_lock, flags);
> napi_schedule(&priv->napi);
> }
> }
>
>
> Wolfgang.
Thank you Wolfgang.
I tried your second patch. It did not correct the o-o-o issue.
Are there other ideas?
I am looking at ti_hecc.c. The HECC and NAPI are new to me so my progress is slow.
Dennis
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ti hecc rx frames out of order
2016-12-14 18:44 ` Grim, Dennis
@ 2016-12-15 7:45 ` Wolfgang Grandegger
0 siblings, 0 replies; 14+ messages in thread
From: Wolfgang Grandegger @ 2016-12-15 7:45 UTC (permalink / raw)
To: Grim, Dennis, linux-can
Hello Denis,
Am 14.12.2016 um 19:44 schrieb Grim, Dennis:
... snip ...
>
> Thank you Wolfgang.
>
> I tried your second patch. It did not correct the o-o-o issue.
>
> Are there other ideas?
>
> I am looking at ti_hecc.c. The HECC and NAPI are new to me so my progress is slow.
OK. Then we need some instrumentation. The history of the mailbox
numbers would be interesting. The following patch may help to find
the problem:
diff --git a/drivers/net/can/sja1000/ems_pci.c b/drivers/net/can/sja1000/ems_pci.c
index 7481c32..b04644d 100644
--- a/drivers/net/can/sja1000/ems_pci.c
+++ b/drivers/net/can/sja1000/ems_pci.c
@@ -115,7 +115,7 @@ MODULE_DEVICE_TABLE(pci, ems_pci_tbl);
/*
* Helper to read internal registers from card logic (not CAN)
*/
-static u8 ems_pci_v1_readb(struct ems_pci_card *card, unsigned int port)
+static u8 ems_pci_v1_readb(const struct ems_pci_card *card, unsigned int port)
{
return readb(card->base_addr + (port * 4));
}
diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
index 680d1ff..1b823b6 100644
--- a/drivers/net/can/ti_hecc.c
+++ b/drivers/net/can/ti_hecc.c
@@ -532,15 +532,20 @@ static netdev_tx_t ti_hecc_xmit(struct sk_buff *skb, struct net_device *ndev)
netif_stop_queue(ndev);
}
hecc_set_bit(priv, HECC_CANME, mbx_mask);
- spin_unlock_irqrestore(&priv->mbx_lock, flags);
hecc_clear_bit(priv, HECC_CANMD, mbx_mask);
hecc_set_bit(priv, HECC_CANMIM, mbx_mask);
+ spin_unlock_irqrestore(&priv->mbx_lock, flags);
hecc_write(priv, HECC_CANTRS, mbx_mask);
return NETDEV_TX_OK;
}
+static RX_MBX_HIST_MAX 16
+static unsigned char rx_data0_last;
+static int rx_mbx_hist_idx;
+static int rx_mbx_history[RX_MBX_HIST_MAX];
+
static int ti_hecc_rx_pkt(struct ti_hecc_priv *priv, int mbxno)
{
struct net_device_stats *stats = &priv->ndev->stats;
@@ -573,6 +578,24 @@ static int ti_hecc_rx_pkt(struct ti_hecc_priv *priv, int mbxno)
data = hecc_read_mbx(priv, mbxno, HECC_CANMDH);
*(__be32 *)(cf->data + 4) = cpu_to_be32(data);
}
+
+ rx_mbx_history[rx_mbx_hist_idx++] = mbxno;
+ if (rx_mbx_hist_idx >= RX_MBX_HIST_MAX)
+ rx_mbx_hist_idx = 0;
+
+ if (cf->can_id == 0x77) {
+ if (cf->data[0] != (rx_bx_last + 1)) {
+ int i;
+ pr_info("O-O at priv->rx_next = %d\n", priv->rx_next);
+ pr_info("rx_mbx_hist_idx = %d\n", rx_mbx_hist_idx);
+ for (i = 0; i < RX_MBX_HIST_MAX; i++)
+ pr_info("rx_mbx_history[%d] = %d\n",
+ i, rx_mbx_history[i]);
+
+ }
+ rx_bx_last = cf->data[0];
+ }
+
spin_lock_irqsave(&priv->mbx_lock, flags);
hecc_clear_bit(priv, HECC_CANME, mbx_mask);
hecc_write(priv, HECC_CANRMP, mbx_mask);
@@ -649,9 +672,11 @@ static int ti_hecc_rx_poll(struct napi_struct *napi, int quota)
if (hecc_read(priv, HECC_CANRMP) == 0) {
napi_complete(napi);
/* Re-enable RX mailbox interrupts */
+ spin_lock_irqsave(&priv->mbx_lock, flags);
mbx_mask = hecc_read(priv, HECC_CANMIM);
mbx_mask |= HECC_TX_MBOX_MASK;
hecc_write(priv, HECC_CANMIM, mbx_mask);
+ spin_unlock_irqrestore(&priv->mbx_lock, flags);
}
return num_pkts;
@@ -776,9 +801,9 @@ static irqreturn_t ti_hecc_interrupt(int irq, void *dev_id)
mbx_mask = BIT(mbxno);
if (!(mbx_mask & hecc_read(priv, HECC_CANTA)))
break;
+ spin_lock_irqsave(&priv->mbx_lock, flags);
hecc_clear_bit(priv, HECC_CANMIM, mbx_mask);
hecc_write(priv, HECC_CANTA, mbx_mask);
- spin_lock_irqsave(&priv->mbx_lock, flags);
hecc_clear_bit(priv, HECC_CANME, mbx_mask);
spin_unlock_irqrestore(&priv->mbx_lock, flags);
stats->tx_bytes += hecc_read_mbx(priv, mbxno,
@@ -798,9 +823,11 @@ static irqreturn_t ti_hecc_interrupt(int irq, void *dev_id)
/* Disable RX mailbox interrupts and let NAPI reenable them */
if (hecc_read(priv, HECC_CANRMP)) {
+ spin_lock_irqsave(&priv->mbx_lock, flags);
ack = hecc_read(priv, HECC_CANMIM);
ack &= BIT(HECC_MAX_TX_MBOX) - 1;
hecc_write(priv, HECC_CANMIM, ack);
+ spin_unlock_irqrestore(&priv->mbx_lock, flags);
napi_schedule(&priv->napi);
}
}
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: ti hecc rx frames out of order
2016-12-02 19:43 ti hecc rx frames out of order Grim, Dennis
2016-12-04 13:07 ` Oliver Hartkopp
@ 2017-01-05 9:10 ` Yegor Yefremov
2017-01-06 6:02 ` Yegor Yefremov
2017-01-06 20:51 ` Grim, Dennis
1 sibling, 2 replies; 14+ messages in thread
From: Yegor Yefremov @ 2017-01-05 9:10 UTC (permalink / raw)
To: Grim, Dennis; +Cc: linux-can
Hi Dennis,
On Fri, Dec 2, 2016 at 8:43 PM, Grim, Dennis <Dennis.Grim@teejet.com> wrote:
> When running canfdtest on a TI AM3517 HECC, frames randomly appear out of order.
>
> "can-utils" is current (cloned this week from github)
>
> Linux kernel is 3.19.0.
Are you using Device Tree (DTS)? If yes, could you share your HECC
configuration fragment? Aside from hecc_ck I don't see much DTS
related info.
Thanks.
Yegor
> From host (canfdtest -vv -g can0):
>
> 0078: [8] ed ee ef f0 f1 f2 f3 f4
> 0078: [8] ee ef f0 f1 f2 f3 f4 f5
> 0078: [8] ef f0 f1 f2 f3 f4 f5 f6
> 0078: [8] f0 f1 f2 f3 f4 f5 f6 f7
> 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
> Databyte 0 mismatch !
> expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
> received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
> Databyte 1 mismatch !
> expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
> received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
> Databyte 2 mismatch !
> expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
> received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
> Databyte 3 mismatch !
> expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
> received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
> Databyte 4 mismatch !
> expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
> received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
> Databyte 5 mismatch !
> expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
> received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
> Databyte 6 mismatch !
> expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
> received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
> Databyte 7 mismatch !
> expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
> received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
>
> Test messages sent and received: 507377
> Exiting...
>
> From ti hecc DUT (canfdtest -vv can2):
>
> 0077: [8] ed ee ef f0 f1 f2 f3 f4
> 0077: [8] ee ef f0 f1 f2 f3 f4 f5
> 0077: [8] ef f0 f1 f2 f3 f4 f5 f6
> 0077: [8] f1 f2 f3 f4 f5 f6 f7 f8
> 0077: [8] f2 f3 f4 f5 f6 f7 f8 f9
> 0077: [8] f0 f1 f2 f3 f4 f5 f6 f7 NOTE: this line is out of order
> 0077: [8] f3 f4 f5 f6 f7 f8 f9 fa
> 0077: [8] f4 f5 f6 f7 f8 f9 fa fb
> 0077: [8] f5 f6 f7 f8 f9 fa fb fc
>
>
> From Peak PCAN-View:
>
> 99893) 594360.7 Rx 0077 8 ED EE EF F0 F1 F2 F3 F4
> 99894) 594361.1 Rx 0078 8 EC ED EE EF F0 F1 F2 F3
> 99895) 594361.6 Rx 0077 8 EE EF F0 F1 F2 F3 F4 F5
> 99896) 594362.1 Rx 0078 8 ED EE EF F0 F1 F2 F3 F4
> 99897) 594362.5 Rx 0078 8 EE EF F0 F1 F2 F3 F4 F5
> 99898) 594363.0 Rx 0078 8 EF F0 F1 F2 F3 F4 F5 F6
> 99899) 594363.5 Rx 0077 8 EF F0 F1 F2 F3 F4 F5 F6
> 99900) 594363.9 Rx 0077 8 F0 F1 F2 F3 F4 F5 F6 F7
> 99901) 594364.4 Rx 0078 8 F0 F1 F2 F3 F4 F5 F6 F7
> 99902) 594364.9 Rx 0077 8 F1 F2 F3 F4 F5 F6 F7 F8
> 99903) 594365.8 Rx 0077 8 F2 F3 F4 F5 F6 F7 F8 F9
> 99904) 594366.8 Rx 0077 8 F3 F4 F5 F6 F7 F8 F9 FA
> 99905) 594367.3 Rx 0078 8 F2 F3 F4 F5 F6 F7 F8 F9
> 99906) 594367.8 Rx 0078 8 F3 F4 F5 F6 F7 F8 F9 FA
> 99907) 594368.3 Rx 0077 8 F4 F5 F6 F7 F8 F9 FA FB
> 99908) 594368.7 Rx 0078 8 F1 F2 F3 F4 F5 F6 F7 F8 NOTE: this line is out of order
> 99909) 594369.2 Rx 0077 8 F5 F6 F7 F8 F9 FA FB FC
> 99910) 594369.7 Rx 0078 8 F4 F5 F6 F7 F8 F9 FA FB
> 99911) 594370.2 Rx 0077 8 F6 F7 F8 F9 FA FB FC FD
>
> I'm looking at ti_hecc.c.
>
> Any guidance would be very much appreciated.
>
> Dennis
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: ti hecc rx frames out of order
2017-01-05 9:10 ` Yegor Yefremov
@ 2017-01-06 6:02 ` Yegor Yefremov
2017-01-06 20:51 ` Grim, Dennis
1 sibling, 0 replies; 14+ messages in thread
From: Yegor Yefremov @ 2017-01-06 6:02 UTC (permalink / raw)
To: Grim, Dennis; +Cc: linux-can, hs, anton.a.glukhov
Hi Anton and Heiko,
On Thu, Jan 5, 2017 at 10:10 AM, Yegor Yefremov
<yegorslists@googlemail.com> wrote:
> Hi Dennis,
>
> On Fri, Dec 2, 2016 at 8:43 PM, Grim, Dennis <Dennis.Grim@teejet.com> wrote:
>> When running canfdtest on a TI AM3517 HECC, frames randomly appear out of order.
>>
>> "can-utils" is current (cloned this week from github)
>>
>> Linux kernel is 3.19.0.
>
> Are you using Device Tree (DTS)? If yes, could you share your HECC
> configuration fragment? Aside from hecc_ck I don't see much DTS
> related info.
Are you still working on upstreaming HECC driver?
Yegor
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: ti hecc rx frames out of order
2017-01-05 9:10 ` Yegor Yefremov
2017-01-06 6:02 ` Yegor Yefremov
@ 2017-01-06 20:51 ` Grim, Dennis
1 sibling, 0 replies; 14+ messages in thread
From: Grim, Dennis @ 2017-01-06 20:51 UTC (permalink / raw)
To: linux-can
Hello Yegor,
I'm using a vendor-supplied board support package that is based on the 3.6.0 Linux kernel.
The package does not make use of the Device Tree.
Dennis
> -----Original Message-----
> From: Yegor Yefremov [mailto:yegorslists@googlemail.com]
> Sent: Thursday, January 05, 2017 3:10 AM
> To: Grim, Dennis <Dennis.Grim@teejet.com>
> Cc: linux-can@vger.kernel.org
> Subject: Re: ti hecc rx frames out of order
>
> Hi Dennis,
>
> On Fri, Dec 2, 2016 at 8:43 PM, Grim, Dennis <Dennis.Grim@teejet.com> wrote:
> > When running canfdtest on a TI AM3517 HECC, frames randomly appear out of
> order.
> >
> > "can-utils" is current (cloned this week from github)
> >
> > Linux kernel is 3.19.0.
>
> Are you using Device Tree (DTS)? If yes, could you share your HECC configuration
> fragment? Aside from hecc_ck I don't see much DTS related info.
>
> Thanks.
>
> Yegor
>
> > From host (canfdtest -vv -g can0):
> >
> > 0078: [8] ed ee ef f0 f1 f2 f3 f4
> > 0078: [8] ee ef f0 f1 f2 f3 f4 f5
> > 0078: [8] ef f0 f1 f2 f3 f4 f5 f6
> > 0078: [8] f0 f1 f2 f3 f4 f5 f6 f7
> > 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
> > Databyte 0 mismatch !
> > expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
> > received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9 Databyte 1 mismatch !
> > expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
> > received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9 Databyte 2 mismatch !
> > expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
> > received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9 Databyte 3 mismatch !
> > expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
> > received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9 Databyte 4 mismatch !
> > expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
> > received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9 Databyte 5 mismatch !
> > expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
> > received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9 Databyte 6 mismatch !
> > expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
> > received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9 Databyte 7 mismatch !
> > expected: 0078: [8] f1 f2 f3 f4 f5 f6 f7 f8
> > received: 0078: [8] f2 f3 f4 f5 f6 f7 f8 f9
> >
> > Test messages sent and received: 507377 Exiting...
> >
> > From ti hecc DUT (canfdtest -vv can2):
> >
> > 0077: [8] ed ee ef f0 f1 f2 f3 f4
> > 0077: [8] ee ef f0 f1 f2 f3 f4 f5
> > 0077: [8] ef f0 f1 f2 f3 f4 f5 f6
> > 0077: [8] f1 f2 f3 f4 f5 f6 f7 f8
> > 0077: [8] f2 f3 f4 f5 f6 f7 f8 f9
> > 0077: [8] f0 f1 f2 f3 f4 f5 f6 f7 NOTE: this line is out of order
> > 0077: [8] f3 f4 f5 f6 f7 f8 f9 fa
> > 0077: [8] f4 f5 f6 f7 f8 f9 fa fb
> > 0077: [8] f5 f6 f7 f8 f9 fa fb fc
> >
> >
> > From Peak PCAN-View:
> >
> > 99893) 594360.7 Rx 0077 8 ED EE EF F0 F1 F2 F3 F4
> > 99894) 594361.1 Rx 0078 8 EC ED EE EF F0 F1 F2 F3
> > 99895) 594361.6 Rx 0077 8 EE EF F0 F1 F2 F3 F4 F5
> > 99896) 594362.1 Rx 0078 8 ED EE EF F0 F1 F2 F3 F4
> > 99897) 594362.5 Rx 0078 8 EE EF F0 F1 F2 F3 F4 F5
> > 99898) 594363.0 Rx 0078 8 EF F0 F1 F2 F3 F4 F5 F6
> > 99899) 594363.5 Rx 0077 8 EF F0 F1 F2 F3 F4 F5 F6
> > 99900) 594363.9 Rx 0077 8 F0 F1 F2 F3 F4 F5 F6 F7
> > 99901) 594364.4 Rx 0078 8 F0 F1 F2 F3 F4 F5 F6 F7
> > 99902) 594364.9 Rx 0077 8 F1 F2 F3 F4 F5 F6 F7 F8
> > 99903) 594365.8 Rx 0077 8 F2 F3 F4 F5 F6 F7 F8 F9
> > 99904) 594366.8 Rx 0077 8 F3 F4 F5 F6 F7 F8 F9 FA
> > 99905) 594367.3 Rx 0078 8 F2 F3 F4 F5 F6 F7 F8 F9
> > 99906) 594367.8 Rx 0078 8 F3 F4 F5 F6 F7 F8 F9 FA
> > 99907) 594368.3 Rx 0077 8 F4 F5 F6 F7 F8 F9 FA FB
> > 99908) 594368.7 Rx 0078 8 F1 F2 F3 F4 F5 F6 F7 F8 NOTE: this line
> is out of order
> > 99909) 594369.2 Rx 0077 8 F5 F6 F7 F8 F9 FA FB FC
> > 99910) 594369.7 Rx 0078 8 F4 F5 F6 F7 F8 F9 FA FB
> > 99911) 594370.2 Rx 0077 8 F6 F7 F8 F9 FA FB FC FD
> >
> > I'm looking at ti_hecc.c.
> >
> > Any guidance would be very much appreciated.
> >
> > Dennis
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-can"
> > in the body of a message to majordomo@vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2017-01-06 20:51 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-02 19:43 ti hecc rx frames out of order Grim, Dennis
2016-12-04 13:07 ` Oliver Hartkopp
2016-12-07 16:55 ` Grim, Dennis
2016-12-10 14:11 ` Oliver Hartkopp
2016-12-12 15:34 ` Grim, Dennis
2016-12-12 17:01 ` Oliver Hartkopp
2016-12-12 17:17 ` Grim, Dennis
2016-12-12 18:46 ` Wolfgang Grandegger
2016-12-12 19:11 ` Wolfgang Grandegger
2016-12-14 18:44 ` Grim, Dennis
2016-12-15 7:45 ` Wolfgang Grandegger
2017-01-05 9:10 ` Yegor Yefremov
2017-01-06 6:02 ` Yegor Yefremov
2017-01-06 20:51 ` Grim, Dennis
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.