From 7088701ec6808c1dfa0f1db55760cea56fbe35d5 Mon Sep 17 00:00:00 2001 From: Shaun Ruffell Date: Tue, 23 Jun 2009 15:44:41 +0000 Subject: README: Adding a known issues section to the README files. git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@6695 a0bf4364-ded3-4de4-8d8a-66a801d63aff --- README | 33 ++++++++++++++++++++++++--------- 1 file changed, 24 insertions(+), 9 deletions(-) diff --git a/README b/README index aaf737e..c8d090d 100644 --- a/README +++ b/README @@ -81,7 +81,7 @@ Installing to a Subtree ~~~~~~~~~~~~~~~~~~~~~~~ The following may be useful when testing the package or when preparing a package for a binary distribution (such as an rpm package) installing -onto a subtree rather than on th real system. +onto a subtree rather than on the real system. make install DESTDIR=targetdir @@ -164,7 +164,7 @@ Thus for the moment, the simplest way to build OSLEC with dahdi is: (at least 2.6.28-rc1) to the a subdirectory with the same name in the dahdi-linux tree. -2. Edit drivers/dahdi/Kbuild and unrem the two lines related to OSLEC. +2. Edit drivers/dahdi/Kbuild and uncomment the two lines related to OSLEC. After doing that, you'll see the following when building (running 'make') @@ -270,7 +270,7 @@ Internals DAHDI Device Files ~~~~~~~~~~~~~~~~~~~ Userspace programs will usually interact with DAHDI through device -files under the /dev/dahdi directory (pedantically: characted device files +files under the /dev/dahdi directory (pedantically: character device files with major number 196) . Those device files can be generated statically or dynamically through the udev system. @@ -287,7 +287,7 @@ or dynamically through the udev system. 249 channels. * /dev/dahdi/pseudo (196:255) - A timing-only device. Every time you open it, a new DAHDI channel is created. That DAHDI channel is "pseudo" - - DAHDI recieves no data in it, and only sends garbage data with the + DAHDI receives no data in it, and only sends garbage data with the same timing as the DAHDI timing master device. @@ -307,7 +307,7 @@ similar connection. With an analog connection you are not synced to the other party. And some systems don't have DAHDI hardware at all. Even a digital card may be used for other uses or is simply not connected to a provider. DAHDI cards are also capable of providing timing from a clock on card. Cheap x100P -clone cards are sometimes used for that pupose. +clone cards are sometimes used for that purpose. If all the above fail, you can use the module dahdi_dummy to provide timing alone without needing any DAHDI hardware. It will work with most systems and @@ -331,7 +331,7 @@ Or even run: Spans and Channels ~~~~~~~~~~~~~~~~~~ DAHDI provides telephony *channels* to the userspace applications. -Those channels are channels are incorperated into logical units called +Those channels are channels are incorporated into logical units called *spans*. With digital telephony adapters (e.g: E1 or T1), a span normally @@ -356,7 +356,7 @@ then a line for each channel of the span. The title line shows the number of the span, its name and title, and (potentially) the alarms in which it is. -The title shows the span number and name, followed by any allarms the +The title shows the span number and name, followed by any alarms the span may have: For example, here is the first span in my system (with no alarms): @@ -382,7 +382,7 @@ ABI Compatibility ~~~~~~~~~~~~~~~~~ Like any other kernel code, DAHDI strives to maintain a stable interface to userspace programs. The API of DAHDI to userspace programs, dahdi/user.h, has -remained backword-compatible for a long time and is expected to remain so in +remained backward-compatible for a long time and is expected to remain so in the future. With the ABI (the bits themselves) things are slightly trickier. DAHDI's interface to userspace is mostly ioctl(3) calls. Ioctl calls @@ -390,7 +390,7 @@ are identified by a number that stems from various things, one of which is the size of the data structure passed between the kernel and userspace. -Many of the DAHDI ioctl-s use some sepcific structs to pass information +Many of the DAHDI ioctl-s use some specific structs to pass information between kernel and userspace. In some cases the need arose to pass a few more data members in each call. Simply adding a new member to the struct would have meant a new number for the ioctl, as its number depends on @@ -525,6 +525,21 @@ terms are not appropriate (e.g. a proprietary embedded system), licenses under more flexible terms can be readily obtained through Digium, Inc. at reasonable cost. +Known Issues +------------ + +Removing echocan modules +~~~~~~~~~~~~~~~~~~~~~~~~ +Before unloading an echo-canceller module you must remove an reference to it. +Using 'etc/init.d/dahdi stop' is the preferred method. + +However if, for some reason, you want to unload just a single dahdi_echocan_* +module that you use, you must first edit /etc/dahdi/system.conf and change any +echocan lines referring to it to refer to a different echo canceller module. + +https://issues.asterisk.org/view.php?id=15327[0015327: oops after removing an echocan module that is in use] + + Reporting Bugs -------------- Please report bug and patches to the Asterisk bug tracker at -- cgit v1.2.3