Kernel Traffic #195 For 2002/12/09

There were 462 different contributors. 244 posted more than once. 176 posted last week too.

Najnowsze Athlony (Model 8 stepping 1 and above) (serie XP/MP i te w laptopach) powodują interesujący problem. Niektóre bity w rejestrze CLK_CTL muszą być programowane inaczej, niż we wcześniejszych modelach. Problem powstaje, gdy ludzie wsadzą te nowe procesory w płyty, których BIOS nie wie o tym fakcie.

Receptą na to jest przeprogramowanie CLK_CTL na 200xxxxx zamiast 0x600xxxxx, jak było w poprzednich modelach. Ludzie z AMD stwierdzili, że to polepsza stabilność.

Poniższa łatka dokonuje tego przeprogramowania, jeśli wykryje model/bios, którego dotyczy problem.

Dave poprosił, by ktoś posiadający komputer, którego to dotyczy, wykonał jakieś testy porównujące sytuację przed i po dodaniu łatki, lecz nikt nie wyraził na to chęci. Pavel Machek zapytał, jakie zachowanie powodowałoby złe ustawianie bitów CLK_CTL. Dave odpowiedział: "Dokumentacja, którą mam nie mówi nic poza ,,...komputery są szybsze...'' z tą poprawką. To po prostu sprawa zaufania, lecz skoro manipulują zegarem procesora, możliwe jest, że mogą *odrobinę* wpływać na jego szybkość." Daniel Nofftz przypomniał, z jego własnych prac z Athlonem, że: "rejestr clk_ctl jest istotny, gdy procesor athlon powraca z trybu acpi-c2. W trybie c2 jest on odłączony od szyny systemowej i wewnętrzny zegar jest spowalniany. W niektórych przypadkach nieprawidłowa wartość w tym rejestrze może nie pozwolić procesorowi powrócić z c2 -> zawiesić komputer lub coś takiego ... (błąd 11 według przewodnika po wydaniach athlonów)" . Dave potwierdził to, dodając, że rejestr "zawiera wartości będące wskazówką dla procesora, w jaki sposób ustawić procesor podczas trybu oszczędzania energii."

Oto lista zmian, które mam zamiar wprowadzić w modułach, na wypadek, jeśli ktoś byłby zainteresowany lub chciał wytknąć błąd w moim rozumowaniu. Większość z tych zmian nie zależy od tego, czy ładowanie modułów jest zaimplementowane w jądrze, czy też jako program przestrzeni użytkownika. Zmiany odnoszące się tylko do modułów ładowanych przez użytkownika oznaczyłem jako ,,wersja dla przestrzeni użytkownika''.

