LINUX.ORG.RU

Ноутбук HP dv6 1123sl проблема с DSDT


0

2

Доброго времени суток!

Имеются в наличии:

1. Бук HP dv6 1123sl.

2. Errors & Warnings в «dmesg» следующего характера:

ACPI Error: [_T_1] Namespace lookup failure, AE_ALREADY_EXISTS (20101013/dswload-802) [ 9.296442] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20101013/psloop-231) [ 9.296447] ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEGP.VGA_.LCD_.GBQC] (Node f3823438), AE_ALREADY_EXISTS (20101013/psparse-537) [ 9.296455] ACPI: Marking method GBQC as Serialized because of AE_ALREADY_EXISTS error [ 9.296461] ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEGP.VGA_.LCD_._BQC] (Node f3823420), AE_ALREADY_EXISTS (20101013/psparse-537) [ 9.296468] ACPI: Marking method _BQC as Serialized because of AE_ALREADY_EXISTS error [ 9.296475] ACPI Warning: Evaluating _BQC failed (20101013/video-538) [ 9.300632] acpi device:08: registered as cooling_device2 [ 9.301621] ACPI Error: [_T_1] Namespace lookup failure, AE_ALREADY_EXISTS (20101013/dswload-802) [ 9.301629] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20101013/psloop-231) [ 9.301634] ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEGP.VGA_.LCD1.GBQC] (Node f38235b8), AE_ALREADY_EXISTS (20101013/psparse-537) [ 9.301642] ACPI: Marking method GBQC as Serialized because of AE_ALREADY_EXISTS error [ 9.301648] ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEGP.VGA_.LCD1._BQC] (Node f38235a0), AE_ALREADY_EXISTS (20101013/psparse-537) [ 9.301655] ACPI: Marking method _BQC as Serialized because of AE_ALREADY_EXISTS error [ 9.301662] ACPI Warning: Evaluating _BQC failed (20101013/video-538)

3. Как следствие Warnings & Remarks в DSDT. 4. Фиксенный мною, вследствии этого, DSDT. Теперь имеющий 0 Errors, 0 Warnings, 0 Remarks, 38 Optimizations. 5. Перезаписанный посредством «initramfs» и сборки ядра (в том числе «ванильном») DSDT, и «dmesg», по - прежнему выводящий вышеописанные ошибки в каждом из вариантов. Пробовал запускать с acpi_osi=Linux/Windows 2006/Windows 2009; Пробовал выпиливать из DSDT все параметры _OS кроме Vista. Ничего не помогло.

Тем у кого появятся какие - нибудь идеи по поводу вышеописанной проблемы, заранее признателен.

С уважением, Ingmar_14.



Последнее исправление: Ingmar_14 (всего исправлений: 3)

Правил DSDT на своём EeePC 1201N, а потом вкомпиливал оное в ядро.
Раньше было так: без опции acpi=copy_dsdt при подключении по wi-fi соединение «жило» минуту-другую, потом отсутствие пингов, потом мёртвый фриз; с опцией acpi=copy_dsdt всё было нормально, но раз-два в недёлю всё равно спонтанно ловил мёртвый фриз системы.
Сейчас всё то же самое, но вообще без фризов (то есть без выше указанной опции wi-fi всё же отваливается, а с опцией всё работает «на пять с плюсом»). Проверка показала, что при использовании собственного ядра (с вкомпиленной правленой DSDT) используется новая DSDT (вне зависимости от использования опции acpi=copy_dsdt).
Вывод: попробуйте опцию acpi=copy_dsdt.
P.S.: Вот все используемые дополнительные опции: video=vesafb:ywrap,mtrr:3 vga=0x37B rdblacklist=nouveau acpi=copy_dsdt acpi_osi=Linux acpi_backlight=vendor pci=nomsi

carasin ★★★★★
()

А ещё после загрузки нового ядра проверьте, удачно ли прошло «подсовывание» ядру кастомной DSDT.

carasin ★★★★★
()

2. Errors & Warnings в «dmesg» следующего характера:

2.1 Ну оформи нормально а читать невозможно

2.2 Это все на чистом ядре без исправленного dsdt(вариант 1) или на ядре с уже «пофиксенным» dsdt (вариант 2)?

init_6 ★★★★★
()

