Всем привет. В одной из прошлых статей я писал о мультипротокольном кроссплатформенном мессенджере MDC. Напомню, MDC – мессенджер с поддержкой протоколов ICQ, Mail.ru и других. Но главной его фишкой является возможность хранить историю на сервере и объединять контакты из разных протоколов. На момент написания статьи в моем репозитории был собран пакет MDC.

С тех пор много воды утекло. Был открыт исходный код MDC. Но почему-то его разработка была заброшена. На сегодняшний день последней версией мессенджера так и осталась 1.0.4.3. В связи с этим  я не придал значения тому, что с выходом openSUSE 12.1 не был собран rpm-пакет для этой версии дистрибутива. И как оказалось, напрасно. На почту мне стали приходить письма с просьбой собрать rpm-пакет MDC для последней версии дистрибутива openSUSE. Должен признать, что по причине занятости я немного повременил со сборкой. Но теперь пакет собран и выложен в моей домашнем репозитории. Прошу любить и жаловать.

Если у вас еще не добавлен мой репозиторий:

#zypper ar http://download.opensuse.org/repositories/home:/tuoma/openSUSE_12.1/  home:tuoma

И устанавливаем MDC:

#zypper in mdc

Для любителей поклацать мышкой, все тоже самое можно сделать в YaST

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

Искренне ваш.

ВНИМАНИЕ!!! Следуйте советам, приведенным ниже, только в том случае, если вы четко понимаете, что вы делаете. Автор не несет ответственности за любые последствия, вызванные манипуляциями, о которых пойдет речь далее.

Продолжение. Начало тут

Теперь самое время, посмотреть чего же мы все-таки добились нашими действиями. Ведь первоначальная задача стояла во включении ASPM для PCI Express. Кстати, предварительно не мешает указать в параметрах ядра pcie_aspm=force и перегрузиться. # dmesg | grep ASPM

[ 0.000000] PCIe ASPM is forcibly enabled

[ 1.783332] ACPI FADT declares the system doesn’t support PCIe ASPM, so disable it

[ 1.931463] ACPI _OSC control for PCIe not granted, disabling ASPM

Как видим, ядро выругалось на метод _OSC и не захотело включать ASPM. Собственно, метод _OSC определяет возможности и детали некоторого устройства и является дочерним для этого устройства.

Теперь смотрим, что же с ним не так.

# dmesg | grep _OSC

[ 1.921997] \_SB_.PCI0:_OSC invalid UUID

[ 1.921999] _OSC request data:1 8 1f

[ 1.931408] \_SB_.PCI0:_OSC invalid UUID

[ 1.931409] _OSC request data:1 1f 1f

[ 1.931413] pci0000:00: Requesting ACPI _OSC control (0x1d)

[ 1.931457] \_SB_.PCI0:_OSC invalid UUID

[ 1.931459] _OSC request data:1 0 1d

[ 1.931462] pci0000:00: ACPI _OSC request failed (AE_ERROR), returned control mask: 0x1d

[ 1.931463] ACPI _OSC control for PCIe not granted, disabling ASPM

То есть можно сделать вывод о том, что методу _OSC не понравился идентификатор нашей шины PCI. Лезем в спецификацию ACPI и смотрим пример реализации этого метода для шины PCI Express. После чего ищем этот метод в нашем исходнике DSDT. У меня например до правки он был таким:

Device (PCI0) // Это начало секции PCI

{

…

//буфер, который теоретически содержит правильный идентификатор и с которым производится сравнение

Name (GUID, Buffer (0×10)

{

/* 0000 */ 0x5B, 0x4D, 0xDB, 0×33, 0xF7, 0x1F, 0x1C, 0×40,

/* 0008 */ 0×96, 0×57, 0×74, 0×41, 0xC0, 0x3D, 0xD7, 0×66

})

Name (SUPP, Zero)

Name (CTRL, Zero)

//Собственно сам метод

Method (_OSC, 4, Serialized)

{

Store (Arg3, Local0)

CreateDWordField (Local0, Zero, CDW1)

CreateDWordField (Local0, 0×04, CDW2)

CreateDWordField (Local0, 0×08, CDW3)

If (LAnd (LEqual (Arg0, GUID), NEXP))

{

Store (CDW2, SUPP)

Store (CDW3, CTRL)

If (Not (And (CDW1, One)))

{

If (And (CTRL, One))

{

NHPG ()

}

If (And (CTRL, 0×04))

{

NPME ()

}

}

If (LNotEqual (Arg1, One))

{

Or (CDW1, 0×08, CDW1)

}

If (LNotEqual (CDW3, CTRL))

{

Or (CDW1, 0×10, CDW1)

}

Store (CTRL, CDW3)

Store (CTRL, OSCC)

Return (Local0)

}

Else

{

Or (CDW1, 0×04, CDW1)

Return (Local0)

}

}

После правки метод _OSC (привожу только его):

Method (_OSC, 4, Serialized)

{

Store (Arg3, Local0)

CreateDWordField (Local0, Zero, CDW1)

CreateDWordField (Local0, 0×04, CDW2)

CreateDWordField (Local0, 0×08, CDW3)

// Check for proper UUID

If(LEqual(Arg0,ToUUID(“33DB4D5B-1FF7-401C-9657-7441C03DD766″)))

{

Store (CDW2, SUPP)

Store (CDW3, CTRL)

If(LNotEqual(And(SUPP, 0×16), 0×16))

{

And(CTRL,0x1E,CTRL)

}

And(CTRL,0x1D,CTRL)

If (Not (And (CDW1, One)))

{

If (And (CTRL, One))

{

NHPG ()

}

If (And (CTRL, 0×04))

{

NPME ()

}

}

If (LNotEqual (Arg1, One))

{

Or (CDW1, 0×08, CDW1)

}

If (LNotEqual (CDW3, CTRL))

{

Or (CDW1, 0×10, CDW1)

}

Store (CTRL, CDW3)

Store (CTRL, OSCC)

Return (Local0)

}

Else

{

Or (CDW1, 0×04, CDW1)

Return (Local0)

}

}

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

После этого вот что мне сказал dmesg:

~> dmesg | grep _OSC

[ 1.941655] pci0000:00: Requesting ACPI _OSC control (0x1d)

[ 1.942228] pci0000:00: ACPI _OSC control (0x1d) granted

~> dmesg | grep ASPM

[ 0.000000] PCIe ASPM is forcibly enabled

[ 1.785347] ACPI FADT declares the system doesn’t support PCIe ASPM, so disable it

Последняя строка должна нас смутить. Лезем в исходники ядра:

static int __init acpi_pci_init(void)

{

int ret;

if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_MSI) {

printk(KERN_INFO”ACPI FADT declares the system doesn’t support MSI, so disable it\n”);

pci_no_msi();

}

if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_ASPM) {

printk(KERN_INFO”ACPI FADT declares the system doesn’t support PCIe ASPM, so disable it\n”);

pcie_no_aspm();

}

ret = register_acpi_bus_type(&acpi_pci_bus);

if (ret)

return 0;

pci_set_platform_pm(&acpi_pci_platform_pm);

return 0;

}

и видим, что эта запись выводится в том случае, если ACPI сообщает о том, что ASPM не поддерживается. Но как мы помним, благодаря патчу от Мэтью Гаррета ASPM будет все-равно включен.

И напоследок хочу напомнить вам, что если у вас процессор core iX, то результата эти действия не принесут. Думаю, это из-за того, что контроллер PCI Express встроен в процессоры Intel Core iX. В этом случае лучше уж приобрести рулонный газон и украсить свой сад. Пользы будет больше и отличный фон для кустарников и деревьев будет радовать не только ваш глаз, но и ваших близких и друзей.

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

До новых встреч.

ВНИМАНИЕ!!! Следуйте советам, приведенным ниже, только в том случае, если вы четко понимаете, что вы делаете. Автор не несет ответственности за любые последствия, вызванные манипуляциями, о которых пойдет речь далее.

Итак, если у вас не процессор coreiX и советы по уменьшению энергопотребления ноутбука, описанные в предыдущей статье вам не подходят, а ноут по прежнему очень быстро расходует ресурсы батареи, самое время обратить внимание на ASPM.

Как я уже писал в предыдущей статье, проблема с ASPM в Линуксе была решена включением патча от Мэтью Гаррета в ядро linux начиная с версии 3.3.

Патч действует только в системах, в которых в сообщениях ядра появляется «ACPI FADT declares the system doesn’t support PCIe ASPM, so disable it».

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

Справка из вики:

Интерфейс ACPI организуется путём размещения в определённой области оперативной памяти нескольких таблиц, содержащих описание аппаратных ресурсов и программных методов управления ими. Каждый тип таблицы имеет определённый формат, описанный в спецификации. Кроме того, таблицы, содержащие методы управления устройствами и обработчики событий ACPI, содержат код на языке AML (ACPI Machine Language) — машинно независимый набор инструкций, представленный в компактной форме. Операционная система, поддерживающая ACPI, содержит интерпретатор AML, который транслирует инструкции AML в инструкции центрального процессора, выполняя таким образом методы или обработчики событий.

Некоторые из этих таблиц полностью или частично хранят статические данные в том смысле, что от запуска к запуску системы, они не изменяются. Статические данные, как правило, создаются производителем материнской платы или BIOS и описываются на специальном языке ASL (ACPI Source Language), а затем компилируются в представление на AML.

