Fedora 13: Compositing funktioniert plötzlich nicht mehr

[mj]

Wir haben in der Firma ein paar Lenovo Ideapad U350 mit Fedora 13 / KDE4. Bei allen (!) hat gestern gleichzeitig das Compositing aufgehört zu funktionieren, ohne, dass irgendwelche Updates eingespielt oder sonstige Änderungen vorgenommen wurden. Auf einen Schlag war das Compositing deaktiviert und lässt sich auch nicht mehr aktivieren. Die Laptops sind sämtlich stock Fedora 13 von der DVD, es wurde kein einziges Update eingespielt. glxinfo ist davon überzeugt, dass direct rendering nicht mehr unterstützt sei, obwohl es wie gesagt bis gestern auf allen einwandfrei funktioniert hat.

martin/nmartin$ glxinfo | grep render
Xlib: extension "NV-GLX" missing on display ":0.0".
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset GEM 20100328 2010Q1

Versuche ich Compositing in den Systemeinstellungen von KDE4 zu aktivieren, kommt folgende Fehlermeldung:

Deaktiviere ich die Funktionsprüfung, kommt ein verschobenes und auf dem Kopf stehendes Bild:


Die Systeme sind alle identisch, Klone vom Master den ich hier am Schreibtisch habe. Woher die Fehlermeldung in Bezug auf NV kommt ist mir nicht klar, könnte allerdings daher stammen, dass das ursprüngliche Master-System ein T510 mit Nvidia-Karte war. Um das System auf dem U350 lauffähig zu machen war es lediglich nötig den Nvidia-Treiber zu deinstallieren und KMS wieder zu aktivieren.

Die komplette Ausgabe von glxinfo mit aktiviertem LIBGL_DEBUG=verbose:

root/nmartin$ LIBGL_DEBUG=verbose glxinfo
name of display: :0.0
Xlib: extension "NV-GLX" missing on display ":0.0".
display: :0 screen: 0
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGIX_visual_select_group, GLX_INTEL_swap_event
client glx vendor string: NVIDIA Corporation
client glx version string: 1.4
client glx extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info,
GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync,
GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGI_swap_control, GLX_EXT_swap_control, GLX_ARB_create_context,
GLX_ARB_create_context_profile, GLX_NV_float_buffer,
GLX_ARB_fbconfig_float, GLX_EXT_fbconfig_packed_float,
GLX_EXT_texture_from_pixmap, GLX_EXT_framebuffer_sRGB,
GLX_NV_present_video, GLX_NV_copy_image, GLX_NV_multisample_coverage,
GLX_NV_video_capture
GLX version: 1.4
GLX extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGI_swap_control,
GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_ARB_get_proc_address
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset GEM 20100328 2010Q1
OpenGL version string: 1.4 (2.1 Mesa 7.8.1)
OpenGL extensions:
GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program,
GL_ARB_fragment_program_shadow, GL_ARB_multisample, GL_ARB_multitexture,
GL_ARB_occlusion_query, GL_ARB_point_parameters, GL_ARB_point_sprite,
GL_ARB_shadow, GL_ARB_texture_border_clamp, GL_ARB_texture_compression,
GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar,
GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat,
GL_ARB_texture_non_power_of_two, GL_ARB_vertex_program, GL_ARB_window_pos,
GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_draw_range_elements,
GL_EXT_framebuffer_object, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays,
GL_EXT_packed_pixels, GL_EXT_rescale_normal, GL_EXT_secondary_color,
GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap,
GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias,
GL_EXT_texture_object, GL_EXT_vertex_array,
GL_IBM_texture_mirrored_repeat, GL_NV_blend_square, GL_NV_depth_clamp,
GL_NV_light_max_exponent, GL_NV_texture_env_combine4,
GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program1_1,
GL_SGIS_generate_mipmap, GL_SGIS_texture_lod

Aber:

root/nmartin$ grep glx /var/log/Xorg.0.log
[ 26.271] (II) LoadModule: "glx"
[ 26.272] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
[ 26.325] (II) Module glx: vendor="X.Org Foundation"
[ 26.377] (==) AIGLX enabled
[ 26.377] (II) Loading extension GLX
[ 27.163] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[ 27.163] (II) AIGLX: enabled GLX_INTEL_swap_event
[ 27.163] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[ 27.163] (II) AIGLX: enabled GLX_SGI_make_current_read
[ 27.163] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[ 27.163] (II) AIGLX: Loaded and initialized /usr/lib64/dri/i965_dri.so
[ 27.163] (II) GLX: Initialized DRI2 GL provider for screen 0

Ich bin mittlerweile ehrlich gesagt ziemlich ratlos, vor allem da es zeitgleich auf allen Modellen aufgetreten ist

 

[Desti]

Warum aktualisiert du das System nicht mal?

 

