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

> один дистр из сотни это все-таки мало, согласитесь.

Ну да, один дистр из одного -- это намного больше, согласитесь.

> Глючный люлипс сосед.

К лобопеду быдла.

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

>Старый пень под 2.6.20 тоже есть, кстати. Сидит себе тихо, никаких ошибок не сыплет.. Что теперь, делать вывод, что Линукс - это ОС для старых пней?

скорее для продукции от intel, это будет более правильным.

p.s. noapic irqpoll noirqdebug - страшное заклинание, которое, скорее всего поможет начать жить. но не факт, что хорошо.

У вас видимо чипсет от NVidia
Набpеите noapic в параметрах ядра при загрузке убунты или загрузитесь в "safe mode"
после первого-же
apt-get update; apt-get dist-upgrade
это исчезнет

BTW я уже пару кадров пересадил на убунту с Windows. Один - тракдрайвер, второй спец по холодильному оборудованию. Оба довольны
Надеюсь и у вас всё получится :)

> У вас видимо чипсет от NVidia

Нет, не NVidia

> Набpеите noapic в параметрах ядра

См.Выше

> после первого-же apt-get update; apt-get dist-upgrade

У меня демон проверяет апдейты ежедневно

> noapic irqpoll noirqdebug - страшное заклинание, которое, скорее всего поможет начать жить

noirqdebug - т.е. кернел просто не будет сообщать о необрабатываемых прерываниях?

> 3. Читай man lilo.conf или что у тебя там, советчики сидят по другую сторону монитора и просто не могут знать, что у тя не работает, но опять дам совет - все-таки попробуй acpi=off

Угу, на лэптопе. Это самоубийство.

У меня тоже есть такие ошибки:

# dmesg | grep error
[40603.154000] APIC error on CPU0: 00(40)
[40603.180000] APIC error on CPU1: 00(40)

При этом других проблем не вижу.

где было сказано про лэптоп?

> Не покупайте ATI чипсеты для Linux!

Неправильным чипсетом ты, товарищ, идёшь не в ногу с линугз-сообществом.

Обращайся лично к товарищу Торвальдсу с просьбой указать тот единственно правильный чипсет который на современном этапе развития линугза является истинным ТруЪ!

Ударим тысячами багов в кернеле по бурзуазной AMDвщине, которая ловко маскируя гнусное проприетарное рыло под видом напускного стремления к раскрытию стандартов, настойчиво пытается внедриться в наши ряды и уничтожить линугз-сообщество изнутри! Как бы ни был хитёр и коварен производитель, против багов линугза не выстоит никакое железо!

> где было сказано про лэптоп?

А у вас к лэптопу претензии?

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

Скорее всего кривой биос. Если так, то к багам самого Линукса отношения не имеет. Вырубай APIC в биосе или в параметрах загрузки ядра. примерно так: http://support.novell.com/techcenter/sdb/en/2002/10/81_acpi.html

Попробуй перепрошить биос, если сможешь потом правильно выставить в нём настройки.

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

А что это вобще за ошибка? Дистр/железо какое? Тут не шаманы якутские собираются и какая _у_тебя_ проблема без описания ошибки вобще сложно, как можно понять если мыслить логически мозгом.

> но опять дам совет - все-таки попробуй acpi=off

> Хорошо, я попробую.

Аминь.

> Только это не решение проблемы, а workaround. Однако в результате заранее сомневаюсь: ACPI существует давно и с чего бы это линукс начал вдруг с ним глючить - неочевидно.

А что надо делать вместо workaround-ов, если производители железе выпускают глючное железо и тестируют на нём только винду и исправляют только баги вылезающие под виндой? И глючное оно даже не смотря на то, что ACPI существует уже без малого 7 лет.

> неча на железо пенять - если оно в принципе способно работать, то всё остальное уже зависит от способа его использования софтом.

Вспоминаю истерические вопли идиотов, которые кричали, что MS-HTML - стандарт де-факто и все обязаны делать так, как для IE с багами и через жопу.

