It could be trying to load a mixture of the "staging" comedi modules
from your distro's kernel package and the "
comedi.org" comedi modules
built by yourself. The binary interfaces between the two sources of
modules are not compatible with each other.
You can check where modules are loaded from with the 'modinfo' command:
/sbin/modinfo comedi | head -n 1
/sbin/modinfo adl_pci7250 | head -n 1
Those print the first line of the modinfo output, indicating the full
filename of the module. If the filename includes the sub-path
"kernel/drivers/staging/comedi", the module will be coming from the
distro's kernel package (or from any other kernel built with comedi
included). Otherwise the module will be loaded from the your self-built
and installed comedi installation. The key thing is you don't want any
of the comedi modules to be loaded from "staging" for your tests.
I think the self-build comedi modules used to be installed in
"/lib/modules/${KERNEL_VER}/kernel/comedi/" by default, but I just tried
it on my Debian system and they got installed to
"/lib/modules/${KERNEL_VER}/comedi/". However, if you install the
modules with the DKMS system, I think they get installed to
"/lib/modules/${KERNEL_VER}/updates/comedi/".
If necessary, you can change the search order for modules by creating a
file in the /etc/depmod.d/ directory with the .conf extension (e.g.
"/etc/depmod.d/mysearch.conf") and adding the following line:
search comedi updates built-in
Then running "depmod -a" as root (or "sudo depmod -a").
I'm planning to submit a driver module to the Linux kernel so you won't
have to use the self-built driver from
comedi.org. However, it would be
nice to see if the one from
comedi.org works properly first. In any
case, it would be several months before the submitted driver trickled
through to the mainline Linux sources and it wouldn't get back-ported to
older kernels.