Комплект драйверов версии 6.1 к адаптерам Кроникс для ОС Linux ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Дата сборки 2009-10-29. Последняя версия всегда доступна на сайте http://www.cronyx.ru/software О проблемах/ошибках просьба сообщать в службу поддержки: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Павлу Червонцеву, +7 (499) 946-99-90, info@cronyx.ru Содержание руководства: ~~~~~~~~~~~~~~~~~~~~~~~ 1. Общие сведения. 1.1. Важные замечания. ВНИМАНИЕ!!! 1.2. Последние изменения. 1.3. Системные требования. 1.4. Введение. 1.5. Состав комплекта драйверов. 1.5.1. Загружаемые модули коммуникационных протоколов. 1.5.2. Загружаемые модули драйверов адаптеров. 1.5.3. Загружаемый модуль управления binder. 1.5.4. Утилита sconfig и другие компоненты. 2. Установка. 2.1. Выбор протокольных модулей. 2.2. Выбор модулей поддержки модельных серий адаптеров. 2.3. Прочие опциональные параметры. 3. Использование. 3.1. Система именования адаптеров, интерфейсов и каналов. 3.2. Опции командной строки sconfig. 3.3. Набор допустимых параметров. 3.4. Краткое описание моделей адаптеров. 3.4.1. Серия Tau-PCI/32. 3.4.2. Серия Tau-PCI. 3.4.3. Серия Tau-ISA. 3.4.4. Серия Sigma-ISA. 3.5. Поддержка Zaptel и IP-АТС Asterisk. 3.6. Непосредственный обмен в "телефонных" режимах. 3.7. Примеры использования sconfig. 3.8. Конфигурирование /etc/cronyx.conf. 4. История выхода версий и изменений. ___________________________________________________________________________ 1. Общие сведения. ~~~~~~~~~~~~~~~~~~ 1.1. Важные замечания. ВНИМАНИЕ!!! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ВНИМАНИЕ! В серии адаптеров Tau-PCI применяется PCI-контроллер Siemens/Infineon 20534, известный также как DSCC4. В комплект исходных текстов ядра Linux и в состав большинства дистрибутивов входит драйвер для этого контроллера в виде модуля dscc4.ko. Драйвер dscc4.ko не может обслуживать адаптеры серии Tau-PCI, а также содержит ошибки, из-за которых при таких попытках может произойти крах системы. Обычно это приводит к сбою в коде драйвера, ошибке или длительной приостановке процесса загрузки системы, невозможности освободить и использовать занятый драйвером адаптер до успешной загрузки (без dscc4 или без Tau-PCI). По этой же причине может быть невозможно установка многих дистрибутивов Linux (например Ubuntu) на компьютер, в который уже установлен адаптер Tau-PCI. Для решения проблемы вам необходимо использовать ядро Linux без поддержки dscc4, либо отключить его автоматическую загрузку. В простейшем случае можно просто удалить модуль dscc4. Например, выполнив команду: sudo rm `find /lib/modules -name 'dscc4.*'` ВНИМАНИЕ! Так как имена интерфейсов и каналов могут содержать символ '.' (точка) и из-за ограничения синтаксиса языка sh, в файле '/etc/cronyx.conf' в соответствующих именах '.' (точка) должна быть заменена на '_' (подчерк). Отредактируйте файл '/etc/cronyx.conf' под свои нужды, в комментариях даны примеры типовых конфигураций. Список возможных параметров и их значений приведены в описании утилиты sconfig (см. ниже и 'man sconfig'). Последние версии драйверов доступны на сервере http://www.cronyx.ru С вопросами и предложениями просьба обращаться по адресу 1.2. Последние изменения. ~~~~~~~~~~~~~~~~~~~~~~~~~ 2009-10-29, 6.1.11: - ошибок не замечено; - доработка configure и makefile драйвера Omega для поддержки Ubuntu; - более интеллектуальная подстройка i/o-chunk (параметр mtu) при смене набора таймслот в телефонных режимах для Tau-PCI/xE1; 2009-10-08, 6.1.10: - доработка скрипта запуска cronyx.sh для автоматического выбора между синхронным и асинхронным режимом ppp; - исправления драйвера Tau-ISA, в нескольких случаях при успешной установке параметров возвращался код ошибки; 2009-09-23, 6.1.9: - ликвидация предупреждений gcc 4.4.x при сборке диагностических утилит; - доработка DDK и драйвера Tau-PCI для обхода ошибки в Infineon PEB20534 связанной с управлением сигналом RTS; 2009-09-11, 6.1.8: - ошибок не замечено; - использование kernel-API для ISA-DMA вместо непосредственных обращений в драйверах Sigma-ISA и Tau-ISA; - использование buildroot для сбоки диагностического комплекта; - толерантный к DAHDI/Asterisk порядок запуска (update-rc.d и chkconfig); - пауза для гашения RTS и DTR в Tau-PCI (Infineon PEB20534 нужна пара тактов TXC); 2009-07-10, 6.1.7: - исправление ошибки в драйвере Tau-PCI/32, из-за которой остановка логических каналов, работающих в режиме HDLC, приводила к выдаче диагностических предупреждений и "зависания" процесса остановки на 5-6 секунд. Спасибо Николаю Фролову за сообщение о проблеме; - доработка кода управления сигналом RTS в DDK для Tau-PCI. До этого сигнал мог "залипать", т.е. не изменяться при старте или остановке канала; - в readme.txt добавлен раздел 3.6. "Непосредственный обмен в "телефонных" режимах"; 2009-06-05, 6.1.6: - исправление ошибки в DDK для Tau-PCI, из-за которой изменения CAS всегда краткосрочно трактовалось как AIS16. Ошибка проявлялась как "мелькание" аварийной индикации AIS16 и RED ALARM при работе CAS-сигнализаций в DAHDI/Zaptel/Asterisk; - поддержка DAHDI 2.2.x (проверено на 2.2.0-rc5); - доработка сценария сборки diag.mk, который используется только при сборке диагностических утилит. Теперь всегда правильно трактуются и принимаются во внимание ссылки /lib/modules/*/build; - исправление в cdahdi.ko и czaptel.ko, при работе с CAS-сигнализациями после выхода из ситуации CAS LOMF (потеря сверхциклового синхронизма) первое изменение сигнальных ABCD-битов не доходило до DAHDI/Zaptel; 2009-05-08, 6.1.5: - доработка логики обхода проблем MUNICH32X, переработка watchdog-механизма для rx-запросов; - тривиальные доработки для поддержки RHEL 5.3 (предположительно 5.x); - замена xxx_sleep_on() на wait_event_xxx(); 2009-04-20, 6.1.4: - поддержка ядра Linux версии 2.6.30; - устранение утечек памяти в tau32.c/ce.ko в маловероятных ошибочных ситуациях; - переработка кода остановки каналов и адаптеров в tau32.c/ce.ko; - доработки tau32.c и tau32-ddk.c для обхода проявления "особенностей" контроллера Infineon MUNICH32X. В результате чего могла выполнятся отложенная запись из DMA-FIFO в уже освобожденные буферы, связанные с только-что остановленным каналам; - исправление старой, не замеченной при выходе linux 2.6.0, ошибки использования статических экземпляров tty_driver в async.c и sync.c вместо динамических kobject со счетчиком ссылок; 2009-03-12, 6.1.3: - изменения в omega-diag для поддержки Omega-PCI на основе PLX9030; 2009-03-03, 6.1.3: - модуль поддержки DAHDI/asterisk.org; - доработана логика работы режима "phony", добавлен режим "voice". Отличия между режимами только в поведении при transmit-underrun: * в режиме "voice" на передачу подставляется порция данных заполненная кодом 0xD5, а в режиме "phony" кодом 0xFF; * в режиме "voice" очередная порция помещается в уже передаваемый подставленный буфер, а в режиме "phony" в следующий; Поэтому режим "voice" оптимален для "голосовых" применений, в частности для DAHDI/Zaptel. При этом последствия ситуаций underrun менее заметны. Режим "phony" нужен для корректной работы в случаях когда ситуация underrun не является ошибкой, например при работе пакетных протоколов с байт-стаффингом; - исправление утечки памяти в tau32.c в функции tau32_update_dxc(), в случае когда нет изменений в привязке канальных интервалов E1. 2009-01-16, 6.1.2: - обновление маркера версии выдаваемого по sconfig -v. В конце декабря, в спешке, это не было сделано; - поддержка ядра Linux версии 2.6.29; - доработка для поддержки старых ядер Linux линейки 2.4 начиная от 2.4.23; - доработка для поддержки ядер Linux линейки 2.6 начиная от 2.6.0; - чистка fr.c от неактивного экспериментального кода; - правка configure, теперь при отсутствии в /lib/modules/ нужного для собираемых модулей подкаталога выдается предупреждение, а не происходит остановка по ошибке; - ликвидация использования spinlock'ов в коде sync.c, для гарантированного избавления от deadlock в различных версиях ядер; - доработка async.c и sync.c, теперь по-возможности используются tty_ldisc_ref() и tty_ldisc_deref(); - добавлен контроль CAP_SYS_ADMIN в binder.c; 2008-12-30, 6.1.1: - доработка Makefiles и исходных текстов для сборки с Linux 2.4 при наличии только заголовочных файлов ядра; - правки модулей для совместимости с gcc 2.95 (кроме ce.ko); - доработки fr.c для авто-выбора сигнального DLCI; - исправления sync.c для предотвращения deadlock в коде передачи ошибок; 2008-11-06, 6.1.0 (release): - поддержка ядер Linux версий 2.6.27 и 2.6.28; - мелкие правки в taucpi-ddk.c для предотвращения сбоев при попытке запуска каналов без назначенных канальных интервалов E1; - правки в объявлениях inline-функций для подавления предупреждений при сборке c помощью GCC 4.3; - ликвидация анонимных структур и объединений в tau32-ddk.c для совместимости с FreeBSD. Спасибо Юрию Салтикову за содействие. Историю более ранних версий см. в разделе 4 в конце документа. 1.3. Системные требования. ~~~~~~~~~~~~~~~~~~~~~~~~~~ * Ядро ОС Linux версии 2.4.x (от 2.4.23) или 2.6.x (от 2.6.0). * Для поддержки Zaptel/Asterisk исходные тексты Zaptel-стека. * Стандартная среда ОС Linux (bash, cat, sed, tc, make, и т.д.). * Компилятор GNU GCC версии 3.2 или более поздней. * 10 Мбайт свободного дискового пространства. * Вменяемый и здравомыслящий системный администратор. 1.4. Введение. ~~~~~~~~~~~~~~ Комплект драйверов предназначен для обеспечения функциональности различных адаптеров для PC-платформы производства "КБ Кроникс". Комплект драйверов состоит из исходных текстов модулей ядра ОС Linux и утилиты управления sconfig. Всё взаимодействие пользователя (системного администратора) с комплектом драйверов производится с помощью утилиты sconfig. Дополнительно для удобства использования в наиболее распространённых конфигурациях предусмотрен единый конфигурационный файл /etc/cronyx.conf и обрабатывающий его sh-сценарий, который может быть установлен в rc.d или init.d подсистему. В комплект драйверов входит несколько "протокольных модулей", которые организуют взаимодействие между низкоуровневыми драйверами адаптеров и остальными компонентами системы. Привязка "протокольных модулей" к низкоуровневым драйверам, а также предоставление интерфейса для централизованного управления входит в задачи связующего модуля binder. Управление комплектом драйверов сводится к загрузке необходимых модулей ядра, установке требуемых параметров (для линейных интерфейсов, логических каналов приёма-передачи и адаптеров в целом) и далее к назначению канальных протоколов, настройке полученных сетевых интерфейсов. Протокольные модули с сетевой поддержкой создают в системе стандартные сетевые интерфейсы, настройка и взаимодействие с которыми, происходит стандартным способом (ifconfig и т.д.). Разработка и проверка работы комплекта драйверов производится под Gentoo Linux и ядрах линейки 2.6 c http://www.kernel.org. Ядра Linux линейки 2.4 поддерживаются на прецедентной основе, т.е. исправления и доработки производятся только при поступлении сообщений о проблемах. Ядра Linux версий менее 2.4.28, включая 2.2.x и 2.0.х, не поддерживаются, и больше не будут поддерживаться когда-либо. При просмотре исходных текстов рекомендуется установить размер табуляции равным 4. 1.5. Состав комплекта драйверов. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Комплект драйверов состоит из нескольких компонентов: 1.5.1. Загружаемые модули коммуникационных протоколов: a) ccisco.ko - драйвер протокола Cisco HDLC; b) cfr.ko - драйвер протокола Frame Relay; c) crbrg.ko - драйвер моста Ethernet (см. ниже); d) craw.ko и cpacket.ko - драйверы 'непосредственного' доступа (без сетевой поддержки); e) casync.ko - драйвер асинхронного режима (без сетевой поддержки); f) csync.ko - драйвер синхронного tty для протокола PPP; g) cdahdi.ko - обеспечивает DAHDI-совместимый интерфейс для проекта http://www.asterisk.org/, см. ниже; h) czaptel.ko - обеспечивает Zaptel-совместимый интерфейс для проекта http://www.asterisk.org/, см. ниже; * - модули ядра версий 2.6.х имеют расширение '.ko', модули предыдущих версий ядер имеют расширение '.o'. Загружать можно не все протоколы, а только те, которые необходимы. Модули ccisco.ko, cfr.ko и crbrg.ko реализуют сетевые интерфейсы, которыми можно управлять командой ifconfig. Модуль csync.ko обслуживает синхронные tty-устройства вида /dev/cronyx/<имя-канала> для работы службы (демона) pppd. В зависимости от используемой ОС могут автоматически создаваться устройства /dev/ttyZ#. Для работы PPP необходимо иметь в ядре стандартную поддержку (модуль ppp.ko), а также запустить службу (демон) pppd для работы с устройством /dev/cronyx/<имя-канала>. Модуль casync.ko обслуживает асинхронные tty-устройства /dev/<имя-канала> и /dev/<имя-канала>_cu. В зависимости от используемой ОС могут автоматически создаваться устройства /dev/ttyQ# и /dev/cuq#. Асинхронный режим поддерживается только некоторыми моделями адаптеров серии Sigma-ISA. Модуль craw.ko дает возможность работать с каналом в низкоуровневом режиме через /dev/cronyx/<имя-канала>, например, для реализации собственных протоколов. Для большинства адаптеров доступен только HDLC-режим (приём/передача кадров HDLC Layer 2). Для адаптеров Tau-PCI/2E1, Tau-PCI/4E1 и серии Tau-PCI/32 также доступен прозрачный 'телефонный' режим. Дополнительнная информация по этой теме подготовлена нами на странице http://www.cronyx.ru/case/raw/ Модуль cpacket.ko обеспечивает функциональность аналогичную craw.ko, но при этом обеспечивает пакетный режим с буферизацией передаваемых данных. Это позволяет уменьшить количество коротких HDLC-пакетов и тем самым снизить накладные расходы. Использование модулей craw.ko и cpacket.ko предполагает разработку вашими силами дополнительного ПО, которое будет производить обмен данными посредством стандартных файловых операций, через /dev/cronyx/<имя-канала>. 1.5.2. Загружаемые модули драйверов адаптеров: a) ce.ko - драйвер для PCI-адаптеров серии Tau-PCI/32; b) cp.ko - драйвер для PCI-адаптеров серии Tau-PCI (Tau-PCI/Lite, Tau-PCI/2E1, Tau-PCI/4E1 и т.д.); c) ct.ko - драйвер для ISA-адаптеров серии Tau-ISA (сняты с производства); d) cx.ko - драйвер для ISA-адаптеров серии Sigma-ISA (сняты с производства); Их функция - взаимодействие с оборудованием и передача данных на обработку соответствующему модулю протокола. 1.5.3. Загружаемый модуль управления cbinder.ko. Модуль cbinder.ko связывает модули протоколов и драйверов адаптеров между собой, а также реализует устройство /dev/cronyx/binder для управления. В нём также обрабатываются некоторые ioctl-вызовы, общие для всех режимов. 1.5.4. Утилита sconfig и прочие компоненты. - Утилита конфигурации sconfig. Всё управление адаптерами, протокольными модулями, логическими каналами и интерфейсами производится с помощью утилиты sconfig. Исключения составляет загрузка и выгрузка модулей ядра. - Командный файл (сценарий) cronyx.sh для загрузки и инициализации драйверов. - Пример файла конфигурации cronyx.conf. ___________________________________________________________________________ 2. Установка комплекта драйверов. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Если уже были установлены какие-либо драйверы адаптеров Кроникс, то перед установкой новой версии, во избежание конфликтов и неопределенностей, все модули ядра от предыдущей версии необходимо удалить. Модули комплекта драйверов версии 5.x устанавливались в каталог /lib/modules/имя-ядра/kernel/net/cronyx, для более ранних версий место расположения может быть иным. Модули комплекта драйверов версии 6.x устанавливались в каталог /lib/modules/имя-ядра/cronyx. Не забывайте, что перед запуском новых версий модулей необходимо выгрузить предыдущие. Комплект драйверов собирается стандартным для ОС Linux способом сборки из поставляемых исходных текстов. Для компиляции модулей необходимы заголовочные файлы и конфигурация целевого ядра ОС. Для ядер версий 2.4.x требуется полный набор исходных текстов ядра ОС. Перед процессом компиляции необходимо произвести подстройку системы сборки под вашу среду. Для этого в комплекте поставляется сценарий ./configure Этот сценарий принимает набор опций, позволяющий задать необходимый набор модулей, которые Вы будете использовать, и другие параметры. Требуется выбрать как минимум один протокольный модуль и один модуль поддержки оборудования. В процессе работы ./configure пытается определить (с помощью вызова утилиты lspci) наличие установленных PCI-адаптеров и автоматически выберет соответствующие им модули. 2.1. Опции выбора протокольных модулей: --enable-fr - подключает модуль Frame Relay (cfr.ko); --enable-cisco - подключает модуль Cisco/HDLC (ccisco.ko); --enable-rbrg - подключает модуль Ethernet-моста (crbrg.ko); --enable-sync - подключает поддержку синхронного tty (csync.ko) для протокола PPP; --enable-raw - подключает поддержку "прозрачного" режима для программ пользователя (craw.ko); --enable-packet - подключает поддержку пакетного HDLC-режима для программ пользователя (cpacket.ko); --enable-async - подключает поддержку асинхронного режима (casync.ko, только для адаптеров Simga-ISA); --with-dahdi=.. - включает поддержку DAHDI/asterisk.org и задаёт месторасположение заголовочных файлов к интерфейсному DAHDI-драйверу телефонии; --with-zaptel=.. - включает поддержку zaptel/asterisk.org и задаёт месторасположение заголовочных файлов к интерфейсному Zaptel-драйверу телефонии. В комплект многих дистрибутивов Linux уже входит комплект драйверов zaptel-интерфейса. В таких случаях требуется указать путь к каталогу в исходных текстах установленного ядра Linux с файлом zaptel.h; 2.2. Опции выбора модулей поддержки оборудования: --enable-ce - подключает модуль 'ce' для адаптеров серии Tau-PCI/32. Если опция --enable-ce не задана, то ./configure попытается определить наличие Tau-PCI/32; --enable-cp - подключает модуль 'cp' для адаптеров серии Tau-PCI; Если опция --enable-cp не задана, то ./configure попытается определить наличие Tau-PCI; --enable-ct - подключает модуль 'ct' для адаптеров серии Tau-ISA; --enable-cx - подключает модуль 'cx' для адаптеров серии Sigma-ISA; --enable-all - включает поддержку всех модулей; 2.3. Прочие опциональные параметры: --cronyx-major=.. - определяет базовый major-номер для devnode-устройств, которые будут использоваться комплектом драйверов. Разные компоненты комплекта драйверов будут требовать различные major-номера, начиная от указанного базового. Как минимум будет использоваться сам базовый major. Модуль csync.ko использует номер +1, а модуль casync.ko номера +2 и +3. Необходимо, чтобы все major-номера были свободны, и не использовались другими компонентами ядра. По умолчанию в качестве базового major-номера выбирается 222. --with-ksrc=.. - задаёт путь к конфигурации, заголовочным файлам и/или исходным текстам целевого ядра ОС Linux. Внимание! Версия исходных текстов и конфигурация должны полностью совпадать с ядром ОС, в котором будут работать модули; --with-libmod=.. - задаёт путь для установки готовых модулей. Если не задано, то делается попытка определить автоматически; --with-rcdir=.. - задаёт путь для установки rc-сценария cronyx.sh, например '/etc/init.d'. Если не задано, то делается попытка определить автоматически; --with-rctype=.. - задаёт тип системы rc-инициализации. Допустимые варианты: 'update-rc' (Ubuntu, Debian), 'rc-update' (Gentoo), 'chkconfig' (RedHat), 'rc.local' (Slackware). Если не задано, то делается попытка определить автоматически; --with-rclocal=.. - задаёт путь к сценарию 'rc.local'. Если не задано, то делается попытка определить автоматически; --with-manpath=.. - задаёт путь для установки man-страниц. Если не задано, то делается попытка определить автоматически; --with-manpath-ru=.. - задаёт путь для установки русскоязычных man-страниц. Если не задано, то делается попытка определить автоматически; --with-manpath-en=.. - задаёт путь для установки англоязычных man-страниц. Если не задано, то делается попытка определить автоматически; --with-man-encoding=.. - задаёт кодировку для русскоязычной man-страницы. Допустимые варианты: 'utf8', 'koi8-r', 'win-1251', 'dos-866', 'iso-8859-5'. Если не задано, то делается попытка определить автоматически на основе уже установленных man-страниц; После успешного выполнения ./configure c требуемыми опциями, можно произвести сборку и установку комплекта драйверов командами: make && sudo make install При наличии правильно установленных и сконфигурированных исходных текстов ядра Linux этого должно быть достаточно. Затруднения могут возникнуть при использовании дистрибутивов Linux с нестандартным, измененным процессом сборки внешних модулей, либо специализированных версий. В этих случаях рекомендуем обратиться к разделу документации "building & installing external kernel modules" вашей версии ядра ОС Linux и/или различным статьям в Интернет, описывающим решение подобных проблем. Но не стоит при этом обращаться в службу поддержки Кроникс, мы не можем помочь Вам изучить и освоить Linux. Следует отметить, что наиболее частой ошибкой при сборке комплекта драйверов является использование среды построения ядра Linux не совпадающей (по версии и/или по конфигурации) с используемым ядром, а также использование исходных текстов DAHDI/zaptel, отличных от входящих в дистрибутив ОС и/или комплект ядра. В этом случае при попытке загрузки собранных модулей, система будет сообщать о несовпадении сигнатур/версий, либо о невозможности разрешить ссылки на внешние символы. Как правило, сообщение "kernel tainted" говорит именно о такой ситуации (см. http://www.trixbox.org/wiki/kernel-tainted). Не забывайте, что после сборки и установки новых версий модулей они будут использоваться системой только после выгрузки предыдущих. ___________________________________________________________________________ 3. Использование. ~~~~~~~~~~~~~~~~~ 3.1. Система именования адаптеров, интерфейсов и каналов. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ До версии комплекта 6.0 использовалась старая "плоская" система именования, при которой имена назначались только каналам приёма-передачи данных. Такая схема была удобной и достаточной, пока каждый логический канал однозначно соответствовал аппаратному линейному интерфейсу. С появлением нового поколения адаптеров (Tau-PCI/2E1, Tau-PCI/4E1 и Tau-PCI/32) стала возникать путаница, так как логические каналы больше не соответствовали линейным интерфейсам, а при конфигурировании линейных интерфейсов возникала нелогичность и неоднозначность в их выборе. Поэтому начиная с версии 6.0 была введена новая "иерархическая" система именования. Новая схема именует и различает объекты нескольких типов: 'адаптер', 'интерфейс', 'канал'. При этом, каждый из объектов имеет свой набор конфигурационных параметров. Соответственно для задания полной конфигурации необходимо отдельно определить набор параметров для каждого из объектов. При этом необходимо произвести большее количество действий, но зато всегда есть полная ясность и однозначность. Адаптерам присваиваются имена вида <тип-адаптера_#>, например: 'tau32_0', 'taupci_0', 'tauisa_2' и т.д. Линейным интерфейсам (E1, V.35, RS-530 и т.д.) присваиваются имена вида <имя-адаптера.тип-интерфейса_#>. Где 'имя-адаптера' соответствует адаптеру, на котором расположен линейный интерфейс. А 'тип-интерфейса_#' определяет тип и порядковый номер интерфейса на адаптере. Например 'tau32_0.e1_0', 'taupci_0.e1_3', 'tauisa_0.s_1' и т.д. Тип линейного интерфейса именуется так: 's' - синхронный последовательный интерфейс; 'e1' - интерфейс E1/ИКМ-30 (ITU-T G.703) c поддержкой структурированного режима ITU-T G.704; 'g703' - интерфейс ITU-T G.703 с поддержкой только неструктурированного режима; 'e3' - интерфейс E3; 'rs232' - синхронный последовательный RS-232; 'rs449' - синхронный последовательный RS-449; 'rs530' - синхронный последовательный RS-530; 'v35' - синхронный последовательный V.35; 'x21' - синхронный последовательный X.21; 'a' - асинхронный последовательный интерфейс RS-232; 'u' - универсальный синхронный/асинхронный интерфейс; Логические каналы приёма/передачи данных получают имена вида <имя-адаптера.#>, где указывается имя адаптера, на котором расположен логический канал, и номер канала на адаптере. Например: 'tau32_0.0', 'tau32_0.31', 'taupci_1.3' и т.д. Кроме этого, для удобства логическим каналам присваиваются псевдонимы (aliases), которые совпадают с их именами в старой схеме именования. Это позволяет использовать более короткие имена (в том числе получаемых сетевых интерфейсов) и одновременно сохранить максимум совместимости с прикладным ПО рассчитанным на старую схему именования. Псевдонимы логических каналов имеют вид , , и для адаптеров Tau-PCI/32, Tau-PCI, Tau-ISA и Sigma-ISA соответственно. Посмотреть актуальный список доступных объектов можно по команде 'sconfig -r'. Псевдонимы логических каналов отображаются через '/' (слеш) после имени. 3.2. Опции командной строки sconfig. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sconfig [-raimsxeftucqv] [<имя-объекта> [параметры...]] -r -- отображение карты существующих объектов; -a -- вывод полной информации о конфигурации; -i -- вывод статистики сетевого интерфейса; -m -- вывод информации о состоянии модемных сигналов; -s -- вывод краткой статистики логического канала; -x -- вывод расширенной статистики логического канала; -e -- вывод краткой статистики интерфейса E1/G.703; -f -- вывод полной статистики интерфейса E1/G.703; -t -- вывод краткой статистики интерфейса E3; -u -- вывод полной статистики интерфейса E3; -c -- очистка статистики; -q -- не выводить никакой информации; -v -- вывод информации о версии; Если <имя-объекта> не задано, то соответствующее действие выполняется для всех существующих объектов. 3.3. Набор допустимых параметров. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Для просмотра текущей конфигурации необходимо вызвать утилиту sconfig с именем интересующего объекта. При вызове без параметров sconfig отобразит основные параметры конфигурации для всех доступных объектов. Для изменения конфигурации утилите sconfig кроме имени объекта необходимо указать имена изменяемых параметров конфигурации и их значения в форме <параметр=значение>. Для адаптеров, интерфейсов и каналов доступны разные наборы параметров. В каждом конкретном случае множество доступных параметров зависит от модели адаптера, типа интерфейса, режима работы и выбранного протокола. Например, параметр 'line=' (кодирование в линии) недоступен для асинхронных интерфейсов, а параметр 'dpll=' (включение DPLL/ФАПЧ) недоступен для интерфейсов E1. Для просмотра всех параметров применимых к объекту вызовите sconfig c опцией '-a' и указанием имени объекта. Полный список допустимых параметров конфигурации: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Параметры конфигурации адаптера в целом: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ adapter=.. -- задаёт режим работы для адаптеров Tau-ISA и Tau-PCI с интерфейсами E1. Возможные значения: separate - режим независимых каналов. Каждому линейному интерфейсу соответствует один логический канал; mux - режим мультиплексирования канальных интервалов между линейными интерфейсами и логическими каналами; split - распределение канальных интервалов интерфейса E1 между логическими каналами приёма-передачи; b-mode - режим "B" адаптера Tau-ISA/E1; led=.. -- задаёт режим индикации светодиодом адаптера различных ситуаций и событий. Допустимы комбинации следующих опций, которые перечисляются без пробелов через запятую: smart - режим по умолчанию, индикатор моргает в зависимости от состояния физического интерфейса (шлейф, потеря несущей, потеря фреймовой синхронизации т.д.); on - индикатор постоянно горит; off - индикатор погашен; # (число) - 32-битное значение позволяет задать произвольный режим каденции; irq - если указано, индикатор кратковременно вспыхивает (либо гаснет) при каждом аппаратном прерывании со стороны адаптера; rx - если указано, индикатор кратковременно вспыхивает (либо гаснет) при приёме пакета (порции) данных; tx - если указано, индикатор кратковременно вспыхивает (либо гаснет) при передаче пакета (порции) данных; err - если указано, индикатор кратковременно вспыхивает (либо гаснет) при ошибках приёма-передачи; subchan=.. -- задаёт множество канальных интервалов для режима "B" адаптера Tau-ISA/E1. Например: subchan=16,29-31; reset -- сброс/перезапуск адаптера, по возможности с полным сбросом аппаратной части; Параметры конфигурации логических каналов: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ debug=# -- задаёт уровень (0..2) выдачи отладочной информации, "0" - отладка выключена, "2" - максимум отладочной информации (для разработчиков); extclock -- включает режим внешней синхронизации для последовательных синхронных интерфейсов (V.35, RS-530 и т.д.). Режим внешней синхронизации является основным при подключении к модемному оборудованию (устройству DCE). В этом режиме внешний сигнал синхронизации поступает на контакт разъёма TXCIN и используется как тактирующий синхросигнал для передачи данных (контакт разъёма TXD); # (число) -- для серийных синхронных интерфейсов (V.35, RS-530 и т.д.), задаёт скорость в битах в секунду и включает синхронизацию от внутреннего генератора адаптера. Нулевое значение будет эквивалентно указанию опции 'extclock'. В случае ненулевого значения скорость обмена будет установлена равной заданному значению в бит/с. При этом, в качестве источника синхросигнала будет использоваться внутренний генератора адаптера. Передаваемые данные будут синхронизированы с сигналом внутреннего генератора адаптера, сгенерированный синхросигнал будет подаваться на контакт TXCOUT, а сигнал с контакта разъёма TXCIN будет игнорирован. Этот режим используется для непосредственного соединения адаптера с терминальным оборудованием (устройством DTE). Также режим внутренней синхронизации необходим для тестирования с использованием внешнего замыкателя; mtu=# -- задаёт ограничение размера MTU (Maximum Transfer Unit); qlen=# -- задаёт длину очередей приёма-передачи. Необходимо правильно задавать размер очередей, находя компромисс между вынужденной задержкой данных и вероятностью ситуаций underrun/overrun вследствие латентности системы при обработке аппаратных прерываний; timeslots=.. -- задаёт список канальных интервалов для интерфейсов или ts=.. E1/ИКМ-30. Например: timeslots=1-7,15,27-29; iface=# -- привязывает логический канал приёма-передачи к линейному интерфейсу по его порядковому номеру на адаптере (0, 1, 2, 3...); mode=.. -- задаёт режим работы логического канала. Возможные значения: async - асинхронный режим (только для Sigma-ISA); hdlc - синхронный режим, приём-передача пакетов в формате HDLC Layer 2; phony - для адаптеров Tau-PCI/32 и Tau-PCI c интерфейсами E1/ИКМ-30, непосредственный обмен данными ("телефонный" режим); voice - аналогичен режиму "phony", но оптимизирован для "телефонных" применений. Отличия между режимами "phony" и "voice" в поведении при ситуации transmit-underrun: * в режиме "voice" на передачу подставляется порция данных заполненная кодом 0xD5 а в режиме "phony" кодом 0xFF; * в режиме "voice" очередная порция помещается в уже передаваемый подставленный буфер, а в режиме "phony" в следующий; Поэтому режим "voice" оптимален для "голосовых" применений, в частности для DAHDI/Zaptel. При этом последствия ситуаций underrun менее заметны. Режим "phony" нужен для корректной работы в случаях когда ситуация underrun не является ошибкой, например при работе пакетных протоколов с байт-стаффингом. Более подробную информацию по этой теме можно найти на странице http://www.cronyx.ru/case/raw/; crc=.. -- задает режим формирования и контроля FCS (CRC) для HDLC. Возможные значения: none/off - генерация и контроль CRC отключены (0 байт FCS), только для Tau-PCI/32; on/16 - используется 16-битный (2 байта FCS) контроль по ITU-T Q.921; 32 - используется 32-битный (4 байта FCS) контроль, только для Tau-PCI/32; Параметры конфигурации протоколов (протокольных модулей): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ dlci=# -- при использовании протокольного модуля Frame Relay добавляет PVC (Permanent Virtual Circuit) с указанным номером DLCI; qlen-limit=# -- при использовании DAHDI/zaptel-протоколов задает предел для автоматического увеличения длины очередей приёма/передачи в результате обнаружения ситуаций переполнения/опустошения; ec-delay=# -- при использовании DAHDI/zaptel-протоколов задает задержку в миллисекундах (с точностью до 0.125 мс) для подачи переданного в линию E1 сигнала на вход обратной связи эхоподавителя. Допускается указание ec-delay=auto, в результате будет установлено адекватное значение исходя из текущего значения параметра qlen; Параметры конфигурации линейных интерфейсов: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ loop=.. -- включает/выключает шлейф (заворот данных). Возможные значения: off - нормальный режим, все шлейфы выключены; internal - внутренний шлейф - данные, передаваемые в линию, принимаются обратно; mirror - внешний шлейф - данные, принимаемые из линии, передаются (отражаются) обратно в линию; remote - выдача запроса на удаленную сторону на включение заворота данных, принимаемых с нашей стороны; dpll=on/off -- включение ФАПЧ (DPLL) на последовательных синхронных интерфейсах для восстановления тактирующего синхросигнала по поступающим данным; line=.. -- выбор линейного кода. Возможные варианты зависят от вида линейного интерфейса: nrz - код NRZ, для последовательных синхронных интерфейсов; nrzi - код NRZI, для последовательных синхронных интерфейсов; hdb3 - код HDB3, для интерфейсов E1/ИКМ-30 и G.703; ami - код AMI, для интерфейсов E1/ИКМ-30 и G.703; invclk=.. -- для последовательных синхронных интерфейсов, режим инверсии тактирующих синхросигналов. Возможные значения: normal или off - нормальный режим (по умолчанию); rx-only - инверсия только синхроимпульсов приёма (RXC/ERC). Поддерживается только адаптерами серии Tau-PCI; tx-only - инверсия только синхроимпульсов передачи (TXC/ETC). Поддерживается только адаптерами серии Tau-PCI; both или on - инверсия синхроимпульсов как приёма, так и передачи; higain=on/off -- для интерфейсов E1/ИКМ-30, включение режима повышенной чувствительности приёмника. Это позволяет увеличить дальность по линии E1 до 2.5 км (по витой паре сечением 0.6 мм2); monitor=on/off -- для интерфейсов E1/ИКМ-30, включение режима мониторинга (подслушивания) линии через внешние высокоомные резисторы; unframed=on/off -- для интерфейсов E1/ИКМ-30, включение неструктурированного (нефреймированного) режима E1/ИКМ-30 (без структуры канальных интервалов); scrambler=on/off -- для интерфейсов E1/ИКМ-30, включение скремблера в неструктурированном режиме E1/ИКМ-30; cas=.. -- для интерфейсов E1/ИКМ-30, задаёт режим обработки CAS (Channel Associated Signaling). Возможные значения: off - нет сигнализации CAS-типа, 16-ый канальный интервал доступен для передачи данных или сигнализации CCS-типа; set - CAS контролируется по приёму, но замещается при передаче (нет необходимости подготавливать CAS-данные для передачи); pass - CAS контролируется по приёму и передается "как есть" из соответствующего логического канала; cross - кросс-коммутация CAS средствами аппаратного кросс-коннектора параллельно с коммутацией канальных интервалов; crc4=on/off -- для интерфейсов E1/ИКМ-30, включение сверхциклов (мультифрейминга) и проверки CRC4; clock=.. -- для интерфейсов E1/ИКМ-30, задаёт режим синхронизации передатчика, а при работе в режиме мультиплексора всего тракта приёма-передачи. Возможные значения: internal - синхронизация от внутреннего генератора; receive - синхронизация от приёмного тракта (по восстановленной из линии частоте); rcv0 - синхронизация от приёмного тракта физического интерфейса #0; rcv1 - синхронизация от приёмного тракта физического интерфейса #1; rcv2 - синхронизация от приёмного тракта физического интерфейса #2; rcv3 - синхронизация от приёмного тракта физического интерфейса #3; Выбор протокола: ~~~~~~~~~~~~~~~~ idle -- нет протокола (отключение протокольного модуля); async -- асинхронный протокол без сетевой поддержки, только для адаптеров серии Sigma-ISA. При выборе протокола в /dev/* автоматически создаются входы для доступа к каналу; sync -- поддержка интерфейса синхронного tty без или ppp непосредственной сетевой поддержки. Позволяет использовать стандартные системные средства (pppd) для организации сетевого взаимодействия. При выборе протокола в /dev/* автоматически создаются входы для доступа к каналу; cisco -- протокол Cisco HDLC, создает point-to-point сетевой интерфейс; rbrg -- протокол удаленного моста Ethernet. С противоположной стороны канала передачи данных должен работать аналогичный модуль, либо совместимое устройство (Ethernet-мосты серий Cronyx BRDG-ETV, Cronyx BRDG-ETH, конвертеры серий PCM2L, PCM2D, E1-L, мультиплексоры E1-XL). Совместно с корреспондентом образуется полноценный мост Ethernet и создаётся Ethernet-совместимый сетевой интерфейс; fr -- поддержка проколола Frame Relay (ANSI T1.167 Annex D). Для получения сетевых point-to-point интерфейсов, с помощью параметра dlci=#, необходимо добавить PVC с требуемыми номерами DLCI; raw -- поддержка непосредственного обмена данными для программ пользователя. Возможен обмен как HDLC-пакетами, так и "сырыми данными" в прозрачном (телефонном) режиме. При выборе протокола в /dev/cronyx/* автоматически создаются входы для доступа к каналу. Более подробную информацию по этой теме можно найти на странице http://www.cronyx.ru/case/raw/; packet -- организует для программ пользователя режим приёма-передачи с агрегированием мелких порций данных в пакеты HDLC, что позволяет уменьшить накладные расходы. При выборе протокола в /dev/cronyx/* автоматически создаются входы для доступа к каналу; dahdi -- обеспечивает DAHDI-совместимый интерфейс для открытой IP-АТС Asterisk. Для сборки и загрузки протокольного модуля необходимо наличие установленного модуля DAHDI; zaptel -- обеспечивает Zaptel-совместимый интерфейс для открытой IP-АТС Asterisk. Для сборки и загрузки протокольного модуля необходимо наличие установленного Zaptel-стека; Перед выбором протокола соответствующий протокольный модуль должен быть загружен. При подключении протокольного модуля к логическому каналу может быть автоматически произведена установка отдельных параметров. Так, например, почти все протокольные модули устанавливают режим работы канала (async/hdlc/phony). После подключения какого-либо протокола к логическому каналу часть параметров может стать недоступной для изменения. Например, модуль cdahdi.ko запрещает изменение списка канальных интервалов, многие протокольные модули не допускают изменение mtu и режима работы канала (async/hdlc/phony). Поэтому, при конфигурировании с помощью утилиты sconfig рекомендуется назначать канальный протокол последним параметром. После указания протокола необходимо указывать только DLCI-номера (параметр dlci=#) при использовании протокола Frame Relay. 3.4. Краткое описание модельных серий адаптеров. За последние 10 лет фирмой "КБ Кроникс" было выпущено более 20 моделей адаптеров для PC-платформ. Многие модели и модельные серии уже сняты с производства. Все адаптеры выпускались и выпускаются в нескольких ревизиях, которые отличаются между собой по эксплуатационным характеристикам. За более полной и точной информацией о технических характеристиках, описанием возможностей различных моделей и их ревизий обращайтесь к документации, которая входит в комплект поставки оборудования. 3.4.1. Серия Tau-PCI/32. Адаптеры серии Tau-PCI/32 позволяют организовать до 32 независимых каналов передачи данных суммарной пропускной способностью до 2048 кбит/c (один полный поток E1/ИКМ-30). Каждый канальный интервал набирается из канальных интервалов E1 и может работать как в режиме HDLC, так и в прозрачном "телефонном" режиме. Существует две модели Tau-PCI/32 (с двумя интерфейсами E1) и Tau-PCI/32-Lite (с одним интерфейсом E1). Основным отличием "полной" модели от "облегченной" является возможность кросс-коммутации и проброса незадействованных канальных интервалов между интерфейсами E1. Модель Tau-PCI/32-Lite может устанавливаться в слот Low-Profile PCI. Объектами конфигурирования в модельной серии Tau-PCI/32 являются: Адаптер в целом - выбор источника синхронизации и установка режима работы светодиодного индикатора. Интерфейсы E1 - выбор структурированного/неструктурированного режимов, включение CRC4, режима обработки CAS, линейного кода, занижение скорости, включение шлейфов, скремблера, режима высокой чувствительности приёмников, режима "подслушивания" линии E1. Логические каналы - назначение канальных интервалов, выбор режима HDLC/Transparent, размера очередей, привязка к интерфейсу E1, привязка канального протокола (протокольного модуля). ВНИМАНИЕ! К сожалению, в базовом контроллере Siemens/Infineon 20231 нами было обнаружено несколько существенных ошибок уже после разработки и выпуска этой серии адаптеров. Все эти ошибки, за исключением описанной ниже, полностью нейтрализованы в DDK и драйверах. Единственная, заметная со стороны пользователя, ошибка проявляется только при работе в прозрачном (aka "телефонном") режиме, при этом с небольшой вероятностью границы байтов в памяти компьютера могут не совпадать с границами канальных интервалов E1. Устранить эту проблему нам удалось ценой определенных неудобств. В комплекте драйверов, начиная с версии 6.0rc32 от 20 марта 2007, при запуске и/или остановке любого канала происходит остановка приёма и передачи во всех других каналов E1 на период 4-15 мс. Другими словами, следует учитывать, что при запуске/остановке канала Tau-PCI/32 будут индуцироваться ошибки во всех других активных каналах того же адаптера. По-умолчанию этот механизм включен, но может быть деактивирован указанием параметра infineon20321_stall_clk=0 при загрузке модуля ce.ko. Этот механизм может быть безопасно отключен если не предполагается использовать Tau-PCI/32 в прозрачном (aka "телефонном", т.е. mode=phony) режиме (например с Zaptel/Asterisk). 3.4.2. Серия Tau-PCI. В серию адаптеров Tau-PCI входит более 10 моделей. Все модели имеют не только много общего, но и отличия, обусловленные различием линейных интерфейсов. Многие модели серии Tau-PCI имеют возможность расширения с помощью дополнительной двухканальной платы серии Delta2. ВНИМАНИЕ! В серии адаптеров Tau-PCI применяется PCI-контроллер Siemens/Infineon 20534, известный также как DSCC4. В большинстве современных дистрибутивов Linux для этого контроллера доступен драйвер, оформленный в виде модуля dscc4.ko. Драйвер dscc4.ko не совместим с адаптерами серии Tau-PCI, и как правило попытка его загрузки заканчивается сбоем в коде драйвера. В результате первый адаптер серии Tau-PCI становится заблокированным до перезагрузки системы. Для решения проблемы вам необходимо использовать ядро Linux без поддержки dscc4, либо отключить его автоматическую загрузку. В простейшем случае можно просто удалить модуль dscc4. Например, выполнив команду: sudo rm `find /lib/modules/\`uname -r\` -name dscc4.*` Tau-PCI - модели с двумя синхронными последовательными и Tau-PCI/R интерфейсами V.35/RS-232 (модель Tau-PCI), либо RS-530/X.21 (модель Tau-PCI/R). Допускается расширение с помощью Delta2 или Delta2/R. Tau-PCI/Lite - пара моделей, аналогичных Tau-PCI и Tau-PCI/R, и Tau-PCI/R-Lite но с одним синхронным интерфейсом. Допускается установка в слот Low-Profile PCI. Tau-PCI/2E1 - модели с двумя (Tau-PCI/2E1) или четырьмя (Tau-PCI/4E1) и Tau-PCI/4E1 интерфейсами E1, которые могут работать как в структурированном, так и в неструктурированном режимах. Поддерживается до 4 логических каналов передачи данных, которые формируются из канальных интервалов E1 и могут работать как в режиме HDLC, так и прозрачном "телефонном" режимах. Модель Tau-PCI/2E1 допускает расширение с помощью Delta2 или Delta2/R. При этом логические каналы 2 и 3 жестко закрепляются за интерфейсами платы расширения. При работе в "телефонном" режиме имеется ряд ограничений: * нулевой канальный интервал недоступен; * размер порции данных не может быть более 32 кадров E1; Tau-PCI/E3 - модель с одним интерфейсом E3 34.368 Мбит/c, которому соответствует один логический канал приёма-передачи. Tau-104 - двухканальный адаптер для промышленных применений с шиной PC104+ (PCI-совместимое расширение шины PC104). Каналы оснащены универсальными интерфейсами V.35/RS-232/RS-530/X.21/V.10/V.11. Переключение типа интерфейса происходит автоматически в зависимости от подключенного кабеля. Tau-PCI/G703 - снятая с производства модель с двумя интерфейсами E1, которые поддерживают только неструктурированный режим. Допускается расширение с помощью Delta2 или Delta2/R. Tau-PCI/E1 - снятая с производства модель с двумя интерфейсами E1, которые поддерживают только структурированный режим. Допускается расширение с помощью Delta2 или Delta2/R. При работе в "телефонном" режиме имеется ряд ограничений: * нулевой канальный интервал недоступен; * можно выбрать не менее двух канальных интервалов; * размер порции данных зафиксирован в 16 кадров E1; Объектами конфигурирования в моделях серии Tau-PCI являются: Адаптер в целом - установка режима работы светодиодного индикатора, выбор режима mux/separate для моделей Tau-PCI/2E1 и Tau-PCI/4E1. Интерфейсы E1 - выбор структурированного/неструктурированного режимов, включение CRC4, режима обработки CAS, занижение скорости, включение шлейфов, скремблера, режима высокой чувствительности приёмников, режима "подслушивания" линии E1. Последовательные - выбор кодирования, Интерфейсы включение шлейфов, включение ФАПЧ/DPLL, инверсии синхросигналов. Логические каналы - в зависимости от того, линейному интерфейсу какого типа соответствует (привязывается) логический канал. В случае интерфейсов E1: назначение канальных интервалов, выбор режима HDLC/Transparent, привязка к интерфейсу E1. В случае синхронных последовательных интерфейсов: выбор скорости приёма-передачи и режима синхронизации. Не зависимо от типа физического интерфейса: установка размера очередей, привязка канального протокола (протокольного модуля). 3.4.3. Серия Tau-ISA. Серия Tau-ISA была предшественником серии Tau-PCI, что отражено в названии. К настоящему времени все адаптеры серии Tau-ISA сняты с производства. Были выпущены следующие модели адаптеров: Tau, - модели с двумя синхронными последовательными Tau/R интерфейсами из набора V.35/RS-232 и RS-530/RS449. и Tau/VR Tau/G703 - модели с двумя интерфейсами E1/G.703, Tau/G703-R которые поддерживают только неструктурированный режим. Tau/E1 - модели c двумя интерфейсами E1 и одним и Tau/E1/R дополнительным синхронным последовательным интерфейсом из набора V.35/RS-232 и RS-530/RS449. 3.4.4. Серия Sigma-ISA. Адаптеры модельной серии Sigma-ISA являются одними из первых синхронных последовательных адаптеров, которые производились в России. Эта модельная серия получила широкое распространение на первых этапах развития Интернет в России. Существуют следующие модели серии Sigma-ISA: Sigma-800 - снятая с производства модель, имеющая восемь универсальных синхронно/асинхронных интерфейсов RS-232, поддерживающих скорость обмена до 128 кбит/c и полное модемное управление. Sigma-22 - адаптер с двумя синхронными последовательными интерфейсами из набора V.35/RS-232 и RS-530/RS449, поддерживающих скорость обмена до 384 кбит/c. Sigma-24 - адаптер модели Sigma-22 в комплекте с двухканальной платой расширения Delta2. 3.5. Поддержка DAHDI/zaptel и IP-АТС Asterisk. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Поддержка DAHDI и Zaptel-интерфейса взаимодействия IP-АТС Asterisk доступна для адаптеров Tau-PCI/32, Tau-PCI/32-Lite, Tau-PCI/2E1 и Tau-PCI/4E1, Tau-PCI/E1. Адаптеры модификаций Tau-PCI/G.703, Tau/E1 и Tau/G.703 не поддерживаются (и не будут поддерживаться). ВНИМАНИЕ! Адаптеры "старой" серии Tau-PCI/E1 (состоят из двух плат, одна над другой) вследствие ограничений аппаратного дизайна могут работать только c порциями данных по 16 кадров E1. Что соответствует ZT_CHUNKSIZE=16 (стандартное значение ZT_CHUNKSIZE=8) и интервалу обмена/обработки в 2 ms с темпом в 500 прерываний за секунду. При работе с ZT_CHUNKSIZE != 16 могут наблюдаться заметные помехи и искажения, а работа алгоритмов эхокомпенсации будет затруднена. При сборке модулей Zaptel-стека под Linux 2.6, для некоторых версий Zaptel необходимо указывать цель linux26, т.е 'make linux26'. За более подробной информацией обращайтесь к документации по Zaptel. Важным аспектом при конфигурировании каналов DAHDI и zaptel является установка оптимального размера очередей приёма-передачи параметром qlen=#. Чем больше задаваемое значение, тем больше будет задержка, вносимая очередями и эффект телефонного эха соответственно. Минимальное значение для qlen равно 2, однако при этом требуется, чтобы система в целом успевала обрабатывать аппаратные прерывания, поступающие с темпом порядка 2000 в секунду для каждого интерфейса E1. Все версии ядер Linux линейки 2.6, в соответствующей конфигурации, могут без труда справиться с этой задачей. Проблемы возникают только при использовании драйверов устройств, которые допускают блокирование прерываний на продолжительное время (более 100 мкс). Для получения гарантированно минимальной латентности обработки прерываний и соответственно качественной работы DAHDI/zaptel рекомендуется использовать realtime-ядра Linux, см. http://people.redhat.com/~mingo/realtime-preempt/ Для минимизации проблем связанных с установкой размера очередей приёма-передачи в модулях cdahdi.ko и czaptel.ko реализовано их автоматическое увеличение в ситуациях underrun/overrun. Предусмотрена установка предела для автоматического увеличения или блокировка этого механизма с помощью параметра qlen-limit=#. Для оптимизации и облегчения работы блока эхоподавления, встроенного в DAHDI/zaptel, предусмотрена возможность регулировки задержки в поступлении данных на вход обратной связи эхоподавителя с помощью параметра ec-dealy=#. Величина задержки указывается в миллисекундах. Допускается установка задержки с точностью до 0.125 миллисекунд. Для оптимальной работы системы эхоподавления задаваемая задержка должна быть максимально близкой к (но не больше) времени прохождения сигнала от DAHDI/zaptel, через буферы приёма/передачи и аппаратуру адаптера, далее через линию E1 до hybrid-модуля (места перевода сигнала в 2-х проводную телефонную линию) и обратно до DAHDI/zaptel. По-умолчанию устанавливается значение, соответствующее задержке в буферах приёма-передачи адаптера, это же значение будет установлено при указании ec-delay=auto. Модули cdahdi.ko и czaptel позволяют использовать для телефонии как полный поток E1, так и подмножество канальных интервалов. Кроме этого, DAHDI/zaptel-стеку передается информация об аварийных ситуациях E1 (alarms) и счетчиках ошибок. После подключения протоколов dahdi или zaptel к логическому каналу невозможно изменение списка канальных интервалов, режима обработки CAS/CCS. Поэтому установку режима CAS (cas=off/pass/cross) и выбор канальных интервалов (ts=...) необходимо производить до назначения канального протокола. Установка параметров актуальных только для DAHDI/zaptel, таких как qlen-limit=# и ec-delay=#, напротив должна производиться после подключения канального протокола. При использовании /etc/cronyx.conf это обеспечивается автоматически. При использовании сигнализаций CAS-типа (E&M, MFC-R2, R2, R1.5) необходимо учитывать, что в этих случаях 16-ый канальный интервал теперь не входит в набор голосовых DAHDI/zaptel-каналов. Другими словами, в настройках chan_unicall не нужно пропускать 16-канальный интервал, так как он не попадает в набор доступный DAHDI/zaptel-стеку. Из-за ошибок в старых версиях утилиты zttool, с её помощью невозможно корректно производить мониторинг. Легко видеть, что в списке канальных интервалов пропущен 26'й и присутствует 32'й, кроме этого есть и другие ошибки. При необходимости использовать zttool к её исходным текстам рекомендуется приложить наши исправления из файла zttool.cronyx-patch, например так: patch zttool.c < zttool.cronyx-patch. В данной версии не реализовано управление DACS (прямой коммутации соединений на базе канальных интервалов). Предположительно такая функциональность будет реализована в будущем. 3.6 Непосредственный обмен в "телефонных" режимах. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Использование протокольного модуля craw.ko с адаптерами, поддерживающими "телефонный" режим, позволяет создавать программно-аппаратных комплексы обработки потоков E1.Например, системы мониторинга, тестирования или анализа E1, конвертеры телефонной сигнализации, VoIP-шлюзы, интерактивные голосовые службы, система записи/протоколирования и т.д. Вся необходимая информация по этой теме подготовлена нами на странице http://www.cronyx.ru/case/raw/ 3.7. Примеры использования sconfig. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Просмотр текущей конфигурации. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Для просмотра конфигурации адаптеров/интерфейсов/каналов: sconfig [-a] [имя-объекта] Например: sconfig sconfig -a sconfig -a tau32_0 sconfig ce0 Для просмотра "карты" оборудования, имен и псевдонимов адаптеров/интерфейсов/каналов: sconfig -r Просмотр статуса интерфейсов, счетчиков ошибок, статистики и т.д. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Для просмотра статистики/статуса адаптеров/интерфейсов/каналов (описание опций см. в разделе 2): sconfig {-sixmefut} [имя-объекта] Например: sconfig -s ce0 sconfig -m Для очистки/сброса статистики/счетчиков: sconfig -c [имя-объекта] Например: sconfig -c tau32_0.e1_0 Конфигурирование адаптеров, линейных интерфейсов и логических каналов. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Управляем адаптером Tau-PCI/32 #0, включаем светодиод и устанавливаем синхронизацию от приёмника E1-интерфеcа #1: sconfig tau32_0 led=on clock=rcv1 Управляем E1-интерфейсом #1 на адаптере Tau-PCI/32 #0, устанавливаем структурированный режим, сверхциклы CRC4 и отключаем CAS: sconfig tau32_0.e1_1 unframed=off crc4=on cas=off Управляем каналом #10 на адаптере Tau-PCI/32 #0, назначаем канальные интервалы на E1-интерфейсе #1, подключаем протокольный модуль моста Ethernet: sconfig tau32_0.10 ts=4-8 iface=1 rbrg Управляем каналом #1 на адаптере Tau-PCI/xE1, выбираем множество канальных интервалов, подключаем DAHDI-протокол, длину очереди передачи устанавливаем равной 2, отключаем механизм автоувеличения очередей: sconfig cp1 ts=1-31 qlen=2 dahdi qlen-limit=2 3.8. Конфигурирование /etc/cronyx.conf. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Для удобства работы предусмотрен файл конфигурации '/etc/cronyx.conf' и обрабатывающий его sh-сценарий. После задания требуемой конфигурации можно загрузить драйверы и применить установки командой 'cronyx.start'. Остановить каналы и выгрузить драйверы можно командой 'cronyx.stop'. В процессе установки sh-сценарий 'cronyx.sh' (из комплекта драйверов) будет установлен как одна из команд инициализации системы. Также этот сценарий будет выполняться при вызове 'cronyx.start' и 'cronyx.stop'. В зависимости от режима запуска cronyx.sh выполняет разбор параметров конфигурации, заданных в '/etc/cronyx.conf' и транслирует их в соответствующие вызовы утилит 'sconfig', 'ifconfig' и т.д. Также cronyx.sh производит загрузку (или выгрузку) модулей ядра из комплекта драйверов. Файл '/etc/cronyx.conf' и обрабатывающий его sh-сценарий 'cronyx.sh' предназначены для наиболее распространённых, простейших конфигураций. В случае, если заложенных возможностей недостаточно необходимо использовать утилиту 'sconfig'. Конфигурация в файле '/etc/cronyx.conf' задаётся в виде пар <имя-объекта>=<значение>, в синтаксисе sh. Где <имя-объекта> должно соответствовать имени адаптера, линейного интерфейса на адаптере или канала. А <значение> задаёт конфигурацию в виде списка параметров в синтаксисе утилиты sconfig. В конфигурации каналов для некоторых протоколов необходимо также задать локальный и/или удаленный IP-адреса, либо локальный MAC-адрес. Номера DLCI для Frame Relay (параметр dlci=#) следует указывать после выбора протокола, а соответствующие локальный и удаленный IP-адреса после каждого DLCI. 4. История выхода версий и изменений. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2008-09-15, 6.1-rc3: - в ce.ko количество логических каналов приёма-передачи по-умолчанию сокращено до 4. Для получения доступа к остальным каналам необходимо соответственно определить константу TAU32_CHANNELS в начале файла tau32.c; - в ce.ko добавлен контроль размера порций данных при работе в "телефонном" режиме; - добавлен импорт внешних Module.symvers для подавления предупреждений о неопределенных внешних символах при сборке czaptel.ko; - доработана логика реакции на аварийные ситуации E1 в czaptel.ko; - поддержка 2.6.26 в диагностических модулях и утилитах; - небольшие правки в коде устройств для шины ISA; - небольшие правки для устранения предупреждений при сборке для 64-битных платформ; - ошибок не обнаружено :-) - если в ближайшие 5 недель до конца октября 2008 не будет замечено неполадок, эта версия будет "заморожена" как 6.1-release. Развитие будет продолжено в версии 6.2: * поддержка только 2.6 и последующих версий ядра Linux, линейка ядер 2.4 поддерживаться больше не будет; * функционал DACS-коммутации для zaptel/asterisk; * udev и dev_fs, управление и мониторинг через sys_fs; * поддержка стека hdlc и других протоколов посредством ядра Linux; * возможно: Sigma-ISA, Tau-ISA и Omega-ISA больше поддерживаться не будут; * возможно: будут ликвидированы протокольные модули, для которых в Linux есть функциональные аналоги (cfr.ko и т.д.); 2008-08-06, 6.1.rc2: - ce.ko и cp.ko: за ненадобностью ликвидирована поддержка операции аппаратного сброса ("sconfig reset"); - tau32.c: устранена ошибка, из-за которой при очистке всей статистики ("sconfig -c") мог происходить системный сбой; 2008-08-05, 6.1.rc1: - csync.ko и casync.ko: устранена возможность взаимного ожидания между open() и close() при асинхронном закрытии файлового дескриптора (обработка ASYNC_CLOSING). Спасибо Роману Куракину за сообщение о проблеме; - устранение предупреждения о неиспользуемой декларации при сборке tau32.o; 2008-07-29, 6.1.beta6: - в протокольном модуле craw.ko исправлена ошибка в поддержке poll/select. Ошибка была внесена случайно при отладке версии 6.1.beta3. Спасибо Станиславу Локалину (МФИ Софт) за сообщение о проблеме; 2008-07-25, 6.1.beta5: - исправление в czaptel.c причины возникновения ошибки "Invalid argument" при выполнении ztcfg для span'а с включенным crc4 в zatepl.conf, ошибка проявлялась только c последними версиями zaptel, где был добавлен контроль битов span.linecompat; - исправление очепятки (был пропущен знак "!") в tau32.c, из-за чего статус E1 всегда отображался как "OFF". Спасибо Владимиру Кондратенко (SETEL.RU) за сообщение о проблеме; - доработка DDK, драйверов и утилит диагностики для корректной работы DMA на всех платформах (в частности на nVidia nForce3 и nForce4). Спасибо Владиславу Шашкову (SETEL.RU) за сообщение о проблеме и помощь в тестировании; 2008-07-18, 6.1.beta4: - доработана структура этого readme.txt; - все файлы содержащие русскоязычный текст перекодированы в UTF-8; - поддержка ядер Linux до 2.6.26; - исправления и доработки в cronyx.sh: * исправлена ошибка загрузки binder-модуля по старому имени; * исправлена ошибка, из-за которой параметры port/dma/irq не доходили до модулей cx и cp. Поэтому адаптеры серий Sigma и Tau-ISA определялись только поиском с параметрами по-умолчанию; * более аккуратная остановка pppd; * протокольные модули загружаются только при необходимости; - исправлена ошибка в DDK Sigma, из-за которой после старта канала, при передаче первого пакета размером больше одного байта, возникала ошибка "transmit underrun"; - теперь драйвер Tau-PCI, при конфигурировании канала подключаемого к интерфейсу E1, автоматически отключает канальные интервалы E1, занимаемые другими неактивными каналами; 2008-05-14, 6.1.beta3: - исправление в протокольном модуле craw.ko, была возможна ситуация рекурсивного захвата spinlock'а; 2008-05-08, 6.1.beta2: - устранены проблемы сборки с ядрами младше 2.6.20; - в Tau-PCI/32 DDK добавлена возможность установки заполнителя данных в телефонном режиме; - протокольный модуль craw.ko переведен в режим работы без использования отложенной очереди; 2008-04-24, 6.1.beta1: - для устранения конфликтов с системными именами протокольные модули переименованы с добавлением префикса 'c'; - поддержка amd64 и других архитектур, поддерживаемых актуальными ядрами Linux; - поддержка ядер Linux до 2.6.24 включительно; - доработка драйверов нижнего уровня (DDK) для обхода аппаратной ошибки в DS21554, приводящей к неправильной работе PLL (ФАПЧ). Проблема проявлялась в отдельных экземплярах адаптеров Tau-PCI/32, Tau-PCI/32-Lite, Tau-PCI/2E1 и Tau-PCI/4E1 при включении синхронизации E1 от сигнала из линии; - доработка библиотек используемых в диагностических утилитах; - доработки configure и makefile для поддержки Ubuntu и Debian; - исправление ошибок ccisco.ko и cfr.ko, внесенных ранее при доработках поддержки для новых ядер Linux; 2008-01-14, 6.0.3: - устранение передачи нулевого указателя при вызове tty->ldisс.receive_buf() для индикации ошибки, спасибо Роману Куракину за сообщение о проблеме; - добавление ddk_arch.h и ddk_host.h для возможности поддержки архитектур отличных от i386; 2007-12-18, 6.0.2: - удален неиспользуемый параметр type в proto.select(); - включен режим объединения HDLC-флагов начала и конца кадра; ! есть несколько известных, но не исправленных недочетов в сценарии установки и интеграции cronyx.start в rc.d/init.d подсистемы различных дистрибутивов; - подавление индикации ошибки "короткого кадра HDLC" при отсутствии других ошибок и наличии данных в кадре, спасибо Игорю Крымову за сообщение о проблеме; - устранение двойного освобождения spinlock'а в packet.ko, спасибо Роману Куракину за сообщение о проблеме; - новое firmware для Tau-PCI/32 и обход проблемы "нулевого канального интервала" в прозрачном режиме Infineon 20321; - устранение race при обращении к skb в sync.c, спасибо Роману Куракину за сообщение о проблеме; 2007-10-10, 6.0.1: - исправления в драйвере Omega для последних ядер; 2007-09-02, 6.0: - мелкие исправления в cisco.c и fr.c; 2007-08-24, rc27: - поддержка Ubuntu в configure и makefile; - исправлена ошибка в sconfig, из-за которой /dev/cronyx пересоздавался без необходимости. Большое спасибо Кириллу Капранову, ООО "НИТА", Спб; - исправление ошибки в firmware Tau-PCI/32. Ошибка проявлялась как повреждение данных по приёму, на некоторых экземплярах адаптеров, при определенных установках кросс-коннектора; - правки для совместимости с 2.6.22; - ликвидация блокировки прерываний в raw.ko и packet.ko; 2007-05-31, rc26: - в scondig добавлен параметр crc={off,16,32}, который задает режим подсчета CRC (FCS) для HDLC. Режимы "crc=off" и "crc=32" поддерживаются только серией адаптеров Tau-PCI/32; - доработка DDK для Tau-PCI/32, устранена еще одна возможность для "застревания" принятого HDLC-пакета; - устранена возможность зависания (recursive lock) в модуле raw.ko для SMP-ядер; - устранена опечатка, из-за которой драйвер Tau32-PCI не подсчитывал кол-во ошибок приёма/передачи; - устранена ошибочная передача AIS16 при установке режима cas=set в DDK Tau-PCI; 2007-04-25, rc25: - исправления для стабильной работы "телефонного" режима, ошибка была внесена в ходе доработок при выпуске версии rc24; - доработка makefile для извлечения ECHO-констант из zaptel-base.c в zaptel 1.4.1; - доработка czaptel.c для возможности "горячей" остановки, т.е. для вызова zt_unregister() при работающем span'е; - доработка cronyx.sh для установки ppp-mtu с учетом накладных расходов ppp. Большое спасибо Дмитрию Давыдову, ООО "Сибнет", г. Бийск; 2007-04-12, rc24: - доработка DDK адаптеров серии Tau-PCI, исправление ошибки приёма HDLC-пакетов размера близкого к MTU/MRU. Большое спасибо Дмитрию Давыдову, ООО "Сибнет", г. Бийск; - незначительная доработка драйверов адаптеров с интерфейсами E1/ИКМ-30 для блокировки информации о статусе порта E1 при включенном шлейфе; - доработка модулей сетевых протоколов и драйверов адаптеров для правильной работы tcpdump; 2007-03-20, rc23: - доработка DDK адаптеров серии Tau-PCI, для обхода неточности/ошибки в документации Siemens/Infineon 20534, из-за чего данные могли "залипать" в очереди на передачу до следующей порции. Одно из проявлений проблемы - задержка ping'ов до 1000 мс, или точнее говоря до следующего ICMP-запроса (как правило 100 мс) или другого отправляемого пакета; - доработка DDK адаптеров серии Tau-PCI/32, для обхода ошибки в логике формирования DMA-payload при работе в прозрачном (aka "телефонном") режиме логических каналов в Siemens/Infineon 20321; - доработка драйвера и DDK адаптеров серии Tau-PCI для учета ошибки в логике контроля превышения максимального размера HDLC-пакетов в Siemens/Infineon 20534. Актуальный размер MTU/MRU теперь на один байт меньше; 2007-03-12, rc22: - исправления в czaptel.c: упрощен код обработки span->open/close(), теперь запуск/остановка канального уровня производится только в span->startup/shutdown(); 2007-03-05, rc21: - исправление в czaptel.c для правильной обработки многократных span->open() при взаимодействии с zaptel 1.4.x; - контроль допустимости установки mtu в модуле cisco.c (поддержка Cisco-HDLC); - корректировка размера mtu с учетом служебных полей HDLC в tau-pci.c; 2007-02-09, rc20: - устранение ошибок в fr.c при сборе принимаемых фрагментов FRF.12; - в fr.c реализована фрагментация FRF.12 при передаче; - небольшая доработка DDK для Tau-PCI; 2007-02-07, rc19: - совместимость с Linux 2.6.20; - устранение ошибки в fr.c в поддержке нескольких DLCI; - в cronyx.conf поправлен пример конфигурации для FrameRelay/DLCI; - в czaptel.c изменен log-уровень сообщения "rx-backlog underflow"; 2007-01-25, rc18: - доработка czaptel.c для совместимости с многократными open/close в Zaptel 1.4.x; - незначительная правка sconfig и sh-скрипта для возможности запуска pppd не в "sync"-режиме; - устранение недоработок в Makefile c zaptel-echostate-def.h; 2007-01-25, rc17: - доработка czaptel.c для совместимости с Zaptel 1.4.x; - в czaptel.c добавлена диагностика об underflow-ситуации backlog-буфера по приёму; - доработка Makefile для "выдергивания" определений констант ECHO_STATE_* из исходного кода Zaptel-стека; - правка sh-скрипта для указания mtu при запуске pppd в sync-режиме; - изменения в DDK для Tau-PCI для предотвращения генерации прерываний при запуске канала без предварительного разрешения генерации прерываний; 2007-01-24, rc16: - доработка czaptel.c, в связи с несовместимостью с Zaptel 1.4.x, теперь при открытии span-а делает необходимая проверка; - доработка czaptel.c, для обеспечения синхронной обработки приёма и передачи реализован backlog-буфер по приёму; - изменения в tau32.c, в связи с доработкой zaptel-модуля удален код, гарантирующий обслуживание по приёма после передачи; - изменения в DDK для Tau-PCI: * исправление кода инициализации, в случае ошибки инициализировались не все указатели; * изменение кода обработки прерываний, в связи с доработкой zaptel-модуля удален код, гарантирующий обслуживание по приёму после передачи; - доработки taucpi.c, как требует новый Tau-PCI DDK теперь всегда выполняется полный аппаратный сброс контроллера Infineon PEB20354; - в связи с доработкой драйвера Tau-PCI из sconfig удалена опция "hardware-reset". 2007-01-23, rc15: - изменения в DDK для Tau-PCI: * устранение возможности переполнения входящей очереди при отсутствии данных на передачу в "телефонном" режиме; 2007-01-19, rc14: - исправление в async.c и sync.c для устранения EEXIST при регистрации tty-устройств; - исправления в async.c и sync.c для устранения возможности deadlock; - исправление в cronyx.sh для остановки pppd; - большие изменения в DDK для Tau-PCI: * изменен режим работы контроллера Infineon PEB20534 c дескрипторами DMA. (HOLD-биты больше не используются); * для стабильной работы чипа Infineon PEB20534 всегда производиться его аппаратный сброс; * переработан код обработки прерываний, инициализации, остановке и т.д.; * переработана поддержка "телефонного" режима. Зафиксирован размер порции данных для "старой" серии адаптеров Tau-PCI/E1 (состоит из двух частей, одна над другой); * При работе в телефонном режиме с "совмещенными" прерываниями и отсутствии данных на передачу будут автоматически подставляются "заглушки" с кодом "все единицы"; * теперь при работе в "телефонном" режиме адаптеры "старой" серии Tau-PCI/E1 продолжают генерировать входящий поток данных при потере несущей E1; - устранен сброс mtu в значение по умолчанию при старте каналов Tau-PCI/xE1 в "телефонном" режиме; - в драйвере fr.c добавлен механизм ответов на запросы удаленной стороны; 2006-12-26, rc13: - устранена проблема сборки для версий Linux 2.6.x без gfp_t; - при работе в "телефонном" режиме, прерывания от E1-интерфейсов больше не порождают джиттер в темпе прерываний по приёму; - теперь при работе в "телефонном" режиме уведомления о приёме и передачи порций данных синхронизированы. Вначале всегда вызывает уведомление о передаче и затем сразу о приёме. Это детерминирует работу клиентского ПО, в частности Zaptel-стека; - теперь при работе в "телефонном" режиме адаптеры серии Tau-PCI/xE1 продолжают генерировать входящий поток данных при потере несущей E1; - косметические доработки в tau32.c и taupci.c; - исправлена ошибка в tau32.c, которая могла приводить к зацикливанию при остановке логического канала (был пропущен знак '!'); 2006-12-15, rc12: - уменьшено вдвое кол-во генерируемых прерываний при работе в "телефонном" режиме адаптеров серий Tau-PCI/32 и Tau-PCI/xE1. Для серии Tau-PCI/32 это возможно только когда все используемые логические каналы работают в "телефонном" режиме; - небольшие изменения в czaptel.ko при обслуживании кольцевого буфера ec-feedback; - использование mempool в 2.6.x; - совместимость с 2.6.19; - исправление нескольких мелких некритичных неточностей; - замена error на warning при контроле прав root'а в configure; 2006-11-23, rc11: - в binder.c добавлена явная диагностика о невозможности выделить память при организации отложенной обработки; - доработка DDK для Tau-PCI: Теперь при установке baudrate на последовательных интерфейсах видна реальная результирующая скорость; - доработка DDK для Tau-PCI: В обработчик прерывания добавлена проверка ситуации "отставания" записи со стороны PCI-контроллера в очередь прерываний и обновлении DMA-дескрипторов от момента выставления IRQ-запроса. Что при специфической загрузке PCI-шины могло приводить к "залипанию" передатчика и/или приёмника; 2006-10-31, rc10: - в czaptel.ko и sconfig добавлена возможность регулировки задержки данных в пути обратной связи эхоподавителя с помощью ec-delay=; - в czaptel.ko и sconfig добавлен параметр qlen-limit= для ограничения автоматического увеличения длины очередей приёма-передачи; - доработка кода контроля underrun для Tau-PCI/xE1; - переработка формирования sigcap-флагов в czaptel.c; 2006-10-04, rc9: - исправление ошибок в makefile и configure; 2006-10-02, rc8: - исправления в русскоязычной и англоязычной версиях readme.txt; - man-страница на русском языке; - исправления в англоязычной man-странице; - доработка configure и makefile для установки русскоязычной man-страницы с авто-определением кодировки кириллицы; - в configure добавлены опции --with-manpath-ru=.., --with-manpath-en=.., --with-man-encoding=..; 2006-09-27, rc7: - новая man-страница по sconfig, пока только на английском; - англоязычная версия readme; - исправления в русскоязычной версии readme; 2006-09-20, rc6: - доработка configure, async.c и sync.c для поддержки 2.6.18; - блокировка отключения протокола zaptel, если span используется; - существенное пополнение содержимого этого readme; - к configure добавлена опция --with-cronyx-major=..; 2006-09-12, rc5: - доработка интерфейса binder.ko для устранения возможности тупиковых ситуаций (oops) при выгрузке модулей; - исправления в сценарии cronyx.sh для корректного разбора DLCI, правильной остановки сетевых интерфейсов и удаления маршрутов; - мелкие исправления в sconfig для правильной работы cronyx.sh; rc3->rc4: - исправлена ошибка в разборе параметра "dlci=..." в sconfig-main.c; - в начало сценария cronyx.sh добавлен заголовок для chkconfig; rc2->rc3: - в DDK и драйвере Tau-PCI/xE1 реализован контроль underrun при работе в "телефонном" режиме; - в драйвере Tau-PCI/xE1 изменено кол-во буферов приёма/передачи, реализовано формальное управление длиной очередей; - в czaptel.ko реализовано автоматическое увеличение длины очередей приёма/передачи, при обнаружении overrun/underrun; rc1->rc2: - устранена возможность deadlock в binder.ko; - в DDK и драйвере Tau-PCI/xE1 реализована поддержка режимов cas=off/set/pass/cross, ликвидирован параметр use16; ___________________________________________________________________________ Copyright (C) 1998-2009 КБ Кроникс