netdev - Re: [PATCH] can: add Renesas R-Car CAN driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5282A17C.1030309@cogentembedded.com>
Date:	Wed, 13 Nov 2013 00:45:32 +0300
From:	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
To:	Wolfgang Grandegger <wg@...ndegger.com>, netdev@...r.kernel.org,
	mkl@...gutronix.de, linux-can@...r.kernel.org
CC:	linux-sh@...r.kernel.org, vksavl@...il.com
Subject: Re: [PATCH] can: add Renesas R-Car CAN driver

Hello.

On 11/09/2013 04:02 AM, Sergei Shtylyov wrote:

>>>> 2. ... with short-circuited CAN high and low and doing some time later
>>>>          a manual recovery with "ip link set can0 type can restart"

>>>     Now we have auto recovery only. Manual recovery was tested with the
>>> first driver version and worked.

>> What do you mean with "auto recovery"? Auto recovery by the hardware or
>> via "restart-ms <ms>"? How do you choose between "manual" and "auto"
>> recovery?

>     This exact test was done with hardware auto-recovery only. No "restart-ms"
> was programmed.

>>> Terminal 1:

>>> root@...0.0.104:/opt/can-utils# ./cangen -n 1 -g 1 can0
>>> root@...0.0.104:/opt/can-utils# ./cangen -n 1 -g 1 can0
>>> root@...0.0.104:/opt/can-utils# ./cangen -n 1 -g 1 can0
>>> root@...0.0.104:/opt/can-utils#

>>> Terminal 2:

>>> root@...0.0.104:/opt/can-utils# ./candump -td -e any,0:0,#FFFFFFFF
>>> (000.000000) can0 2000008C [8] 00 00 08 00 00 00 00 00 ERRORFRAME
>>> controller-problem{}
>>> protocol-violation{{tx-dominant-bit-error}{}}
>>> bus-error
>>> (000.021147) can0 20000144 [8] 00 00 00 00 00 00 00 00 ERRORFRAME
>>> controller-problem{}
>>> bus-off
>>> restarted-after-bus-off

>> Why does it get "restarted" directly after the bus-off?

>     Because we have hardware auto-recovery enabled.

>>> (011.738522) can0 2000008C [8] 00 00 08 00 00 00 00 00 ERRORFRAME
>>> controller-problem{}

>> What controller problem? data[1] is not set for some reasom.

>     Not comments. Looking into it.

    Sorry, this has been fixed a while ago. Now the log looks like:

root@...0.0.104:/opt/can-utils#  ./candump -td -e any,0:0,#FFFFFFFF
  (000.000000)  can0  2000008C   [8]  00 28 08 00 00 00 88 00 ERRORFRAME
         controller-problem{tx-error-warning,tx-error-passive}
         protocol-violation{{tx-dominant-bit-error}{}}
         bus-error
         error-counter-tx-rx{{136}{0}}
  (000.007578)  can0  20000040   [8]  00 00 00 00 00 00 00 00 ERRORFRAME
         bus-off
  (000.091847)  can0  20000100   [8]  00 00 00 00 00 00 00 00 ERRORFRAME
         restarted-after-bus-off
  (056.136722)  can0  2000008C   [8]  00 28 08 00 00 00 88 00 ERRORFRAME
         controller-problem{tx-error-warning,tx-error-passive}
         protocol-violation{{tx-dominant-bit-error}{}}
         bus-error
         error-counter-tx-rx{{136}{0}}

>>> dmesg:
>>> rcar_can rcar_can.0 can0: Error warning interrupt
>>> rcar_can rcar_can.0 can0: Error passive interrupt
>>> rcar_can rcar_can.0 can0: Bus error interrupt:
>>> rcar_can rcar_can.0 can0: Bit Error (dominant)
>>> rcar_can rcar_can.0 can0: Error warning interrupt
>>> rcar_can rcar_can.0 can0: Error passive interrupt

>> Why are they reported again. You are already in error passive.

>     Don't know. :-/

    This also has been dealt with. Here's an example:

rcar_can rcar_can.0 can0: Bus error interrupt:
rcar_can rcar_can.0 can0: ACK Error
rcar_can rcar_can.0 can0: Error warning interrupt
rcar_can rcar_can.0 can0: Bus error interrupt:
rcar_can rcar_can.0 can0: ACK Error
rcar_can rcar_can.0 can0: Error passive interrupt

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html