asterisk users - Jan 2011 - problems inserting dahdi modules using Debian Leni

Hi.  I have a Debian Leni system  with asterisk-1.8.  I was trying to
get meetme to work and it depends on dahdi, so I compiled dahdi-trunk
and dahdi-tools-trunk, however, when trying to insert dahdi_dummy, it
complained about symbol crc_ccitt_table, although the module was
actually there in the kernel tree.  So, I took the Debian source, and I
had the config and I did make Bzimage, make modules and make
modules_install, but dahdi_dummy still complains about the same symbol,
it says no version for that symbol, so I am confused as to how to
resolve this so I can modprobe dahdi_dummy properly.

Any ideas would be appreciated.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici at ccs.covici.com

On 01/04/2011 05:09 PM, covici at ccs.covici.com wrote:
> Hi.  I have a Debian Leni system  with asterisk-1.8.  I was trying to
> get meetme to work and it depends on dahdi, so I compiled dahdi-trunk
> and dahdi-tools-trunk, however, when trying to insert dahdi_dummy, it
> complained about symbol crc_ccitt_table, although the module was
> actually there in the kernel tree.  So, I took the Debian source, and I
> had the config and I did make Bzimage, make modules and make
> modules_install, but dahdi_dummy still complains about the same symbol,
> it says no version for that symbol, so I am confused as to how to
> resolve this so I can modprobe dahdi_dummy properly.
> 
> Any ideas would be appreciated.
> 
First off, I recommend using dahdi-linux 2.4.0 *without* compiling
dahdi_dummy.  A dummy span is no longer needed for DAHDI to provide a
timing source to asterisk.

But you'll still need crc_ccitt module for dahdi to load, so that
doesn't fix the problem as you describe here.

If you rebuilt your kernel (which probably wasn't necessary...) you need
to reboot into the new kernel, then rebuild DAHDI against your running
kernel in order to load.  Sounds like you have built DAHDI against one
version of the kernel and you're running against another one.

Also...make sure you're using "modprobe" and not
"insmod" to load the
driver...so that crc_ccitt will automatically be loaded as a dependency.

For example you can see it automatically loaded here (and how
dahdi_dummy isn't needed for timing).

]# lsmod | grep crc_ccitt
]# dahdi_test -c 1
Unable to open dahdi interface: No such file or directory
]# modprobe dahdi
]# lsmod | grep crc_ccitt
crc_ccitt              10240  1 dahdi
]# dahdi_test -c 5
Opened pseudo dahdi interface, measuring accuracy...
99.998% 99.981% 99.990% 99.990% 99.991%
--- Results after 5 passes ---
Best: 99.998 -- Worst: 99.981 -- Average: 99.990100, Difference: 99.990101
]#

Hope this helps,
Shaun

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org

> FATAL: Error inserting dahdi (/lib/modules/2.6.26-2-686/dahdi/dahdi.ko):
> Unknown symbol in module, or unknown parameter (see dmesg)
> [25991.968325] dahdi: no symbol version for crc_ccitt_table
> [25991.968330] dahdi: Unknown symbol crc_ccitt_table
I think the message "no symbol version for crc_ccitt_table" may be
the key here.

It's possible (and fairly common) for Linux kernels and modules
to be compiled using an option which explicitly adds some
"version number" information to each symbol which is imported
or exported.  The "symbol version" information identifies the
exact version of the kernel which was built, or against which
a module was compiled.

This is done in order to provide some assurance that the
implementations in the kernel (used by the module) are
exactly those against which the module was compiled.  It
helps prevent situations in which a module which was
compiled against (e.g.) an older version of the kernel,
isn't loaded and run in the environment of a newer
kernel versions whose APIs or data structures have changed
in an incompatible way.

The use of this versioning feature is optional... you can
use it or not... but you have to make sure that you either
enable it in *both* the kernel and module compile environments,
or in *neither*.

I think that modprobe/insmod is complaining that you have not
followed this rule.  One of the two builds (either the kernel,
or dahdi) was compiled using kernel versioning, and the other
was not.

You'll have to restore consistency to your compilation
environments, before you can produce a dahdi module which
will load.