[debian] ssh -X nvidia et opengl

ssh -X nvidia et opengl [debian] - Logiciels - Linux et OS Alternatifs

Marsh Posté le 16-11-2015 à 11:41:38    

M'sieurs D'ames bonjour [:prodigy]
 
Voilà le topo, depuis des lustres on a des machines qui tournent sous debian 7 (ou 8) avec carte graphique Geforce et les drivers du site nvidia
Les utilisateurs peuvent faire du ssh -X dessus et lancent par exemple un soft qui s'appelle VMD qui permet de faire joujou avec des molécules.
 
Tout allait bien jusqu'à la semaine dernière où on a du rebooter toutes les machines.
 
Maintenant on a le problème suivant:
Depuis plusieurs machines lorsqu'on fait un ssh -X et qu'on lance le soft en question (ou glxinfo), on a ça en retour
 

Code :
  1. user@machine:~$ glxinfo
  2. name of display: localhost:10.0
  3. X Error of failed request:  BadValue (integer parameter out of range for operation)
  4.   Major opcode of failed request:  154 (GLX)
  5.   Minor opcode of failed request:  24 (X_GLXCreateNewContext)
  6.   Value in failed request:  0x0
  7.   Serial number of failed request:  87
  8.   Current serial number in output stream:  88


 

