Re: Une histoire d'authentification à s'arracher les cheveux
Bonjour JKB, BERTRAND Joël, on 2021-06-27: > Et là, je sèche, je ne comprends pas. L'authentification doit être > reproductible. Je ne vois pas pourquoi b2 peut se connecter au démarrage > de la machine hilbert et pas b1. Et surtout, je ne comprends pas > pourquoi après un certain temps, tout semble redevenir normal sans que > rien d'explicite n'ait été fait sur le réseau, sur le client ou sur le > serveur. Ce genre de symptôme ressemble furieusement à un cache qui tarde à se mettre à jour. Est-ce que, par hasard, les choses rentrent dans l'ordre d'elles-même un peu plus vite en redémarrant nscd sur hilbert ? (en admettant que nscd soit présent ; il est tiré comme paquet recommandé par ypbind-mt.) Bonne soirée, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/5, please excuse my verbosity. signature.asc Description: PGP signature
Re: Plantages Xorg (i915, context reset due to GPU hang)
Bonjour Daniel, Daniel Caillibaud, on 2021-07-01: > Le 16/06/21 à 13:13, Daniel Caillibaud a écrit : > > J'ai commencé par mettre les options > > intel_idle.max_cstate=1 i915.enable_dc=0 > > Ça n'a rien changé. > > J'ai ensuite désactivé dans le bios toutes les optimisation cpu (cstate, > speed state, turbo > boost), et je me suis retrouvé avec un gros veau (délais ×2 à ×6 suivant les > tâches) qui > plantait un peu moins mais plantait quand même. > > J'avais qq espoirs après là mise à jour du paquet intel-microcode de lundi, > encore raté… > > J'ai par ailleurs constaté que mon client slack-desktop était vraiment > goinfre en RAM, je l'ai > fermé, et depuis ça n'a pas planté… > > Ce n'est peut-être pas lui qui est directement en cause, mais la conjonction > d'opérations qui > menaient au plantage (et que j'ai pas identifié) semble ne plus se produire > depuis qu'il ne > tourne plus… > > (c'était un slack-deskop installé sous jessie depuis la source > deb https://packagecloud.io/slacktechnologies/slack/debian/ jessie main > que j'ai récemment réinstallé avec snap, j'avais des plantages avec les deux > versions) Je n'ai jamais eu l'occasion d'utiliser slack, donc peut-être que mon idée n'aura pas beaucoup de sens, mais est-ce que slack propose de désactiver l'accélération graphique ? Peut-être que désactiver ce paramètre aiderait à la stabilité de la machine ? J'ai téléchargé un .deb de slack-desktop 4.17.0[1] depuis le site de slack.com, et j'ai vu que le programme embarquait un chrome-sandbox setuid, combiné à des bibliothèques OpenGL et Vulkan tierces. D'où l'idée que, si ce programme exécute des bibliothèques graphiques buguées en tant que root, alors peut-être que ça expliquerait les crashes avec le pilote i915. Bonne soirée, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/0, please excuse my verbosity. Pour référence : [1] : https://downloads.slack-edge.com/linux_releases/slack-desktop-4.17.0-amd64.deb signature.asc Description: PGP signature
Re: Debian Buster - Installation du client oracle 11.2 en version complete
Bonjour à tous, Comme l'a suggéré Bernard dans un courriel, il est possible de se référer à la documentation https://help.ubuntu.com/community/Oracle%20Instant%20Client Et dans ce cas, en effet il est possible d'installer les différents paquets au format RPM via 'alien'. C'est le choix de contournement que j'utilise pour l'instant et il fonctionne (Test via sqlplus OK) au moins au niveau système. Au niveau applicatif, je verrai lors de l'installation de l'applicatif. Cordialement, Thierry
Re: Plantages Xorg (i915, context reset due to GPU hang)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Étienne Mollier a écrit : > Bonjour Daniel, > > Daniel Caillibaud, on 2021-07-01: >> Le 16/06/21 à 13:13, Daniel Caillibaud a >> écrit : >>> J'ai commencé par mettre les options intel_idle.max_cstate=1 >>> i915.enable_dc=0 >> >> Ça n'a rien changé. >> >> J'ai ensuite désactivé dans le bios toutes les optimisation cpu >> (cstate, speed state, turbo boost), et je me suis retrouvé avec >> un gros veau (délais ×2 à ×6 suivant les tâches) qui plantait un >> peu moins mais plantait quand même. >> >> J'avais qq espoirs après là mise à jour du paquet intel-microcode >> de lundi, encore raté… >> >> J'ai par ailleurs constaté que mon client slack-desktop était >> vraiment goinfre en RAM, je l'ai fermé, et depuis ça n'a pas >> planté… >> >> Ce n'est peut-être pas lui qui est directement en cause, mais la >> conjonction d'opérations qui menaient au plantage (et que j'ai >> pas identifié) semble ne plus se produire depuis qu'il ne tourne >> plus… >> >> (c'était un slack-deskop installé sous jessie depuis la source >> deb https://packagecloud.io/slacktechnologies/slack/debian/ >> jessie main que j'ai récemment réinstallé avec snap, j'avais des >> plantages avec les deux versions) > > Je n'ai jamais eu l'occasion d'utiliser slack, donc peut-être que > mon idée n'aura pas beaucoup de sens, mais est-ce que slack propose > de désactiver l'accélération graphique ? Peut-être que désactiver > ce paramètre aiderait à la stabilité de la machine ? > > J'ai téléchargé un .deb de slack-desktop 4.17.0[1] depuis le site > de slack.com, et j'ai vu que le programme embarquait un > chrome-sandbox setuid, combiné à des bibliothèques OpenGL et Vulkan > tierces. D'où l'idée que, si ce programme exécute des > bibliothèques graphiques buguées en tant que root, alors peut-être > que ça expliquerait les crashes avec le pilote i915. Bonsoir, En fait, toutes les bibliothèques d'accélération graphiques sont buggués parce qu'elles ne vérifient pas les allocations mémoire. La plupart du temps, ça termine par un segfault de l'application, mais ça peut aussi terminer beaucoup plus mal par un crash noyau. J'ai cherché un tel bug durant des années, bug lié à la taille de la mémoire graphiqu e. Je ne me souviens pas, mais quelle est la taille de la mémoire graphique sur la machine en question ? Ça vaut le coup d'augmenter la taille pour voir si cela change quelque chose. Bien cordialement, JKB -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEq4YCoAJMwLElZVYXOAfo0lKQ8+cFAmDeEWIACgkQOAfo0lKQ 8+eyQA/9GR5OXUPW+Ztbw3la+cOTTbGTUwLSVMSUGL0pWSAA2HP8AMLYD7Ac19bt iDjYfGCN7E781dBabL3L4UN2+GNmUhm8YU6gp5TpLCjYNyYHq2p+cvxO47zVSW+u YS7US4LubW6jwtxVC13Fpk5MvAJlzz0NdESWwjn1XdoSqS+6SCO2VV/zWtVNZB6q dfOjA67g8o86KOej5sQiEeTSXUoaKWiU39X8VhuA5TUQhc+M4VhxTZocT5LMil6l EY6WXlE97vyBDBFy3C84UYFXOiS3yRXVYB5+rxT0wogbvBseJYnhA9LmO3g62PRn IaWHu8LCzwIOURhkZdqIlNsMHY7pRo9+j7PGGk168cnH2I2FQfYNmuilNTzddlhu EaCbbDyeX0sE9r0+N0j9c+UOAW2F/YmknW8GVg1JpWHFAsN0PIMtkIiScj9whHrS x5ibL0CHr+MJcNZpNR8y0Qtq50kTLlB+w9k7oeAcZpZRMqrODJOPbs4EkchFEMte gLdG/oeaep3bqtThkawSPfRz7NCjgtdeysl4Mn6e0xfM39i8gmpxMe26GF1Mne3+ ivmgJnaxecQTP5SQS2Kh8NewCaCDL1DlvxZFuOpmvmfuEGl2TllLbhse7LVrh4QJ FZxsoM9nGB9g5zgllo5aTLCJqMwctkfeveK/oF4yfZ0B4LOFGm0= =2Nkb -END PGP SIGNATURE-
Re: Une histoire d'authentification à s'arracher les cheveux
Étienne Mollier a écrit : > Bonjour JKB, > > BERTRAND Joël, on 2021-06-27: >> Et là, je sèche, je ne comprends pas. L'authentification doit >> être reproductible. Je ne vois pas pourquoi b2 peut se connecter >> au démarrage de la machine hilbert et pas b1. Et surtout, je ne >> comprends pas pourquoi après un certain temps, tout semble >> redevenir normal sans que rien d'explicite n'ait été fait sur le >> réseau, sur le client ou sur le serveur. > > Ce genre de symptôme ressemble furieusement à un cache qui tarde à > se mettre à jour. Est-ce que, par hasard, les choses rentrent > dans l'ordre d'elles-même un peu plus vite en redémarrant nscd sur > hilbert ? (en admettant que nscd soit présent ; il est tiré comme > paquet recommandé par ypbind-mt.) Bonsoir, Effectivement, il y a nscd qui tourne. Et je viens de vérifier, il ne tourne pas sur heisenberg. Je vérifierai au prochain redémarrage... Mais j'avoue ne pas tout à fait comprendre pourquoi b2 pourrait dans se cas se connecter et pas b1. Peut-être parce que b2 n'utilise pas ce poste et que l'authentification s'est faite directement sur le serveur ? Merci du tuyau, JKB
Re: Plantages Xorg (i915, context reset due to GPU hang)
Le 16/06/21 à 13:13, Daniel Caillibaud a écrit : > J'ai commencé par mettre les options > intel_idle.max_cstate=1 i915.enable_dc=0 Ça n'a rien changé. J'ai ensuite désactivé dans le bios toutes les optimisation cpu (cstate, speed state, turbo boost), et je me suis retrouvé avec un gros veau (délais ×2 à ×6 suivant les tâches) qui plantait un peu moins mais plantait quand même. J'avais qq espoirs après là mise à jour du paquet intel-microcode de lundi, encore raté… J'ai par ailleurs constaté que mon client slack-desktop était vraiment goinfre en RAM, je l'ai fermé, et depuis ça n'a pas planté… Ce n'est peut-être pas lui qui est directement en cause, mais la conjonction d'opérations qui menaient au plantage (et que j'ai pas identifié) semble ne plus se produire depuis qu'il ne tourne plus… (c'était un slack-deskop installé sous jessie depuis la source deb https://packagecloud.io/slacktechnologies/slack/debian/ jessie main que j'ai récemment réinstallé avec snap, j'avais des plantages avec les deux versions) -- Daniel Il n'est pas de vent favorable pour celui qui ne sait où il va. Sénèque
