«Огромное число ошибок тормозит развитие ядра»

> Ага, и как этот идентификатор следует интерпретировать? Что он нам говорит?

О том, что Linux получает настройки таблицы роутинга прерываний от ACPI, т.е. от BIOS и если индусы что-то там напортачили, то это не сулит ничего хорошего.

> То, что стандартный PC-шный контроллер прерываний это intel 8259A или аналогичный в составе чипсета, а не APIC. Это к вопросу о том кто же будет обрабатывать прерывания.

Любопытно, а размышлений о том, кто такой I/O APIC у вас в черепной коробочке не водится?

> 0x40 означает неправильный вектор прерывания.

Шо вы-таки говорите? В каком смысле "неправильный"?

> Пинать индусов написавших кривой BIOS.

Т.е. вы согласны, что своими рассуждениями насчет SMP и PIC просто подпортили воздух в помещении?

> С того, что немного знаю про архитектуру PC, PIC и APIC. В таком случае, вам ничто не мешает обосновывать свои утверждения, не правда ли? Просто попытайтесь добавлять к каждой глупости, которую вы собрались написать, пояснение - почему вы так считаете. И сами поймете, какую ерунду вы тут пишете :-)

> О том, что Linux получает настройки таблицы роутинга прерываний от ACPI, т.е. от BIOS и если индусы что-то там напортачили, то это не сулит ничего хорошего.

Ход вашей мысли мне не ясен, извините.

> Это разработчикам BIOS видней.

Ну если вы рассуждаете о том, о чем не имеете представления - это ли не флуд?

> Например, кривыми ACPI таблицами. Тем более выше я привел конкретный пример чудного избавления от Apic Error 0x40 путем обновления BIOS, что подтверждает теорию.

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

> Ход вашей мысли мне не ясен, извините.

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

> Ну если вы рассуждаете о том, о чем не имеете представления - это ли не флуд?

Вы очень дохера много знаете, особенно откуда Linux берет настройки APIC.

> Или иди матчасть по ACPI, ACPI таблицам роутинга прерываний, где они находятся и кто за них отвечает, или не ипи моск своей демагогией.

Видишь, ты не в состоянии пояснить что ты тут брякнул. Потому, что ты пустозвон.

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

ПОка я привел конкретный реальный пример того, как после обновления BIOS точно такие же ошибки вдруг чудным образом починились. Наверное, производители говнобиоса пропатчили глючный Linux из BIOS-а?

> Вы очень дохера много знаете, особенно откуда Linux берет настройки APIC.

Ответ такой же, как предыдущему оратору.

> Наверное

Именно, что "наверное". Я бы предпочел избежать обсуждения вопросов веры :-)

> Видишь, ты не в состоянии пояснить что ты тут брякнул. Потому, что ты пустозвон.

Плять это ты мудозвон. Откуда по-твоему Linux берет настройки контроллера прерываний? Из пальца высасывает? Вот тебе строка из dmesg сиди и осмысливай свою тупизну:

[ 19.758527] ACPI: Using IOAPIC for interrupt routing

и эту впридачу

[ 0.000000] ACPI: APIC 1FFF7100, 0068 (r1 GBT AWRDACPI 42302E31 AWRD 1010101)

> сиди и осмысливай свою тупизну

Ты прочесть в состоянии, что написано в приведенной тобой же строке?

Читай еще раз свой тупой бред:

> В системе существует прерывание, которое в упор не воспринимается линуксом. И ни железо ни биос тут ни при чем - их задача обеспечить вызов указанного линуксом кода по данному прерыванию и они это делают исправно.

Ага исправно, с ошибкой 0x40 и кучей ERR в /proc/interrupts. До тебя что, сложно доходит, что AWRDACPI означает идентификатор ACPI таблицы в Award BIOS, по которой и инициализщуируется контроллер прерываний?

Вот как выглядит нормальное железо с BIOS-ом не слишком большой паршивости с корректными ACPI таблицами.

$ grep ERR /proc/interrupts
ERR: 0

ACPI: Используется I/O APIC для маршрутизации прерываний

Объяснять откуда растут ноги у ACPI нужно и каким здесь боком BIOS?

> Ага исправно, с ошибкой 0x40 и кучей ERR в /proc/interrupts. До тебя что, сложно доходит, что AWRDACPI означает идентификатор ACPI таблицы в Award BIOS, по которой и инициализщуируется контроллер прерываний?

Ну да. Ошибка 40h появляется в результате первой "обработки" линуксом этого прерывания. Ну вы хоть почитайте что я вам выше писал.

