SocketCAN stops read after RX overflow, is it normal?
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.
Marc Kleine-Budde
maintainerQuoted 3 lines · Guillaume Picquet
Hi every one.
I’m not sure to post to the correct list, if so please correct me.
100% correct.
Quoted 8 lines
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.
Quoted 7 lines
read()do not return, I've tested also withselect()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
Signature · 4 lines
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 |
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.
Quoted 30 lines · Marc Kleine-Budde
Quoted 3 lines · Guillaume Picquet
Hi every one.
I’m not sure to post to the correct list, if so please correct me.
100% correct.
Quoted 8 lines
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.
Quoted 7 lines
read()do not return, I've tested also withselect()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
Marc Kleine-Budde
maintainerQuoted 2 lines · Guillaume Picquet
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?
Quoted 5 lines
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 setSO_RXQ_OVFLflag, 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
Signature · 4 lines
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 |
Quoted 4 lines · Marc Kleine-Budde
Quoted 2 lines · Guillaume Picquet
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.cto the list?
It's your patch I gave my provider.
Quoted 9 lines
Quoted 6 lines
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 setSO_RXQ_OVFLflag, use recvmsg and check ancillary data.No, that's not correct. With
SO_RXQ_OVFLyou'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 !
Quoted 3 lines
Marc
Marc Kleine-Budde
maintainerQuoted 8 lines · Guillaume Picquet
Quoted 4 lines · Marc Kleine-Budde
Quoted 2 lines · Guillaume Picquet
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.cto the list?It's your patch I gave my provider.
Ah, good to hear that this works for your usecase aswell. Can I add your Tested-by Tag to the patch?
Quoted 11 lines
Quoted 8 lines
Quoted 5 lines
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 setSO_RXQ_OVFLflag, use recvmsg and check ancillary data.No, that's not correct. With
SO_RXQ_OVFLyou'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 withCAN_ERR_MASKset0x1FFFFFFFUit means that the hardware is handling CAN traffic well !
Yes.
Marc
Signature · 4 lines
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 |
Quoted 11 lines · Marc Kleine-Budde
Quoted 8 lines · Guillaume Picquet
Quoted 4 lines · Marc Kleine-Budde
Quoted 2 lines · Guillaume Picquet
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.cto the list?It's your patch I gave my provider.
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.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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 setSO_RXQ_OVFLflag, use recvmsg and check ancillary data.
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
No, that's not correct. With
SO_RXQ_OVFLyou'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 withCAN_ERR_MASKset0x1FFFFFFFUit means that the hardware is handling CAN traffic well !Yes.
Good.
Quoted 3 lines
Marc
Thanks
Guillaume
Marc Kleine-Budde
maintainerQuoted 8 lines · Guillaume Picquet
Quoted 5 lines · Marc Kleine-Budde
Quoted 4 lines · Guillaume Picquet
Quoted 3 lines · Marc Kleine-Budde
Quoted 2 lines · Guillaume Picquet
I've received a patched firmware from my provider, tested it and so far so good.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
Good to hear that. Can you send the patches or
at91_can.cto the list?It's your patch I gave my provider.
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
Signature · 4 lines
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 |
Hi Guillaume,
Quoted 9 lines · Guillaume Picquet
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 ?
Quoted 5 lines
read()do not return, I've tested also withselect()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
Signature · 17 lines
Dipl.-Inf. Alexander Stein SYS TEC electronic GmbH [email protected] 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