# [X] Deadlock

## mdk

Nie wiem czy śledzicie inne fora, ale być może zauważyliście posty o b. podejrzanym problemie związanym z X'ami. System "zamraża się" (najczęściej - podczas korzystania z mozillowatych aplikacji, choć nie tylko), widać kursor myszy (można nim ruszać) ale klawiatura jest niefunkcjonalna i nic nie da się zrobić/kliknąć. System (zazwyczaj) jednak "działa", i można się do niego zalogować np. przez SSH. 

Problem jest b. podejrzany bo:

1. Występuje zarówno na Xorg jak i Xfree

2. Nie jest zależny od sterowników karty graficznej (ATI, NVIDIA)

3. Nie jest zależny od jądra (2.4, 2.6)

4. W innych dystrybucjach nie występuje, lub występuje b. rzadko. 

5. U jednych występuje 5 razy dziennie, u innych raz na miesiąc.

Główne posty o problemie:

https://forums.gentoo.org/viewtopic-t-198023.html

https://forums.gentoo.org/viewtopic.php?t=215629

(i mnóstwo innych. Keywords: xorg freeze lockup)

Nie udało się znaleźć żadnej jednoznacznej przyczyny/rozwiązania tego problemu. Różnym ludziom pomagały (lub zmniejszały częstotliwość występowania) róźne rzeczy, np:

1. Zmiana metalog na syslog

2. Zmiana syslog na metalog

3. Zmiana reiserfs na ext3

4. Wyłączenie ACPI

6. Zmiana sterownika NVIDI, downgrade, upgrade, wyłączenie Sideband addressing.

7. Sztywne IRQ dla karty graficznej w biosie

8. Przejście z Gnome na KDE

9. Przejście z KDE na XFCE

Spotkaliście się z tym? U mnie pojawiło się magicznie parę dni temu przy okazji upgrade'u do xorg-x11 6.8.2-r1. W ciągu dwóch godzin "trafiły" mi się trzy "zmrożenia". Od razu zrobiłem downgrade z powrotem do xorg-x11 6.8.0... i od tego czasu (trzy dni?) trafiło mi się jedno "zmrożenie" (wcześniej nigdy się z tym nie spotkałem!)

???

----------

## bacouch

Mi sie pojawialy ostatnio bardzo czesto szczegolnie jak probowalem odpalic cos z kde 3.4, ale kiedy zdowngradeowalem sterowniki nvidii do 6629-r4 z 7167 wszystko wrocilo do normy i poki co dziala bezproblemowo(jakies 3 dni).

----------

## m@niac!

ja staram sie miec system jak najbardziej aktualny, zawsze najnowsze drivery, xorg6.8.2, kde3.4, nigdy nie mialem zadnych freezow.

 jedyne co mi sie zdarzylo to sie komp sam zresetowal ale dlatego ze byl pod wplywem 18godzinnej kompilacji i nagle wydarzyl sie skok napiecia. a tak to zadnych problemow.

----------

## fallow

[wersja_szybka]

musze teraz wyjsc  i nie studiuje wszystkich materialow ktore swietnie tutaj opisales ( zrobie to  pozniej ) - tak czy siak wlasnie taki problem mam ze sterownikami nvidi 7167 .  pomogl mi downgrade do 6629.  u mnie "dzialo " sie to przy wlaczonym composite i probie przeciagniecia okna mozilli .  dokladnie - wtedy kiedy w driverze nvidii wlaczony byl renderaccel , jesli byl wylaczony wszystko bylo ok.  zglosilem ten blad na bugsy xfce gdzie powiedzieli ze to blad nvidii i zebym sprobowal zmniejszyc agprate i wylaczyc sba - nie pomoglo , od nvidii nie dostalem zadnych odpowiedzi ,  a spotkalem sie z opiniami ze starsze modele geforcow wywaluja takie objawy ( albo raczej odwrotnie ) z nowymi driverami .

moja karta to geforce 2 GTS. 

[/wersja_szybka]

cheers.

----------

## mirekm

Mam ten sam problem. 

U mnie pomogło nie ładowanie drivera ac z ACPI.

Obserwowałem dość długo ten problem i szczerze nie wiem co jest przyczyną,

ale zauważyłem, że przerwanie timera (irq0) przestaje działać, pomimo że przerwanie LOC na procesorze hula. 

W momenice kiedy irq0 stanie to w zasadzie jest już koniec pod x-ami.

----------

## mdk

 *Quote:*   

> 
> 
> pomogl mi downgrade do 6629
> 
> 

 

No... jednak u mnie okazało się, że problemem też są sterowniki 7167. Nowy xorg tylko bardziej to "obnażył". Downgrade do 6629 pomógł. Podobno pomaga też mącenie z ustawieniami AGP, ale to tylko jedno z rozwiązań. 

Problem tkwi gdzieś głębiej... w jednym z tych postów o identycznym efekcie/problemie pisze człowiek z iBookiem + ATI! 

 *Quote:*   

> 
> 
> jedyne co mi sie zdarzylo to sie komp sam zresetowal ale dlatego ze byl pod wplywem 18godzinnej kompilacji i nagle wydarzyl sie skok napiecia. a tak to zadnych problemow
> 
> 

 

Nie zdziw się, jak pewnego dnia się pojawi  :Evil or Very Mad:  To wyskakuje jak diabełek z pudełka, ja też nie miałem problemów przez osatnie pół roku z nvidią. 

 *Quote:*   

> 
> 
> ...zauważyłem, że przerwanie timera (irq0) przestaje działać, pomimo że przerwanie LOC na procesorze hula. 
> 
> 

 

Po freezie u mnie zużycie procesora przez X'y szło do 100% (permanentnie).

----------

## arsen

Dodam że miałem podobne objawy na sterach 7167

Z tym że od razu po odpaleniu x-ów to mi się działo, po chwilowych męczarniach poszedł downgrade  :Smile: 