P.S. Я бы вам предложил закончить с болтологией. Я конечно понимаю, что получив вчера от меня по носу, вы пытаетесь сегодня взять реванш анонимно, как-то дискредитировать меня что-ли в глазах общественности что бы как-то реабилитировать свой псевдоним. Я бы вам порекомендовал затаить на меня злобу и выместить её в той теме, в которой вы компетентны.

> Я конечно понимаю, что получив вчера от меня по носу, вы пытаетесь сегодня взять реванш анонимно

Вы меня с кем-то путаете. Я анонимус по жизни.

> как-то дискредитировать меня что-ли в глазах общественности что бы как-то реабилитировать свой псевдоним

Не угадал. Я просто не смог пройти спокойно мимо твоих выступлений, в которых рассказывалось как бедные юзеры повально мучаются с APIC Error 0x40 и как мультипроцессорные системы тоже глючат и что на ЛОРе все ламеры неспособные объяснить что значит код 0x40 и что BIOS(ACPI) не при чем, и что венда де работает замечательно и т.п. муйни. Ведь ясно как белый день, что ты зашел сюда попи*еть и обосрать Linux и всех присутствующих здесь линуксоидов, отсюда и демагогия, "ах что значат эти ключи", "какой кошмар они от 2002 года" и пр. Если бы ты хотел реально разобраться кто виноват и что делать или аргументированно ткнуть нас носом, что Linux реально глючит на некоторых конфигурациях, а не сбоит из-за кривого биоса, то привел бы lspci, uname -a, /proc/interrupts, dmesg и дампы ACPI таблиц(что это такое можешь посмотреть на примере /proc/acpi/fadt и /proc/acpi/dsdt), чтобы моожно было выяснить причину.

анонимус, забей на него. явный тролль.

> Вы меня с кем-то путаете. Я анонимус по жизни.

Неправда. У "анонимусов по жизни" обычно нет комплексов, вынуждающих их высказываться в той теме, которая им не интересна и в которой они не смыслят нихрена (анонимус не вынужден поддерживать некий имидж, связанный в его представлении с его псевдонимом, по этому он более раскован и интересен в общении, чем чванливый неанонимус).

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

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

> Я просто не смог пройти спокойно мимо твоих выступлений, в которых рассказывалось как бедные юзеры повально мучаются с APIC Error 0x40 и как мультипроцессорные системы тоже глючат

Ну да, и как Чип-и-Дейл поспешил на помощь своим тупым неанонимным собратьям в опровержении очевидного факта, легко подтверждаемого одним запросом к гуглу :-D

> и что на ЛОРе все ламеры неспособные объяснить что значит код 0x40 и что BIOS(ACPI) не при чем, и что венда де работает замечательно и т.п. муйни.

Ну вот видишь, что и требовалось доказать, как говорится. А говоришь, что я не угадал :-)

Я не утверждал, что тут все ламеры, но указал на глупость пары участников дискуссии, забивающих обсуждение своим пустозвонством. Но я не стану показывать пальцем кто из них ты: пусть остальные читатели этого треда сами решат для себя эту сложную головоломку :-D

yу и зачем ты расшифровался? Мы бы ещё поугадывали - кто он такой, этот умный анонимус :-D

> Неправда. У "анонимусов по жизни" обычно нет комплексов, вынуждающих их высказываться в той теме, которая им не интересна и в которой они не смыслят нихрена

Да ты сам дуб-дубом, тролль. Если бы я ничего не понимал, то не сделал бы ни эту программку и не разобрался бы с приведенной выше аппаратной проблемой http://www.linux.org.ru/add_comment.jsp?topic=2140391&replyto=2143265. Я не мегаспециалист по ACPI и APIC, но такого бреда бы, что железо и BIOS не при не заявил бы. И было бы у меня твое железо с причиной бы я разобрался, покопавшись и вкурив спеки по APIC из Intel IA-32, спеки на чипсет и ACPI, даже если бы все это потребовало бы дизассемблирования кода BIOS, благо опыт имеется.

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

Вероятную причину на основании крупиц предоставленных тобой информации тебе предоставили. Конкретный пример где BIOS исправляет такую же ошибку ACPI error 0x40 привели. Валяй, сри дальше в форуме, занимаясь демагогией, если нечем больше заняться. Если будет что сказать по теме, скинуть куда-нибудь информацию, позволяющую локализовать проблему, или еслиу тебя есть неопровержимые доказательства глючности именно Linux, а не кривых таблиц ACPI - приводи, по существу, без воды, которой ты залил весь топик. А слушать один и тот же околокомпьютерный треп мне неинтересно.

> Но я не стану показывать пальцем кто из них ты: пусть остальные читатели этого треда сами решат для себя эту сложную головоломку :-D

