Przerwania

Przerwania

  • Comments 4
  • Likes

Zdaję sobie sprawę, że do Marka Russinovicha to mi daleko, ale jeżeli brać przykład, to z najlepszych. Tak jak on spotykał swoje "case of the unexplained", tak i ja, i każdy z nas obserwuje czasem naprawdę dziwne zjawiska z pozornie dobrze znanym komputerem.

Jako Security Trusted Advisor, zostałem zaopatrzony w bardzo przyjemnego netbooka, (tak swoją drogą wyobraźcie sobie konferencję, na której uczestnicy dostają netbooki – prowadzący sesję w sumie może się spakować i wyjść, i tak nikt go nie słucha, bo każdy ma swoją zabawkę) i po obejrzeniu wynalazków zainstalowanych przez producenta stwierdziłem, że format i instalacja od nowa to jest to, czego mi trzeba. Pomijam już to, że na procesorze x64 zainstalowany był system 32bit.

Instalacja systemu nie jest specjalnie ciekawym tematem zwłaszcza, że przebiegła bez żadnych sensacji. Doinstalowałem świeże sterowniki do wszystkiego, co mi się w oczy rzuciło i komputer był gotowy do pracy.

Po jakimś czasie, jeszcze w czasie instalacji niezbędnych aplikacji, zacząłem odnosić wrażenie, że komputer jakoś wolno działa, ale jako że to netbook – dużo mu byłem w stanie wybaczyć. Szybki rzut oka na Task Manager pokazał, że procesy nie zjadają specjalnie dużo CPU, ale tryb jądra jednak coś tam sobie przetwarza. Tym bardziej zrzuciłem w myślach winę na procesor ATOM i pracowałem dalej. W procesie przygotowania nowego komputera, przychodzi taki moment, że instaluje się Process Explorer. Może nie wszyscy w domach go używają, ale znam wiele osób, które nie wyobrażają sobie bez niego komputera i ja sam jestem taką osobą. I Process Explorer pokazał moje problemy wydajnościowe już w trochę innym świetle:

snip1

Po pierwsze, zajętość procesora nie od razu była taka duża i wzrastała z czasem (obrazek powstał po kilkudziesięciu godzinach pracy systemu), po drugie, to już nie było tylko wrażenie spowolnienia pracy. System po prostu się nie nadawał do użytku. Oczywiście restart na jakiś czas pomagał, ale to żadna przyjemność.

Wypadało więc dowiedzieć się, kto jest winny.

Dla pewności (choć widać było, że przyczyna raczej nie tutaj leży) sprawdziłem wątki procesu System. Oczywiście trochę ich było, ale ich aktywność nie wykraczała poza zupełnie typowe zachowania.

snip2

Nadeszła więc pora na znalezienie odpowiedzi na pytanie, który ze sterowników obsługuje przerwania w taki sposób, że zjada mi prawie połowę mocy obliczeniowej. Dla przypomnienia dodam, że w systemie Windows wygląda to tak:

  1. Sprzęt zgłasza przerwanie
  2. W trybie jądra wywoływana jest obsługa przerwania i Microsoft grzecznie prosi, żeby nie zajęła więcej niż 10µs.
  3. Jeżeli obsługa przerwania "wie", że pracy jest więcej niż da się wykonać w zalecanym czasie, może odłożyć jej część na później, pozostawiając jej wykonanie mechanizmom DPC.

Jak widać na pierwszym obrazku, tutaj nic poważnego do DPC nie trafiało. Wszystkiemu winny był sterownik obsługujący przerwanie. Warto zwrócić uwagę, że zalecany czas obsługi to tylko zalecenie. Windows wychodzi z założenia, że obsługa przerwań (tak jak masa innych rzeczy, które robią pracujące w trybie jądra sterowniki) jest święta i skoro sterownik nie zastosował się do zalecenia dziesięciu mikrosekund, to wie lepiej i nie należy mu przerywać. Gorzej tylko, gdy pośrednio Windows zaufa w ten sposób jakiemuś mniej biegłemu programiście...