----------

## Zwierzak

Musze sie przyznać że mi to właśnie występuje, i nawet nie wiedziałem ze może być to winą przegladraki. Jednak ja bez przegladarki żyć nie moge, było by tro jak odciecie polowy reki. Jedno jest pewne problemem jest Gecko, bo raczej nie sama mozilla skoro wystepuje to w kilku mozillach.

----------

## keman

Ten sam problem, downgrade sterów nvidii pomogł. Teraz te najnowsze (7167-r1) mam zamaskowane.

Ludzie coś glendzili o spatchowaniu stera, ale nasze Gentoo samo patchuje podczas emergowania  :Smile: 

Miałem jeszcze jeden ciekawy objaw na nowych sterach, i włączonym renderaccel, podczas uruchamiania nowego KDE3.4 system sie tak samo zamrażał na tym splash screenie.

----------

## wojtek

 *mirekm wrote:*   

> ale zauważyłem, że przerwanie timera (irq0) przestaje działać, pomimo że przerwanie LOC na procesorze hula. 
> 
> W momenice kiedy irq0 stanie to w zasadzie jest już koniec pod x-ami.

 

Mozna wiedziec jak to sprawidziles? Bo IMHO jak stanie IRQ0 to w ogole nici z przelaczania procesow i dalszej dzialalnosci sytemu... W kazdym razie do niedawana tak bylo. Teraz, w dobie APIC, ACPI i HPET to moze wygladac nieco inaczej.

----------

## mirekm

Sprawdziłem to podglądając /proc/interrupts

Ale doszedłem do tego przypadkiem, bo takie rzeczy jak kompilacja puszczam z konsoli 

a w kosoli takie sprawy jak klawiatura chodzą nawet w przypadku zawieszenia timera 0.

Nie wiem dlaczego tak jest. 

W każdym bądź razie nie zauważyłem, żeby był problem z innymi przerwaniami (tzn dyski, sieciówka, klwaiatura i myszka chodzą).

Natomiast wszystkie zadania wykorzystujące timery i opóźnienia śpią i czekają na swój czas, który nigdy nie nadchodzi.

----------

## wojtek

 *mirekm wrote:*   

> Sprawdziłem to podglądając /proc/interrupts
> 
> Ale doszedłem do tego przypadkiem, bo takie rzeczy jak kompilacja puszczam z konsoli 
> 
> a w kosoli takie sprawy jak klawiatura chodzą nawet w przypadku zawieszenia timera 0.
> ...

 

Hmm, na ile znam budowe kernela (a raczej nie jest mi aż tak obca) to brak przerwania IRQ0 skutkowal by brakiem mozliwosci wywlaszcznia procesow. Najprawdopodobniej cos w kernelu sie sypnelo z jego obsluga, ale samo przerwanie (dostarczne przez niezalezny sprzetowy uklad) nadal funkcjonowalo skoro mogles normalnie uzywac konsoli. Druga hipoteza (tez mozliwa), ze uzywasz ukladu HPET/APIC zamiast starego 8254 jako glownego przerwania timera (z tymi timerami to jest troche zakrecona sprawa, bo moze byc kilka zrodel czasowych w systemie, ale tylko jedno jest uzywane przez program szeregujacy jako sygnal odniesienia) co od pewnego czasu mozna wykorzystac w Linuksie i rzeczywiscie 8254 stoi, ale HPET/APIC dalej napedza system.

Szczegoly tutaj: http://www.cs.ucl.ac.uk/staff/a.greenhalgh/teaching/2b10/lecture_scheduling.pdf

----------

## mdk

[quote]

Musze sie przyznać że mi to właśnie występuje, i nawet nie wiedziałem ze może być to winą przegladraki. Jednak ja bez przegladarki żyć nie moge, było by tro jak odciecie polowy reki. Jedno jest pewne problemem jest Gecko, bo raczej nie sama mozilla skoro wystepuje to w kilku mozillach.

[quote]

To nie jest wina przeglądarki! Po prostu przeglądarka w jakiś sposób "wywołuje" ten błąd. Podobnie np. Gaim i operacja przełączania wirtualnych pulpitów. 

Żadna aplikacja w Linuksie nie ma prawa zawieśić jądra/systemu. Jeżeli coś takiego się dzieje, to znaczy, że problem leży po stronie kernela/sterowników lub hardware'u. Hardware możemy od razu wykluczyć, skoro problem występuje u tylu ludzi na tak różnym sprzęcie. 

Pozostaje kernel lub sterowniki. W wątku, który na górze podałem pojawiają się coraz to nowe informacje i rozwiązania (typu: wyłączanie mmx, przełączanie NVAGP na 2, etc.) Dla mnie najbardziej przekonująco brzmi hipoteza:

 *Quote:*   

> 
> 
> From discussion with the XOrg developers, the problem diagnosis is that it's a driver problem that causes such lockups. XOrg makes a function call to the driver (usually to paint something) and the driver errors and does not return, causing XOrg to loop continuously and consume CPU. 
> 
> 

 

Gdyby sterowniki NVIDI/ATI miały otwarty kod, to pewnie już dawno mielibyśmy ten problem rozwiązany.

----------

## mdk

 *Quote:*   

> 
> 
> Musze sie przyznać że mi to właśnie występuje, i nawet nie wiedziałem ze może być to winą przegladraki. Jednak ja bez przegladarki żyć nie moge, było by tro jak odciecie polowy reki. Jedno jest pewne problemem jest Gecko, bo raczej nie sama mozilla skoro wystepuje to w kilku mozillach.
> 
> 

 

To nie jest wina przeglądarki! Po prostu przeglądarka w jakiś sposób "wywołuje" ten błąd. Podobnie np. Gaim i operacja przełączania wirtualnych pulpitów. 

