* SocketCAN stops read after RX overflow, is it normal?
@ 2015-09-02 10:17 Guillaume Picquet
2015-09-03 9:01 ` Marc Kleine-Budde
2015-09-03 9:16 ` Alexander Stein
0 siblings, 2 replies; 9+ messages in thread
From: Guillaume Picquet @ 2015-09-02 10:17 UTC (permalink / raw)
To: linux-can
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: SocketCAN stops read after RX overflow, is it normal?
2015-09-02 10:17 SocketCAN stops read after RX overflow, is it normal? Guillaume Picquet
@ 2015-09-03 9:01 ` Marc Kleine-Budde
2015-10-12 8:05 ` Guillaume Picquet
2015-09-03 9:16 ` Alexander Stein
1 sibling, 1 reply; 9+ messages in thread
From: Marc Kleine-Budde @ 2015-09-03 9:01 UTC (permalink / raw)
To: Guillaume Picquet, linux-can
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: SocketCAN stops read after RX overflow, is it normal?
2015-09-03 9:01 ` Marc Kleine-Budde
@ 2015-10-12 8:05 ` Guillaume Picquet
2015-10-12 8:54 ` Marc Kleine-Budde
0 siblings, 1 reply; 9+ messages in thread
From: Guillaume Picquet @ 2015-10-12 8:05 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can
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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: SocketCAN stops read after RX overflow, is it normal?
2015-10-12 8:05 ` Guillaume Picquet
@ 2015-10-12 8:54 ` Marc Kleine-Budde
2015-10-12 9:04 ` Guillaume Picquet
0 siblings, 1 reply; 9+ messages in thread
From: Marc Kleine-Budde @ 2015-10-12 8:54 UTC (permalink / raw)
To: Guillaume Picquet, linux-can
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: SocketCAN stops read after RX overflow, is it normal?
2015-10-12 8:54 ` Marc Kleine-Budde
@ 2015-10-12 9:04 ` Guillaume Picquet
2015-10-12 9:15 ` Marc Kleine-Budde
0 siblings, 1 reply; 9+ messages in thread
From: Guillaume Picquet @ 2015-10-12 9:04 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can
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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: SocketCAN stops read after RX overflow, is it normal?
2015-10-12 9:04 ` Guillaume Picquet
@ 2015-10-12 9:15 ` Marc Kleine-Budde
2015-10-12 9:46 ` Guillaume Picquet
0 siblings, 1 reply; 9+ messages in thread
From: Marc Kleine-Budde @ 2015-10-12 9:15 UTC (permalink / raw)
To: Guillaume Picquet, linux-can
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: SocketCAN stops read after RX overflow, is it normal?
2015-10-12 9:15 ` Marc Kleine-Budde
@ 2015-10-12 9:46 ` Guillaume Picquet
2015-10-12 9:50 ` Marc Kleine-Budde
0 siblings, 1 reply; 9+ messages in thread
From: Guillaume Picquet @ 2015-10-12 9:46 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: SocketCAN stops read after RX overflow, is it normal?
2015-10-12 9:46 ` Guillaume Picquet
@ 2015-10-12 9:50 ` Marc Kleine-Budde
0 siblings, 0 replies; 9+ messages in thread
From: Marc Kleine-Budde @ 2015-10-12 9:50 UTC (permalink / raw)
To: Guillaume Picquet, linux-can
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: SocketCAN stops read after RX overflow, is it normal?
2015-09-02 10:17 SocketCAN stops read after RX overflow, is it normal? Guillaume Picquet
2015-09-03 9:01 ` Marc Kleine-Budde
@ 2015-09-03 9:16 ` Alexander Stein
1 sibling, 0 replies; 9+ messages in thread
From: Alexander Stein @ 2015-09-03 9:16 UTC (permalink / raw)
To: Guillaume Picquet; +Cc: linux-can
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-10-12 9:50 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-02 10:17 SocketCAN stops read after RX overflow, is it normal? Guillaume Picquet
2015-09-03 9:01 ` Marc Kleine-Budde
2015-10-12 8:05 ` Guillaume Picquet
2015-10-12 8:54 ` Marc Kleine-Budde
2015-10-12 9:04 ` Guillaume Picquet
2015-10-12 9:15 ` Marc Kleine-Budde
2015-10-12 9:46 ` Guillaume Picquet
2015-10-12 9:50 ` Marc Kleine-Budde
2015-09-03 9:16 ` Alexander Stein
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.