Système : jessie redémarre aléatoirement

Support Debian
#1

Bonjour à tous,

fraîchement inscrit sur le forum, voici mon premier post.
Je souhaite corriger un problème de reboot aléatoire dans Jessie.

Ayant cherché longuement une solution, mais sans succès, je vous livre ici l’état de mes recherches.
Peut-être quelque chose d’évident ne m’a pas sauté aux yeux.

merci d’avance à ceux qui liront jusqu’au bout…
(j’ai fait beaucoup de tests et de recherches)

1/ symptômes :
Jessie reboot aléatoirement dans les deux cas suivants :

  1. pendant une lecture d’un fichier vidéo par vlc (fréquence du problème : à chaque fois, pourvu que la vidéo soit suffisamment longue)
  2. au lancement de certaines applications (iceweasel, vlc, mpv, pcmanfm), soit par commande dans un xterm, soit par raccourcis (fréquence du problème : aléatoire)

remarque :
il s’agit d’un reboot sâle : au redémarrage, fsck me dit que les partions n’ont pas été démontées proprement.

le problème : les logs sont vides de toutes infos relatives à ce reboot et à son origine…
(ou alors je ne regarde pas les bons…)

2/ ma config :

  • carte mère : gigabyte socket775 avec une puce intégrée GeForce 9400 désactivée dans le bios
  • processeur : intel Q9650
  • ram : 8Go
  • carte graphique : geforce 750ti

2’/ mon install :

faite depuis une netinst dont la somme de contrôle est OK.

uname -a :

Linux jessie 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux

  • gestionnaire de connexion : xdm (gdm non installé, ni kdm, ni d’autres)
  • getionnaire de fenêtres : openbox (gnome non installé, ni kde, ni d’autres)
  • pilotes graphique : drivers nvidia propriétaires (installation “à la Debian” avec dkms, et pilote nouveau blacklisté)

cat /etc/apt/sources.list :

deb http://httpredir.debian.org/debian/ jessie main contrib non-free
deb-src http://httpredir.debian.org/debian/ jessie main contrib non-free

deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free

deb http://httpredir.debian.org/debian/ jessie-updates main contrib non-free
deb-src http://httpredir.debian.org/debian/ jessie-updates main contrib non-free

Utilisant Steam, (installé “à la Debian”) , j’ai également ajouté ceci à mon install :

dpkg --add-architecture i386

3/ les éléments contrôlés :

  • alimentation électrique : non en cause (car tests avec plusieurs alim différentes)
  • RAM : non en cause (car tests croisés avec plusieurs barrettes)
  • processeur : non en cause (car tests avec proc e8400)
  • problème matériel défectueux ? : sans doute non en cause (car pas de reboot intempestif sous wheezy, avec cette config et le même type d’installation)
  • ce n’est pas un cronjob qui fait redémarrer la machine.
  • les logs sont vierges de toutes informations.

4/ complément d’info et faits étranges :
a)
en déconnectant la carte graphique additionnelle 750ti,
en activant la carte graphique intégrée 9400 dans le bios,
en peuplant la RAM avec plus d’une barrette,
=> alors l’affichage vidéo dans l’installeur debian de JESSIE se corrompt (lignes grises, couleurs en négatif, ou écran noir, …) et parfois le clavier “ne répond plus”.

b)
en déconnectant la carte graphique additionnelle 750ti,
en activant la carte graphique intégrée 9400 dans le bios,
en peuplant la RAM avec une seule et unique barrette,
=> alors l’affichage vidéo de l’installeur debian de JESSIE n’est pas corrompu.

c)
aucune corruption vidéo n’a lieu, quelle que soit la config matérielle, avec l’installeur debian de WHEEZY.

d)
l’utilisation des pilotes propriétaires disponibles dans jessie-backport amplifie de façon notable le phénomène de reboot intempsetif (les reboots sont plus nombreux, surtout dans les jeux).