Если вы также считаете, то я склонен присоединится к тем, кто не советовал бы вам переходить на что-либо кроме MS-DOS 5.0.

> Скорее всего кривой биос. Если так, то к багам самого Линукса отношения не имеет. Вырубай APIC в биосе или в параметрах загрузки ядра. примерно так:

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

> Попробуй перепрошить биос, если сможешь потом правильно выставить в нём настройки.

Повторюсь - версия биоса - самая свежая и предлагаемых производителем, версии софта - самые свежие из предложенных репозиториями.

> зы. Вобще если хочешь чтобы тебе помогли с проблемой не пиши как ты любишь винду потому что большинству народа насрать на то как ты её любишь.

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

> А кому не насрать, тому больше бы понравилось, если бы ты сидел под быдловиндой.

Я уж сам разберусь под чем мне сидеть :-)

> Лучше напиши чего ты делал при загрузке,

Сидел смотрел на ровные ряды бегущих по экрану букв и пил кофий.

> какой дистрибутив устанавливал,

Kubuntu Feisty

> какие параметры загрузки ядра,

default

> какое железо, http://www.linux.org.ru/jump-message.jsp?msgid=2140391&cid=2141933

> какие ошибки возникли при загрузке до выдачи ошибок APIC http://www.linux.org.ru/view-message.jsp?msgid=2140391&page=1

> и вобще информативнее описывай _свои_ проблемы. А нафиг? Тому кто встречался с такой бедой и поборол её - описано подробнее, чем необходимо. А тот, кто такой проблемы не фиксил - тот ничего полезного не посоветует.

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

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

>> зы. Вобще если хочешь чтобы тебе помогли с проблемой не пиши как ты любишь винду потому что большинству народа насрать на то как ты её любишь.

>Нелогично. Если народу насрать, то какая разница - писать или не писать

Это в том смысле, что разъярённая толпа линаксоидов забросает тебя камнями за сравнение линакса с другими ОС не в пользу линакса. И ей будет насрать на то что ты там любишь.

Пестуй к себе на венду, быдлище, у нас в GNU/Linux всё работает, в отличие от тебя, криварукого уйобисча.

> Статья за 2002й год - нешто ничего не изменилось с тех пор?

Спрашивай у производителей железа.

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

Значит в генту был включён патч от этих багов, а в то, что ты ставил сейчас небыл. Или ты предлагаешь все патчи багов железа хранить в ядре?

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

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

> Я уж сам разберусь под чем мне сидеть :-) Ну ты видимо уже разобрался. К чему тогда весь твой флуд?

>> Лучше напиши чего ты делал при загрузке,>Сидел смотрел на ровные ряды бегущих по экрану букв и пил кофий.>> какой дистрибутив устанавливал,>Kubuntu Feisty>> какие параметры загрузки ядра, default>> какое железо, >http://www.linux.org.ru/jump-message.jsp?msgid=2140391&cid=2141933>>; какие ошибки возникли при загрузке до выдачи ошибок APIC >http://www.linux.org.ru/view-message.jsp?msgid=2140391&page=1

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

Во-первых, на сайте самого MSI нету мат. плат MS-7184. Во-вторых, полное название дистрибутива написать видимо выше тебя (полное название iso с дистрибутивом). В-третьих, попробовал ли ты менять параметры загрузки или по статье 2002 года у тебя это не получится?

> Я что-то ни разу не встречал подобных заявлений со ссылками на конкретные факты. Меня бы устроило заявление вида: производитель такой-то таким-то образом нарушил стандарт производства железа, что выражается в том-то и том-то и по этому линукс в принципе не может работать с такой железкой, в то время как виндовс может. Со ссылками на источники, разумеется.

acpi.sourceforge.net - пожалуйста заходи качай патч и копай его на предмет того какие баги железа он обходит. Лично я - не информ бюро.

> Пестуй > криварукого уйобисча

К логопеду, быдло!

>> и вобще информативнее описывай _свои_ проблемы.

