# [kernel] Redémarrage en boucle [Résolu]

## Jamesbch

Bonjour à tous,

Après le changement de matériel d'un de mes ordis, celui-ci refuse de démarrer. Je suis passé d'un Pentium 4 à un E2180 d'Intel. La plupart des composants ont été changé (CM, CG, RAM, CPU). J'ai donc dû faire un petit tour dans le kernel histoire de configurer. Il me semble avoir tout bien fait et j'ai pris mon temps. Après ça le PC boot, donc j'y vois que du feu.

Malheureusement, vu que je devais paufiner certains détails dans le kernel, j'ai eu la mauvaise surprise que ça ne démarrait plus, mais cela ne viens pas du changement. En fait c'est encore plus vicieux que ça parce que le kernel sans ce "paufinage" ne démarrait pas non plus. Du coup lorsque le système se lance, il s'arrête bien 3 secondes sur quelque chose qui ressemble à "Activation of Core 1/1" puis là ça défile à toute allure et finit par redémarrer. Le /var/log/dmesg ne donne rien à signler. Vu que le système démarrait en boucle il a FINIT par démarrer !

C'est bien là que le mystère commence, puisque aucune modification n'a été faite à ce kernel. Je laisse l'ordi allumer pour éviter de ne pouvoir le démarrer plus tard. Les Live CD n'ont pas l'air de poser de problème, Windows non plus (c'était juste pour essayer et pour flasher le BIOS sans succès).

Vu que l'ordinateur est allumé j'ai pu regarder si il y avait des problèmes et bien je suis surpris ! je ne vois rien de particulier. Aucune surchauffe (lm_sensors), les disques durs semblent bons.

J'aurais bien besoin d'un coup de main pour cerner le problème ! Je peux vous passer mon .config kernel ou quoi que ce soit.

Je remercie quiconque venant me sauver de cette mystérieuse impasse.

A bientôt.Last edited by Jamesbch on Sun Sep 14, 2008 5:00 pm; edited 2 times in total

----------

## gglaboussole

Salut ,

Ton message n'est pas très clair et les infos que tu donnes pour obtenir de l'aide sont plutôt succintes..

Si ça marche avec un livecd le bon fonctionnement du matos et sa compatibilité avec linux ne sont pas à mettre en cause

Pour commencer il faudrait que tu donnes :

-La sortie de lspci (afin de voir les caractéristiques des chipsets de ton nouveau matos)

- le .config de ton noyau (afin de voir si les supports des chipsets en question sont bien activés)

- le sortie de dmesg (car contrairement à ce que tu dis il doit bien y avoir des infos intéressantes à glaner)

- ton emerge --info ou au moins tes CFLAGS (afin de voir si t les options de compilations utilisées pour construire ton système précédent ne sont pas trop éloignées de ton sytème actuel...les CFLAGS notamment le type de CG....etc...

- plus de détails sur ancien matos et nouveau (tu n'indiques que le cpu)

EDIT: En théorie pour faire ce que tu veux faire, c'est à dire changer de matos sans réinstaller :

1) Recompiler le kernel en désactivant les vieux chipsets et activer les nouveaux

2) Modifier le make.conf pour adapter les CFLAGS, les KEYWORD (en effet tu passes d'un cpu X86 à un cpu qui gère le 64 bit donc amd64 et par conséquent te poser la question du multilib ou pas....--> il y a plein de posts là dessus sur le forum)

3/recompiler l'intégralité de ton système  pour que tout soit reconstruit avec tes nouvelles CFLAGS et USE

----------

## kopp

euh tu peux pas changer de x86 à amd64 comme ça. Si tu veux garder ton système, faut rester en 32 bits.

----------

## Jamesbch

Salut gglaboussole et kopp,

J'ai été peu clair c'est vrai, je vais commencer par les informations.

 *Quote:*   

> JServer ~ # lspci
> 
> 00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02)
> 
> 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)
> ...

 

Voici le .config de mon kernel 2.6.25-r7 :

http://www.pastebin.ca/1183678

Voici le dmesg lorsque ça redémarre :

http://www.pastebin.ca/1183676

 *Quote:*   

> JServer ~ # emerge --info
> 
> Portage 2.1.4.4 (default/linux/x86/2008.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.26-gentoo-r1 i686)
> 
> =================================================================
> ...

 

Ce qui concerne l'ancien matos, c'était à base de Pentium4 HT, avec de la ram DDR1, carte mère Asus (de tête). J'ai bien fait attention à enlevé les drivers de l'ancien matos. J'ai aussi pris soin de modifier les uses et les cflags puis un emerge -eav world. Le matos actuel se base sur de la DDR2, et un chipset Intel 945GCM, avec CG intégrée. Vu que c'est un ordinateur serveur, je ne me soucie pas du son ni de l'accélération vidéo.

Pour ce qui est du x64 bits, je n'ai pas changé le système, c'est à dire que je reste en x86 pour le moment. Ce serait tout une étape de changer en 64 bits maintenant.