Веришь или нет, но мне пох что ты там думаешь. Можешь попросить модератора выяснить тот ли я о ком ты там думаешь по IP.

Если хотите продолжать общение, высказывайтесь по существу - в чем на ваш взгляд причина возникновения проблемы, как именно возникает эта ошибка и почему вы считаете, что она возникает именно так.

Если вам необходима какая-то конкретная информация - вы можете попросить её у меня. Как вы могли убедиться, когда у меня просят конкретную информацию - я её предоставляю, несмотря даже на то, что иногда явно просят сами не зная зачем.

Короче, либо говорите предметно и аргументированно, либо идите в жопу.

Вот это уже другой разговор.

> Если хотите продолжать общение, высказывайтесь по существу - в чем на ваш взгляд причина возникновения проблемы, как именно возникает эта ошибка и почему вы считаете, что она возникает именно так.

Предположительно, проблема в кривой APIC Table в ACPI DSDT.

> Если вам необходима какая-то конкретная информация - вы можете попросить её у меня. Как вы могли убедиться, когда у меня просят конкретную информацию - я её предоставляю, несмотря даже на то, что иногда явно просят сами не зная зачем.

Выложи, если тебя это не затруднит, lspci, uname -a, cat /proc/interrupts, dmesg и sudo cat /proc/acpi/dsdt > dsdt на какой-нибудт slil.ru, imageshack.us или cl1p.net.

Еще неплохо бы посмотреть файл дампа acpidump > acpi.bin.
Утилита на http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/

Как можно увидеть здесь:
http://acpi.sourceforge.net/dsdt/view.php?id=728

У Microstar есть таблица APIC Table yes

> Любопытно, а размышлений о том, кто такой I/O APIC у вас в черепной коробочке не водится?

I/O APIC подключен к local APIC.

Note that the local APIC can be disabled (see Section 8.4.3, “Enabling or Disabling the Local APIC”). This allows an associated processor core to receive interrupts directly from an 8259A interrupt controller.

> Шо вы-таки говорите? В каком смысле "неправильный"?

В смысле ошибка "Received Illegal Vector".

When an interrupt vector in the range of 0 to 15 is sent or received through the local APIC, the APIC indicates an illegal vector in its Error Status Register (see Section 8.5.3, “Error Handling”). The IA-32 architecture reserves vectors 16 through 31 for predefined interrupts, exceptions, and Intel-reserved encodings (see Table 5-1). However, the local APIC does not treat vectors in this range as illegal. When an illegal vector value (0 to 15) is written to an LVT entry and the delivery mode is Fixed (bits 8-11 equal 0), the APIC may signal an illegal vector error, without regard to whether the mask bit is set or whether an interrupt is actually seen on the input.

> Т.е. вы согласны, что своими рассуждениями насчет SMP и PIC просто подпортили воздух в помещении?

APIC может быть отключен. В старых BIOS-ах была такая функция и система нормально продолжала работать со стандартным PIC i8259A встроенынм в чипсет...

> Предположительно, проблема в кривой APIC Table в ACPI DSDT по-че-му ^

> Выложи, если тебя это не затруднит http://slil.ru/24859587

> Еще неплохо бы посмотреть файл дампа acpidump

По части APIC:

APIC @ 0x7bef6e80 0000: 41 50 49 43 68 00 00 00 01 7a 48 50 2d 43 50 43 APICh....zHP-CPC 0010: 41 57 52 44 41 43 50 49 31 2e 30 42 41 57 52 44 AWRDACPI1.0BAWRD 0020: 00 00 00 00 00 00 e0 fe 01 00 00 00 00 08 00 00 ................ 0030: 01 00 00 00 00 08 01 01 00 00 00 00 01 0c 02 00 ................ 0040: 00 00 c0 fe 00 00 00 00 02 0a 00 00 02 00 00 00 ................ 0050: 00 00 02 0a 00 09 09 00 00 00 0f 00 04 06 00 05 ................ 0060: 00 01 04 06 01 05 00 01 ........

Если вам нужны остальные секции дампа - пишите, выложу через тот же сайт.

> I/O APIC подключен к local APIC. .. что бы обрабатывать прерывания от внешних устройств.

> Note that the local APIC can be disabled (see Section 8.4.3, “Enabling or Disabling the Local APIC”). This allows an associated processor core to receive interrupts directly from an 8259A interrupt controller.

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

> When an illegal vector value (0 to 15) is written to an LVT entry and the delivery mode is Fixed (bits 8-11 equal 0), the APIC may signal an illegal vector error, without regard to whether the mask bit is set or whether an interrupt is actually seen on the input.

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

