Kernel Traffic #166 For 2002/05/13

Kernel Traffic właśnie zmienił swój system publikacji. W tej chwili używany jest parser XML domowej roboty, który współpracuje z bazą danych i produkuje gotowy HTML, a dalej propaguje go na różne komputery znajdujące się w naszym round-robin DNS-owym.

Nasz system wykorzystuje arkusze XSLT do przekształcenia XML do HTML oraz 'make', aby upewnić się, że jedynie właściwe pliki są przebudowane. Kiedyś system publikacji zostanie opublikowany z numerami wersji, kontrolą wydań, itd., a tymczasem możecie obejrzeć pliki pod adresem http://kt.zork.net/xslt/. Kluczowy XSLT wykorzystywany do generacji HTML do serwisu to http://kt.zork.net/xslt/kt.xsl, który odwołuje się do plików w różnych podkatalogach.

Powiem o tym więcej i udostępnię nieco dokumentacji w ciągu najbliższych tygodni. Na razie mówię tylko, że te pliki tam są, na wypadek, gdyby ktoś chciał poeksperymentować z nimi, a może nawet wysłać mi łaty, czy nowe pomysły.

Chciałem serdecznie podziękować Joergowi Heinicke i Jeni Tennison z listy dyskusyjnej XSL, którzy napisali obsługę <kcref> w http://kt.zork.net/xslt/html/misc.xsl.

There were 424 different contributors. 217 posted more than once. 143 posted last week too.

Ukazało się LTT 0.9.5.

Od czasów 0.9.4 zostało dodanych naprawdę wiele usprawnień. Oto streszczenie:

port na S/390
port na SuperH
port na MIPS
Możliwości śledzenia pomiędzy różnymi platformami
Aktualizacja obsługi RTAI
Zdarzenia z przestrzeni użytkownika (LibUserTrace)
Udostępnienie binarnego śledzenia przez bibliotekę z przestrzeni użytkownika (LibLTT)
Usprawnienia przy wizualizacji
Dynamiczne zmiany maski śledzenia
integracja z systemem budowania autoconf/autobuild

Wszystkie szczegóły na temat zmian znajdziecie w sekcji z nowościami na stronie projektu.

Ponieważ LTT istnieje już prawie 3 lata, stało się całkiem dużym kawałkiem oprogramowania. Aby umożliwić łatwe zrozumienie co LTT robi, a czego nie, dodałem opis ,,możliwości'' na głównej stronie projektu: http://www.opersys.com/LTT/index.html#features

Lista zdarzeń śledzonych przez LTT była wcześniej udokumentowana jedynie w kilku artykułach, w których prezentowałem narzędzie. Aby ułatwić dostęp, dodałem listę zdarzeń na stronie: http://www.opersys.com/LTT/trace-points.html

Jak już powiedziałem, dostępna jest łata do 2.5.x, a LTT jest gotowe do włączenia do serii 2.5.

Serwis LTT to: http://www.opersys.com/LTT

Łata spodobała się Romanowi Zippelowi, który stwierdził, że powinna trafić do głównego kodu jądra pod warunkiem przeformatowania kodu. Wskazał Karimowi Documentation/CodingStyle w źródłach jądra. Karim powiedział, że się tym zajmie, po czym wymienili jeszcze kilka wiadomości na temat różnych szczegółów.

David Macbanay zgłosił, że na jego SOYO K7VTA-B z układem VIA 82C686B oraz procesorem Duron 750MHz "gdzieś po jądrze 2.5.1 (nie mogłem skompilować żadnego jądra pomiędzy tym a 2.5.5), klient pocztowy z Evolution wiesza się zawsze, gdy próbuję otworzyć Kalendarz, Zadania czy Kontakty. Muszę przejść na inny terminal i go zabić." Pavel Machek zasugerował użycie strace, aby zobaczyć, co Evolution robi tuż przez zwisem. Dave Jones zgodził się z tym i spytał, czy to zachowanie może być powtórzone w 2.5.10; David potwierdził: "to się zdarza przy każdym jądrze pomiędzy 2.5.5 a 2.5.10. Mogło się zdarzać też wcześniej, ale, jak już mówiłem, nie byłem w stanie skompilowac żadnego jądra pomiędzy 2.5.1 a 2.5.5." Wysłał kilka ostatnich linii z wyniku strace.

