christian pellegrin wrote: > 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.
Is that really true. The manual states that an interrupt is generated when the TXREQ bit will be cleared, which is the case for OSM after the message has been sent. Otherwise it's a bad design flaw. But I might have misinterpreted chapter 3.3. It would make sense to contact National Instruments. >> 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. Yes, or at least do not add additional code. We need some more experience with one-shot mode .. > 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 ... and a patch for interested people would be nice, indeed. > 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 But that's the same with all other CAN controllers. It's normal CAN behavior. > 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. Reporting as much errors as possible to the user space is always a good thing allowing the user/app to catch them and act upon (e.g. stop the device). The hardware retrying to send a message is normal and I do not see any need for a special treatment, especially not just by one driver. >> 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. Yes, that would be a possible solution. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
