Autor: Maciej W. Rozycki (macro_at_amg.gda.pl)
Data: Mon 24 Nov 1997 - 16:16:17 MET
On 23 Nov 1997, Andrzej Karpinski wrote:
> No tak, ale zapytam po raz 100tny, co bedzie, jesli zapatchujemy system i
> procesor nie bedzie sie zawieszal tylko poprawnie obsluzy blad? Czyli
> obejdziemy blad na drodze softwareowej powodujac, ze bedzie on bez zadnego
> znaczenia?
Widzisz, ta konkretna lata powoduje nieprzyjemne skutki uboczne:
-- klopoty z programami uruchomieniowymi w zwiazku z faktem, ze wyjatek nr
1 moze byc zarowno niepowodzeniem, jak i potrzaskiem (co prawda mozna
dokonac "recznie" dekodowania zrodla wyjatku, poprzez analize zawartosci
rejestrow DRx, ale wszystkich sytuacji sie niestety nie da rozwiazac),
-- niemoznosc odroznienia NMI od INT 2,
-- klopot z INT 3 (wersja jednobajtowa jest inaczej traktowana przez
procesor w sensie poziomu uprzywilejowania).
Wszystko to powoduje inne od zalozonego dzialanie procesora i/lub
nadmierna zlozonosc laty (mozliwosc bledow trudnych do uchwycenia).
Tym razem jednak, Intel mial niewiarygodne szczescie, gdyz jak sie
okazuje, przy wystapieniu rzeczonego bledu, procesor usiluje dokonac
-zapisu- do IDT. W zwiazku z tym, nie ma koniecznosci zaznaczania strony
sawierajacej poczatek IDT, jako nieobecnej. Wystarczy zabezpieczyc ja
przed zapisem, a wyjatek #PF bledu strony dla obszaru IDT bedzie zglaszany
tylko i wylacznie w kontekscie feralnego rozkazu "LOCK CMPXCHG8B reg". Co
implikuje, ze nie ma koniecznosci dekodowania przyczyny wyjatku.
Jesli chodzi o Linuxa, to lata bedzie umieszczona w 2.0.33.
Pozdrawiam.
-- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro_at_ds2.pg.gda.pl, PGP key available +
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 16:34:08 MET DST