Próbując znaleźć odpowiedź na postawione wyżej pytanie "który to sterownik?", staniemy przed dwoma faktami i jak zwykle jeden ucieszy a drugi trochę mniej. Pozytywną informacją jest to, że Windows ma mechanizmy ETL dzięki którym da się wygodnie zajrzeć do tego, co robi jądro. Mniej pozytywną – że narzędzia, którymi można to zrobić nie są wbudowane w system. Trzecia wiadomość przynosi jednak pewną nadzieję, ponieważ wszystko to, co może nam być potrzebne jest wbudowane w bezpłatnie dostępny pakiet WDK.

Tak więc po zainstalowaniu WDK (co ciekawe instaluje się on domyślnie folderze WinDDK na dysku C:\ zamiast w Program Files), można było przystąpić do działania.

  • Krok pierwszy: podręcznikowe (opisane na przykład w Windows Internals) polecenie tracelog –start –f c:\mojtrace.etl –dpcisr –UsePerfCounter –b 64 – uruchamia ono rejestrowanie w pliku zdarzeń wygenerowanych przez jądro, w szczególności (dzięki zastosowaniu parametru –dpcisr) przez obsługę przerwań. Należy mieć świadomość, że tych zdarzeń może być dość dużo, więc wynikowy plik może przyrastać po kilka MB na sekundę. U mnie przez 20s nazbierało się prawie 1500000 zdarzeń, więc jako próbka do analizy powinno wystarczyć.
  • Krok drugi: zatrzymanie śledzenia poleceniem tracelog –stop
  • Krok trzeci: przerobienie pliku etl na coś bardziej sympatycznego. Polecenie tracerpt jest wbudowane w system i wpisane w postaci tracerpt c:\mojtrace.etl –report c:\raport.htm –f html wygeneruje naprawdę przyjazny w lekturze plik zawierający podsumowanie i analizę zebranych danych.

W moim przypadku, wynik był jasny:

snip3

Iastor.sys Po kolejnym poleceniu driverquery | findstr / iastor łatwo można zobaczyć, że winny jest "Intel AHCI Controller" czyli intelowskie sterowniki do kontrolera dysku twardego. U mnie w wersji 8.9.0.1023. Teoretycznie jest to ich najświeższa wersja, ale na stronach producenta daje się odnaleźć również wersja 9.6. Po szybkiej aktualizacji i niezbędnym w tym przypadku restarcie – wszystko wydaje się działać bez zarzutu.

Autor: Grzegorz Tworek [MVP]

Comments
  • 8.9 to jest gigantyczna porażka.

    Powoduje m.in. losowe wypadanie dysków z mirrorów.

    Wczoraj w nocy właśnie przeinstalowałem 8.9 na 9.6 i czekam na efekty.

    Najciekawsze jest to, że 9.6 nie są dostępne w sposób oczywisty. Gdy poszukasz sterowników dla W7 x64 to w dalszym ciągu Intel domyslnie zwraca stare 8.9.

    Polecam lekturę wątków tutaj:

    "Random drive fails with new Matrix Storage Manager 8.9"

    http://communities.intel.com/thread/5036

    Jak opiszesz tam tez swoje doświadczenia z tego postu - wielu ludziom zaoszczędzisz duuużo czasu :)

  • Nie jestem specjalistą od sterowników intela. Ale ten wyraźnie pokazał, że mi się nie podoba, więc został zastąpiony nowym i tyle. I masz rację (nie wprost to napisałem), że 9.6 trochę wygląda na schowany przed użytkownikami. No cóż. Pozostaje się cieszyć, że nowsza niż 8.9 wersja istnieje :)

  • Po wydaniu pierwszego polecenia na win7 x86 (tj. tracelog -start..) otrzymuje komunikat could not start logger: NT kernel logger, operatin status 5L, odmowa dostepu,

    Czy można coś na to poradzić? Obecnie na komputerze przerwania zabierają tyle czasu procesora, że klawiatura i touchpad nie odpowiadają, działa jedynie myszka podłączona pod USB.

    Problem nie występuje w dystrybucjach linuksa.

  • A uruchomiłeś cmd.exe jako administrator? Prawdopodobnie nie...

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment