Re: lug-bg: Slackware 10.0 SMP IRQ ��облеми

["����� ������" <whitefang@xxxxxx>]

On Tue, 3 Aug 2004 19:36:57 +0300
 George Danchev <danchev@xxxxxxxxx> wrote:
> On Tuesday 03 August 2004 18:06, Nikolay Tenev wrote:
> > Georgi Chorbadzhiyski wrote:
> > > Опитай да boot-неш със опция noapic към
> ядрото.
> >
> > Не става. Нито с noapic, нито с nolapic, нито
> и с двете заедно. Всъщност
> > когато boot-на със noapic има разлика. Във
> /proc/interrupts в колоната за
> > втория процесор (CPU1) ми показва само 0
> изключение на реда LOC: ( там
> > стойността е сходна със тази на
> полето CPU0) и в следващата колона
> вместо
> > IO-APIC-xxx пише XT-PIC. Обаче ред за eth0 няма.
> Иначе по време на
> > зареждане казва че eth0 е на IRQ 11. Този
> път вдига картата (виждам я със
> > ifconfig - ip, netmask, broadcast и т.н.) но пусна ли
> ping до gateway -
> > всичко умира по същия начин. Иначе
> сама до себе си има ping, но предполагам
> > че това е защото минава през lo.
> >
> > Също така други 2 реда ми направиха
> впечатление по време на зареждане:
> >
> > PCI: Found IRQ 11 for device 00:11.0
> > PCI: Sharing IRQ 11 with 00:07.2
> >
> > (Ако е без noapic редовете са същите но
> IRQ-то е 19)
> >
> > 00:11.0 е мрежовата карта
> > 00:07.2 USB Controler: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
> >
> > Реших да пробвам да заредя модулите
> usb-uhci или uhci. И в двата случая
> > излизаше същата грешка (Oops)
> > Като има 3 реда текст които казват:
> 
> ако искаш да поддържаш различен
> хардуер с драйвери на модули (както
> казваш в 
> предното msg), то самите модули би
> трябвало да поддържат опции за irq= , 
> io= ... и т.н. при зареждане, така, че след
> като е свършила процедурата по 
> irq routing при зареждането на ядторо и
> потребителя види какво е заето, то да 
> му се даде възможност да зададе
> други/свободни стойности.
Това не важи за PCI устройства 
> > Unable to handle kernel NULL pointer dereference at virtual address
> > 000001cb (тази стойност винаги е
> различна)
> >
> > <0> Kernel panic: Aiee, killing interrupt handler !
> > In interrupt handler - not syncing
> 
> Нищо чудно да си попаднал на smp-unsafe
> части от ядрото (драйвери)... или 
> неправилно използване на функцията
> BUG() в ядрото или просто някой
> девелопър 
> е забравил, че я извиква в някоя част
> на кода, където е дебугвал... пиши на 
> LKML ако е спешен проблема.
> 
> > А иначе под Windows и двете ( eth и usb) са
> пак на едно и също IRQ
> > (обикновенно 19) и работят ... има и
> мрежа, и usb клавиатура работи
> 
> това според мен, не е feature, а bug и ще се
> прояви съвсем случайно и без 
> основание за потребителя... но не се
> види от всички де...
> 
> > И още нещо:
> > когато давам modprobe някой от usb
> модулите се появява и ред:
> > kernel BUG at /usr/src/linux-2.4.26/include/asm/spinlock.h:133!
> 
> е тука в този файл на 133-ти ред що се
> извиква BUG() след тази проверка - един 
> господ знае ... можеш да я коментираш (
> функцията BUG() де) и рекомпайл ... 
> ама незнам доколко е sane & safe просто да
> се коментира BUG() и да не се 
> предприеме нищо друго след като
> сравнението в проверката излезе
> вярно.
Извиква се защото ядрото му е компилясано
с DEBUG SPINLOCKS или нещо от сорта беше
и защото най-вероятно някъде (в interrupt
hendler-a, на USB-то или на ETH) се стига до
ситуация , която ще доведе до deadlock поради
задържан spinlock. По скоро си мисля, че проблема
е в разпознаването на прекъсването  от драйвера
на мрежовата карта. Когато има няколко устройства на
едно прекъсване ,се извикват последователно регистрираните
за това прекъсване interrupt  handlers, а когато прекъсването
не е дошло реално от мрежовата платка , то и в регистъра
за състоянието и битовете , които индицират прекъсване поради
някаква причина - RX interrupt, CRC Error и т.н , драйвера решава, че
това е фалшиво прекъсване и  там някъде ше да е проблема.
При NON SMP ядро 
spinlock()== нищо , 
spinlock_irq()==disable_irq()
така, че е съвсем нормално грешката да не се появява.

> А иначе BUG() си е фукнция на ядторо, но
> понякога се извиква неправилно или 
> прибързано в кода на ядрото от някой
> ядрени програмисти... демек
> достигнато е 
> до критична ситуация, но положението
> не се е скофтило чак до там, че да се 
> убива машината умишлено .. почти
> винаги може да се предприеме нещо за
> да не 
> се влиза в тази част от кода или ако
> все пак се влезе да се изпълни нещо 
> смислено вместо BUG() ... но програмиста
Точно в този сл. няма нищо друго смислено което
да се изпълни ще се получи deadlock - 
примерно една нишка е заела един lock и се опитва
да заеме друг lock който е зает от 2-ра нишка, а
през това време 2-рата нишка е зациклила да чака
първия lock със spinlock(lock1) и никога не освобождава втория lock2
Според теб какво смислено може да се направи в сл. осен фунциите за
заемане на locks да ти изведе събщение за бъг и да halt-ne машината,
в противен сл. никога няма да излезе от цикъла чакащ освобождаването
на lock1.
> може да не е знаел какво е то. Ask 
> LKML.
> 
В сл. функцията BUG() се извиква от някой от макросите 
дефинирани в spinlock.h
Тях точно силно се съмнявам да ги е писал някои от
"ядрените програмисти"
Ако DEBUG SPINLOCKS e включена при компилация на ядрото
се откриват точно такива SMP unsafe бъгове в драйверите , които
се дължат на неправилно използване на spinlock функциите
от самите драйвери.
> -- 
> pub 4096R/0E4BD0AB  2003-03-18  <keyserver.bu.edu ; pgp.mit.edu>
> fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 
>
============================================================================
> A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
> http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara
> Zagora
> To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
>
============================================================================

============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================