Kernel Traffic #197 For 2002/12/23

There were 510 different contributors. 253 posted more than once. 182 posted last week too.

Teraz, gdy już wszyscy komercyjni dostawcy używają portu schedulera O(1) Ingo, zewnętrzne projekty takie, jak XFS oprócz głównej linii jądra muszą śledzić różne pomniejsze łatki.

Z punktu widzenia tych projektów byłoby świetnie, gdybyśmy mieli nowe, wspólne API w głównej linii jądra. Mamy już właściwy yield() w 2.4.20, ale brak jeszcze API set_cpu_allowed(), które jest wykorzystywane w kernelthreads do przywiązywania do procesora.

Czy istnieje jakaś szansa na włączenie łatki Roberta Love do 2.4.21? Zauważcie, że nie zmienia ona żadnego istniejącego kodu, ale po prostu dodaje interfejs.

Dodałbym do tego, że jest to także użyteczne do przenoszenia różnych rzeczy Ingo związanych z kolejką roboczą (workqueue), które są użyteczne i zupełnie oddzielne od algorytmu szeregowania O(1).

Mam zamiar używać kolejek roboczych przy przenoszeniu niektórych obowiązków sterowników do kontekstu procesu, gdzie właściwie należą [co w sumie pozwoli naprawić wiele błędów].

Christoph powiedział, że pracował nad łatką z kolejką roboczą, a Robert Love wspomniał, że kod kolejek roboczych był przyczyną, dla której na początku wziął się właśnie za set_cpus_allowed().

Martin J. Bligh również odpowiedział na pierwotną wiadomość Christopha, pytając o scheduler O(1): "Jeśli każda dystrybucja go ma, i 2.5 go ma, i już istnieje od jakiegoś czasu, sądzę, że udowodnił, że jest stabilny. Marcelo, jakie są szanse na włączenie tego algorytmu do głównej linii jądra przed 2.4.20?" Ale Christoph odpowiedział, że sam Ingo zawetował to (Alan Cox podniósł brwi ze zdziwienia, że Ingo ma moc wetowania różnych rzeczy w jądrze, ale Christoph przypomniał, że Ingo jest autorem rzeczonej łatki). Robert zauważył: "Ingo powiedział wprost, że nie sądzi, aby scheduler O(1) nadawał się do 2.4. Nie wiem, czy nie zmieniło się to ze wględu np. na stabilizację schedulera. Ale przypominam sobie tę opinię z przeszłości." A Bill Davidsen dodał: "Wymieniłem z nim trochę poczty, wyjaśniając, dlaczego uważam, że jest to bardzo pożądane na serwerach news i wysłałem dane z pomiarów z algorytmem szeregującym O(1) i bez niego. Miałem wrażenie, że przemyśli jeszcze tę kwestię w przyszłości. To znaczy, że ,,pomyśli o tym jeszcze raz'', a nie że zmieni swoją decyzję."

Patrick Mochel zdawał się pamiętać, że interfejs /proc/pci był uznany za przestarzały już w przeszłości, ale nie był tego pewien. Zasugerował, że program lspci jest znacznie lepszym sposobem do uzyskania tych samych informacji, a /proc/pci powinno zostać uznane za przestarzałe, o ile jeszcze tak się nie stało. Sądził, że pozwoliłoby to na usunięcie kawałka kodu, co z kolei uprościło by nieco kod. Spytał, czy jakieś programy z przestrzeni użytkownika jeszcze polegają na /proc/pci. Jeff Garzik odrzekł:

Historycznie, to była decyzja Linusa :)

IIRC /proc/pci było w jednym z następujących stanów (a) uznane za przestarzałe, (b) usunięte lub (c) prawie usunięte, a Linus z powrotem przywrócił je do życia. Logika tej decyzji była taka, że udostępnia szybkie podsumowanie użytecznych informacji, tak jak /proc/cpuinfo i /proc/meminfo. Tzn. nie potrzeba zainstalowanego lspci, wystarczy /bin/cat.