Прошу прощения за оформление - не разобрался форматом вывода.

Начну с пункта 2. Итак, после установки чистой оси с ядром 2.5.35.22 «dmesg» выдал следующий лог:

ACPI Error: [_T_1] Namespace lookup failure, AE_ALREADY_EXISTS (20101013/dswload-802) [ 9.296442] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20101013/psloop-231) [ 9.296447] ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEGP.VGA_.LCD_.GBQC] (Node f3823438), AE_ALREADY_EXISTS (20101013/psparse-537) [ 9.296455] ACPI: Marking method GBQC as Serialized because of AE_ALREADY_EXISTS error [ 9.296461] ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEGP.VGA_.LCD_._BQC] (Node f3823420), AE_ALREADY_EXISTS (20101013/psparse-537) [ 9.296468] ACPI: Marking method _BQC as Serialized because of AE_ALREADY_EXISTS error [ 9.296475] ACPI Warning: Evaluating _BQC failed (20101013/video-538) [ 9.300632] acpi device:08: registered as cooling_device2 [ 9.301621] ACPI Error: [_T_1] Namespace lookup failure, AE_ALREADY_EXISTS (20101013/dswload-802) [ 9.301629] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20101013/psloop-231) [ 9.301634] ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEGP.VGA_.LCD1.GBQC] (Node f38235b8), AE_ALREADY_EXISTS (20101013/psparse-537) [ 9.301642] ACPI: Marking method GBQC as Serialized because of AE_ALREADY_EXISTS error [ 9.301648] ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEGP.VGA_.LCD1._BQC] (Node f38235a0), AE_ALREADY_EXISTS (20101013/psparse-537) [ 9.301655] ACPI: Marking method _BQC as Serialized because of AE_ALREADY_EXISTS error [ 9.301662] ACPI Warning: Evaluating _BQC failed (20101013/video-538)

Это основные ошибки. Мною было решено посмотреть DSDT. Обнаружилось: 0 Errors, 27 Warnings, 20 Remarks, 38 Optimizations. Дальше я всё это дело пофиксил. Как результат: 0 Errors, 0 Warnings, 0 Remarks, 38 Optimizations.

После получения DSDT «без ошибок» предпринял разные способы DSDT override. В первом случае попробовал переписать DSDT.aml через initramfs - ошибки никуда не исчезли. Во втором случае скачал сорцы ядра из репозитория оси, собрал ядро, подсунув DSDT.hex. В третьем (для верности) скачал «ванильное» ядро 2.6.37.4, собрал ядро, подсунув всё тот же DSDT.hex. По итогу «dmesg» выдал тот же лог. Тогда начались эксперименты с правкой acpi_osi.

Ingmar_14
() автор топика
Ответ на: комментарий от Ingmar_14

Выхлоп dmesg надо в тег «code» заключать. Но теперь уже не суть важна.
Мой совет из первого комментария пробовали?

carasin ★★★★★
()
Ответ на: комментарий от Ingmar_14

А вообще, кроме как засорение dmesg, это ещё как-нибудь на стабильность работы системы влияет? Просто обычно DSDT правят в случае необходимости. У Вас есть такая необходимость или просто жалко, что «страдает» dmesg?

carasin ★★★★★
()

>Ну вот твои 27 Warnings и вылазят в dmesg.

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

Мой совет из первого комментария пробовали?


Сейчас попробую и отпишу.

А вообще, кроме как засорение dmesg, это ещё как-нибудь на стабильность работы системы влияет? Просто обычно DSDT правят в случае необходимости. У Вас есть такая необходимость или просто жалко, что «страдает» dmesg?


Не совсем корректно работает Hibernate/Sleep(иногда не просыпается), плюс ко всему, вся эпопея началась с того, что нет показаний датчиков lm sensors.

С уважением, Ingmar_14.

Ingmar_14
() автор топика
Ответ на: комментарий от Ingmar_14

Ingmar_14

Не совсем корректно работает Hibernate/Sleep(иногда не просыпается), плюс ко всему, вся эпопея началась с того, что нет показаний датчиков lm sensors.

