Re: socket can receive order

[Marc Kleine-Budde <mkl@pengutronix.de>]

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

On 09/08/2015 12:41 PM, Daniel Squires wrote:
> On my laptop and Desktop PC I have not seen it happen.

> Both the application PC (NUC) and the Laptop are running Ubuntu kernel 
> 3.19.0-26-generic
> 
> The NUC has the kernel rebuilt without xhci due to problems it causes 
> with another USB peripheral.
> 
> I am not entirely sure what you mean by which can core I am using but if 
> it helps i am opening the socket as follows :

I mean what kind of CAN adapter...

> 
>      sock = socket(PF_CAN,SOCK_RAW,CAN_RAW);
> 
> in a small standalone test application which I wrote after having 
> difficulty with our main application.
> 
> I am using custom hardware/firmware and am using the kernel module found 
> here : https://github.com/fabiobaltieri/open-usb-can
> though it has a small change to stop the net queue at the top of 
> open_usb_can_start_xmit as otherwise its prone to loosing TX packets 
> when loaded.

Yes, this looks racy - You should ask then to mainline working the driver.

> I can see the packets coming in the correct order in wireshark and it is 
> not immediately obvious to me how the kernel module could mix up the 
> order, so it seems that it must be something that happens at the socket 
> level?

The kernel module "produces" the CAN frames, so if you see them in the
correct order in wireshark, they have left the module in the right order.

> candump can3 -tz
> <snip>
>   (003.088648)  can3  043   [8]  F7 2D 00 00 00 00 00 00
>   (003.089149)  can3  045   [8]  F9 2D 00 00 00 00 00 00
>   (003.088897)  can3  044   [8]  F8 2D 00 00 00 00 00 00

The timestamps are in the correct order. Maybe Oliver can help here,
he's an expert when it comes to strange reordering :)

> On the top level I am using CANFestival for CANOpen implementation, so 
> it has occurred to me I could implement a CANFestival "driver" using 
> libusb and completely bypass the kernel module and socket can layers, 
> but I hope not to have to do this.

Na, you don't want to do this.

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