Pozwolić na wiele MODULE_DEVICE_TABLE tego samego typu w tym samym pliku .c zamiast implementacji combined_dev_id_table, która jest teraz używana przez moduły, które naprawdę muszą załadować oddzielne, lecz powiązane sterowniki.
Wprowadzić w końcu jedną komendę do budowania modułów i wkompilowywanych obiektów, tak, żeby wystarczało budować 'all modules' i skrypt do konsolidowania pozwalający na wprowadzanie zmian przez użytkownika, który nie chce rekompilować kodu jądra.
1. Kompilacja module_init, subsys_init, itp. przez mechanizmy używane przez obiekty jądra.
2. Przekazywanie parametrów modułów przez __setup(), a nie przez MODULE_PARM().
3. Wyeliminowanie ,,#ifdef MODULE'' z init.h, module.h i, docelowo, prawie z każdego miejsca.
4. W samym jądrze, THIS_MODULE powinien wskazywać na strukturę module, a nie zawierać wartość NULL (wyeliminowanie wielu drobnych gałęzi.
Zapobiec wykonywaniu rmmod w czasie modprobe, niech rmmod wykonuje flock(/proc/modules,LOCK_EX), a modprobe flock(/proc/modules, LOCK_SH). Tak, można to już wykryć, lecz w ten sposób nie kończy się porażką i nie potrzeba kodu powrotu.

Inne życzenia, które prawdopodobnie nie dotyczą narzędzi inicjujących moduły, przynajmniej, gdy ładowanie modułów jest w jądrze:

niezawodne, bez wyścigów, wyładowywanie modułów przez system modułu->rwsem_list, który opisałem na początku wiadomości: http://marc.theaimsgroup.com/?l=linux-kernel&m=103773401411324&w=2
Dodanie możliwości decyzji załadowania modułu jako nieusuwalnego, aby, w celu zmiejszenia rozmiaru jądra, uniknąć ładowania .exit{,data}. To może wymagać jedynie zmian w insmod z przestrzeni użytkownika.
Używanie funkcji kmalloc dla małych modułów w celu zmniejszenia zużycia pamięci i możliwe, że również w celu uniknięcia używania TLB na niektórych architekturach (412 z 1129 modułów w moim systemie ma .text + .data < 4096).
1. Może ładować .text i .data oddzielnie dla modułów gdzie .text + .data >= 4096 && .text < 4096 && .data < 4096 (26 z 1129 modułów ma tą własnością w moim systemie). Raczej nie warte zachodu.
Wersja dla poziomu użytkownika: opcjonalnie umożliwić przenoszenie wszelkich symboli do przestrzeni użytkownika, wyrzucając w tym celu kksymoops (zaoszczędziłoby ~100kB w moim systemie).
Wersja dla poziomu użytkownika (już opisana w wersji dla ładowania w jądrze): wyeliminować zależność od struktury module, używając module-start.o bazującego na tym, co zaproponował Roman Zippel w http://marc.theaimsgroup.com/?l=linux-kernel&m=103740379811285&w=2 (ale używając pliku module-end.o i eliminując skrypt konsolidujący).
Wersja dla poziomu użytkownika: ładowanie zawartości modułów przez mmap(/dev/kmem), zmniejszając początkowe wymagania dotyczące pamięci i unikając używania malloc i copy.
Przeniesienie szukania zależności pomiędzy ładowanymi modułami do przestrzeni użytkownika (umożliwiając rekonstrukcję z modules.dep w niektórych przypadkach).

Mam nadzieję, że wysłanie tej listy zmniejszy szanse duplikowania starań, lub pomoże naświetlić problem lub potencjalne ulepszenie, których nie rozważyłem.

Rusty Russell odpowiedział na większość pozycji z tej listy, z dwoma głównymi wątkami dyskusji i wieloma mniejszymi. Co do pierwszej propozycji Adama (wiele MODULE_DEVICE_TABLE), Rusty stwierdził, że brzmiało to sensownie i nie powinno sprawiać problemów. O drugiej propozycji (to samo polecenie do budowania modułów i wkompilowywanych obiektów), napisał: "Nigdy tak naprawdę nie zastanawiałem się nad tym, a jak sam zauważyłeś, istnieje tu kilka problemów." Ingo Oeser zasugerował: "Może dałoby się to już zrobić wykorzystując listę modułów dla initramfs? Zresztą, jest to i tak w planach Alana, więc równie dobrze możemy rozwiązać to tutaj." Lecz nikt nie odpowiedział na to.

W kwestii trzeciej z propozycji Adama (zapobieżenie wykonywaniu rmmod podczas modprobe), Rusty określił metodę Adama jako sensowną. Co do czwartej propozycji (niezawodne, bez wyścigów wyładowywanie modułów), Rusty przestudiował podany przez Adama odnośnik i zgodził się na podstawowy schemat, ale zwrócił uwagę, że przeszkody techniczne są znaczące. A dokładniej, stwierdził, że wszelkie blokowanie to nie przelewki; po czym obydwaj porozwodzili się odrobinę nad sprawami technicznymi.

Piątą propozycję Adama (decydowanie w czasie modprobe o ładowaniu modułu jako nieusuwalny), Rusty skomentował: "pozwolenie użytkownikom na to byłoby ślicznym kawałkiem kodu." Lecz Ingo zauważył, że prowadziłoby to do proliferacji zawieszonych wskaźników. Adam nie zgodził się z tym, twierdząc, że problem jest naprawdę prosty; i znów zaczęli dyskutować nad sprawami technicznymi nie dochodząc do porozumienia.

Na szóstą propozycję Adama (używanie kmalloc() na małych modułach w celu mniejszego zużycia pamięci), Rusty odpowiedział: "Tak, to całkiem proste uwzględniając obecny schemat i było to jednym z zamierzeń. Funkcja alloc jest zależna od architektury."

Rusty nie miał nic do powiedzenia o innych propozycjach Adama poza tą z numerkiem 10 (szukanie zależności dla ładowanych modułów z przestrzeni użytkownika), o której napisał:

Osobiście uważam, że ładowanie modułów w przestrzeni użytkownika jest gorsze, szczególnie, gdy zamierzasz zepsuć tę przestrzeń praktycznie każdą z tych zmian. Jasne, możesz użyć bibliotek specyficznych dla jądra, aby przywrócić elastyczność interfejsu, tylko po co? Komplikujesz całość, a Twoje jądro i tak nie jest mniejsze.

W każdym razie uważam, że wspieranie obydwu sposobów nie ma sensu. Albo ładowanie w jądrze jest dobre, w którym to przypadku powinno zostać, lub nie, w związku z czym powinno być wywalone.

Przynajmniej rozstrzyganie aliasów nazw modułów i opcji mogłoby być robione w przestrzeni użytkownika, ponieważ jest to istotne dla automatycznej konfiguracji i jej czytelności w systemie.

jakiś module_name_deamon?

To rozstrzyganie może być rozdzielone i nie musi nawet mieć przywilejów roota, może być nawet rozstrzygane jako specjalny użytkownik (przekazywanie jako parametr przez jądro i ustawianie domyślnie UID 0), gdyż potrzeba po prostu przeczytać pewną bazę danych.

To redukuje ataki nadpisania bufora i temu podobne.

Romain Lievin uaktualnił kgc, swój graficzny front-end do programu LinuxKernelConf autorstwa Romana Zippela, będącego zamiennikiem dla CML1, umożliwiając użycie biblioteki graficznej GTK+ 2.0. Wywołało to dyskusję, w której poproszono o łatkę do nałożenia na źródła jądra w celach testowych; Romain przesłał łatkę kilka dni później.

Jeremy Fitzhardinge zgłosił: "Mam pewne problemy z eksportem systemów plików ext3 z htree przez NFS. Dość często, w chwili gdy program po stronie klienta czyta katalog, po prostu staje i zżera istotną ilość pamięci. Wydaje się, że readdir nigdy się nie kończy i wciąż bez końca zwraca te same elementy katalogu." Dodał: " Na maszynie klienckiej jak i na serwerze działa 2.4.20-rc1 z łatką Teda extfs-update-2.4.20-rc1 (z 8 listopada, czy coś). Czy jest już nowsza łatka?" Z tego, co sam mógł rozpoznać, wydawało się, że "problem dotyczy obsługi ciasteczek NFS readdir, ale nie jest dla mnie jasne, czy to NFS serwer/ext3 generuje złe ciasteczka, czy klient NFS źle je obsługuje." Theodore Ts'o odpowiedział:

Cóż, nawet jeśli serwer NFS generuje wadliwe ciasteczka (co jest możliwe), klient NFS powinien się zachować sensownie i nie kręcić się bez końca w pętli.

Czy możesz mi przesłać (z serwera) listę ścieżek, o których piszesz w pytaniu? Możesz mi też przysłać wynik dumpe2fs -h z systemu plików. Tego drugiego potrzebuję, żeby dostać sito funkcji mieszającej htree, by móc to powtórzyć u siebie.

Co więcej, czy próbowałeś uruchomić e2fsck na systemie plików na serwerze? Bardzo ciekawe byłoby potwierdzenie, czy system plików jest spójny.

Jeremy przesłał informację i dodał: "Ten" [problem] "zdarza się bardzo regularnie. Zawsze, gdy się zdarzy, robię nowy katalog i do niego kopiuję wszystko. To prawdopodobnie działa, bo miesza wszystko i/lub zmienia płożenie konkretnych d-entry w stosunku do pakietów zwrotnych NFS. Chcę powiedzieć, że jeśli system plików wchodzi w niespójny stan, robi to bardzo gwałtownie. Sprawdzę to " [z e2fsck] "w każdym razie... wszystko w porządku."

Nie było dalszego ciągu, ale w innym miejscu Trond Myklebust napisał, że żeby zidentyfikować czy jest to problem po stronie serwera, czy klienta, to pomocne by było "gdybyś mógł wypisać gdzieś ciasteczka, a lepiej nawet, gdybyś mógł dostarczyć surowe wyjście tcpdump. Pamiętaj proszę o użyciu 8k snaplen przy tcpdump..." Jeremy odpowiedział plikiem ze zrzutem pcap z transakcji dodając: "Zmieniłem [rw]size na 1024, bo nie mogłem dojść jak dostać ethereal by zbudować coś z tych fragmentów. Nie wydaje się, żeby to jakoś wpłynęło na zachowanie całości. To zdarzyło się przy kliencie z 2.5.47 (przy tym samym serwerze, co wcześniej)." Stephen C. Tweedie przyjrzał się zrzutowi i po przeanalizowaniu go nie umiał powiedzieć na pewno, w czym leży problem. Powiedział jednak: " Podejrzewam, że jest to problem klienta --- klient powtórzył READDIR, chociaż wcześniej dostał odpowiedź, że było EOF --- ale najlepszym rozwiązaniem jest jednak zmiana serwera tak, żeby dawał dedykowane ciasteczko z EOF w ostatniej pozycji katalogu ze strumienia. Jednym z powodów dla których trzeba to zrobić jest to, że trzeba sobie radzić z niejasną sytuacją, w której aplikacja używa telldir/seekdir do przepozycjonowania strumienia katalogu (tcsh jest naprawdę złe, gdy próbuje to zrobić z 32-bitowych przesunięć na przykład przy rozwijaniu ścieżek, jakkolwiek właściwą odpowiedzią jest tu ,,użyj readdir64''.)" Trond nie zgodził się z tą interpretacją i w spokoju spierali się przez jakiś czas. W końcu Stephenowi udało się samemu powtórzyć ten problem i prześledzić go aż do ext3. Podsumował: " Problem polega na tym, że kod htree readdir nie aktualizuje f_pos po zwróceniu ostatniego kawałka danych wołającemu. To nie przeszkadza większości wołających, bo położenie jest zapisywane w prywatnych danych we filp->, a to przeszkadza NFS." Odpowiedział sam sobie:

Właściwie, to nie jest jasne, co _możemy_ zwrócić, jako f_pos po ostatniej pozycji w katalogu.

W tej chwili używamy jedynie 31-bitowych haszów. Trond, jak inne klienty NFS zareagują, jeśli zwrócimy 32-bitowe ciasteczko NFS? Moglibyśmy łatwo użyć czegoś w stylu 0x80000000 jako f_pos do reprezentowania EOF po stronie Linuksa, ale czy takie ciasteczko wpuszczone w gąszcz NFSv2 zadziała?

Alternatywą jest hakowanie specjalnego przypadku, w którym (na przykład) rozważamy główny htree hasz 0x7fffffff żeby zmapować to na f_pos 0x7ffffffe i rozważać tylko możliwe konflikty, tak, żeby 0x7fffffff było jedynym EOF dla przechodzącego po drzewie htree.

Dla wszystkich innych klientów NFS, które znam, jest to całkowicie akceptowalne. Tak długo, jak dotyczy to jądra Linuksa to jest w porządku, ale gdy przechodzimy do trybu użytkownika, glibc-2.2 i wyższe będą upierały się, że jest to nieprawidłowa wartość (lubią mieć znaki przy rozszerzonych wartościach 32-bitowych). To powoduje niekończące się problemy, ponieważ XFS używa '0xffffffff' jako ciasteczka oznaczającego EOF.

Mam łatkę, która hakuje wartości takich ciasteczek tak, żeby glibc je zaakceptował. To rozwiązanie nigdy nie trafi do oficjalnego jądra, zatem miło by było, gdyby w ext2/ext3 udało się uniknąć potrzeby używania go.

Na zaproponowany przez Stephena alternatywny specjalny przypadek, Trond napisal, że sądzi, że byłoby to w porządku. Jeremy jednakże napisał:

Nawet jeśli to poprawisz to jest inny problem.

Wydaje sie, że htree ogólnie nie działa z NFS w obecnym stanie - działa tylko na małych katalogach, które nie są haszowane i w ten sposób używa schematu ciasteczek bez htree. To może być naprawione przez utworzenie bezpośredniego ciasteczka EOF.

Jednakże w trakcie transformacji z niehaszowanego do haszowanego katalogu schemat ciasteczka zupełnie się zmienia i objawia się tym, że wszystkie znane klientom ciasteczka przestają być właściwe. Oczywisty problem polega na tym, że czasem dodanie pojedynczej pozycji do katalogu zabije wszystkie równoległe readdir.

Wiem, że zmiana katalogu w trakcie jego przeglądania ma w najlepszym wypadku trochę niezdefiniowanych efektów (pozwala opuścić jakąś pozycję, ale nie pozwala jej powielić, jeśli dobrze to rozumiem), ale jeśli dodajesz pojedynczą pozycję do katalogu, to czy jest dozowolone kompletne niedziałanie wszystkich trwających właśnie operacji readdir?

Jedyne rozwiązanie jakie przychodzi mi do głowy polega na tym, żeby zawsze używać haszy nazw jako ciasteczek katalogów, nawet dla tych, dla których nie ma haszowania. To oznacza, że przeglądanie małego katalogu będzie wymagało liniowego przeszukiwania w celu znalezienia pozycji odpowiadającej konkretnemu ciasteczku, ale skoro katalog jest mały, to z definicji nie powinno to zepsuć wydajności.

Frederik Dannemare zapytał, czy istnieje sposób na ograniczenie maksymalnego czasu procesora w zależności od użytkownika. Przeszukał archiwa linux-kernel i znalazł jedynie pojedynczy wątek, w którym Rik van Riel opisał łatkę wypuszczoną przez Conectiva dla jąder serii 2.2. Frederik zapytał, czy ktokolwiek wie o przeniesieniu tej łatki do serii 2.4 i 2.5.

Marc-Christian Petersen odpowiedział: "Mogę zaoferować Ci naprawdę miłą łatkę wykonaną przez Karola Gołębia. Możesz ją znaleźć tutaj: http://www.tls-technologies.com/CPU/cpu-intro.html. Jak dla mnie, działa wspaniale." Frederik odpowiedział, że zdecydowanie ją sprawdzi.

Rik van Riel napisał również, że łatka Connectiva została przeniesiona i była na jego stronie z łatkami. Hu Gang potwierdził, że łatka działała, a Frederik powiedział, że przetestuje ją. W innym miejscu, Martin Waitz napisał również:

Pracuję nad implementacją kontenera zasobów dla linuksa w związku z moją pracą dyplomową.

Kontener zasobów pozwala w hierarchiczny sposób naliczać i ograniczać zasoby. Umożliwi to nie tylko definiowanie ograniczeń w zależności od użytkownika, ale jak tylko sobie wymyślicie (w zależności od usługi, klienta ...)

Pracę mam skończyć w styczniu, lecz zainteresowani mogą obejrzeć (jeszcze nieudokumentowane ;) źródła wcześniej.

po miesiącu ciężkiej, nocnej pracy :)), jestem dumny mogąc zaprezentować uaktualnioną obsługę VISWS dla jąder 2.5.xx.