> А нафиг? Тому кто встречался с такой бедой и поборол её - описано подробнее, чем необходимо. А тот, кто такой проблемы не фиксил - тот ничего полезного не посоветует.

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

Очень интересно, а что представляет сегодня это "линукс-сообщество"? Читая ЛОР, я. иногда с ужасом наблюдаю некоторых особей этой популяции.

Moin, я для удобства объединил всех три ваших поста.

> Спрашивай у производителей железа. > acpi.sourceforge.net - пожалуйста заходи качай патч и копай его на предмет того какие баги железа он обходит. Лично я - не информ бюро.

Если бы вы удосужились прочитать то, что написано по адресу, на который вы меня послали, то вы бы не могли не обратить внимания, что данный проект посвящен идее заставить Линукс работать устойчиво на платформах с поддержкой ACPI: "The Linux/ACPI project is focused on making Linux run well on all ACPI-enabled platforms.", т.е. о багах железа, и тем более патчах к нему, речи не идет. Речь идет о том, что линукс почему-то не может работать well на ACPI-enabled platforms. Само существование этого проекта говорит о наличии подобной проблемы у линукса. Кроме того, речь идет об интеловской имплементации, так что, видимо, в моем случае ссылка бесполезна.

> Значит в генту был включён патч от этих багов, а в то, что ты ставил сейчас небыл. Или ты предлагаешь все патчи багов железа хранить в ядре?

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

>Кому-то насрать, а кому-то нет. И вполне возможно среди тех, кому не насрать есть люди которые знают решение именно твоей проблеммы в два клика.

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

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

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

>> Я уж сам разберусь под чем мне сидеть :-) >Ну ты видимо уже разобрался. К чему тогда весь твой флуд?

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

> Судя по твоим словам вроде "есть мнение" и битым ссылкам ты видимо думаешь,

Обозначьте логическую связь более четко, а то я её не вижу.

> что эта тема тут именно про твои баги и людям больше нечего делать,

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

> кроме как разбираться в том "что же НИКТО имелл ввиду" читая попутно, как винда "на лету" справилась со всеми багами своими багами.

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

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

Гугл. Идите и считайте сколько линуксоидов имеет эту проблему.

> Во-первых, на сайте самого MSI нету мат. плат MS-7184.

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

>Во-вторых, полное название дистрибутива написать видимо выше тебя (полное название iso с дистрибутивом).

вывод uname -a приводился выше. Всё-таки ниасилил ссылку-то? Хех..

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

Тред ты не читал.

> А нафиг ты такой умный вобще в линукс-сообществе нужен, если ты даже о _своих_ проблемах не можешь толком рассказать?

На конкретно сформулированные вопросы ответы были даны.

> При этом упорно ломишься доказывать всем, что де они то о твоей проблеме не знают - "потому что сами её не решали". Интересно только если следовать твоей логике, то как сыновья матерей-одиночек научились ссать стоя, ведь эту проблему они не фиксили сами.

А эти ваши домыслы как раз очень легко проверить. Спорим не найдется такого сына матери-одиночки, который сможет объяснить что означает сообщение "APIC error on CPU0" в логах? Хотя бы объяснить, тем более, что я не просил решать мне эту проблему, изначальный вопрос был - что это означает.

P.S. Кстати да, а что вы имеете в виду, когда пишете: "линукс-сообщество"?

> Я что-то ни разу не встречал подобных заявлений со ссылками на конкретные факты.

Смотри: http://lkml.org/lkml/2005/9/28/323

> Меня бы устроило заявление вида: производитель такой-то таким-то образом нарушил стандарт производства железа

Производитель Intel(!) в некоторых моделях Pentium 4 Prescott нарушил стандарт производства железа и в поле "число физических бит адреса" показывает 40, при реальных 36, что приводило к сильным глюкам в Linux на ядрах 2.6.12-2.6.14, при отсутсвии проблем в винде, которая настраивает тип кеширования WC для региона памяти иначе, чем это делает Linux.

