SocketCAN stops read after RX overflow, is it normal?

SocketCAN stops read after RX overflow, is it normal?

[Guillaume Picquet]

Hi every one.

I’m not sure to post to the correct list, if so please correct me.

I’m doing tests on embedded hardware with integrated CAN bus interface 
(based on AT91). The driver provides Linux Socket API and I try to see 
the limits:
I have one transmitter that writes CAN frames (CAN_RAW) as fast as 
possible and a receiver that reads continuously.
After a moment the receiver gets an error frame signalling RX overflow. 
I have no problem with that, it's normal and expected.
But question is why at this point no more frame is received ?

read() do not return, I've tested also with select() which return timeout.
(The restart-ms option is set)

I expected some dropped frames and others RX buffer errors but not the 
end of reception.

The only way to recover the interface is to set it down and up again.

Thanks in advance.

Regards.

Re: SocketCAN stops read after RX overflow, is it normal?

[Marc Kleine-Budde]

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

On 09/02/2015 12:17 PM, Guillaume Picquet wrote:
> Hi every one.
> 
> I’m not sure to post to the correct list, if so please correct me.

100% correct.

> I’m doing tests on embedded hardware with integrated CAN bus interface 
> (based on AT91). The driver provides Linux Socket API and I try to see 
> the limits:
> I have one transmitter that writes CAN frames (CAN_RAW) as fast as 
> possible and a receiver that reads continuously.
> After a moment the receiver gets an error frame signalling RX overflow. 
> I have no problem with that, it's normal and expected.
> But question is why at this point no more frame is received ?

It's probably a bug in the driver.

> read() do not return, I've tested also with select() which return timeout.
> (The restart-ms option is set)
> 
> I expected some dropped frames and others RX buffer errors but not the 
> end of reception.
> 
> The only way to recover the interface is to set it down and up again.

Try the patches I send you in the other mail. They switch the at91 to
the new infrastructure. Some generic testing show good results, but it
seems you have a harder/better test case.

Hope that helps, please keep us informed,
Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: SocketCAN stops read after RX overflow, is it normal?

[Alexander Stein]

Hi Guillaume,

On Wednesday 02 September 2015 12:17:44, Guillaume Picquet wrote:
> I’m doing tests on embedded hardware with integrated CAN bus interface 
> (based on AT91). The driver provides Linux Socket API and I try to see 
> the limits:
> I have one transmitter that writes CAN frames (CAN_RAW) as fast as 
> possible and a receiver that reads continuously.
> After a moment the receiver gets an error frame signalling RX overflow. 
> I have no problem with that, it's normal and expected.
> But question is why at this point no more frame is received ?
> 
> read() do not return, I've tested also with select() which return timeout.
> (The restart-ms option is set)
> 
> I expected some dropped frames and others RX buffer errors but not the 
> end of reception.

Maybe you are hitting the same problem as I was last year: http://marc.info/?l=linux-can&m=141225364212703&w=2
It seems the at91_can driver hasn't changed essentially since that time. So please give the patches Marc sent today a try.

Best regards,
Alexander
-- 
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.stein@systec-electronic.com

Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany

Office: +49 (0) 3765 38600-0
Fax:    +49 (0) 3765 38600-4100
 
Managing Directors:
	Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
	Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
	Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010

Re: SocketCAN stops read after RX overflow, is it normal?

[Guillaume Picquet]

Hi Marc,

I've received a patched firmware from my provider, tested it and so far 
so good.
I've connected 2 devices (AT91 based) at 1Mb/s.
So far more than 470000000 frames received so far.
 From the user-space point of view it's much better.
Now the only way to know if rx overflow occur is to set SO_RXQ_OVFL 
flag, use recvmsg and check ancillary data.

Regards

Guillaume.

Le 03/09/2015 11:01, Marc Kleine-Budde a écrit :
> On 09/02/2015 12:17 PM, Guillaume Picquet wrote:
>> Hi every one.
>>
>> I’m not sure to post to the correct list, if so please correct me.
> 100% correct.
>
>> I’m doing tests on embedded hardware with integrated CAN bus interface
>> (based on AT91). The driver provides Linux Socket API and I try to see
>> the limits:
>> I have one transmitter that writes CAN frames (CAN_RAW) as fast as
>> possible and a receiver that reads continuously.
>> After a moment the receiver gets an error frame signalling RX overflow.
>> I have no problem with that, it's normal and expected.
>> But question is why at this point no more frame is received ?
> It's probably a bug in the driver.
>
>> read() do not return, I've tested also with select() which return timeout.
>> (The restart-ms option is set)
>>
>> I expected some dropped frames and others RX buffer errors but not the
>> end of reception.
>>
>> The only way to recover the interface is to set it down and up again.
> Try the patches I send you in the other mail. They switch the at91 to
> the new infrastructure. Some generic testing show good results, but it
> seems you have a harder/better test case.
>
> Hope that helps, please keep us informed,
> Marc
>

Re: SocketCAN stops read after RX overflow, is it normal?

[Marc Kleine-Budde]

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

On 10/12/2015 10:05 AM, Guillaume Picquet wrote:
> I've received a patched firmware from my provider, tested it and so far 
> so good.

Good to hear that. Can you send the patches or at91_can.c to the list?

> I've connected 2 devices (AT91 based) at 1Mb/s.
> So far more than 470000000 frames received so far.
>  From the user-space point of view it's much better.
> Now the only way to know if rx overflow occur is to set SO_RXQ_OVFL 
> flag, use recvmsg and check ancillary data.

No, that's not correct. With SO_RXQ_OVFL you'll detect overflows of the
socket. When there are overflows in the hardware the rx overrun in per
device statistics will be increased (see ifconfig) output.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: SocketCAN stops read after RX overflow, is it normal?

[Guillaume Picquet]

Le 12/10/2015 10:54, Marc Kleine-Budde a écrit :
> On 10/12/2015 10:05 AM, Guillaume Picquet wrote:
>> I've received a patched firmware from my provider, tested it and so far
>> so good.
> Good to hear that. Can you send the patches or at91_can.c to the list?
It's your patch I gave my provider.

https://git.kernel.org/cgit/linux/kernel/git/mkl/linux-can-next.git/commit/?h=at91-next&id=7234e9dee7d0df75de7ae14443a2306435750594
>
>> I've connected 2 devices (AT91 based) at 1Mb/s.
>> So far more than 470000000 frames received so far.
>>   From the user-space point of view it's much better.
>> Now the only way to know if rx overflow occur is to set SO_RXQ_OVFL
>> flag, use recvmsg and check ancillary data.
> No, that's not correct. With SO_RXQ_OVFL you'll detect overflows of the
> socket. When there are overflows in the hardware the rx overrun in per
> device statistics will be increased (see ifconfig) output.
Ok good to know.
So your saying that if I receive nothing on a socket with CAN_ERR_MASK 
set 0x1FFFFFFFU it means that the hardware is handling CAN traffic well !
>
> Marc
>

Re: SocketCAN stops read after RX overflow, is it normal?

[Marc Kleine-Budde]

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

On 10/12/2015 11:04 AM, Guillaume Picquet wrote:
> Le 12/10/2015 10:54, Marc Kleine-Budde a écrit :
>> On 10/12/2015 10:05 AM, Guillaume Picquet wrote:
>>> I've received a patched firmware from my provider, tested it and so far
>>> so good.
>> Good to hear that. Can you send the patches or at91_can.c to the list?
> It's your patch I gave my provider.
> 
> https://git.kernel.org/cgit/linux/kernel/git/mkl/linux-can-next.git/commit/?h=at91-next&id=7234e9dee7d0df75de7ae14443a2306435750594

Ah, good to hear that this works for your usecase aswell. Can I add your
Tested-by Tag to the patch?

>>> I've connected 2 devices (AT91 based) at 1Mb/s.
>>> So far more than 470000000 frames received so far.
>>>   From the user-space point of view it's much better.
>>> Now the only way to know if rx overflow occur is to set SO_RXQ_OVFL
>>> flag, use recvmsg and check ancillary data.
>> No, that's not correct. With SO_RXQ_OVFL you'll detect overflows of the
>> socket. When there are overflows in the hardware the rx overrun in per
>> device statistics will be increased (see ifconfig) output.
> Ok good to know.
> So your saying that if I receive nothing on a socket with CAN_ERR_MASK 
> set 0x1FFFFFFFU it means that the hardware is handling CAN traffic well !

Yes.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: SocketCAN stops read after RX overflow, is it normal?

[Guillaume Picquet]

Le 12/10/2015 11:15, Marc Kleine-Budde a écrit :
> On 10/12/2015 11:04 AM, Guillaume Picquet wrote:
>> Le 12/10/2015 10:54, Marc Kleine-Budde a écrit :
>>> On 10/12/2015 10:05 AM, Guillaume Picquet wrote:
>>>> I've received a patched firmware from my provider, tested it and so far
>>>> so good.
>>> Good to hear that. Can you send the patches or at91_can.c to the list?
>> It's your patch I gave my provider.
>>
>> https://git.kernel.org/cgit/linux/kernel/git/mkl/linux-can-next.git/commit/?h=at91-next&id=7234e9dee7d0df75de7ae14443a2306435750594
> Ah, good to hear that this works for your usecase aswell. Can I add your
> Tested-by Tag to the patch?
Yes why not, But I can not guarantee that my provider did not modify the 
patch.
>
>>>> I've connected 2 devices (AT91 based) at 1Mb/s.
>>>> So far more than 470000000 frames received so far.
>>>>    From the user-space point of view it's much better.
>>>> Now the only way to know if rx overflow occur is to set SO_RXQ_OVFL
>>>> flag, use recvmsg and check ancillary data.
>>> No, that's not correct. With SO_RXQ_OVFL you'll detect overflows of the
>>> socket. When there are overflows in the hardware the rx overrun in per
>>> device statistics will be increased (see ifconfig) output.
>> Ok good to know.
>> So your saying that if I receive nothing on a socket with CAN_ERR_MASK
>> set 0x1FFFFFFFU it means that the hardware is handling CAN traffic well !
> Yes.
Good.
>
> Marc
>
Thanks

Guillaume

Re: SocketCAN stops read after RX overflow, is it normal?

[Marc Kleine-Budde]

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

On 10/12/2015 11:46 AM, Guillaume Picquet wrote:
> 
> 
> Le 12/10/2015 11:15, Marc Kleine-Budde a écrit :
>> On 10/12/2015 11:04 AM, Guillaume Picquet wrote:
>>> Le 12/10/2015 10:54, Marc Kleine-Budde a écrit :
>>>> On 10/12/2015 10:05 AM, Guillaume Picquet wrote:
>>>>> I've received a patched firmware from my provider, tested it and so far
>>>>> so good.
>>>> Good to hear that. Can you send the patches or at91_can.c to the list?
>>> It's your patch I gave my provider.
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/mkl/linux-can-next.git/commit/?h=at91-next&id=7234e9dee7d0df75de7ae14443a2306435750594
>> Ah, good to hear that this works for your usecase aswell. Can I add your
>> Tested-by Tag to the patch?
> Yes why not, But I can not guarantee that my provider did not modify the 
> patch.

Thanks,
Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]