Dołączam łatki dla 2.5.49-ac1, można je również nałożyć na 2.5.47-ac z małymi zmianami w Kconfig. 2.5.47-ac jest nawet zalecane dla ludzi, którzy nie chcą się przejmować nieporządkiem w modułach w nowszych jądrach.

To jądro ładuje się i pracuje dobrze na moim VISWS 320 z konsolą szeregową lub przez ssh.

Pozostałe problemy:

dlaczego adres wskazujący obraz jądra w formacie elf wskazuje na rest_init()? Do naprawienia tego potrzebna jest sztuczka w programie ładującym, paczka z 'ładowaczem' dołączona.
konsola niczego nie pokazuje, pomimo działającego /dev/fd0;
'modprobe parport_pc' powoduje zawieszenie się, trzeba przejrzeć sondowanie irq;
obsługa SMP zupełnie nieprzetestowana;

Alan, czy możesz dodać tę łatkę do 2.5.49-ac, czy powinna zostać podzielona na mniejsze łatki, zależne od przeznaczenia?

Alan Cox powiedział, że prawdopodobnie zaaplikuje łatkę, dodając: "to prawdziwie obłąkane. Zadbaj o przeniesienie ucLinuksa na Amigę 500 następnym razem 8)"

Robię sobie małą przerwę z okazji Święta Dziękczynienia, ale przedtem, prezentuję 2.5.50.