В первом случае чаще «грешат» на видео-драйвер. Про второй могу от себя сказать, что ядро (установленной у Вас версии) может попросту не поддерживать Ваши сенсоры (чипсет).
То есть я не говорю категорично, что дело не в ACPI, но, может быть, стОит поискать причину в другом. Тем более, что у Вас в DSDT не было ошибок (Errors), а были только предупреждения (Warnings) и замечания (Remarks).

carasin ★★★★★
()
Ответ на: комментарий от Ingmar_14

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

Я имею в виду то, что ошибки в вашем dsdt вызваны теми самыми 27 варнингами… Вызывают их довольно типичные вещи. Решения в сети есть. Если поборешь все 27 то и сообщение из dmesg пропадет.

init_6 ★★★★★
()

>Я имею в виду то, что ошибки в вашем dsdt вызваны теми самыми 27 варнингами… Вызывают их довольно типичные вещи. Решения в сети есть. Если поборешь все 27 то и сообщение из dmesg пропадет.

Там уже нет Варнингов и Ремарксов, я их заборол. То есть DSDT уже пофиксен. Я имел ввиду, может ли быть такое, что компилятор показывает, что проблем нет, хотя они есть. но не суть важно...

Имеется свежая информация следующего характера:
По совету carasin, я стал добавлять по подстрокам директивы запуска, начиная с acpi=copy_dsdt. Предварительно перед этим поправив DSDT(вернул туда «поддержку» Linux, Win7, так как я уже говорил я их выпилил). Компильнул и поменял старый на новый (в старом была оставлена только Vista). После добавления acpi_backlight=vendor pci=nomsi ошибки пропали. Вместе с тем пропала возможность регулировки яркости LCD. В целях контрольной проверки убрал директивы запуска полностью, оставив только acpi_osi=Linux. Рестартанул ось. В логе опять без ошибок. Сейчас пробую на другом ядре. Пока результат нулевой... Такие дела. Sensors частично заработали...

Ingmar_14
() автор топика
Ответ на: комментарий от Ingmar_14

video=vesafb:ywrap,mtrr:3 vga=0x37B - параметры, ответственные за поведение консолей (видео-драйвер, используемый в них, разрешение); в частности, это позволяет использовать plymouth («красивости» при загрузке/выключении);
rdblacklist=nouveau - параметр, запрещающий ядру загружать видео-драйвер nouveau (т.к. используется драйвер nvidia);
acpi=copy_dsdt - ACPI: add boot option acpi=copy_dsdt to fix corrupt DSDT - в общем, для кривых таблиц DSDT... Впрочем, я уже писАл про этот параметр;
acpi_osi=Linux - иногда этот параметр помогает с мультимедийными клавишами на ноутбуках (в основном, на Asus'ах); в принципе, можно и без него обойтись;
acpi_backlight=vendor - параметр, иногда помогающий задействовать регулировку подсветки клавишами Fn+F{1-12} на некоторых ноутбуках (как правило, работает в связке с параметром acpi_osi=Linux);
pci=nomsi - параметр, указывающий ядру использовать «старый» способ обработки прерываний (IRQ), у меня используется как воркэраунд проблемы с мёртвыми фризами при нагрузке на eth0 (Atheros AR8132).
Думаю, в Вашем случае бездумное использование всего подряд из этого списка не оправдано. Смотрите сами, что Вам необходимо.

carasin ★★★★★
()
Ответ на: комментарий от carasin

>Думаю, в Вашем случае бездумное использование всего подряд из этого списка не оправдано. Смотрите сами, что Вам необходимо.

Совершенно с Вами согласен.

Но Вы оказались АБСОЛЮТНО ПРАВЫ, похоже стоит грешить всё - таки на видео драйвер (ну или на XORG.CONF). Просто перепробовав все варианты на другом ядре (generic), я решил на всякий пожарный кильнуть Атишные дрова и КСОРГ. Выхлоп «dmesg» прошел без ошибок! Короче говоря - есть над чем подумать... Думаю завтра займусь «творческой» работой: поставлю свежее «ванильное» ядро и на нём поэкспериметирую. Обязательно отпишусь о проделанной работе!

Ingmar_14
() автор топика
Ответ на: комментарий от Ingmar_14

Пожалуйста. Рад помочь. А насчёт проделанной работы - гОдно. Даже интересно стало, что там у Вас. Обязательно отписывайтесь.

carasin ★★★★★
()
Ответ на: комментарий от Ingmar_14

Возникла у меня «теория» по этому поводу:
Поставил я ось и драйвер Атишный стал из коробки. Прописался в Xorg.conf соответсвенно. «dmesg» честно показал ошибки. После чего я стал фиксить DSDT. Но прикол в том, что .config ядра при пересборке не не генерил, а копировал существующий в сорц ядра и прописывал в нём фиксенный DSDT(то есть .config был создан на основе нефиксенного DSDT). Я так понимаю, что существующий Xorg.conf подхватывался на автомате и приклеивался к всё тому же сорцу ядра. Отсюда я и получал что на старом ядре, что на новом ядре - «богомерзкий» выхлоп «dmesg» :) Так как там DSDT был ещё старый нефиксенный, а здесь уже фиксенный но со старым Xorg.conf... Посему результат, как говорится, на лице :).
Но это ещё надо доказать, чем я, как уже говорил, и займусь завтра.

