On Mon, Feb 1, 2010 at 5:38 PM, Oliver Hartkopp <[email protected]> wrote:
> Especially OSM is "fire-and-forget" by design. Busy-Waiting on application
> level for OSM messages looks strange to me. What would happen in multi-user
> applications then?
>
Perhaps I didn't explain well. Nothing would change for user level
applications except that some of their packets could be silently
discarded (but counted in the interface error counters). The user
level write will see less ENOBUFS actually.
>
> As i understood the situation, you do not get any interrupt when the OSM
> transmission fails on the bus, right?
>
Exactly. To be more precise: there is no way to have an interrupt on
"lost of arbitration" with OSM on.
> Then i would tend to remove the OSM functionality as long as the driver is not
> able to handle the descibed problem in OSM mode on the bus.
>
I can do it and have a separate patch om my site if someone needs the
OSM. Paul told me that his user-case is that he doesn't want to have
the mcp2515 trying to resend the packet for many times if no one is
responding. I can see the problem: when this happens also other
packets are stalled on the tx queue. I could implement the use of all
the three TX buffer but the problem is just moved forward if we have 3
pending packets with no one responding. Another thing we could do is
catch MERR interrupt (which should encompass acknowledge errors and so
missing partner situation too) and give up transmission after a given
number of retries. Any other suggestion on how to solve this problem
would be appreciated. I'm not a CAN expert and unfortunately all of my
customer user-cases are using CAN as a cheap and noise resistant
replacement for ethernets or having a can chip on-board to comply to
some call for bidding, so I really don't know which is the right thing
(tm) to do in these cases.
> Regarding the missing tx interrupt the use of the "standard netdev tx timeout"
> IMO could be the right approach to catch this *special* MCP251x problem. Btw.
In the early versions it worked this way to avoid the trouble described above.
>> - netif_wake_queue(net);
>> + if (!(priv->can.ctrlmode & CAN_CTRLMODE_ONE_SHOT)) {
>> + netif_wake_queue(net);
>> + }
>
> Ugh! ;-)
>
huh, didn't run checkpatch.pl yet ..... coding habits are hard to die,
I guess I picked-up the "{} always after if" when was doing perl
programming for a living. ;-)
--
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-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