Włączenia od Alana, Dave'a i Andrew. Uaktualnienia sterowników ACPI, USB, LSM i SCSI. Uaktualniłem również architektury Sparc, ARM i v850.

Dodał też: "Dla niezorientowanych w zwyczajach US: jest to czas w roku, gdy cały kraj zmienia się w jedno, wielkie koryto wypełnione indykami, a każdy zachowuje się jak prosię. Zjedzone indyki, jeśliby je ułożyć w jednej linii, sięgnęłyby, z grubsza licząc, 5.4 raza do księżyca i z powrotem. Małe czarne dziury tworzą się tam, gdzie zbierze się wystarczająca liczba grubych ludzi. To nie wygląda dobrze. I zrobię co w mojej mocy, by wtopić się w otoczenie ;^)."

Nathan Walp dodał: "Hrmm, więc to czyni drzewo 2.5.x o rok starszym. Czapki z głów dla wszystkich, którzy dokonali tak wiele w ciągu 12 krótkich miesięcy."

Rusty Russell podał odnośnik do module-init-tools w wersji 0.8 i poprosił Linusa Torvaldsa o nałożenie łaty. Powiedział:

Niniejsza wersja znowu wymaga depmod, co powinno pomóc tym z Was, którzy mają 1300 modułów. Dostajecie zamiennik depmoda, ponieważ ten stary jest oczywiście zdezorientowany przez jądra powyżej 2.5.47. Aby uruchomić tablice PCI i USB musicie nałożyć małą łatkę na 2.5.50 (poniżej).

Dołączyłem także modules.conf2modprobe.conf; jest w miarę prosty, ale powinien zadziałać u większości ludzi. Zostanie kiedyś dołączony w formie nowych opcji do nowego modprobe.

Zaimplementowałem również kilka ,,ślepych'' (dummy) opcji, także ,,modprobe -c'', co powinno ułatwić skryptom startowym RedHata i Mandrake'a poradzić sobie ze zmianami.

Wielkie dzięki wszystkim tym, któzy nadesłali łaty, powiadomienia o błędach i kopie ich skryptów startowych. Jestem Wam bardzo wdzięczny za odzew!

Wszelkie informacje o błędach proszę nadsyłać na: rusty@rustcorp.com.au.

Gerd Knorr napisał, że jego system wciąż nie startuje prawidłowo z łatką Rusty'ego. Zauważył mnóstwo zwieszonych procesów modprobe w ,,ps'', a w pewnym momencie ,,lsmod'' również się wieszało. Nie dało się potem załadować żadnych nowych modułów, co właściwie unieruchamiało system. Narzekał: "Odpluskwianie modułów jest teraz niemalże niemożliwe. Moduł apm.o puszcza mi w 2.5.50 oopsy. ksymoops nie umie przetłumaczyć żadnego symbolu z modułów. Wenętrzny dekoder modułów jądra (CONFIG_KALLSYMS) również nie działa." Rusty przysłał następną łatę i dodał, że nie mógł odtworzyć tego błędu na swoich systemach. Gdzie indziej wspomniał: "Linus, niestety, odrzucał moje łaty." W pewnym momencie Bill Davidsen powiedział:

Cały ten szmelc nowych modułów kręci się już tu około trzech tygodni, wielu ludzi ma z nim problemy i muszę jeszcze zobaczyć przynajmniej jeden list wychwalający *prawdziwe* pożytki. Czy nadejdzie czas, gdy powrócimy do poprzedniego rozwiązania i przeniesiemy do przyszłych wersji (2.7?), czy to może zmiana typu zrobić-albo-umrzeć?

To nie wygląda jak coś solidnego, wymagającego drobnych poprawek, to wygląda jak kłębek drutu, który rozlezie się w przyszłych wersjach i wciąż będzie wymagał stałego nadzoru.

Jan-Benedict Glaw dodał: "To nie tylko i386 jest do pewnego stopnia popsute. Sprawdzaliście inne architektury? Znowu, większość (o ile nie wszystkie) w ogóle się nie kompiluje. Na przykład ostatnie jądro dla Alphy, któe działało u mnie (TM) to 2.5.44..." Zaraz po nim dorzucił Tomas Szepe:

Nie mogę zrozumieć, jak nowa infrastruktura modułów mogła dostać się do jądra niekompletna, *niefunkcjonalna* i niesprawdzona dokładnie poza drzewem (myślałem, że to standard w tym miejscu). Dojrzałe projekty w rodzaju kbuild 2.5 Keitha Owensa są ignorowane, natomiast coś tak dzikiego jak ,,witajcie na wystawie piekła modułów'' Rusty'ego włącza się właśnie wtedy, gdy drzewo powinno się stabilizować.

I, cholera, nie widziałem nawet żeby Viro i Hellwig narzekali! Co się dzieje? :)

Narzekałem na samym początku. Przejrzenie archiwum może pomóc.

Wróciłem do 2.5.47-xfs na potrzeby mojej codziennej pracy, dopóki jacyś śmiałkowie nie naprawią całego tego bałaganu wokół modułów. Nie wygląda jednak na to, aby miało się tak stać w najbliższej przyszłości.

Od jakiegoś czasu zespół XFS tworzył oddzielne łaty dla XFS, oddzielając zmiany w rdzeniu od dodatków, jak np. kdb, xattr, acl, dmapi. Udostępniliśmy je światu z nadzieją, że przydadzą się deweloperom i dystrybutorom.

Przeczytajcie bardzo uważnie README w każdym katalogu, kształt łat zmieniał się w różnych wydaniach jądra. Jakiekolwiek sugestie już znajdujące się w README będą ignorowane. Jest nawet 2.4.21/README dla niecierpliwych :).

Kiedy opublikowałem 3.7 FINAL, powiedziałem, że rozwój serii 3.x został zawieszony, ale nie mogłem przestać... To jak narkotyk ;)... Następna wersja to z pewnością będzie WOLK4.0 z 2.4.20... Czekam jeszcze na łaty O(1), Lowlat, Preempt dla O(1) dla 2.4.20 ...

Domyślam się, że bardzo chcielibyście tej wersji!

Po ukończeniu prac (dość długich) stworzyliśmy i przetestowaliśmy (również na maszynie SMP) nową implementację POSIX-owych kolejek wiadomości.

Zgodnie z sugestią, zrobiliśmy to jako system plików.

Ostatnio pojawiły się łaty Petera Waechtlera o podobnym działaniu. Jako że jest konkurencyjna dla naszej, wskażę kilka kluczowych różnic (i przewag naszej implementacji, jak myślę :-)

Aby zadziałać, system plików mqueue musi zostać zamontowany (pod /dev/mqueue, jeśli chcemy używać naszej biblioteki),
czytanie z pliku kolejki przekaże pewne informacje o nim, obsługiwane są również główne funkcje vfs,
nie tworzymy nowych wywołań systemowych (ale jeśli preferujemy teraz nieużywanie ioctli, możemy to zmienić w jeden dzień)
ta implementacja nie zmienia niczego w pozostałych częściach jądra,

i dwie ostatnie, najważniejsze:

nasza implementacja obsługuje planowanie priorytetowe, co zostało pominięte w wersji Petera (oznacza to, że jeśli wiele procesów czeka np. na wiadomość, jeden _przypadkowy_ ją otrzyma). To ważne, ponieważ deweloperzy mogą opierać się na tej funkcji - i jest to, jak myślę, najtrudniejsza część implementacji,
nasza wersja został całkiem dobrze przetestowana - z łatą Petera (przynajmniej na 2.5.46) miałem wiele problemów.

Na koniec notka o bibliotece - można ją pobrać z www.mat.uni.torun.pl/~golbi/mqueuelib-3.0beta.tar.gz, ale to wersja beta (głównie, bo nie uaktualniono dokumentacji). Planujemy ukończyć ją (i uaktualnić stronę) w następny wtorek.

Russell King i Manfred Spraul mieli pewne techniczne obiekcje i Krzysztof przysłał uaktualnione wersje łaty.

Romain Lievin chciał zaimportować sterownik tipar do 2.4 i zapytał, czy będą jakieś wersje po 2.4.20; Bert Hubert odpowiedział: "Pewnie, również w serii 2.2 wciąż trwa rozwój. Nie licz na to, że 2.6 stanie się niedługo główną wersją." Bill Davidsen dodał:

Do roku 2001 była wydawana seria 2.0, w tym roku były już trzy wersje 2.2, możesz więc założyć, że będą nowe wersje przynajmniej jeszcze przez rok.

W zasadzie, biorąc pod uwagę wszystkie doniesienia o kłopotach i częściowe poprawki utraty danych na systemach z księgowaniem (a może tylko ext3), spodziewałbym się nowej wersji już niedługo.

Z pewnością, jeśli nadeślesz łatę do końca roku, to zdążysz, jednakże musi i tak zostać zaakceptowana. Nie widzę powodu, żeby nie była, ale to niewiele znaczy.

W 2.4.20-pre5 zrobiono optymalizację funckji fsync w ext3, która może łatwo spowodować pospucie danych podczas odmontowywania. Pierwszy raz doniósł o tym Nick Piggin 29 listopada (dzień po opublikowaniu 2.4.20 i trzy miesiące po włączeniu błędu. Ujawnił się w niefortunnym czasie)

Dotyczy tylko systemów plików zamontowanych z opcją ,,data=journal''. Albo plików działających pod ,,chattr -j''. Większość ludzi jest zatem bezpieczna. Problem nie wystęuje w jądrach 2.5.

Symptomy są następujące: jakiekolwiek pliki zapisane trzydzieści sekund przed odmontowaniem dysku mogą nań nie trafić. Obejście polega na wykonaniu ,,sync'' przed odmontowaniem.

Optymalizacja miała na celu ominięcie zapisu i oczekiwania na bufory i-węzłów, kiedy późniejszy commit i tak by to zrobił. Optymalizację wprowadziliśmy w opcjach data=journal i w data=ordered. Ale to działa tylko z data=ordered.

W trybie data=journal dane pozostaną w pamięci a umount po cichu je odrzuci.

Poprawka polega na wprowadzeniu optymalizacji tylko w tych i-węzłach, które działają w trybie data=ordered.

Ale odpowiedział sam sobie, powiadamiając, że zaproponowana przez niego poprawka nie jest prawidłowa. Dodał: "Proszę, unikajcie ext3/data=journal, dopóki nie rozwiążemy problemu."

Nick Piggin powiedział: "Naprawdę powiadomienie o tym ukazało się na lkml 18 lipca, jeśli dobrze pamiętam, zanim opublikowano 2.4.19, jeśli to pomoże. 2.4.19 i 2.4.20 zawierają błąd, ale nie testowałem poprzednich wersji. Miałem o tym kiedyś przypomnieć, ale Alan wywlókł to już następnego dnia." Andrew odpowiedział: "Jesteś pewien? Nie mogę tego błędu spowodować na 2.4.19. A wyłączenie nowej logiki BH_Freed (która trafiła do 2.4.20-pre5) usuwa błąd." Stephen C. Tweedie uznał, że usunięcie logiki BH_Freed spowodowałoby powrót błędów, które kod BH_Freed miał naprawić. Przedstawił swój punkt widzenia problemu i po bardzo krótkiej technicznej rozmowie wątek zakończył się bez wniosku, kiedy to obaj, Andrew i Stephen, powiedzieli, że znaleźli właściwą poprawkę.

Załączam łatę, zgzipowaną z powodu wielkości, która uaktualnia do ostatniej wersji pnp w 2.5.50. Zawiera wszystkie dziewięć poprzednio nadesłanych łat.

Najważniejsze punkty:

poprawki do BIOS-u PnP,
kilka nowych makr,
PnP Card Services,
różne poprawki błędów,
więcej sterowników przeniesiono do nowego API.

Deweloperzy PnP są proszeni o używanie tej łaty.

Pavel Machek nadesłał dużą łatę i powedział: "Wprowadza ona sterownik amd766 wraz z adm1021 i lm75 do 2.5.50. Czy wygląda na gotowe do włączenia? Jeśli tak, proszę o nałożenie."

Stephen Rothwell zacytował oświadczenie RedHata, w którym firma ogłosiła, że ich system operacyjny oparty na 2.4 mógłby obsłużyć nie więcej niż 16G RAM-u. Zapytał, dlaczego taki limit istnieje. Odpowiedział mu Andrew Morton:

To limit praktyczny. Sama tablica mem_map zajęłaby 720 megabajtów, nie zostaje więc nic wolnej pamięci normalnej strefy.

Przy 16G mem_map[] zajmuje 180 megabajtów i zostaje 540 megabajtów normalnej strefy do ogólnego użytku.

Nawet przy tej proporcji 20:1 highmem:lowmem, system będzie kulał. Kiedykolwiek będziesz miał struktury danych normalnej strefy przybite stronami, matematyka Cię w końcu dorwie.

buffer_heads, stronicowane strony, węzły radix-tree, pte_chains i i-węzły to struktury danych normalnej strefy, któe, w zależności od wersji jądra, mogą zostać wpięte do normalnej strefy przez strony highmem.

W 2.5, z opcją no-buffer-head dla ext2, współdzielone pagetables, highpte, jak skrzyżujesz palce i wiatr będzie południowo-zachodni, 32G systemy mają szanse działać.

32GB to cel naszych prac dla 2.6 i uruchamialiśmy to pod dużym obciążeniem.

Jeśli jednak gotów jesteś działać na podziale 2:2 albo nawet 1:3 użytkownik:jądro zamist standardowego 3:1, może Ci się udać całkiem sporo, włączając prawdopodobnie 64GB. Mam sprzęt, żeby taką bestię zbudować, ale jeszcze się za to nie zabrałem (mamy już wystarczająco problemów ;-)). Wielkie bazy danych tego nie polubią, ale pozostałe obciążenia bez dużych indywidualnych procesów (albo współdzielonych mapowań) będą w porządku.

Udostępniłem dyskutowane tu uaktualnienie HDLC pod adresem: ftp://hq.pm.waw.pl/pub/linux/hdlc/current/hdlc-2.4.20.patch.gz

Łata jest w zasadzie przeniesieniem z aktualnej linii 2.5, co oznacza sporo przepisywania i niezgodność binarną narzędzia przestrzeni użytkownika ,,sethdlc''.

Mamy chyba porozumienie, że łata powinno zostać naniesiona na 2.4, pomimo kłopotów z kompatybilnością. Większość użytkowników i tak korzysta już z uaktualnionej wersji (moje własne sterowniki obsługują tylko dwie starsze karty ISA, zaś sterowniki producentów nowszych kart działają tylko z nowym kodem).

Nowy kod nie jest znowu aż tak nowy, jest w użyciu ponad rok.

Łata nie zmienia niczego poza obszarem ,,ogólnego HDLC'' (poza tym, że dodaje nowe ioctl urządzenia sieciowego SIOCWANDEV, używane zamiast różnych SIOCDEVPRIVATE-ów, ale to trywialna zmiana).

Proszę o nałożenie na 2.4. Dzięki..

Wolałbym nie wpychać kodu chipsetu dscc4 z 2.5.x do 2.4 teraz, kiedy wciąż część obsysa. Czy nie lepiej byłoby poczekać na moje uaktualnienie kodu dscc4 w 2.4.x? Czas oczekiwania = teraz +, w najgorszym razie, kilka dni.

Swoją drogą, jesli ktoś może skontaktować się z Infineon, interesuje mnie informacja, czy nowe chipsety zachowują się tak, jak stare (mam tylko raczej stare).

Krzysztof odparł na temat oczekiwania na uaktualnienie Francois: "Nie widzę problemu, o ile zmieścimy się we wczesnym stadium 2.4.21."

kexec-tools-1.8 są dostępne tutaj: http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.8.tar.gz

Dave Hansen ma łatę umożliwiającą exportowanie zasobów z /proc/iomem powyżej 4GB, czego potrzebują komputery z pamięcią > 4GB.

Zmiany:

/proc/iomem jest teraz przetwarzane, zatem mapa pamięci nowych jąder powinna być prawidłowa.
initrds są ładowane do pamięci, powinny więc również działać.

To powinno sprawić, że kexec będzie w miarę użyteczne.

Wywołanie systemowe: http://www.xmission.com/~ebiederm/files/kexec/linux-2.5.48.x86kexec.diff i poprawki http://www.xmission.com/~ebiederm/files/kexec/linux-2.5.48.x86kexec-hwfixes.diff aplikują się również do 2.5.50, więc ich nie uaktualniałem.

Archiwum jest na: http://www.xmission.com/~ebiederm/files/kexec/

Przepraszam, że nie zrobiłem tego wcześniej. Oprócz świąt walczyłem też z przeziębieniem...

Dave Hansen był bardzo zadowolony. Powiedział: "Uruchomiło się przy pierwszej próbie, nawet przy 64-bitowych zmianach /proc/iomem. Przetestowałem to na maszynach z 16GB i 1GB RAM-u. (klaskanie)" Eric odpowiedział:

Dzięki. Kod czytający /proc/iomem był pisany na bazie pracy Andy'ego Pfiffera i Twojej wcześniejszej łaty. Po prostu je oczyściłem i włączyłem na czysto do mojego kodu bazowego.

Myślę, że powinienem jeszcze to trochę oczyścić ze zgnilizny i posłać ponowienie do Linusa.

Valdis Kletnieks zapytał, czy powiadomienia o błędach lepiej wysyłać na na listę dyskusyjną linux-kernel, na Bugzillę, czy w obydwa miejsca. Odpowiedział mu Martin J. Bligh:

Powiedziałbym, że oba sposoby. Bądź jednak ostrożny, żeby nie duplikować powiadomień. Ludzie dołączający łaty do powiadomień są szczególnie mile widziani. ;-)

Błędy zostaną zamknięte kiedy tylko zostaną naprawione w następnej pełnej wersji, Bugzilla nie powinna zatem być zbyt zaśmiecona. Potrzebujemy lepszej wersji (bardziej przeszukiwalnej), ale to wymagałoby większych prac przy Bugzilli... myślimy o tym, jak zrobić to najlepiej.

proste rzeczy, jak błędy kompilacji
tutaj. Nie ma potrzeby zaśmiecać Bugzilli trywialnymi problemami,
architektura xxx nie kompiluje się
jest ich kilka w Bugzilli i osobiście uważam, że nie przynależą tutaj. Każda architektura poza i386 zawsze będzie goniła i386 i niemal zawsze będzie przedawniona,
trywialne łaty
wysyłać Rusty'emu, a cc tutaj,
wszystko inne
tutaj. Jeśli nie dostaniesz szybkiej poprawki, wyślij to do Bugzilli. W ten sposób ważne błędy nie zaginą gdzieś w archiwach. (Tak długo, jak długo Bugzilla będzie używalna).

skoro już jesteśmy przy Bugzilli: kilka osób (w tym ja) przegladają raz na tydzień bazę danych o błędach i usuwają przedawnione/naprawione błędy. Do tej pory te, które zamykałem były w miarę sensowne, ale jest kilka w postaci:

,,xxx nie działa w 2.5.47'', wtedy pojawiła się przeróbka modułów Rusty'ego i testujący nie sprawdził (albo nie mógł), czy poprawiono to w następnych jądrach. Wyślę pinga do takiego raportu, kiedy zestarzeje się o pięć jąder. Jeśli problem nie będzie miał re-ACK, zamnknę go.

IBM i MontaVista rozpoczęli wspólny projekt mechanizmu kontroli i reguł dynamicznego zarządzania zasilaniem (dynamic power management) dla Linuksa, dla procesorów obsługujących dynamiczne skalowanie napięcia i częstotliwości. Dokument opisujący propozycję można pobrać z:

http://www.research.ibm.com/arl/projects/dpm.html

Działający prototyp proponowanego szkieletu istnieje dla procesora IBM PowerPC 405LP i zostanie opublikowany w najbliższej przyszłości.

Alan Cox odparł: "Interesujące. Mam jednak jedno małe pytanie. Dokument wspomina: ,,Inni również badali możliwości tego typu kontroli''. Ściśliej jednakże byłoby powiedzieć, że mają patenty. Co IBM zamierza z tym zrobić?" Bishop powiedział:

To ważne i skomplikowane zagadnienie. Nasz kod przeszedł wewnętrzny przegląd legalności IBM-a, wciąż jednakże dyskutujemy implikacje patentowe z naszymi prawnikami. Jedyne co mogę powiedzieć, to że spodziewamy się mieć ostateczną odpowiedź w przyszłym tygodniu.

Patent, o który chodzi (US 6,298,448) dotyczy dynamicznego skalowania charakterystycznego dla aplikacji. Chociaż to ważna część naszej propozycji, nie jest to centralny pomysł i wierzę, że propozycja przyniesie pożytek, nawet jeśli ta część zostanie usunięta.

Gdzie indziej, na bardziej technicznym poziomie, Arjan van de Ven zapytał: "Jakiś pomysł czy/jak będzie to pasowało do istniejącego międzyplatformowego szkieletu cpufreq?" Dominik Brodowski odpisał: "Jeśli prawidłowo zrozumiałem propozycję IBM-a, wydaje się to być alternatywą dla cpufreq: inne warstwy pośrednie między niskopoziomowymi sterownikami procesorów, inny kod jądra i użytkownika. Nie jest to więc rozszerzenie istniejącej opcji, ale całkiem nowa opcja." Hollis Blanchard dodał: "Pomysł polega na tym, że wydarzenia skalowania powinny być wykonywane przez jądro, a nie na podstawie danych z przestrzeni użytkownika. Dokument" [...] "wyjaśnia kiedy i dlaczego..." Dominik uważał, że propozycja IBM-a to po prostu duplikacja CPUFREQ z dodatkiem kilku elementów. Powiedział: "CPUfreq udostępnia uniwersalny, niezależny od architektury interfejs pomiędzy kodem jądra, przestrzenią użytkownika o sterownikami procesora w celu statycznego i/lub dynamicznego skalowania częstotliwości i napięcia. Propozycja DPM, to propozycja stworzenia kolejnej takiej ,,warstwy pośredniej''. I choć powinno być możliwe zaemulowanie CPUFREQ jako sterownika DPM, to będzie możliwe również wykonanie tego w drugą stronę, emulując DPM, jako sterownik CPUFREQ." Podsumował: "Chciałbym abyśmy popracowali razem nad włączeniem propozycji DPM do istniejącego szkieletu cpufreq. Jak już mówiłem, jeśli są potrzebne jakieś zmiany w rdzeniu cpufreq, możemy je wprowadzić, o ile nie będą ograniczały funkcjonalności ani nie będą powodowały problemów z działaniem oferowanej funkcjonalności."

