Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[Résolu] Hard freeze du kernel

Tutul3

Bonsoir 🙂

Depuis une précédente mise à jour du système, j'ai commencé à rencontrer des freeze assez random mais souvent dans l'heure du démarrage. En voulant retourner sur une version antérieur, j'ai redémarrer en mode terminal pour faire la regression mais le kernel à freeze durant la procédure ce qui a casser la totalité du système. J'avais jeter l'éponge surtout que j'avais de gros travaux à faire et pas de temps libre pour m'occuper de cela. Hier j'ai réinstaller complètement le système mais j'ai du le faire en lowgraphic :/ Une fois l'installation terminé, j'ai pu reboot sur le nouveau système et tout à marcher pendant 30 minutes. L'ordinateur à un dual-boot avec un windows qui lui marche très bien. Mon hardware est overclocker depuis plus d'un an et à passer tout les test de stabilité sur les deux OS. Voici mes observations :

- Le CPU n'est pas en surchauffe et l'alimentation est stable
- La RAM à passer les test sans erreur détecter au bout de 12 heures
- Le jour de la première mise à jour, j'ai rajouter un disque dure qui contient la partition home et ma session Windows, windows n'a aucun soucis
- Je suis obligé de démarrer avec nomodeset sinon l'écran se corrompt lors du passage de la résolution de base de KMS vers ma native
- J'utilise le driver nvidia officiel qui est à jour (nouveau est bien retirer , le système à marcher comme ça depuis plus d'un an sans soucis)
- Je sais que c'est le kernel qui réagit pas car les commandes SYSRQ ne fonctionne plus (oui elles sont bien activé j'ai même fait des test entre deux freeze)
- De plus, lors d'un freeze, les clé usb ne clignotent plus quand je les branches, ce qui indique que le kernel ne les détecte pas
- L'écran reste allumé et continue de montrer la dernière image
- La carte ethernet reste allumé et connecté au modem (en tout cas, ce dernier détecte encore qu'il est branché à qqch mais plus moyen de voir l'OS)
- Aucun trace dans les logs de Xorg ou du kernel (oui j'avais penser à un soucis de Xorg à la base), dmesg ne montre rien avant le freeze et le journal ne contient rien d’inhabituel quand je regarde le boot précédent
- Le kernel semble bien activer le watchdog sur mes core mais rien ne se produit une fois que le freeze est là
- Le problème semble plus courant quand X tourne, j'ai laisser tourner mon ordi en init 3 avec une boucle while qui affiche l'uptime et ça marchait encore le lendemain... mais ça à freeze dès que j'ai voulu voir htop
- Aucun processus particulier semble en être lié

Bref, un problème bien emmerdant :/
Actuellement, mes hypothèse sont un soucis de stabilité d'un module, un kernel instable sur ma configuration, le disque dure mal branché (mais il me semble que dans ce cas là je devrais avoir au moins une panic) ou bien le kernel n'arrive pas à gérer mon overclocking depuis la mise à jour.
Si qqun à une idée, moi je suis à cours ^^"

OS : je suis synchroniser avec le dépot de fedora 25 ('dnf istro-sync' fait hier)
CPU : Intel Core i7 5820K overclocker à 4GHz (tout les technologie intel activer hormis le turboboost, le speedstep, les C-state ACPI et la vitesse est réglé sur statique pour un OC stable)
RAM : deux barrettes de 8Go chacune DDR4-2132 en dual channel (même marque, même modèle, même réglages) réglé sur le XMP-2666
BOARD : MSI X99a RAIDER avec UEFI à jour
GPU : NVIDIA GeForce GTX 970 overclocker et stable en jeu (je ne joue pas sur Linux)

Bonne soirée

PS : je reste évidement à disposition pour tout demande d'informations complémentaire ^^

nouvo09

Salut

La première question qui me vient à l'esprit est : "as-tu essayé en remettant toutes les fréquences à leurs valeurs standard ?" Il m'est arrivé d'avoir des soucis en augmentant trop la fréquence de la ram.

Tutul3

oui oui j'ai remis tout les paramètre plus bas. Mais de tt façon ça faisait plus d'un an que Fedora tournait à merveille avec le même OC.

PS : depuis la mise à jour du kernel hier il me semble plus stable en tty (en tout cas j'ai pas eu de freeze avant de passer en init 5). Il a freeze 5 minutes durant une recherche sur firefox mais s'était juste une actualisation de page Bon il m'a quand même freeze durant une mise à jour git en init 3

Tutul3

Mise à jour du kernel 4.10.10-200 réussi, le système à tenu 31 minutes dessus en graphique, j'ai (presque) cru que s'était résolu ^^"
J'avais chrome qui tournait pour jouer de la musique et un git clone en cours (aucun de ces deux truc n'avait été fait précédemment donc je doute qu'ils soit lié).

Edouard_le_homard

4.40 ?? que renvoie

uname -r

Tutul3

sorry j'ai été trop vite, la 4.10.10-200.fc25.x86_64

VINDICATORs

Tu peux faire un :

su -lc 'smartctl -A /dev/sdX'

En remplaçant la lettre X par la lettre de tes disques et nous donner le retour stp?

Tutul3

pour /dev/sda qui est un ssd (le disque contenant la partition EFI, C: et la racine linux) :

root@PartedMagic:~# smartctl -A /dev/sda
smartctl 6.4 2015-06-04 r4109 [x86_64-linux-4.1.7-pmagic64] (local build)
Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x0000   100   100   000    Old_age   Offline      -       0
  5 Reallocated_Sector_Ct   0x0000   100   100   000    Old_age   Offline      -       0
  9 Power_On_Hours          0x0000   100   100   000    Old_age   Offline      -       1100
 12 Power_Cycle_Count       0x0000   100   100   000    Old_age   Offline      -       687
192 Power-Off_Retract_Count 0x0000   100   100   000    Old_age   Offline      -       143
194 Temperature_Celsius     0x0000   100   100   000    Old_age   Offline      -       19
195 Hardware_ECC_Recovered  0x0000   100   100   000    Old_age   Offline      -       793
196 Reallocated_Event_Count 0x0000   100   100   016    Old_age   Offline      -       0
197 Current_Pending_Sector  0x0000   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0000   100   100   050    Old_age   Offline      -       8
160 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       0
161 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       45
163 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       25
164 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       187276
165 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       230
166 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       129
167 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       184
168 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       3000
169 Unknown_Attribute       0x0000   100   100   000    Old_age   Offline      -       96
232 Available_Reservd_Space 0x0000   100   100   000    Old_age   Offline      -       100
177 Wear_Leveling_Count     0x0000   100   100   050    Old_age   Offline      -       670
181 Program_Fail_Cnt_Total  0x0000   100   100   000    Old_age   Offline      -       0
182 Erase_Fail_Count_Total  0x0000   100   100   000    Old_age   Offline      -       0
241 Total_LBAs_Written      0x0000   100   100   000    Old_age   Offline      -       608855
242 Total_LBAs_Read         0x0000   100   100   000    Old_age   Offline      -       377700

Pour /dev/sdb qui est un hdd (le disque contenant la partition /home, ainsi que la partition D: et une swap pour l'hibernation) :

root@PartedMagic:~# smartctl -A /dev/sdb
smartctl 6.4 2015-06-04 r4109 [x86_64-linux-4.1.7-pmagic64] (local build)
Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   062    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   100   100   040    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0007   253   253   033    Pre-fail  Always       -       1
  4 Start_Stop_Count        0x0012   099   099   000    Old_age   Always       -       3004
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   100   100   040    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0012   044   044   000    Old_age   Always       -       24926
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       2926
191 G-Sense_Error_Rate      0x000a   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   099   099   000    Old_age   Always       -       328
193 Load_Cycle_Count        0x0012   001   001   000    Old_age   Always       -       1819959
194 Temperature_Celsius     0x0002   253   253   000    Old_age   Always       -       18 (Min/Max 9/47)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       2
223 Load_Retry_Count        0x000a   100   100   000    Old_age   Always       -       0

A noter que sdb semble avoir eu des erreurs mais j'ai lancer cette nuit un test complet sur tout mes disque durs et les test se sont achevé sans erreurs. GSmartControl affiche un compteur de erreurs pour sdb mais les erreurs datent d'il y a deux ans donc je doute que se soit ça qui cause un soucis vu que j'ai encore utilisé ce disque avec succès pendant deux ans avant d'avoir les soucis d'aujourd'hui.

Error 14 occurred at disk power-on lifetime: 15442 hours (643 days + 10 hours)
  When the command that caused the error occurred, the device was active or idle.

Son power-on lifetime est maintenant de 24926 heures (soit pratiquement 3 ans).

PS : A noter que partedmagic n'a aucun soucis d'utilisation de mes disques durs, j'ai même pu faire un backup des données. Mais c'est une vieille version qui est encore sous son kernel 4.1.7-pmagic64
PS2: ah bah j'ai parlé trop vite, freeze durant le formatage de la clé usb qui avait servi de live... Après 11h sans problème

VINDICATORs

Rien de bien alarmant, il faudrait regarder du coté des températures de tout le système (cpu, gpu, carte maman etc...).

C'est bizarre que ce soit aléatoire comme cela...

Tutul3

le truc qui m'étonne le plus c'est que le windows qui partage le même matériel (hdd compris) n'a aucun soucis quand je joue à des jeux stressant pour l'alimentation et avec des température qui peuvent grimper à 80°C sur les coeurs CPU :/
Linux garde des températures au alentours de 50°C (en tout cas juste avant les freezes). Et l'alimentation n'est pas malmené, le GPU reste calme donc plus calme que sous Windows.
J'ai encore vérifier tout les branchement ajd pour voir si c'est pas lié, mais tout semble bien branché.
Le secureboot est désactiver et le ME doit marcher correctement vu que Windows n'a pas de soucis (j'y avais penser à cause de cette histoire de 30 minutes qui m'ont fait penser au hlt forcer par le ME en cas de soucis).

J'ai également tester plusieurs fois avec des noapic, nolapic/lapic, acpi=off/acpi=ht mais sans différence (à part une lenteur phénoménale si je mélange noapic, nolapic et acpi=off mais ça c'est normal sur les CPU multi-coeur).

Vu que partedmagic à fini par freezer je suspecte un soucis hardware ou de firware, mais je trouve ça étonnant que Windows reste stable vu qu'à ma connaissance, Linux à un meilleur fallback dans ce genre de cas.

PS : quelques semaine avant les soucis de Linux, j'ai eu un soucis plus grave qui provoquait des freeze sur Windows et le firmware, mais j'ai réparer ça en réinstallant le firmware (j'ai une double puce, j'ai réparer la première et mis à jour la seconde), et depuis j'avais plus de soucis. Je sais pas si c'est lier, je mentionne juste ça ici... Vais finir par croire que c'est les systèmes de sécurité qui déconne (ME ou autre) 🙁

antbel

Bonsoir,
? Ou Matériel ?
Overcloker à 4GHz, je veux bien mais .......t'as joué, t'as peut-être perdu ???? May Be

VINDICATORs

Test avec un noyau plus ancien, mais comme dit antbel, si ta eu un gros souci faut pas trop chercher non plus.

4Ghz pour un 5820K c'est quand même un peut trop en demander à mon avis. Les Haswell ne sont pas vraiment reconnu pour l'overcloking il me semble.

Ou alors le big problème vient d'ailleurs... Et en utilisant l'autre bios? ça n'irait pas? Parce que bon parler juste du firmeware... Il y en a pratiquement partout, bios, cpu, disques, etc...

antbel

Re-
J'ajouterai que la pâte thermique sympa, mais à trop tirer elle sèche???

Tutul3

Alors petite précision :
- 4GHz parfaitement stable (surtout que les série K sont prévue pour)
- Linux n'utilise absolument pas le CPU à pleine puissance donc pourquoi lui aurait des soucis et pas Windows
- Comme déjà dit, j'ai fait des test sans l'OC et ça a quand même freeze
- le firmware je parlais de l'UEFI de la carte mère
- la pâte thermique DOIT secher, c'est comme ça qu'elle devient efficace :p

VINDICATORs

Qu'est ce qu'il y a eu avec ton bios pour que tu ais besoin de passer par l'autre et de flasher?

Les K sont juste "débridé", après c'est un peu la loterie (j'en ai souvent fait les frais...).

sèche sèche... je dirais pâteux oui, vraiment sèche c'est pas le pied.

Tutul3

J'avais suspecté un soucis durant sa mise à jour et dès le reboot j'ai commencer à avoir des freeze+reset après environ 30 minutes. J'avais donc suspecté une corruption du ME surtout que l'autre puce n'avais aucun soucis.

Sèche pâteux oui, j'ai même par précaution retirer la couche que j'avais mise pour en mettre une nouvelle mais sans différence.

Je tient quand même à rappeler que j'ai fait les dernier test (et partedmagic) sans l'OC donc je doute que se soit lier. Accessoirement, mon CPU n'a gagné en moyenne que 5°C par rapport à la version de base. Et j'aurais pu monter plus haut mais je préférais éviter de devoir pousser mon ventirad plus vite 🙂

Sinon je viens de faire un autre check des branchements hier soir, j'ai rien vu d'anormal mais pas doute j'ai débrancher/rebrancher tout et là le Linux à tourner toute la nuit sous un bête truc de test, sans erreurs :/
Je vous tiens au courant mais je comprend plus rien, ça fait trois fois que je vérifie les branchements et comme tout l'hardware est partagé avec Windows, ça me semble étrange que si c'est bien un soucis de branchement, seul Linux en souffre et que windows fonctionne normalement Oo

antbel

Bonjour,
Quand tu es sur windows ?, essayes :
https://www.digitalmastersmag.com/magazine/tip-of-the-day-how-to-find-crash-logs-on-windows-10/
http://packard-bell-fr.custhelp.com/app/answers/detail/a_id/37245/~/windows-10-%3A-ouvrir-lobservateur-d%C3%A9v%C3%A9nements

Tu verras peut-être quelque chose de plus informatif ?

Tutul3

J'avais déjà fait, rien d'anormal

Tutul3

J'ai remarqué qqch sous Linux, le CPU a beau être réglé en 4GHz constant, linux utilise quand même du scaling alors qu'il ne devrait pas. Et j'ai beau changer les paramètres de p-state il continue à fluctuer entre 30% et 100% de fréquence. Quand je désactive p-state, il passe sur un driver inconnu de cpupower et reste à la vitesse par défaut : 3.3GHz.
Je ne dis pas que c'est ça mais je donne juste l'informations, j'ai aussi noter que les freeze sont à des températures différentes (une fois 56, une fois 60, une fois 45), donc rien de bien concret :/

Ah et pour ce qui est de Windows, aucun message comme je disais juste avant et de tt façon, l'OS vient de faire une mise à jour importante donc le journal d’événement à été reset.

PS : Quelqu'un à une idée pour debug ça ? ce qui me tue c'est de pas avoir de log... J'ai cru comprendre que quasi tout les CPU intel moderne possède le support pour un watchdog, peut-on le configurer pour provoquer une panic en cas de freeze ? ça donnerait au moins des infos et peut-être de quoi trouver la cause ^^ Ou tout autre façon de récupérer des données ??? ^^"

Tutul3

Alors, j'ai pas compris mais j'ai eu une mise à jour du kernel et depuis plus aucun soucis...
Enfin bref, suis content quand même et j'espère que ça ne reviendra pas ^^"
Merci pour votre attention 🙂

Page suivante »