Libre Linux (GNU Kernel) on openSUSE
As we known, openSUSE project doesn’t provide official packages for Linux Libre kernel. There is a simple reason for that: default openSUSE kernel doesn’t include some proprietary modules; it’s free. All proprietary parts of the kernel could be found in a separate package kernel-firmware. But anyway there are users who want to use exactly GNU version. So, why not? This short tutorial describes how to build and install Libre Linux on openSUSE Leap 15.1 (openSUSE TW needs the same instructions).
Right now in the Leap 15.1 repository the kernel version is 4.12.14.
> uname -r 4.12.14-lp151.16-default
Let’s check the latest available 4.x kernel on the FSF server. Right now the latest avaliable kernel there is version 4.18. Its size is less then 100 Mb. Download it:
> wget -c \ https://linux-libre.fsfla.org/pub/linux-libre/releases/LATEST-4.N/linux-libre-4.18-gnu.tar.xz
Before we continue, I will recommend to verify file integrity. The .sign files can be used to verify that the downloaded files were not corrupted or tampered with. The steps shown here are adapted from the Linux Kernel Archive, see the linked page for more details about the process.
wget -c \ https://linux-libre.fsfla.org/pub/linux-libre/releases/LATEST-4.N/linux-libre-4.18-gnu.tar.xz.sign
Having downloaded the keys, you can now verify the sources. You can use gpg2 to verify the .tar archives. Here is an example of a correct output:
> gpg2 --verify linux-libre-4.18-gnu.tar.xz.sign gpg: assuming signed data in 'linux-libre-4.18-gnu.tar.xz' gpg: Signature made Mon 13 Aug 2018 01:25:14 AM CEST gpg: using DSA key 474402C8C582DAFBE389C427BCB7CF877E7D47A7 gpg: Can't check signature: No public key > gpg2 --keyserver hkp://keys.gnupg.net --recv-keys \ 474402C8C582DAFBE389C427BCB7CF877E7D47A7 key BCB7CF877E7D47A7: 12 signatures not checked due to missing keys gpg: key BCB7CF877E7D47A7: \ public key "linux-libre (Alexandre Oliva) " imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 > gpg2 --verify linux-libre-4.18-gnu.tar.xz.sign gpg: assuming signed data in 'linux-libre-4.18-gnu.tar.xz' gpg: Signature made Mon 13 Aug 2018 01:25:14 AM CEST gpg: using DSA key 474402C8C582DAFBE389C427BCB7CF877E7D47A7 gpg: Good signature from "linux-libre (Alexandre Oliva) " [unknown] gpg: aka "[jpeg image of size 5511]" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 4744 02C8 C582 DAFB E389 C427 BCB7 CF87 7E7D 47A7
The primary key fingerprint looks good.
If everything goes well, untar downloaded kernel:
> tar xfv linux-libre-4.18-gnu.tar.xz > cd linux-4.18
Well… now comes the personal part of the installation process, i.e. you know better what’s you should to care about during creating the config file, what’s hardware do you have and your kernel should support, what kind of optimization do you want to have, etc. That’s the most important step of this entire tutorial. For example, good configured kernel could save few seconds of boot time, bad configured kernel will doesn’t boot at all 🙂
To prepare the configuration file, you will need a base kernel configuration, it’s a plain text file calling .config. The are many ways to create .config file. It’s the same like for official Linux Kernel.
Before we can configure our new kernel we will need to install all needed dependencies.
# zypper in gcc make ncurses-devel bison flex libelf-devel libopenssl-devel bc # make menuconfig # make -j4 # make modules_install # make install
If you newer built a linux kernel before and it makes you scary, you can just make make menuconfig and just close it without to change anything. It will scan your hardware and generate a default config. This configuration will include much more then you will really need, but it guarantees that the new kernel will boot.
After installing we can still find the native openSUSE default-kernel in the GRUB menu. I think, this is the default behavior today in the most GNU/Linux systems. Thus, if something goes wrong and, for example, your new self-configured kernel will not boot, don’t worry.
> uname -r 4.18.0-gnu-lp151.16-default
I think, if it’s your first experience with the kernel compilation process and you will get new kernel that will boot and it will be smaller then default openSUSE kernel, you can be proud of yourself.
Whatever you will get, don’t forget to have a lot of fun 🙂
More info about Linux kernel for beginners could be found on the https://kernelnewbies.org/. More info about GNU Libre Linux could be found on the https://www.fsfla.org/ikiwiki/selibre/linux-libre/index.en.html. And, finally, if you interested in the openSUSE Linux kernel development process, you are always welcome to visit openSUSE wiki portal 😉
Leap 15.0 Beta testing: Fujitsu U757 Laptop
2 месяца назад нашел незначительный, но все же баг в ядре openSUSE Leap 15.0 (тогда еще это была Beta, build 174). Баг связан с лептопом Fujitsu U757 и воспроизводиться должен во всех дистрибутивах, т.к. проблема в upstream коде ядра.
Суть проблемы связана с поддержкой мультифункциональных клавиш, отвечающих за включение/выключение wifi.
Чтобы удостовериться, что kernel не обрабатывает нажатие клавиш, можно воспользоваться libinput. Это так называемый input device driver для X.org window system. С его помощью можно легко (в userland) отлавливать события, которые должны быть обработаны ядром. Так вот он показывал, что комбинация клавиш Fn+F5 при нажатии не давала никакого эффекта (F5 – это wifi-клавиша).
Тем не менее, при помощи rfkill wireless можно легко включить/отключить:
# rfkill list
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
# rfkill block 0
# rfkill list
0: phy0: Wireless LAN
Soft blocked: yes
Hard blocked: no
Как оно обычно и бывавает, много времени уходит на то, чтобы собрать достаточно материала. Долгое время я не был уверен, что делаю все верно. С толку сбивало и то, что в других дистрибутивах проблема воспроизводилась один в один. Я отключил Bluetooth в BIOS, чтобы только одно устройство влияло на работу LED на корпусе лептопа. Таким образом, LED должен был загораться при включении wireless и наоборот – тухнуть при выключении. Этого не происходило…
Я решил опробовать другие ядра. Я ставил ядро из репозиториев Kernel:stable (на тот момент это было ядро 4.15.13) и Kernel:HEAD (4.16 rc7-1). Это не решило проблему.
Спустя какое-то время я нашел в сети описание этой проблемы и патч. Я отправил bugreport. Такаши, один из разработчиков в Kernel Team, сказал мне, что патч будет принят в upstream в 4.17-rc1. В стандартное Leap-ядро этот фикс сразу же не попал, т.к. баг не слишком критичен, НО Такаши пересобрал ядро с этим исправлением для SLE15 и Leap15. Leap пользователи могут установить его отсюда. Это исправление будет в Leap совсем скоро официально, в виде maintenance update.
После установки этого ядра libinput отлавливает events:
# libinput debug-events -event7 KEYBOARD_KEY +3.51s KEY_RFKILL (247) pressed event7 KEYBOARD_KEY +3.51s KEY_RFKILL (247) released
В качестве заключения я хочу сказать всем разработчикам: слушайте свою интуицию, не давайте никому сбить вас с толку. Полагайтесь в первую очередь на свой опыт. Не слушайте коллег, которые подгоняют логику под увиденный результат. К сожаленью, часто бывает, когда вы стоите в шаге от правильного решения, но все же решаете посоветоваться, коллеги начинают вас переубеждать. Защайтесь. Не ленитесь перепроверить все еще раз.
Удачи! Have a lot of fun =)
openSUSE :: kernel of the day
Для тех, кто по той или иной причине хочет использовать последнюю версию ядра, но постоянно пересобирать ее вручную нет ни времени ни желания, openSUSE проект делает это за нас. Идея Kernel Of The Day – предоставить тестерам и прсто kernel инженерам последнюю git-версию ядра в виде RPM пакета. Это devel проект для ядра, в котором собираются версии для последующего тестирования и отправлки в tumbleweed. Делается это также с целью получить feedback от сообщества в виде bugreports или просто в ML/IRC.
Процесс полностью автоматизированный. Вы подключаете репозиторий и обновляетесь (каждый раз как пакет с новым ядром доступен для установки) как и обычно.
Версия unstable, поэтому имеет смысл не перезаписывать каждый раз старое ядро, а добавлять новое. Это не работает автоматически. Для этого надо отредактировать /etc/zypp/zypp.conf. Добавьте две строчки:
multiversion = provides:multiversion(kernel) multiversion.kernels = latest,running
Подробнее о multiple kernel.
Добавлю, что система ломатеся. Ломается достаточно часто. Только что, к примеру, у меня поломался dracut на ядре 4.9.0-2. Я не cмог загрузиться, т.к. он связан с LUKS, а я использую шифрование. Откатился назад на 4.8.13.
Интерсно, что именно сломано, почему и как починить. Это как раз ответ на вопрос “зачем мы этим занимаемся?”. Если бы этого не произошло, я вряд бы ли стал разбираться глубже в dracut. Проект таким способом предоставляет идеальную трейнинг площадку для энтузиастов, где обучение проходит в играющей форме 🙂
wikidevi.com
Хочу поделиться ссылочкой на интересную БД wifi адаптеров. Я помню, как еще каких-то семь-десять лет назад у пользователей GNU/Linux были проблемы их с поддержкой. Сегодня ситуация на много лучше, но проблема как будто осталась. Мы знаем о поддерживаемом ядром чипе, но не знаем в каких устройствах используется этот чип. Мы заходим на страницу магазина, но видем лишь цену, производителся и название конкретных моделей. Если повезет, то в комментариях кто-то напишет, что та или иная железка заработала в GNU/Linux.
Проект wikidevi.com собрал для нас информацию более чем о 5К Wireless адаптеров. Информация включает в себя фотографии устройства и самой платы, информацию о чипсете и драйвере, используемом в Linux (а также версия ядра, начиная с которой есть его поддержка), страну производитель, страницу оф. поддержки производителем и другие полезные ссылки, типа темы на форуме, где пользователи делятся своими впечатлениями и просто опытом, как завести устройство, если оно не завелось автоматически.
Например, я беру первый попавшийся wifi адаптер на amazon, в описании к которому отсутствует “Linux” как поддерживаемая ОС. Пускай это будет Linksys AE3000. Вот что я нахожу о нем на wikidevi: wikidevi: Linksys_AE3000. Как видим, официальной поддержки нет (хотя ожидается в драйвере rt2800usb). Но есть патч, который исправляет эту проблему начиная с версии 3.12. На wiki есть ссылка на solved-тему форума, откуда мы узнаем, что
After installing the hacked module and loading it, I had to edit the wireless configuration menu to enter my network name and the device hardware address. I am not yet familiar with Debian, so had to dig around a while to find things. After that the device was recognized and my network came up. The real key is to get the hacked source code for the chipset. I believe you have seen where to get that.
Другими словами, если руки растут из нужного места, то устройство у вас заработет.
Другим примером может быть TP-LINK_TL-WN822N_v2. Откуда я узнаю, что начиная с версии 2.6.36 (2010-10-20) ядро поддеживает этот USB адаптер. Модуль называется ath9k_htc. В магазине о поддеожке Linux ни слова, но теперь мы знаем, что проблем с устройством не будет 🙂
Linux Kernel 4.7 Update for openSUSE
Пару дней назад вышло ядро 4.7. В связи с этим наш репозиторий Tumbleweed в скором будущем будет обновлен. Для тех же, кому по той или иной причине нужны самые свежие версии ядер, собраные для openSUSE (не только Tumbleweed), существует специальный kernel-репозиторий. Там лежат ядра, собранные сразу же после официального релиза (в тот же день). Доступны сборки не только для x86, но и для ARM и Power. Есть vanilla.
Установка не предствляет из себя ничего сложного – самое обычное обновление rpm-пакета.
Я только что обновил ядро на одной из своих тестовых систем. Это 32-битный x86 нетбук c установленной (где-то в середине июня) Tumbleweed.
# uname -pr 4.6.2-1-pae i686 # zypper ar -f http://download.opensuse.org/repositories/Kernel:/HEAD/standard/Kernel:HEAD.repo Adding repository 'Kernel builds for branch master (standard)' ...............................[done] Repository 'Kernel builds for branch master (standard)' successfully added Enabled : Yes Autorefresh : Yes GPG Check : Yes Priority : 99 URI : http://download.opensuse.org/repositories/Kernel:/HEAD/standard/ # zypper lr # | Alias | Name | Enabled | GPG Check | Refresh --+---------------------+--------------------------------------------+---------+-----------+-------- 1 | Kernel_HEAD | Kernel builds for branch master (standard) | Yes | ( p) Yes | Yes 2 | openSUSE-20160613-0 | openSUSE-20160613-0 | No | ---- | Yes 3 | packman | packman | Yes | (r ) Yes | Yes 4 | repo-debug | openSUSE-Tumbleweed-Debug | No | ---- | Yes 5 | repo-non-oss | openSUSE-Tumbleweed-Non-Oss | Yes | (r ) Yes | Yes 6 | repo-oss | openSUSE-Tumbleweed-Oss | Yes | (r ) Yes | Yes 7 | repo-source | openSUSE-Tumbleweed-Source | No | ---- | Yes 8 | repo-update | openSUSE-Tumbleweed-Update | Yes | (r ) Yes | Yes
Значит новый репозиторий называется Kernel_HEAD. Хорошо, я хочу обновиться только из него:
# zypper dup -r Kernel_HEAD Retrieving repository 'Kernel builds for branch master (standard)' metadata --------------------[\] New repository or package signing key received: Repository: Kernel builds for branch master (standard) Key Name: Kernel OBS Project Key Fingerprint: 4529410A B52F94C4 03BAB484 ECEEF210 03579C1D Key Created: Mi 22 Apr 2015 14:25:51 CEST Key Expires: Fr 30 Jun 2017 14:25:51 CEST Rpm Name: gpg-pubkey-03579c1d-5537934f Do you want to reject the key, trust temporarily, or trust always? [r/t/a/? shows all options] (r): a Retrieving repository 'Kernel builds for branch master (standard)' metadata ...................[done] Building repository 'Kernel builds for branch master (standard)' cache ........................[done] Loading repository data... Reading installed packages... Computing distribution upgrade... The following 2 NEW packages are going to be installed: kernel-default-4.7.rc7-2.1.g152f160 kernel-pae-4.7.0-1.1.g24f30d5 The following 2 packages are going to be upgraded: kernel-firmware ucode-amd The following 2 packages are going to change vendor: kernel-firmware openSUSE -> obs://build.opensuse.org/Kernel ucode-amd openSUSE -> obs://build.opensuse.org/Kernel 2 packages to upgrade, 2 new, 2 to change vendor. Overall download size: 156.5 MiB. Already cached: 0 B. After the operation, additional 372.8 MiB will be used. Continue? [y/n/? shows all options] (y): y
После установки просто перезагружаемся и наслаждаемся работой нового ядра.
> uname -pr 4.7.0-1.g24f30d5-pae i686
Обновляя ядра, вы не только становитесь привлекательнее для девушек, но и помогаете проекту в качестве beta-тестера. Помните, что Tumbleweed это не самое-самое свежее ПО. Это коллекция уже протестированных вместе компонентов.
“Стоит ли мне учавстовать в этом? А вдруг я себе что-то сломаю?”, – подумает ленивец. Нет, вероятность того, что произойдет креш системы очень мал. Прежде чем ядро официально выпустят, оно пройдет серию тестов.
Если креш все же произошел, всегда можно загрузить старое ядро, в котором вы работали прежде (и где все работало). В этом случае вы очень поможете, если не поленитесь сообщить нам о возникшей проблеме.
Посмотреть список установленных ядер можно вот так:
# zypper se -si 'kernel*' Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository --+-----------------+---------+----------------------+--------+--------------------------------------- i | kernel-default | package | 4.6.2-1.2 | i586 | (System Packages) i | kernel-default | package | 4.7.rc7-2.1.g152f160 | i586 | Kernel builds for branch master i | kernel-firmware | package | 20160712-137.1 | noarch | Kernel builds for branch master i | kernel-pae | package | 4.6.2-1.2 | i686 | (System Packages) i | kernel-pae | package | 4.7.0-1.1.g24f30d5 | i686 | Kernel builds for branch master
Как видете, старое ядро никуда не делось. Я отправляю всех интересующихся к 12 главе нашего руководства. Там описана Multiple Kernel магия для zypper.
Обновившись, я протестировал сейчас, к примеру, LUKS и совместимость с проприетарным broadcom модулем для wireless. Все работает как и прежде, значит я иду дальше – перехожу к обновлению на своих ARM embedded-системах, чтобы удостовериться, что и там все работает как надо. Счастливо 😉
kernel-russian@kernelnewbies.org
Решил немного расширить тематику нашей рассылки. Отныне тут можно пообщаться не только о ядре Linux, но и о обычном системном программировании.
Проекту уже несклько лет, но его продвижением никто не занимается. Трафик очень низкий, поэтому, думаю, никто не будет против, если рассылку можно будет использовать и для обычного системного или сетевого программирования на C. Если вы используете один из дистрибутивов GNU/Linux и интересуетесь С, не стесняйтесь подписываться, задавать вопросы, подкидывать идеи и просто принимать участие в обсуждении.
Кстати, пару часов назад я создал группу на github.com для этого проекта. Теперь нам не нужно выкладывать код то там то тут. Все активные учасники могут работать с проектами в одном месте (без необходимости ожидать подтверждения на разрешение сделать push).
New openSUSE kernel available for testing
Сегодня утром были пересобраны desktop ядра 3.11.10. Был добавлен патч, исправляющий проблему с зависанием (минут на 20) во время установки системы (на этапе инициализации разделов: seeking for Linux partitions). Проблема заключалась в запуске blkid(8) для устройства /dev/fd0.
Тестируем:
- Найти машину, на которой получится воспроизвести проблему
- Отключить floppy в BIOS
- Установить систему
- Включить floppy в BIOS
- Убедиться, что yast2 partitioner зависает
- Устанавливать новое ядро и перезагрузиться
- Убедиться, что yast2 partitioner больше не зависает 🙂
Эта проблема не связана с новым YaST, который недавно был переписан. Баг тянется еще с openSUSE 12.2 (патч добавлен и в SLE-SP3).
Если BIOS не позволяет отключить floppy, просто добавте brokenmodules=floppy как параметр при загрузке. При этом не забудьте проверить modprobe.conf посте успешной установки (во время тестирования).
openSUSE :: Atheros TL-WN822N
Цикл тестирования следующей версии нашего любимого дистрибутива в самом разгаре. Сейчас я работаю с четвертой milestone и хотел бы коротко рассказать о внешнем USB wifi-адаптере TL-WN822N от компании TP-LINK. Он соборан на основе седьмого и девятого поколения чипов Atheros Communications.
В июле 2008 г. компания Atheros решила сменить политику, наняла двух ключевых разработчиков Linux: Луиса Родригеса (исп. Luis Rodriguez) и Йоуни Малинена (фин. Jouni Malinen), выпустивших открытые драйверы для работы устройств 802.11n в Linux. Atheros также опубликовала часть исходного кода их бинарного HAL под лицензией ISC в целях помощи сообществу в добавлении поддержки чипов Atheros 802.11a/802.11b/802.11g. Компания стала принимать активное участие в разработке драйвера ath9k для Linux, с поддержкой всех нынешних 802.11n чипсетов.
Итак, драйвера ath9k и ath9k_htc открыты и включены в ядро. Тем не менее, ожидаемого результата после включения этого устройства мы не получим… но обо всем по порядку.
Читать дальше…
openSUSE :: Encrypted File Systems
Криптография – наука о шифрах – очень глубокая, требующая изучения, тема, история которой насчитывает более четырех тысяч лет. Это один из основных инструментов, использующихся при защите информации. Спецслужбы бывшего Советского Союза, США, Франции и других стран вкладывали огромные средства в разработку криптостойких алгоритмов для своих информационных каналов, параллельно пытаясь вскрывать чужие. Сегодня этими технологиями мы пользуемся каждый день, даже не задумываясь об этом.
Причин зашифровать информацию может быть несколько. К примеру, у вас есть любого рода секретная информация, которая ни в коем случае не должна попасть к кому-то конкретно, а может вы просто хотите оградить свою личную жизнь от чужих глаз. Мы теряем нетбуки или флешки, а на них, как правило, конфиденциальная информаця. Просто поломка носителя это уже печально, но на много хуже, когда наша информация попадает в чужие руки. Можно лишь догадываться как будет использованна эта информация, и надеяться, что она не будет использованна нам во вред.
В этом посте я расскажу о методе шифрования файловых систем (ФС) в openSUSE 13.1-m3, которая собрана на основе последней на данный момент stable-версии ядра – 3.10.0.
upd:
Тут вы так же можете найти руководство (добавленное в октябре 2018) по установке openSUSE Leap 15.1 на зашифрованный LVM-контейнер.
Читать дальше…
Yet another method to find PCI vendor and device ID
Первым шагом написания драйвера для PCI устройства является определение его Vendor ID и Device ID. Существует много способов найти их. Кто-то советует смотреть документацию к устройству, более распространенным способом является просто заглянуть в файл include/linux/pci_ids.h. Ок, если я кернел-разработчик, то у меня естественно есть этот файл, а также я могу сделать что-то типа
> /sbin/lspci -n -s 02:00.0 02:00.0 0200: 11ab:4364 (rev 12)
…но что делать, если мне понадобился Vendor ID и Device ID на какой-нибудь, возможно даже не моей машине, где во-первых нет этого файла, а во-вторых мне также нужны Class code, BAR0-BAR5, Subvendor ID и Subdevice ID, которых lspci с ключами -n и -s не показывает?
Информацию об этом можно вытянуть из sysfs (рассматривается случай, если устройство уже зарегистрированно). Пусть это будет, к примеру, Ethernet-карта; cмотрим её адрес:
> /sbin/lspci | grep Ethernet 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller 05:04.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller
Ок, карт две, с адресами 02:00.0 и 05:04.0 соответсвенно. Более подробно PCI-дерево можно увидеть через тот же lscpi, но с ключем -t (tree).
> /sbin/lspci -t
-[0000:00]-+-00.0
+-01.0-[01]--
+-1a.0
+-1a.1
+-1a.7
+-1b.0
+-1c.0-[04]----00.0
+-1c.4-[03]--+-00.0
| \-00.1
+-1c.5-[02]----00.0
+-1d.0
+-1d.1
+-1d.2
+-1d.7
+-1e.0-[05]--+-03.0
| \-04.0
+-1f.0
+-1f.2
+-1f.3
\-1f.5
Я показываю этот вывод для того, чтобы вам легче было отследить откуда я узнал адрес /sys/devices/pci0000:00/0000:00:1c.5/0000:02:00.0/:
> l /sys/devices/pci0000\:00/0000\:00\:1c.5/0000\:02\:00.0/driver lrwxrwxrwx 1 root root 0 Nov 16 22:04 /sys/devices/pci0000:00/0000:00:1c.5/0000:02:00.0/driver \ -> ../../../../bus/pci/drivers/sky2/
Да, это то устройство, и работает оно под управлением модуля sky2.
Второе висит на skge:
> l /sys/devices/pci0000\:00/0000\:00\:1e.0/0000\:05\:04.0/driver lrwxrwxrwx 1 root root 0 Nov 17 00:12 /sys/devices/pci0000:00/0000:00:1e.0/0000:05:04.0/driver \ -> ../../../../bus/pci/drivers/skge/
Каждое PCI устройство имеет область памяти (256-байт), которая содержит его конфигурацию. Эта информация является ключевым для определения марки и возможности PCI-карт. Находится она в config-файле, в том же каталоге. Прочитать её дамп можно с помощью od:
> od -x /sys/devices/pci0000\:00/0000\:00\:1c.5/0000\:02\:00.0/config 0000000 11ab 4364 0407 0010 0012 0200 0008 0000 0000020 c004 fa7f 0000 0000 8801 0000 0000 0000 0000040 0000 0000 0000 0000 0000 0000 1043 81f8 0000060 0000 fa7c 0048 0000 0000 0000 010a 0000 0000100 0000 01f0 8000 01a0 5001 fe03 2000 1300 0000120 5c03 83fc ffff ffff 0000 0100 e005 0081 0000140 300c fee0 0000 0000 41a1 0000 0000 0000 0000160 0200 0000 0000 0000 0000 0000 0000 0000 0000200 0000 0000 7000 0000 0000 0000 a882 00e8 0000220 0000 0000 0000 0000 0000 0000 0000 0000 *
Первые два бита – это Vendor ID [11ab]. Дальше (смещение 2 бита) – Device ID [4364]. Class code находится со смещением 10 бит [0200]. BAR0 – BAR5 (base address register) со смещением с 16 по 39 бит [c004…0000]. Subvendor ID имеет смещение 44 [1043], и наконец Subdevice ID имеет смещение 46 бит [81f8].
Кстати, зная Vendor и Device ID, мы можем заглянуть на pcidatabase.com и попробовать узнать побольше об этом устройстве:
Пройдя дальше по ссылке я узнал немного о производителе и других его разработках.
check point
Один важный момент, который я хотел бы рассмотреть в конце – это отсутствие информации об устройстве с device ID 4364 в include/linux/pci_ids.h. Как вы видете, там есть лишь vendor ID 11ab. Значит ли это, что карта с этим ID не поддерживается ядром? Нет, карта работает отлично, и ядро находит устройство без каких-либо проблем. Проверить это можно с помощью API ядра: pci_get_device(), которая находит (или не находит) устройство и pci-enable-device(), которая включает его.
#include <linux/init.h>
#include <linux/module.h>
#include <linux/pci.h>
#define VENDOR_ID 0x11ab
#define DEVICE_ID 0x4364
static int __init pci_start(void)
{
struct pci_dev *pdev;
pdev = pci_get_device(VENDOR_ID, DEVICE_ID, NULL);
if(!pdev)
printk("Device not found\n");
else {
printk("Device found\n");
if(pci_enable_device(pdev)) {
printk("Could not enable the device\n");
return NULL;
}
else
printk("Device enabled\n");
}
return 0;
}
static void __exit pci_exit(void)
{
printk("Bye bye");
}
module_init(pci_start);
module_exit(pci_exit);
MODULE_LICENSE("GPL");
Почему так происходит, я не знаю. Возможно вы, уважаемые мои читатели, сможете подсказать мне это? 😉
Don’t Panic
Порой бывает непросто разобраться в неполадках работы ядра Linux. Поиск причины, приводящей к kernel panic, требует воспроизведения ситуации, вызывающей некорректное поведение ядра, а также сбора информации, на основании которой можно сделать какие-то выводы. Проблема в том, что kernel panic иногда вешает систему полностью, и в этом случае даже не знаешь с какой стороны подступиться и что вообще делать с “заблокированной” машиной.
В этом посте я описал в общих чертах некоторые методы, которые помогут разобраться с причиной возникновения kernel panic.
Читать полностью…
openSUSE 11.4 :: Kernel Update
Первое обновление (2.6.37.6-0.5) ядра для openSUSE 11.4 доступно в Update репах. Исправленно много ошибок. Для обновления, как и обычно, достаточно просто сделать:
> zypper up
Upstream ядра, начиная с 2.6.37.2 до 2.6.37.6 включительно:
ChangeLog-2.6.37.2
ChangeLog-2.6.37.3
ChangeLog-2.6.37.4
ChangeLog-2.6.37.5
ChangeLog-2.6.37.6
[Nouveau] Tester wanted: Timing management
Трое ребят работают над созданием свободного драйвера для nVidia карточек, а именно – над таймингами чипов. Так как спецификации закрыты, они решили обратиться за помощью к сетевому сообществу. Им нужна помощь в reverse engineering’е vBIOSов nVidia видеокарт, для получения данных об их таймингах.
Если у тебя nVidia карточка, ты можешь помочь им, предоставив некоторую инфу о начинке своей видяхи.
Читать полностью…
Russian kernelnewbies mailing list
Небольшая, но все же приятная новость: у русскоговорящих энтузиастов ядра Linux теперь есть своя mail-рассылка. Запущенна рассылка в рамках проекта kernelnewbies.org, инициатором и координатором русской части которого я являюсь.
Я думаю, что поддерживать контакт таким образом на много удобнее. Отслеживать последние сообщения на форуме никто не хочет, а с настройкой RSS возникли некоторые проблемы.
Надеюсь, что мы сможем весело провести время, обсуждая ядро. Так же надеюсь, что она поможет многим из нас лучше разобраться в принципах работы ядра, и подталкнет к написанию хоть и самых простых, но все же собственных модулей 🙂
Подписаться на нее можно на этой странице. Там же есть ссылка и на архив сообщений.
⌨ Labor omnia vincit ☮ 
2 comments