W międzyczasie Tommy Faasen potwierdził problem w 2.5.8 i powiedział, że nie występuje on w jądrach 2.4. W tym momencie Miles Lane wyjaśnił:

Obserwuję ten błąd od około 2.5.5. Jest też w 2.5.10. Próbowałem uzyskać więcej użytecznych informacji na jego temat. Niestety nie udało mi się dotrzeć do niczego, co by jasno wskazywało na przyczynę.

Co to użycia strace w celu znalezienia błędu, to pamiętajcie, że Evolution używa wielu procesów, których używa do komunikacji z procesem głównym (evolution). Proces, który obsługuje większość informacji Evolution dla różnych komponentów Evolution nazywa się wombat.

Mam zamiar uruchomić ,,strace wombat'', ,,strace evolution-mail'' i ,,strace evolution-adressbook'' w różnych oknach terminala. Wtedy proces evolution może być uruchomiony normalnie.

Z moich obserwacji wynika, że problem tkwi w wombat. Jeśli ktoś z użytkowników Evolution chciałby mi pomóc, niech to zrobi!

Keith Owens spytał: "W jakim stanie są procesy, gdy to zwisa? S, R, D, N, T, jakim? Mam taki pojawiający się i znikający problem z 2.4, gdzie cała grupa procesów wchodzi do stanu T, nawet gdy nic ich nie śledzi. Zabicie brużdżącego procesu, a następnie wysłanie SIGCONT do pozostałych procesów w grupie, restartuje grupę. Brużdżącym procesem jest zazwyczaj ostatni w drzewie." Miles na to odparł: "Hmm. Sprawdziłem to w 2.5.12 (cały czas się wiesza) i po zwisie, wszystkie procesy związane z Evolution były w stanie ,,S''." Koniec wątku.

Wakko Warner zgłosił, że jego nowiutki 160G dysk jest widoczny jedynie jako 137G. Randy Dunlap odparł: "Był o tym wątek jakieś 2-3 miesiące temu. O ile dobrze pamiętam, IDE w 2.4 nie ma interfejsu do 48-bitowych adresów bloków, chociaż Andre ma na to kilka łat. To jest niezbędne, aby przejść przez granicę 137GB." Mike Fedyk wskazał, że kilka łat Andre zostało włączonych w trakcie prac nad 2.4.19-pre, a Jeff V. Merkey powiedział: "To prawda, ale niektóre karty będą wymagały aktualizacji firmware."

Gdzie indziej Jeff zasugerował Wakko, aby to zrobił, jeśli używa adaptera 3Ware albo innego kontrolera RAID. Ale Wakko odparł: "To nie jest kontroler raidowy. Komputer ma kontroler ide PIIX3 i kontroler scsi AHA-2940UW. Oba mają ten sam problem." Martin Bene odpowiedział:

Właściwie to nie: Aby w pełni używać napędów 160GB ATA, bez względu na to, jakie urządzenie jest na drugim końcu ATA, szyna musi obsługiwać 48-bitowy tryb adresowania. W tych przypadkach, o których mówisz, to oznacza

IDE: Sterownik IDE z jądra musi obsługiwać 48-bitowe adresowanie, aby mógł obsługiwać 160GB.

SCSI: firmware w Twoim adapterze IDE<->SCSI musi obsługiwać 48-bitowe adresowanie.

Więc, mimo że objawy są takie same w obu przypadkach, to przyczyny problemów leżą zupełnie gdzie indziej.

Najprawdopodobniej nie jesteś w stanie nic zrobić z firmware adaptera IDE<->SCSI; jednakże możesz coś zrobić ze sterownikiem ATA w linuksie: kod jest w drzewie 2.4.19-pre, wszedł w 2.4.19pre3.

Ville Herva spytał: "Ale które kontrolery IDE obsługują 48-bitowe adresowanie?" Vojtech Pavlik powiedział, że wszystkie, ale Andre Hedrick odrzekł, ze ma listę pojedynczych kontrolerów IDE, które nie zadziałały. Vojtech poprosił go o wysłanie tej listy na linux-kernel, ale Andre nie odpowiedział. Gdzie indziej, inne osoby również roztrząsały ten problem, ale bez żadnej konkluzji.

Połączyłem następujące łaty dla 2.4.18:

Scheduler 0(1)
Małe opóźnienia (Low Latency)
Wywłaszczalne jądro
Skompresowana pamięć podręczna
nowy podsystem IDE

Moja kompozycja jest oparta na dość świeżych łatach, ale nie wszystkie są w ostatnich wersjach.

Zauważyłem odczuwalną poprawę (odczucia przy używaniu komputera) po włączeniu ich wszystkich oprócz skompresowanej pamięci podręcznej, ale nie miałem danych aby sprawdzić wrażenia. Komputer, na którym to wypróbowałem, działa już od 3 tygodni przy dużym obciążeniu i jest bardzo stabilny. Umieściłem połączone łaty pod adresem:

http://kernel.kolivas.net

Śmiało testujcie ją i powiedzcie mi, co myślicie. Wielkie dzięki dla tych, którzy włożyli wysiłek w stworzenie poszczególnych łat.

Mark Hounschell poza listą odpowiedział, że po wykonaniu 'make mrproper oldconfig dep bzImage', jądro się nie kompiluje. Po opuszczeniu 'mrproper' wszystko jest w porządku. Con powiedział: "Hmm. Zgodnie z podręcznikową konfiguracją, wykonywałem make mrproper && make clean bez żadnych problemów." Mark odpowiedział (tym razem na liście): "Nie sądzę, aby te łaty dobrze się komponowały z O(1)."

J.A. Magallon spytał, czy sterowniki e100 i e1000 wejdą do źródeł głównego jądra. Jeff Garzik odparł:

e100 jest w 2.5.x już od jakiegoś czasu. Również wszystkie kwestie licencyjne już jakiś czas temu zostały rozwiązane.

Sądzę, że dział Q/A Intela już wkrótce da zielone światło dla nowego sterownika. Gdy dołożymy kilka łat, będzie niedługo gotowe do włączenia 2.4.x.

Możesz po prostu skopiować drivers/net/we100[0] do jądra 2.4.x, najprawdopodobniej skompilują się bez żadnych modyfikacji.

J.A. odpowiedział: "Zrobiłem tak, biorąc sterowniki z 2.5.12 i się kompilują. Muszę wypróbować to na prawdziwym komputerze, ale nie sądzę, abym natrafił na jakieś problemy, tak jak w 2.5.... Marcelo, czy jest jakaś szansa na włączenie tego w następnym -pre albo w .19?" Jeff odrzekł:

Kiedy będą odpowiednie dla Marcelo, to je do niego wyślę.

Jak już napisałem w cytowanej wiadomości, wymagają jeszcze kilku łat i jestem zainteresowany odzewem ze strony Q/A Intela (który jest zaplanowany na kiedyś w tym tygodniu).

Jeśli jesteś zainteresowany w opiece nad łatami 2.4.x przez jakiś czas, zrób to. Ale nie chcę podsyłać prawie-gotowego e100 do Marcelo i opublikować w 2.4.19 niekompletnego. Jest dostępne, jest publiczne, zostawmy to w tej postaci jeszcze przez jakiś czas.

J.A. przeprosił za niezrozumienie. Dodał: "Jeśli ktoś chce wypróbować te sterowniki, to proponuję zajrzeć do wiadomości o -jam9. To ta sama historia, potrzebowałem tego dla kilku komputerów (e1000) i wolałem mieć to wszystko w jednym drzewie niż oddzielnie, więc wziąłem te z 2.5 zamiast tych z Intela."