> APIC может быть отключен. В старых BIOS-ах была такая функция и система нормально продолжала работать со стандартным PIC i8259A встроенынм в чипсет...

Ух. Ло-каль-ный апик. если в системе нет айо-апика, а сидит обычный пик - то локальный апик надо тоже отключать. Но не более того.

Во, смотри, Анонимус, специально для тебя цитатку выгуглил: "Most x86 systems rely on either the i8259A Programmable Interrupt Controller (PIC) or a variant of the i82489 Advanced Programmable Interrupt Controller (APIC); the majority of new computers include an APIC. "

Понимаешь, тут одно из двух - или в системе установлен ПИК или там АПИК - понимаешь? Не И, а ИЛИ, одно из двух блин. Написано коротко и ясно, и не невесть кем написано, а самим микрософтом :-) http://book.itzero.com/read/microsoft/0507/Microsoft.Press.Microsoft.Windows....

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

Неверно.

Локальный APIC может быть запрещен. Это позволяет соответствующему ядру проуессора получать прерывания непосредственно от контроллера прерываний 8259A.

http://en.wikipedia.org/wiki/Intel_APIC_Architecture#I.2FO_APICs

In systems containing an 8259 PIC, the 8259 may be connected to the LAPIC in the system's bootstrap processor (BSP), or to one of the system's I/O APICs.

В системах со стандартным контроллером прерываний 8259, он может быть подключен или к локальному APIC на BSP или к одному из системных I/O APIC-ов.

Там же:

Hardware Bugs
...
There are defective BIOSes which do not set up interrupt routing properly. This includes the errors in the implementation of ACPI tables and Intel Multiprocessor Specification tables.

Перевожу: Аппаратные ошибки
Существуют дефективные BIOS-ы которые неправильно устанавливают таблицу маршрутизации прерываний. Это включает в себя ошибки реализации ACPI таблиц и MP-таблиц.


> "Most x86 systems rely on either the i8259A Programmable Interrupt Controller (PIC) or a variant of the i82489 Advanced Programmable Interrupt Controller (APIC)

The local APIC in the P6 family and Pentium processors is an architectural subset of the Intel®
82489DX external APIC.

Локальный встроенный в процессор APIC это и есть вариант i82489.

> [ 54.413603] Kernel command line: root=UUID=5686e619-db23-43e2-b249-d78c1c4db770 ro nosplash noacpi

Ключ noacpi - это разве дефолтная конфигурация?

> [ 0.000000] ATI board detected. Disabling timer routing over 8254.

А вот пример кривости железа - чипсета ATI(__init ati_bugs(void))...

Насчет того, что первая строка была не ошибкой:
[ 478.932000] APIC error on CPU0: 00(40)
Ошибаетесь. Ошибка. На IRQ 0x40. Правда со странным статусом ноль...

Странно, кроме чипсетов ATI RS480 проблема похоже нигде больше не проявляется. ATI-шники что-то накосячили с реализацией IOAPIC )

> In systems containing an 8259 PIC..

Забудьте уже про эти системы, они ушли в прошлое вместе со своими пиками и переключателями биоса. Не верите микрософту? Вот с той же вики: "The 8259 has coexisted with the Intel APIC Architecture since its introduction in Symmetric Multi-Processor PCs. Modern PCs have since begun to completely phase out the use of the 8259 family in favor of the exclusive use of the Intel APIC Architecture." ( http://en.wikipedia.org/wiki/8259 )

> В системах со стандартным контроллером прерываний 8259, он может быть подключен или к локальному APIC на BSP или к одному из системных I/O APIC-ов

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

> Существуют дефективные BIOS-ы которые неправильно устанавливают таблицу маршрутизации прерываний. Это включает в себя ошибки реализации ACPI таблиц и MP-таблиц.

А я вот думаю, что кернел сам с роутингом определяется, вон он в логе пишет: "ATI board detected. Disabling timer routing over 8254", "Using IOAPIC for interrupt routing".. При этом, если брать за рабочую гипотезу, что ваше предположение верно, то вам придется признать, что виндовс как-то умудряется этот роутинг себе организовать, а линукс - нет :-)

> Локальный встроенный в процессор APIC это и есть вариант i82489.

Но вы ведь уловили суть: "или пик или апик"?

> Ключ noacpi - это разве дефолтная конфигурация?

А вы и не просили dmesg именно для дефолтной конфигурации. Я скинул текущую. Не суть - апик-ерор присутствует в логе независимо от того установлен noacpi или нет.

> А вот пример кривости железа - чипсета ATI(__init ati_bugs(void))...

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