[mj]

Was sollte das bitte bringen, wenn es doch bis vorgestern auf allen funktioniert hat und erst seit gestern auf allen nicht mehr funktioniert

Es handelt sich hier um Firmenlaptops, da werd ich den Teufel tun und blind alle Patches und Updates einspielen, oder gar das Autoupdate schalten und walten lassen. Das gibt nur Ärger. Gegen punktuelle Updates habe ich nichts, aber ein pauschaler Rundumschlag ist kategorisch ausgeschlossen, danach funktioniert nämlich erstmal gar nichts mehr.

 

[Berniyh]

Überprüfe doch mal, ob der nvidia Treiber wirklich komplett entfernt wurde, also vor allem inkl. Kernel Modul.

Dann überprüfe, ob KMS noch läuft (dmesg), oder ob es da Fehlermeldungen gibt.

Prinzipiell würde ich mal diese Schritte empfehlen:
1. Deinstallation aller(!) Komponenten des nvidia Murks
2. Reinstallation des Intel Treibers (falls es noch nicht funktioniert)
3. Überprüfen ob evtl. notwendige Firmware fehlt (weiß nicht auswending, ob die Intel Treiber welche brauchen)
4. Sicherstellen, dass KMS funktioniert

 

[Tom24]

Xlib: extension "NV-GLX" missing on display ":0.0".

client glx vendor string: NVIDIA Corporation

Warum möchte er das?

 

[mj]

Da waren tatsächlich noch ein paar Nvidia-Dateien vorhanden, obwohl ich den Treiber über den nvidia-installer wieder deinstalliert hatte. Nachdem ich die Dateien gelöscht habe (libnvidia-glcore, libnidia-tls) startet der ksmserver nicht mehr sondern meckert, dass die Dateien nicht gefunden werden können. Leider finde ich nirgends einen Hinweis darauf an welcher Stelle sie geladen werden, daher spiele ich jetzt wieder das originale Image zurück und fang noch mal von vorne an.

 

[Lynxeye]

Der NVidia Treiber überschreibt einige .so des XServers. Diese kommen auch bei der Deinstallation nicht wieder. Du musst also das Paket des XServers neu installieren, um die Zerstörung, welche der NVidia Treiber hinterlässt, zu beseitigen.

 

[Berniyh]

Der NVidia Treiber überschreibt einige .so des XServers. Diese kommen auch bei der Deinstallation nicht wieder. Du musst also das Paket des XServers neu installieren, um die Zerstörung, welche der NVidia Treiber hinterlässt, zu beseitigen.

Wenn das so wäre, dann wären die Maintainer von XServer bzw. Nvidia Treiber auf Fedora entweder inkompetent oder unterbelichtet, insofern bezweifle ich das.

Außer natürlich der Nvidia Treiber wurde manuell installiert, in dem Fall würde das aber auch auf den Admin zutreffen.

 

[Nero24]

Jetzt mal ganz auf blöd: wenn bei mehreren Systemen das absolut gleiche plötzlich von jetzt auf gleich nicht mehr funktioniert, ohne dass was daran gemacht worden ist, könnte es ja auch irgendein Bug mit einer Zeitangabe sein. Hatte das bei einem (Cisco ) Access Point Typ mal, der bei mehreren Kunden am selben Tag angefangen hat zu spinnen. Was hab ich nicht alles probiert. Am Ende hab ich das interne Datum des AP von 2010 auf 2007 zurückgesetzt und siehe da: alles lief wieder wie am schnürchen. Da ist in der Firmware wohl bei irgendeiner Funktion, die auf einen Timestamp zugreift, ab einem gewissen Wert was schiefgelaufen. Vielleicht ist das ja auch hier so? Würde ich schon mal probieren. Eine Lösung wäre es zwar bei Laptops (im Gegensatz zu einem AP) auch nicht einfach das Datum zurückzusetzen, aber zumindest wüsstest Du schon mal was Sache ist

 

[SnakePlisken]

Nicht, dass Ihr denkt, auf meinem Netbook wär ständig Kraut und Rüben. Beim Kernelbacken, mit Hilfe des dpkg-Paketsystems bekam ich am Ende immer die Meldung:


Worauf ich anfangs dann den Vorschlag mit dem Paket nvidia-common durchgeführt hatte, und später dann ignoriert. Nachdem ich beim x-ten mal immer noch die Meldung bekam hab ich heut mal genauer geschaut:

root@beimir:/usr/src# dpkg -l | grep 'nvidia'
ii  nvidia-173-modaliases                  173.14.22-0ubuntu11                             Modaliases for the NVIDIA binary X.Org drive
ii  nvidia-185-modaliases                  195.36.24-0ubuntu1~10.04                        Transitional package for nvidia-185-modalias
ii  nvidia-96-modaliases                   96.43.17-0ubuntu1                               Modaliases for the NVIDIA binary X.Org drive
ii  nvidia-common                          0.2.23                                          Find obsolete NVIDIA drivers
ii  nvidia-current-modaliases              195.36.24-0ubuntu1~10.04                        Modaliases for the NVIDIA binary X.Org drive