Żadna aplikacja w Linuksie nie ma prawa zawieśić jądra/systemu. Jeżeli coś takiego się dzieje, to znaczy, że problem leży po stronie kernela/sterowników lub hardware'u. Hardware możemy od razu wykluczyć, skoro problem występuje u tylu ludzi na tak różnym sprzęcie. 

Pozostaje kernel lub sterowniki. W wątku, który na górze podałem pojawiają się coraz to nowe informacje i rozwiązania (typu: wyłączanie mmx, przełączanie NVAGP na 2, etc.) Dla mnie najbardziej przekonująco brzmi hipoteza:

 *Quote:*   

> 
> 
> From discussion with the XOrg developers, the problem diagnosis is that it's a driver problem that causes such lockups. XOrg makes a function call to the driver (usually to paint something) and the driver errors and does not return, causing XOrg to loop continuously and consume CPU. 
> 
> 

 

Gdyby sterowniki NVIDI/ATI miały otwarty kod, to pewnie już dawno mielibyśmy ten problem rozwiązany.

----------

## Zwierzak

Pewnie na 90% winą można obarczyć stery binarne od ATi/NVIDI, tak do tąd robiłem i pewnie miałem racje. Pewnie twórcy coś tam skonocili a innym developerą trudno jest to naprawić. Ale z tego co przeczytałem to wynika że błąd występuje w przypadku aplikacji GTK. Nie wiem czy to ma coś związek czy to tylko moje błędne spostrzerzenie

----------

## mdk

 *Quote:*   

> 
> 
> Mi sie pojawialy ostatnio bardzo czesto szczegolnie jak probowalem odpalic cos z kde 3.4
> 
> 

 

Nie tylko przy aplikacjach GTK, chociaż zdaje się, że częściej. GTK korzysta agresywniej z RenderAccel. Ja z kolei zauważyłem, że po zwisie kursor myszy działa tylko w przypadku HW_CURSOR = true (sprzętowy kursor). Przy SW_CURSOR = true zwis jest "kompletny".

----------

## kuku

ja miałem takie cos jak używałem sterownika nv !!!! występowało w knoppixie i potem w gentoo - dopiero po zainstalowaniu sterów od nvidii przestało (6629 chyba) teraz mam  7167 i też sie zdarzyło

może nakierujecie mnie na jakieś howto jak to diagnozować bo ze zdalnym logowaniem niema problemu

i wiem że zalogowanie sie z innego komputera i ubicie X-ów pomogło, jeśli ktoś niema możliwości zdalnego logowania to może możnaby jakoś podłączyć skrypt ubijający X-y do guzika power na obudowie (w acpi chyba tak można)

----------

## tdi

nigdy nie mialem takiego cusia

uzywam grafiki intela, i testowalem na all xorgach i xfree jakie byly, kde, e17 xfce

----------

## mdk

 *Quote:*   

> 
> 
> i wiem że zalogowanie sie z innego komputera i ubicie X-ów pomogło, jeśli ktoś niema możliwości zdalnego logowania to może możnaby jakoś podłączyć skrypt ubijający X-y do guzika power na obudowie (w acpi chyba tak można)
> 
> 

 

Ciekawy pomysł. Ale lepiej - włączyć w kernelu opcję Kernel Hacking -> Kernel Debugging ->Magic SysReq Key. Potem, przy użyciu klawisza SysReq + kombinacja mamy dostęp do różnych ciekawych funkcji (to "pomija" driver klawiatury, X'y, etc. i powinno działać w każdej sytuacji, w której działa jeszcze kernel). Dostępne kombinacje:

```

(magic sysreq keys)

shift-scroll lock   memory information

ctrl-scroll lock   process listing

alt-sysreq-

0-9   set console log level

b   emergency reboot

e   kill all except init

i   kill all, incl. init

k   kill all programs on current console

l   kill all, hardlock

m   same as shift-scroll lock (memory info)

o   apm poweroff

p   show registers

r   set keyboard to XLATE

s   sync disks

t   same as ctrl-scroll lock (process list)

u   unmount all filesystems and change to readonly

```

----------

## tdi

madre nie wiedzialem o tym, dzieki przyda sie na bank !

----------

## joi_

kiedy miałem kernel 2.6.9 i sterowniki 6629 + włączone Composite, Render i RenderAccel działy się niesamowite cyrki: od wywracającego się na starcie konquerora czy kadu, po wywracający się w losowych momentach gcc (!) i make (!!), pamięć sprawdzałem memtestem (nic), procesor na pewno się nie przegrzewał (sprawdzałem później w biosie i temperatura była w normie)

co ciekawe, to te wywrotki szczególnie nasilały się po lub w trakcie używania mplayera / tvtime

obecnie mam kernel 2.6.11, sterowniki 7167 i takich cudów nie ma (choć Composite i sp. jeszcze nie włączałem), ale ze 2 czy 3 razy miałem takiego freeze'a jak opisujecie (firefoksa mam odpalonego prawie przez cały czas)

xorg 6.8.2, Athlon64 3200, GeForce FX 5200

----------

## kuku

a nie jest to może jakis problem z framebufferem ? 

tak mnie zastanowiło jak skonczyłem konfigurować kernela - a na 99% mialem vesafb-tng

nowego kernela jeszce nie skompilowalem ale wyłaczyłem RenderAccel i jest spokojnie a wczoraj miałem ze 4 zwisy Xów

----------

## Zwierzak

fb nie ma nic z tym wspólnego, wcześniej miałem starego fb (vega) i wieszało się mi wtedy, po zmianie na tng nadal jest to samo

----------

## grzewho

u mnie na 100% problem powodowany jest przez firefoxa, chociaż po skasowaniu .mozilla jakby wszystko nagle zaczęło działać

----------

## mdk

Chwilowo korzystam z ArchLinux, gdzie w tej samej konfiguracji sprzętowej + tych samych ustawieniach jądra problem nie występuje (jedyna róźnica - gentoo-dev-sources vs. vanilla-sources na archu). 

Przy ostatnim zwisie jaki miałem na Gentoo zauważyłem, że w Xorg.log pojawiają się jakieś podejrzane wpisy w momencie zwisu. Nie potrafię przywołać w tej chwili, ale można by napisać skrypt, który monitoruje Xorg.log np. raz na minutę, i jak pojawi się odpowiedni komunikat to zabija X'y.

----------

## keman

Heh, po wczorajszym, i dzisiejszym updacie systemu, dopiero dzis zrobiłem reboota, i x'y nie chciały wstać...

Pomyślałem, że moze zepusłem to jakos inaczej, bo eksperymentowałem z paatchami na jądro.

Jednak po rekompilacji jądra, z defaultowych źródełek, problem dalej występował.

po wpisaniu startx, system mrugał pare razy jak zwykle, a następnie, widziałem tylko biały znak zachety, mrugający na czarnym tle.

Kolejna rekompilacja nic niepomogła...

Zainstalowałem więc, wcześniej maskowane, nowe stery nvidi-7167, problem zniknął.

I co ciekawe, ruszam oknem Firefoxa, i żadnych błędów, ani zwiech.

Wydaje mi się, że problem zniknął....

Ale potestuje jeszcz, i za dobe dam znac :]