И опять же что с того? Аппаратура имеет свои особенности и операционные системы обычно не имеют никаких проблем с использованием данной фичи, по-видимому даже линукс, несмотря на встроенный в него ati_bug ;-)

>Насчет того, что первая строка была не ошибкой: [ 478.932000] APIC error on CPU0: 00(40) Ошибаетесь. Ошибка. На IRQ 0x40. Правда со странным статусом ноль... Тут мы с вами оба ошиблись. Это всё-таки специальное прерывание, которое "is generated when the local APIC sets one of the error bits in the ESR." - т.е. лапик, видимо, обиделся на то, что под управлением линукса его попросили послать какой-то неправильный вектор. Цифра ноль не имеет значения, потому, что перед скобками мусор, а истинное значение ошибки приводится в скобках (что на мой взгляд говорит о том, что тот, кто писал драйвер, не сильно был обременен пониманием того, что он выводит - я уж не говорю о как-нибудь более продвинутой диагностике) - просто программа должна осуществлять предварительную холостую запись в ESR (он записи защелкивает значение ошибки) и после этого из регистра считывается актуальная информация, а нолик - это так, остался от предыдущей ошибки, которой не было. Так у интела в доках написано.

> Странно, кроме чипсетов ATI RS480 проблема похоже нигде больше не проявляется. ATI-шники что-то накосячили с реализацией IOAPIC )

Я подозреваю, что они с другим накосячили.. При активной работе с дисками на матери нехило греется вот эта деталь: http://cimg.163.com/dp/050713/a1176cn/clip_image001_0016.jpg При этом аналогичная фигня у меня и с интелом была на работе, но тот честно падал и под виндовсом. А этот не падал.. Я вот думаю, может они используют отдельное прерывание от чипа, сигнализируещее о перегреве и пр. аварийных ситуациях что бы система могла притормозить обмен и дать чипу остыть, ну и встраивают этот костыль в закрытые драйвера, а линуксоидам никогда и не за что про это прерывание не расскажут потому, что те поднимут визг, что у АТИ цифры дутые и реально чипсет неспособен качать данные на заявленной скорости.. Ну просто гипотеза, рожденная желанием как-то оправдать линукс :-)

> Многоуважаемые любители линуксового ядра, пожалуйста, помогите мне:

Господи, ты и тут вылез со своим оффсетом....

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

За неполоманное ABI, небось, трясутся?

> и по этому линукс в принципе не может работать с такой железкой, в то время как виндовс может.

А в логи винды что-нибудь пишется? И есть ли они вообще? :)

Кривой ACPI на тошибах - древняя традиция.

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

В качестве примера такой "заботы" можно почитать на ixbt ветку про тошибу A100-906. На странице 129 находится ссылка на статью, сделанную владельцем такой тошибы:

...

Ищем в файле dsdt.dsl слово _OSI, исправляем Store (One, LINX) на Store (0×03E8, OSYS) (как вариант можно использовать Store (0×07D6, OSYS)). Возможно, лучшим вариантом было прикинуться, какой-нибудь Windows, но я поленился ;)

Компилируем заново:

# iasl -tc dsdt.dsl

Если ошибок компиляции небыло, то на выходе получаем два файла - dsdt.aml и dsdt.hex. Нас интересует последний.
Компиляция ядра с новым DSDT.

Далее все строго по мануалу Встраивание в Кернел.
Перегружаемся и проверяем. В моем случае нареканий небыло.

Вообще после всей проделанной работы, у меня сложилось впечатление, что Toshiba намерено внесла такие коррективы в биос.

...

Для сравнения, вот что было:

If (CondRefOf (_OSI, Local0))
{
If (_OSI ("Linux"))
{
Store (One, LINX)
}

If (_OSI ("Windows 2001"))
{
Store (0x07D1, OSYS)
}

If (_OSI ("Windows 2001 SP1"))
{
Store (0x07D1, OSYS)
}

If (_OSI ("Windows 2001 SP2"))
{
Store (0x07D2, OSYS)
}

If (_OSI ("Windows 2006"))
{
Store (0x07D6, OSYS)
}
}

> http://slil.ru/24859587

