[extinction brutale]crash complet (résolu)

[GuilouV]

Voilà le journalctl après un crash (j'ai allumé le pc, verrouillé l'écran avec xscreensaver et attendu que ça plante):

http://pastebin.archlinux.fr/452495

[GuilouV]

Après toutes ces semaines à chercher dans tous les sens je ne suis pas peu fier de vous annoncer que le problème est "résolu" (ou contourné devrai-je plutôt dire) en bloquant le chargement des modules acpi_cpufreq et mpref (qui dépend du précédent).

Maintenant la question qui en découle est donc comment faire en sorte de rétablir ces modules sans recréer le problème? Question accessoire: ces modules sont-ils "indispensables" sachant que j'utilise un portable?

[kero]

Déjà pour commencer, tu as posté un bug sur https://bugzilla.kernel.org/ ?

Ce serait la première chose à faire, d'autant plus si tu es sûr que le chargement de ces deux modules est à l'origine du problème. Par contre, avant de faire ça, attention à refaire un test avec un kernel vanilla, et pas le kernel patché archlinux ...

[benjarobin]

Tu as quoi comme carte graphique / driver, je pense avoir une idée de l'origine du bug

[GuilouV]

Ma carte graph est une intel:

Code : Tout sélectionner

VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)

Et voici mes pilotes:

Code : Tout sélectionner

extra/intel-dri 9.0-1
multilib/lib32-intel-dri 9.0-1
extra/xf86-video-intel 2.20.12-1 (xorg-drivers xorg)

@Kero
J'ai commencé par tester avec le kernel vanilla et tout fonctionne. Pour le report de bug j'attends surtout de savoir si s'en est vraiment un ou si une manip de ma part est à l'origine du problème (car comme toujours "c'est l'ordinateur qui bug" > FAUX "c'est l'utilisateur qui a fait une erreur").
Là je teste le kernel ck mais sans trop savoir pourquoi car je n'ai pas encore saisi si il y avait une réelle différence (mais c'est une autre histoire).

[kero]

J'ai commencé par tester avec le kernel vanilla et tout fonctionne. Pour le report de bug j'attends surtout de savoir si s'en est vraiment un ou si une manip de ma part est à l'origine du problème (car comme toujours "c'est l'ordinateur qui bug" > FAUX "c'est l'utilisateur qui a fait une erreur").
Là je teste le kernel ck mais sans trop savoir pourquoi car je n'ai pas encore saisi si il y avait une réelle différence (mais c'est une autre histoire).

Pour être clair: tu veux dire qu'avec un vanilla, tu n'as pas de plantage, aussi bien si tu tourne sans les modules qu'avec les modules ? Parce que dans ton cas, le plus urgent serait d'être en clair là dessus: il faudrait vérifier si avec un vanilla, ET avec les modules chargés, tu plantes aussi.

Si c'est le cas, un rapport de bug, ça mange pas de pain. Je sais qu'il faut pas balancer des rapports de bug à tout va, mais généralement (et surtout avec le kernel) les gens ont tendance à faire le contraire: ne pas en faire, de peur de mal faire. Maintenant, avec des crash depuis des semaines, et après avoir constaté que sans les modules tu plantes pas, je crois que tu peux légitimement te poser la question du kernel. Et un rapport peut t'aider là dessus. Mais pour ça faut vérifier que le crash se reproduit avec un vanilla.

Si c'est pas le cas, tu sais que le problème vient soit d'un kernel patché, soit d'autre chose. Accessoirement, si ça vient d'un kernel patché, la solution est simple: utiliser un vanilla.

Accessoirement, je suis tombé aujourd'hui sur une discussion concernant le DSDT. Maintenant, si on considère que tes crash sont quand même assez violents, que l'ACPI est mêlé à tout ça, il faudrait voir si t'aurais pas un DSDT mal codé. Ce qui est relativement fréquent (même si les conséquences ne sont pas toujours aussi graves).

