что такое модуль dpio

Перестал работать PCI-девайс 🙁

Написал простенькую прогу, обмен проиходит по известному алгоритму, скопированному из досовской проги, из «железных» функций использую только in_p, out_p, iopl(). Всё работало зашибись.

Потом, когда делал к проге всякие навороты, плата вдруг работать перестала. Причём не работают даже первые примитивные варианты проги, которые раньше работали.

Кроме того, теперь при загрузке комп выдаёт (можно потом посмотреть с помощью dmesg):

Пробовал презагружаться, пихать плату в другой pci-слот, загружаться через recovery mode. Не помогает, все порты остаются disabled:( При этом в DOS’е всё работает окей, и на другой машине в Xubuntu всё окей.

В самой плате, вроде, ничего нет, что можно было бы сломать экспериментами с ПО. Неужели механически, что-то треснуло? Глазами повреждений не нашёл, контакты протирал. Да и в ДОСе всё работает.

Что тут можно сделать в принципе? Может в самой Убунте можно как-то обнулить записи про эту плату, сделать так, чтоб порты не были disabled?

BIOS пробовал сбрасывать? Еще может в платке прошивка своя сырая.

а на той же машинке, но с лайв убунты работает? кстати если в досе работает, то просто не может быть такого что с платой что-то нарушено, кстати другие девайсы в pci там звуковая или сеть работают?

BIOS пробовал сбрасывать? Еще может в платке прошивка своя сырая.

Пока не пробовал, завтра попробую. Может ещё стоит поэкспериментировать с номерами прерываний?

а на той же машинке, но с лайв убунты работает?

Не, и с лайва не работает 🙁 Не могу понять, что может быть такого, что в ДОСе работает, а в убунте блокируется(

кстати если в досе работает, то просто не может быть такого что с платой что-то нарушено, кстати другие девайсы в pci там звуковая или сеть работают?

Всё остальное работает. Но есть один момент. на старом компе, на котором Xubuntu, если эту плату ткнуть в определённый слот, то видюха не работает) а если в другой слот, то всё как надо) ну это наверно уже к вопросу об архитектуре современных PC, тут мне кажется проблема с портами не при чём:)

Твое это устройство поддерживает Plug and Play? Не рассматривал вариант, что у него конфликт прерываний с чем-то из оборудования?

Возможно, твоя плата хочет использовать смежные ресурсы с какой-то из железяк, установленных в компьютер. А работает в ДОСе по причине того, что в ДОСе не подгружается драйвер под конфликтующую железяку и она не активна.

Твое это устройство поддерживает Plug and Play?

хз.. плату сделали на работе, по сути это АЦП, который общается по PCI с компом с помощью PLX9050. Попробую узнать. Если нет, то это очень плохо?:)

Не рассматривал вариант, что у него конфликт прерываний с чем-то из оборудования?

Была такая мысль, сейчас думаю как бы отследить, где именно конфликт.

Возможно, твоя плата хочет использовать смежные ресурсы с какой-то из железяк, установленных в компьютер. А работает в ДОСе по причине того, что в ДОСе не подгружается драйвер под конфликтующую железяку и она не активна.

Толковая идея, буду пробовать разобраться. Спасибо!

хз.. плату сделали на работе, по сути это АЦП, который общается по PCI с компом с помощью PLX9050. Попробую узнать. Если нет, то это очень плохо?:)

Это не плохо, просто означает, что ОС не знает какие параметры нужны устройству для корректного функционирования, и эти параметры как-то надо задать руками.

Была такая мысль, сейчас думаю как бы отследить, где именно конфликт.

Отключи всю периферию и максимум интегрированных устройств

>Всё остальное работает. Но есть один момент. на старом компе, на котором Xubuntu, если эту плату ткнуть в определённый слот, то видюха не работает) а если в другой слот, то всё как надо) ну это наверно уже к вопросу об архитектуре современных PC, тут мне кажется проблема с портами не при чём

Если на компе той эпохи распаяны все пять разъёмов PCI, то первый и пятый делят между собой ресурсы.

Источник

Наглядный обзор оптических передатчиков

Часто у знакомых системных администраторов, не сталкивавшихся раньше с оптическим волокном, возникают вопросы, как и какое оборудование необходимо для организации соединения. Немного почитав, становится понятно, что нужен оптический трансивер. В этой обзорной статье я напишу основные характеристики оптических модулей для приема/передачи информации, расскажу основные моменты, связанные с их использованием, и приложу много наглядных изображений с ними. Осторожно, под катом много трафика, делал кучу своих собственных фотографий.