Ist seit jeher eine Intel Graphik. Also ich fühle mich schon schuldlos. 8)

Jetzt mal ganz auf blöd: wenn bei mehreren Systemen das absolut gleiche plötzlich von jetzt auf gleich nicht mehr funktioniert, ohne dass was daran gemacht worden ist, könnte es ja auch irgendein Bug mit einer Zeitangabe sein. Hatte das bei einem (Cisco ) Access Point Typ mal, der bei mehreren Kunden am selben Tag angefangen hat zu spinnen. Was hab ich nicht alles probiert. Am Ende hab ich das interne Datum des AP von 2010 auf 2007 zurückgesetzt und siehe da: alles lief wieder wie am schnürchen. Da ist in der Firmware wohl bei irgendeiner Funktion, die auf einen Timestamp zugreift, ab einem gewissen Wert was schiefgelaufen. Vielleicht ist das ja auch hier so? Würde ich schon mal probieren. Eine Lösung wäre es zwar bei Laptops (im Gegensatz zu einem AP) auch nicht einfach das Datum zurückzusetzen, aber zumindest wüsstest Du schon mal was Sache ist

Ich bezweifle, dass Timermäßig im X-System irgendwas abläuft. Was ablaufen kann sind user-accounts. Aber vllt. haben unfreie Treiber mitlerweile ein Haltbarkeitsgrenze.

Überhaupt, composite und Konsorten bezüglich spontaner Verweigerung ist für mich nichts neues: Läuft fröhlich ein paar Wochen, nachher kannst Du dann hingehen und ne xorg.conf schreiben. War jedenfalls vor zwei Jahren mal so.


Und ich sehe gerade:

root@beimir:~# dpkg -l | grep 'fglrx'
ii  fglrx-modaliases                       2:8.723.1-0ubuntu5                              Identifiers supported by the ATI graphics dr

...
Als würde man ständig das Sys abgrasen, was nicht gerade ist...

 

[mj]

Ich hab das System jetzt aus einem Image wiederhergestellt und schon geht das Compositing auch wieder. Dafür musste ich den Nvidia-Treiber mittels nvidia-uninstall deinstallieren und KMS wieder aktivieren. Warum es plötzlich geht kann ich nicht sagen, mal schauen wie lang das noch so bleibt...

Im Übrigen ist der Treiber noch immer im System vorhanden, trotz uninstall:

root/nmartin$ find /usr -name libnvidia*
/usr/lib64/libnvidia-glcore.so.260.19.36
/usr/lib64/tls/libnvidia-tls.so.256.35
/usr/lib64/tls/libnvidia-tls.so.260.19.36
/usr/lib64/libnvidia-glcore.so.256.35
/usr/lib/libnvidia-glcore.so.260.19.36
/usr/lib/libnvidia-tls.so.256.35
/usr/lib/tls/libnvidia-tls.so.260.19.36
/usr/lib/libnvidia-glcore.so.256.35

Wenn ich diese entferne startet ksmserver nicht mehr, ich dreh mich also im Kreis. Allerdings werd ich erstmal nix machen, schließlich funktioniert es momentan.

 

[Berniyh]

Wenn ich diese entferne startet ksmserver nicht mehr, ich dreh mich also im Kreis. Allerdings werd ich erstmal nix machen, schließlich funktioniert es momentan.

Also ist der Nvidia Treiber über dessen Installroutine installiert worden?
Fedora hat doch den Treiber sicherlich auch in den Repositories, oder nicht?
In dem Fall sollte man auf jeden Fall diese Treiber verwenden. Der Grund ist eben, dass der Treiber mit einigen X.org-Dateien (meines Wissens Mesa) kollidiert. Distributionen müssen in diesem Fall Routinen einbauen, die das berücksichtigen, um eine saubere Deinstallation zu ermöglichen.

So wie das jetzt bei dir ist ist es vermutlich pures Glück, dass es überhaupt noch funktioniert.
Den Nvidia Treiber sollte man nur dann manuell installieren, wenn man sich im klaren darüber ist, was man da tut und insbesondere auch nur dann, wenn man sich sicher ist, dass man auf dem System nichts anderes als diesen Treiber für die Ausgabe verwenden will.

Zur Analyse des Problems:
1. Schau dir an, welche Dateien von Nvidia überhaupt installiert werden
2. Schau dir die Abhängigkeiten der entsprechenden libs/bins an (i.e. kmserver, libGl.so, libnividia*)