Enfin bref, d'après mes diagnotiques, le problème ne serait pas inscrit dans le dmesg du kernel. Le problème vient entre la fin de l'init du kernel et avant l'init du système (lancement des daemons etc...). Je dis ça parce que le dmesg reste identique que la machine redémarre ou pas. Vu que ça va tellement vite je ne peux pas vraiment aider de ce côté.

Cependant je ne peux pas exclure un problème matériel parce que si un LiveCD fonctionne, je ne pourrait pas dire autant du disque dur par exemple. C'est peut-être lui le fautif, qui sait ? Je vais le controller avec -f. Pour le moment je ne sais pas qu'est-ce que je peux essayer, je n'ai plus d'idée.

à kopp: Désolé j'ai peut-être mal formé quelque chose mais je ne compte pas changer en 64 bits pour le moment. Le système est actuellement en x86.

Merci de vos réponses à vous deux.

----------

## ghoti

Bon, je ne sais pas si ça va régler le problème mais il y a déjà trois anomalies à régler :

 *dmesg wrote:*   

> 465. EXT3-fs warning: mounting fs with errors, running e2fsck is recommended

 

Une partition est peut-être corrompue. Suivre les recommandations du monsieur ...

 *config kernel wrote:*   

> 655. CONFIG_IDE=y
> 
> [ ... ]
> 
> 809. CONFIG_ATA=y

 

Tu configures à la fois l'ancien driver IDE et le nouveau driver libata. Cela ne peut t'apporter que des ennuis.

Vire l'ancien driver IDE, il est obsolète !

De plus, tu actives une tripotée de pilotes qui ne correspondent à aucun matériel listé dans ton lspci (notamment dans la rubrique libata : ATA_SFF, SATA_SVW, SATA_NV etc ...)

Il ne te faut que les drivers suivants :

