# [kernel] unable to handle kernel paging request at

## Chr0nos

bonjours, j'ai actuelement un gros souci avec ma gentoo: je ne peu plus rien emerger, j'était en 2.6.39-r1 et tout alais bien et lors du passage au 3.0.4 -> ca ne marche plus

j'ai tenté de repasser sur mon 2.6.39-r1 mais la non plus je ne pouvais plus emerge (meme eix ne marche pas !), j'ai alors rebooté la machine sur une clef usb live gentoo, je fais un fsck.ext3 -yvf /dev/sda1

qui ne m'a sortis aucune erreur, bon je poursuit: 

mount -t ext3 /dev/sda1 /mnt/gentoo

chroot /mnt/gentoo

mount -t proc proc /proc

emerge portage

et je relance, idem: le probleme ne change pas mais mon emerge est passé, j'en déduis donc que ce n'es pas portage qui a du mal mais le noyeau, je relance le tout passe a nouveau dans mon chroot et recompile le tout: le probleme est toujours la, en plus je ne peu même pas le metre sur bugs.gentoo car ma maitrise de l'anglais laisse un peu à désirer pour un probleme aussi technique

 *Quote:*   

> Sep  1 21:00:09 StarK kernel: BUG: unable to handle kernel paging request at ffff87fac9dedd78
> 
> Sep  1 21:00:09 StarK kernel: IP: [<ffffffff8119d019>] 0xffffffff8119d019
> 
> Sep  1 21:00:09 StarK kernel: PGD 0 
> ...

 

quelqu'un aurais il une idée svp ?

----------

## mp342

 *Quote:*   

> Sep  1 21:00:09 StarK kernel: BUG: unable to handle kernel paging request at ffff87fac9dedd78
> 
> Sep  1 21:00:09 StarK kernel: IP: [<ffffffff8119d019>] 0xffffffff8119d019
> 
> Sep  1 21:00:09 StarK kernel: PGD 0 
> ...

 

On dirait un bug du noyau 3.0.4. Peux tu mettre l'erreur que tu obtiens quand tu boote sur ton ancien noyau ?

----------

## Chr0nos

voila l'erreur avec l'ancien noyeau:

 *Quote:*   

> Aug 31 18:33:44 StarK kernel: BUG: unable to handle kernel paging request at ffff87f95b8ddd78
> 
> Aug 31 18:33:44 StarK kernel: IP: [<ffffffff8119bac9>] 0xffffffff8119bac9
> 
> Aug 31 18:33:44 StarK kernel: PGD 0 
> ...

 