Что и зачем

Сегодня практически любое сетевое оборудование для передачи данных в сетях Ethernet, предоставляющее возможность подключения через оптическое волокно, имеет оптические порты. В них устанавливаются оптические модули, в которые уже может подключаться волокно. В каждый модуль встроен оптический передатчик (лазер) и приемник (фотоприемник). При классической передаче данных с их использованием предполагается использовать два оптических волокна — одно для приема, другое для передачи. На изображении снизу представлен коммутатор с оптическими портами и установленными модулями.

Вот об этих маленьких электронных штуковинах дальше и пойдет речь.

Виды оптических модулей

Периодически возникают вопросы, какой же оптический приемопередатчик нужен в конкретной ситуации. Если перед глазами оказывается прайслист какой-либо, то просто разбегаются глаза от обилия всевозможных наименований. Попробую прояснить, что же значат различные буквы и цифры в названии модулей и что же из них вам может понадобиться. Оптические модули различаются формфактором (GBIC, SFP, X2. ), типом технологии («прямые», CWDM, WDM, DWDM. ), мощностью (в дицебелах), разъемами (FC, LC, SC).

Различные формфакторы

В первую очередь модули различаются своими формфакторами. Немного расскажу про различные варианты.

GigaBit Interface Converter, активно использовался в 2000-х. Самый первый промышленно стандартизованный формат модулей. Очень часто применялся при передачи через многомодовые волокна. Сейчас же практически не используется в силу своих размеров. У меня осталась одна старая циска 3500, еще без поддержки CEF, в которой можно воспользоваться данными модулями. На изображении снизу два GBIC-модуля 1000Base-LX и 1000Base-T:

Small Form-factor Pluggable, наследник GBIC. Наверно самый распространенный на сегодняшний день формат, гораздо удобнее в силу меньших размеров. Такой формфактор позволил значительно увеличить плотность портов на сетевом оборудовании. Благодаря таким размерам стало возможно реализовать до 52 оптических портов на одной железке в один юнит. Используется для передачи данных на скоростях 100Mbits, 1000Mbits. На изображении снизу коммутатор с оптическими портами и пара модулей 1000Base-LX и 1000Base-T.

Enhanced Small Form-factor Pluggable. Имеют идеентичный SFP размер. Схожий размер позволил сделать оборудование с портами, поддерживающими обычные SFP и SFP+. Такие порты могут работать в режимах 1000Base/10GBase. Лишь дальнобойные CWDM-модули имеют большую длину из-за радиатора. Используются для передачи данных на скоростях 10 Gbits. Малые размеры придали некоторые особенности — для дальнобойных модулей бывают случаи слишком сильного нагрева. Поэтому для передачи более чем на 80 км таких модулей пока нет. На картинке снизу два модуля SFP+ — CWDM и обычный 10GEBase-LR:

10 Gigabit Small Form Factor Pluggable. Также, как и SFP+, используются для передачи данных на скоростях 10 Gbits. Но в отличии от предыдущих, немного шире. Увеличенный размер позволил использовать их для прострела на большие расстояние по стравнению с SFP+. Снизу дополнительная плата для Huawei с установленными XFP и пара таких модулей.

XENPAK

Модули, используемые преимущественно в оборудовании Cisco. Используются для передачи данных на скоростях 10 Gbits. Сейчас уже изредка можно найти им применение, изредка можно встретить в старых линейках маршрутизаторов. Также такие модули бывают для подключения медного провода 10GBase-CX4. К сожалению, у меня нашелся лишь один XENPAK-модуль 10GEBase-LR и старая Cisco-вская плата WS-X6704-10GE под них.

Дальнейшее развитие модулей формата XENPAK. Часто в разъемы X2 можно установить модуль TwinGig, в который уже можно установить два модуля SFP… Это нужно в случае, если на оборудовании нет 1GE оптических портов. В основном X2-формфактор использует Cisco. В продаже существуют адаптеры X2-SFP+ (XENPACK-to-SFP+). Интересно, что такой комплект (адаптер+SFP+ модуль) выходит дешевле одного X2 модуля.
К сожалению, на руках у меня нашелся только адаптер, но чтобы понять, как выглядят эти модули и какого они размера этого вполне хватит. На рисунке снизу адаптер X2-SFP+ со вставленным SFP+ модулем.

