pcan-pci problem with intel atom?

[wlt]

We have been using the pcan-pci with VIA C7 motherboards from Jetway for several years with no problems. I'm using the 6.11 peak-linux driver with kernel v2.6.24, mainly because it has worked flawlessly so why update?...
The Jetway C7 boards are becoming very difficult to buy so I have been looking at alternatives - the Intel Atom C2700 looked interesting so I have been evaluating it with our application.
The system is basically a data acquisition system with the main application (on the C7 box) talking to slave units on the CAN bus.
There seems to be a problem, which I have not been able to identify. I have tried both the v6.11 and also the v7.5 drivers and both seem to have problems on this hardware. I'm getting lots of status=128 errors from calls to LINUX_CAN_Write_Timeout(). These do not occur with the C7 boards, but they happen every couple of minutes with the Atom boards. The only way I have found to recover from the error is to completely reinitialize the CAN interface. This is causing big problems because we are running the CAN bus at close to maximum bandwidth and the time needed to reinitialize makes the system miss samples from the slaves.
Has anyone else seen this problem? I'm running out of ideas and would appreciate any advice.
thanks,
wlt

[M.Maidhof]

Hi,

when the returnvalue of LINUX_CAN_Write_Timeout() is 128, the driver will tell you that the XMTQueue is full. This will happen, when you want to transmit more messages than the CAN bus could handle, or when there was an error (BusOff), and the CAN-Controller on the PCAN-PCI card will stop transmitting messages on the bus.

To get behind the problem, we must verify what happened in that moment. As a first test, please check the status of the PCAN-PCI card, (call cat /proc/pcan) and check for the displayed errrors. It will also be helpfull to check for status messages with CAN_Read().

When there are no errors available, we can try to increase the XMTQueue in the driver. You can modify the size of the buffers in pcan_main.h see line 131:

#define READBUFFER_SIZE 80 // buffers used in read and write call
#define WRITEBUFFER_SIZE 80

rebuild and reload the driver, so that the changes can take effect.

It could also be a problem of the used IRQ on the board. Please check which IRQ is used by the PCAN-PCI card (cat /proc/interrupts). Changing the PCI slot or disable other not used devices in the BIOS will help, when there are to much devices uses the same IRQ.

regards

Michael

[wlt]

Michael,
Thanks for the information. I have been busy with another project and am just now getting back to this.
I will try the things you suggested and let you know what happens.
thanks,
larry

[wlt]

Michael,
Well, it is not absolutely fixed, but increasing the buffer sizes seems to have made it much better.
I'm now seeing about one error per hour on the atom-based board. This is down from something like one error per minute. We can probably live with this rate...
By the way, I just noticed a typo in my original posting - the board I'm using is an Intel D2700-MUD.
Thanks for the help.
wlt

[jhfrontz]

I'm not sure if your problem is the same as the one we encountered (on driver version 6.5, kernel 2.6.23), but it sounds similar-- every so often there is a missing transmit interrupt (which causes all out-bound traffic to stop and new outbound messages to get queued, eventually causing a transmit buffer overflow). This seemingly happens exclusively when the system is under heavy load.

Our fix is to have the transmitting process check the write queue-- if it ever went above a certain length, the software tickles the DataSendReady and gets things rolling again.

Since adding this, we've never seen the transmit buffer overrun (unless there is truly a hardware problem on the bus).