Discussion:
Katkestused Linux'i kernelis
(too old to reply)
Erkki Arus
2004-08-10 08:42:47 UTC
Permalink
Tervist!

Jaman siin katkestuste töötlusega ühes draiveris, ja mitte ei saa aru;
kui teha

local_irq_disable();
...
teen midagi muud
...
local_irq_enable();

siis kas kõik riistvaralised katkestused, mis tekivad
local_irq_disable() ja local_irq_enable() vahel, visatakse lihtsalt
minema, unustatakse ära, või siiski järjestatakse nad kuidagi ning peale
local_irq_enable() -t käivitatakse vastav katkestuse töötlusfunktsioon?

Analoogne küsimus tasklet -de kohta: kas tasklet, mis on
tasklet_schedule() abil pandud järjekorda peale seda, kui kusagil mujal
on eelnevalt väljakutsutud funktsioon spin_lock_bh(), käivitatakse peale
spin_unlock_bh() väljakutset?

Andke nüüd andeks, kui on väga rumalad küsimused, aga uurin siin kerneli
koodi ja loen dokumentatsiooni ning mitte ei saa aru.

Linux'i kerneli versiooniks on 2.4.20, arhidektuur on i386 põhine ning
süsteemis on üks ainus protsessor.
--
Lugupidamisega Erkki Arus
Jaanus Kivistik
2004-08-10 10:54:32 UTC
Permalink
Post by Erkki Arus
Tervist!
Jaman siin katkestuste töötlusega ühes draiveris, ja mitte ei saa aru;
kui teha
[...]
Post by Erkki Arus
Andke nüüd andeks, kui on väga rumalad küsimused, aga uurin siin kerneli
koodi ja loen dokumentatsiooni ning mitte ei saa aru.
Ei oska küll lambist antud probleemi kommentida, aga kas "Linux Device
Drivers" nimelise üllitise otsa oled sattunud? Seal tundus küll kõik vajalik
olemas olevat, vabalt downloaditav http://www.xml.com/ldd/chapter/book/
pealt.

Jaanus
Erkki Arus
2004-08-10 12:23:23 UTC
Permalink
Post by Jaanus Kivistik
Ei oska küll lambist antud probleemi kommentida, aga kas "Linux Device
Drivers" nimelise üllitise otsa oled sattunud? Seal tundus küll kõik vajalik
olemas olevat, vabalt downloaditav http://www.xml.com/ldd/chapter/book/
pealt.
Jah, olen lugenud, aga paraku ei selgust ei saanud. Kas ei olnudki
öeldud või siis lugesin kehvasti.
--
Lugupidamisega Erkki Arus
Meelis Roos
2004-08-10 12:33:32 UTC
Permalink
EA> siis kas kõik riistvaralised katkestused, mis tekivad
EA> local_irq_disable() ja local_irq_enable() vahel, visatakse lihtsalt
EA> minema, unustatakse ära, või siiski järjestatakse nad kuidagi ning peale
EA> local_irq_enable() -t käivitatakse vastav katkestuse töötlusfunktsioon?

Kuna katkestused keelatakse riistvara tasemel, siis sõltub see
konkreetse arhitektuuri katkestuste riistvarast. Üldiselt peab
katkestuste kontroller (PIC, APIC x86 puhul) meeles, et seade tõmbas
katkestust, ja kui protsessor katkestused uuesti lubab, teatab
katkestusest protsessorile ka. Nii et järjekorda pole, peetakse meeles,
et see katkestus on ootel.

Lisaks on veel edge-triggered ja level-triggered katkestused, aga need
ei tohiks siia puutuda, kuna nende vahe tuleb välja katkestuse vastu
võtmisest teatamisel. Edge-triggered katkestused võivad kaotsi minna,
kui uus katkestus tuleb pärast eelmise katkestuse töötlemist, aga
vahetult enne ACK-i saatmist. Level-triggered katkestustega seda
probleemi pole.
--
Meelis Roos
Erkki Arus
2004-08-11 06:58:19 UTC
Permalink
Post by Meelis Roos
Lisaks on veel edge-triggered ja level-triggered katkestused, aga need
ei tohiks siia puutuda, kuna nende vahe tuleb välja katkestuse vastu
võtmisest teatamisel. Edge-triggered katkestused võivad kaotsi minna,
kui uus katkestus tuleb pärast eelmise katkestuse töötlemist, aga
vahetult enne ACK-i saatmist. Level-triggered katkestustega seda
probleemi pole.
Edge-triggered katkestustega ei hakanud üldse tööle - PIC lihtsalt ei
suvatse reageerida 166 ns pikusele impulsile, kuigi vaikimisi peaks ta
olema häälestatud just nimelt edge-triggered tüüpi katkestustele reageerima.

Mis ACK -desse puutub, siis vaadates kerneli do_IRQ() funktsiooni,
nähtub, et ACK saadetakse koheselt ja veel enne, kui vastav
katkestustöötlus programm üldse käivitatakse. Kommentaar sealjuures oli
selline:

We ack quickly, we don't want the irq controller
thinking we're snobs just because some other CPU has
disabled global interrupts (we have already done the
INT_ACK cycles, it's too late to try to pretend to the
controller that we aren't taking the interrupt).

Üldiselt suudab mu seade aegajalt genereerida katkestuse nii, et draiver
ei saa sellest midagi teada. Seoses sellega ei võeta seda seadmelt maha
ja järgmist katkestust enam ei tule, sest seade arvab, et esimene on kas
töötlusel või üldse töötlemata. Tegin siin väikeseid katseid ja paistab,
et mingi lahendus probleemile on panna "watchdog", mis käib ja vaatab,
ega vahepeal midagi juhtunud pole. "Geniaalne lahendus" tiitlile see
ilmselt nüüd ei pretendeeri, kuid midagi siiski. Süsteemi jõudlus
igatahes oluliselt ei kannatanud.
--
Lugupidamisega Erkki Arus
V
2023-05-13 13:08:33 UTC
Permalink
⠀⠀⠀⠀⠀New place has been opened for chat⠀⠀⠀⠀⠀⠀¯\_(ツ)_/¯⠀⠀⠀😎⠀⠀⠀⠀⠀:⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀americasnumberonechatplace.000webhostapp.com⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀
Post by Erkki Arus
Tervist!
Jaman siin katkestuste töötlusega ühes draiveris, ja mitte ei saa aru;
kui teha
local_irq_disable();
...
teen midagi muud
...
local_irq_enable();
siis kas kõik riistvaralised katkestused, mis tekivad
local_irq_disable() ja local_irq_enable() vahel, visatakse lihtsalt
minema, unustatakse ära, või siiski järjestatakse nad kuidagi ning peale
local_irq_enable() -t käivitatakse vastav katkestuse töötlusfunktsioon?
Analoogne küsimus tasklet -de kohta: kas tasklet, mis on
tasklet_schedule() abil pandud järjekorda peale seda, kui kusagil mujal
on eelnevalt väljakutsutud funktsioon spin_lock_bh(), käivitatakse peale
spin_unlock_bh() väljakutset?
Andke nüüd andeks, kui on väga rumalad küsimused, aga uurin siin kerneli
koodi ja loen dokumentatsiooni ning mitte ei saa aru.
Linux'i kerneli versiooniks on 2.4.20, arhidektuur on i386 põhine ning
süsteemis on üks ainus protsessor.
--
Lugupidamisega E
Loading...