Bon mes explications ne sont pas nécessairement très précises (et je ne peux pas affirmer que dans ton cas il y a un problème de DSDT), mais en gros: le DSDT c'est une table du BIOS qui fournit des informations sur le matériel au kernel. Le problème est que souvent le DSDT est compilé avec un compilateur Microsoft, avec le résultat que la table est bien reconnue par Windows, mais truffée d'erreurs pour d'autres OS, qui n'ont qu'une vue imprécise du matériel. La solution dans le temps était d'extraire le DSDT du bios, le décompiler, le corriger, le recompiler avec un compilateur standard, et inclure la table dans la compilation du kernel, pôur lui donner les infos correctes. Procédure assez lourde mais nécessaire si on veut que le matériel soit reconnu.

Edit: je viens de jeter un oeil à ton dmesg (enfin, journalctl) et cette ligne:

Code : Tout sélectionner

Nov 08 09:38:46 myhost kernel: ACPI: DSDT 00000000bdb905c0 0D6EC (v02 TOSASU      A00 00000001 MSFT 03000001)

Signifie, sauf erreur, que ton DSDT est bien compilé à la sauce Microsoft (=MSFT).

Edit 2: Accessoirement, tu ne nous as pas précisé ce que tu as exactement comme matériel (à moins que j'ai mal lu, j'ai juste revérifié les premiers messages). On parle de quel hardware, là ?

[GuilouV]

Ouahoooo et c'est dans ces cas là qu'on se rend compte qu'on n'est qu'un simple être humain ^^

Alors pour être clair:
Vanilla/CK avec les 2 modules incriminés = plantage
Vanilla//CK sans les 2 modules incriminés = stable
LTS: stable puisqu'il ne charge pas ces modules

Concernant le matériel voici le retour de lspci:

Code : Tout sélectionner

00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
00:1a.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03)
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03)
00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03)
02:00.0 SD Host controller: Ricoh Co Ltd MMC/SD Host Controller (rev 01)
02:00.1 System peripheral: Ricoh Co Ltd R5U2xx (R5U230 / R5U231 / R5U241) [Memory Stick Host Controller] (rev 01)
02:00.2 System peripheral: Ricoh Co Ltd PCIe xD-Picture Card Controller (rev 01)
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8191SEvB Wireless LAN Controller (rev 10)
07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)

Sinon pour le DSDT ben si il faut le faire je le ferai mais faudra m'aider parce que ça m'a l'air assez compliqué.
Et pour le rapport de bug je veux bien tenter, ce sera mon premier... ça compte pour mes points de participation à la communauté? :p

[kero]

Alors pour être clair:
Vanilla/LTS/CK avec les 2 modules incriminés = plantage
Vanilla/LTS/CK sans les 2 modules incriminés = stable

Donc le problème se pose aussi avec un Vanilla. Éventuellement, ce serait pas mal que tu tentes aussi avec une autre distro pour confirmer. Par exemple une ubuntu, juste en LiveCD/USB. Lance-la, vérifie que les mêmes modules sont chargés, et voit si tu plantes.

Ça pue d'autant plus que t'as plein de matos Intel qui est généralement bien supporté. Je soupçonne de plus en plus en DSDT mal foutu.

Et justement, concerannt le hardware, t'es encore peu précis: c'est quoi exactement ton modèle de laptop ? (*exactement*) Ce serait plus facile de vérifier si d'autres ont un problème de DSDT.

Concernant le bugzilla: tu sais, personnellement, je n'en ai fais qu'un seul, c'est pas la mort. Faut juste suivre précisément ce qui est demandé et tu as du retour de qualité en général. N'hésite pas. Tant que t'es pas un boulet allant là-bas faire n'importe quoi, les retour sont appréciés. Pour eux, c'est une manière de vérifier que leur matos tourne correctement, donc c'est gagnant-gagnant.