Jak już wspomniałem w prywatnej rozmowie z Linusem kilka dni temu, zmieniłem dość znacznie sterownik AGPART. Pewnie pozostało trochę błędów, byłbym więc wdzięczny za testowanie/przejrzenie kodu tej sporej zmiany (>200KB diffa, ale kilka plików się przemieściło).

Wprowadzono nową funkcję ,,agp_register_driver'', która całkowicie oddziela chipset od backendu,
sterowniki chipsetów stały się pełnoprawnymi modułami. To zdaje się działać, gdy wszystko jest wkompilowane. Jeszcze nie przetestowałem modułów, ale oznacza to, że trzeba teraz zrobić insmod via-agp.o albo którykolwiek chipset jest potrzebny, zanim odpali się X. agp_try_supported() jest teraz parametrem modułów chipsetów, nie modułu agpgart.o,
i8x0.c & i810.c stały się intel-agp.c, CONFIG_AGP_I810 jest popsute, naprawię to szybciutko,
agp.c stało się backendem,
wydzieliłem ogólne procedury do generic.c,
numer wersji podskoczył do 1.0. To, moim zdaniem, poważna zmiana, a i tak siedzieliśmy przy 0.99 całą wieczność,
Poprawki wywołań (Alan),
poprawki x86-64 (Andi),
Dodałem rozpoznanie kilku nowych urządzeń,
umieściłem siebie jako głównego opiekuna 1.0+. Jeff Hartmann, o ile mi wiadomo, nie zrobił nic wielkiego w agpart od '99. Próby skontaktowania się z nim nie powiodły się.

Całość można pobrać z bk://linux-dj.bkbits.net/agpgart albo, dla tych, którzy nie mogą, można pobrać diffa : ftp.kernel.org/pub/linux/kernel/people/davej/patches/2.5/2.5.50/agpgart-recore-2.diff.gz.

Rudmer van Dijk przetestował łatkę i napisał, że wydaje się działać doskonale.

Nowy sterownik NTFS 2.1.0 (a) jest już dostępny dla jądra 2.4.20.

Można pobrać go wraz z ntfstools i innymi łatami z http://linux-ntfs.sf.net.

Guillaume Boissiere przysłał swój Stan jąder 2.5 z 4 grudnia, 2002, mówiąc:


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

1.	21 Nov 2002 - 29 Nov 2002	(5 posts)	Nowy 'błąd' w Athlonach
2.	25 Nov 2002 - 29 Nov 2002	(21 posts)	Lista życzeń dla cech modułów
3.	26 Nov 2002 - 29 Nov 2002	(5 posts)	Nowe graficzne narzędzie GKC do systemu konfiguracji LinuxKernelConf
4.	26 Nov 2002 - 28 Nov 2002	(21 posts)	Problemy z NFS/ext3
5.	27 Nov 2002 - 28 Nov 2002	(7 posts)	Ustawianie ograniczeń dla zasobów per użytkownik
6.	27 Nov 2002 - 28 Nov 2002	(5 posts)	Obsługa stacji roboczych SGI Visual w 2.5
7.	27 Nov 2002 - 4 Dec 2002	(21 posts)	Ukazał się Linux 2.5.50
8.	27 Nov 2002 - 29 Nov 2002	(16 posts)	Rozwój modułów w toku; niektórzy deweloperzy są niezadowoleni
9.	28 Nov 2002	(1 post)	Pojawił się Linux 2.4.20
10.	28 Nov 2002	(1 post)	Debuger oparty na jądrze dla 2.4.20
11.	28 Nov 2002	(1 post)	Łaty XFS dla 2.4.20
12.	29 Nov 2002	(1 post)	Ukazał się WOLK 3.8
13.	29 Nov 2002	(1 post)	Wydano Linuksa 2.2.23
14.	30 Nov 2002 - 2 Dec 2002	(5 posts)	Obsługa kolejek wiadomości POSIX
15.	30 Nov 2002 - 2 Dec 2002	(3 posts)	Status różnych stabilnych serii
16.	1 Dec 2002 - 2 Dec 2002	(8 posts)	Zepsute dane w ext3 pod 2.4.20
17.	1 Dec 2002	(1 post)	Obsługa PnP dla jądra Linuksa 2.5.50 w wersji 0.93
18.	1 Dec 2002	(4 posts)	Sterownik i2c-amd766 dla 2.5.50
19.	1 Dec 2002	(4 posts)	Maksymalna wielkość fizycznego RAM-u
20.	1 Dec 2002 - 2 Dec 2002	(3 posts)	Przenoszenie HDLC do 2.4
21.	1 Dec 2002 - 2 Dec 2002	(4 posts)	Opublikowano kexec-tools 1.8
22.	2 Dec 2002 - 5 Dec 2002	(15 posts)	Bugzilla: dalszy ciąg sagi
23.	3 Dec 2002 - 5 Dec 2002	(11 posts)	Propozycja dynamicznego zarządzania zasilaniem
24.	3 Dec 2002 - 4 Dec 2002	(2 posts)	Przeprojektowanie AGPGART
25.	3 Dec 2002	(1 post)	Opublikowano NTFS 2.1.0 dla jądra 2.4.20
26.	4 Dec 2002	(1 post)	Stan jąder 2.5

Kernel Traffic #195 For 2002/12/09

By Zack Brown

Translated By: Damian Wojsław , Maja Królikowska and Marcin Cylke