Użytkownik "1634Racine" <1634@Racine.pl> napisał w wiadomości
news:5320eb4f$0$2237$65785112@news.neostrada.pl...
dzieki, zapisalem w arch. porad :)
z tym,ze u mnie poki co nie ma klopotu wejscia w udma5, to (byl?) klopot z
utrzymaniem udma. Teraz nagle spokoj. Dowiedzialem sie, ze powodem moglo
byc to, ze po rootkitowej sprawie dosyc czesto skanowalem sprawdzajaco w
sprawie rootkita, a to sa softy intensywnie odpytujace kontrolery (
_zwlaszcza_ gmer) i taka wlasnie bywa reakcja na intensywne odpytywanie -
samoistne zejscie z udma do pio.
Ha! Już wiem, o czym mówisz! Odważyłbym się stwierdzić, że winne jest nie
odpytywanie kontrolerów, choć ma znaczenie, tylko bardzo mocne obciążenie
systemu w ogóle - zauważyłem nieraz, że przy jakiejś operacji dyskowej, gdy
procesy młócą procka do czerwoności, wywołanie operacji dyskowej nie da
odpowiedzi od razu (niby nie powinno tak zadziałać, ale czasem się zdarza),
co sterownik może zinterpretować jako błąd. Bez parametru DWORD
"ResetErrorCountersOnSuccess" =1, lub gdy jest, ale =0, po sześciu błędach,
transmisja przechodzi z UDMA w PIO. Gdy =1 - jeśli wystąpił błąd, ale po nim
zadanie zakończyło się poprawnie, licznik jest zerowany i dopiero, gdy błąd
wystąpi 6 razy z rzędu (nie pod rząd - to rusycyzm), UDMA przechodzi w PIO.
Zbadam jeszcze przy okazji, czy wartość DWORD
UserMaster|SlaveDeviceTimingAllowed nie wymusza na siłę trybu UDMA, takie
mam wrażenie.
Może się z rzadka zdarzyć, że mimo wykazywania w Menedżerze Urządzeń trybu
UDMA, rzeczywistym trybem będzie PIO (niekiedy nie da się tego stwierdzić
wprost, w moim awaryjnym laptopie rwie wtedy dźwięk). Wtedy prosto -
de|reinstalacja urządzenia, wciągnięcie po restarcie i ponowne pobujanie się
z wpisaniem wartości, które podałem w poście, powinno być dobrze.
--
ACMM-033-PC-GCI-Warszawa.
Spamerstwu i "pytaczom" wstęp do skrzynki email surowo zabroniony!
To, że adres ten jest publiczny i nieodspamiony, nie oznacza, że wolno
wam tu załatwiać się, do tego jest klop, tylko go z szafą nie pomylcie!
|