Глянь в табличке DSDT Method (\_SB.PCI0._INI, 0, NotSerialized). ACPI_OS_NAME в линуксе по-умолчанию равно "Microsoft Windows NT" (_OS), но _OSI не будет "Windows 2001". Т.е. в случае с линуксом _SB.PCI0._INI вообще ничего делать не будет, просто офигительно. Возможно, ничего страшного, но лично меня такая "аккуратность" напрягает.

            Method (\_SB.PCI0._INI, 0, NotSerialized)
            {
                If (STRC (\_OS, "Microsoft Windows"))
                {
                    Store (0x56, SMIP)
                }
                Else
                {
                    If (STRC (\_OS, "Microsoft Windows NT"))
                    {
                        If (CondRefOf (\_OSI, Local0))
                        {
                            If (\_OSI ("Windows 2001"))
                            {
                                Store (0x59, SMIP)
                                Store (0x00, OSFL)
                                Store (0x03, OSFX)
                            }
                        }
                        Else
                        {
                            Store (0x58, SMIP)
                            Store (0x00, OSFX)
                            Store (0x00, OSFL)
                        }
                    }
                    Else
                    {
                        Store (0x57, SMIP)
                        Store (0x02, OSFX)
                        Store (0x02, OSFL)
                    }
                }
            }

Собственно, патч:

diff -up ./dsdt.dsl.orig ./dsdt.dsl
--- ./dsdt.dsl.orig     2007-09-16 02:20:42.000000000 +0200
+++ ./dsdt.dsl  2007-09-16 02:34:06.000000000 +0200
@@ -2907,12 +2907,9 @@ DefinitionBlock ("dsdt.aml", "DSDT", 1, 
                     {
                         If (CondRefOf (\_OSI, Local0))
                         {
-                            If (\_OSI ("Windows 2001"))
-                            {
-                                Store (0x59, SMIP)
-                                Store (0x00, OSFL)
-                                Store (0x03, OSFX)
-                            }
+                            Store (0x59, SMIP)
+                            Store (0x00, OSFL)
+                            Store (0x03, OSFX)
                         }
                         Else
                         {

> А в логи винды что-нибудь пишется? И есть ли они вообще? :)

Про прерывания не припомню чот.. Но вот зависни оно ни с того ни с сего - уж заметил бы небось :-)

> Ищем в файле dsdt.dsl слово _OSI, исправляем Store (One, LINX) на Store (0×03E8, OSYS)

Что-б я ещё понял что означают эти странные строки в том файле..

> Глянь в табличке DSDT Method (\_SB.PCI0._INI, 0, NotSerialized).

Да, всё в точности так. Лишнее условие убрал, при компиляции ещё варнингов получил. Типа:

dsdt.dsl 228: Method (\_WAK, 1, NotSerialized)
Warning 1079 - ^ Reserved method must return a value (_WAK)

dsdt.dsl 2372: Return (GTF (0xA0, BUF))
Warning 1098 - Statement is unreachable ^


Вопрос такой, при загрузке кернел пишет:

ACPI: Looking for DSDT in initramfs... file /DSDT.aml not found, using machine DSDT.

Т.е. видимо нет необходимости перекомпилять кернел, а надо просто куда-то подсунуть этот aml-файл? В каком каталоге он его ищет?

> В каком каталоге он его ищет? А, дошло. В initrd его пихать надо, вроде. Завтра поэкспериментирую..

> А, дошло. В initrd его пихать надо, вроде. Завтра поэкспериментирую..

Если у тебя убунта, то в /etc/initramfs-tools положи под именем DSDT.aml и пересобери образ рамдиска: dpkg-reconfigure linux-image-$(uname -r)

> Да, всё в точности так. Лишнее условие убрал, при компиляции ещё варнингов получил. Типа:

dsdt.dsl 228: Method (\_WAK, 1, NotSerialized) Warning 1079 - ^ Reserved method must return a value (_WAK)

dsdt.dsl 2372: Return (GTF (0xA0, BUF)) Warning 1098 - Statement is unreachable ^

Пардон за предыдущий пост

> dsdt.dsl 2372: Return (GTF (0xA0, BUF))
> Warning 1098 - Statement is unreachable ^ 

Return (Local5)
Return (GTF (0xA0, BUF))

iasl ведь прав... Хотя, по сути ничего страшного в местах с warning'ами не происходит, но вот патч:

diff -up ./dsdt.dsl.orig ./dsdt.dsl
--- ./dsdt.dsl.orig	2007-09-16 02:20:42.000000000 +0200
+++ ./dsdt.dsl	2007-09-16 11:11:32.000000000 +0200
@@ -288,6 +288,7 @@ DefinitionBlock ("dsdt.aml", "DSDT", 1, 
                 \_SB.PCI0.LPC0.DSPI ()
             }
         }
+        Return(Package(0x02){0x00, 0x00})
     }
 
     Scope (\_SI)
@@ -2369,7 +2370,6 @@ DefinitionBlock ("dsdt.aml", "DSDT", 1, 
                                     0x00, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xF5
                                 }, Local5)
                             Return (Local5)
-                            Return (GTF (0xA0, BUF))
                         }
                     }
 
@@ -2395,7 +2395,6 @@ DefinitionBlock ("dsdt.aml", "DSDT", 1, 
                                     0x00, 0x00, 0x00, 0x00, 0x00, 0xB0, 0xF5
                                 }, Local5)
                             Return (Local5)
-                            Return (GTF (0xB0, BUF))
                         }
                     }
                 }
@@ -2463,7 +2462,6 @@ DefinitionBlock ("dsdt.aml", "DSDT", 1, 
                                     0x00, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xF5
                                 }, Local5)
                             Return (Local5)
-                            Return (GTF (0xA0, BUF))
                         }
                     }
 
@@ -2489,7 +2487,6 @@ DefinitionBlock ("dsdt.aml", "DSDT", 1, 
                                     0x00, 0x00, 0x00, 0x00, 0x00, 0xB0, 0xF5
                                 }, Local5)
                             Return (Local5)
-                            Return (GTF (0xB0, BUF))
                         }
                     }
                 }
@@ -2907,12 +2904,9 @@ DefinitionBlock ("dsdt.aml", "DSDT", 1, 
                     {
                         If (CondRefOf (\_OSI, Local0))
                         {
-                            If (\_OSI ("Windows 2001"))
-                            {
-                                Store (0x59, SMIP)
-                                Store (0x00, OSFL)
-                                Store (0x03, OSFX)
-                            }
+                            Store (0x59, SMIP)
+                            Store (0x00, OSFL)
+                            Store (0x03, OSFX)
                         }
                         Else
                         {

> А я вот думаю, что кернел сам с роутингом определяется, вон он в логе пишет: "ATI board detected. Disabling timer routing over 8254", "Using IOAPIC for interrupt routing"..

Linux по умолчанию использует настройки BIOS и иногда подхакивает эти настройки у глючных BIOS-ов. Плюс в некоторых BIOS-ах в DSDT торчит некая APIC table...


/usr/src/linux/arch/i386/pci/irq.c


/*
* Check passed address for the PCI IRQ Routing Table signature
* and perform checksum verification.
*/

static inline struct irq_routing_table * pirq_check_routing_table(u8 *addr)
{
struct irq_routing_table *rt;
int i;
u8 sum;

rt = (struct irq_routing_table *) addr;
if (rt->signature != PIRQ_SIGNATURE ||
rt->version != PIRQ_VERSION ||
rt->size % 16 ||
rt->size < sizeof(struct irq_routing_table))
...

/usr/src/linux/drivers/acpi/pci_irq.c
/* --------------------------------------------------------------------------
PCI IRQ Routing Table (PRT) Support
-------------------------------------------------------------------------- */

static struct acpi_prt_entry *acpi_pci_irq_find_prt_entry(int segment,
int bus,
int device, int pin)
{
struct list_head *node = NULL;
struct acpi_prt_entry *entry = NULL;


if (!acpi_prt.count)
return NULL;

/*
* Parse through all PRT entries looking for a match on the specified
* PCI device's segment, bus, device, and pin (don't care about func).
*
*/
...


> При этом, если брать за рабочую гипотезу, что ваше предположение верно, то вам придется признать, что виндовс как-то умудряется этот роутинг себе организовать, а линукс - нет :-)

Windows точно также полагается на настройки BIOS и по-другому настраивае6т железо(так, например, в случае проблем с MTRR, тип WC в MTRR был прописан только в Linux по запросу fglrx, а для рассчета маски Linux полагался на результаты полученные из cpuid, в то время как Windows по запросу тех же дров ATI помечала сами страницы памяти типом кеширования WC, а не прописывала диапазон с типом WC в MTRR). К тому же с чего вы решили, что Windows не ловит проблем с APIC и молчит об этом? Как там посмтреть grep ERR /proc/interrupts?

> Ну вот вы опять утверждаете, что железо криво на основании одного только названия функции, без каких-либо отсылок к документации - как на самом деле чипсет д/б реализован и в чем расхождения с дизайном.

А вы посмотрите код...

> И опять же что с того? Аппаратура имеет свои особенности и операционные системы обычно не имеют никаких проблем с использованием данной фичи, по-видимому даже линукс, несмотря на встроенный в него ati_bug ;-)

Я все это к чему говорю. К тому, что индусские биосы кривые, железо кривое, и в итоге какая система будет иметь на борту больше всего костылей-workarounds, та и сможет нормально выжить. А какие у вас проблемы, кроме сообщений об ошибках APIC, о которых винда молчит?

> Цифра ноль не имеет значения, потому, что перед скобками мусор, а истинное значение ошибки приводится в скобках

Точно, что-то я протупил ... Там два раза читается ESR - сразу при входе в ISR обработки прерывания свид-щего об ошибке и после записи в ESR нуля.

> что тот, кто писал драйвер, не сильно был обременен пониманием того, что он выводит

Ну а чего плохого в том, чтобы распечатать предыдущее значение ESR и текущее? printk (KERN_DEBUG "APIC error on CPU%d: %02x(%02x)\n", smp_processor_id(), v , v1); v - состояние до v1 - текущее состояние ESR.

> Ну просто гипотеза, рожденная желанием как-то оправдать линукс :-)

А что его оправдывать? Какие-то последствия от того, что APIC сыплет ошибки есть?

> А что его оправдывать? Какие-то последствия от того, что APIC сыплет ошибки есть?

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

> Если у тебя убунта, то в /etc/initramfs-tools положи под именем DSDT.aml и пересобери образ рамдиска: dpkg-reconfigure linux-image-$(uname -r)

Да, всё сработало.

APIC error on CPU0 остался..

>> А что его оправдывать? Какие-то последствия от того, что APIC сыплет ошибки есть? >Увеличивает энтропию, приближая тепловую смерть Вселенной. Логи место лишнее на диске занимают.

Писал же - иногда в разгар этих самых ошибок, машина виснет. И по отзывам владельцев этих самых APIC-ерроров, виснет не у меня одного.

> Linux по умолчанию использует настройки BIOS и иногда подхакивает эти настройки у глючных BIOS-ов.

Вот я и говорю - хреново подхакивает, ошибки сыплются. А вы на меня набросились за правду и жрёте поедом :-)

> Плюс в некоторых BIOS-ах в DSDT торчит некая APIC table...

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

> Windows точно также полагается на настройки BIOS и по-другому настраивае6т железо

Да, разница явно присутствует..

> К тому же с чего вы решили, что Windows не ловит проблем с APIC и молчит об этом? Как там посмтреть grep ERR /proc/interrupts?

видовс не висло.

>> Ну вот вы опять утверждаете, что железо криво на основании одного только названия функции, без каких-либо отсылок к документации - как на самом деле чипсет д/б реализован и в чем расхождения с дизайном. >А вы посмотрите код...

Вы сделали свой вывод о кривизне железа на основании просмотра кода? 8-)