Osobiście sądzę, że byłoby fajnie usunąć /proc/pci -- na rzecz czegoś udostępniającego podobną funkcjonalność z sysfs: ,,cat /sys/all-busses'' czy coś w ten deseń. Nie wiem jak to jest wykonalne. Zasadniczy pomysł polega na tym, aby wylistować tak wiele dołączonych urządzeń, jak to się da w jednym przebiegu, bez konieczności otwierania 40 różnych plików :) [niestety sądzę, że tutaj się z Tobą nie zgadzam ;)]

Gwarantuję Ci, że jeśli usunęlibyśmy nazwy, to uczyniłoby to sekcje __init i struktury trzymane w pamięci mniejszymi... ale czy chcemy? Jasne, że mamy lseisa, i lspci, i lsusb i inne. Ale czy to neguje potrzebę posiadania prostego podsumowania posiadanego sprzętu?

Patrick odpowiedział, że /proc/pci jest rzadko używane i, że ponieważ ta sama informacja była dostępna w przestrzeni użytkownika, było logiczne, aby mieć narzędzie w przestrzeni użytkownika do czytania jej. Kai Henningsen odparł: "Nie wierzę rozwiązaniom opartym na różnych narzędziach przy takich rzeczach. Jest zbyt prawdopodobne, że gdy będę go najbardziej potrzebował, nie będzie do tego odpowiedniego narzędzia. Nie chcę się przekopywać przez 7868 narzędzi, ani nie chcę przekopywać się przez 7868 plików. I im więcej ich jest, tym mniej prawdopodobne, że nawet o nich usłyszę -- spośród narzędzi lsXXX, słyszałem jedynie o lspci i lsusb (bo chyba tylko te mam zainstalowane), które zresztą nie daje żadnej użytecznej informacji osobie, która nie jest ekspertem od USB." Krzysztof Halasa zauważył: "Tak, czy siak, w tej chwili /proc/pci i tak nie działa dobrze (jądro nie wie, jakich urządzeń typu hot-plug używasz i nie zachowuje odpowiednich nazw)." Zasugerował, że jeśli jądro ma zamiar udostępniać te informacje przez interfejs /proc, to niech ten interfejs będzie przynajmniej poprawny.

Gdzie indziej, Petr Vandrovec zauważył, że /proc/pci było bardzo użytecznie przy instalacji, gdy lspci nie było jeszcze zainstalowane. Dodał: "Następnym problemem jest to, że niektóre sterowniki chcą wypisywać ,,czytelną dla użytkownika'' nazwę sprzętu i choć niektóre mają swoją własną bazę nazw (e100), to inne biorą to z pcidev..." Erik Hensema zaoponował: "Każdy na wpół przyzwoity instalator wykrywa automatycznie wszystkie urządzenia PCI. I ma lspci w obrazie instalacyjnym." Na to Dr. David Alan Gilbe odparł: "Tak, ale poczekaj aż utkniesz na jakiejś zakręconej płycie z serii wbudowanych z małym flashem i konsolą szeregowa i będziesz próbował debugować urządzenie, które stworzyłeś."

Jedną rzeczą którą daje ci /proc/pci jest to, że 'lspci' historycznie nie wykonywało poprawnej konfiguracji przerwań (ponieważ rutowanie przerwań jądra nie ma nic wspólnego z konfiguracją przerwań PCI na najbardziej ,,interesujących'' maszynach).

Nie wiem, czy lspci robi to już poprawnie, ale informacja istnieje w /sys, więc rzeczywiście istnieje potencjalna możliwość wyrzucenia /proc/pci.

Patrick przetestował lspci i zgłosił, że wydaje się wykonywać konfigurację przerwań poprawnie. Wysłał łatkę, aby uczynić /proc/pci opcją konfiguracyjną. Nastąpiła krótka dyskusja techniczna, o tym skąd lspci bierze swoje dane i na temat innych rzeczy, aż w pewnym momencie Linus dodał: "Sądzę, że powinniśmy" [...] "upewnić się, że /sbin/lspci (czy jakieś inne narzędzie) może łatwo pokazywać zarówno mapowanie przerwań z jądra _lub_ ,,oryginalną konfigurację PCI''. W tym momencie zgodzę się, że /proc/pci dożyło swego kresu." Nastąpiła jeszcze dyskusja implementacyjna i wątek wygasł.