$ ./cpuid
CPU Identification CPUID(1)=0x00000f33
Max CPUID level supported: 0x80000008
Getting extended features supported via CPUID with EAX=0x80000001..
Checking for Intel EM64T technology.. not supported
Getting address line info via CPUID with EAX=0x80000008.. OK
CPUID returned: EAX=0x00002028
- Physical Address Bits(EAX:0-7): 40
- Virtual Address Bits(EAX:8-15): 32

А вот патч:

diff -puN arch/i386/kernel/cpu/mtrr/main.c~cpuid_errta arch/i386/kernel/cpu/mtrr/main.c
--- linux-2.6.14-rc2/arch/i386/kernel/cpu/mtrr/main.c~cpuid_errta 2005-09-29 08:35:34.000000000 +0800
+++ linux-2.6.14-rc2-root/arch/i386/kernel/cpu/mtrr/main.c 2005-09-29 08:37:16.000000000 +0800
@@ -626,6 +626,14 @@ void __init mtrr_bp_init(void)
if (cpuid_eax(0x80000000) >= 0x80000008) {
u32 phys_addr;
phys_addr = cpuid_eax(0x80000008) & 0xff;
+ /* CPUID workaround for Intel 0F33/0F34 CPU */
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
+ boot_cpu_data.x86 == 0xF &&
+ boot_cpu_data.x86_model == 0x3 &&
+ (boot_cpu_data.x86_mask == 0x3 ||
+ boot_cpu_data.x86_mask == 0x4))
+ phys_addr = 36;
+

>Производитель Intel(!) в некоторых моделях Pentium 4 Prescott нарушил стандарт производства железа и в поле "число физических бит адреса" показывает 40, при реальных 36, что приводило к сильным глюкам в Linux на ядрах 2.6.12-2.6.14, при отсутсвии проблем в винде, которая настраивает тип кеширования WC для региона памяти иначе, чем это делает Linux.

Мальчик, сними розовые очки. Intel уже сто лет назад подписал кабальную грамоту у Microsoft, что будет поддерживать платформу Windows как основу своего бизнеса. Даже уже процессоры делают под нужды программистов Microsoft.

>Спорим не найдется такого сына матери-одиночки, который сможет объяснить что означает сообщение "APIC error on CPU0: 40(40" в логах?

спорим. объясняю: 40=32+8=2^5+2^3, т.е.: Receive accept error Send illegal vector

почитать багзиллу ядра или исходники религия не позволяет, да?

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

Например, что винда не использует APIC.

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

То, что ты не знаешь решения, еще не означает, что его нет. Когда у меня были проблемы из-за глючного интелловского камня, который показывал 40 вместо положенных 36, что затрагивало Linux, а не винду, я не ныл что в инете столько много ниасиливших разобраться в чем дело, а пошел и разобрался и начал долбить саппорт. Могу назвать не один десяток примеров, когда винда падала в синий экран, зависала из-за конфликта прерываний и дохла при отключении APIC в то время как Linux нормально работал и десятки случаев когда винда падала в BSOD из-за кривых драйверов, а Linux говорил oops и работал дальше. Из чего также можно сделать вывод, что винда - говно.

> А эти ваши домыслы как раз очень легко проверить. Спорим не найдется такого сына матери-одиночки, который сможет объяснить что означает сообщение "APIC error on CPU0" в логах? Хотя бы объяснить, тем более, что я не просил решать мне эту проблему, изначальный вопрос был - что это означает.

Для забаненных на kernel.org чайников:

/* Here is what the APIC error bits mean:
0: Send CS error
1: Receive CS error
2: Send accept error
3: Receive accept error
4: Reserved
5: Send illegal vector
6: Received illegal vector
7: Illegal register address
*/
printk (KERN_DEBUG "APIC error on CPU%d: %02lx(%02lx)\n",
smp_processor_id(), v , v1);
irq_exit();