Так вот, по каким-то совершенно непонятным причинам разработчики BIOS не считают нужным придерживаться стандартов в описании таблиц. В пору, конечно, в очередной раз заподозрить разработчиков в сговоре с пресловутым Мелкософтом. Впрочем, многие производители железа грешат составлением совместных бизнес планов с разработчиками софта. Судить, о том, насколько подобное бизнес планирование выгодно для обоих, не будем. Можем лишь предположить, что если звезды зажигаются… то есть такие договоренности происходят, значит это кому-то нужно. Впрочем, не стоит сбрасывать со счетов и банальную халатность.

Итак, прежде всего нас интересует таблица DSDT, которая содержит описание устройств материнской платы. Для того чтобы нам ее получить, нужно сначала обзавестись необходимым инструментарием. Для этого ставим пакет acpica. После чего выполняем команды:

# acpidump > myacpi.dat

# acpixtract -a myacpi.dat

В результате мы получим все таблицы в бинарном виде. Для того, чтобы получить исходник таблицы DSDT:

# iasl -d DSDT.dat

На выходе мы получаем файл DSDT.dsl, который можно просмотреть обычным текстовым редактором и в случае знания языка ASL, даже что-то понять Мы же пойдем методом научного тыка. Пробуем скомпилировать полученный исходник обратно в бинарный вид:

# iasl -sa DSDT.dsl

В результате мы получим файл DSDT.aml и кучу ошибок в консоли Например:

DSDT.dsl 3060: Name (_T_1, Zero)

Remark 5111 – Use of compiler reserved name ^ (_T_1)

DSDT.dsl 3061: Name (_T_0, Zero)

Remark 5111 – Use of compiler reserved name ^ (_T_0)

DSDT.dsl 4191: Method (WM00, 3, NotSerialized)

Warning 1088 – ^ Not all control paths return a value (WM00)

Собственно, указывается номер строки в исходнике и содержимое ошибки.

Первые 2 ошибки говорят о том, что используется имя, зарезервированное компилятором и устраняются довольно просто. Достаточно заменить _T_X на T_X. Третья ошибка, как вы понимаете, указывает на то, что в методе не всегда возвращается какое-либо значение. Идем к нужной строке и смотрим содержимое метода:

Method (WM00, 3, NotSerialized)

{

Store (“00″, MTNM)

If (LEqual (Arg1, 0×06))

{

WMIS (Arg1, Arg2)

Return (DI00)

}

}

Как видим, в случае не выполнения условия If метод действительно не вернет ничего. Допишем его так:

Method (WM00, 3, NotSerialized)

{

Store (“00″, MTNM)

If (LEqual (Arg1, 0×06))

{

WMIS (Arg1, Arg2)

Return (DI00)

}

Return (0×00)

}

И попробуем снова скомпилировать исходник. Ошибки, которые мы исправили, должны исчезнуть. И так нужно исправить все ошибки, пока компилятор не перестанет ругаться.

У меня в результате получилось:

Intel ACPI Component Architecture

ASL Optimizing Compiler version 20110316-64

Copyright (c) 2000 – 2011 Intel Corporation

ASL Input: DSDT.dsl – 10014 lines, 336764 bytes, 3609 keywords

AML Output: DSDT.aml – 36671 bytes, 862 named objects, 2747 executable opcodes

Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 17 Optimizations

Даже если вы не знаете языка ASL, можно обратиться в гугл, способы исправления основных ошибок в исходнике ASL, как правило, уже давно описаны на многих форумах.

После правки таблицы DSDT нам нужно каким-то образом указать ядру использовать именно его. Один и возможных способов — это включить ее в initrd. Для этого выполняем команды:

# cat DSDT.aml >> /boot/<Имя_нового_initrd>

# cat /boot/<Имя_существующего_initrd> >> /boot/<Имя_нового_initrd>

После этого правим секцию загрузчика, и указываем Начальный RAM-диск как /boot/<Имя_нового_initrd>, после чего перегружаемся, выбирая исправленную секцию при загрузке.

Теперь смотрим, как определилась наша таблица DSDT:

# dmesg | grep DSDT

[ 0.000000] DSDT ACPI table found in initrd – size: 36671

[ 0.000000] ACPI: DSDT @ 0x0000000096ff0000 Phys table override, replaced with:

[ 0.000000] ACPI: DSDT 0000000096e2f000 08F3F (v01 ACRSYS ACRPRDCT 00000000 INTL 20110316)

[ 1.832955] ACPI: EC: Look up EC in DSDT

Как мы видим, наша правленная таблица была успешно подхвачена из initrd.

Продолжение следует.