Polskie Forum Użytkowników Debiana

Podczas jednej z rutynowych aktualizacji (gałąź testing) zainstalowałem xserver-xorg-core w wersji 1.3.0.0.dfsg-6 i kilka innych paczek X-owych. Po restarcie kompa zamiast ekranu logowania XDM dostaję kursor (tekstowe podkreślenie jak za starych czasów DOS-a) w lewym górnym rogu ekranu i klawiatura zamiera.

To samo dzieje się, gdy uruchamiam xorg z trybu single.

Czasem da się wybrnąć kombinacją "Alt SysRq K", potem tylko "Ctrl Alt Del", by móc w ciemno zamknąć system. Ale czasem trzeba restartować z obudowy, co nieraz kończyło się uszkodzeniem systemów plików na twardym.

Naturalne byłoby zajrzeć do Xorg.0.log, tymczasem w nim nie widzę podpowiedzi - być może xorg wiesza się zanim odnotuje w logu błąd.

Do dziś wyjściem była instalacja z powrotem starej wersji xserver-xorg-core, ale po kolejnym zaktualizowaniu (odświeżeniu kilku x-owych paczek) ten sposób nie działa.

Próbowałem wyłączania akceleracji 3D, zamiany steru "radeon" na "vesa", ale na próżno.

W czym problem? Może ktoś z Was też miał takie szopki z tą wersją paczki?

Pozdrawiam

Wydaje mi się, że podany log w załączniku jest ucięty - sprawdź to.

Normalnie, gdy xorg koÃączyÂł pracê z bÂłÃªdem, zrzucaÂł komunikaty do tegoÂż loga i moÂżna byÂło kontynuowaæ pracê w trybie tekstowym. Czy jest moÂżliwe, Âże system zawis nie pozwalajÂąc na ten zrzut?

arctgx, popraw ten post, bo nie mogę się rozczytać co tam napisałeś - same krzaki dałeś

Nie ma sprawy , zatem:

Normalnie, gdy xorg kończy pracę z błędem, to zrzucał komunikaty do pliku z logami i albo mogłem dalej w tej samej powłoce pracować, albo zachęta do logowania (tekstowego) się pojawiała. Czy jest możliwe, że teraz wiesza się i nie jest już w stanie dopisać kluczowych logów?

********
P.S. Byłem przekonany, że ogonki poprawnie wyjdą, a tylko Elinks ich nie wyświetla. Dzień wcześniej przestawiłem globalnie locale na UTF-8 i nie wybrnąłem ze wszystkich konfiguracji. Podczas pierwszej próby nie udało mi się skonfigurować Elinksa do pracy z UTF-8, cokolwiek by to znaczyło. Ale nie chcę odwracać uwagi od tematu tego postu.

[ Dodano: 2007-06-30, 12:35 ]
Udało mi się znaleźć na innych forach kilka postów o tym samym problemie. Jeden z nich zawierał podpowiedź, by nie ładował modułu int10. Zahaszowałem wpis load "int10", dodałem niezależnie od tego Option "NoInt10" "yes", ale wiechy nadal dostaję.

Wygląda coraz bardziej na to, że będę czekał na nowe wydanie paczki...

[ Dodano: 2007-07-20, 23:01 ]
Uaktualniłem xserver-xorg-core do 2:1.3.0.0.dfsg-11 i problem ten sam. Ale w sekcji "Modules" dałem

Disable "dri"

i xorg ruszył. Moduł "glx" jest załadowany, o czym wiem z Xorg.0.log.

Teraz więc problem brzmi: jak odpalić Xorg z akceleracją 3D bez wiechy?

Czyżby moduł radeon_dri.so z libgl1-mesa-dri był uszkodzony? Wersja paczki to 6.5.2-5. Taki sam numer wersji ma libgl-mesa-glx.

[ Dodano: 2008-01-25, 13:41 ]
Nieźle - ponad pół roku dłubałem w problemie - a powodem była nieaktualna bibilioteka libdrm ze źródeł, która nie chciała chodzić z serwerem 1.3 i nowszymi.

Mam też doświadczenie, że nie każde wyjście błędów musi trafiać do logów Xorg. Mój błąd wyszedł podczas uruchamiania X-ów na surowo, przy czym zamrażania (by odczytać ten błąd z ekranu) uniknąłem, nie ładując modułu radeonfb.
To wystarczyło już wygooglować, odpalić ldd na tym module, zobaczyć że korzysta ze starego libdrm w /lib. Bieżąca wersja libdrm siedzi w /usr/lib. Usunąłem więc starą (prawdopodobnie ze źródełek pochodziła), dałem ldconfig na wypadek i gra!