(jai testé de faire "aujourd'hui" sur lancien noyeau: aucune erreur mais freez de la commande emerge, impossible de la stoper avec ctrl+c et meme un kill -9 n'en viens pas a bout)

meme les emerge --info ne marchent plus

----------

## guilc

En furetant sur google, beaucoup de littérature dirige vers un défaut matériel...

Tu devrais faire tourner quelques heures un petit memtest !

----------

## Chr0nos

un default materiel ? hum étrange car apres tout ce temp (1ans sans aucun souci (et sans jamais avoir OC la machine)) je n'ai jamais eut le moindre pépin, meme pour la ram je ne fais pas mon radin j'ai pris du corssair, mais soit, demain avant de partir au travail je lancerais un memtest

edit: en ravanche quand je boot depuis une clef usb et que je chroot tout se passe bien avec portage, ca m'étone :s

----------

## guilc

 *Chr0nos wrote:*   

> edit: en ravanche quand je boot depuis une clef usb et que je chroot tout se passe bien avec portage, ca m'étone :s

 

Et avant ton 2.6.39 marchait, maintenant il plante comme le 3.0.4 non ?

Ca aussi c'est étrange non ? :p

----------

## Chr0nos

ouais c'est exactement ca, du coup je me retrouve avec un systeme sur le quel je ne peut plus rien faire en raport avec portage/eix

et sur une clef live je n'ai aucune erreur et tout marche a la perfection, prob de noyeau ?

je peu fournir mon fichier de config du noyeau si besoin

----------

## mp342

 *Chr0nos wrote:*   

> ouais c'est exactement ca, du coup je me retrouve avec un systeme sur le quel je ne peut plus rien faire en raport avec portage/eix
> 
> et sur une clef live je n'ai aucune erreur et tout marche a la perfection, prob de noyeau ?
> 
> je peu fournir mon fichier de config du noyeau si besoin

 

Vu qu'il y a aussi eu une mise a jour de portage récemment (le 27 pour moi en x86, quelques jours avant pour amd64), c'est peut être un problème avec portage. Tu devrais essayer de réinstaller la version précédente depuis ta clé usb live.

----------

## Fenril

A tout hasard, j'ai eu un souci équivalent, et je ne suis pas certain qu'il y a un lien de cause à effet avec ton problème, mais la cause était le module nvidia qui était corrompu (me demandez pas comment c'était arrivé). Une recompilation des modules avait résolu mon souci.

----------

## barul

 *Chr0nos wrote:*   

> un default materiel ? hum étrange car apres tout ce temp (1ans sans aucun souci

 

C'est le même principe que les voitures qui tombent en panne, hein. Un jour ça fonctionne, l'autre pas.

----------

## Chr0nos

je suis daccord avec ca mais ce qui me parais bizzard c'est que sur un live: tout marche bien, et sur mes kernels: ca bug

j'ai lancé un memtest toute la journée: aucune erreur de mémoire :s, pour la corruption du driver graphique je vais tenter de le recompiler dans un chroot tout a l'heure

dans le doute je lance un emerge -e world cette nuit... des fois que le souci viene d'une appli externe bien que j'en doute

----------

## Chr0nos

alors malgres le emerge -e world -> le probleme est toujours la,

j'ai bien recompilé mon nvidia-drivers aussi pour le noyeau 3.0.4 et je boot avec, de ce coté la tout marche bien

toutefois des que je tente une commande de type emerge: freez du terminal dans le quel je l'ai lancé :s

j'avoue ne plus savoir quoi faire la, du coup pour compiler mes maj je dois systematiquement booter sur une clef usb et emerge dans un chroot :/

----------

## El_Goretto

+1 guilc, pour le pb matériel.

 *Chr0nos wrote:*   

> je suis daccord avec ca mais ce qui me parais bizzard c'est que sur un live: tout marche bien, et sur mes kernels: ca bug

 

C'est au contraire super simple: un matériel défectueux fait des erreurs... de calculs, conserve ces erreurs et les stocke sur disque, dans des données mal générées ou des binaires mal compilés, etc.

Tu t'étonnes toujours que ta clé live fonctionne?  :Smile:  Plutôt normal pour un OS "frais" garanti non corrompu.

Si tu veux mettre vraiment tes noyaux (hors de/en) cause, tu peux toujours pendre celui de ta clé et l'utiliser pour booter ta gentoo.

Les 2 derniers kernel panic que j'ai eu sur un atom m'ont fait immédiatement réagir, démontage, dépoussièrage, augmentation de la vitesse des ventilos, et bizarrement, je n'en ai plus eu un seul pépin de l'été (et oui).

----------

## Chr0nos

bon alors aussi étrange que cela puisse paraitre cela ne venais pas d'un probleme "materiel" mais plutot d'un hdd en xfs qui semble avoir des fichiers "hs"

mon /usr/portage/packages/ pointais sur une partition xfs qui à son dossier innacessible (pas toute la partition juste le secteur ou se trouvent mes packages)

des que j'ai umount /usr/portage/packages mes commandes emergent remarches mais je ne peu pas umount toute la partition (/mnt/Ares) car j'ai un:

 *Quote:*   

> StarK / # umount /mnt/Ares/
> 
> démontage : /mnt/Ares : périphérique occupé.
> 
>        (Dans certains cas, des infos sur les processus l'utilisant
> ...

 

donc je ne peu pas encore faire un xfs_check pour en savoir plus, cela s'ajoutant à des soucis de "Please use extra_commands or extra_started_commands." dans mes logs au demarage de mon serveur nfs je sens que je vais m'amuser aujourd'huis...

en tout cas merci à tous pour votre aide

----------

## guilc

Un FS ne se corromp pas comme ça !

Soit tu as fait des arrêts trop violent mal réparés, soit tu as effectivement un problème matériel sur ton disque avec des clusters en train de mourir...

Que dit le rapport smart ? (smartctl -a /dev/sdX)

Que donne le résultat d'un test complet ? (smartctl -t long /dev/sdX, puis une fois le test fini smartctl -l selftest /dev/sdX)

----------

## Chr0nos

j'ai eut quelques soucis de "coupures de courant", en revanche n'ayant pas la commande smartctl je suis passé par l'outil smart de gnome, il me dis que le disque n'a aucun soucis (j'ai fait une analyse "longue)

sur un disque de 2To en xfs ça prends un certain temps  :Smile: 

----------