Wiele zmian od ostatniego tygodnia - szczególnie zauważalne to początek nowej warstwy bufora Andrew Mortona, bardzo poprawiony podsystem Bluetooth, dzięki Maximowi Krasynyansky'emu i innym.

Bliższe szczegóły tam gdzie zwykle:

http://kernelnewbies.org/status/

Nie wahajcie się mówić jeśli są jakieś niedociągnięcia lub czegoś brakuje. Miłej zabawy!

Jeff Dike podesłał parę uaktualnień do niektórych elementów listy Guillauma. Koniec wątku.

Eugene Kuznetsov zapytał, kiedy będzie obsługiwany pod Linuksem ruter AMD 760 IRQ, a Alan Cox odpowiedział: "Gdy ktoś zgłosi się na ochotnika do przetestowania. " Eugene się zgłosił i porozmawiali o różnych łatkach. Na początku Eugene zgłosił błąd, a Alan myślał, że to jego BIOS jest bardzo zepsuty. Ale wtedy Eugene'owi zaczęło się udawać. Napisał: "Bez noapic, to co było w poprzedniej wiadomości było z MP 1.1. Z MP 1.4 jądro wiesza się gdzieś w okolicach ,,calibrating APIC timer''. Wydaje się natomiast, ze działa z noapic, zarówno z 1.1, jak i z 1.4." Alan spytał: "Może to wina ASUS A7M-266D? Jeśli tak, to to losowo zależy od tego, który masz aktualnie BIOS. Znajdź taki dla którego działa i go nie dotykaj. 8)." And Eugene potwierdził: "Tak - to moja płyta główna. Mam BIOS w wersji 1004 z 12/17/2001."

UML może już teraz być uruchomiony jako zagnieżdżony sam w sobie. Działa to na UML 2.4.18-21, który jeszcze nie jest opublikowany, ale wkrótce będzie. By zdobyć krwiste szczegóły, spójrzcie na poniższy log, zobaczcie też http://user-mode-linux.sf.net/nesting.html, by wiedzieć jak to samemu zrobić.

To jest raczej znak dojrzałości UML, a nie dodanie nowej magicznej funkcjonalności. UML jest bardzo wymagającym procesem, więc chociaż używa tylko interfejsu wołań systemowych Linuksa, to przejmuje część jądra.

Brakujące fragmety to parę błędów, które wciąż próbujemy naprawić. Jak tylko się je naprawi, to będzie można już startować UML-a.

Poprawił jednak od razu numer wersji. Nie było to 2.4.18-21, tylko 2.4.18-22. Andries Brouwer był pod wrażeniem i napiał: "To przypomina mi stare dobre czasy sprzed 30 lat - mieliśmy wieżę z trzech maszyn wirtualnych działających na prawdziwym PDP 8/I. Teraz, gdy możesz już uruchomić UML-a pod UML-em, czy możesz też uruchomić UML-a pod UML-em pod UML-em?" Jeff napisał, że to powinno działać, a w innym miejscu wspomniał o interesującym projekcie, który planuje w średniej perspektywie czasowej, polegającym na rozłożeniu instancji UML z SMP na wiele maszyn. Mike'a Fedyka zaciekawiło, jakie specjalne korzyści by to przyniosło w porównaniu z czymś takim jak MOSIX, czy innymi rozwiązaniami klastrowymi. Jeff odpowiedział: "MOSIX (lub SSI Compaq-a) to oczywiście sposoby w jaki zrobiłoby się takie coś. Należałoby podzielić ,,fizyczną'' pamięć UML pomiędzy maszyny i wykorzystać to, że strony te są naprawdę wirtualne do rozrzucenia ich na poszczególne maszyny. To by działało fatalnie, ale podoba mi się prostota rozwiązania. " Lars Marowsky-Bree odparł:

To faktycznie interesujące i proste podejście; ale rozrzucanie jednej instancji byle jak pomiędzy wiele węzłów, nie jest tak łatwe jak to się wydaje; gdzie trzymasz dane systemu operacyjnego, dostęp do WE/WY, decyzje schedulera, komunikację między węzłami, co najważniejsze, jak radzić sobie z problemami z węzłami itp...