Ingmar_14
() автор топика
Ответ на: комментарий от Ingmar_14

Что-то не вяжется это с действительностью.

Ingmar_14

то есть .config был создан на основе нефиксенного DSDT

Ваш старый (изначальный) конфиг, насколько я понял, вообще не содержал записи об использовании кастомной DSDT.
В любом случае, при конфигурировании конфига с помощью make menuconfig, нужно предварительно в этой псевдографической тулзе явно указать (открыть на редактирование) Ваш конфиг. Тогда изменения сохранятся при выходе из этой тулзы в том файле, который Вы этой тулзе указывали. Иначе, сгенерится дефолтный ХЗ-какой конфиг, но с внесёнными Вами изменениями.

Ingmar_14

существующий Xorg.conf подхватывался на автомате и приклеивался к всё тому же сорцу ядра

Этого не может быть в принципе, т.к. в состав Linux-kernel'а не входит графика, в частности, X'ы. И вообще, в последствии Вы можете использовать скомпиленное Вами ядро на любой другой совместимой с нынешней архитектурой машине; то есть, в момент сборки никакой автоматической линковки с индивидуальными параметрами Вашей машины не происходит (если иное явно не указано при конфигурировании, как, например, когда Вы задаёте использование кастомной DSDT).

carasin ★★★★★
()
Ответ на: комментарий от carasin

>Ваш старый (изначальный) конфиг, насколько я понял, вообще не содержал записи об использовании кастомной DSDT.
В любом случае, при конфигурировании конфига с помощью make menuconfig, нужно предварительно в этой псевдографической тулзе явно указать (открыть на редактирование) Ваш конфиг. Тогда изменения сохранятся при выходе из этой тулзы в том файле, который Вы этой тулзе указывали. Иначе, сгенерится дефолтный ХЗ-какой конфиг, но с внесёнными Вами изменениями.

Так оно и было. Я имел ввиду, что я брал .config с установленной оси(а соответственно DSDT там был ещё дефолтный). Копировал его, и через «menuconfig» добавлял туда путь к DSDT.

Ingmar_14
() автор топика
Ответ на: комментарий от Ingmar_14

Не бывает дефолтной DSDT, т.к. таблица DSDT - это, грубо говоря, часть Вашего BIOS'а. При использовании дистрибутивного ядра во время загрузки ОС подхватывается именно таблица DSDT, заложенная производителем Вашей материнской платы (ноутбука). А в случае использования самосборного ядра (если в процессе сборки было явно задано вкомпиливание кастомной DSDT, как, например, в Вашем случае) подхватывается таблица DSDT уже из самого ядра. Если же при сборке опция, сообщающая использование кастомной DSDT, задана не была, то даже в самосборном ядре будет использован неизменная DSDT «от производителя».

carasin ★★★★★
()
Ответ на: комментарий от Ingmar_14

А вообще, неплохо было бы указать конфигурацию «железа», а то гуглить - это как-то в данном вопросе, что на кофейной гуще гадать.

carasin ★★★★★
()
Ответ на: комментарий от carasin

lspci:

