Re: kernel: Disabling IRQ...
В Срд, 28/11/2007 в 10:03 +0300, Alexey Lobanov пишет: Hi all. Конструктивный вывод такой: Disabling IRQ - не болячка, а относительно безобидный симптом более серьёзной беды. Типа кашля при туберкулёзе. Смотрим kernel/irq/spurious.c и видим, что кашлять оно начинает, когда мимо попадает 99900 прерываний из 10. То есть дело совсем плохо. Соответственно, когда я этот кашель приглушил таблеточкой /* */ , через полчаса самый нагруженный из винчестеров отвалился от контроллера совсем, перестал детектироваться при тёплой перезагрузке. Но машина при этом хотя бы не сдохла, и факсы продолжает исправно принимать и сейчас. Ds: в морг. Так в чём же причина по вашему? Железо? Софт? Или их неудачная комбинация? Я склоняюсь к последнему. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel: Disabling IRQ...
On Tue, Nov 27, 2007 at 06:48:48PM +0200, Sergey Chumakov wrote: Live!, но увидело только 1G RAM из 2-х. Бороться с опцией mem я не стал, бо испугался встроенного видео, попробовал 2.6.18-5-amd64 - упало, заработало 2.6.18-5-686. Вот так вот. Апгрейдиться после случая потери консоли реально страшно теперь :) GRUB и LILO, таки, умеют откатываться на альтернативное ядро при повторном старте -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel: Disabling IRQ...
Alexey Lobanov пишет: Hi all. Есть старый двухпроцессорный сервер. Зависал без видимой причины он давно, поменять железо я хотел ещё в 2004 году. Но так и не поменял, уволился. После меня - тоже не поменяли :-) После апгрейда ядра с 2.4.25 на 2.6.23 стало совсем плохо. При большой нагрузке на сеть (Intel Ethernet Pro 100) или на IDE диски (карточки с CMD 648, CMD 649) через несколько минут ядро отключает прерывание нагруженного PCI устройства, примерно так: Nov 26 11:52:29 woody kernel: irq 17: nobody cared (try booting with the irqpoll option) Nov 26 11:52:29 woody kernel: Disabling IRQ #17 В данном случае это пострадал IDE-контроллер CMD-649, повод - 5 минут активного копирования с диска на диск. Далее, естественно, Nov 26 11:52:49 woody kernel: hdk: dma_timer_expiry: dma status == 0x24 - и половина дисковой подсистемы умерла. Упомянутый параметр загрузки irqpoll не меняет в поведении системы абсолютно ничего. Равно как ничего (кроме номеров прерываний) не меняют irqfixup, nosmp, noacpi. Говорить noapic не пробовал, но он вроде как входит в nosmp - SMP mode deactivated, forcing use of dummy APIC emulation. Чипсет там странный. Broadcom он же ServerWorks CNB20LE. Вопрос: что ещё можно покрутить в параметрах ядра и его загрузки для получения устойчивой работы? Можно с ущербом для производительности. Откат на старое ядро, увы, не проходит - по другим причинам. Да оно и там висло, только без диагностики. А.Л. Вообще-то если пишешь что отключает разные устройства то надо приводить все примеры. В данном случае похоже что проблемыы с DMA у контроллера HDD. Постарайся средствами BIOS или тусованием плат разнести DMA контроллер на отдельное прерывание. Вообще неплохо-бы еще сюда cat /proc/interrupts - Чтобы видно было что там у тебя творится. Oleg. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel: Disabling IRQ...
Hi, 28.11.2007 12:04, Oleg Frolkov пишет: Вообще-то если пишешь что отключает разные устройства то надо приводить все примеры. Скорее, это означает, что виноваты не устройства, а система. И перечислять примеры бестолку. В данном случае похоже что проблемыы с DMA у контроллера HDD. Постарайся средствами BIOS или тусованием плат разнести DMA контроллер на отдельное прерывание. Я же писал, что ничего (кроме номеров прерываний) не меняют irqfixup, nosmp, noacpi. А основной режим smp+apic сам всё разносит. Вообще неплохо-бы еще сюда cat /proc/interrupts - Чтобы видно было что там у тебя творится. [EMAIL PROTECTED]:~# cat /proc/interrupts CPU0 CPU1 0: 61 0 IO-APIC-edge timer 1: 4 4 IO-APIC-edge i8042 3: 44728 45264 IO-APIC-edge serial 7: 0 0 IO-APIC-edge parport0 8: 61246284 61249572 IO-APIC-fasteoi rtc 10: 40 57 IO-APIC-fasteoi ohci_hcd:usb1 12: 7265 7480 IO-APIC-edge i8042 14: 1761 1855 IO-APIC-edge ide2 16: 11443 11594 IO-APIC-fasteoi ide0 17: 1722 1670 IO-APIC-fasteoi ide4 18:110 82 IO-APIC-fasteoi serial 19: 3101 2788 IO-APIC-fasteoi eth0 31:493494 IO-APIC-fasteoi acpi NMI: 0 0 LOC: 143906 144292 ERR: 0 MIS: 0 Отваливались: irq 16 RAID bus controller: Silicon Image, Inc. SiI 0649 Ultra ATA/100 PCI to ATA Host Controller irq 17 RAID bus controller: Silicon Image, Inc. PCI0648 irq 19 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] А.Л. Oleg. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel: Disabling IRQ...
Alexey Lobanov пишет: Hi, 28.11.2007 12:04, Oleg Frolkov пишет: Вообще-то если пишешь что отключает разные устройства то надо приводить все примеры. Скорее, это означает, что виноваты не устройства, а система. И перечислять примеры бестолку. Тем не менее телепатов тут нет, диагноз можно поставить только видя как можно больше симптомов. Я же писал, что ничего (кроме номеров прерываний) не меняют irqfixup, nosmp, noacpi. Я не понял... это опции ядра или опции биоса? noapic пробовал? Не noacpi а именно noapic. А основной режим smp+apic сам всё разносит. Основной режим это что? Каким образом осуществляется переключение основной/дополнительный? Вообще неплохо-бы еще сюда cat /proc/interrupts - Чтобы видно было что там у тебя творится. [EMAIL PROTECTED]:~# cat /proc/interrupts CPU0 CPU1 0: 61 0 IO-APIC-edge timer 1: 4 4 IO-APIC-edge i8042 3: 44728 45264 IO-APIC-edge serial 7: 0 0 IO-APIC-edge parport0 8: 61246284 61249572 IO-APIC-fasteoi rtc 10: 40 57 IO-APIC-fasteoi ohci_hcd:usb1 12: 7265 7480 IO-APIC-edge i8042 14: 1761 1855 IO-APIC-edge ide2 16: 11443 11594 IO-APIC-fasteoi ide0 17: 1722 1670 IO-APIC-fasteoi ide4 18:110 82 IO-APIC-fasteoi serial 19: 3101 2788 IO-APIC-fasteoi eth0 31:493494 IO-APIC-fasteoi acpi NMI: 0 0 LOC: 143906 144292 ERR: 0 MIS: 0 Если я не туплю то 0-15 Это основной контроллер прерываний, 16 - выше это APIC. Отваливались: irq 16 RAID bus controller: Silicon Image, Inc. SiI 0649 Ultra ATA/100 PCI to ATA Host Controller irq 17 RAID bus controller: Silicon Image, Inc. PCI0648 irq 19 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] А.Л. Отваливалось все что на APIC. Возможные варианты лечения: 1. Обновить BIOS чтобы пофиксить ошибки программирования APIC. Мне помогало на многих материнках на которых ядро 2.6 вообще не грузилось без noapic. 2. Отключить apic в BIOS - тогда все должно рассаживаться в пределах 0-15 прерываний. 3. Отключить APIC при загрузке ядра Других вариантов вроде-бы нет Oleg. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel: Disabling IRQ...
Hi Иван, * Иван Лох [EMAIL PROTECTED] * 2007-11-28 11:01: On Tue, Nov 27, 2007 at 06:48:48PM +0200, Sergey Chumakov wrote: заработало 2.6.18-5-686. Вот так вот. Апгрейдиться после случая потери консоли реально страшно теперь :) GRUB и LILO, таки, умеют откатываться на альтернативное ядро при повторном старте Это если оно грузиться. В моем случае с потерей консоли старое ядро не загрузилось c новым /. -- Best regards, Sergey Chumakov 2:450/77[.43] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel: Disabling IRQ...
Hi all. 28.11.2007 15:19, Oleg Frolkov пишет: Тем не менее телепатов тут нет, Дык. Поэтому я и не рассчитываю на диагноз, а надеюсь получить свежие идеи для диагностики на месте. Это обмен опытом, а не техподдержка IBM :-) диагноз можно поставить только видя как можно больше симптомов. Точно. Основной режим это что? Каким образом осуществляется переключение основной/дополнительный? Основной, штатный режим работы ядра SMP. Если ничего не говорить ему при загрузке. Вообще неплохо-бы еще сюда cat /proc/interrupts - Чтобы видно было что там у тебя творится. [EMAIL PROTECTED]:~# cat /proc/interrupts CPU0 CPU1 0: 61 0 IO-APIC-edge timer 1: 4 4 IO-APIC-edge i8042 3: 44728 45264 IO-APIC-edge serial 7: 0 0 IO-APIC-edge parport0 8: 61246284 61249572 IO-APIC-fasteoi rtc 10: 40 57 IO-APIC-fasteoi ohci_hcd:usb1 12: 7265 7480 IO-APIC-edge i8042 14: 1761 1855 IO-APIC-edge ide2 16: 11443 11594 IO-APIC-fasteoi ide0 17: 1722 1670 IO-APIC-fasteoi ide4 18:110 82 IO-APIC-fasteoi serial 19: 3101 2788 IO-APIC-fasteoi eth0 31:493494 IO-APIC-fasteoi acpi NMI: 0 0 LOC: 143906 144292 ERR: 0 MIS: 0 Если я не туплю то 0-15 Это основной контроллер прерываний, 16 - выше это APIC. Насколько я понимаю, в SMP режиме они всё APIC. О чём прямо сказано выше. Возможные варианты лечения: 2. Отключить apic в BIOS - тогда все должно рассаживаться в пределах 0-15 прерываний. 3. Отключить APIC при загрузке ядра Дык. Тот же результат достигается nosmp в загрузке. Всё рассаживается в пределах 15, и при хорошей нагрузке на ide4, ide5 Disabled оказывался irq 12. Других вариантов вроде-бы нет Так я уже написал про вариант, который оказался конструктивным. Закомментировать вызов disable_irq в kernel/irq/spurious.c. После этого машина перестаёт хотя бы виснуть, и с ней можно разговаривать дальше. Далее, сегодня утром один из винчестеров был перенесён с карты которая irq17 на свободный IDE канал на мамке, поганый ServerWorks OSB4. И - ГЛЮКИ ПОЛНОСТЬЮ ИСЧЕЗЛИ. Возможных объяснений два. 1. Чип CMD-649 под ядром 2.6 категорически не смог работать с двумя каналами. До этого почему-то 6 лет как-то работал под 2.4... 2. Источником проблем был именно СВОБОДНЫЙ контроллер ServerWorks. В пользу этого говорит то, что при отсутствии винта ядро не присваивало этому устройству прерывания вообще (по lspci). То есть не до конца его конфигурировало (Will probe later в загрузке) - и мог гнать в шину какой-то мусор? А.Л. Oleg. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel: Disabling IRQ...
В Пнд, 26/11/2007 в 23:08 +0300, Alexey Lobanov пишет: Nov 26 11:52:29 woody kernel: irq 17: nobody cared (try booting with the irqpoll option) Nov 26 11:52:29 woody kernel: Disabling IRQ #17 Nov 26 11:52:49 woody kernel: hdk: dma_timer_expiry: dma status == 0x24 - и половина дисковой подсистемы умерла. Такая же проблема была на старой машине (Duron ~800) с NIC Intel PRO/1000 GT при большой нагрузке на сеть. На драйвер e1000 запостено куча багрепортов по этой теме, но толком решения нет. Лично я для себя сделал вывод, что причина в багонутых матерях в области работы с IRQ. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel: Disabling IRQ...
Вопрос: что ещё можно покрутить в параметрах ядра и его загрузки для получения устойчивой работы? Можно с ущербом для производительности. Откат на старое ядро, увы, не проходит - по другим причинам. Да оно и там висло, только без диагностики. Если железо неисправно, то париться с ним - пустая трата времени. А ваше время вероятно стоит больше, чем новое железо. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel: Disabling IRQ...
В Вто, 27/11/2007 в 14:19 +0300, Nikita V. Youshchenko пишет: Вопрос: что ещё можно покрутить в параметрах ядра и его загрузки для получения устойчивой работы? Можно с ущербом для производительности. Откат на старое ядро, увы, не проходит - по другим причинам. Да оно и там висло, только без диагностики. Если железо неисправно, то париться с ним - пустая трата времени. А ваше время вероятно стоит больше, чем новое железо. Дело в том, что железо исправно, так сказать. Intel'овские сетевухи заменили обычные по $8 - проблем нет. Intel'овские на другой, более современной машине работают нормально. Железо новое уже заказываем, но не по причине неисправности старого, а по причине увеличения трафика. Машина работает в качестве роутера, раньше ходил траф до 100Мбит/с, будет до 3Гбит/с. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel: Disabling IRQ...
Hi Покотиленко, * Покотиленко Костик [EMAIL PROTECTED] * 2007-11-27 15:01: Такая же проблема была на старой машине (Duron ~800) с NIC Intel PRO/1000 GT при большой нагрузке на сеть. На драйвер e1000 запостено куча багрепортов по этой теме, но толком решения нет. Лично я для себя сделал вывод, что причина в багонутых матерях в области работы с IRQ. Лет 8 у меня стоит компак 2500 2хPPro. Ядра на нем стояли с 2.0.х C включенным SMP тоже падал раз в неделю обязательно на ровном месте (без SMP работал пока питание не рубили). Полечилось это разнесением сетевых карт по разным шинам PCI (там их две, включенных через какой-то мост). Естественно своеобразный биос там с опциями по многопроцессорности, тоже были ньюансы. Сейчас etch c 2.6, я уже спрашивал - начал глючить интерфейс на tlan (ну может от старости). Был перевернут в сторону инета а его место занял ee100. С самой первой установки 2.6 я потерял консоль. т.е. она есть, но похоже на 10х80. Машине пора на списание, но все таки проблема скорее всего не в ней. Да, вместо этого компака поставил сервер на A64x2 asus mATX что-то на nForce 6100. 2.6.18-4-486 заработало только после оключения в биосе CQ и Live!, но увидело только 1G RAM из 2-х. Бороться с опцией mem я не стал, бо испугался встроенного видео, попробовал 2.6.18-5-amd64 - упало, заработало 2.6.18-5-686. Вот так вот. Апгрейдиться после случая потери консоли реально страшно теперь :) -- Best regards, Sergey Chumakov 2:450/77[.43] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel: Disabling IRQ...
Hi all. Конструктивный вывод такой: Disabling IRQ - не болячка, а относительно безобидный симптом более серьёзной беды. Типа кашля при туберкулёзе. Смотрим kernel/irq/spurious.c и видим, что кашлять оно начинает, когда мимо попадает 99900 прерываний из 10. То есть дело совсем плохо. Соответственно, когда я этот кашель приглушил таблеточкой /* */ , через полчаса самый нагруженный из винчестеров отвалился от контроллера совсем, перестал детектироваться при тёплой перезагрузке. Но машина при этом хотя бы не сдохла, и факсы продолжает исправно принимать и сейчас. Ds: в морг. А.Л. Такая же проблема была на старой машине (Duron ~800) с NIC Intel PRO/1000 GT при большой нагрузке на сеть. На драйвер e1000 запостено куча багрепортов по этой теме, но толком решения нет. Лично я для себя сделал вывод, что причина в багонутых матерях в области работы с IRQ. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
kernel: Disabling IRQ...
Hi all. Есть старый двухпроцессорный сервер. Зависал без видимой причины он давно, поменять железо я хотел ещё в 2004 году. Но так и не поменял, уволился. После меня - тоже не поменяли :-) После апгрейда ядра с 2.4.25 на 2.6.23 стало совсем плохо. При большой нагрузке на сеть (Intel Ethernet Pro 100) или на IDE диски (карточки с CMD 648, CMD 649) через несколько минут ядро отключает прерывание нагруженного PCI устройства, примерно так: Nov 26 11:52:29 woody kernel: irq 17: nobody cared (try booting with the irqpoll option) Nov 26 11:52:29 woody kernel: Disabling IRQ #17 В данном случае это пострадал IDE-контроллер CMD-649, повод - 5 минут активного копирования с диска на диск. Далее, естественно, Nov 26 11:52:49 woody kernel: hdk: dma_timer_expiry: dma status == 0x24 - и половина дисковой подсистемы умерла. Упомянутый параметр загрузки irqpoll не меняет в поведении системы абсолютно ничего. Равно как ничего (кроме номеров прерываний) не меняют irqfixup, nosmp, noacpi. Говорить noapic не пробовал, но он вроде как входит в nosmp - SMP mode deactivated, forcing use of dummy APIC emulation. Чипсет там странный. Broadcom он же ServerWorks CNB20LE. Вопрос: что ещё можно покрутить в параметрах ядра и его загрузки для получения устойчивой работы? Можно с ущербом для производительности. Откат на старое ядро, увы, не проходит - по другим причинам. Да оно и там висло, только без диагностики. А.Л. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
