Comment 6 for bug 506210

Had same problem here.

I managed to the conclusion that echo.ko that is in my kernel is not the same compiled together with dahdi_echocan_oslec!

Look:
md5sum /lib/modules/3.13.0-66-generic/kernel/drivers/staging/echo/echo.ko
4d13d548ea08ee01fe9958de736f121c /lib/modules/3.13.0-66-generic/kernel/drivers/staging/echo/echo.ko

while

md5sum /var/lib/dkms/dahdi/2.5.0.1+dfsg-1ubuntu4~14.04.4/3.13.0-66-generic/x86_64/module/echo.ko
dbf4152d6c86853d8791dbdd36889c34 /var/lib/dkms/dahdi/2.5.0.1+dfsg-1ubuntu4~14.04.4/3.13.0-66-generic/x86_64/module/echo.ko

Rename "/lib/modules/3.13.0-66-generic/kernel/drivers/staging/echo/echo.ko" to something else and

cp /var/lib/dkms/dahdi/2.5.0.1+dfsg-1ubuntu4~14.04.4/3.13.0-66-generic/x86_64/module/echo.ko \
/lib/modules/3.13.0-66-generic/kernel/drivers/staging/echo/echo.ko

execute "modprobe dahdi_echocan_oslec"

and things will work. At least the module will load flawlessly.

This is a test environmet and I still do not know if oslec is doing its job.

A problem I am facing now is that "dahdi_echocan_oslec" is not been loaded "automatically".
I must do it "manually". My production system loads it automatically.
I mean, there is not an explicit "modprobe dahdi_echocan_oslec" I can find anywhere.
"service dahdi stop" unloads it, but does not loads it!

Cheers