00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express Graphics Port (rev 07)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03)
00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.3 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
00:1f.6 Signal processing controller: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem (rev 03)
01:00.0 VGA compatible controller: ATI Technologies Inc M96 [Mobility Radeon HD 4650]
01:00.1 Audio device: ATI Technologies Inc RV710/730
02:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
06:00.0 FireWire (IEEE 1394): JMicron Technology Corp. IEEE 1394 Host Controller
06:00.1 System peripheral: JMicron Technology Corp. SD/MMC Host Controller
06:00.2 SD Host controller: JMicron Technology Corp. Standard SD Host Controller
06:00.3 System peripheral: JMicron Technology Corp. MS Host Controller
06:00.4 System peripheral: JMicron Technology Corp. xD Host Controller
Ingmar_14
() автор топика
Ответ на: комментарий от Ingmar_14

Закрадывается подозрение, что нужно просто правильно оформить xorg.conf. Например, у меня на Fedor'е с версии 13 в xorg.conf'е стали «вредными» опции, касающиеся InputDevice'ов. Из-за них фризилась система. В общем, смотрите документацию на Ubuntu/Ati/X.org . Естественно, это ИМХО.

carasin ★★★★★
()
Ответ на: комментарий от carasin

...в xorg.conf'е стали «вредными» опции, касающиеся InputDevice'ов

У меня возникло ощущение, что я как-то не так ставятся дрова на видео... В xorg.conf у меня после установки минимальный конфиг типа:

Section "Device"
 Identifier "ATI radeon 4650"
 Driver "fglrx"
EndSection
То есть «Input device» даже и близко нет... Сейчас курю всякие разные Wiki.

Ingmar_14
() автор топика
Ответ на: комментарий от carasin

>ЕМНИП, конфиг должен быть намного больше.

Вот и я про то же... Но похоже ситуация потихоньку поясняется...

Ingmar_14
() автор топика
Ответ на: комментарий от Ingmar_14

По результатам отписывайтесь здесь, чтобы потом другие могли посмотреть решение.

carasin ★★★★★
()
Ответ на: комментарий от Ingmar_14

Короче говоря, причина этих ошибок

[   13.601150] ACPI Error (dswload-0802): [_T_1] Namespace lookup failure, AE_ALREADY_EXISTS
[   13.601158] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20100428/psloop-231)
[   13.601163] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.PEGP.VGA_.LCD_.GBQC] (Node f701e438), AE_ALREADY_EXISTS
[   13.601175] ACPI: Marking method GBQC as Serialized because of AE_ALREADY_EXISTS error
[   13.601213] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.PEGP.VGA_.LCD_._BQC] (Node f701e420), AE_ALREADY_EXISTS
[   13.601223] ACPI: Marking method _BQC as Serialized because of AE_ALREADY_EXISTS error
[   13.601265] ACPI Warning: Evaluating _BQC failed (20100428/video-651)
[   13.660076] acpi device:07: registered as cooling_device2
[   13.663360] ACPI Error (dswload-0802): [_T_1] Namespace lookup failure, AE_ALREADY_EXISTS
[   13.663367] ACPI Exception: AE_ALREADY_EXISTS, During name lookup/catalog (20100428/psloop-231)
[   13.663373] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.PEGP.VGA_.LCD1.GBQC] (Node f701e5b8), AE_ALREADY_EXISTS
[   13.663384] ACPI: Marking method GBQC as Serialized because of AE_ALREADY_EXISTS error
[   13.663424] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.PEGP.VGA_.LCD1._BQC] (Node f701e5a0), AE_ALREADY_EXISTS
[   13.663433] ACPI: Marking method _BQC as Serialized because of AE_ALREADY_EXISTS error
- методы измененяющие яркость экрана (method _BQC, method _GBQC). Их надо фиксить в DSDT. Как пока сам не знаю. Купируется этот «симптом» именно прописыванием acpi_backlight=vendor в параметрах загрузки, но при этом я уже не могу изменять яркость посредством Fn+F7-F8. Вообще говоря об этой директиве загрузки можно сказать следующее:
1. acpi_backlight=video (дефолтный режим изменения яркости, используя драйвер видео и утилиту изменения яркости, у ATi это radeontool). 
2. acpi_backlight=vendor (соответственно режим отключения поддержки динамического изменения яркости комбинацией клавиш(Fn+(F1-F12)), используя драйвер видео)

То есть пока у меня в параметрах загрузки стоит acpi_backlight=vendor. Вышеописанных ошибок больше нет. Дальше будем разбираться..

Ingmar_14
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.