scanelf -L -n -q -F '%n #F'  /path/to/lib |tr ',' '\n'

3. Irgendwo wirst du einen Verweis auf libnvidia* finden, also den Übeltäter
4. Finde heraus, welchem Paket diese Datei angehört (in deinem Fall vermutlich `rpm -qf /path/to/lib`
5. Installiere dieses Paket neu und überprüfe alles nochmal

Alternativ, ist aber nicht garantiert, dass es funktioniert:
1. Nvidia Treiber installieren, über das Paketsystem
2. Nvidia Treiber deinstallieren, über das Paketsystem
3. libnvidia* Überreste entfernen

Es ist deshalb nicht garantiert, dass das funktioniert, da sich die Installroutinen unterscheiden können und somit nicht garantiert ist, dass die Überreste wirklich entfernt werden.
Jedenfalls sollte bei der Deinstallation des Nvidia Treibers über das Paketsystem kein Überrest verbleiben. Falls doch, dann haben die Maintainer da etwas falsch gemacht...

 

[mj]

Ich habe den Treiber über den Nvidia-Installer installiert, den Treibern aus den Repositories traue ich nicht da ich damit schon öfters schlechte Erfahrungen gemacht habe.

Ursprünglich war das Fedora auch ausschließlich für das T510 gedacht. Davon haben wir etwa zwei dutzend, alles Geschäftslaptops, die sobald sie einmal laufen keinerlei Treiberupdates mehr erfahren, sondern allerhöchstens noch kritische Sicherheitsupdates. Dass es letztlich auch auf den U350 zum Einsatz kam ist mehr einem Zufall zu verdanken - ich hab's einfach mal probiert, es hat ohne Probleme funktioniert und wir sind dabei geblieben. Bis vor kurzem hat ja auch noch alles prima funktioniert, ich tendiere daher auch eher in die Richtung, die Nero24 eingeschlagen hat - da muss irgendwo ein Problem mit der Zeit gewesen sein, denn sonst hätten die nicht alle zeitgleich genauso reagiert.

 

[Ragas]

Ich habe den Treiber über den Nvidia-Installer installiert, den Treibern aus den Repositories traue ich nicht da ich damit schon öfters schlechte Erfahrungen gemacht habe.

Ich weiß ja nicht, welche schlechten Erfahrungen du mit den Repositories gemacht hast.
Aber mit selbst Installieren macht man sich grundsätzlich nur alles kaputt. (es sei denn man trennt das ganze wirklich ordentlich, das man vom Nvidia-Installer nicht behaupten kann)

 

[Berniyh]

Ich habe den Treiber über den Nvidia-Installer installiert, den Treibern aus den Repositories traue ich nicht da ich damit schon öfters schlechte Erfahrungen gemacht habe.

Wie oben erwähnt ist und bleibt das eine schlechte Idee.
Der Nvidia-Installer kann zunächst einmal nichts besser als das Paketmanagement selbst, im Gegenteil, er macht oft auch Dinge schlechter, da er ja über das Paketmanagement nichts wissen kann (oder zumindest nicht für jede Distribution). Genau das ist dann auch bei dir aufgetreten.

Wenn es seitens der Maintainer ordentlich umgesetzt wird, dann gibt es da auch keine Probleme, zumindest keine, die unmittelbar mit der Installation zusammenhängen. Falls es nicht ordentlich umgesetzt wird, dann solltest du den entsprechenden Leuten von Fedora eins auf den Deckel geben, dass sie es ordentlich umsetzen.

Prinzipiell sollte man alles in /usr, insbesondere /usr/bin und /usr/lib{,32,64} dem Paketmanager überlassen, sonst sind Probleme quasi vorprogrammiert (außer man ist sehr vorsichtig und weiß was man tut, aber dann lässt man es wahrscheinlich ohnehin bleiben). Im Zweifelsfall dann die Möglichkeiten des Paketmanagers nutzen eigene Pakete einzubinden. Leider sind da die meisten Tools (meines Wissens auch rpm) ziemlich beschränkt in ihren Möglichkeiten...

Dass es letztlich auch auf den U350 zum Einsatz kam ist mehr einem Zufall zu verdanken - ich hab's einfach mal probiert, es hat ohne Probleme funktioniert und wir sind dabei geblieben. Bis vor kurzem hat ja auch noch alles prima funktioniert, ich tendiere daher auch eher in die Richtung, die Nero24 eingeschlagen hat - da muss irgendwo ein Problem mit der Zeit gewesen sein, denn sonst hätten die nicht alle zeitgleich genauso reagiert.

Ich halte das immer noch eher für Zufall, dass es funktioniert hat. Warum es dann plötzlich schief ging ist natürlich schwer zu sagen. Weiter wichtig ist das aber auch nicht unbedingt.
Der Weg das zu beheben sollte jedenfalls oben beschrieben sein.