Code :
  1. user@machine:~$ vmd
  2. Info) VMD for LINUXAMD64, version 1.9.1 (February 1, 2012)
  3. Info) http://www.ks.uiuc.edu/Research/vmd/                       
  4. Info) Email questions and bug reports to vmd@ks.uiuc.edu         
  5. Info) Please include this reference in published work using VMD: 
  6. Info)    Humphrey, W., Dalke, A. and Schulten, K., `VMD - Visual 
  7. Info)    Molecular Dynamics', J. Molec. Graphics 1996, 14.1, 33-38.
  8. Info) -------------------------------------------------------------
  9. Info) Multithreading available, 4 CPUs detected.
  10. Info) Free system memory: 7739MB (97%)
  11. Warning) Detected a mismatch between CUDA runtime and GPU driver
  12. Warning) Check to make sure that GPU drivers are up to date.
  13. Info) No CUDA accelerator devices available.
  14. Warning) Detected X11 'Composite' extension: if incorrect display occurs
  15. Warning) try disabling this optional X server feature.
  16. XRequest.154: BadValue (integer parameter out of range for operation) 0x0
  17. ERROR) Could not create OpenGL rendering context-> Exiting...
  18. Info) VMD for LINUXAMD64, version 1.9.1 (February 1, 2012)
  19. Info) Unable to create OpenGL window.


 
La machine distante d'où viennent ces logs est un Debian 8 avec une GeForce 9500GT, j'ai testé à peu près tous les drivers NVIDIA possible, ceux du site nvidia et ceux du repository debian.
Ma machine locale est une debian testing avec une nvidia quadro K600 sur laquelle j'ai également essayé tous les drivers possibles (mais pas nouveau).
 
Par contre le truc fun c'est que mon collègue avec son debian 7.8 à côté de moi n'a pas ces soucis :heink: il tourne également avec une carte nvidia mais une quadro 600 et des drivers du site nvidia.
 
Et bien entendu aucune erreur dans les logs...
 
Bref je ne comprends pas le machin donc si qqn a une idée, je suis preneur :D
 
Merci !


---------------
Des trucs - flickr - Instagram
Reply

Marsh Posté le 16-11-2015 à 11:41:38   

Reply

Marsh Posté le 16-11-2015 à 14:54:15    

As-tu fait un "xhost +" sur le client pour permettre des connections distantes?
Un xclock fonctionne-t-il?

Message cité 1 fois
Reply

Marsh Posté le 16-11-2015 à 14:56:38    


 
xhost + sur les 2 machines pour être sur.
xterm et xclock fonctionnent.


---------------
Des trucs - flickr - Instagram
Reply

Marsh Posté le 15-02-2016 à 13:28:17    

bon je lance un petit UP histoire de déterrer la chose :o

 

Toujours impossible de corriger ce problème.

 

J'ai une nouvelle machine client qui tourne sous debian stable avec 2 cartes GTX 970 et les derniers drivers Nvidia installés (361.28).

 

Toujours le même problème, depuis ma machine (debian testing) quand je ssh -X sur la machine et que je lance glxinfo j'ai ce retour

Code :
  1. # glxinfo
  2. name of display: localhost:10.0
  3. X Error of failed request:  BadValue (integer parameter out of range for operation)
  4.   Major opcode of failed request:  154 (GLX)
  5.   Minor opcode of failed request:  24 (X_GLXCreateNewContext)
  6.   Value in failed request:  0x0
  7.   Serial number of failed request:  42
  8.   Current serial number in output stream:  43
 

alors que mon collègue qui se connecte avec sa vieille debian obtient le bon retour. Il peut aussi lancer les app genre glxgears sans problème.
Depuis un windows 10 et un soft genre MobyXterm je peux me connecter en SSH X et lancer les glxgears également !

 

Bref je ne comprends pas pourquoi ça merde depuis ma machine uniquement !


Message édité par darxmurf le 15-02-2016 à 13:28:37

---------------
Des trucs - flickr - Instagram
Reply

Marsh Posté le 15-02-2016 à 13:51:23    

Tiens j'ai potentiellement trouvé une piste !

 

Lorsque mon collègue lance un glewinfo depuis sa session ssh -X on a (entre autre)

Code :
  1. GLEW version 1.10.0
  2. Reporting capabilities of display localhost:12.0, visual 0x2b
  3. Running on a Quadro 600/PCIe/SSE2 from NVIDIA Corporation
  4. OpenGL version 2.1.2 NVIDIA 349.16 is supported
 

alors que depuis ma machine j'ai

Code :
  1. GLEW version 1.10.0
  2. Reporting capabilities of display localhost:11.0, visual 0xa4
  3. Running on a Software Rasterizer from Mesa Project
  4. OpenGL version 1.4 (2.1 Mesa 10.5.4) is supported
 

Donc depuis mon SSH ça ne passe pas comme il faudrait au niveau OpenGL bourdail :heink:


Message édité par darxmurf le 15-02-2016 à 13:51:38

---------------
Des trucs - flickr - Instagram
Reply

Marsh Posté le 15-02-2016 à 13:55:08    

compare vos versions de openssh, et les options liées du client

Message cité 1 fois

---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 15-02-2016 à 14:39:27    

black_lord a écrit :

compare vos versions de openssh, et les options liées du client


 
Je me suis demandé si ça pouvait effectivement venir de là étant donné que je tourne avec une testing.
 
Mais en essayant depuis une autre debian stable avec la même configuration ça fait la même chose. :(


---------------
Des trucs - flickr - Instagram
Reply

Marsh Posté le 15-02-2016 à 15:37:39    

tu as vu ce thread http://www.cgl.ucsf.edu/pipermail/ [...] 09829.html qui parle de comparer les versions de mesa ?


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 16-02-2016 à 08:27:29    

merci pour l'info, par contre j'ai déjà Mesa 10.x sur les 2 machines [:paysan] tain c'est vraiment du random ces conneries, d'autant que mon collègue tourne avec sa debian de l'age de pierre et que ça fonctionne pour lui :heink:

Message cité 1 fois

---------------
Des trucs - flickr - Instagram
Reply

Marsh Posté le 16-02-2016 à 09:46:26    

darxmurf a écrit :

merci pour l'info, par contre j'ai déjà Mesa 10.x sur les 2 machines [:paysan] tain c'est vraiment du random ces conneries, d'autant que mon collègue tourne avec sa debian de l'age de pierre et que ça fonctionne pour lui :heink:


Environnements different?
 
Essaie:
 
ssh -X user@cible1 set > /tmp/cible1.txt
ssh -X user@cible2 set > /tmp/cible2.txt
 
Puis un diff des deux et regarde si il y a un truc qui saute aux yeux: LD_LIBRARY_PATH? PATH? ...

Reply

Marsh Posté le 16-02-2016 à 09:46:26   

Reply

Marsh Posté le 18-02-2016 à 10:35:10    

Bon, je biens de tester avec 2 machines absolument identiques, même hardware et disque cloné. La seule différence c'est leur hostname.
Bah ça ne passe toujours pas :/


---------------
Des trucs - flickr - Instagram
Reply

Marsh Posté le 18-02-2016 à 12:13:48    

T'as pas l'impression que sur ta machine tu tourne avec le driver libre et pas le driver proprio des fois non ?
 
https://wiki.debian.org/NvidiaGraphicsDrivers
 
En gros un ssh +X va utiliser tes ressources locales via une redirection des appels. Le problème n'est donc pas sur la machine distante, mais bel et bien en local.

Message cité 1 fois
Message édité par MysterieuseX le 18-02-2016 à 12:14:31
Reply

Marsh Posté le 18-02-2016 à 15:14:13    

MysterieuseX a écrit :

T'as pas l'impression que sur ta machine tu tourne avec le driver libre et pas le driver proprio des fois non ?
 
https://wiki.debian.org/NvidiaGraphicsDrivers
En gros un ssh +X va utiliser tes ressources locales via une redirection des appels. Le problème n'est donc pas sur la machine distante, mais bel et bien en local.


 
C'est bien ce que j'ai cru comprendre au niveau de l'exploitation des ressources.
Au niveau driver toutes les machines que j'ai testé tournent avec le driver proprio de NVIDIA et pas le driver "nouveau".
J'ai testé avec des versions plus ou moins vieilles et aussi la version qu'on trouve dans les repo debian, ça ne change rien.
 
Le truc qui me gave c'est que ça passait bien depuis la machine en debian wheezy et après la mise à jour en jessie, plus moyen.
 
Pour le moment j'ai installé VitrualGL, ça permet aux utilisateurs de lancer leurs app openGL à distance tout en exploitant la CG distante également. Ca fonctionne mais j'aimerais bien comprendre pourquoi ce foutu ssh -X (ou -Y) merde maintenant !


---------------
Des trucs - flickr - Instagram
Reply

Marsh Posté le 18-02-2016 à 16:16:01    

ca donne quoi un lspci -vv sur la machine incriminée ? Non ... Juste comme ça quoi.

Message cité 1 fois
Reply

Marsh Posté le 18-02-2016 à 17:13:43    

MysterieuseX a écrit :

ca donne quoi un lspci -vv sur la machine incriminée ? Non ... Juste comme ça quoi.


 
tu veux juste la partie NVIDIA je pense ?
 

Code :
  1. 81:00.0 VGA compatible controller: NVIDIA Corporation Device 13c2 (rev a1) (prog-if 00 [VGA controller])
  2.         Subsystem: ASUSTeK Computer Inc. Device 852e
  3.         Physical Slot: 801
  4.         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- DisINTx-
  5.         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
  6.         Latency: 0
  7.         Interrupt: pin A routed to IRQ 130
  8.         Region 0: Memory at c8000000 (32-bit, non-prefetchable) [size=16M]
  9.         Region 1: Memory at 387fe0000000 (64-bit, prefetchable) [size=256M]
  10.         Region 3: Memory at 387ff0000000 (64-bit, prefetchable) [size=32M]
  11.         Region 5: I/O ports at 8000 [size=128]
  12.         [virtual] Expansion ROM at c9080000 [disabled] [size=512K]
  13.         Capabilities: [60] Power Management version 3
  14.                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  15.                 Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
  16.         Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
  17.                 Address: 00000000fee10000  Data: 4058
  18.         Capabilities: [78] Express (v2) Legacy Endpoint, MSI 00
  19.                 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us
  20.                         ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
  21.                 DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported-
  22.                         RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop-
  23.                         MaxPayload 256 bytes, MaxReadReq 512 bytes
  24.                 DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend+
  25.                 LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <1us, L1 <4us
  26.                         ClockPM+ Surprise- LLActRep- BwNot-
  27.                 LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
  28.                         ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
  29.                 LnkSta: Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
  30.                 DevCap2: Completion Timeout: Range AB, TimeoutDis+, LTR+, OBFF Via message
  31.                 DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
  32.                 LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
  33.                          Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
  34.                          Compliance De-emphasis: -6dB
  35.                 LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+, EqualizationPhase1+
  36.                          EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest-
  37.         Capabilities: [100 v1] Virtual Channel
  38.                 Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
  39.                 Arb:    Fixed- WRR32- WRR64- WRR128-
  40.                 Ctrl:   ArbSelect=Fixed
  41.                 Status: InProgress-
  42.                 VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
  43.                         Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
  44.                         Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
  45.                         Status: NegoPending- InProgress-
  46.         Capabilities: [250 v1] Latency Tolerance Reporting
  47.                 Max snoop latency: 0ns
  48.                 Max no snoop latency: 0ns
  49.         Capabilities: [258 v1] L1 PM Substates
  50.                 L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
  51.                           PortCommonModeRestoreTime=255us PortTPowerOnTime=10us
  52.         Capabilities: [128 v1] Power Budgeting <?>
  53.         Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
  54.         Capabilities: [900 v1] #19
  55.         Kernel driver in use: nvidia


 
et pour la route  
 

Code :
  1. # lsmod | grep nvidia
  2. nvidia_uvm             67503  2
  3. nvidia               8588835  79 nvidia_uvm
  4. drm                   249955  4 nvidia
  5. i2c_core               46012  5 drm,igb,i2c_i801,i2c_algo_bit,nvidia


 
et aussi  
 

Code :
  1. # nvidia-smi
  2. Thu Feb 18 17:12:50 2016     
  3. +------------------------------------------------------+                     
  4. | NVIDIA-SMI 352.55     Driver Version: 352.55         |                     
  5. |-------------------------------+----------------------+----------------------+
  6. | GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
  7. | Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
  8. |===============================+======================+======================|
  9. |   0  GeForce GTX 970     Off  | 0000:03:00.0      On |                  N/A |
  10. | 51%   79C    P2   110W / 148W |   1985MiB /  4095MiB |     88%      Default |
  11. +-------------------------------+----------------------+----------------------+
  12. |   1  GeForce GTX 970     Off  | 0000:81:00.0     Off |                  N/A |
  13. | 41%   69C    P2   124W / 148W |   1964MiB /  4095MiB |     84%      Default |
  14. +-------------------------------+----------------------+----------------------+
  15.                                                                              
  16. +-----------------------------------------------------------------------------+
  17. | Processes:                                                       GPU Memory |
  18. |  GPU       PID  Type  Process name                               Usage      |
  19. |=============================================================================|
  20. |    0      1156    G   /usr/bin/X                                      20MiB |
  21. |    0      3922    C   terachem                                      1943MiB |
  22. |    1      3922    C   terachem                                      1943MiB |
  23. +-----------------------------------------------------------------------------+


 
ce sont des machines de calcul, on doit obligatoirement utiliser les drivers nvidia pour exploiter le CUDA


---------------
Des trucs - flickr - Instagram
Reply

Marsh Posté le 18-02-2016 à 18:24:44    

C'est bien ta machine locale que tu test là ?
 
Edit : j'ai pas été assez claire en fait. Fait le lspci -vv sur ta machine locale, pas dans la console ssh. Ta machine distante n'a pas de problèmes. Tu as donné toi même la réponse :
Ton collègue sur sa machine en local a bien openGL avec le bon driver d'installé :  
 
GLEW version 1.10.0
Reporting capabilities of display localhost:12.0, visual 0x2b
Running on a Quadro 600/PCIe/SSE2 from NVIDIA Corporation
OpenGL version 2.1.2 NVIDIA 349.16 is supported
 
Toi tu ne l'as pas :  
 
GLEW version 1.10.0
Reporting capabilities of display localhost:11.0, visual 0xa4
Running on a Software Rasterizer from Mesa Project
OpenGL version 1.4 (2.1 Mesa 10.5.4) is supported  
 
Donc, c'est au choix : soit ta machine locale qui n'a pas les bons trucs d'installé (t'as pensé a clean, installer nouveau, reboot, installer nvidia jessie backport, vue que t'es en debian 8, et reboot a nouveau puis faire un nvidia-xconfig après ton update vers debian 8 ?) soit ton .xsession ou .xorg.conf dans ta session distante est foireuse.
Rappel : un ssh -X ne fait que rediriger vers le matos local les appels du serveur X. Si le client ne sait pas les gérer, il t'enverra chier. Donc, revois ta conf nvidia/opengl sur ta debian 8 (elle n'a pas changé dans ses fondamentaux)


Message édité par MysterieuseX le 18-02-2016 à 18:32:07
Reply

Marsh Posté le 19-02-2016 à 09:48:35    

Ah toutes mes confuses
 
Pour ma machine locale :
 

Citation :


---------------------------
    GLEW Extension Info
---------------------------
 
GLEW version 1.13.0
Reporting capabilities of display , visual 0x2b
Running on a Quadro K600/PCIe/SSE2 from NVIDIA Corporation
OpenGL version 4.5.0 NVIDIA 361.28 is supported


 
Ce qui est marrant c'est que sur la machine distante si je lance un  

Citation :


glewinfo -display :0


 
Ca passe
 

Citation :


GLEW version 1.10.0
Reporting capabilities of display :0, visual 0x2b
Running on a GeForce GTX 970/PCIe/SSE2 from NVIDIA Corporation
OpenGL version 4.5.0 NVIDIA 352.55 is supported


 
Maintenant la question qui me vient à l'esprit, les machines de calcul n'ont pas forcément d'écran connecté, est-ce que ça ne pourrait pas faire merder l'ensemble par hasard ?


---------------
Des trucs - flickr - Instagram
Reply

Marsh Posté le 19-02-2016 à 11:13:43    

raaaah ptaing finalement trouvé sur un devboard de nvidia !
 

Citation :


See: https://bugs.freedesktop.org/show_bug.cgi?id=93820#c3
"Apparently Xorg 1.17 disables indirect GLX by default. Try starting the X server with +iglx."  


 
j'ai rajouté +iglx dans me conf xorg et yalla ça refonctionne :o certes en rendering local mais c'est moins chiant que de lancer une instance de VGRendering machin truc :o
 
Merci en tout cas pour le coup de main !


---------------
Des trucs - flickr - Instagram
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed