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

[George Danchev <danchev@xxxxxxxxx>]

On Friday 06 August 2004 09:29, Ангел Вълков wrote:
--cut--

такааа, оказало се е административен (компилационен) проблем за питащия и той 
си е решил проблема. Въобще не предполагах, че е превил опити да зарежда 
up-built drivers в smp kernel използващ cpu >1 на smp machine. Помислих, че 
по-вероятно е smp грижата е в неправилно тригване на BUG() отколкото в сорса 
на самите драйвери/модули. Оказва се, че така билднатите up драйвери са 
изловени от BUG(), че се опитват да правят лоши неща. Хвала на такъви 
магические функции (без капка сърказъм го казвам естествено)

> > модулите се появява и ред:
> > > 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()
> така, че е съвсем нормално грешката да не се появява.

ами да, при едно cpu няма друго такова което да се локва за да не се изпълни в 
даден момент паралелено критично коде и върху него, което да доведе до 
страшни неща. За това се наричат SMP spinlocks ;-) Така билднатите up 
drivers, вероятно са правили нещо подобно на това което описваш, но няма как 
да разберем със сигурност и можехме само да предполагаме.

> > А иначе BUG() си е фукнция на ядторо, но
> > понякога се извиква неправилно или
> > прибързано в кода на ядрото от някой
> > ядрени програмисти... демек
> > достигнато е
> > до критична ситуация, но положението
> > не се е скофтило чак до там, че да се
> > убива машината умишлено .. почти
> > винаги може да се предприеме нещо за
> > да не
> > се влиза в тази част от кода или ако
> > все пак се влезе да се изпълни нещо
> > смислено вместо BUG() ... но програмиста
>
> Точно в този сл. няма нищо друго смислено което
> да се изпълни ще се получи deadlock -
> примерно една нишка е заела един lock и се опитва
> да заеме друг lock който е зает от 2-ра нишка, а
> през това време 2-рата нишка е зациклила да чака
> първия lock със spinlock(lock1) и никога не освобождава втория lock2
> Според теб какво смислено може да се направи в сл. осен фунциите за
> заемане на locks да ти изведе събщение за бъг и да halt-ne машината,
> в противен сл. никога няма да излезе от цикъла чакащ освобождаването
> на lock1.

Ще се съглася с теб, че може да се достигне до livelock или deadlock върху SMP 
и по-добре е да се спре системата и да се намери причината, отколкото да се 
лекува симптома от движение (здрава глава -> рана -> цяр и после пак ;-). Но 
защо предположих, че BUG() се тригва прибързано, ами защото погледнах 
различните asm-<arch>/spinlock.h и забелязах, че в 2.4 само x86 използва 
BUG() ( сега видях, че на 2.6 и x86-64 я има ). Та си помислих, да не са 
прекалили с нея малко на x86, но се оказва, че не са, т.е. въведена е първо 
на x86 и сигурно ще се въвежда и за другите.

> > може да не е знаел какво е то. Ask
> > LKML.
>
> В сл. функцията BUG() се извиква от някой от макросите
> дефинирани в spinlock.h
> Тях точно силно се съмнявам да ги е писал някои от
> "ядрените програмисти"
> Ако DEBUG SPINLOCKS e включена при компилация на ядрото
> се откриват точно такива SMP unsafe бъгове в драйверите , които
> се дължат на неправилно използване на spinlock функциите
> от самите драйвери.

no objections ;-) CONFIG_DEBUG_SPINLOCK на kernel hacking / kernel debugging.

За да не отегчаваме публиката, можем да сведем всичко до наличие на симптоми 
на unsafe smp работа (BUG() от spinlock.h), причината не е в сорса на 
драйверите нито в BUG(), тя дори помогна за излавяне на неправилната 
конфигурация/компилация (и да не вкараме някой в заблуждение, BUG() не е само 
за излавяне на unsafe smp works).

-- 
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
============================================================================