Powered By Blogger

Sunday, March 25, 2007

Toshiba Satellite A100-811: WiFi

В Toshiba Satellite A100-811 встроен WiFi-адаптер Intel PRO/Wireless 3945ABG. В принципе, поиск драйвера для этого устройства не представляет собой проблемы. Драйвер можно скачать с официального сайта intel. На данный момент доступны 2 разновидности драйвера: 1-я - это ipw3945. Строго говоря, драйвер состоит из трёх компонентов - собственно, модуль ядра ipw3945, бинарный образ микрокода (firmware) - ipw3945-ucode и демон, работающий в пространстве пользователя - ipw3945d (управляет драйвером).

2-я разновидность - экспериментальный драйвер iwlwifi: это собственно модуль ядра и образ firmware (iwlwifi-ucode). Управляющего демона здесь уже нет (к счастью). Этот драйвер также доступен для загрузки с сайта intel. Кстати, несмотря на предупреждение в документации, что драйвер имеет статус экспериментальный, у меня он работает без каких-либо нареканий.

Изначально, чтобы заставить работать адаптер, я использовал 1-й драйвер (ipw3945). Сложностей с его установкой в общем-то нет никаких (версия ядра, с которой согласен собираться модуль - 2.6.13+). Выкачал драйвер: ipw3945-1.2.0, демон ipw3945d-1.7.22 + firmware не-помню-какой-точно-версии (последняя). Собрал модуль (без проблем), положил firmware в /usr/lib/hotplug/firmware. Положил демон в куда-надо (/sbin), добавил в /etc/modprobe.d файлик, чтобы оно пускало демон при загрузке модуля (файл /etc/modprobe.d/ipw3945):

install ipw3945 /sbin/modprobe --ignore-install ipw3945 ; sleep 0.5 ; /sbin/ipw3945d-start 
remove ipw3945  /sbin/ipw3945d --kill ; /sbin/modprobe -r --ignore-remove ipw3945-stop
Скрипты взяты из тарбола с демоном - ipw3945d:
ipw3945-start
#!/usr/bin/env /bin/bash
# If no parameter is provided then set user to 'root'
[ "$1" ] && user=$1 || user=root

wait_for_cmd() {
 # First, wait for sysfs entry to show up, timing out after 10 seconds:
 count=0
 while [ ! -e /sys/bus/pci/drivers/ipw3945/*/cmd ]; do
  sleep 0.5
  count=$((count+1))
  ((count > 20)) && return 1
 done

 return 0
}

wait_for_cmd && {
 # Set ownership of sysfs entry:
 chown $user /sys/bus/pci/drivers/ipw3945/*/cmd
 chmod a-w,u+rw /sys/bus/pci/drivers/ipw3945/*/cmd

 # Verify/set up PID directory 
 [ ! -d /var/run/ipw3945d ] && {
  mkdir -m 0775 /var/run/ipw3945d
  chown $user /var/run/ipw3945d
 }

 # Launch the regulatory daemon:
 /sbin/ipw3945d --quiet --pid-file=/var/run/ipw3945d/ipw3945d.pid
}


ipw3945-stop
#!/usr/bin/env /bin/bash
PIDPATH=/var/run/ipw3945d
# Kill the regulatory daemon if it is running:
/sbin/ipw3945d --isrunning --pid-file=${PIDPATH}/ipw3945d.pid &&
 /sbin/ipw3945d --kill --pid-file=${PIDPATH}/ipw3945d.pid

# Remove the PID directory
[ -d ${PIDPATH} ] && rm -rf ${PIDPATH}

К слову, директорию /var/run/ipw3945d, где демон будет держать файл со своим PID, желательно создать вручную.

Сам модуль грузится нормально, тянет за собой ieee80211 (который должен быть включен в ядре - по идее, в документации требуется загрузить более новую версию ieee80211, но я не патчил ядро). Выделяется ирка (IRQ18). В общем, всё как-будто нормально. Но демон грузиться отказывается и вываливает сообщение: Could not find Intel PRO/Wireless connection. Модуль при загрузке рапортовар: Intel PRO/Wireless connection detected, но не показывал при этом Detected geography ... Как результат, нет второго eth-интерфейса и вообще, девайс неработает. Начал грешить на hotplug, а именно, что он не грузит firmware, но, как выяснилось позже, hotplug здесь совершенно ни при чём. В конечном счёте, виновным был признан демон. Согласно всё той же документации, демон сперва деинициализирует драйвер при загрузке, затем инициализирует по-новому и если его что-то не устраивает, просто отваливается. В противном случае, если всё нормально - производит калибровку.

Одним словом, я просто плюнул на всякие дальнейшие разбирательства. Тем более, что инстинктивно мне почему-то очень не нравилась такая модель драйвера, где присутствует управляющий user-space демон.

Итак, заменяем неблагонадёжный ipw3945 + ipw3945d на новый iwlwifi. В документах написано, что этот драйвер экспериментальный и может не работать. Но у меня он во всяком случае заработал. Для работы (и сборки?) понадобится подсистема mac80211 (по докам - это кучка фиксов для уже имеющейся в ванильном ядре подсистемы ieee80211 и "ставится" она без проблем на ядра 2.6.18+). Находим и сливаем по возможности последнюю версию, в моём случае это был тарбол mac80211-4.0.4. Распаковываем, говорим make. В ответ на это нам выплёвывают список изменений, которые будут предприняты в ядре. Затем, если всё удачно (этой приблуде может понадобиться rsync - мне пришлось доустанавливать его, т.к. до этого никакой потребности в нём я не испытывал и, соответственно, не ставил) говорим make patch_kernel. В каталоге, где распакован тарбол получаем несколько новых подкаталогов (некоторые были и до этого, но в них появилось новое содержимое): compatible, modified, origin, patches, stubs. В compatible лежат пропатченные куски кода. Копируем содержание compatible в /lib/modules/`uname -r`/build. Затем натравливаем на /lib/modules/`uname -r`/build скрипт ieee80211_ptr.sh из <unpacked_tarball>/scripts. Если этого не сделать, компилятор при пересборке ядра под конец начнёт вопеть как резанный, что structure has no member 'ieee80211_ptr' (На самом деле, странно, но в пропатченном коде просто не делается правильное приведение к типу). В любом случае, ядро придётся пересобирать полностью, естественно. Перед сборкой в конфиге должны быть определены символы CONFIG_CFG80211=m && CONFIG_MAC80211=m (Через menuconfig CONFIG_MAC80211 это Networking -> Generic IEEE 802.11 Networking Stack (dscape) где находится CONFIG_CFG80211, сейчас точно не вспомню, но при желании можно найти).

Если всё прошло успешно, ставим модули, ядро. Перезагружаемся. Тащим тарбол с интеловским firmware: iwlwifi-ucode-2.14.1 или выше. Кладём его в /usr/lib/hotplug/firmware (или /lib/firmware, в зависимости от того, где Ваш hotplug хотел бы всё это хозяйство видеть).

Тащим тарбол с самим драйвером: wlwifi-0.0.11 или выше. Распаковываем, говорим make, make install. После того, как модуль собран и установлен, проверяем:

 # ./load debug=0x43fff 
 
 <SKIPPED>

 выплёвывает кучу всякой полезной и не очень информации, главнй смысл в фразах, что соединение найдено, информация о каналах и тому подобное 
 </SKIPPED> 
 
 # iwconfig 
 wmaster0  IEEE 802.11a  Channel:0 
 
           RTS thr:off   Fragment thr=2346 B 
      
 wlan0     IEEE 802.11a  ESSID:"" 
    Mode:Managed  Channel:0  Access Point: 00:00:00:00:00:00 
    RTS thr:off   Fragment thr=2346 B 
    Encryption key:off 
    Link Quality:0  Signal level:0  Noise level:0 
    Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0 
    Tx excessive retries:0  Invalid misc:0   Missed beacon:0
Что и требовалось доказать. Демон здесь не нужен, поэтому, установка практически завершена.

PS: последовательность моих действий несколько отличается от той, что описана в документации. Например, мне не удалось запустить даже make menuconfig после пропатчивания ядра на предмет mac80211, т.к. make ругался на отсутствие конфига в net/mac80211 (самого каталога тоже не было). Поэтому я просто порывшись определил, где и что находится и скопировал содержимое compatible /lib/modules/`uname -r`/build. Про то, что в пропатченных сырцах компилятор начнёт жаловаться на неприведение к нужному типу, тоже сказано ничего не было (по поводу ieee80211_ptr.sh) Ещё один момент: утилиты выдают предупреждения по поводу стека wireless-расширений:

devel:/home/f0x/tmp# iwconfig wlan0
Warning: Driver for device wlan0 has been compiled with version 21
of Wireless Extension, while this program supports up to version 17.
Some things may be broken...
Но у меня пока проблем не наблюдалось никаких. Возможно, этот чисто внешний дефект устраняется апгрейдом пакета утилит, но меня эти сообщение особо не смущают, так что я ничего не апгрейдил.

Friday, March 23, 2007

Toshiba Satellite A100-811: Bluetooth & suspend

Попутно ещё пара замечаний. В плане bluetooth в моём случае стоит ориентироваться на модуль toshiba_acpi. Отсюда можно почерпнуть косвенное подтверждение тому, что bluetooth активируется через ACPI. Очевидно, для моей модели нет поддержки. А может, здесь такой хитрый ACPI. В общем, я запасся последней спецификацией ACPI - попробую разобраться хоть частично, что к чему. Понять, по какой причине не грузится модуль сложно. Такой код ни к чему, в общем-то, не обязывает (drivers/acpi/toshiba_acpi.c):

static int __init toshiba_acpi_init(void)
{
 acpi_status status = AE_OK;
 u32 hci_result;
 int status2;

 if (acpi_disabled) {
  printk(MY_INFO"ACPI disabled, failed to initialize module\n");
  return -ENODEV;
 }

 if (!acpi_specific_hotkey_enabled) {
  printk(MY_INFO "Using generic hotkey driver\n");
  return -ENODEV;
 }
 /* simple device detection: look for HCI method */
 if (is_valid_acpi_path(METHOD_HCI_1))
  method_hci = METHOD_HCI_1;
 else if (is_valid_acpi_path(METHOD_HCI_2))
  method_hci = METHOD_HCI_2;
 else {
  printk(MY_INFO"device detection: no valid HCI method available\n");
  return -ENODEV;
 }
 ...

Так или иначе, но драйвер не очень многословен и максимум на что его хватает - возвратить ENODEV. Не знаю, насколько это удачная идея, но попробую поиграться с модулем. Для начала имеет смысл вставить в код формальные метки, чтобы было яснее, что может быть не так. Дальше, посмотрим по результатам изучения спецификации и наличного металлолома. К слову, в связи со всем этим, хотелось бы сказать своё "фи" в адрес конторы, носящей гордое название "Toshiba". Похоже, что фирме гораздо выгоднее "рекомендовать Windows Vista", чем поддерживать клиентов хотя бы более подробной технической информацией в интернет, я уж не говорю о том, что можно было собраться с силами и наваять-таки что-нибудь и для linux, хотя бы вот как Intel или nVidia. (Эмоции, однако).

В отношении suspend: как минимум два потока ядра (две подсистемы, два драйвера - называйте, в общем, как хотите) не дают перейти системе в suspend. А именно:

  1. fs/xfs/linux-2.6/xfs_super.c::xfssyncd()
  2. net/core/pktgen.c::pktgen_thread_worker()

1-й из них - поток ядра, создаваемый xfs для синхронизации файловой системы. Не совсем понятно, почему дизайн ФС именно такой, какой он есть, но здесь можно аргументировать отсутствие поддержки режима сна. Хотя, с другой стороны, вместе с тем, что нет вызова try_to_freeze(), нет и установки флага PF_NOFREEZE. Не уверен на все 100%, но вероятно, добавление строки current->flags |= PF_NOFREEZE; позволило бы обойти проблему. Правда, это по-своему рискованно. Должна быть гарантия, что поток не изменит уже сохранённый на свопе образ системы. Иными словами, нельзя, допустим, чтобы после выгрузки образа системы на устройство подкачки кто-то/что-то изменило данные на винчестере. Возникает несоответствие между актуальным состоянием файловой системы и тем, что было сохранено в дамп на свопе. Причина достаточно веская, чтобы не экспериментировать. Впрочем, мои предположения ещё нужно подтвердить. Проще всего это наверно сделать путём сбора статистики юзеров. Если всё же есть люди, у которых xfs уживаются в одном флаконе с suspend - то тем лучше, значит проблема лечится без лоботомии или ампутации.

По поводу 2-го, не совсем понятно, почему там нет поддержки спящего режима. pktgen_thread_worker() - он же наблюдаемый в ps ax, как kpktgend_[0|1] - не что иное, как генератор пакетов, предназначенный для тестирования сети. Совсем не понятно, почему генератор пакетов _не_должен_ замораживаться и что он будет делать, если сетевые интерфейсы будут отключены.

Строго говоря, список драйверов, не поддерживающих suspend этими двумя пунктами не исчерпывается. Кое-что по этому поводу написано здесь - http://suspend2.epfl.ch/status. Список довольно общего плана, но даёт некоторое представление о том, с чем suspend2 может не заработать (suspend это, кстати, касается тоже).

Thursday, March 22, 2007

Toshiba Satellite A100-811: Hello world!

Итак, приступим. Запись за номером 1 не очень оптимистичная. Ноутбук Toshiba Satellite A100-811 оказалось не так-то легко окультурить. Легко было только ушатать установленную там по умолчанию Windows Home Edition. В общем, будем исходить из того, что это - своеобразный TODO.

Далее по списку для ОС Debian GNU/Linux 3.1 на ядре 2.6.20:

  1. до сих пор нет ничего определённого на счёт встроенного bluetooth. Поддержка брендовых фич в ядре ничего не даёт. По правде, я уже запутался. Эти фичи должны обеспечиваться фирменным ACPI. Или...? По порядку (по опциям конфига ядра): TOSHIBA - поддержка доступа к режиму управления системой (Toshiba System Management Mode). Категорически не работает на тошибах с Phoenix BIOS'ом. Это очень прискорбно, так как нет возможности воспользоваться Dial-up доступом к интернет. ACPI_TOSHIBA тоже не помогает.

  2. встоенный модем, работающий через самосборный slmodemd c поддержкой alsa как бы работает, но дозвониться по нему как бы не получается.

  3. suspend - это вообще отдельная большая и больная тема. Проблема, собственно, сугубо ядерная в моём случае. На ванильное ядро был накачен патч suspend2-2.2.9.10-for-2.6.20.patch.bz2. И всё быть может было бы и ничего, если бы не ФС. Цикл засыпания прерывается из-за невозможности заморозить потоки ядра - xfssyncd и kpktgen. Второй можно безболезненно вышвырнуть из ядра. В принципе, мне этот генератор пакетов абсолютно нафиг нужен сейчас. Но с XFS получилось совсем не хорошо.

  4. не работают функциональные клавиши (см. п.1 - суть проблемы та же).

Вот то основное, что хотелось бы исправить на данный момент. В отношении suspend придётся искать альтернативное решение или совсем отказаться от него. Было бы лучше, если бы удалось работать его. На случай форс-мажора, если допустим, Вы отлучились от лаптопа на некоторое время, а батарея почти иссякла. В подобной ситуации было бы неплохо, если бы за 5-10 минут до полной разрядки батарей система автоматически в превентивном порядке заснула и отключила питание.

По поводу bluetooth - при наличии подписки GPRS было бы крайне удобно работать с интернет через сотовый телефон (а подписка у меня есть). При том, что GPRS покрытие в Беларуси очень даже радует, а качество стало не впример лучше, это хорошая возможность - работать с электронной почтой в дороге/там, где нет локалки или обычных телефонных коммуникаций, либо доступ к ним затруднён.

В отношении всего остального: при инсталляции системы ядро (дистрибутивное 2.6.8) немного фыркало в сторону SATA. Это было устранено почти сразу, как только была установлена базовая система и заменено ядро. Со встроенным Ethernet-адаптером проблем по определению быть не должно было. Некоторые проблемы были с Wi-Fi. Но об этом немного попозже, тем более, что сейчас проблема устранена.

Не был протестирован кардридер. По объективным причинам - отсутствие объектов исследования - а.к.а. этих самых карт.

Особняком стоит поддержка встроенного видео 945GM. Точнее было бы сказать, что её нет вообще. Пока Х работает через VESA. Разрешение вполне приличное - 1280х800. Излишне, впрочем, говорить, что фильм в полноэкранном режиме в том же xine особо не посмотришь и в Q3A не поиграешь. Лекарство есть - Xorg 7.1 (vs Xorg 6.9, установленного из бэкпортов). Но... Нет релиза - нет Xorg 7.1. Так что, ждём.

Вообще, вот как выглядит всё хозяйство при более подробном рассмотрении:

0000:00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
0000:00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
0000:00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
0000:00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
0000:00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
0000:00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)
0000:00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02)
0000:00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02)
0000:00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02)
0000:00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02)
0000:00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
0000:00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
0000:00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
0000:00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 02)
0000:00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
0000:05:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
0000:07:06.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
0000:07:06.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller
0000:07:06.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
0000:07:06.3 0805: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller
0000:07:08.0 Ethernet controller: Intel Corporation PRO/100 VE Network Connection (rev 02)

PS: по поводу suspend - наиболее приемлемым решением было бы вправить ядру мозги на предмет XFS. Но как? Подолжаем поиски решения.

ПОСЕТИТЕЛИ

free counters