Polskie Forum Użytkowników Debiana

Witam wszystkich z nowego sprzętu

Ale do rzeczy. Mam zainstalowane sterowniki zamknięte nvidii najnowsze. Czy te z paczek są "takie same"? Wydajność ta sama? Jak to jest?

Co do sedna sprawy: ciągle wywala mi się GDM. Oto /var/log/syslog w chwili wywalenia się GDM (a raczej całych x'ów):

Mar 17 18:40:00 debian gconfd (kaka-5529): Otrzymano sygnał 15, poprawne zakończenie
Mar 17 18:40:00 debian gconfd (kaka-5529): Zakończenie
Mar 17 18:40:00 debian gdm[5106]: Error reinitilizing server

Oczywiście googleiłem i znalazłem parę rzeczy, jednak:

a) aptitude reinstall gdm nie poprawia stanu rzeczy,
b) aptitude purge gdm && aptitude install gdm także nic nie poprawia,
c) dpkg-reconfigure gdm znowu nic nie daje,
d) dpkg-reconfigure gdm i wybieram kdm, to samo,
e) ponowna instalacja sterowników zamkniętych od nvidii nie zmienia sprawy (więc może z paczek?).

Więcej pomysłów nie mam. Trafiłem przypadkowo na jedną stronkę gdzie pisało, że to jest bug, jednak nie mogę teraz znaleźć takowej strony. Ma ktoś jakieś pomysły?

Z góry bardzo dziękuję za odpowiedź.
Pozdrawiam.

Witam,

1. Czy system jest postawiony na dysku SATA ?
2. Jaki chipset płyty głównej ?

Moje doświadczenia (Abit VT7 VIA pt880, Intel 3.0 HT, 2 dyski: 1x ATA, 1xSATA, MBR na dysku ATA)

1. Sarge (2.4) na HDD ATA 200GB - bez problemu
2. Ubuntu na ATA bez problemu.
3. Etch na SATA wywalanie X. Przy logowaniu lub zaraz po zalogowaniu, albo nie dochodziło do logowania.

Mała roszada:

4. Ubuntu na SATA - oczywiście od razu problemy z wysypywaniem X.
5. Etch na ATA - wszystko bez problemu.

Wnioski:

Aby w/w systemy mogły w moim przypadku być na SATA musiałem wyłączyć ACPI. (acpi=off w /boot/grub/menu.list)
Nic innego tutaj nie pomagało. Mam też wrażenie że Etch na SATA wolniejszy jest i to odczuwalnie od instalacji na ATA. (Długie ładowanie stron www, itd)
Ponieważ lubuję się w sprzęcie, przetestowałem w/w sytuacje na płycie GigaByte nForce4 i problem był podobny.

RZ.

Rado pisze:1. Czy system jest postawiony na dysku SATA ?

Tak SATAII - dysk WD 160 GiB.

Rado pisze:2. Jaki chipset płyty głównej ?

Moja płyta główna: Nvidia nForce 550 Gigabyte.

Rado pisze:1. Sarge (2.4) na HDD ATA 200GB - bez problemu
2. Ubuntu na ATA bez problemu.
3. Etch na SATA wywalanie X. Przy logowaniu lub zaraz po zalogowaniu, albo nie dochodziło do logowania.

Zauważ, że nie mam Etch'a lecz Sid'a, ale to dużej różnicy nie robi.

Rado pisze:Aby w/w systemy mogły w moim przypadku być na SATA musiałem wyłączyć ACPI. (acpi=off w /boot/grub/menu.list)

No spróbuję tego, dzięki

Witam.

Ciekawi mnie ten temat strasznie, bo szukam alternarywnego rozwiązania. Dodam też, że ów problem mają także urzytkownicy Fedory, Mandrivy i Gentoo, dlatego będzie to prawdopodobnie problem Kernela. Generalnie wszyscy obwiniają stery grafy za to (tak jak ja kiedyś tez tutaj obwiniałem Nvidie) i mordują się na okrągło ze sterownikami. W większości posty te pozostają NOT SOLVED.

RZ

acpi=off nie pomaga.

Odinstalowałem najnowsze sterowniki nvidii i zainstalowałem sterowniki z paczek (87.76). Są to zarazem starsze sterowniki. No i też się wywala. Znalazłem na google że na sterownikach 7x.xx wszystko jest ok, ale to są już dość stare sterowniki, więc nie wiem czy jest sens je instalować.

Odinstalowałem kdm i gdm i loguję się z konsoli, jednakże nic to nie daje - dalej mnie wywala. No normalnie nie wiem co jest, google i google i nic.

Jakieś propozycje ktoś ma?

A testowałeś sprawe na innych WM? Czy na każdym Cię wywala? Może jakieś GNOME czy cuś ;p

Spróbuj wywalić cały konfig gconf'a ~/.gconf ~/gconfd i inne.

draco pisze:A testowałeś sprawe na innych WM? Czy na każdym Cię wywala? Może jakieś GNOME czy cuś ]

Testowałem chwilę na GNOME, ale jego wygląd mnie przeraża więc zrezygnowałem

Graboś pisze:Spróbuj wywalić cały konfig gconf'a ~/.gconf ~/gconfd i inne.
To chyba nie jest wina gconf. Dlaczego? Otóż dzisiaj cały dzień nie odpalałem beryla - ani jednego wywalenia x'ów (Sic!). A w /var/log/syslog widzę:

Mar 20 17:48:34 debian gconfd (kaka-3893): uruchamianie (wersja 2.16.1), pid 3893, użytkownik "kaka"
Mar 20 17:48:34 debian gconfd (kaka-3893): Uzyskano adres "xml:readonly:/etc/gconf/gconf.xml.mandatory" do źródła konfiguracji tylko do odczytu na pozycji 0
Mar 20 17:48:34 debian gconfd (kaka-3893): Uzyskano adres "xml:readwrite:/home/kaka/.gconf" do zapisywalnego źródła konfiguracji na pozycji 1
Mar 20 17:48:34 debian gconfd (kaka-3893): Uzyskano adres "xml:readonly:/etc/gconf/gconf.xml.defaults" do źródła konfiguracji tylko do odczytu na pozycji 2
Mar 20 17:48:34 debian gconfd (kaka-3893): Uzyskano adres "xml:readonly:/var/lib/gconf/debian.defaults" do źródła konfiguracji tylko do odczytu na pozycji 3
Mar 20 17:48:34 debian gconfd (kaka-3893): Uzyskano adres "xml:readonly:/var/lib/gconf/defaults" do źródła konfiguracji tylko do odczytu na pozycji 4
Mar 20 17:54:34 debian gconfd (kaka-3893): Serwer GConf nie jest używany, zakończenie.
Mar 20 17:54:34 debian gconfd (kaka-3893): Zakończenie
Mar 20 17:55:01 debian gconfd (kaka-3980): uruchamianie (wersja 2.16.1), pid 3980, użytkownik "kaka"
Mar 20 17:55:01 debian gconfd (kaka-3980): Uzyskano adres "xml:readonly:/etc/gconf/gconf.xml.mandatory" do źródła konfiguracji tylko do odczytu na pozycji 0
Mar 20 17:55:01 debian gconfd (kaka-3980): Uzyskano adres "xml:readwrite:/home/kaka/.gconf" do zapisywalnego źródła konfiguracji na pozycji 1
Mar 20 17:55:01 debian gconfd (kaka-3980): Uzyskano adres "xml:readonly:/etc/gconf/gconf.xml.defaults" do źródła konfiguracji tylko do odczytu na pozycji 2
Mar 20 17:55:01 debian gconfd (kaka-3980): Uzyskano adres "xml:readonly:/var/lib/gconf/debian.defaults" do źródła konfiguracji tylko do odczytu na pozycji 3
Mar 20 17:55:01 debian gconfd (kaka-3980): Uzyskano adres "xml:readonly:/var/lib/gconf/defaults" do źródła konfiguracji tylko do odczytu na pozycji 4

Czyli mogę pokusić się o stwierdzenie, że nie jest to wina gconf.

Nie jest to także wina KDM/GDM - jak je wyłączyłem i logowałem się z konsoli, to też mnie wywalało.

Wina sterowników też to nie jest, ale... Natknąłem się na informację, że może być to wina kernela. I tu mnie dręczy. Bo wina beryla to też raczej nie jest, mimo, że mnie wywala gdy go odpalę, ponieważ dużo osób ma ten problem, nawet nie używając beryla, czy compiza (akurat tego drugiego nie próbowałem). Zakładając jednak, że jest to wina kernela, to cóż mam zrobić? Samodzielna kompilacja? Nie mam czasu, chyba, że w święta, kiedy będzie wolne.

Mam jeszcze pytanie. Instalowałem sterowniki nvidii, instalatorem (to znaczy ściągnąłem plik ze strony nvidii) w init 1, kiedy instalator wyraźnie mówi, że nie zaleca w init 1 bo mogą wystąpić problemy z kernelem. Ale podobno te uwagi instalatora można olać. hmm, jak Wy robicie? Instalujecie także to w init 1?

I jeszcze jedna sprawa. Sam instalator pyta się czy pobrać jakieś pliki (jak dobrze pamiętam coś do kernela) z download.nvidia.com (bodajże!) - dałem No - a Wy? Może powinienem dać Yes? Jak uważacie?

Pozdrawiam.

Ehh... KDE ssie, ale olać to :>

Ja instaluję sterowniki w sposób nastepujący:
Zakładam, że headersy już masz i korzystasz z gdm'a...

Przełączam się na konsolę: ctrl+alt+f2

Loguję się jako root

Wpisuję:

Kod: Zaznacz cały

/etc/init.d/gdm stop

Przechodzę do katalogu ze sterownikiem

Wklepuję:

Kod: Zaznacz cały

sh NV*.run

Postępuję zgodnie z kolejnymi ekranami.

Ja osobiście tylko za pierwszym razem pozwoliłem zmodyfikować konfig X'a instalatoraowi, przy upgrejdach juz mu nie pozwalam.

Wpisuję:

Kod: Zaznacz cały

/etc/init.d/gdm start

Ciesze się stabilną akceleracją 3D xD.

Po drodze wywala jednego error'a, ale jest on związany z jednym - w praktyce jak widać - nie istotnym dowiązaniem.

Niezaleznie od tego co klikniesz instalator prawdopodobnie i tak nic nie ściągnie. Nie ma to wplywu w moim przypadku na nic.

GDM można zastąpić KDM w zależności kto z czego korzysta.

Polskie Forum Użytkowników Debiana

[SOLVED] Wywalanie si

[SOLVED] Wywalanie się GDM'a (yakuake)