Edit: Je viens de tiquer sur un point: dans ton premier post, tu dis que ce problème a commencé soudainement. Donc avant ça, il a fonctionné sans problème pendant une longue période ?
Depuis 2 semaines maintenant mon pc a un comportement étrange: il s'éteint subitement purement et simplement.

[GuilouV]

Petite correction, j'ai tapée trop vite, en fait le noyau LTS est toujours stable bien sûr

Vanilla/CK avec les 2 modules incriminés = plantage
Vanilla/CK sans les 2 modules incriminés = stable
LTS: stable puisqu'il ne charge pas ces modules

Sinon effectivement ce problème est apparu "récemment" et rien n'était à signalé durant les 3,5 ans d'utilisation antérieure (même pc, même noyau, jamais réinstallé).

Enfin pour mon pc il s'agit d'un Toshiba Satellite Pro U500-18F dont les spé sont sur http://fr.computers.toshiba-europe.com/ ... ID=1076440.
Je n'ai que Arch d'installé depuis le début, j'ai viré windows dès la réception du pc.

[kero]

Intéressant.

Pourquoi la LTS ne charge pas ces modules ? Ils ne sont pas présents ? (ça m'étonnerait, du moins pour acpi_cpufreq). Ou ils sont compilés en dur dans le noyau ?

En fait, il serait pas mal que tu testes d'anciennes version du noyau. Éventuellement, si tu arrives à retracer l'historique, celles qui étaient présentes sur ton système avant le début des plantages. Si tu arrives à constater que ça plante depuis une certaine version du kernel, tu seras déjà plus en clair sur le fond du problème. Ce serait le signe d'une régression quelque part dans le code.

Va voir les logs de pacman et voit s'il y avait une mise à jour du kernel dans les jours précédents le début des plantage.

[GuilouV]

En fait le souci est survenu après le passage au kernel 3.6.3.
J'ai d'ailleurs dû réparer mon système avec un fsck.ext4 -v /dev/sda2. La partition avait été pas mal "détériorée" et je pense que ce souci pourrait être lié au bug rapporté sur https://bbs.archlinux.org/viewtopic.php?id=151341.

Après est-ce que cette histoire de module est liée...
Concernant LTS je ne sais pas pourquoi il ne charge pas ces modules mais il y en a d'autres qu'il ne charge pas à savoir:

Code : Tout sélectionner

joydev
videobuf2_vmalloc
videobuf2_memops
videobuf2_core
toshiba_acpi
coretemp
kvm_intel 
kvm
microcode
wmi
usb_common
lpc_ich

Par curiosité j'ai regardé mon DSDT et une décompilation/recompilation me renvoit pas moins de 9 erreurs et au moins autant de warnings et remarks. Concernant les erreurs (si ça peut aider) j'en ai deux types:
1ère:

Code : Tout sélectionner

dsdt.dsl   889:   0x00000000,
Error   4043 -            ^Invalid combination of Length and Min/Max fixed flags

Les autres du type:

Code : Tout sélectionner

dsdt.dsl   4084:                 Name (_PLD, Buffer (0x10)
Error   4105 -   Invalid object type for reserved name ^ (found BUFFER, requires Package)

EDIT: j'ai travaillé sur le dsdt et je bloque au point où la seule erreur qu'il me reste (plus de warning ou de remark) est:

Error 4124 - syntax error, unexpected $end and premature End-Of-File

En regardant le fichier cette ligne est vide.

[kero]

Mmh ... Si ton système de fichier a été détérioré lors de ce bug, la *toute première* chose à faire serait d'essayer avec un système propre sur un FS propre. Ne cherche même pas ailleurs tant que t'es pas certain que ceci est réglé.

Par exemple, essaye avec un LiveCD comme je te le disais. Voir si ça te fait les mêmes problèmes.

Note en passant: tu peux avoir ton DSDT plein d'erreurs (d'ailleurs c'est presque obligatoire que t'en aies, s'il a été compilé avec le compilateur Microsoft) mais ça veut pas forcément dire qu'il est à l'origine du problème.

[GuilouV]

Test avec un live-cd Arch avec les modules acpi_cpufreq et mperf chargés. Je n'ai pas eu à attendre longtemps pour constater un plantage. De la même façon le live-cd est stable par contre sans ces modules (qui ne sont par défaut pas chargés au démarrage).

[kero]

Intéressant. Ce n'est donc pas ton FS qui est cassé. Étant donné qu'au début le système fonctionnait et qu'ensuite ça a commencé à foirer (fin octobre), j'écarterais aussi (pour l'instant) l'option DSDT buggué (ou en tout cas pas comme cause principale).

Pour moi ton problème se situe au niveau du kernel. Les problèmes peuvent être nombreux. Je viens de lire un post qui m'a rappelé que le système coupe l'alim du processeur si la température détectée est trop haute (http://forums.archlinux.fr/topic12323.html). Ça peut arriver parfois, même si la température n'est pas trop haute, dans le cas où le kernel lit mal la température des sondes.

Ce que je suggère.
1) Tester avec la version du noyau que t'avais avant le début des plantages. D'après mes logs de pacman, il y a eu une mise à jour de 3.6.2 vers 3.6.3 vers le 25 octobre ([2012-10-26 17:56] upgraded linux (3.6.2-1 -> 3.6.3-1). Voit tes logs pour plus de détails. Par contre, pour tester, il va falloir compiler les vieux noyaux je pense. Si tu ne sais pas faire, c'est le moment d'apprendre Mais c'est pas si compliqué que ça, une fois qu'on a la main. D'ailleurs, t'as peut-être encore les vieux paquets dans ton cache. Dans ce cas là, profites-en.
2) Si ça se confirme, il faudrait déterminer à partir de quelle version de kernel ça plantouille.
3) Tu fais un rapport de bug en expliquant le problème et en attendant, tu continues d'utiliser la dernière version du kernel qui fonctionne.

[GuilouV]

Ayant vidé mon cache je vais pour le moment continuer sans charger les modules, au moins ça fonctionne et ça n'a pas l'air de perturber mon système. Je tenterai un ancien noyau peut être plus tard.
En tout cas merci pour toute cette aide précieuse.

[kero]

Comme tu veux.

Encore une chose toutefois: j'ai rezieuté le topic et en fait tu ne donnes toujours que le résultat de journalctl sur les events après le crash. C'est le cas du dernier. Il faudrait donner la sortie de journactl pour les events qui précèdent immédiatement le crash (donc juste avant le reboot consécutif à un crash).

Ça permettrait d'y voir plus clair.

[GuilouV]

Voici les quelques lignes avant un plantage.
http://pastebin.archlinux.fr/452772

[kero]

Je ne vois rien d'intéressant ...

[GuilouV]

Moi non plus...
C'est ce qu'on appelle un vrai bug.

[GuilouV]

Je reviens après tout ce temps avec LA solution.
J'ai donc:
- laissé tous les modules se lancer au démarrage (même acpi_cpufreq)
- installer cpupower
- régler ce dernier pour gérer la fréquence max de mes processeurs à 2.20 Ghz

Le souci semblait donc venir de la gesiton de la fréquence de mes processeurs. Ceux-ci pouvait tourner jusqu'à 2201 Mhz. Cette légère sur-fréquence était donc à l'origine des crashs de mon pc.

EDIT: bon finalement moins de plantage avec cette nouvelle modification mais le problème persiste encore par moment... Je tente d'autres trucs et vous tient au courant.

EDIT2: le problème semble enfin résolu en ajoutant en plus la ligne options processor ignore_ppc=1 dans le fichier modprobe.conf. Cette ligne a pour effet d'ignorer la limitation de fréquence imposée par le bios (qui chez moi était fixée à 2021MHz pour des processeurs acceptant une fréquence max de 2200MHz)