Je me permets de vous soumettre le problème que je rencontre sur une
nouvelle machine, après avoir essayé une série de choses qui ne le
résolvent pas, en espérant que quelqu'un aurait une expérience utile
en la matière, ou déjà une idée ou deux :-)
La machine est un NUC Intel, modèle NUC7i3DNKE.
Son processeur est un Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz
Sa carte graphique, selon lspci : Intel Corporation HD Graphics 620 (rev 02)
Elle a 4GB de RAM de marque 2-Power dans le slot inférieur et est
couplée à deux écrans DELL U3011 par des câbles HDMI to DVI-D Dual
Link (ce barebone n'a que deux connecteurs HDMI 2.0). Ça fait donc 2x
2560x1600 en résolution (et il peut aller jusqu'à 2x 4k, @60 Hz).
Enfin, elle est utilisée comme client léger sous LTSP, bootant sur un
serveur LTSP en NFS, mais l'aspect LTSP est indifférent.
Question OS, a priori tout est du stretch pur jus, à jour (donc tant
le serveur LTSP que l'OS utilisé par le client léger, c.-à-d. ici le
NUC).
Le souci rencontré est que les écrans clignotent de temps en temps :
ils s'éteignent (l'un ou l'autre ou les deux) une à deux secondes,
voire parfois 4-5, et puis se rallument...
Jusqu'ici, j'ai lancé le NUC sous stretch 32bits et amd64, sans et
puis avec le microcode Intel (avec, ça améliore sensiblement les
choses, bien que ça ne soit pas encore parfait), pour finir enfin en
buster, avec le noyau 4.14.
Toujours avec le microcode, les résultats varient en fonction de la
version du noyau : avec le 4.9 de stretch, c'est inutilisable
tellement ça clignote. C'est un poil mieux avec le 4.14 des backports,
toujours en stretch et ça devient utilisable, mais encore gênant avec
le 4.14 de buster.
Pour voir, j'ai booté aussi, toujours sous buster, avec le noyau
4.15.7 de sid, mais là c'est catastrophique (et pour cause : le noyau
désactive une partie du microcode Intel en signalant qu'il ne résout
pas Spectre (j'ai oublié les termes exacts, mais le microcode est
pourtant la dernière version de chez Intel : 20171117).
Enfin, à part en 4.15.7, j'ai chaque fois essayé avec les pilotes
graphiques modesetting et Intel. On ne peut toutefois pas dire que ça
fait une différence notable de comportement, et comme modesetting est
recommandé et semble (mais c'est subjectif) un poil plus rapide à
l'affichage, je tourne avec ce pilote, sous buster pour le moment.
Enfin encore, je viens aussi d'upgrader le bios du NUC à la dernière
version (039) du 22/02/2018.
Mais même si ça n'a plus rien à voir avec les débuts sous stretch, les
clignotements persistent quand même encore, sur l'un ou l'autre des
écrans, au point que j'hésite à laisser ça comme poste de travail en
l'état...
Inverser les écrans ne change rien ; un à la fois ou deux, c'est tout
à fait pareil ; les connecteurs sont bien vissés aux écrans, etc.
Rien n'y fait : c'est totalement erratique. L'un ou l'autre s'éteint
puis se rallume, jusqu'à parfois 10x sur quelques minutes, et puis
plus rien pendant un moment, etc.
Les seuls constats qui semblent pouvoir être posés sont :
- que le phénomène ne semble jamais se produire quand l'écran change
en permanence : en lançant xscreensaver ou un film, je ne l'ai
jamais surpris à s'éteindre de manière inexpliquée. C'est quand
l'image est fixe, mais qu'on tape du texte ou non, ça le fait ;
- que l'écran qui n'a pas le focus *semble* s'exciter davantage que
celui qui contient la fenêtre où je tape ceci, mais c'est difficile
d'en être sûr...
Voilà le phénomène bizarre. Si quelqu'un a une expérience utile à
partager ou ne fut-ce qu'une idée de piste à explorer, je suis
preneur :-)
Je vous remercie d'avance, en tout cas de m'avoir lu.
Bonjour, - la connectique (cas le plus souvent rencontré - tenter d'essuyer les broches ?) - la bande passante des câbles (un câble de mauvaise qualité ou bien qui touche un transformateur d'alimentation qui génère des perturbations électro-magnétiques et le câble n'est plus capable de transmettre 100% du signal) - la carte graphique est-elle correctement ventilée ? si ce n'est pas une ventilation mécanique, la ventilation passive a-t-elle un flux d'air suffisant ? (une sécurité pourrait couper brièvement l'étage de puissance de la carte graphique à une température maximale) Autre problème matériel : - un vieux moniteur peut avoir une alimentation dont un composant a besoin de se stabiliser au démarrage (montée en température), avant de provoquer une panne d'alimentation complète dans les semaines suivantes.
Bonjour,
- la connectique
(cas le plus souvent rencontré - tenter d'essuyer les broches ?)
- la bande passante des câbles
(un câble de mauvaise qualité ou bien qui touche un transformateur
d'alimentation qui génère des perturbations électro-magnétiques et le
câble n'est plus capable de transmettre 100% du signal)
- la carte graphique est-elle correctement ventilée ?
si ce n'est pas une ventilation mécanique, la ventilation passive
a-t-elle un flux d'air suffisant ?
(une sécurité pourrait couper brièvement l'étage de puissance de la
carte graphique à une température maximale)
Autre problème matériel :
- un vieux moniteur peut avoir une alimentation dont un composant a
besoin de se stabiliser au démarrage (montée en température), avant de
provoquer une panne d'alimentation complète dans les semaines suivantes.
Bonjour, - la connectique (cas le plus souvent rencontré - tenter d'essuyer les broches ?) - la bande passante des câbles (un câble de mauvaise qualité ou bien qui touche un transformateur d'alimentation qui génère des perturbations électro-magnétiques et le câble n'est plus capable de transmettre 100% du signal) - la carte graphique est-elle correctement ventilée ? si ce n'est pas une ventilation mécanique, la ventilation passive a-t-elle un flux d'air suffisant ? (une sécurité pourrait couper brièvement l'étage de puissance de la carte graphique à une température maximale) Autre problème matériel : - un vieux moniteur peut avoir une alimentation dont un composant a besoin de se stabiliser au démarrage (montée en température), avant de provoquer une panne d'alimentation complète dans les semaines suivantes.
err404
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Bonjour JF Straeten (Jean-François?) Je te conseille de tester les écrans sur d'autres machines. Ou de tester avec d'autres cables. Si tu peux tester d'autres écrans sur ce NUC, c'est bien aussi. Est ce que le phénomène de clignotement persiste si tu utilise une résolution plus faible? Et si tu n'utilise qu'un seul écran? -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEJO//ePEJChGbGaZQrjHmR0GD/5kFAlqc/1UACgkQrjHmR0GD /5kvYw//avDGMCEs65jz3RUKCSadspHvApTnqWWsn2Xk+/NP+Fq2vp/QAfgk4YMF 3zMflVe2XbQPCaJcHfkfzRsu7Q2bCmpp4ZvWlDKST+qBTpSG+9adOYsjRx0Keexx CiSuW+GCO+1xERd/u8v87X+/84NyCoNzs9xcuVJI9NwKKtIWMcIkSqzDJbNbsKal bCgA+h21QcN2Kd0tfXCmN6VwV0Hw/1tHI3RWgaXanoHgGBCAgPdr/HZKHNjgKKZ9 DZmYJJPMuLas0udHk7Z+16SFUuzvOcKRdqMfnPCXOrPMFqXTLeWRwm8E1VXvmX+L bBLk+JuY+POXJJoubJ+UoRbtSwSJePHIRN61i8EM9pO9cnCg6t1n3KvSgsplP7Nk 8OCrbIzMwkYA1piu76fQIGIrmqKlm5DKqe2Yep0tboDzgbxD+tzIniU4MfGr/VTn EPjlhkh5pkZv0bDVeW5e3OaZSy6nXImu+CsVXxz83PK3y1NJDWH/DpaI484w7Ec9 cGKOg85YLpZSbRBxZXTGrK6sdKMcFvgreUgK16AWTluhhhqQayeY8lNPsZtrop8L +11IZmFkWv5DMM8hrnLT22qZCXYHxTjy3XROni5xekVYLyuaUD50FrOj/YHfXd12 kkjIIjh64eL4PTfssYeaZLiHKNYU0JVk8PlcNd3vqI3r92xXuoc =FVhp -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Bonjour JF Straeten (Jean-François?)
Je te conseille de tester les écrans sur d'autres machines.
Ou de tester avec d'autres cables.
Si tu peux tester d'autres écrans sur ce NUC, c'est bien aussi.
Est ce que le phénomène de clignotement persiste si tu utilise une résolution plus faible?
Et si tu n'utilise qu'un seul écran?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Bonjour JF Straeten (Jean-François?) Je te conseille de tester les écrans sur d'autres machines. Ou de tester avec d'autres cables. Si tu peux tester d'autres écrans sur ce NUC, c'est bien aussi. Est ce que le phénomène de clignotement persiste si tu utilise une résolution plus faible? Et si tu n'utilise qu'un seul écran? -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEJO//ePEJChGbGaZQrjHmR0GD/5kFAlqc/1UACgkQrjHmR0GD /5kvYw//avDGMCEs65jz3RUKCSadspHvApTnqWWsn2Xk+/NP+Fq2vp/QAfgk4YMF 3zMflVe2XbQPCaJcHfkfzRsu7Q2bCmpp4ZvWlDKST+qBTpSG+9adOYsjRx0Keexx CiSuW+GCO+1xERd/u8v87X+/84NyCoNzs9xcuVJI9NwKKtIWMcIkSqzDJbNbsKal bCgA+h21QcN2Kd0tfXCmN6VwV0Hw/1tHI3RWgaXanoHgGBCAgPdr/HZKHNjgKKZ9 DZmYJJPMuLas0udHk7Z+16SFUuzvOcKRdqMfnPCXOrPMFqXTLeWRwm8E1VXvmX+L bBLk+JuY+POXJJoubJ+UoRbtSwSJePHIRN61i8EM9pO9cnCg6t1n3KvSgsplP7Nk 8OCrbIzMwkYA1piu76fQIGIrmqKlm5DKqe2Yep0tboDzgbxD+tzIniU4MfGr/VTn EPjlhkh5pkZv0bDVeW5e3OaZSy6nXImu+CsVXxz83PK3y1NJDWH/DpaI484w7Ec9 cGKOg85YLpZSbRBxZXTGrK6sdKMcFvgreUgK16AWTluhhhqQayeY8lNPsZtrop8L +11IZmFkWv5DMM8hrnLT22qZCXYHxTjy3XROni5xekVYLyuaUD50FrOj/YHfXd12 kkjIIjh64eL4PTfssYeaZLiHKNYU0JVk8PlcNd3vqI3r92xXuoc =FVhp -----END PGP SIGNATURE-----
fab
'lut, Tu peux essayer ta CG sur un autre poste avec 1 autre écran puis un second pour vérifier si c'est la carte mère qui déconne ou si c'est la carte graphique ? f. Le 04/03/2018 à 22:03, JF Straeten a écrit :
Chère Liste, Je me permets de vous soumettre le problème que je rencontre sur une nouvelle machine, après avoir essayé une série de choses qui ne le résolvent pas, en espérant que quelqu'un aurait une expérience utile en la matière, ou déjà une idée ou deux :-) La machine est un NUC Intel, modèle NUC7i3DNKE. Son processeur est un Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz Sa carte graphique, selon lspci : Intel Corporation HD Graphics 620 (rev 02) Elle a 4GB de RAM de marque 2-Power dans le slot inférieur et est couplée à deux écrans DELL U3011 par des câbles HDMI to DVI-D Dual Link (ce barebone n'a que deux connecteurs HDMI 2.0). Ça fait donc 2x 2560x1600 en résolution (et il peut aller jusqu'à 2x 4k, @60 Hz). Enfin, elle est utilisée comme client léger sous LTSP, bootant sur un serveur LTSP en NFS, mais l'aspect LTSP est indifférent. Question OS, a priori tout est du stretch pur jus, à jour (donc tant le serveur LTSP que l'OS utilisé par le client léger, c.-à-d. ici le NUC). Le souci rencontré est que les écrans clignotent de temps en temps : ils s'éteignent (l'un ou l'autre ou les deux) une à deux secondes, voire parfois 4-5, et puis se rallument... Jusqu'ici, j'ai lancé le NUC sous stretch 32bits et amd64, sans et puis avec le microcode Intel (avec, ça améliore sensiblement les choses, bien que ça ne soit pas encore parfait), pour finir enfin en buster, avec le noyau 4.14. Toujours avec le microcode, les résultats varient en fonction de la version du noyau : avec le 4.9 de stretch, c'est inutilisable tellement ça clignote. C'est un poil mieux avec le 4.14 des backports, toujours en stretch et ça devient utilisable, mais encore gênant avec le 4.14 de buster. Pour voir, j'ai booté aussi, toujours sous buster, avec le noyau 4.15.7 de sid, mais là c'est catastrophique (et pour cause : le noyau désactive une partie du microcode Intel en signalant qu'il ne résout pas Spectre (j'ai oublié les termes exacts, mais le microcode est pourtant la dernière version de chez Intel : 20171117). Enfin, à part en 4.15.7, j'ai chaque fois essayé avec les pilotes graphiques modesetting et Intel. On ne peut toutefois pas dire que ça fait une différence notable de comportement, et comme modesetting est recommandé et semble (mais c'est subjectif) un poil plus rapide à l'affichage, je tourne avec ce pilote, sous buster pour le moment. Enfin encore, je viens aussi d'upgrader le bios du NUC à la dernière version (039) du 22/02/2018. Mais même si ça n'a plus rien à voir avec les débuts sous stretch, les clignotements persistent quand même encore, sur l'un ou l'autre des écrans, au point que j'hésite à laisser ça comme poste de travail en l'état... Inverser les écrans ne change rien ; un à la fois ou deux, c'est tout à fait pareil ; les connecteurs sont bien vissés aux écrans, etc. Rien n'y fait : c'est totalement erratique. L'un ou l'autre s'éteint puis se rallume, jusqu'à parfois 10x sur quelques minutes, et puis plus rien pendant un moment, etc. Les seuls constats qui semblent pouvoir être posés sont : - que le phénomène ne semble jamais se produire quand l'écran change en permanence : en lançant xscreensaver ou un film, je ne l'ai jamais surpris à s'éteindre de manière inexpliquée. C'est quand l'image est fixe, mais qu'on tape du texte ou non, ça le fait ; - que l'écran qui n'a pas le focus *semble* s'exciter davantage que celui qui contient la fenêtre où je tape ceci, mais c'est difficile d'en être sûr... Voilà le phénomène bizarre. Si quelqu'un a une expérience utile à partager ou ne fut-ce qu'une idée de piste à explorer, je suis preneur :-) Je vous remercie d'avance, en tout cas de m'avoir lu. A+
'lut,
Tu peux essayer ta CG sur un autre poste avec 1 autre écran puis un
second pour vérifier si c'est la carte mère qui déconne ou si c'est la
carte graphique ?
f.
Le 04/03/2018 à 22:03, JF Straeten a écrit :
Chère Liste,
Je me permets de vous soumettre le problème que je rencontre sur une
nouvelle machine, après avoir essayé une série de choses qui ne le
résolvent pas, en espérant que quelqu'un aurait une expérience utile
en la matière, ou déjà une idée ou deux :-)
La machine est un NUC Intel, modèle NUC7i3DNKE.
Son processeur est un Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz
Sa carte graphique, selon lspci : Intel Corporation HD Graphics 620 (rev 02)
Elle a 4GB de RAM de marque 2-Power dans le slot inférieur et est
couplée à deux écrans DELL U3011 par des câbles HDMI to DVI-D Dual
Link (ce barebone n'a que deux connecteurs HDMI 2.0). Ça fait donc 2x
2560x1600 en résolution (et il peut aller jusqu'à 2x 4k, @60 Hz).
Enfin, elle est utilisée comme client léger sous LTSP, bootant sur un
serveur LTSP en NFS, mais l'aspect LTSP est indifférent.
Question OS, a priori tout est du stretch pur jus, à jour (donc tant
le serveur LTSP que l'OS utilisé par le client léger, c.-à-d. ici le
NUC).
Le souci rencontré est que les écrans clignotent de temps en temps :
ils s'éteignent (l'un ou l'autre ou les deux) une à deux secondes,
voire parfois 4-5, et puis se rallument...
Jusqu'ici, j'ai lancé le NUC sous stretch 32bits et amd64, sans et
puis avec le microcode Intel (avec, ça améliore sensiblement les
choses, bien que ça ne soit pas encore parfait), pour finir enfin en
buster, avec le noyau 4.14.
Toujours avec le microcode, les résultats varient en fonction de la
version du noyau : avec le 4.9 de stretch, c'est inutilisable
tellement ça clignote. C'est un poil mieux avec le 4.14 des backports,
toujours en stretch et ça devient utilisable, mais encore gênant avec
le 4.14 de buster.
Pour voir, j'ai booté aussi, toujours sous buster, avec le noyau
4.15.7 de sid, mais là c'est catastrophique (et pour cause : le noyau
désactive une partie du microcode Intel en signalant qu'il ne résout
pas Spectre (j'ai oublié les termes exacts, mais le microcode est
pourtant la dernière version de chez Intel : 20171117).
Enfin, à part en 4.15.7, j'ai chaque fois essayé avec les pilotes
graphiques modesetting et Intel. On ne peut toutefois pas dire que ça
fait une différence notable de comportement, et comme modesetting est
recommandé et semble (mais c'est subjectif) un poil plus rapide à
l'affichage, je tourne avec ce pilote, sous buster pour le moment.
Enfin encore, je viens aussi d'upgrader le bios du NUC à la dernière
version (039) du 22/02/2018.
Mais même si ça n'a plus rien à voir avec les débuts sous stretch, les
clignotements persistent quand même encore, sur l'un ou l'autre des
écrans, au point que j'hésite à laisser ça comme poste de travail en
l'état...
Inverser les écrans ne change rien ; un à la fois ou deux, c'est tout
à fait pareil ; les connecteurs sont bien vissés aux écrans, etc.
Rien n'y fait : c'est totalement erratique. L'un ou l'autre s'éteint
puis se rallume, jusqu'à parfois 10x sur quelques minutes, et puis
plus rien pendant un moment, etc.
Les seuls constats qui semblent pouvoir être posés sont :
- que le phénomène ne semble jamais se produire quand l'écran change
en permanence : en lançant xscreensaver ou un film, je ne l'ai
jamais surpris à s'éteindre de manière inexpliquée. C'est quand
l'image est fixe, mais qu'on tape du texte ou non, ça le fait ;
- que l'écran qui n'a pas le focus *semble* s'exciter davantage que
celui qui contient la fenêtre où je tape ceci, mais c'est difficile
d'en être sûr...
Voilà le phénomène bizarre. Si quelqu'un a une expérience utile à
partager ou ne fut-ce qu'une idée de piste à explorer, je suis
preneur :-)
Je vous remercie d'avance, en tout cas de m'avoir lu.
'lut, Tu peux essayer ta CG sur un autre poste avec 1 autre écran puis un second pour vérifier si c'est la carte mère qui déconne ou si c'est la carte graphique ? f. Le 04/03/2018 à 22:03, JF Straeten a écrit :
Chère Liste, Je me permets de vous soumettre le problème que je rencontre sur une nouvelle machine, après avoir essayé une série de choses qui ne le résolvent pas, en espérant que quelqu'un aurait une expérience utile en la matière, ou déjà une idée ou deux :-) La machine est un NUC Intel, modèle NUC7i3DNKE. Son processeur est un Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz Sa carte graphique, selon lspci : Intel Corporation HD Graphics 620 (rev 02) Elle a 4GB de RAM de marque 2-Power dans le slot inférieur et est couplée à deux écrans DELL U3011 par des câbles HDMI to DVI-D Dual Link (ce barebone n'a que deux connecteurs HDMI 2.0). Ça fait donc 2x 2560x1600 en résolution (et il peut aller jusqu'à 2x 4k, @60 Hz). Enfin, elle est utilisée comme client léger sous LTSP, bootant sur un serveur LTSP en NFS, mais l'aspect LTSP est indifférent. Question OS, a priori tout est du stretch pur jus, à jour (donc tant le serveur LTSP que l'OS utilisé par le client léger, c.-à-d. ici le NUC). Le souci rencontré est que les écrans clignotent de temps en temps : ils s'éteignent (l'un ou l'autre ou les deux) une à deux secondes, voire parfois 4-5, et puis se rallument... Jusqu'ici, j'ai lancé le NUC sous stretch 32bits et amd64, sans et puis avec le microcode Intel (avec, ça améliore sensiblement les choses, bien que ça ne soit pas encore parfait), pour finir enfin en buster, avec le noyau 4.14. Toujours avec le microcode, les résultats varient en fonction de la version du noyau : avec le 4.9 de stretch, c'est inutilisable tellement ça clignote. C'est un poil mieux avec le 4.14 des backports, toujours en stretch et ça devient utilisable, mais encore gênant avec le 4.14 de buster. Pour voir, j'ai booté aussi, toujours sous buster, avec le noyau 4.15.7 de sid, mais là c'est catastrophique (et pour cause : le noyau désactive une partie du microcode Intel en signalant qu'il ne résout pas Spectre (j'ai oublié les termes exacts, mais le microcode est pourtant la dernière version de chez Intel : 20171117). Enfin, à part en 4.15.7, j'ai chaque fois essayé avec les pilotes graphiques modesetting et Intel. On ne peut toutefois pas dire que ça fait une différence notable de comportement, et comme modesetting est recommandé et semble (mais c'est subjectif) un poil plus rapide à l'affichage, je tourne avec ce pilote, sous buster pour le moment. Enfin encore, je viens aussi d'upgrader le bios du NUC à la dernière version (039) du 22/02/2018. Mais même si ça n'a plus rien à voir avec les débuts sous stretch, les clignotements persistent quand même encore, sur l'un ou l'autre des écrans, au point que j'hésite à laisser ça comme poste de travail en l'état... Inverser les écrans ne change rien ; un à la fois ou deux, c'est tout à fait pareil ; les connecteurs sont bien vissés aux écrans, etc. Rien n'y fait : c'est totalement erratique. L'un ou l'autre s'éteint puis se rallume, jusqu'à parfois 10x sur quelques minutes, et puis plus rien pendant un moment, etc. Les seuls constats qui semblent pouvoir être posés sont : - que le phénomène ne semble jamais se produire quand l'écran change en permanence : en lançant xscreensaver ou un film, je ne l'ai jamais surpris à s'éteindre de manière inexpliquée. C'est quand l'image est fixe, mais qu'on tape du texte ou non, ça le fait ; - que l'écran qui n'a pas le focus *semble* s'exciter davantage que celui qui contient la fenêtre où je tape ceci, mais c'est difficile d'en être sûr... Voilà le phénomène bizarre. Si quelqu'un a une expérience utile à partager ou ne fut-ce qu'une idée de piste à explorer, je suis preneur :-) Je vous remercie d'avance, en tout cas de m'avoir lu. A+
JF Straeten
Hello, On Mon, Mar 05, 2018 at 07:46:09AM +0100, Hugues MORIN wrote: [...]
Il faudrai controler le materiel car ca ressemble a un probleme electronique (alimentation, carte video ou meme carte mere) plus que logiciel C est le genre de panne galere a resoudre
En effet, mais sans exclure un souci matériel, j'inclinais plus pour un problème logiciel... Le matos est intégralement neuf : barebone NUC, RAM et câbles sortis des boîtes et sachets avant les tests. Les écrans ne sont pas neufs, mais je suis certain qu'ils fonctionnent parfaitement, tous les deux, sur le client léger que le NUC est appelé à remplacer. Par contre, pour ce qui est logiciel, sans charger le microcode Intel au démarrage de la machine, ça fait clairement sapin de Noël quels que soient la distri et le kernel utilisés. Ensuite, avec microcode, ça s'améliore jusqu'à donner les moins mauvais résultats avec le 4.14 de buster. Enfin, je me dis aussi qu'un souci matériel se produirait tout le temps, indépendamment de l'affichage, non ? Or, avec un xscreensaver actif, ça ne le fait jamais, et avec un film jamais non plus si la fenêtre a le focus (je l'ai surpris une fois à s'éteindre brièvement si elle ne l'a pas). Merci pour retour en tout cas, -- JFS.
Hello,
On Mon, Mar 05, 2018 at 07:46:09AM +0100, Hugues MORIN wrote:
[...]
Il faudrai controler le materiel car ca ressemble a un probleme
electronique (alimentation, carte video ou meme carte mere) plus que
logiciel
C est le genre de panne galere a resoudre
En effet, mais sans exclure un souci matériel, j'inclinais plus pour
un problème logiciel...
Le matos est intégralement neuf : barebone NUC, RAM et câbles sortis
des boîtes et sachets avant les tests. Les écrans ne sont pas neufs,
mais je suis certain qu'ils fonctionnent parfaitement, tous les deux,
sur le client léger que le NUC est appelé à remplacer.
Par contre, pour ce qui est logiciel, sans charger le microcode Intel
au démarrage de la machine, ça fait clairement sapin de Noël quels que
soient la distri et le kernel utilisés. Ensuite, avec microcode, ça
s'améliore jusqu'à donner les moins mauvais résultats avec le 4.14 de
buster.
Enfin, je me dis aussi qu'un souci matériel se produirait tout le
temps, indépendamment de l'affichage, non ? Or, avec un xscreensaver
actif, ça ne le fait jamais, et avec un film jamais non plus si la
fenêtre a le focus (je l'ai surpris une fois à s'éteindre brièvement
si elle ne l'a pas).
Hello, On Mon, Mar 05, 2018 at 07:46:09AM +0100, Hugues MORIN wrote: [...]
Il faudrai controler le materiel car ca ressemble a un probleme electronique (alimentation, carte video ou meme carte mere) plus que logiciel C est le genre de panne galere a resoudre
En effet, mais sans exclure un souci matériel, j'inclinais plus pour un problème logiciel... Le matos est intégralement neuf : barebone NUC, RAM et câbles sortis des boîtes et sachets avant les tests. Les écrans ne sont pas neufs, mais je suis certain qu'ils fonctionnent parfaitement, tous les deux, sur le client léger que le NUC est appelé à remplacer. Par contre, pour ce qui est logiciel, sans charger le microcode Intel au démarrage de la machine, ça fait clairement sapin de Noël quels que soient la distri et le kernel utilisés. Ensuite, avec microcode, ça s'améliore jusqu'à donner les moins mauvais résultats avec le 4.14 de buster. Enfin, je me dis aussi qu'un souci matériel se produirait tout le temps, indépendamment de l'affichage, non ? Or, avec un xscreensaver actif, ça ne le fait jamais, et avec un film jamais non plus si la fenêtre a le focus (je l'ai surpris une fois à s'éteindre brièvement si elle ne l'a pas). Merci pour retour en tout cas, -- JFS.
JF Straeten
Re, On Mon, Mar 05, 2018 at 08:49:30AM +0100, Yann Serre wrote:
- la connectique (cas le plus souvent rencontré - tenter d'essuyer les broches ?)
Je vais essayer de changer de câble pour voir, en effet...
- la bande passante des câbles (un câble de mauvaise qualité ou bien qui touche un transformateur d'alimentation qui génère des perturbations électro-magnétiques et le câble n'est plus capable de transmettre 100% du signal)
En principe, elle est bonne : l'HDMI 2.0 monte jusqu'à 4K et ça sort en DVI-D Dual Link, nécessaire pour afficher la résolution native des écrans de 2560x1600. Maintenant, évidemment, la qualité des câbles, on n'en sait rien... Voilà les câbles, identiques et neufs : https://www.centralpoint.be/fr/c-bles-video-et-adaptateurs/manhattan/hdmi-cable-1x-hdmi-male-1x-dvi-d-24-plus-1-male-dual-link-black-1-8m-art-372503-num-5695993/
- la carte graphique est-elle correctement ventilée ?
Elle est intégrée au CPU, c'est de l'Intel.
si ce n'est pas une ventilation mécanique, la ventilation passive a-t-elle un flux d'air suffisant ?
Il y a un ventilo mécanique dans le NUC. On l'entend à fond au cold boot et il se calme ensuite...
(une sécurité pourrait couper brièvement l'étage de puissance de la carte graphique à une température maximale)
Tout est possible... Je cherche ;-)
Autre problème matériel : - un vieux moniteur peut avoir une alimentation dont un composant a besoin de se stabiliser au démarrage (montée en température), avant de provoquer une panne d'alimentation complète dans les semaines suivantes.
Les moniteurs datent de 2011 et 2012, certes, mais ce sont des DELL qui coûtaient un bras, et dont j'espère donc quand même que l'électronique est potable :-) En outre, ils fonctionnent parfaitement sur une autre machine, chacun seul ou les deux ensemble... Merci pour le retour en tout cas, -- JFS.
Re,
On Mon, Mar 05, 2018 at 08:49:30AM +0100, Yann Serre wrote:
- la connectique (cas le plus souvent rencontré - tenter d'essuyer
les broches ?)
Je vais essayer de changer de câble pour voir, en effet...
- la bande passante des câbles (un câble de mauvaise qualité ou bien
qui touche un transformateur d'alimentation qui génère des
perturbations électro-magnétiques et le câble n'est plus capable de
transmettre 100% du signal)
En principe, elle est bonne : l'HDMI 2.0 monte jusqu'à 4K et ça sort
en DVI-D Dual Link, nécessaire pour afficher la résolution native des
écrans de 2560x1600.
Maintenant, évidemment, la qualité des câbles, on n'en sait rien...
- la carte graphique est-elle correctement ventilée ?
Elle est intégrée au CPU, c'est de l'Intel.
si ce n'est pas une ventilation mécanique, la ventilation passive
a-t-elle un flux d'air suffisant ?
Il y a un ventilo mécanique dans le NUC. On l'entend à fond au cold
boot et il se calme ensuite...
(une sécurité pourrait couper brièvement l'étage de puissance de la
carte graphique à une température maximale)
Tout est possible... Je cherche ;-)
Autre problème matériel :
- un vieux moniteur peut avoir une alimentation dont un composant a besoin
de se stabiliser au démarrage (montée en température), avant de provoquer
une panne d'alimentation complète dans les semaines suivantes.
Les moniteurs datent de 2011 et 2012, certes, mais ce sont des DELL
qui coûtaient un bras, et dont j'espère donc quand même que
l'électronique est potable :-) En outre, ils fonctionnent parfaitement
sur une autre machine, chacun seul ou les deux ensemble...
Re, On Mon, Mar 05, 2018 at 08:49:30AM +0100, Yann Serre wrote:
- la connectique (cas le plus souvent rencontré - tenter d'essuyer les broches ?)
Je vais essayer de changer de câble pour voir, en effet...
- la bande passante des câbles (un câble de mauvaise qualité ou bien qui touche un transformateur d'alimentation qui génère des perturbations électro-magnétiques et le câble n'est plus capable de transmettre 100% du signal)
En principe, elle est bonne : l'HDMI 2.0 monte jusqu'à 4K et ça sort en DVI-D Dual Link, nécessaire pour afficher la résolution native des écrans de 2560x1600. Maintenant, évidemment, la qualité des câbles, on n'en sait rien... Voilà les câbles, identiques et neufs : https://www.centralpoint.be/fr/c-bles-video-et-adaptateurs/manhattan/hdmi-cable-1x-hdmi-male-1x-dvi-d-24-plus-1-male-dual-link-black-1-8m-art-372503-num-5695993/
- la carte graphique est-elle correctement ventilée ?
Elle est intégrée au CPU, c'est de l'Intel.
si ce n'est pas une ventilation mécanique, la ventilation passive a-t-elle un flux d'air suffisant ?
Il y a un ventilo mécanique dans le NUC. On l'entend à fond au cold boot et il se calme ensuite...
(une sécurité pourrait couper brièvement l'étage de puissance de la carte graphique à une température maximale)
Tout est possible... Je cherche ;-)
Autre problème matériel : - un vieux moniteur peut avoir une alimentation dont un composant a besoin de se stabiliser au démarrage (montée en température), avant de provoquer une panne d'alimentation complète dans les semaines suivantes.
Les moniteurs datent de 2011 et 2012, certes, mais ce sont des DELL qui coûtaient un bras, et dont j'espère donc quand même que l'électronique est potable :-) En outre, ils fonctionnent parfaitement sur une autre machine, chacun seul ou les deux ensemble... Merci pour le retour en tout cas, -- JFS.
JF Straeten
Re, On Mon, Mar 05, 2018 at 09:27:11AM +0100, wrote: [...]
Pareil, c'était dans le message : seuls ou à deux, même combat ;) Merci pour le retour, -- JFS.
JF Straeten
Salut, On Mon, Mar 05, 2018 at 09:59:13AM +0100, fab wrote:
Tu peux essayer ta CG sur un autre poste avec 1 autre écran puis un second pour vérifier si c'est la carte mère qui déconne ou si c'est la carte graphique ?
Tout est intégré, c'est un NUC : https://www.centralpoint.be/fr/barebones-pc-poste-de-travail/intel/nuc7i3dnke-art-blknuc7i3dnk2e-num-6960343/ Si truc déconne, tout déconne à mon humble avis... Merci quand même, -- JFS.
Salut,
On Mon, Mar 05, 2018 at 09:59:13AM +0100, fab wrote:
Tu peux essayer ta CG sur un autre poste avec 1 autre écran puis un
second pour vérifier si c'est la carte mère qui déconne ou si c'est
la carte graphique ?
Salut, On Mon, Mar 05, 2018 at 09:59:13AM +0100, fab wrote:
Tu peux essayer ta CG sur un autre poste avec 1 autre écran puis un second pour vérifier si c'est la carte mère qui déconne ou si c'est la carte graphique ?
Tout est intégré, c'est un NUC : https://www.centralpoint.be/fr/barebones-pc-poste-de-travail/intel/nuc7i3dnke-art-blknuc7i3dnk2e-num-6960343/ Si truc déconne, tout déconne à mon humble avis... Merci quand même, -- JFS.
Yann Serre
Le 05/03/2018 à 13:59, JF Straeten a écrit :
Les moniteurs datent de 2011 et 2012, certes, mais ce sont des DELL qui coûtaient un bras, et dont j'espère donc quand même que l'électronique est potable:-) En outre, ils fonctionnent parfaitement sur une autre machine, chacun seul ou les deux ensemble...
J'ai 6 Samsung qui coûtaient 6 bras dont 4 sont tombés en panne le même trimestre après 10 ans de bons et loyaux services. Passé à Asus depuis.
Le 05/03/2018 à 13:59, JF Straeten a écrit :
Les moniteurs datent de 2011 et 2012, certes, mais ce sont des DELL
qui coûtaient un bras, et dont j'espère donc quand même que
l'électronique est potable:-) En outre, ils fonctionnent parfaitement
sur une autre machine, chacun seul ou les deux ensemble...
J'ai 6 Samsung qui coûtaient 6 bras dont 4 sont tombés en panne le même
trimestre après 10 ans de bons et loyaux services. Passé à Asus depuis.
Les moniteurs datent de 2011 et 2012, certes, mais ce sont des DELL qui coûtaient un bras, et dont j'espère donc quand même que l'électronique est potable:-) En outre, ils fonctionnent parfaitement sur une autre machine, chacun seul ou les deux ensemble...
J'ai 6 Samsung qui coûtaient 6 bras dont 4 sont tombés en panne le même trimestre après 10 ans de bons et loyaux services. Passé à Asus depuis.
JF Straeten
Re, On Mon, Mar 05, 2018 at 04:19:47PM +0100, Yann Serre wrote:
Le 05/03/2018 à 13:59, JF Straeten a écrit :
Les moniteurs datent de 2011 et 2012, certes, mais ce sont des DELL qui coûtaient un bras, et dont j'espère donc quand même que l'électronique est potable:-) En outre, ils fonctionnent parfaitement sur une autre machine, chacun seul ou les deux ensemble...
J'ai 6 Samsung qui coûtaient 6 bras dont 4 sont tombés en panne le même trimestre après 10 ans de bons et loyaux services. Passé à Asus depuis.
Certes, j'entends bien, mais les écrans fonctionnent parfaitement sur un client Wyse actuellement... Merci, -- JFS.
Re,
On Mon, Mar 05, 2018 at 04:19:47PM +0100, Yann Serre wrote:
Le 05/03/2018 à 13:59, JF Straeten a écrit :
> Les moniteurs datent de 2011 et 2012, certes, mais ce sont des DELL
> qui coûtaient un bras, et dont j'espère donc quand même que
> l'électronique est potable:-) En outre, ils fonctionnent parfaitement
> sur une autre machine, chacun seul ou les deux ensemble...
J'ai 6 Samsung qui coûtaient 6 bras dont 4 sont tombés en panne le même
trimestre après 10 ans de bons et loyaux services. Passé à Asus depuis.
Certes, j'entends bien, mais les écrans fonctionnent parfaitement sur
un client Wyse actuellement...
Re, On Mon, Mar 05, 2018 at 04:19:47PM +0100, Yann Serre wrote:
Le 05/03/2018 à 13:59, JF Straeten a écrit :
Les moniteurs datent de 2011 et 2012, certes, mais ce sont des DELL qui coûtaient un bras, et dont j'espère donc quand même que l'électronique est potable:-) En outre, ils fonctionnent parfaitement sur une autre machine, chacun seul ou les deux ensemble...
J'ai 6 Samsung qui coûtaient 6 bras dont 4 sont tombés en panne le même trimestre après 10 ans de bons et loyaux services. Passé à Asus depuis.
Certes, j'entends bien, mais les écrans fonctionnent parfaitement sur un client Wyse actuellement... Merci, -- JFS.
JF Straeten
Re, On Mon, Mar 05, 2018 at 01:45:25PM +0100, JF Straeten wrote: [...]
Par contre, pour ce qui est logiciel, sans charger le microcode Intel au démarrage de la machine, ça fait clairement sapin de Noël quels que soient la distri et le kernel utilisés. Ensuite, avec microcode, ça s'améliore jusqu'à donner les moins mauvais résultats avec le 4.14 de buster.
Pour renchérir sur la partie logicielle, compte tenu de ceci : https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1604819 j'ai essayé avec plus vieux et booté le NUC sur une jessie. On est toutefois à des versions de noyau et de serveur X encore antérieures à celles rapportées comme fonctionnelles dans ce message, mais ça permet quand même quelques observations, aussi intéressantes que délirantes : - sans installer le microcode Intel, et avec un serveur X en 16 bit, c'est la foire totale : sapin de Noël ; - en installant le microcode et en forçant le serveur X à 24 bit, c'est nettement mieux : ça ne clignote que de temps en temps ; NB1. je n'ai toutefois pas la preuve que le microcode est chargé, je ne le vois pas dans un dmesg -T (BTW, y a-t-il un autre moyen de vérifier ?) NB2. oui, j'ai fait le bleu en troubleshooting en faisant varier deux paramètres à la fois, j'en suis conscient :-) - le serveur X semble adresser la carte avec le driver VESA, d'après le log ; - enfin, en forçant le serveur X à "intel", X ne démarre pas car "No device found" : je pense que le pilote est trop vieux pour la carte ; - et le meilleur pour la fin : quelle que soit la situation ci-dessus, le clignotement n'apparaît *jamais* quand il n'y a que la root window d'affichée. C'est au lancement de quelques rxvt (ou un Thunar) que ça commence à foirer. Mais en les fermant, le clignotement s'arrête net. Idem avec le screensaver : le lancer fait réapparaître l'écran, et il se lance normalement, pourvu que ça soit sur la root window uniquement, au terme de son délai DPMS, sans que ça ne foire... NB1. ce poste tourne sous i3, donc au lancement il n'y a qu'une barre de statut indiquant le n° de workspace sur la root window. Voilà, si quelqu'un y comprend quelque chose ou a des idées, je suis preneur parce que j'y perds mes pingouins pour le moment :-) Je remercie aussi encore ceux qui se sont penchés sur le problème. A+ -- JFS.
Re,
On Mon, Mar 05, 2018 at 01:45:25PM +0100, JF Straeten wrote:
[...]
Par contre, pour ce qui est logiciel, sans charger le microcode
Intel au démarrage de la machine, ça fait clairement sapin de Noël
quels que soient la distri et le kernel utilisés. Ensuite, avec
microcode, ça s'améliore jusqu'à donner les moins mauvais résultats
avec le 4.14 de buster.
Pour renchérir sur la partie logicielle, compte tenu de ceci :
j'ai essayé avec plus vieux et booté le NUC sur une jessie.
On est toutefois à des versions de noyau et de serveur X encore
antérieures à celles rapportées comme fonctionnelles dans ce message,
mais ça permet quand même quelques observations, aussi intéressantes
que délirantes :
- sans installer le microcode Intel, et avec un serveur X en 16 bit,
c'est la foire totale : sapin de Noël ;
- en installant le microcode et en forçant le serveur X à 24 bit,
c'est nettement mieux : ça ne clignote que de temps en temps ;
NB1. je n'ai toutefois pas la preuve que le microcode est chargé, je
ne le vois pas dans un dmesg -T (BTW, y a-t-il un autre moyen de
vérifier ?)
NB2. oui, j'ai fait le bleu en troubleshooting en faisant varier
deux paramètres à la fois, j'en suis conscient :-)
- le serveur X semble adresser la carte avec le driver VESA, d'après
le log ;
- enfin, en forçant le serveur X à "intel", X ne démarre pas car "No
device found" : je pense que le pilote est trop vieux pour la
carte ;
- et le meilleur pour la fin : quelle que soit la situation ci-dessus,
le clignotement n'apparaît *jamais* quand il n'y a que la root
window d'affichée. C'est au lancement de quelques rxvt (ou un
Thunar) que ça commence à foirer. Mais en les fermant, le
clignotement s'arrête net. Idem avec le screensaver : le lancer fait
réapparaître l'écran, et il se lance normalement, pourvu que ça soit
sur la root window uniquement, au terme de son délai DPMS, sans que
ça ne foire...
NB1. ce poste tourne sous i3, donc au lancement il n'y a qu'une
barre de statut indiquant le n° de workspace sur la root window.
Voilà, si quelqu'un y comprend quelque chose ou a des idées, je suis
preneur parce que j'y perds mes pingouins pour le moment :-)
Je remercie aussi encore ceux qui se sont penchés sur le problème.
Re, On Mon, Mar 05, 2018 at 01:45:25PM +0100, JF Straeten wrote: [...]
Par contre, pour ce qui est logiciel, sans charger le microcode Intel au démarrage de la machine, ça fait clairement sapin de Noël quels que soient la distri et le kernel utilisés. Ensuite, avec microcode, ça s'améliore jusqu'à donner les moins mauvais résultats avec le 4.14 de buster.
Pour renchérir sur la partie logicielle, compte tenu de ceci : https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1604819 j'ai essayé avec plus vieux et booté le NUC sur une jessie. On est toutefois à des versions de noyau et de serveur X encore antérieures à celles rapportées comme fonctionnelles dans ce message, mais ça permet quand même quelques observations, aussi intéressantes que délirantes : - sans installer le microcode Intel, et avec un serveur X en 16 bit, c'est la foire totale : sapin de Noël ; - en installant le microcode et en forçant le serveur X à 24 bit, c'est nettement mieux : ça ne clignote que de temps en temps ; NB1. je n'ai toutefois pas la preuve que le microcode est chargé, je ne le vois pas dans un dmesg -T (BTW, y a-t-il un autre moyen de vérifier ?) NB2. oui, j'ai fait le bleu en troubleshooting en faisant varier deux paramètres à la fois, j'en suis conscient :-) - le serveur X semble adresser la carte avec le driver VESA, d'après le log ; - enfin, en forçant le serveur X à "intel", X ne démarre pas car "No device found" : je pense que le pilote est trop vieux pour la carte ; - et le meilleur pour la fin : quelle que soit la situation ci-dessus, le clignotement n'apparaît *jamais* quand il n'y a que la root window d'affichée. C'est au lancement de quelques rxvt (ou un Thunar) que ça commence à foirer. Mais en les fermant, le clignotement s'arrête net. Idem avec le screensaver : le lancer fait réapparaître l'écran, et il se lance normalement, pourvu que ça soit sur la root window uniquement, au terme de son délai DPMS, sans que ça ne foire... NB1. ce poste tourne sous i3, donc au lancement il n'y a qu'une barre de statut indiquant le n° de workspace sur la root window. Voilà, si quelqu'un y comprend quelque chose ou a des idées, je suis preneur parce que j'y perds mes pingouins pour le moment :-) Je remercie aussi encore ceux qui se sont penchés sur le problème. A+ -- JFS.