Но если кому интересно, вот здесь можно посмотреть больше картинок и возможностей этого разъема.

Да, я не затрагивал относительно новые формфакторы (QSFP, QSFP+, CFP). На текущий момент они еще не очень распространены.

Различные стандарты

С использованием спектрального уплотнения

Описанные выше оптические модули передают сигнал в основном на длине волны 1310 нм или 1550 нм на двух волокнах (одно для передачи, другое для приема). Они имеют широкополосный фотоприемник (принимают все) и лазер, излучающий на определенной длине волны (грубо конечно). Но имеется возможность использовать уплотнение по длине волны. Это дает возможность использовать меньшее количество волокон для организации нескольких каналов тем самым увеличивая пропускную способность одного волокна.

Такие модули работают в паре, с одной стороны сигнал передается на длине волны 1310 нм, с другой 1550 нм. Это позволяет вместо двух волокон для организации одного канала использовать одно. Приемник на таких модулях так и остается широкополосным. Бывают как для 1GE, так и для 10GE. Снизу фотографии пары WDM-модулей с различными разъемами для подключения патчкордов LC и SC.

В большинстве случаев предпочтительнее использовать WDM-модули для малых расстояний. Их цена не очень большая (по 1 тыс рублей за модуль против 500 рублей за обычный). Причина — вы экономите целое волокно, на нем можно будет потом еще один такой же канал прогнать. Хотя конечно есть и другие способы экономии волокон.

Дальнейшее продолжение технологии WDM. С ее использованием можно добиться до 8 дуплексных каналов по одному волокну. Для этих целей используются CWDM-мультиплексоры (пассивные устройства с призмой внутри, позволяющей делить сигнал по цветам с шагом 20нм в диапазоне от 1270нм до 1610нм). Для этого также используют специальные CWDM-модули, в простонародье их называют «цветные», они передают сигнал на определенной длине волны. В то же время приемник на них широкополосный. Кроме того, такие оптические модули часто делают для передачи на большие расстояние (до 160 км). На рисунке ниже представлен малый комплект CWDM-SFP, на котором с использованием мультиплексоров можно поднять 2GE на одном волокне.

Как можно заметить, дужки у всех разные. В зависимости от длины волны модуль имеет свою раскраску. К сожалению, у всех производителей они разные.

Здесь появляется понятие оптический бюджет. Правда его расчет выходит за рамки этой статьи. В кратце, чем больше доступных портов, тем больше вы сможете смультиплексировать каналов, тем больше будет затухание. Кроме того, различные длины волн дают различные затухания на 1 километр передаваемого сигнала. А еще нужно учитывать тип волокна…

Можно много писать о методиках подбора таких модулей, о пересечении длин волн, о нежелательных длинах, о ADD/DROP-модулях. Но это отдельная тема.

Разъемы

Это то место, куда вы будете подключать оптический патчкорд. На оптических модулях сейчас используются преимущественно два типа раъемов — SC и LC. Грубо и жаргонно — большой и мелкий квадраты. Понятно, что имея в наличии патчкорд с разъемом SC, вы не подсоедините его к разъему LC. Нужно либо менять патчкорд, либо ставить переходник-адаптер. В большинстве случаев SFP-модули имеют разъем LC, в то время как X2/XENPAK — SC. Выше на изображениях уже были модули с различными разъемами.

Оптические патчкорды, они же оптические шнуры. Нас будут интересовать следующие характеристики: дуплекс/симплекс (количество волокон), полировка (сейчас это UPC-синие или APC-зеленые), разъем (SC, LC, FC), многомодовость и длина. Конечно, важна еще и толщина сердцевины волокна, но сейчас на многомодовые обычные шнуры используют стандартную толщину. Снизу я представил изображение с различными видами концов патчкордов.

В основном вы будете встречать следующее обозначение шнуров — ШО-2SM-SC/UPC-SC/UPC-3.0. Это расшифровывается следующим образом: Шнур Оптический Дуплексный Одномодовый (Single-Mode) с разъемами SC и полировкой UPC с одной стороны и SC-UPC с другой длиной 3.0 метра. Соответственно, например, ШО-SM-LC/APC-SC/APC-15.0 — одномодовый дуплексный шнур с разъемами LC-LC и гравировкой APC длиной 15 метров.

Неоторые особенности

Оптические модули — активное оборудование, они потребяют электроэнергию и выделяют тепло. Это следует учитывать при подключении оборудования к электросети. Также коммутатор, заполненный мощными модулями под завязку может потребовать дополнительного охлаждения.

Не стоит забывать, что в оптические модули встроены лазеры, и с ними необходимо соблюдать некоторую технику безопасности. Конечно в большинстве случаев никакой угрозы они не предоставляют в силу слабой мощности, но бывали случаи, дальнобойные мощные 10GE модули могут вполне выжечь сетчатку глаза или оставить ожог, если использовать палец в качестве аттюниатора.

Современные оптические модули имеют функцию DDM (Digital Diagnostics Monitoring) — в них встроен ряд сенсоров, через которые можно определить текущее значение некоторых параметров. Смотрится это через интерфейс оборудования, в которое установлен модуль. Самые важные параметры для вас — текущие принимаемая мощность и температура.

Ряд производителей сетевого оборудования запрещают использовать сторонние модули в их оборудовании. По крайней мере раньше Cisco не давала их запускать, они в ней просто не работали. Сейчас же в узких кругах известны команды, открывающие возможность использовать сторонние устройства, да и Cisco стала не так трепетно относиться к этому вопросу. Впрочем, при желании любые модули можно перепрошить, в продаже имеются специальные программаторы.

Порт на оборудовании (в большинстве случаев) загорается, если на модуль приходит сигнал достаточной мощности. Если соединить два двухволоконных модуля одинарным патчкордом (просто прием с передачей), с одной стороны порт загорится, но работать при этом ничего не будет.

Да, мощность может быть не только слабой. Если сигнал приходит слишком сильный, можно сжечь фотоприемник. Обычно это относится к дальнобойными мощным модулям с дистанцией > 80 км. Для уменьшения мощности используют специальные аттенюаторы. Хотя если делаем в лабораторных условиях, можно просто намотать пару витков патчкорда на какую-нибудь ручку или карандаш.

Источник

Работаем с модулями ядра в Linux

Ядро — это та часть операционной системы, работа которой полностью скрыта от пользователя, т. к. пользователь с ним не работает напрямую: пользователь работает с программами. Но, тем не менее, без ядра невозможна работа ни одной программы, т.е. они без ядра бесполезны. Этот механизм чем-то напоминает отношения официанта и клиента: работа хорошего официанта должна быть практически незаметна для клиента, но без официанта клиент не сможет передать заказ повару, и этот заказ не будет доставлен.
В Linux ядро монолитное, т.е. все его драйвера и подсистемы работают в своем адресном пространстве, отделенном от пользовательского. Сам термин «монолит» говорит о том, что в ядре сконцентрировано всё, и, по логике, ничего не может в него добавляться или удаляться. В случае с ядром Linux — это правда лишь отчасти: ядро Linux может работать в таком режиме, однако, в подавляющем большинстве сборок возможна модификация части кода ядра без его перекомпиляции, и даже без его выгрузки. Это достигается путем загрузки и выгрузки некоторых частей ядра, которые называются модулями. Чаще всего в процессе работы необходимо подключать модули драйверов устройств, поддержки криптографических алгоритмов, сетевых средств, и, чтобы уметь это правильно делать, нужно разбираться в строении ядра и уметь правильно работать с его модулями. Об этом и пойдет речь в этой статье.

В современных ядрах при подключении оборудования модули подключаются автоматически, а это событие обрабатывается демоном udev, который создает соответствующий файл устройства в каталоге «/dev». Все это выполняется в том случае, если соответствующий модуль корректно установлен в дерево модулей. В случае с файловыми системами ситуация та же: при попытке монтирования файловой системы ядро подгружает необходимый модуль автоматически, и выполняет монтирование.
Если необходимость в модуле не на столько очевидна, ядро его не загружает самостоятельно. Например, для поддержки функции шифрования на loop устройстве нужно вручную подгрузить модуль «cryptoloop», а для непосредственного шифрования — модуль алгоритма шифрования, например «blowfish».

Поиск необходимого модуля

Модули хранятся в каталоге «/lib/modules/ » в виде файлов с расширением «ko». Для получения списка всех модулей из дерева можно выполнить команду поиска всех файлов с расширением «ko» в каталоге с модулями текущего ядра:

filename: /lib/modules/2.6.38-gentoo-r1/kernel/drivers/net/wireless/rt2x00/rt73usb.ko
license: GPL
firmware: rt73.bin
description: Ralink RT73 USB Wireless LAN driver.
version: 2.3.0
author: rt2x00.serialmonkey.com
depends: rt2x00lib,rt2x00usb,crc-itu-t
vermagic: 2.6.38-gentoo-r1 SMP preempt mod_unload modversions CORE2
parm: nohwcrypt:Disable hardware encryption. (bool)

Поле «firmware» указывает на то, что этот модуль сам по себе не работает, ему нужна бинарная микропрограмма устройства в специальном файле «rt73.bin». Необходимость в файле микропрограммы появилась в связи с тем, что интерфейс взаимодействия с устройством закрыт, и эти функции возложены на файл прошивки (firmware). Взять firmware можно с сайта разработчика, установочного диска, поставляемого вместе с устройством, или где-нибудь в репозиториях дистрибутива, затем нужно его скопировать в каталог «/lib/firmware», при чем имя файла должно совпадать с тем, что указано в модуле.
Следующее поле, на которое нужно обратить внимание — это поле «depends». Здесь перечислены модули, от которых зависит данный. Логично предположить, что модули друг от друга зависят, например модуль поддержки USB накопителей зависит от модуля поддержки USB контроллера. Эти зависимости просчитываются автоматически, и будут описаны ниже.
Последнее важное поле — «param». Здесь описаны все параметры, которые может принимать модуль при загрузке, и их описания. В данном случае возможен только один: «nohwcrypt», который, судя по описанию, отключает аппаратное шифрование. В скобках указан тип значения параметра.
Более подробную информацию о модуле можно прочитать в документации к исходным кодам ядра (каталог Documentation) в дереве исходных кодов. Например, найти код нужного видеорежима драйвера «vesafb» можно в файле документации «Documentation/fb/vesafb.txt» относительно корня дерева исходных кодов.

Загрузка и выгрузка модулей

Загрузить модуль в ядро можно при помощи двух команд: «insmod» и «modprobe», отличающихся друг от друга возможностью просчета и удовлетворения зависимостей. Команда «insmod» загружает конкретный файл с расширением «ko», при этом, если модуль зависит от других модулей, еще не загруженных в ядро, команда выдаст ошибку, и не загрузит модуль. Команда «modprobe» работает только с деревом модулей, и возможна загрузка только оттуда по имени модуля, а не по имени файла. Отсюда следует область применения этих команд: при помощи «insmod» подгружается файл модуля из произвольного места файловой системы (например, пользователь скомпилировал модули и перед переносом в дерево ядра решил проверить его работоспособность), а «modprobe» — для подгрузки уже готовых модулей, включенных в дерево модулей текущей версии ядра. Например, для загрузки модуля ядра «rt73usb» из дерева ядра, включая все зависимости, и отключив аппаратное шифрование, нужно выполнить команду:

# modprobe rt73usb nohwcrypt=0

Загрузка этого модуля командой «insmod» произойдет следующим образом:

# insmod /lib/modules/2.6.38-gentoo-r1/kernel/drivers/net/wireless/rt2x00/rt73usb.ko nohwcrypt=0

Но нужно помнить, что при использовании «insmod» все зависимости придется подгружать вручную. Поэтому эта команда постепенно вытесняется командой «modprobe».

После загрузки модуля можно проверить его наличие в списке загруженных в ядро модулей при помощи команды «lsmod»:

# lsmod | grep rt73usb

Из вывода команды ясно, что модуль подгружен, а так же в своей работе использует другие модули.
Чтобы его выгрузить, можно воспользоваться командой «rmmod» или той же командой «modprobe» с ключем «-r». В качестве параметра обоим командам нужно передать только имя модуля. Если модуль не используется, то он будет выгружен, а если используется — будет выдана ошибка, и придется выгружать все модули, которые от него зависят:

# rmmod rt2x00usb
ERROR: Module rt2x00usb is in use by rt73usb

# rmmod rt73usb
# rmmod rt2x00usb

После выгрузки модуля все возможности, которые он предоставлял, будут удалены из таблицы ядра.

Для автоматической загрузки модулей в разных дистрибутивах предусмотрены разные механизмы. Я не буду вдаваться здесь в подробности, они для каждого дистрибутива свои, но один метод загрузки всегда действенен и удобен: при помощи стартовых скриптов. В тех же RedHat системах можно записать команды загрузки модуля прямо в «/etc/rc.d/rc.local» со всеми опциями.
Файлы конфигурация модулей находится в каталоге «/etc/modprobe.d/» и имеют расширение «conf». В этих файлах преимущественно перечисляются альтернативные имена модулей, их параметры, применяемые при их загрузке, а так же черные списки, запрещенные для загрузки. Например, чтобы вышеупомянутый модуль сразу загружался с опцией «nohwcrypt=1» нужно создать файл, в котором записать строку:

options rt73usb nohwcrypt=1

Черный список модулей хранится преимущественно в файле «/etc/modules.d/blacklist.conf» в формате «blacklist ». Используется эта функция для запрета загрузки глючных или конфликтных модулей.

Сборка модуля и добавление его в дерево

Иногда нужного драйвера в ядре нет, поэтому приходится его компилировать вручную. Это так же тот случай, если дополнительное ПО требует добавление своего модуля в ядро, типа vmware, virtualbox или пакет поддержки карт Nvidia. Сам процесс компиляции не отличается от процесса сборки программы, но определенные требования все же есть.
Во первых, нужен компилятор. Обычно установка «gcc» устанавливает все, что нужно для сборки модуля. Если чего-то не хватает — программа сборки об этом скажет, и нужно будет доустановить недостающие пакеты.
Во вторых, нужны заголовочные файлы ядра. Дело в том, что модули ядра всегда собираются вместе с ядром, используя его заголовочные файлы, т.к. любое отклонение и несоответствие версий модуля и загруженного ядра ведет к невозможности загрузить этот модуль в ядро.
Если система работает на базе ядра дистрибутива, то нужно установить пакеты с заголовочными файлами ядра. В большинстве дистрибутивов это пакеты «kernel-headers» и/или «kernel-devel». Для сборки модулей этого будет достаточно. Если ядро собиралось вручную, то эти пакеты не нужны: достаточно сделать символическую ссылку «/usr/src/linux», ссылающуюся на дерево сконфигурированных исходных кодов текущего ядра.
После компиляции модуля на выходе будет получен один или несколько файлов с расширением «ko». Можно попробовать их загрузить при помощи команды «insmod» и протестировать их работу.
Если модули загрузились и работают (или лень вручную подгружать зависимости), нужно их скопировать в дерево модулей текущего ядра, после чего обязательно обновить зависимости модулей командой «depmod». Она пройдется рекурсивно по дереву модулей и запишет все зависимости в файл «modules.dep», который, в последствие, будет анализироваться командой «modprobe». Теперь модули готовы к загрузке командой modprobe и могут загружаться по имени со всеми зависимостями.
Стоит отметить, что при обновлении ядра этот модуль работать не будет. Нужны будут новые заголовочные файлы и потребуется заново пересобрать модуль.

«Слушаем» что говорит ядро

При появлении малейших неполадок с модулем, нужно смотреть сообщения ядра. Они выводятся по команде «dmesg» и, в зависимости от настроек syslog, в файл «/var/log/messages». Сообщения ядра могут быть информативными или отладочными, что поможет определить проблему в процессе работы модуля, а могут сообщать об ошибке работы с модулем, например недостаточности символов и зависимостей, некорректных переданных параметрах. Например, выше рассмотренный модуль «rt73usb» требует параметр типа bool, что говорит о том, что параметр может принимать либо «0», либо «1». Если попробовать передать «2», то система выдаст ошибку:

# modprobe rt73usb nohwcrypt=2
FATAL: Error inserting rt73usb (/lib/modules/2.6.38-gentoo-r1/kernel/drivers/net/wireless/rt2x00/rt73usb.ko): Invalid argument

Ошибка «Invalid argument» может говорить о чем угодно, саму ошибку ядро на консоль написать не может, только при помощи функции «printk» записать в системный лог. Посмотрев логи можно уже узнать в чем ошибка:

В этом примере выведена только последняя строка с ошибкой, чтобы не загромаждать статью. Модуль может написать и несколько строк, поэтому лучше выводить полный лог, или хотя бы последние строк десять.
Ошибку уже легко найти: значение «2» неприемлемо для параметра «nohwcrypt». После исправления, модуль корректно загрузится в ядро.

Из всего сказанного можно сделать один вывод: ядро Linux играет по своим правилам и занимается серьезными вещами. Тем не менее — это всего лишь программа, оно, по сути, не сильно отличается от других обычных программ. Понимание того, что ядро не так уж страшно, как кажется, может стать первым шагом к пониманию внутреннего устройства системы и, как результат, поможет быстро и эффективно решать задачи, с которыми сталкивается любой администратор Linux в повседневной работе.

Источник