Hi, On Mon, Nov 9, 2009 at 9:27 PM, Christian Keydel <[email protected]> wrote: > > > Can someone give me any hints on how to troubleshoot this? Is there any > debug output available that could help? Right now I don't even know at which > level the frames are dropped. >
Just some notes about the performance issue. I had similar problems on a system using both a MAX3100 and the MCP2510 (which is worse than MCP2515) on the same Samsung S3C2440 SPI interface. Unfortunately hardware designer love SPI peripherals because they are cheap, need a small number of wires to connect and eat a small number of GPIOs on the SOC (3 + no. of devices). On the other hand they are not suited for high speed operations. After some analysis I found the following culprits of low performance: 1) many architectures offer very low performance SPI master device drivers especially in the mainline kernel. They are used for really small transfer of data, for example reading/writing some eeprom chips. Many times there are just bit-banging type of drivers or use workqueues. 2) SPI device type drivers often use worqueues. This i for a simple reason: they could block on every SPI I/O and it's quite tricky to understand where in the Linux kernel you can block safely (you get the oops "trying to sleep in an atomic context" quite often if you use SPI naively calls in kernelspace). The easiest solution is using workqueues, otherwise one should structure the driver as a state machine (the kernel doesn't provide cool constructs like coroutines). The real problem is that workqueues compete on the scheduler as normal user space process do. I kind of solved the problems and published the results here: http://www.evolware.org/chri/paciugo/ because I feel they won't be suitable for mainline inclusion. Now the system can sustain 115200 serial communication and reasonable CAN traffic without much loss. Anyway keep in mind that you will never get great results, think about a chip connected via a local bus for those (pci is even better). For every byte transfered via SPI you have an interrupt, a small ARM system starts showing problems with 10000-5000 interrupts per second in my experience. And, as outlined on the page, DMA is not an option at least on the platform I used. That said, it can always be a driver bug, so I'm happy to help you in doing more tests. I'll try to setup a system for testing myself ASAP. As Wolfgang said, pay attention to CAN statistics. Hardware RX buffer overruns and dropped frames due to skb shortage should be correctly counted in the driver. Check both CAN and ifconfig statistics and please report them. HTH, -- 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