Wierzę jednakże, że potencjalnie da się to zaimplementować czyściej niż jest to obecnie w Compaq SSI dlatego, że lepsza jest hermetyzacja itp.; ale znany jestem z tego, że się mylę ;-)

To oczywiście byłoby bardzo interesujące. Jeśli _naprawdę_ chcesz otworzyć tę puszkę robali, powinieneś rozważyć dopisanie się do listy linux-cluster, albo do listy Open Clustering Framework (bo zamierzasz wdepnąć w szaleństwo, które można nazwać ,,współdziałaniem i brakiem standardów'').

Poprzepychali się chwilę na temat szczegółów implementacyjnych. Parę pomysłów Jeffa wzbudziło protest Larsa, ale Jeff zauważył, że on tylko opisał coś, co jest możliwe, a nie coś co jest ładne i efektywne.

http://www.bitkeeper.com/stats/linux.html

Dajcie znać co o tym myślcie, chciałbym wiedzieć, czy wydaje wam się to użyteczne; jeśli tak, mogę zrobić umieścić coś takiego jako część interfejsu webowego BK - wtedy takie statystyki będą dostępne dla każdego drzewa z bkbits.

Z wielką pomocą Antona, przeniosłem sterownik NTFS-TNG do serii jąder 2.4.x. Jeśli boisz się używać jąder 2.5.x, ale chciałbyś móc skorzystać z nowego sterownika NTFS, to jest on dla Ciebie.

Sterownik ten powinien udostępniać całą funkcjonalność sterownika dla 2.5.x -- usunięto lub zmieniono jedynie fragmenty kodu specyficzne dla serii 2.5.x.

Wydaje się, że sterownik jest naprawdę stabilny, przetrwał wszystkie testy, ale jeśli zdarzą się jakieś problemy z jego uruchomieniem, proszę o kontakt ze mną albo z Antonem.

Łatę dla waniliowego 2.4.18 można pobrać z:

http://prdownloads.sourceforge.net/linux-ntfs/linux-2.4.18-ntfs-2.0.6a.patch
http://prdownloads.sourceforge.net/linux-ntfs/linux-2.4.18-ntfs-2.0.6a.patch.gz
http://prdownloads.sourceforge.net/linux-ntfs/linux-2.4.18-ntfs-2.0.6a.patch.bz2

Planuję także synchronizować łatkę z wersjami 2.4.19pre, ale to może zabrać trochę czasu.

Erik Andersen był pod wrażeniem i zapytał, czy ta wersja zawiera obsługę zapisu. Pawel odpowiedział: "E-e. Obsługiwane jest tylko czytanie. Zgodnie z tym, co mówi Anton, upłynie jeszcze sporo czasu zanim uzyskamy wsparcie dla zapisu dla NTFS... "


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	24 kwi 2002 - 2 kwi 2002	(4 posts)	Status Linux Trace Toolkitu
2.	25 kwi 2002 - 1 maj 2002	(11 posts)	Polowanie na babole w 2.5
3.	26 kwi 2002 - 2 maj 2002	(22 posts)	Dyskusja na temat maksymalnego rozmiaru twardego dysku
4.	29 kwi 2002 - 1 maj 2002	(4 posts)	Unifikowanie schedulera O(1) z innymi łatami
5.	30 kwi 2002 - 6 maj 2002	(11 posts)	Stan sterowników e100-e1000 w głównym jądrze
6.	7 maj 2002 - 8 maj 2002	(2 posts)	Stan rozwoju 2.5
7.	2 maj 2002 - 3 maj 2002	(14 posts)	Stan obsługi rutera AMD 760 IRQ
8.	3 maj 2002 - 7 maj 2002	(20 posts)	UML może już działać na UML
9.	4 maj 2002	(1 post)	Statystyki rozwijania jądra w BitKeeperze
10.	6 maj 2002	(3 posts)	Stan NTFS w 2.4

Kernel Traffic #166 For 2002/05/13

By Zack Brown

Translated By: Maja Królikowska and Paweł Kot