Voilà pour les investigations et l’état de mes recherches.
merci d’avoir lu jusqu’ici !!!

J’espère avoir indiqué les infos nécessaires à l’analyse de mon problème…
Si vous avez une idée, ou besoin d’info complémentaires, n’hésitez pas !

mk

#2

Bonjour,

Et sans passer par dkms mais en utilisant le module tout prêt, ça donnerait quoi ?

Debian – Détails du paquet nvidia-kernel-340.96 dans jessie

#3

Salut
As tu essaye de modifier les préférences de vlc
decodage materiel

as tu essayé avec le lecteur video mpv

#4

Testé logiciellement les barrettes de RAM avec les binaires :

  • memtest86, ou
  • memtest86+

Les deux logiciels sont dans les dépots officiels.

La probabilité pour que l’une soit défectueuse semble exister …

#5

Je me demande si c’est pas sa CM qui déconne, car à part ça il a quasiment tout testé (il a déjà fait des tests croisés avec d’autres barrettes de RAM).

#6

De deux choses l’une :

  • tout dépend de ce qu’il appelle tester, car si c’est juste, je déplace et je mets dans une autre carte-mère … c’est une méthode empirique mais pas très probante …
  • de l’intérêt des logiciels sus-nommés, tu mets tes deux barrettes RAM, tu exécutes le binaire en question. L’une semble défectueuse, tu la prends, tu la mets de côté ; tu prends l’autre, et la mets à sa place, et tu relances le test logiciel … etc … etc … y’a que comme ça que tu peux te rendre + ou - compte que cela vienne du connecteur.
    Et pour finir, tu t’assures que la barrette qui semblait défectueuse, tu la mets sur le connecteur de celle qui semble efficiente, et tu relances le test logiciel … oui, ça prend du temps !
#7

Bah pour ce qui est de tester la carte-mère en elle-même je vois pas comment il pourrait faire autrement à part prendre une autre carte-mère, à moins de prendre un oscilloscope et de tester les composants un par un :smiley: (c’est de l’ironie).

Je suis d’accord avec les binaires que tu as cité (Memtest pour rappel), mais bon moi quand il me dit :

je sous-entends que c’est ce qu’il a déjà fait donc je reviens pas dessus.

Mais bon déjà même sans lancer Memtest, quand t’as plusieurs barrettes à disposition tu peux t’orienter vers une éventuelle barrette défaillante, pour peu que les caractéristiques des barrettes soient identiques bien sûr et compatibles avec les prescriptions de la carte-mère :smiley:

#8

Bonsoir
moi ce qui me choque c est une GTX750TI avec un driver non-free 340.96
normalement cette carte est en maxwell , a vérifier avec la commande "lspci"
utiliser l utilitaire nvidia-detect du paquet “nvidia-detect” pour connaitre le driver conseillé
l utilisation des backports pour le noyau et le driver peut résoudre le problème .
noyau 4.7 présent dans les backports de jessie
driver 367.xx présent dans les backports de jessie
il peut y avoir autre chose comme souci mais a mon avis le noyau 3.16 doit faire “la grimace” avec ce gpu au démarrage .

#9

Bonjour à tous,

merci pour vos nombreuse réponses !

@jcsm33 :
-> je n’avais pas envisager cette possibilité, je vais tester ça.
(je créerai sans doute un nouveau fil de discussion sur la différence entre :
" l’utilisation de DKMS" versus " l’utilisation des modules tout prêt",
car c’est un peu flou pour moi).

@grandtoubab :
-> avec mpv, la machine peut crasher directement au lancement de l’application (plutôt que durant la lecture, comme dans le cas de l’utilisation de vlc).
-> avec vlc et le décodage matériel : je vais tester ça.

@PengouinPdt :
-> j’ai lancé memtest86+ cette nuit : (lancé avec les options par défaut, et avec la totalité des 4 barrettes peuplant la machine) , il a fait 5 passes et n’a trouvé AUCUNE ERREUR.
(dans ce cas précis -> “aucune erreur”) est-il utile de refaire memtest86+ en mettant les barrettes une à une ?