Pour le contrôleur ICH7, il te faut ATA_PIIX (ou éventuellement SATA_AHCI s'il est mentionné dans le BIOS)

Pour le contrôleur Promise, c'est le PATA_PDC2027X.

Voilà, fais d'abord un peu de nettoyage et tiens-nous au courant  :Wink: 

----------

## Jamesbch

Salut ghoti,

je te remercie de ton aide. J'avais totalement oublié de remplacer la vieille librairie IDE par libata, honte à moi. Voilà du coup c'est un petit peu plus rapide. Et du même coup, j'ai enlevé les drivers inutiles. J'avoue que c'était pas très ordré tout ça. Je n'ai pas osé touché autre chose pour le moment. Les disques sont passés sous sd[a-z] au lieu de hd[a-z], tout semble fonctionner sous libATA.

Pour ce qui est d'une partition corrompue, j'ai trouvé quel disque c'était. Ce n'est pas le disque système mais en tout cas ça été réparé selon e2fsck. Je n'ai pas eu à le lancer avec -f, il a détecté de lui même l'anomalie. De toute manière j'ai passé tous mes disques à un contrôle -f avec e2fsck. Rien à signaler.

Voici la nouvelle configuration de mon kernel: http://www.pastebin.ca/1184411

Malheureusement, le problème persiste et toujours de la même manière.

[quote=jamesbch]Malheureusement, vu que je devais paufiner certains détails dans le kernel, j'ai eu la mauvaise surprise que ça ne démarrait plus, mais cela ne viens pas du changement. En fait c'est encore plus vicieux que ça parce que le kernel sans ce "paufinage" ne démarrait pas non plus. Du coup lorsque le système se lance, il s'arrête bien 3 secondes sur quelque chose qui ressemble à "Activation of Core 1/1" puis là ça défile à toute allure et finit par redémarrer. Le /var/log/dmesg ne donne rien à signler. Vu que le système démarrait en boucle il a FINIT par démarrer ![/quote]

En fait j'ai trouvé le message exacte qui bloque pendant quelques secondes. Ligne 110 "Booting processor 1/1 ip 4000". Il est possible que ça soit un indice puisque lorsque ça fonctionne cette ligne n'est pas affichée aussi longtemps. Du coup le coupable serait le CPU ? ou bien le driver qui passe mal à ce CPU ? Qu'en pensez-vous ?

Merci de votre soutient.

----------

## ghoti

Donc, si je comprends bien, au démarrage l'ordi reboote plusieurs fois avant que le noyau soit complètement chargé et puis finit tout de même par démarrer correctement ?

Tu peux toujours essayer de générer un noyau avec genkernel. 

Si ça marche, c'est que tu avais un problème de config.

Si le noyau genkernel ne marche pas non plus, il faudra probablement soupçonner le hardware.

Perso, c'est tout de même bien à un défaut matériel que tes symptômes me feraient penser.

Vérifie si tous les composants sont branchés fermement.

Par exemple, avec le CPU, on a vite fait de répandre par mégarde un minuscule soupçon de pâte thermique sur les broches et ce n'est généralement pas du tout apprécié (qui a dit que ça sentait le vécu ?  :Wink: )

Mais je pense surtout à la RAM : bien vérifier qu'elle soit clipsée à fond.

Vérifie aussi dans le BIOS si elle est reconnue correctement, si les timings et les tensions correspondent aux spécifications.

Si tu as plusieurs barrettes, vois ce qui se passe si tu n'en mets qu'une à la fois.

Vérifie aussi si ta CM n'impose pas d'utiliser des slots bien précis en fonction du nombre de barrettes.

Enfin, fais un memtest86 approfondi.

Une autre piste à creuser, c'est l'alimentation.

Regarde dans le BIOS si les tensions sont aussi proches que possble de leur valeur nominale. 

Essaie éventuellement avec ton ancienne alim (à condition qu'elle soit compatible!)

----------

## kopp

POur le 64 bits, c'était destiné à la remarque précédente qui parlait de multilib, amd64 etc.

Il me semble que le multilib marche que dans le sens : système 64 bits et multi lib pour du 32. Mais peut-être que je em trompe, au quel cas ma remarque ne sert à rien.

----------

## xaviermiller

non, tu as raison Kopp : un système ne peut exécuter que des binaires "plus petits" : 64 ->32 (win 9x) ->16 (win 3) ->8 (dos)

----------

## gglaboussole

Je pensais qu'il était possible de passer de 32 à 64 et vice versa (me semblait avoir vu des posts là dessus)...enfin c'était pour faire remarquer à notre ami qu'il changeait de cpu et que cela devait à priori entrainer des changement dans son make.conf et une recompilation de tout son système....

En fait d'après http://gentoo-wiki.com/Safe_Cflags   il s'avère que les CFLAGS sont strictement identiques entre un P4 et un Core Duo conservé en 32 bits, donc il n'a que le MAKEOPTS à modifier- ce qu'il à fait apparemment- et pas tout à recompiler ! (veinard !   :Very Happy:  )

----------

## kopp

hum, c'est peut-être pas à jour la page des safe cflags, y a un flag core2 maintenant. À moins que ce soit que dans le gcc 4.3 ...

Enfin, y a toujours le -march=native à partir de gcc 4.2 qui fera au mieux.

De toutes façons il n'y a a priori rien à changer à part le kernel pour les chipsets. Vu que c'est rétro compatible, c'est pas la peine de tout recompiler.

----------

## xaviermiller

sauf si on passe d'un pentium 1 à un CoreDuo, sinon on perd le support pour MMX et SSE*, très utiles pour des lourds traitements numériques (compression / décompression de vidéos par exemple)

----------

## kopp

ça reste pas nécessaire. Une bonne idée par contre, ça l'est  :Wink: 

Mais quand je disais que c'était pas nécessaire, c'est que le système fonctionnera quand même.

Enfin, les choses se feront de toutes façons au fur et à mesure avec les mises à jour, si on change le cflags vers native.

----------

## xaviermiller

oui, tout à fait  :Smile: 

----------

## Jamesbch

Salut à tous à nouveau,

je suis sur la bonne piste ! La mémoire fonctionne très bien, elle a aucune erreur durant les 1h30 de memtest86.

Cependant j'ai eu la bonne idée de prendre en vidéo le boot qui fonctionne pas et celui qui fonctionne. Et là miracle, on voit les erreurs, oui il y en a plusieurs. 

Malheureusement je suis incapable de les interpréter parce que je ne vois pas bien comment un CPU ne peut pas répondre, enfin je vous laisse admirer :

Pour voir les erreurs, il vous faut y aller image par image, car c'est très rapide en effet !

Vidéo où ça ne fonctionne pas :

http://www.james-b.ch/video/MOV00004.MPG

où ça fonctionne :

http://www.james-b.ch/video/MOV00005.MPG

Pour faciliter un peu voici les deux images intéressantes de la vidéo 1.

Image #01

Image #02

Qu'est-ce que vous en pensez ?

----------

## Jamesbch

Je n'ai toujours pas pu régler le problème, ne sachant pas comment et où chercher. Je requière toujours de l'aide.

Merci d'avance.

----------

## CryoGen

Essai de booter avec l'option 'noapic'

----------

## Jamesbch

J'ai essayé de rajouté noapic à mon grub mais j'ai pas de changement. Pour être sûr voici la ligne que j'ai modifiée :

 *Quote:*   

> kernel /boot/noyau-2.6.25-r7-20080825 root=/dev/sda1 noapic

 

----------

## ghoti

Ton problème pourrait être lié au support d'un clavier/souris USB au démarrage.

Regarde dans le BIOS si tu n'as pas une option du genre "Disable Legacy USB Support". Si c'est le cas, active-la.

----------

## Jamesbch

 *ghoti wrote:*   

> Ton problème pourrait être lié au support d'un clavier/souris USB au démarrage.
> 
> Regarde dans le BIOS si tu n'as pas une option du genre "Disable Legacy USB Support". Si c'est le cas, active-la.

 

Chapeau bas, alors là j'y crois pas ! Vraiment ghoti t'es vraiment un chef. Je n'arrive pas à comprendre pourquoi ça vient de là, mais chose est sûr. J'ai beau redémarrer 5x, ça fonctionne cette fois et pour de bon je crois bien. J'étais sur le point de laisser tomber mais là... très bien trouvé !

En tout cas bravo ghoti et comment pourrais te remercier, merci mille fois ! Si t'a compris pourquoi ça buggais je suis curieux de connaître l'explication. Génial en tout cas.

----------