Pozdrawiam, waluigi

----------

## noobah

Może się dołączę do dyskusji.

Jakieś 2 lata temu początkowałem z linuxem na Mandrake i miałem podobny problem. Razem z jednym gościem śledziliśmy fora i wg naszych obserwacji zdarzały się podobne zwisy na chipsetach nforce. Tak czy inaczej znowu nVidia  :Very Happy: 

----------

## argasek

Przyznam się że ostatnio miałem tego typu lockup i stwierdziłem, że gdy będzie więcej czasu przyjrzę się temu. Kiedyś takie lockupy miałem bardzo często, było to jeszcze na Slackware, potem na Mandrake, miałem jednak wówczas kartę nVidii i sterowniki coś w okolicy serii 4xxx. Problem prawie na bank był wówczas spowodowany eksperymentalną wówczas (nie wiem jak jest z nią teraz) obsługą RenderAccel. Zwis wyglądał tak jak opisywany: tylko w X, kursor ruchomy, XMMS odtwarza (!), ale nie daje się ubić (wówczas jeszcze) XFree za pomocą Ctrl+Alt+Backspace.

Tym razem zestaw mam inny, tzn. sterowniki binarne ATi, KDE 3.4, jądro 2.6.13-gentoo, niestety moja płyta główna ma już swoje lata i jej sprawność pozostaje pod znakiem zapytania. Zadziwiająco, pod WinXP nie mam jakichś strasznych problemów, ale stosunek czasu jaki spędzam pod Win do tego pod Gentoo to jakieś 1/3 do 2/3, więc też ciężko o stuprocentowy obiektywizm.

Chciałem zaznaczyć, że cuda działy się na tych sterownikach w przypadku włączonej w BIOS opcji "AGP Fast Writes", jeśli ktoś ma problem ze sterownikami ATi, to proponuję wyłączyć to w 1. kolejności, jeśli ma się taką możliwość. Wzrost prędkości był w moim przypadku żaden, a problemów masa (również pod WinXP).

Chyba postawię to SSH   :Rolling Eyes: 

Aha, lockup zdarzył mi się na OpenGLowym wygaszaczu.

----------

## szolek

U mnie często to występowało z RenderAccel. Nie ważne czy samo compozite było włączone czy nie. Po mojej przesiadce na ck-sources też miałem problem z xorgiem, ale tu ewidentnie sam zawaliłem. Nie skonfigurowałem na nowo config jądra.

W tej chwili pracuje na ciągle najnowszych sterach z portage (~x86) bez RenderAccel. Nie mam tego problemu ale założę sie że jeśli włączę tą akcelerację to będzie deadlock.

----------

## Gabrys

Hej, ja mam Gentoo 2.6.13-r5, Xorg 6.8.2-r6, nVidia 1.0.6629-r4, grafikę geForce 4 MX440 128bit. X-y zamrażają się (z możliwością ruszania kursorem ofkoz -- mam HWCursor) około raz na miesiąc. Zwykle wtedy wyłączam kompa przyciskiem (przez ACPI) lub killuję X-y przez SSH. Rozszerzenia Composite nie używam, bo wtedy (przy włączonym kadu) po paru godzinach zyżucie procesora przeracza 50%. To tyle. Rozszerzam statystykę  :Very Happy: .

EDIT:

RenderAccel True (ale z tego co wyczytałem to jest domyślna wartość).

EDIT 2:

Poza Mozillą, niektórym osobom zamrażanie iksów na Ubuntu powoduje wysyłanie SMSów na Orange przez Kadu. Zwiecha następuje przy wyświetlaniu obrazka, z którego trzeba przepisać tekst, żeby wysłać SMS.

EDIT 3:

Nie zauważyłem przy jakich aplikacjach szczególnie mi się to wiesza, ale Ffx zawsze u mnie siedzi.

----------

## Yatmai

Sam miałem takie "zawiechy" gdy chciałem skonfigurować sobie Alpha Channel przez RenderAccel i Compisite (w sumie i tak poległem, bo sprzęt  odmówił współpracy   :Confused:   ) No ale wtedy stadnadrowo, drugi komp obok -> ssh -> killowanie Xów -> konfiguracja od nowa  :Smile: 

Tylko wtedy to był Debian Testing i mimo, że mam Linuchy na 3 kompach zdarzyło mi sie to tylko w tym jednym wypadku, ale to pewnie wina złego configa X'ów :]

----------

## Gabrys