(je n’avais effectivement pas fait lancé memtest86+ plus tôt, j’ai été négligent sur ce point).

@GOGI :
-> l’oscilloscope est sur le bureau en train de chauffer :wink:

@robert2a :
-> l’utilisation du driver (367.xx) présent dans les backports amplifie le phénomène de reboot MAIS je n’avais pris des backports QUE les drivers de la carte graphique (en particulier, je n’avais pas mis à jour le noyau dans sa verison 4.x).
a => je vais donc faire le test avec drivers bpo ET kernel bpo.
b => j’ai en outre vu que les drivers bpo ont évolués : ils sont en 365.57 maintenant, alors que la dernière fois que j’ai testé, ils étaient en 367.44. => donc à tester aussi :wink:

et le résultat des commandes :
nvidia-detect :

Detected NVIDIA GPUs:
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] [10de:1380] (rev a2)
Your card is supported by the default drivers.
It is recommended to install the
nvidia-driver
package.

matériel supporté par le driver 340.x : (http://us.download.nvidia.com/XFree86/Linux-x86_64/340.65/README/supportedchips.html)

GeForce GTX 750 Ti 0x1380 E

donc a priori, c’est bon.

@ tous :

Bon, ben je sais comment occuper mon weekend :wink:
merci encore et bon weekend à vous !

#10

Non, et tant mieux :wink:

Et, désolé, car dans l’immédiat, je n’ai pas d’autres idées, car vu les symptômes décrits, j’étais prêt à parier pour une défaillance matérielle. :stuck_out_tongue:

#11

@PengouinPdt :
je me demande si je n’aurais pas préféré que ce soit une défaillance de RAM en fait … :wink:
je la changeais et zou, le problème aurait été résolu…

en tout cas, ça m’a permis de découvrir memtest que je n’avais jamais utilisé… :confused:

#12

avec vlc et le décodage matériel : je vais tester ça.

Plutôt “sans décodage matériel” choisir desactiver

Nvidia et Linux…:grinning:

#13

Bonjour
la génération képler est compatible avec le 340.96 (serie GTX7XX )
toi => NVIDIA Corporation GM107
le GM107 fait partie de la génération maxwell (serie GTX9xx)
la GTX750TI a été le premier chipset maxwell mit sur le marché (puis 960 , 970 et 980 )
ça vaut le coup de tenter noyau 4.7 et driver 367.xx .
il est important de vérifier que DRI2 se charge bien et que la prise en charge de la 3D soit correcte .
je pense que quelques paquets supplémentaires seront pris dans les backports aussi.
comme tu parle de reboot sur une utilisation de certaines applications .
regarde ton fichier /var/log/Xorg.0.log et le /var/log/syslog a la recherche d erreurs
aprés si cela ne change rien , pas d idées sur le fautif

#14

Hello,

je viens de procéder à ceci :
- ajout des jessie-backports dans le sources.list
- install du kernel 4.7 issu des bpo
- install des pilotes 367. 57 issus des bpo

(redémarrage volontaire de la machine)
puis lancement de vlc, lecture de fichiers vidéo,
et lancement des appli qui pouvaient entraîner le reboot intempestif.

et pour le moment, le problème n’est pas réapparu !

Donc, bien encourageant !
Si ma machine ne présente pas le problème d’ici la fin du weekend, je passerai le fil en “RESOLU”.
Je croise les doigts :wink:

@robert2a
1/ -> qu’entends-tu par “vérifier que DRI2 se charge bien” ?

$ glxinfo | grep -i “render”

direct rendering: Yes
OpenGL renderer string: GeForce GTX 750 Ti/PCIe/SSE2
GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth,
GL_KHR_robustness, GL_KTX_buffer_region, GL_NVX_conditional_render,
GL_NV_conditional_render, GL_NV_copy_depth_to_color, GL_NV_copy_image,
GL_NV_parameter_buffer_object2, GL_NV_path_rendering,
GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted,
GL_KHR_robustness, GL_KTX_buffer_region, GL_NVX_conditional_render,
GL_NV_conditional_render, GL_NV_copy_depth_to_color, GL_NV_copy_image,
GL_NV_parameter_buffer_object2, GL_NV_path_rendering,
GL_EXT_primitive_bounding_box, GL_EXT_render_snorm, GL_EXT_robustness,
GL_NV_conditional_render, GL_NV_copy_buffer, GL_NV_copy_image,
GL_NV_packed_float_linear, GL_NV_path_rendering,
GL_OES_fbo_render_mipmap, GL_OES_geometry_point_size,

est-ce ça que tu voulais vérifier ?

2/ concernant les fichiers de log :
j’étais déjà allé jeter un oeil dans ces deux fichiers de log (et leurs archives plus anciennes, *.2.gz , …) ,
mais il semble ne pas y avoir d’info relatives à mon problème dedans…
si le problème reviens, je posterai un extrait des fichiers de log.

bonne fin de weekend !!

#15

je te donne un exemple pris sur mon log

[     7.171] (II) NVIDIA(0): NVIDIA GPU GeForce GTX 970 (GM204-A) at PCI:4:0:0 (GPU-0)
[     7.171] (--) NVIDIA(0): Memory: 4194304 kBytes
[     7.171] (--) NVIDIA(0): VideoBIOS: 84.04.1f.00.f1
[     7.171] (II) NVIDIA(0): Detected PCI Express Link width: 16X
[     7.171] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID for display
[     7.171] (**) NVIDIA(0):     device Idek Iiyama PLE2483H (DFP-0) (Using EDID
[     7.171] (**) NVIDIA(0):     frequencies has been enabled on all display devices.)

[     7.290] (==) NVIDIA(0): DPMS enabled
[     7.290] (II) Loading sub module "dri2"
[     7.290] (II) LoadModule: "dri2"
[     7.290] (II) Module "dri2" already built-in
[     7.290] (II) NVIDIA(0): [DRI2] Setup complete
[     7.290] (II) NVIDIA(0): [DRI2]   VDPAU driver: nvidia
[     7.291] (--) RandR disabled
[     7.294] (II) SELinux: Disabled on system
[     7.295] (II) Initializing extension GLX
[     7.295] (II) Indirect GLX disabled.

je pense que maintenant tu a une meilleure prise en charge du materiel par le noyau 4.7

#16

rhaaaaaa… (hurlement primaire => ça a rebooté )

$ cat /var/log/Xorg.0.log | grep -i "dri2

[ 32.525] (II) Loading sub module “dri2”
[ 32.525] (II) LoadModule: “dri2”
[ 32.525] (II) Module “dri2” already built-in
[ 32.525] (II) NVIDIA(0): [DRI2] Setup complete
[ 32.525] (II) NVIDIA(0): [DRI2] VDPAU driver: nvidia

je regarde pour mettre des extraits de log pertinnets (“au moment du reboot”)…

#17

Concernant opengl, est-ce que la libegl1-mesa a bien basculé en version bpo elle aussi ?

#18

Plutôt :
$ grep -i "dri2" /var/log/Xorg.0.log

:wink:

#19

a priori tu a un autre souci , mais je te conseille de rester dans cette configuration pendant la recherche du problème .
j’ai des machines en 775 avec du dual et quad core (en autre du q9550 en quad ) sur carte mere asus
avec du GTX750 (TI) stretch + lightdm + mate sans probleme (j ai commencé avec wheezy )
l alimentation il semble que tu soit sur quelle est hors de cause ?
dans le bios de la CM tu n a pas d overclocking ?
le retour de lspci pour voir la totalité du materiel ?

ps: peut etre du coté de l acpi , voir si le syslog ne te donne pas des erreurs
désactiver les mises en veille de debian dans mate voir si ça change quelque chose

#20

Hello,
i’m back

@jcsm33 :
effectivement CE paquet (libegl1-mesa) était resté dans sa version “jessie” et pas dans sa version “jessie-backports”.
je viens de le mettre à jour.

(question offtopic) => doit-on le signaler comme un bug dans la gestion des dépendances?

@PengouinPdt :
(question offtopic) : ce que tu proposes (dans l’écriture de la commande avec grep), ça permet une optimisation de la commande/gestion en mémoire ou le résultat peut (dans certain cas) être différent ?

ou est-ce vraiment l’élégante manière d’utiliser cette commande ?
(-> ce n’est pas un sarcasme de ma part que d’utiliser “élégante” dans cette phrase; mon profs de maths l’utilisait comme ça pour nous expliquer ses démonstrations).


@robert2a :
1/ pour l’alim j’ai fait des tests croisés (Corsair 400W, Corsair 430W et une autre Corsair 430W)
normalement, pour cette gamme de cartes, la puissance de l’alim est préconisée à 400W.

2/ pas d’overclocking sur ma machine.

3/ $ lspci

00:00.0 Host bridge: NVIDIA Corporation MCP79 Host Bridge (rev b1)
00:00.1 RAM memory: NVIDIA Corporation MCP79 Memory Controller (rev b1)
00:03.0 ISA bridge: NVIDIA Corporation MCP79 LPC Bridge (rev b2)
00:03.1 RAM memory: NVIDIA Corporation MCP79 Memory Controller (rev b1)
00:03.2 SMBus: NVIDIA Corporation MCP79 SMBus (rev b1)
00:03.3 RAM memory: NVIDIA Corporation MCP79 Memory Controller (rev b1)
00:03.4 RAM memory: NVIDIA Corporation MCP79 Memory Controller (rev b1)
00:03.5 Co-processor: NVIDIA Corporation MCP79 Co-processor (rev b1)
00:04.0 USB controller: NVIDIA Corporation MCP79 OHCI USB 1.1 Controller (rev b1)
00:04.1 USB controller: NVIDIA Corporation MCP79 EHCI USB 2.0 Controller (rev b1)
00:06.0 USB controller: NVIDIA Corporation MCP79 OHCI USB 1.1 Controller (rev b1)
00:06.1 USB controller: NVIDIA Corporation MCP79 EHCI USB 2.0 Controller (rev b1)
00:08.0 Audio device: NVIDIA Corporation MCP79 High Definition Audio (rev b1)
00:09.0 PCI bridge: NVIDIA Corporation MCP79 PCI Bridge (rev b1)
00:0a.0 Ethernet controller: NVIDIA Corporation MCP79 Ethernet (rev b1)
00:0b.0 SATA controller: NVIDIA Corporation MCP79 AHCI Controller (rev b1)
00:0c.0 PCI bridge: NVIDIA Corporation MCP79 PCI Express Bridge (rev b1)
00:16.0 PCI bridge: NVIDIA Corporation MCP79 PCI Express Bridge (rev b1)
02:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev a2)
02:00.1 Audio device: NVIDIA Corporation Device 0fbc (rev a1)
03:00.0 IDE interface: JMicron Technology Corp. JMB368 IDE controller

4/ je n’ai pas de mise en veille active sur ma machine (uniquement un économiseur d’écran : xscreensaver).

5/ dans le log de syslog, j’ai 1 warning conrcernant l’acpi :

ACPI Warning: SystemIO range 0x0000000000001C80-0x0000000000001CBF conflicts with OpRegion 0x0000000000001C80-0x0000000000001C85 (\SM00) (20160422/utaddress-255)

mais à part ça, ça à l’air d’aller de ce point de vue là…non ?

(les fichiers arrivent)