Thanks for the feedback.

I forgot to say that I'm running at 250K
After my last post I have tried the version that is included in kernel
2.6.35 and I will try to continue with that version unless someone suggest
that I should use the SVN Rev 1123 or the version from kernel 2.6.34.

Apparently fewer out of order messages, but still some. Even after removing
the "free one buffer ASAP".

I have to do some reading in the datasheet, but I guess I will try to
disable the rollover as a starting point.

I have hardware at the moment so please let me know if I can help with some
testing.


Thanks
Benny

2010/8/6 christian pellegrin <[email protected]>

> On Fri, Aug 6, 2010 at 3:56 PM, Wolfgang Grandegger <[email protected]>
> wrote:
> > To be clear, out-of-order messages are also not OK.
>
> Yes I was looking at this with some interleave analysis. I think the
> problem lies in the following race:
>
> // suppose we come here with RXB0 filled with packet X
>                u8 intf = mcp251x_read_reg(spi, CANINTF);
>                u8 eflag;
>                int can_id = 0, data1 = 0;
>
> // packet X+1 arrives and lands in RXB1
>
>                if (intf & CANINTF_RX0IF) {
>                        mcp251x_hw_rx(spi, 0);
>                        /* Free one buffer ASAP */
>                        mcp251x_write_bits(spi, CANINTF, intf &
> CANINTF_RX0IF,
>                                           0x00);
>                }
>
> // packet X+2 arrives and lands in RXB0
> // unfortunately variable intf is old and doesn't show that we have
> something in RXB1
> // (*1)
>                if (intf & CANINTF_RX1IF)
>                        mcp251x_hw_rx(spi, 1);
>
> now on the next turn we will have packet X+2 in RXB0 and X+1 in RXB1
> so we read them out-of-order. The easiest way to solve the problem is
> to take out the line:
>
>                        /* Free one buffer ASAP */
>                        mcp251x_write_bits(spi, CANINTF, intf &
> CANINTF_RX0IF,
>                                           0x00);
>
> but we risk to lose more packets. Perhaps also rereading intf in (*1)
> could work but we must be careful when we reset CANINTF register to
> not lose an interrupt for RXB0. I will do some tests but after next
> week because I don't have the access to the hardware until then.
>
> --
> Christian Pellegrin, see http://www.evolware.org/chri/
> "Real Programmers don't play tennis, or any other sport which requires
> you to change clothes. Mountain climbing is OK, and Real Programmers
> wear their climbing boots to work in case a mountain should suddenly
> spring up in the middle of the computer room."
>
_______________________________________________
Socketcan-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-users

Reply via email to