Zupgrade'owałem sobie Xorga do 6.9-rc4, sterowniki nvidia do 8xxx-r1 i zmieniłem RenderAccel na False. Używam KDE 3.4 i Firefoksa 1.5. Nie zaliczyłem od tamtej pory żadnej zwiechy (oprócz całkowitego padu kernela raz (a potem zawsze kilka minut po uruchomieniu kompa) z niewiadomych przyczyn - zmieniłem kernela na 2.6.14-r5, trochę pozmieniałem konfigurację (powywalałem mnóstwo rzeczy), przekompilowałem i działa), choć może to być przypadek.

----------

## pax82

Nie przeczytalem wszystkich powzyszych postow, wiec moze to juz ktos powiedzial, mi sie zdarzaja takie sytuacje, ale zazwyczaj da sie przelaczyc na konsole CTRL+ALT+F1 i tam po prsotu robie killall -9 firefox (a moze w konqueror??) w kazdym badz razie na 100% wywoluje to jakas aplikacja. Co ciekawe myszka chodiz ale nie mozna ingerowac nie w zadna aplikacje, no i oczywisice reszta programow w tle tez dziala (widzialem zmieniajace se wykresy w gkrellm). Mi sie wydaje ze ktos cos spieprzyl z przechwytywaniem XEventow.

----------

## Gabrys

A mi się wydaję, że faktycznie NIE przeczytałeś tych paru postów. Klawiatura zostaje zablokowana. Ekran też przestają np. migać kropki w zegarze.

Jedyne co wydaje się rozsądne w takiej sytuacji, to skorzystać z SSH, przycisku power (który przy dobrze skonfigurowanym ACPI wyłączy kompa albo zakiluje X-y) bądź pilota (który przy dobrze skonfigurowanym LIRCu zrobi co przycisk power).

----------

## rzabcio

Dodam jeszcze swoje dwa slowa:

NIE MAM zainstalowanych sterów NVidii, w configu mam nv, system świeżutko zainstalowany, a problem wystąpil dwa razy. Wspolną aplikacją w obydwu przypadkach bylo Kadu i Eterm. Nie wlączalem Firefoxa więc to nie jego wina.

Po przeczytaniu wszystkich postów - suma sumarum: to zachowanie xorga jest kompletnie niedeterministyczne...

----------

## Gabrys

Ja znalazłem po części rozwiązanie. Jest nim temperatura na chipsecie. Zauważyłem, że jeszcze nigdy nie udało się zablokować X-owi zaraz po starcie, prawdopodobieństwo rośnie przy korzystaniu z OpenGLowych pełnoekranowych aplikacji i przy długim uptime'ie. Nie mam wiatraka na radiatorze mojego GeForce'a, a temperatura potrafi dojść do 60-70 st. na radiatorze (na dotyk, niestety nie mam żadnych termoaktywnych elementów na grafice). Może ktoś z wiatrakiem wyprowadzić mnie z błędu stwierdzając, że u niego też deadlock wystąpił mimo dobrego chłodzenia?

----------

## rzabcio

Przed chwila zaliczylem dwa deadlocki przy korzystaniu jedynie z czystego Fluxboxa (nawet bez torsmo), a w nim z Eterma, w ktorym instalowalem Jave. Czy mozliwe, by zagrzala mi sie karta? Nie sadze...   :Confused: 

----------

## Gabrys

jeśli korzystasz z czystego nv (jedzie prawie bez akceleracji), a wiadomo, że Eterm ma przeźroczystość, kompilacja lata dość szybko, to wszystko mogło Ci zagrzać chipset. Po każdej zwiesze dotknij chipsetu to się dowiemy  :Very Happy: . Jeśli będzie zimny (nie parzy, zaczyna parzyć od gdzieś 60 stopni, tyle jeszcze karta spokojnie wytrzymywać), to z jednej strony wiemy, że moja hipoteza jest błędna, ale z drugiej strony nadal nie wiemy co jest przyczyną.

----------

## rzabcio

Mój Eterm nie jest przezroczyszty - tzn w sensie, że nie mam wlączonego composite. Ale może się nie znam, uruchamiam Eterma po prostu przez

```
Eterm
```

Ale coś w tym jest bo faktycznie deadlock występuje przy wlączonym Etermie. Używalem wczoraj po ostatnim poście systemu normalnie (m.in. Kadu, Firefox) i jedynie zamiast Eterma korzystalem z xterma i deadlock nie wystąpil.[/post]

Także zwracam rację, Gabrys!  :Very Happy: 

----------

## Nomen

 *mdk wrote:*   

> 
> 
> Nie udało się znaleźć żadnej jednoznacznej przyczyny/rozwiązania tego problemu. Różnym ludziom pomagały (lub zmniejszały częstotliwość występowania) róźne rzeczy, np:
> 
> 1. Zmiana metalog na syslog
> ...

 

Miałem ten sam problem ,ale juz dawno o nim zapomniałem.

U mnie pomogło ustawienie w jadrze ilości pamięci o jeden mniej MB niż posiadam.

Tego Tipsa znalazłem wertując książeczki o Linie w Empiku.

Pomogło u mnie, u kumpla i u kumpla kumpla.    :Cool: 

Dajcie znać czy u was też.

----------

## Poe

hmm... mam nadzieje, ze taki "tps" pomoże ,bo rowniez ten problem u mnie wystepuje i potrafi naprawde duzo nabruździć w kompie, w pracy, nerwach i psychice...

----------

## argasek

 *Nomen wrote:*   

> U mnie pomogło ustawienie w jadrze ilości pamięci o jeden mniej MB niż posiadam.
> 
> Tego Tipsa znalazłem wertując książeczki o Linie w Empiku.

 

Czy to rozwiązanie dotyczy tylko kart nVidii?

----------

## Nomen

 *argasek wrote:*   

