Peak CAN PCI fails to load at boot time

Hardware

• PCI slot-CPU, Advantech PCI-7031N-S6A1E using an Atom N450
• passive backplane, two other PCI cards
• PCI dual CAN can, Peak model IPEH-002067

Software

• "vanilla" kernel 3.8.8, .config
• current Peak driver 7.14 and 7.15.1-beta , make NET=NO DBG=DEBUG DNG=NO PAR=NO USB=NO ISA=NO all

failure of module load

• module load causes kernel 'oops', however, kernel is intact enough to login remotely
• after some debugging: module fails at second call of sja1000_probe() dmesg of Peak beta driver
• the CAN driver shipped in the vanilla kernel loads without problems (however it wasn't tested with traffic yet)

bits of insight

• Without PCIe , the Peak PCI module crashed with kernel-oops at load, even if no PCIe card is used.
• When compiling a the Peak CAN module outside the kernel, the Peak PCI-express part gets silently skipped if "I2C_ALGOBIT" isn't set in kernel.
  Apparently, I2C_ALGOBIT is deselected, if the default "Autoselect pertinent helper modules" is configured.
  a gcc "#warning" for this case to pcan_common.h , line 116 , might come in useful.
• The Peak driver stalls at the first of two CAN interfaces and bails out at module load. Apparently, this renders a redundant second interface inaccessible, even if that SJA1000 is still working.
• The Peak driver peak-linux-driver-X.YY.tar.gz differs quite a bit from source contribution of Peak GmbH to the vanilla kernel. Technically they are mutually exclusive at load time. However, they are apparently supported by two different teams, so the support framework differs quite a bit. Mind that this company offers nothing but CAN solution and high-end software, so to their 1st-level-support, a kernel related problem may seem a bit "off-road".
• Peak fist level support had been not very kernel-savvy, especially when running a kernel on a small embedded system:
  No folks, we can't run "a CD image of Ubuntu to have the same kernel options" on an embedded, remote system.
  And yes, I think any kernel module should care about kernel options.
  And yes, it would just be subjectively nice not to be told "go away, your config sucks" when submitting a patch to your source that makes compiling more reliable.
• Conclusively, in a bare-metal environment, the vanilla kernel CAN framework seems a more suitable choice then the Peak stand-alone driver.
  Since it supports more vendors, there's less reliance on a single company and varying levels of their support.

solution

text and images are under the GNU_Free_Documentation_License.