netdev - Re: [PATCH] can: kvaser_usb: Add support for Kvaser CAN/USB devices

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sun, 05 Aug 2012 22:43:55 +0200
From:	Wolfgang Grandegger <wg@...ndegger.com>
To:	Marc Kleine-Budde <mkl@...gutronix.de>
CC:	Olivier Sobrie <olivier@...rie.be>, linux-can@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH] can: kvaser_usb: Add support for Kvaser CAN/USB devices

On 08/02/2012 01:56 PM, Marc Kleine-Budde wrote:
> On 08/02/2012 12:53 PM, Olivier Sobrie wrote:
...
>> I actually implemeted it as you said and here is what I observed in
>> candump output with restart_ms set to 100 ms:
>>
>> t0: Short circuit between CAN-H and CAN-L + cansend can1 123#1122
>>   can1  2000008C  [8] 00 04 90 00 00 00 00 00   ERRORFRAME
>> 	controller-problem{rx-error-warning}
>> 	protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
>> 	bus-error
>>   can1  2000008C  [8] 00 10 90 00 00 00 00 00   ERRORFRAME
>> 	controller-problem{rx-error-passive}
>> 	protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
>> 	bus-error
>>   can1  200000C8  [8] 00 00 90 00 00 00 00 00   ERRORFRAME
>> 	protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
>> 	bus-off
>> 	bus-error
>> ...

FYI, the option "-td" nicely shows the timing. I assume that the
"warning->passive->bus-off" sequence repeats because automatic bus-off
is active via ip option "restart-ms xx ms". What I'm missing is the
message "restarted-after-bus-off". Maybe it's not listed here...

>>   can1  2000008C  [8] 00 04 90 00 00 00 00 00   ERRORFRAME
>> 	controller-problem{rx-error-warning}
>> 	protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
>> 	bus-error
>>   can1  2000008C  [8] 00 10 90 00 00 00 00 00   ERRORFRAME
>> 	controller-problem{rx-error-passive}
>> 	protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
>> 	bus-error
>>   can1  200000C8  [8] 00 00 90 00 00 00 00 00   ERRORFRAME
>> 	protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
>> 	bus-off
>> 	bus-error
>>
>> t1: short circuit removed
>>   can1  123  [2] 11 22
>>   can1  20000100  [8] 00 00 00 00 00 00 00 00   ERRORFRAME
>> 	restarted-after-bus-of
>>
>> The echo coming before the restart looks weird? No?

Yes. It should come later.

>> Shouldn't we drop the frame once BUF-OFF is reached?

No.

> No, I don't think so. But wait for Wolfgang, here's more into error
> handling then me.

Looking to your code it's not clear to me how you do recovery from
bus-off (called "restart"). This is usually done via
do_set_mode(CAN_MODE_START), either manually (restart-ms==0) or
automatically (restart-ms>0). Could you please explain how the device
does bus-off recovery? Does the hardware do it automatically? This
should be suppressed if if restart-ms==0 (as Marc already pointed out).

Wolfgang.

--
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