>  *Nomen wrote:*   U mnie pomogło ustawienie w jadrze ilości pamięci o jeden mniej MB niż posiadam.
> 
> Tego Tipsa znalazłem wertując książeczki o Linie w Empiku. 
> 
> Czy to rozwiązanie dotyczy tylko kart nVidii?

 

Może źle się wyraziłem. Chodzi o ilość RAMu -1 a nie pamięć na karcie.

A pomogło i na nvidi i na ati.

----------

## argasek

 *Nomen wrote:*   

>  *argasek wrote:*    *Nomen wrote:*   U mnie pomogło ustawienie w jadrze ilości pamięci o jeden mniej MB niż posiadam.
> 
> Tego Tipsa znalazłem wertując książeczki o Linie w Empiku. 
> 
> Czy to rozwiązanie dotyczy tylko kart nVidii? 
> ...

 

Jasne, nie mam wątpliwości co do tego że o RAM chodzi, co nie oznacza, że to nie może mieć związku z kartą graficzną (hint: pamięć karty graficznej jest mapowana na adresowalny obszar pamięci).

----------

## mirekm

Panowie spróbujcie czy problem będzie występował w przypadku, gdy uruchomicie system z parameterem:

```
noapic
```

Bo ja miałem identyczne objawy i zaobserwowałem następującą rzecz:

1. myszka i klawiatura działają (działanie klawiatury daje się zaobserwować tylko w przypadku, gdy otwarte jest okienko temrinala)

2. przestaje działać timer (irq0) - związane to jest z zablokowaniem się tego przerwania w APICu, w związku z czym wszystkie operacje zależne od czasu (opóźnienia) przestają działać.

3. przełączanie zadań w systemie realizowane jest dzięki istnieniu localtimerów przy procesor[ze,ach].

----------

## Gabrys

Tu jest ból, że nigdy do końca nie wiadomo kiedy problem wystąpi. Można czasem orzec, że przy danej operacji Deadlock wystąpił, ale nie sposób dowieść, że wyłączenie jakiejś tam opcji spowoduje zaprzestanie występowania problemu. Tutaj trzeba wytężonej i rozproszonej informacji od wielu ludzi. Wniosek: poczekasz sobie trochę na odpowiedź  :Wink: . Ja już dopisuję do swojego grub.confa kolejną opcję (po mem=511 czas na noapic).

----------

## (l)user

U mnie x.org zawsze dosc szybko zawiesza komputer podczas uzywania sterownika nv. Gdy uzywam sterownika nvidii nie ma tego problemu.

----------

## Nomen

 *Gabrys wrote:*   

> Tu jest ból, że nigdy do końca nie wiadomo kiedy problem wystąpi. Można czasem orzec, że przy danej operacji Deadlock wystąpił, ale nie sposób dowieść, że wyłączenie jakiejś tam opcji spowoduje zaprzestanie występowania problemu. Tutaj trzeba wytężonej i rozproszonej informacji od wielu ludzi. Wniosek: poczekasz sobie trochę na odpowiedź . Ja już dopisuję do swojego grub.confa kolejną opcję (po mem=511 czas na noapic).

 

Odpal 20-30 sesji mplayera i będziesz wiedział   :Very Happy: . Ja testowałem w ten sposób.

----------

## Nomen

Hmm 

Muszę się jeszcze podzielić jednym doświadczeniem.

Ostatnio spinaliśmy się z chłopakami ,żeby sobie pograć. Była ostra wymiana kart sieciowych graficznych i muzycznych ,żeby uzyskac podobne wydajnościowo sprzęty do grania bo niektórzy z chłopaków mieli słabsze maszyny. Po włożeniu tego wszystkiego z powrotem do mnie deadlocki powróciły. 

Pomogło tasowanie slotami PCI - zauważyłem ,że problem występuje u mnie jeśli karta TV jest na tym samym przerwaniu co muzyka bądź grafika. Teraz problem zniknął. 

Potasujcie slotami PCI ewentualnie jeśli jakiś sprzęt upiera się by być na tym samym przerwaniu co grafika ,zabłokujcie to przerwanie w biosie i dajcie reset ustawień PCI. 

Mam nadzieję ,że to komuś pomoże zanim go krew zaleje  :Smile: 

----------

## Bzyk

Odkopię wątek.

Chyba mam ten sam problem choć tak nie do końca. Mimo to podobny, więc może coś razem znajdziemy, bo to już ponad rok minął od ostatniego posta i ciągle brak ostatecznego rozwiązania.

Jeśli siedzę przy kompie i cokolwiek robię, to KDE działa perfekt, żadnych zwisów, ale niech no tylko zostawię komputer bez opieki (np. idę na fajkę) to na 80% mam zawieszenie Xorg'a (użycie CPU = 100%). Poruszanie myszą działa (ale kliknięcie na coś zawiesza mysz). Jeśli akurat ostatnio aktywna była konsola, to nie ma problemu z pisaniem w niej. Działa jak należy. Wciśnięcie 'ctrl+alt+backspace' powoduje chwilowe podwieszenie obrazu - zostaje np. ramka i tło konsoli ale już bez napisów na belce i w oknie, znika też kicker (mam KDE).

Zwiechy są niezależne od karty graficznej (próbowałem na nVidia GF4 MX Integrated oraz Radeon 9600 Pro) a także niezależne od użytych sterowników (próbowałem 'ati' i 'fglrx' oraz 'nv' ('nvidia' nie pozwalała nawet się Xorgowi uruchomić)) .

Jest też niezależne od dystrybucji (Kubuntu 6.10/7.04, Gentoo 2007.0) oraz od  Xorga (7.1.x, 7.2, 7.3)

Nie wiem czy jest zależne od slotów PCI - pojawiło się nagle jeszcze na Kubuntu 6.10 i na 100% nie ruszałem wnętrzności kompa, więc tasowanie kartami w slotach może pomóc ale na pewno nie to jest powodem.

