Community > ReactOS Newsletter Archive > ReactOS Newsletter: Biuletyn 70

Biuletyn 70

by Z98 on 2010-03-31
translated by Haos on 2010-04-03

Problemy z UniATA

UniATA w dalszym ciągu stanowi twardy orzech do zgryzienia, szczególnie dla testerów, próbujących przebrnąć przez pierwszy etap instalacji na VirtualBox. Jak wspominaliśmy w poprzednich wydaniach, UNIATA ma o wiele krótsze opóźnienia w porównaniu do poprzedniego sterownika ATA. VirtualBox, szczególnie na starszym sprzęcie ma tendencję do odrzucania wirtualnego CD-ROM-u, tylko dlatego, że ten nie odpowiada wystarczająco szybko. Wywołuje to błąd systemu, mimo, że w rzeczywistości nic złego czy tym bardziej krytycznego się nie stało. Możliwym rozwiązaniem byłby powrót do starych ustawień, lecz takie podejście nie uzyskało akceptacji deweloperów. Szansę na akceptację ma natomiast rozwiązanie kompromisowe, polegające na ustaleniu takich wartości opóźnień, by rozwiązać problem bez nadmiernej utraty wydajności.

Kolejnym problemem jest występujący na VirtualBox i sprzęcie błąd 0x7b, pojawiający się na początku pierwszego etapu instalacji, gdy CD-ROM ustawiony jest jako Slave na którymkolwiek z kanałów. Zaraportowany niezależnie przez Carlo Bramixa i Olafa Siejkę, potwierdzony został później przez Gabriela na maszynie wirtualnej. Olaf rozpoczął analizę tego błędu od testów regresji. Ustalił, że na jego maszynie wywołała go rewizja nr. 45320 - poważna zmiana w HAL. Niestety, Gabriel nie mógł potwierdzić tego na VirtualBox-ie. Po osobnych testach obaj doszli do wniosku, iż na maszynie wirtualnej błąd pojawił się o wiele wcześniej, wraz z przejściem na UNIATA. Mimo łudząco podobnych, a właściwie niemal identycznych objawów, jedynym możliwym wyjaśnieniem tej rozbieżności, było uznanie dwóch osobnych błędów o tych samych objawach. W międzyczasie, Daniel Reimer, przygotowujący się wraz z Colinem na CLD, potwierdził ustalenia Olafa. Aleksiej Bragin wkrótce naprawił zresztą błąd z VirtualBoxa, na laptopie Daniela i stacjonarnym PC Olafa sytuacja nie zmieniła się. Teoria o dwóch różnych błędach z identycznymi objawami stała się faktem. Olaf przy wydatnej pomocy Aleksieja rozpoczął zbieranie informacji. Już na samym początku odkrył, że włączenie debugowania w UNIATA jednocześnie likwidowało sam problem. Debugowanie, a konkretnie jego efekt, czyli duża ilość drukowanych komunikatów w istotny sposób spowalnia tempo wykonywania funkcji w których zostało włączone. Rozsądek podpowiadał iż problem po raz kolejny dotyczy opóźnień.

Kolejny krok Olafa wymagał dużo czasu i jeszcze więcej cierpliwości. Rozpoczął on od dodania na początku każdej funkcji instrukcji zwracającej jej nazwę. Liczył, iż uda mu się ustalić ciąg wywołań i określić z przybliżeniem, lokalizację błędu. Ku jego zdziwieniu, podobnie jak w przypadku debugowania, błąd nie chciał się ujawnić. Metodą zbliżoną do testów regresji rozpoczął usuwanie instrukcji, sprawdzając za każdym razem czy błąd się pojawi. Każda próba z kolei, prócz rekompilacji, wymagała wypalenia pliku iso na płytę a także dokładnego dokumentowania listy funkcji sprawdzonych i oczekujących na sprawdzenie. Efektem było znalezienie trzech funkcji, w których umieszczenie jakiejkolwiek instrukcji zwracającej (DPRINT, DbgPrint, PrintF) sprawiało, że błąd znikał. Wszystkie trzy związane były z przerwaniami sprzętowymi. Przypadkowo, Olaf odkrył również, ze istnieją trzy funkcje w scsiport o podobnej własności. Niestety, uruchomienie debugowania w UNIATA z pominięciem trzech wykrytych funkcji nadal nie pozwalało odtworzyć błędu. Trzeba przyjąć, że problem jest rozleglejszy, jako że niektóre instrukcje zwracające tekst w pozostałych funkcjach UNIATA również mają wpływ na ten problem. Jest ich jednak kilkaset, a testy regresji takiej ilości instrukcji robią z tego zajęcie iście syzyfowe. Z całą pewnością udało się dowieść iż problem tkwi w zmianach HAL PIC (programowanego kontrolera przerwań). Jest to jednak moduł niezwykle wrażliwy na manipulacje, a naprawa tego błędu bez dalszych badań będzie niezwykle trudna.

PnP and ACPI

Plug and Play jest modułem, umożliwiającym systemowi operacyjnemu wykrycie nowozainstalowanego sprzętu. Gdy instalujesz na przykład nową kartę dźwiękową, system odkrywa ten fakt właśnie dzięki PnP. Alternatywą jest ręczna konfiguracja sprzętu w systemie, zadanie niełatwe i niezbyt przyjemne. Moduł PnP w ReactOS daleki jest od ideału, w części niekompletny a w pozostałych często prowizorycznie poskładany, tak by skompensować brak co istotniejszych elementów. Jednym z braków związany był z nieraportowaniem przez Freeloader (bootloader ReactOS) wykrytych przezeń urządzeń do Menedżera PnP. W rezultacie system nie mógł poprawnie zainicjalizować sterowników do tychże urządzeń, czy nawet zgłosić użytkownikowi ich braku. Cameron uzupełnił tę funkcjonalność, przy okazji naprawiając powiązane błędy w deskryptorach urządzeń, zarządzanych teraz przez PnP.

W trakcie wymienionych wyżej prac, Cameron natrafił na problem, gdy jego komputer był niepoprawnie identyfikowany jako niewspierający ACPI. Advanced Configuration and Power Interface odpowiedzialny jest za zarządzanie energią oraz powiązanymi urządzeniami (jak chociażby baterie). Poziom wsparcia ACPI przez ReactOS wahał się do tej pory między rachitycznym a nieistniejącym, w zależności od warstwy systemu na którą by zwrócić uwagę. Menedżer PnP na przykład nie obsługiwał wszystkich urządzeń, raportowanych doń przez Freeloader. Ten ma za zadanie przesłanie do PnP listy urządzeń z Rejestru a Menedżer PnP ma taką listę odczytać i uzupełnić dla tych urządzeń wpisy w Rejestrze. Konwersja danych pomiędzy nimi wymagała poprawnej listy identyfikatorów, zapisanej w kodzie. Na nieszczęście, w kodzie Menedżera PnP niektórych identyfikatorów brakowało, w związku z czym odpowiadające im urządzenia nie były poprawnie rejestrowane. W rezultacie system nie był w stanie załadować przeznaczonych im sterowników. Prócz tego klucz Rejestru odpowiadający sterownikowi ACPI był oznaczony flagą volatile, przez co sterownik ten był instalowany przy każdym uruchomieniu systemu. Cameron naprawił oba błędy, lecz zaraz potem utknął w bardzo problematycznym i jeszcze starszym fragmencie kodu na niskim poziomie systemu. Z tego właśnie powodu wiele osób miało problem z niedziałającą myszką w drugim etapie instalacji. Zgodnie z rekomendacją ekipy ReactOS ARM, ACPI zostało wyłączone do czasu uzupełnienia kodu HAL o wsparcie dla tego modułu.

DVB-T

Standard Digital Video Broadcasting-Terrestrial jest jednym z popularniejszych formatów nadawania telewizji cyfrowej. Używany jest w Europie, Rosji, Grenlandii, Australii, południowej Azji i części Afryki a także kilku innych krajach świata. Komputery z cyfrowymi Tunerami TV są w stanie odbierać i wyświetlać programy, o ile system operacyjny będzie poprawnie przeprowadzać dekodowanie strumienia. Johannes Anderwald zdecydował się na małe urozmaicenie w pracy nad stosem dźwięku i zajął się dodaniem wsparcia w ReactOS dla tej technologii. Niezbędne stało się zaimplementowanie stosu, sięgającego od aplikacji użytkownika po sterowniki w trybie kernela. Do wymaganych modułów kernela zaliczyć trzeba ks.sys (Kernel Streaming, znany już z prac nad stosem dźwięku) jak i bdasup.sys, będący standardowym sterownikiem dla Tunerów TV. W trybie użytkownika brakowało ksproxy - biblioteki odpowiedzialnej za komunikację ze stosem w trybie kernela, licznych filtrów DirectShow, jak i bibliotek msdvbnp i bdaplgin. Dzięki filtrom system może dostroić się do konkretnego kanału i przesyłać strumienie dźwięku i obrazu do odpowiednich modułów systemu. Użytkownik potrzebuje jeszcze odpowiedniej aplikacji do odkodowania samego strumienia w celu jego odtworzenia, ale znalezienie takowej nie powinno już sprawić nikomu problemu. Podobnie jak w przypadku prac nad stosem dźwięku, Johannes testuje swój kod w Windows XP, zastępując rejestracje COM tak by podpiąć swój stos na miejsce oryginalnego. Testując komponenty trybu kernela, używa oryginalnych filtrów DirectShow, tak by ograniczyć źródła błędów możliwie tylko do testowanego kodu. Uzyskany efekt jest zdumiewający, biorąc pod uwagę krótki czas trwania prac. Johannesowi z pewnością przydałaby się pomoc, w postaci osób z odpowiednim sprzętem, gotowych testować jego kod i przysyłać logi z debugowania.