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 это, кстати, касается тоже).