> Я все это к чему говорю. К тому, что индусские биосы кривые, железо кривое, и в итоге какая система будет иметь на борту больше всего костылей-workarounds, та и сможет нормально выжить.

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

> А какие у вас проблемы, кроме сообщений об ошибках APIC, о которых винда молчит?

Ну, кроме повисаний кормпа, как справедливо заметил mv - ещё и энтропия возрастает, что немаловажно в наше время..

>> что тот, кто писал драйвер, не сильно был обременен пониманием того, что он выводит >Ну а чего плохого в том, чтобы распечатать предыдущее значение ESR и текущее? printk (KERN_DEBUG "APIC error on CPU%d: %02x(%02x)\n", smp_processor_id(), v , v1); v - состояние до v1 - текущее состояние ESR. Плохого? Ничего. Просто показательно. Нормально люди при письме обычно указывают основное значение, а в скобки выносят каку-нибудь второстепенную информацию, тут же наоборот. Да и не факт, что код ошибки - это основная информация, ибо эта строка всё равно не позволяет обнаружить источник проблемы.

> А что его оправдывать? Какие-то последствия от того, что APIC сыплет ошибки есть? Разумеется.

> Такого решения не существует. Я же ссылался на 13 тысяч страниц найденных гуглом. Будь проблема легкоразрешима - этих страниц бы просто не было бы.

Вы прочли 13 тысяч страниц и не нашли решения проблемы? (мне отчего-то кажеться, что максимум на первых 15 сылках содержиться полное решение проблемы с детальным разжёвыванием пригодным даже для полного дебила).

> ...

Я не сообираюсь преодолевать чьи-то битые ссылки.

> ...

"Линукс-сообщество" это сообщество людей, которые говоря о Линуксе способны говорить о Линуксе.

> ...

Если вам будет интесно сравнить _вашу_ ситуацию тут с реальностью, попробуйте сходить на какой-нибудь виндовый форум и бездоказательно козыряя тем какой вы профессионал в линуксе спрашивайте там у всех "какого писюна у меня аптайм винды без фаервола на выделенке не превышает 24 часа без мегатормозов, троянов и BSOD". Далее прочтите мат который вам напишут там и сравните с ответами по вашему оффтопику тут. Если в мозгу прояснится, то приходите снова и описывайте _свою_ проблему.

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

_Ваша_ первая проблема не в ОС и не в железе, а в голове.