Milan Roubal zauważył, że do jego systemu dało się podłączyć jedynie 10 urządzeń IDE, a chciał przekroczyć ten limit. Próbował napisać własną łatkę, ale udało mu się zwiększyć tę liczbę jedynie do 12, a chciałby dojść do 20, czy nawet do 32, co byłoby, jak uważał, wystarczającą liczbą na jakiekolwiek potrzeby. Alan Cox zasugerował metodę dodania 'a-f' do istniejących '0-9' nazw IDE. To pozwoliłoby uzyskać kilka dodatkowych wartości, a Petr Sebor napisał łatkę, która realizowała ten pomysł tworząc idea - idez (dodatkowych 26 wartości), ale Henning P. Schmiedehausen wytknął, że to jedynie odwlekanie problemu w czasie. John Bradford wskazał, że 36 urządzeń IDE powinno wystarczyć każdemu. A Alan zauważył, że jako minimalna zmiana w stabilnej serii 2.4, łatka Petra jest odpowiednia i, że i tak będą problemy z liczbą pobocznych numerów urządzeń przy tej liczbie urządzeń IDE. Sądził, że następna niestabilna seria będzie lepszym miejscem, aby zająć się tym problemem na poważnie.

9 Dec 2002 - 14 Dec 2002 (11 posts) Subject: "[BK fbdev] Yet again more fbdev updates."

James Simmons zakomunikował Linusowi Torvaldsowi z radością: "Oto aktualizacje fbdev, na które ludzie czekali tak długo. Część sterowników została już przeniesiona. Wiele poprawek zostało zaimplementowanych i dodano również wiele fajnych rzeczy. Wciągnij te zmiany do swojego drzewa, proszę. Zostały przetestowane przez ludzi na tej liście. Dziękuję." Christoph Hellwig poprosił Linusa o wciągnięcie zmian Jamesa mówiąc: "Wysyła aktualizację fbdev razem z poprawkami znanych problemów w różnych sterownikach już od dłuższego czasu, a ja nie przypominam sobie, kiedy widziałem ostatnie włączenie zmian w fbdev. Większość sterowników fbdev z głównej linii jądra jest bez tych poprawek zupełnie bezużyteczna." Linusa nie odpowiedział na to bezpośrednio, ale narzekał, że zmiany we framebufferze najwyraźniej spowodowały, że nie działa jego konsola VGA. Wysłał kilka objawów i razem z Jamesem przez jakiś czas wymieniali się uwagami, aż James sądził, że wyśledził problem; nie było jednak pozytywnego potwierdzenia tego faktu na liście.

No dobra, duża łatka, ale tym razem zmiany są wszędzie, razem z dużą liczbą losowych małych poprawek (np. dużo poprawek kompilacji dotyczących niebudowania się jądra z powodu czyszczenia plików nagłówkowych).

Reorganizacja AGP, łączenie z fbdev, aktualizacje s390 również pomogły zwiększyć łatkę.

Łączenie z różnymi architekturami, więcej łączenia z Andrew, a Al rozpoczął czyszczenie jednego ze swoich ulubionych kawałków kodu -- devfs. Szczegóły w liście zmian.

PS. Wyjeżdżam na trzy dni, więc...

Allan Duncan wskazał, że kod framebuffera jest nieco zepsuty, a James Simmons powiedział: "Sterownik Matroksa nie został jeszcze przeniesiony. Mamy przeniesioną do nowego api już mniej więcej połowę sterowników. Przez następny tydzień będę przenosił kolejne sterowniki. Mamy już wykonane ostateczne zmiany w api, więc można przenosić sterowniki!!!! Jeśli potrzebujecie pomocy przy przenoszeniu, napiszcie do mnie, a ja postaram się pomóc." A Petr Vandrovec był zachwycony widząc łatki framebuffera w końcu zaakceptowane w głównej linii jądra.

No to macie pierwsze jądro pre dla 2.4.21, w którym znajdziecie włączony kod IDE z drzewa Alana.

Testujcie uważnie, bo nowy kod IDE nie jest jeszcze w pełni przetestowany.

Nie używajcie go przy krytycznych danych.

Natjaniel Russell ogłosił: "Ta łatka dodaje obsługę mostka Via VT8633 AGP. Przetestowałem ją z różnymi aplikacjami GL, w tym z różnymi wygaszaczami ekranu. Łatka zawiera procedury via_generic_setup i identyfikatory urządzeń. Zaaplikujcie proszę do bieżącego jądra 2.4.X." Marcelo Tosatti odparł: "Zaaplikowałem, dzięki."

Garst R. Reese spytał, czy ktoś się aktualnie opiekuje ROMFS, a Miles Bader odesłał go do http://romfs.sourceforge.net. Garst powiedział, że już tam próbował, ale informacja z kontaktami na tej stronie wyglądała na martwą. Miles odparł: "Hmmm, możesz spytać opiekuna debianowego genromfs; Chyba pamiętam, że kontaktował się z autorem już wcześniej: Juan Cespedes <cespedes@debian.org>" Koniec wątku.

Paul Mackerras zaoferował: "Ta łatka naprawia sterownik offb i naprawia Makefile, tak żeby nie szukało nieistniejącego pliku (cfbimgblit.o), gdy jest włączona opcja CONFIG_FB_OF. W sterowniku offb przy niektórych kartach nadpisywaliśmy koniec pola info->fix.id i dodatkowo mieliśmy niezdefiniowaną zmienną. Sądzę, że możemy pozbyć się również linii ,,info->node = NODEV;''" James Simmons odpowiedział: "Zaaplikowałem wszystkie łatki :-)"

W dalszym ciągu brak rozstrzygnięcia w sprawie dwóch konkurujących projektów procps. Albert D. Cahalan ogłosił:

To wydanie zawiera możliwość wyboru użytkownika w top, opcję -e dla sysctl potrzebną do skryptów inicjujących w Red Hacie 8.0 oraz wykorzystuje /proc/*/wchan z ostatnich jąder 2.5.xx.

Jeśli należycie to tych, którzy aktualizują procps z wersji 2.0.xx, możecie oczekiwać:

top może sortować po dowolnej kolumnie (stare klucze sortowania cały czas są dostępne)
top może wybrać procesy pojedynczego użytkownika do pokazywania
top może być wyświetlany w trybie wielooknowym i/lub kolorowym
vmstat ma opcję -s, jak w systemach UNIX i BSD
vmstat ma opcję -f, jak w systemach UNIX i BSD
watch nie zjada przez pomyłkę pierwszej pustej linii
vmstat używa szybkiego algorytmu O(1) na jądrach 2.5.xx
polecenie pmap jest zgodne z SunOS
vmstat pokazuje czas IO-wait
pgrep i pkill potrafią znaleźć najstarszy pasujący proces
sysctl obsługuje interfejsy VLAN z Linuksa 2.5.xx
top pokazuje czas IO-wait wtw, gdy jądro go oblicza
większość programów jest szybsza od 30% do 300% (testowane na 450 MHz MPC7400)
ps ma nowy format ,,-F'' (bardzo ładny, jak w DYNIX/ptx)
ps z poprawnym wyborem procesów BSD
lepsza obsługa bardzo długich uptime'ów

Istnieje lista dyskusyjna procps-feedback@lists.sf.net, której można użyć do wysyłania propozycji nowych rzeczy, zgłaszana błędów i takich różnych. Używajcie jej! Dzięki odzewowi dzieją się różne rzeczy.

Oto łatka do 2.5.51 z uaktualnionym dmfs. Zawiera dwie łatki pod adresem: http://people.sistina.com/~thornber/patches/2.5-unstable/2.5.50/2.5.50-dmfs-1/00012.patch i http://people.sistina.com/~thornber/patches/2.5-unstable/2.5.50/2.5.50-dmfs-1/00013.patch z następującymi zmianami:

naprawia niezgodność typów przy blokowaniu (próba wywołania spin_lock na rw_semaphore).
naprawione ostrzeżenia przy kompilacji przy makrze dbg() (powinniśmy użyć tu czegoś lepszego, na razie wykomentowałem...)
zmieniony plik dev, aby wypisywał wartość kdev, a nie właściwe urządzenie blokowe.

Co do ostatniej zmiany, to nie śledziłem sposobu, w jaki inne pliki współpracują z ich złożoną strukturą tworzenia strony, jako że to jedynie prosty jednolinijkowy plik.

On i Joe Thornber przez chwilę dyskutowali implementację i wkrótce wątek wygasł.

Zestaw testów do wstawiania błędów

Fault-Injection Test Harness Project

Mam przyjemność ogłosić uformowanie się nowego projektu, mającego na celu rozwijanie zestawu testów do wstawiania błędów do wewnątrz działającego jądra. Projekt ma bazę na http://fault-injection.sf.net, z drzewem bitkeepera umieszczonym na http://fault-injection.bkbits.net:8080/linux-2.5/, oraz na kanale IRC #fi na serwerze 206.103.61.170. (Wpis DNS dla IRC serwera się zmieni, ale adres IP powinien pozostać taki sam.)

Projekt został zapoczątkowany w celu sprawdzenia, czy sterownik był do zaakceptowania dla środowiska nośnika (ten ,,mistyczny'' ulepszony sterownik) :). Teraz, stał się ogólnym narzędziem do wstawiania błędów do którejkolwiek części jądra w celu sprawdzenia czy jądro reaguje tak, jak oczekuje tego deweloper. Mamy pewnego rodzaju (...) konstrukcję w _bardzo_ wczesnym stadium rozwoju, ale dla większości części sprawy dopiero zaczynają się rozwijać. Wiem, że na tej liście jest kilka osób, które mają pewne doświadczenie w temacie wstrzykiwania błędów w innych Uniksach i część z Was doradzała mi w emailach, że moglibyście być zainteresowani stworzeniem jakiegoś narzędzia do wstrzykiwania błędów dla Linuksa. Mam nadzieję, że skuszę Was do wspierania naszych starań (nawet jeśli chcecie nam tylko pomóc kierować projekt w odpowiednią stronę.)

Jak wspomniałem, korzystamy z klonu drzewa 2.5, które co jakiś czas synchronizujemy. Drzewo CVS i ,,migawki'' dla tych, którzy nie korzystają z bitkeepera, dostępne są ze strony projektu na sourceforge, lecz pozostają one zawsze trochę w tyle.

Yasunori Goto wyraził duże zainteresowanie projektem i chciał pomóc, ale na liście nie było odpowiedzi.

Nowa wersja łatek ACPI jest dostępna pod adresem http://sf.net/projects/acpi. Nie-Linuksowe paczki źródłowe nie będą dostępne przed 20 grudnia z powodu problemów z publikacją na WWW. (Mogę podesłać e-mailem, jeśli ktoś chce.)

(Jeśli już ściągnęliście łatkę do 2.5.51, możecie chcieć ją pobrać ponownie. Dodałem małą poprawkę przy zapisywaniu do interfejsu /proc.)

Różne rzeczy. Najbardziej zauważalne jest połączenie z Andrew z wieloma różnymi małymi poprawkami.

Aktualizacje XFS, JFS, ACPI i USB. Aktualizacja KConfig i implementacja parametrów modułów Rusty'ego. I poprawka głupiego nanosleep(), które dało o sobie znać w kilku programach.

Wypycham to, bo próbowałem zsynchronizować rzeczy, które mi się zebrały, gdy mnie nie było w tym tygodniu (podpowiedź: jeśli czegoś nie ma w tym jądrze, nie ma tego w mojej kolejce do wejścia i powinniście ponownie podesłać).

W ciągu dyskusji okazało się, że łata Bena Collinsa dla tego jądra mogła włączyć nieco starszego kodu, co było wynikiem niepoprawnego śledzenia wielu drzew jądra. Ben zaczął narzekać: "Próby śledzenia dwóch odrębnych drzew ze źródłami nie jest tak łatwe, jak mogłoby się wydawać." I dodał: "Włożyłem sporo wysiłku, aby włączyć zmiany wysłane Linusowi do repozytorium Linux1394." Linus odparł:

Jest o wiele łatwiej, gdy śledzisz je _często_, a nie sporadycznie. To główny problem, który mam z drzewami CVS innych osób -- CVS ma bardzo słabą obsługę śledzenia dowolnych zewnętrznych źródeł i to w połączeniu z tym, że ludzie nie śledzą tego w sposób systematyczny, zazwyczaj powoduje problemy.

Przy CVS, prosty skrypt, jak

pobierz bieżącą wersję
znajdź różnice z ostatnią wersją, z którą się łączyłeś
zaaplikuj zmiany do bieżącego drzewa
_potem_ wygeneruj diff do bieżącej wersji
usuń ,,ostatnią wersję łączoną'', zastępując ją bieżącą wersją.

będzie działał całkiem zgrabnie w większości przypadków dla podsystemów, które nie dostają zasilania z innych źródeł niż ,,opiekun''. Zwłaszcza, jeśli robisz to z rozsądną częstotliwością (możesz zrobić wsteczne łączenie, nawet jeśli _nie_ jesteś gotów, aby wysłać mi swoje rzeczy), diff z mojego drzewa będzie mały i łatwy do włączenia.

Jeśli sądzisz, że ,,opiekun'' oznacza, że nikt inny nie może dotknąć drzewa i z tego powodu nie musisz dbać o to, jesteś w BŁĘDZIE.

Alternatywnie, nigdy PRZENIGDY nie rób łatki do ,,bieżącej wersji jądra''. Rób jedynie łatki do _ostatniego_ jądra, z którym się łączyłeś, a jeśli nie będę w stanie zaaplikowac łatki, powiem Ci o tym. Robienie łatki pomiedzy Twoim drzewem a moim _zawsze_ skończy się utraceniem poprawek.

Ben odrzekł: "Nie winiłem nikogo o nic, tylko zauważyłem, że niemożliwym jest nigdy nie popełniać błędów. Ty także je popełniasz." Powiedział: "Nigdy nie powiedziałem" [że ,,opiekun'' oznacza, że nikt inny nie może dotknąć drzewa.] "Powiedziałem, że ponieważ nie jestem w stanie spędzać zbyt wiele czasu na śledzeniu zmian, _czasami_ nie zauważam ich. W logach repozytorium SNV znajdziesz wiele śladów, gdy włączałem zmiany z Twojego drzewa. Naprawiłem już i ten błąd dodając łatkę do repozytorium linux1394."

Linux 2.2.24-rc1

Poprawka literówki w maintainters (James Morris)
Dave Niemi się przeprowadził (Dave Niemi)
Poprawka niepoprawnego blokowania na nieblokujących potokach (Pete Benie)
Poprawka niepoprawnej identyfikacji niektórych procesorów AMD (Bruce Robson)
Poprawka paskudnego błędu skb_realloc_headroom (James Morris)
Usunięcie ostrzeżenia kompilatora w sterowniku lance (Thomas Cort)
Poprawka błędu obsługi znaku w sterowniku pms (Silvio Cesare)
Usunięcie możliwości mmapowania /proc/<pid>/mem jak to jest w 2.4/2.5 (poprawia też kilka błędów) (Michal Zalewski)

Jest dostępny pod adresem https://sourceforge.net/projects/e1000.

Pełny tytuł to:

Rodzina kontrolerów ethernetowych Intel 8255x 10/110
Podręcznik programisty Open Source
Wersja 1.0

(Intel 8255x 10/100 Mbps Ethernet Controller Family
Open Source Software Developer Manual
Revision 1.0)

Podręcznik powstał w celu wsparcia utrzymania sterownika e100 (czy też najlepszego sterownika dla sprzętu sieciowego PRO/100 ;-). Podręcznik obejmuje kontrolery ehternetowe 82557, 82558, 82559, 82550 i 82551.

Chciałbym podziękować Jeffowi Garzikowi za naleganie na tę publikację i za cierpliwość na użeranie się z biurokracją Intela.

Chciałbym również podziękować edytorom i recenzentom z Intela: Carolyn Abrigana, Larry'emu Batesowi, Julie Donnelly, Johnowi Ronciakowi, Wen-Hwa Tao, Eli Kupermannowi, Davidowi Valdezowi, Colleen Culbertson i zwłaszcza Glenn Bergis za niepoddawanie się.

Odbyła się rundka generalnego aplauzu od deweloperów jądra razem z prośbami o więcej dokumentacji do takich rzeczy, jak sprzęt kryptograficzny z PRO/100 S i podręcznik programisty dla e1000. Scott powiedział, że nie ma specjalnych planów co do żadnej z tych rzeczy, ale rzeczywiście podręcznik e1000 jest pożądanym celem na przyszłość.

Chciałem publicznie podziękować zespołowi Intel NIC [i związanym z nim osobom] za wspaniałą robotę. Odpowiadaliście zarówno na techniczne, jak i na polityczne pytania, jak te dotyczące otwarcia dokumentacji.

Mamy teraz sytuację, gdy myślę, że to udostępnienie dokumentacji poprowadzi nas do lepszych doświadczeń użytkowników Linuksa na sprzęcie Intela i być może posłuży jako wzór innym dostawcom sprzętu.

Dzięki Intel!


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

1.	2 Dec 2002 - 13 Dec 2002	(35 posts)	Stan schedulera O(1) i związanych z nim łatek w 2.4
2.	6 Dec 2002 - 10 Dec 2002	(39 posts)	/proc/pci kontra lspci
3.	6 Dec 2002 - 13 Dec 2002	(22 posts)	Więcej niż 10 urządzeń IDE w systemach 2.4
4.	9 Dec 2002 - 14 Dec 2002	(11 posts)	Stan uaktualnień framebuffera
5.	9 Dec 2002 - 12 Dec 2002	(22 posts)	Ukazał się Linux 2.5.51
6.	10 Dec 2002 - 17 Dec 2002	(22 posts)	Ukazało się jądro Linuksa 2.4.21-pre1
7.	10 Dec 2002 - 13 Dec 2002	(3 posts)	Stan obsługi mostka Via VT8633 AGP w 2.4
8.	11 Dec 2002 - 12 Dec 2002	(4 posts)	Opieka nad ROMFS
9.	11 Dec 2002 - 12 Dec 2002	(2 posts)	Poprawka dla sterownikia offb
10.	12 Dec 2002	(1 post)	Ukazało się Procps 3.1.3
11.	12 Dec 2002 - 13 Dec 2002	(7 posts)	Stan dmfs w 2.5
12.	12 Dec 2002	(2 posts)	Nowy zestaw testów do wstawiania błędów
13.	13 Dec 2002	(1 post)	Aktualizacja ACPI
14.	15 Dec 2002 - 16 Dec 2002	(12 posts)	Ukazało się jądro 2.5.52; Śledzenie wielu drzew
15.	16 Dec 2002 - 19 Dec 2002	(7 posts)	Ukazał się Linux 2.2.24-rc1
16.	17 Dec 2002 - 18 Dec 2002	(8 posts)	Ukazał się podręcznik programisty Intel PRO/100

Kernel Traffic #197 For 2002/12/23

By Zack Brown

Translated By: Jakub Jankowski and Paweł Kot