DPMS, screensavery już wyłączałem i nic. Ciągle to samo. Już mnie to męczy, bo nie mogę odejść od kompa...  :Wink: 

Jeśli jest jakaś możliwość zapisania do logu działań Xorg czy jakichś innych to napiszcie jak. W dmesg nic nie ma a w Xorg.0.log właściwie nie wiem, bo jak zrestetuję kompa, to mam nowy plik Xorg.0.log. Zobaczę, czy da się przez SSH z PDA zalogować i zrobię kopię czy coś...

Jeśli to jednak nie ten sam problem, co wątek, to proszę o przeniesienie tego posta jako oddzielny wątek, bo walczę już bez efektów ponad pół roku.

Pozdrawiam

PS. Zapomniałem napisać jaki sprzęt.

 *Quote:*   

> 00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev a2)
> 
> 00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev a2)
> 
> 00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev a2)
> ...

 

uname -a

 *Quote:*   

> Linux ghost 2.6.22-gentoo-r2-custom #8 SMP PREEMPT Sat Aug 18 18:02:19 CEST 2007 i686 AMD Athlon(tm) XP 3000+ AuthenticAMD GNU/Linux

 

----------

## Yatmai

 *Quote:*   

> W dmesg nic nie ma a w Xorg.0.log właściwie nie wiem, bo jak zrestetuję kompa, to mam nowy plik Xorg.0.log

 

Wyłącz automatycze wstawanie X'ów przy starcie systemu i nie będzie tworzyć nowego pliku  :Smile: 

BTW tak jak to czytałem to coś mi zasugerowało jakiś błąd w hardware....  :Wink: 

----------

## Bzyk

Błąd w hardware? Hmm... Sprzęt był składany przeze mnie jakieś 5-6 lat temu i przez większość czasu działał na nim 'jedyny słuszny OS'. Działał zupełnie dobrze, żadnych niespodzianek (wręcz lepiej, bo WinMobile 5 do teraz nie potrafię zsynchronizować z Linuksem a z Windows to był 'piece of cake', podobnie z nagrywaniem dźwięku na SBLive a odtwarzanie przez zintegrowaną). Od roku działa na nim Linuks i tylko Linuks. Wpierw Kubuntu, od 3 miesięcy (około) Gentoo. I od czasu Kubuntu (po około 2 miesiącach od instalacji) mam zwisy Xorg'a.  Na próbę zainstalowałem którąś betę Visty (tę co była za free do pobrania z M$) i sieciówka nie działała ale zwisów nie było...

Podrzuć jakieś pomysły, jak wykryć ów sugerowany błąd hardware, jakimi narzędziami czy coś. Ozłocę Cię.  :Wink: 

Ostatecznie jeśli sądzisz, że to hardware, to może zacznę po trochu rozbierać kompa? W PCI mam w sumie tylko SBLive i kartę DVB-S (SkyStar2). Dysków nie mogę odłączyć (bo /home na innym) ale na upartego napędy CDROM nie problem. 

PS. Co do startowania bez X'ów to już zrobione. Zobaczymy. A nie powinien tego robić jakiś 'logrotate'?

PS2. A jeśli to coś w chipsecie nForce2, to co proponujesz dla tego Athlona (teraz mam Leadtek K7NCR)? I nie mów, że cały komp nowy, bo mi nie potrzebny szybszy (a jeśli już, to nie wcześniej niż będzie tańsze Core2Quad)  :Wink: 

----------

## Yatmai

Znaczy no tak mi się zasugerowało, co nie znaczy, że zaraz hw trza winić  :Wink:  Generalnie przepuszczenie pare razy memtesta, superpi czy 3d mark'a nie zaszkodzi  :Wink:  Ew. pomęczyć twardziela, przykładowy HDD Regenerator może go zmolestować bez utraty danych  :Smile: 

Inna rzecz, pisałeś, że jak sie bawisz to działa, a wiesza się jak sie nudzi - może gryzoń albo klawisze z nudów coś świrują  :Wink:  Wydawać się to może absurdalne, ale firma w której pracuje zajmuje się też serwisowaniem komputerów. Czasem pomagam kumplowi jak ma dużo maszynek do naprawy a ja się nudzę. Jak miał niedawno wypadek to przed 2 tygodnie musiałem go zastąpić i naprawde szczena nieraz opada jakie kompy potrafią cuda odstawiać  :Wink: 

PS2. tu Ci przyznam pełną rację ani pci-e ani ddr2 ani 64bit nie są warte przesiadania się, jedyne co mi się podoba po zmianie kompa to dwa rdzenie.... w Linuchu naprawdę wymiatają  :Wink: 

----------

## Bzyk

Wiesz, jesteś drugi, który mi sugeruje winę sprzętu, dlatego tak poważnie do tego podszedłem.

Co do 3Dmark albo SuperPI to nie widziałem na Linuksa. Memtest gdzieś mam na którymś LiveCD ale jak sam zauważyłeś, to raczej nie to, bo to tylko przy "nicnierobieniu" się dzieje...