Итого 40h означает "Received illegal vector", например, если local APIC получен неправильный вектор прерывания под номером от 0 до 15. Свидетельствует о серьезных проблемах с шиной APIC или c неправильными ACPI/MP таблицами в BIOS-е. Решение: обновить BIOS, отключить APIC или поиграться с роуингом прерываний...

> Мальчик, сними розовые очки

Ты сам мальчик.

> Intel уже сто лет назад подписал кабальную грамоту у Microsoft, что будет поддерживать платформу Windows как основу своего бизнеса. Даже уже процессоры делают под нужды программистов Microsoft.

Ну и к чему ты это приплел, дурик?

Кстати, патч этот прислал инженер Intel, так что убейся об стену.

Ой, вы дама. Тогда извиняюсь, что я так грубо. :)

>спорим. объясняю: 40=32+8=2^5+2^3, т.е.: Receive accept error Send illegal vector >почитать багзиллу ядра или исходники религия не позволяет, да?

Вы сами-то в исходники смотрели? Ещё раз объясняю последовательность: 1. APIC error on CPU0: 00(40) Происходит однократно после рестарта системы. Этот APIC error происходит первым. 2. Впоследствии происходят серии ошибок вида: "APIC error on CPU0: 40(40)"

Теперь, раз уж вы такой спорщик, разъясните что происходит.

На мой взгляд, виноват линукс потому, что он плохо с этим апиком работает. Т.е. при инициализации ядро программирует интерапт контроллер (он же программируемый, я не путаю значение буквы "Р" в аббревиатуре, да?), т.е. объясняет для каких прерываний какому коду на каком процессоре передавать управление. Кто это апику рассказывает как не ядро? Таким образом, на те прерывания, с которыми линукс работать не умеет, вешается заглушка, которая пишет нулики в error status register. И когда это, неучтенное кернелом, прерывание происходит в первый раз, он читает код ошибки=0, всё ОК, пишет туда свой нолик и это и вызывает ваш "Receive accept error Send illegal vector". А происходит это по моим наблюдениям при интенсивном IO. И не только на моей плате, но и на оборудовании других моделей и даже других производителей. Что это за прерывание и почему игнорирование этого сигнала угрожает стабильности системы линукс, почему ядро не отрабатывает этот очевидно важный сигнал - вот вопросы на которые должен связно ответить тот, кто претендует на роль способного объяснить. А ваш нечленораздельный бред с отсылками вникуда объяснением считаться никак не может.

> А вот патч

Этот патч лечит железо или линукс? :-)

>Этот патч лечит железо или линукс? :-)

он лечит вас ...

>> Этот патч лечит железо или линукс? :-)

> он лечит вас ...

Патч-логопед?

> Например, что винда не использует APIC.

Но ведь линукс тоже можно попросить не использовать APIC - ни локальный, ни I/O APIC. Только при этом он совсем перестаёт работать. Неужели винда способна работать совсем без прерываний? :-)

> Для забаненных на kernel.org чайников: > bla-bla-bla > Итого 40h означает "Received illegal vector", например, если local APIC получен неправильный вектор прерывания под номером от 0 до 15. Свидетельствует о серьезных проблемах с шиной APIC или c неправильными ACPI/MP таблицами в BIOS-е. Решение: обновить BIOS, отключить APIC или поиграться с роуингом прерываний...

Ну вы же даже кусок сорца apic.c процитировали. Ну посмотрели бы на несколько строк выше - откуда берется это 40h. Оно устанавливается как ответ на действия линукса (в самый первый раз приходит 0) и ничего при этом не говорит о номере вектора. Это код ошибки из ESR. Можете хоть изобновляться с биосом, хоть изыграться с тем, что вы называете роутингом прерываний - неважно. В системе существует прерывание, которое в упор не воспринимается линуксом. И ни железо ни биос тут ни при чем - их задача обеспечить вызов указанного линуксом кода по данному прерыванию и они это делают исправно.

> В системе существует прерывание, которое в упор не воспринимается линуксом.

