Desktop hängt, oder doch nicht?
Hallo! Ich kann seit einiger Zeit folgendes Phänomen beobachten: Wenn ich von der Konsole (egal welche) auf KDE (Strg+Alt+F7) umschalte, so ist dort der ganze Desktop "verwischt", also einige Icons werden nicht angezeigt und ich habe solche Querstreifen drinnen. Maus reagiert dann auch net. Wenn ich dann etwa drei bis fünf Sekunden warte, funzt wieder alles normal. Woran liegt das? Ich habe eine Grafikkarte mit NVIDIA-Chip, kein 3D aktiviert und die aktuellen NVIDIA-Treiber installiert (mit denen liefs am Besten). Gruß Jürgen
On Tuesday 25 March 2003 06:36, Jürgen Fahnenschreiber wrote:
Ich kann seit einiger Zeit folgendes Phänomen beobachten: Wenn ich von der Konsole (egal welche) auf KDE (Strg+Alt+F7) umschalte, so ist dort der ganze Desktop "verwischt", also einige Icons werden nicht angezeigt und ich habe solche Querstreifen drinnen. Maus reagiert dann auch net. Wenn ich dann etwa drei bis fünf Sekunden
Ich würde mal versuchen, den Interrupt der Graka zu ändern/zu reservieren. Sie kommt wahrscheinlich nicht durch die Initialisierung. -- Frieden ist Krieg, der woanders ist.
Am Dienstag, 25. März 2003 06:36 schrieb Jürgen Fahnenschreiber:
Ich kann seit einiger Zeit folgendes Phänomen beobachten: Wenn ich von der Konsole (egal welche) auf KDE (Strg+Alt+F7) umschalte, so ist dort der ganze Desktop "verwischt", also einige Icons werden nicht angezeigt und ich habe solche Querstreifen drinnen. Maus reagiert dann auch net. Wenn ich dann etwa drei bis fünf Sekunden warte, funzt wieder alles normal.
Hast Du die Konsole als Framebuffer oder im Textmodus laufen? Hier läuft sie im Textmodus und ich hab (glücklicherweise) keine Probleme mit dem Umschalten (nicht dass ich es oft machen würde).
Woran liegt das? Ich habe eine Grafikkarte mit NVIDIA-Chip, kein 3D aktiviert und die aktuellen NVIDIA-Treiber installiert (mit denen liefs am Besten).
Ansonsten Mail an NVidia. Bei einem Closed-Source Treiber ist es schwierig weiter zu helfen. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am Dienstag, 25. März 2003 12:19 schrieb Manfred Tremmel:
Am Dienstag, 25. März 2003 06:36 schrieb Jürgen Fahnenschreiber:
Ich kann seit einiger Zeit folgendes Phänomen beobachten: Wenn ich von der Konsole (egal welche) auf KDE (Strg+Alt+F7) umschalte, so ist dort der ganze Desktop "verwischt", also einige Icons werden nicht angezeigt und ich habe solche Querstreifen drinnen. Maus reagiert dann auch net. Wenn ich dann etwa drei bis fünf Sekunden warte, funzt wieder alles normal.
Hast Du die Konsole als Framebuffer oder im Textmodus laufen? Hier läuft sie im Textmodus und ich hab (glücklicherweise) keine Probleme mit dem Umschalten (nicht dass ich es oft machen würde).
Woran liegt das? Ich habe eine Grafikkarte mit NVIDIA-Chip, kein 3D aktiviert und die aktuellen NVIDIA-Treiber installiert (mit denen liefs am Besten).
Ansonsten Mail an NVidia. Bei einem Closed-Source Treiber ist es schwierig weiter zu helfen.
Manfred | http://www.knightsoft-net.de OK. Wie/ wo kann ich Framebuffer deaktivieren? Ich hab jetzt SuSE 8.2 und immer noch das gleiche Problem. Die NVIDIA -Treiber sind auch ganz neu.... Wie kann ich ggf. denn IRQ von der Grafikkarte (dauerhaft) wechseln)? Es ist eine GeForce2 MX400 Gruß,
Jürgen
Jürgen Fahnenschreiber wrote:
Wie/ wo kann ich Framebuffer deaktivieren?
das wird doch ueber den "vga=" Parameter im Bootloader gesetzt. Bei dir muesste das dann in /boot/grub/menu.lst geschehen, falls SuSE nicht wieder zu LILO zurueckgekehrt ist.
Wie kann ich ggf. denn IRQ von der Grafikkarte (dauerhaft) wechseln)? Es ist eine GeForce2 MX400
Mainboard umloeten. Ich hab noch nie ein BIOS gesehen, in dem man den IRQ vom AGP einstellen kann. Peter
Hi, Peter Wiersig wrote:
Wie kann ich ggf. denn IRQ von der Grafikkarte (dauerhaft) wechseln)? Es ist eine GeForce2 MX400
Mainboard umloeten.
:).
Ich hab noch nie ein BIOS gesehen, in dem man den IRQ vom AGP einstellen kann.
ACK, aber häufig teilen sich der erste PCI Platz und der AGP einen IRQ und bei Konfilkten kann es helfen einfach diesen Platz unbelegt zu lassen (näheres man MB-Handbuch) -- - maik
Maik Holtkamp wrote:
Peter Wiersig wrote:
Ich hab noch nie ein BIOS gesehen, in dem man den IRQ vom AGP einstellen kann.
ACK, aber häufig teilen sich der erste PCI Platz und der AGP einen IRQ und bei Konfilkten kann es helfen einfach diesen Platz unbelegt zu lassen (näheres man MB-Handbuch)
Waere einen Versuch wert. Ich persoenlich bezweifele aber immer noch, das bei PCI/AGP ein IRQ-Konflikt auftreten kann. Ich weiss, das es bei ISA-Bus-Systemen solche Konflikte gab, aber bei PCI ist es nicht mehr der Fall. Anderenfalls haette man nur die Moeglichkeit 4 Geraete mit den Steckkarten zu betreiben, da im Steckplatz nur 4 Leitungen fuer Interrupts vorhanden sind. Interne Geraete wie USB und Sound belegen ebenfalls diese Leitungen. Meine NVidia-Karte zickt auch oft rum, und selbst meine Matrox G200 ueberlebt den Wechsel von der Konsole in den KDM nicht. (In einen KDE-Desktop eigentlich immer.) Peter
Hi, Peter Wiersig wrote:
Maik Holtkamp wrote:
Peter Wiersig wrote:
Ich hab noch nie ein BIOS gesehen, in dem man den IRQ vom AGP einstellen kann.
ACK, aber häufig teilen sich der erste PCI Platz und der AGP einen IRQ und bei Konfilkten kann es helfen einfach diesen Platz unbelegt zu lassen (näheres man MB-Handbuch)
Waere einen Versuch wert.
Ich persoenlich bezweifele aber immer noch, das bei PCI/AGP ein IRQ-Konflikt auftreten kann. Ich weiss, das es bei ISA-Bus-Systemen solche Konflikte gab, aber bei PCI ist es nicht mehr der Fall.
Ich persönlich hatte diese Proleme bei A7V-133, GF2MX und SB live (u.a. im ersten Platz). Nach einer excessiven google Nacht wundert man sich dann, dass diese Komponenten überhaupt zusammen spielen konnten ;). Es liegt wohl daran, dass die SB-live kein vernüftiges PCI-sharing kann und der via chipsatz an und für sich _scheisse_ (sorry, aber IMHO passenste Bezeichnung) ist. Wenn dann noch die Dauerbaustelle ide zusätzliche Probleme schafft, verwechselt man schon mal Ursache und Wirkung und man kehrt reuhemütig in der nächsten Nacht zur guten alten try&error Methode zurück :(. -- - maik
Maik Holtkamp wrote:
Ich persönlich hatte diese Proleme bei A7V-133, GF2MX und SB live (u.a. im ersten Platz). Nach einer excessiven google Nacht wundert man sich dann, dass diese Komponenten überhaupt zusammen spielen konnten ;).
Laeuft hier einwandfrei - man muss nur vorher das Motherboard-Manual lesen und das IRQ Sharing der PCI Slots beachten... Nur gibt es leider sehr vie- le Leute, die gleich mal installieren und das Hand- buch aussen vor lassen. Das raecht sich dann eben in so einem Falle.
Es liegt wohl daran, dass die SB-live kein vernüftiges PCI-sharing kann und der via chipsatz an und für sich _scheisse_ (sorry, aber IMHO passenste Bezeichnung) ist.
Naja, ich bin zufrieden damit. Besser als ein Ali Chipsatz jedenfalls ;-)
[...] in der nächsten Nacht zur guten alten try&error Methode zurück :(.
Es heisst "trial and error", nicht "try and error". Gruesse, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
Hi, Thomas Hertweck wrote:
Maik Holtkamp wrote:
Es liegt wohl daran, dass die SB-live kein vernüftiges PCI-sharing kann und der via chipsatz an und für sich _scheisse_ (sorry, aber IMHO passenste Bezeichnung) ist.
Naja, ich bin zufrieden damit. Besser als ein Ali Chipsatz jedenfalls ;-)
Ali kenne ich nicht, ich würde jedenfalls von VIA die Finger lassen: http://groups.google.com/groups?hl=de&lr=&ie=UTF-8&threadm=bakg2b.3lv.ln%40ID-4496.user.dfncis.de&rnum=1&prev=/groups%3Fq%3DMaik%2BHoltkamp%2Bgroup:de.comp.hardware.cpu%252Bmainboard.amd%26hl%3Dde%26lr%3D%26ie%3DUTF-8%26selm%3Dbakg2b.3lv.ln%2540ID-4496.user.dfncis.de%26rnum%3D1 (sorry, wegen langer Zeile) Wenn mein board/chipsatz Hersteller Versprechungen macht, die er nicht halten kann und das Aufrüsten des Rechners zum Lotteriespiel wird, wende ich mich dankend ab. Ich glaube nicht das ASUS hier das Übel ist (die in obigem link genannten Erkenntnisse dauerten dabei deutlich länger als 1-2 Nächte :().
in der nächsten Nacht zur guten alten try&error Methode zurück :(.
Es heisst "trial and error", nicht "try and error".
Ja, danke. -- - maik
Maik Holtkamp wrote:
[...] Ali kenne ich nicht, ich würde jedenfalls von VIA die Finger lassen: [...] Wenn mein board/chipsatz Hersteller Versprechungen macht, die er nicht halten kann und das Aufrüsten des Rechners zum Lotteriespiel wird, wende ich mich dankend ab.
Ach, ist das bei anderen Herstellern anders? Da habe ich aber auch so manche Erfahrung ge- macht. Hardware fuer die Zukunft kaufen, um spaeter dann vielleicht mal aufruesten zu koennen, ist eh eine aussichtslose Geschichte. VIA war lange Zeit die einzige Alternative zu Intel, und so ein bisschen Konkurrenz kann IMHO nicht schaden. Ich jedenfalls bin mit meinem Asus A7V-133 mit VIA Chipsatz ziemlich zufrieden... Cu, Th. -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
Hi, Thomas Hertweck wrote:
Maik Holtkamp wrote:
[...] Ali kenne ich nicht, ich würde jedenfalls von VIA die Finger lassen: [...] Wenn mein board/chipsatz Hersteller Versprechungen macht, die er nicht halten kann und das Aufrüsten des Rechners zum Lotteriespiel wird, wende ich mich dankend ab.
Ach, ist das bei anderen Herstellern anders?
Unter anderem aus dem Aufrüstgrund kaufe ich normalerweise Asus boards. Es ist IMHO ein recht zuverlässiger Hersteller. Aufrüstoptionen (Bios updates etc.) gibt es hier IMHO etwas länger als bei anderen. Was mich madig gemacht hat war das Asus auf seiner Webseite ausdrücklich darauf hinweist, dass es mit meiner Boardrevision und entsprechendem Bios geht. - Bei mir ging es aber nicht. Wenn das board von Firma xy gewesen wäre, die diese Behauptung aufgestellt hätte, hätten die bestimmt nicht sowiel Vertrauensvorschuss von mir bekommen, nach dem Motto: "Wenn Asus das sagt, kann das Problem ja nur bei Dir liegen." Dieser Einstellung habe ich so mache Nacht geopfert. Vergeblich :(.
Da habe ich aber auch so manche Erfahrung ge- macht. Hardware fuer die Zukunft kaufen, um spaeter dann vielleicht mal aufruesten zu koennen, ist eh eine aussichtslose Geschichte.
Na, ja ich mache rel. viel video Bearbeitung und da spielt eigentlich nur der Prozeßor-Speed eine Rolle. Die Aufrüstung vom Duron 800 auf Athlon 1400 hat den speed beim s(vcd) codieren fast verdoppelt: 3-4fps:6-7fps oder 90min Material = 7 Stunden:4 Stunden Das ist schon ein Unterschied, besonders wenn man nach dem job erkennen muss, dass man was entscheidenes vergessen hat und nochmal von vorne beginnt ;). Als ich günstig einen 1900erter im Tausch angeboten bekam (Kiste Bier/Flasche Schnaps;)), wollte ich nochmal aufrüsten.
VIA war lange Zeit die einzige Alternative zu Intel, und so ein bisschen Konkurrenz kann IMHO nicht schaden.
FULLACK, aber: Ich habe während die Probleme bestanden, rel. viel gewühlt und wenn man sich die Infos so anschaut (insbesondere die Homepage von memtest86 IIRC), ist AMD etwas problematischer. - Was mich _nicht_ zu Intel treibt.
Ich jedenfalls bin mit meinem Asus A7V-133 mit VIA Chipsatz ziemlich zufrieden...
Ich nicht. Lotterie halt ;). -- - maik
Maik Holtkamp wrote:
Es liegt wohl daran, dass die SB-live kein vernüftiges PCI-sharing kann und der via chipsatz an und für sich _scheisse_ (sorry, aber IMHO passenste Bezeichnung) ist.
Ja, diese Kombination macht Probleme bei PCI Busmastering. Ohne die Kombination (Oder anstelle der SBLive ne TV-Karte) hab ich mit dem Chipsatz selbst wenig Probleme. Ich hab mich schon vor langer Zeit gegen Creative-Produkte entschieden. Alleine, das man nicht nur Treiber ziehen konnte hat mich in meinen ISDN-Zeiten von dieser Marke weit weggebracht. Peter
participants (6)
-
Jens Haase -
Jürgen Fahnenschreiber -
Maik Holtkamp -
Manfred Tremmel -
Peter Wiersig -
Thomas Hertweck