On 10/12/2010 07:11 PM, "Müller, René" wrote: > Am 12.10.2010 12:53, schrieb Michal Sojka: >> On Mon, 11 Oct 2010, Wolfgang Grandegger wrote: >>> On 10/11/2010 05:01 PM, "Müller, René" wrote: >>>> Now we have two cases, one with missing frames and one without: >>>> Case 1: >>>> - candump -l -s2 can0 -> logging in an file which is stored in RAM >>>> - we get all messages in the logfile >>>> >>>> Case 2: >>>> - candump -l -s2 can0 -> logging in an file which is stored on an >>>> CompactFlash-card >>>> - the CF-card is connected via the IDE-interface without DMA (we don't >>>> get DMA working with the CF-card, unfortunately it only works with >>>> harddrives) >>>> - we are loosing messages: >>>> - every 35s we are missing messages in blocks, never we are missing 1 >>>> message, always 5-6 at once >>>> >>>> Anyone had similar problems? Any hints? >>> >>> Sounds like a receive buffer overrun when the application is not able to >>> read messages fast enough. You could use setsockopt(... ,SOL_SOCKET, >>> SO_RCVBUF, ....) to increase the buffer size. It's also possible to >>> detect dropped CAN frames as described here: >> >> I'm not sure whether this is receive buffer overrun. AFAIK 5200 has some >> problems with ATA. People using 5200 with CF complain about hudge >> latencies caused by ATA interrupts. I do not know whether this is >> related to using DMA or not. >> > > This sounds like our problem. As I wrote in the other mail, we only loose > frames, if we have IDE-traffic. > > Do you know anyone with an solution to the high latencies caused by IDE > interrupts? > >> The CAN controller on 5200 has hardware buffers only for 2 messages. The >> driver reads the received messages in soft-irq so if the soft-irq is >> delayed you loose the mesasges because of hardware buffer overruns. I >> gess this is very likely especially if you use CF. >> > > I don't think so. If we use candump with the '-d' option it reports dropped > frames. These frames are dropped of the buffer in the kernel, so the frames > are already read out of the hardware buffers. Maybe I'm wrong on this, but > this is how I understand it.
You are right. Frames are dropped if they could not be delivered into the RX socker buffer. Furthermore, with "candump any,0:0,#FFFFFFFF" you should see an error messages if the CAN controller hardware did drop messages. Maybe both does happen when CF activity blocks the task and softirq handling for a too long time. >> We were able to avoid losing messages by reading them in hard-irq >> context (with lincan driver), but I'm not sure whether this will help if >> you use CF (we do not use it). > > What's this lincan driver? I found it on sourceforge, but it seems to lack > MPC5200-support. In addition we are happy with socketcan, but if we are stuck > with bad hardware (MPC5200), we are open to every chance... It's one of many character device drivers for CAN. It's not an option, I assume. Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