Имя, сестра, имя! Какой номер у этого упорно невоспринимаемого прерывания?

> Имя, сестра, имя! Какой номер у этого упорно невоспринимаемого прерывания?

Читай вниматочнее: "ничего при этом не говорит о номере вектора"

> Этот патч лечит железо или линукс? :-)

Этот патч позволяет обойти кривое интелловское железо.

> Только при этом он совсем перестаёт работать. Неужели винда способна работать совсем без прерываний? :-)

Открой для себя стандартный PIC! APIC - это Advanced PIC, изначально сделанный для SMP-систем.

> А происходит это по моим наблюдениям при интенсивном IO. И не только на моей плате, но и на оборудовании других моделей и даже других производителей.

А я не разу не видел нигде таких проблем, узнал о проблемах из гугля. Чипсетами SiS и ATI не увлекаюсь.

Если Linuх такой кривой, а настройки чипсета и таблицы BIOS-а - прямые, как и само железо, то как ты объяснишь вот это:

https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/84204

The errors have disappeared !!

Here are the things I tried (i had been googling for so long i guess)
...
I didn't know which model i had, PSAE0 or PSAE1
I used the BIOS UPDATE for PSAE1
http://support.toshiba-tro.de/tools/bios/tecra/a8/pta83/win/bios-330win.zip
updated the BIOS from windows.

Now i haven't received these errors yet !

> В системе существует прерывание, которое в упор не воспринимается линуксом.

Потому что BIOS, видимо, ничего не рассказало об этом прерывании в MP-таблице. dmesg|grep APIC и внимательно вкуривать откуда Linux берет настройки APIC, особое внимание обратить на идентификатор таблицы AWRDACPI(Award ACPI).

$ dmesg|grep APIC
[ 0.000000] ACPI: APIC 1FFF7100, 0068 (r1 GBT AWRDACPI 42302E31 AWRD 1010101)
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[ 0.000000] Processor #0 15:3 APIC version 20
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[ 0.000000] Processor #1 15:3 APIC version 20
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
[ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
[ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs
[ 0.000000] mapped APIC to ffffd000 (fee00000)
[ 0.000000] mapped IOAPIC to ffffc000 (fec00000)
[ 19.591601] ENABLING IO-APIC IRQs
[ 19.758527] ACPI: Using IOAPIC for interrupt routing

> Открой для себя стандартный PIC!

Что ты имел в виду когда писал это высказывание? :-)

> APIC - это Advanced PIC, изначально сделанный для SMP-систем.

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

Более того, вы-таки будете смеяться, но многопроцессорные системы, работающие под управлением линукса, так же подвержены этой проблеме. Забавно, да? Им тоже переходить на PIC?

Кстати, а с чего вы вообще взяли, что в системе живёт несколько разных контроллеров прерываний, работающих с одними и теми же прерываниями? Разъясните мне, а то я затрудняюсь представить - как и зачем это нужно :-D

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

> как ты объяснишь вот это

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

Если у тебя нет внятного объяснения данного феномена - не спамь всякой ерундой из интернета.

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

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

> Что ты имел в виду когда писал это высказывание? :-)

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

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

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

> Более того, вы-таки будете смеяться, но многопроцессорные системы, работающие под управлением линукса, так же подвержены этой проблеме. Забавно, да? Им тоже переходить на PIC?

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

> Кстати, а с чего вы вообще взяли, что в системе живёт несколько разных контроллеров прерываний, работающих с одними и теми же прерываниями? Разъясните мне, а то я затрудняюсь представить - как и зачем это нужно :-D

С того, что немного знаю про архитектуру PC, PIC и APIC. http://en.wikipedia.org/wiki/8259A http://en.wikipedia.org/wiki/APIC

> особое внимание обратить на идентификатор таблицы AWRDACPI(Award ACPI).

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

> Ваше мнение было бы для нас особенно ценно, дорогой анонимус, если бы оно сопровождалось разъяснением в чем конкретно заключается кривизна железа или БИОСа.

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