Mysz odpada, bo mam trzeci model od czasu pierwszego pojawienia się problemu ale zastanawia mnie klawiatura (na USB z dwoma HUBami USB). Nie wiem dokładnie, kiedy mi żonka sprezentowała tę świetną klawiaturkę z niskoprofilowymi klawiszami (a'la notebook ale pełnowymiarowa) ale gdzieś chyba w tamtym okresie.   :Shocked:   Do tego dodam, że też mam cyrki z USB2.0 (moduł ehci_hcd). Od dwóch wersji jaja jest lepiej ale nie znaczy to, że jest dobrze... Właśnie wyładowałem ten moduł i zobaczę, czy się powiesi. Jeśli nie, to zablokuję ładowanie i potestuję (kilka dni bez USB2.0 mnie nie zbawi).

PS. Kupowanie dwóch rdzeni też nie dla mnie. Teraz mam 2.2GHz jeden rdzeń. Dokupując "drugi" rdzeń będę musiał nieźle się wykosztować, zmienić właściwie wszystko (oprócz DVD) a zysk? No zakładając, że kupię proc z 2.2GHz na rdzeń, to będzie raptem drugie tyle mocy... Czyli encodowanie, które teraz trwa całą noc (7 godzin), będzie trwało 3,5 albo bardziej pod 4, bo komunikacja międzyrdzeniowa też zdeczka czasu zabiera... Też mi zysk... Co innego Core2Quad. Tu już zaczyna być widoczna różnica - 7 godzin czy 2... Do tego drugie tyle RAM (teraz mam 1.25GB) i dyski w RAID0, jakaś niedroga grafa (i tak w nic nie gram) ale choć taka, żeby Beryl powodował zwisy... szczęk użytkowników Visty.  :Wink:  I to wszystko chłodzone cieczą (bloki na grzejące się czipy i dyski) i wolnoobrotowy wysysacz temperatury z obudowy... Ehhh... Rozmarzyłem się.  :Wink: 

----------

## Yatmai

Nie patrz na matmę  :Razz:  2 rdzenie = 1/2 czasu kompilacji.... Owszem ale nie w tym jest magia. Sens jest w tym gdy zapuszczasz kompilacje/ rozpakowywanie/ cokolwiek żrącego proca, bierze to 100% rdzenia, ale system działa na drugim przez co w ogóle kompa nie zamula  :Smile: 

----------

## c2p

 *Yatmai wrote:*   

>  *Quote:*   W dmesg nic nie ma a w Xorg.0.log właściwie nie wiem, bo jak zrestetuję kompa, to mam nowy plik Xorg.0.log 
> 
> Wyłącz automatycze wstawanie X'ów przy starcie systemu i nie będzie tworzyć nowego pliku 

 

Przecież podczas uruchamiania X'ów poprzedni log jest kopiowany do pliku Xorg.0.log.old.

----------

## Yatmai

Ty faktycznie, znów się dałem wkręcić  :Very Happy: 

Ostatnio na serwisie klient mi coś wspominał, że ma kabel podpięty do portu WAN w switchu.... Zdziwiłem się troche ale olałem, potem dopiero zajarzyłem, że jak wan to on tam ma router a nie switcha  :Very Happy: 

----------

## machiavelli

od jakiegoś czasu mam podobny problem, tyle że komp przestaje wogóle reagować, nawet na pingi nie odpowiada, dzieje się tak jak tylko włącze przeźroczystość w terminalu, to po jakimś czasie system robi stop klatkę i jedynie twardy reset go rusza. Jeżeli przeźroczystość jest wyłączona wszystko śmiga bez problemu, komp chodzi 24h non stop bez restartów po pare tygodni.

----------

## Bzyk

@machiavelli, to wygląda na to, że nie lubi przezroczystości. Stawiam na grafikę a raczej jej konfigurację i/lub sterowniki (bug?).

@Yatmai:

Mimo wyłączonego ehci_hcd po jakimś czasie nieużywania kompa znów 100% zużycia proca i Xorg w 'malinach'.

Końcówka Xorg.0.log.old wygląda tak:

```
(--) <default pointer>: PnP-detected protocol: "ExplorerPS/2"

(II) <default pointer>: ps2EnableDataReporting: succeeded

(II) RADEON(0): RADEONRestoreMemMapRegisters() :

(II) RADEON(0):   MC_FB_LOCATION   : 0xcfffc000

(II) RADEON(0):   MC_AGP_LOCATION  : 0xffffffc0
```

Wcześniej tylko niby normalny start X-ów (uruchomienie myszy, gdzie dwie ostatnie linijki masz też załączone powyżej).

Niestety nie jest to nic 'extra' bo bieżący log wygląda identycznie. Czyli żadnych błędów - normalny log, mimo wczorajszej zawieszki.

Chyba zaraz włączę "kernel hacking" choć nie wiem czego szukać... Masz jeszcze jakieś pomysły?

PS. Owszem, responsywność dwu rdzeni jest lepsza niż jednego, choć nie narzekam na moją (czego nie mogłem powiedzieć pod Window$). Mi raczej zależy na mocy obliczeniowej i podniesienie jej o niecałe 100% kosztem przynajmniej potrojenia wartości bieżącego kompa jest dla mnie osobiście absolutnie bezsensowna.  :Smile: 

----------

## Redhot

O, nie widziałem wcześniej tego tematu.

Na laptopie miałem po 3 godzinach nieużywania komputera 100% CPU i X-y zawieszone, SSHd działało, powodem było KDE >=3.5.6...

----------

## Bzyk

 *Redhot wrote:*   

> Na laptopie miałem po 3 godzinach nieużywania komputera 100% CPU i X-y zawieszone, SSHd działało, powodem było KDE >=3.5.6...

 

Hmm... To brzmi logicznie. Dziwne tylko, że tak mało osób to ma... Gdyby każdy używający KDE >=3.5.6 miał te zwisy, to tylko userzy Gentoo gałęzi 'stable' by ich nie mieli. ZTCW to jedynie PIM z KDE3.5.6 jest oznaczony jako 'unstable', z tego powodu całe KDE >=3.5.6 jest zamaskowane... Hmm... Wyłączam KOrganizer Remainder Daemon i zobaczymy co dalej.

----------

## Yatmai

Nie wiem czy to ma coś wspólnego, u mojej miłej X'y freezują całkowicie co jakiś czas przy Operze i zawsze przy Skype. Revdep-rebuild nic nie wskazał  :Wink: 

----------

## Bzyk

Nie używam ani Opery ani Skype, więc odpada.

Używam natomiast superkaramby a na bugs.kde.org znalazłem, że komuś pomogło... Warto spróbowac.

----------

