<![CDATA[Форум Рутокен — Rutoken S + ECS BAT-I v1.2]]> https://forum.rutoken.ru/topic/2844/ Tue, 11 Sep 2018 09:52:50 +0000 PunBB <![CDATA[Re: Rutoken S + ECS BAT-I v1.2]]> https://forum.rutoken.ru/post/12089/#p12089 Рады, что у вас получилось!

]]> Tue, 11 Sep 2018 09:52:50 +0000 https://forum.rutoken.ru/post/12089/#p12089 <![CDATA[Re: Rutoken S + ECS BAT-I v1.2]]> https://forum.rutoken.ru/post/12086/#p12086 Update
Если кому-либо будет интересно (или столкнутся с подобными проблемами на других мат.платах) - косяк был в ядре, но и не в ядре...
Короче говоря, новая чистая установка Debian 9 на машину с мат.платой ECS BAT-I v1.2 + отключение опции Legacy USB + включение опции xHCI на постоянной основе (вместо Auto в Enable) + legacy-boot в режиме "Windows 7 or Other OS" показала корректность работы на стоковом ядре (4.9)...
Далее обновление ядра до 4.17.0-bpo.1 через репозиторий stretch-backports (загрузка linux-headers-4.17.0-bpo.1 и linux-image-4.17.0-bpo.1) вместо gentoo-way по пересборке ядра из исходников с kernel.org + установка драйверов Rutoken S и необходимых зависимостей для pcscd решила проблему полностью!
Любопытно, что размер ядер, собранного по технологии Debian и собранного из исходников, одинаков вплоть до байта. Т.е. где-то в коде одного из usb-модулей (подозреваю, что xhci.ko) имелся баг, вошедший "в клинч" с некорректной реализацией поддержки USB на уровне мат.платы. Возможно, какая-нибудь debug-опция, т.е. debug-вызов мог привести к останову ядра и краху системы...
Вывод: обновляйте ядро правильно и не покупайте кривые мат.платы :)

]]> Mon, 10 Sep 2018 09:12:00 +0000 https://forum.rutoken.ru/post/12086/#p12086 <![CDATA[Re: Rutoken S + ECS BAT-I v1.2]]> https://forum.rutoken.ru/post/12076/#p12076 to Владимир Салыкин
Спасибо!
От Рутокен S отказаться, увы, нельзя. Но вроде разобрался - проблема все-таки ядерная, вернее в кривой реализации xhci в мат.плате и его кривой поддержки в ядре 4.17.0-bpo. Буду либо собирать с другим ядром, либо пересобирать модули xhci. В любом случае, тему, пожалуй, можно закрывать. Обидно, что мат.платы настолько кривые - на других машинах (с другими мат.платами) все завелось без сучка без задоринки...

]]> Wed, 05 Sep 2018 16:32:45 +0000 https://forum.rutoken.ru/post/12076/#p12076 <![CDATA[Re: Rutoken S + ECS BAT-I v1.2]]> https://forum.rutoken.ru/post/12074/#p12074 Добрый день, akademik.

Похоже дело действительно в какой-то аппаратной несовместимости несовместимости USB контроллера мат.платы и устройств Рутокен S. Единственные варианты, которые мы видим, это использовать другие модели токенов, все таки Рутокен S это старая модель. Или портировать изменения между ядрами linux в USB стеке.

]]> Wed, 05 Sep 2018 13:18:56 +0000 https://forum.rutoken.ru/post/12074/#p12074 <![CDATA[Re: Rutoken S + ECS BAT-I v1.2]]> https://forum.rutoken.ru/post/12072/#p12072 Добился положительного результата под Win7 и Debian 8. Проблема в том, что мат.плата не отключает режим xHCI-hangoff (попросту отсутствует понятие Disable, только Enable, Auto и Smart Auto). Тем не менее, при отключении Legacy USB и xHCI-Enable на Debian 8 (ядро 3.16) в той же конфигурации pcsc_scan уже не вызывает останов системы. Драйвер Rutoken S оригинальный и последний с сайта (1.0.4-i386).
Однако нужен Debian 9 с нестандартным ядром (4.17.0-bpo), на котором при этих настройках все равно система падает.

]]> Mon, 03 Sep 2018 20:45:48 +0000 https://forum.rutoken.ru/post/12072/#p12072 <![CDATA[Rutoken S + ECS BAT-I v1.2]]> https://forum.rutoken.ru/post/12071/#p12071 Здравствуйте!
Закупили партию Rutoken S (вер. 51.00.36.03) для ИАФ пользователей во внутренней сети. Часть машин базируется на мат.плате ECS BAT-I v1.2 (Elitegroup). На них наблюдается странная картина: вне зависимости от типа ОС (по штату предполагалась работа под Debian 9, но проверялось так же под Win7 Pro) при подключении Rutoken S и выполнении к нему запроса (через Панель управления Рутокен, через pcsc_scan, через софт для ИАФ) происходит аварийный останов машины. Т.е. отключаются USB-устройства, зависают все исполняемые процессы и т.д. - помогает только выключение машины по кнопке питания либо горячая перезагрузка. Аналогичная ситуация проявляется и при загрузке машины на этапе POST BIOS, если к ней подключить Rutoken S.
Гугл подсказал единственную схожую тему: https://forum.alta.ru/viewtopic.php?f=36&t=25561
С режимами Legacy USB играл. Их отключение позволило игнорировать Rutoken S на этапе загрузки BIOS. Но как только происходит обращение к Rutoken S в любой ОС - все повторяется вновь.
ПО BIOS прошивал (стоковая версия AMI 2.16.1242 за 2013 г., после прошивки - AMI 2.17.1249 за 2016 г., последняя от производителя). Пробовал другие версии Rutoken S (вер. 32.00.21.03). Не помогло, увы.

Собственно, вопрос: нам "повезло" с версией мат.платы, т.е. попали на мизерный процент аппаратной несовместимости? Или есть какое-либо решение?

Заранее спасибо!

]]> Mon, 03 Sep 2018 12:11:20 +0000 https://forum.rutoken.ru/post/12071/#p12071