Unix, l'ACPI et les BIOS, on en est où ? - Divers - Linux et OS Alternatifs
Marsh Posté le 21-04-2009 à 07:52:03
ReplyMarsh Posté le 21-04-2009 à 08:01:55
Topic très intéressant
Acer Aspire One :
Intel ACPI Component Architecture |
Marsh Posté le 21-04-2009 à 08:05:51
Sur ma Gigabyte GA-EP35-DS3, ça a déjà l'air moins propre :
Intel ACPI Component Architecture |
Marsh Posté le 21-04-2009 à 13:45:05
Ce lien pourrait faire d'affaire, cependant ça fait un bout de temps qu'il n'est pas à jour ! Les personnes qui sont prêtes à débugger de l'assembleur sont plutôt rares...
Apparemment Acer n'a pas succombé au lobby du compilateur Microsoft (d'ailleurs quelqu'un sait qui est le constructeur de leur carte-mère !?), Gigabyte ça a l'air moins pire, j'ai vraiment l'impression que je suis tombé sur le constructeur qu'il ne fallait pas pour mettre Linux dessus.
J'aimerais bien savoir où en sont les cartes mères Intel, ce serait un comble si ils utilisaient M$ pour leur BIOS
Marsh Posté le 21-04-2009 à 14:24:07
redvivi a écrit : |
C'est du Quanta Computer.
Mais c'est pas super étonnant, vu que l'Aspire One a été livré avec une distro Linux, il valait mieux pour eux que l'ACPI soit un tantinet correct
Sinon, mon Dell Inspiron 6000 :
Intel ACPI Component Architecture |
Marsh Posté le 21-04-2009 à 14:32:41
je posterai pour mon HP nc6120, mais pareil y'a des erreurs ...
Marsh Posté le 21-04-2009 à 14:47:38
HP DV4-1105ef :
Intel ACPI Component Architecture |
Marsh Posté le 21-04-2009 à 17:22:56
Je sens que ça va être funky sur mon asus à base de chipset nvidia
Marsh Posté le 21-04-2009 à 17:29:50
Sur mon dell XPS M1530:
Intel ACPI Component Architecture |
Hum on a connu mieux....
Marsh Posté le 21-04-2009 à 17:33:22
Là par contre c'est plus grave: un string qui ne doit pas contenir de caractères spéciaux, et des tests qui ne fonctionnent pas ! Je tire mon chapeau à Dell !
Marsh Posté le 21-04-2009 à 18:08:58
Contre toute attente c'est pas si affreux que ça :
Citation : Intel ACPI Component Architecture |
A part que je détiens le record de la non-optimisation avec une bonne longueure d'avance, j'ai aucune erreur. Pourtant j'ai effectivement plusieurs warnings/erreurs dans le log kernel qui me font dire que mon bios est certainement assez pourri.
Marsh Posté le 21-04-2009 à 18:12:46
BloodyCarnage a écrit : A part que je détiens le record de la non-optimisation avec une bonne longueure d'avance, j'ai aucune erreur. Pourtant j'ai effectivement plusieurs warnings/erreurs dans le log kernel qui me font dire que mon bios est certainement assez pourri. |
Non ne t'inquiète pas ce sont les optimisations faites par le compilateur d'Intel lors de la tentative de compilation, pas les compilations effectives de ton ACPI . Cependant celà veut dire que le code peut-être optimisé, en recompilant ta DSDT et en la mettant dans ton initramfs, tu aura ainsi un BIOS et une gestion des IRQ optimisés.
Même si il n'y a pas d'erreur, les warnings peuvent très bien être des fonctions/tests qui ne fonctionnent pas, d'où peut-être tes erreurs de ton log (cf post de raphoun).
Quelle est la marque/modèle de ta carte-mère ?
Marsh Posté le 21-04-2009 à 18:26:59
Asus P5N-E SLi (nforce 650 SLi).
Et les erreurs sont du genre :
Citation : [ 0.000000] ACPI: RSDP 000F7910, 0024 (r2 Nvidia) |
Citation : [ 15.764790] it87: Found IT8718F chip at 0x290, revision 2 |
Citation : [ 27.246491] nvidia 0000:01:00.0: irq 26 for MSI/MSI-X |
ou encore le fait que les modes S1 et S3 (suspend to ram/disk) plantent systématiquement la machine.
Marsh Posté le 21-04-2009 à 18:28:54
je crois que je définitivement laisser tomber Asus, c'est quand même important ce genre d'erreur qui mettent en cause la stabilité de la machine.
Marsh Posté le 21-04-2009 à 23:39:15
Asus EEEPC 901 (netbook)
|
Marsh Posté le 21-04-2009 à 23:44:14
Asus P5Q-E
|
Intel D101GGC
|
HP/Compaq 8510p (notebook)
|
Marsh Posté le 21-04-2009 à 23:52:17
C'est une blague ? Intel aussi s'y met ? Quel age a cette carte-mère ?
Marsh Posté le 22-04-2009 à 04:02:16
Ca a l'air plutot recent (LGA775) : http://pentium.com/products/mother [...] /index.htm
Marsh Posté le 22-04-2009 à 08:25:49
C'est une petite carte MicroATX avec un Pentium4 Bi-core 2.8Ghz.
Marsh Posté le 22-04-2009 à 13:45:27
M300A a écrit :
|
Je ne suis pas expert mais il y a vraiment quelquechose qui ne tourne pas rond. Quand je regarde sur le site d'Intel ( http://pentium.com/design/motherbd [...] yspecs.htm ) les spécifications ACPI de la carte sont:
Citation : Version 2.0a, March 31, 2002, Compaq Computer Corporation, Intel Corporation, Microsoft Corporation, Phoenix Technologies Limited, and Toshiba Corporation |
Rapide lecture de la spécification ( http://www.acpi.info/DOWNLOADS/ACPIspec-2-0a.pdf ):
Citation : 7.3.5 \_WAK (System Wake) |
La méthode WAK ne prend qu'un seul argument, cependant cette ligne me choque: Method (\_WAK, 1, NotSerialized) (ligne 231) car il y a 2 arguments, cependant je ne suis pas assez qualifié pour déterminer si c'est correct ou non. L'erreur principale vient du fait qu'il n'y a pas de "Return (Value)" Value étant un package de 2 DWORD à la fin de la méthode _WAK ( http://www.gentoo-wiki.info/ACPI/Fix_common_problems )
Autre chose:
Citation : 7.2.10 _PSW (Power State Wake) |
Est-ce que vous lisez comme moi: ils ont (déclaré une variable/méthode ?) alors que c'est un nom réservée ? (DSDT.dsl 1459: Name (_PSW, 0x01)) ?
Marsh Posté le 22-04-2009 à 15:01:05
EDIT: J'ai un peu remanié mon premier post en ajoutant des informations sur les IRQ et le pourquoi du comment de l'APIC.
Marsh Posté le 22-04-2009 à 18:03:51
Ce qui est dommage, c'est que ce post risque de ne faire que soulever la question sans pouvoir y apporter de solution envisageable.
Histoire de faire un peu avancer le shmilblik, voilà 2 liens qui apportent quelques lumières :
http://web.archive.org/web/2007101 [...] roken_dsdt
http://forums.gentoo.org/viewtopic.php?t=122145
Marsh Posté le 22-04-2009 à 18:07:13
On peut toujours remplacer le DSDT par une DSDT débuggée, mais ça reste du debugging et spécifique à chaque carte-mère. Cependant il est important, je pense, de prendre conscience du problème et de son ampleur.
Marsh Posté le 22-04-2009 à 18:29:10
D'un autre côté, ce que veulent les constructeurs, c'est vendre. De deux choses l'une, soit :
- Linux fait vendre (significativement) -> les constructeurs s'adaptent automatiquement en écrivant les 2 implémentations.
- Linux ne fait pas vendre -> les constructeurs continueront à l'ignorer.
C'est pas la peine d'espérer l'alternative "MS arrête de vendre son compilateur et change son implémentation présente sur 85% des PC du monde pour un standard dont le non-respect n'emmerde que ses concurrents et non-clients".
Marsh Posté le 22-04-2009 à 18:35:15
Ben le pire c'est que leur compilateur est en libre accès. Disons que si c'était une histoire de compilateur, le code serait à peu près correct. Mais là c'est plus grave: les développeurs se permettent de coder d'une manière peu réglementaire et non stricte car ils savent que le compilateur Microsoft derrière acceptera un code mal foutu (premier aspect qui est pas compliqué à résoudre quand meme, c'est la moindre des choses de ne pas superposer des plages mémoires !). Le deuxième aspect est que les constructeurs demandent aux dev de construire des fonctions pour palier aux bugs de Windows, là on ne peut pas faire grand chose mais ça n'empêche pas de créer un BIOS correct qui est la base du PC.
Marsh Posté le 22-04-2009 à 19:01:46
j'y comprend rien du tout, mais c'est un toshiba satellite U200
on dirait qu'il n'y a pas d'erreur ...
Code :
|
voilà.
Marsh Posté le 22-04-2009 à 19:20:23
Jusqu'ici Acer et Toshiba sont réglos, dommage qu'ils ne fassent pas de carte-mère . Il peut etre en version Linux ton Toshiba ?
Marsh Posté le 22-04-2009 à 19:48:14
BloodyCarnage a écrit : D'un autre côté, ce que veulent les constructeurs, c'est vendre. De deux choses l'une, soit : |
L'exemple de l'Aspire One (conçu pour être vendu en partie sous Linux) et de son bios OK est assez révélateur de cet état de fait
Ça serait intéressant de voir ce que ça donne pour un eeePC, Asus faisant apparemment des choses un peu crades sur le reste de ses gammes.
Marsh Posté le 22-04-2009 à 20:23:58
Un lien extremement interressant je trouve:
http://mjg59.livejournal.com/2008/07/27/
Vous m'avez collé le VIRUS, maintenant j'ai envie de voir un truc:
Sur ma P5Q-E, j'ai bien le speedstep sur le CPU. Cependant, dès que je l'overclock, le speedstep ne marche plus et je me demande si ça serait pas l'ACPI qui fait ça....
Des pistes ?
Marsh Posté le 22-04-2009 à 20:24:26
deK a écrit : |
Tu en a un juste au dessus!
Marsh Posté le 22-04-2009 à 22:23:15
C'est quand même malheureux que l'on soit obligé de faire du reverse engineering pour faire fonctionner linux....
Que veux tu dire que ça ne marche plus, tu l'overclock un peu et tu ne peux plus changer la valeur ?
Marsh Posté le 22-04-2009 à 23:19:46
ReplyMarsh Posté le 22-04-2009 à 23:53:11
redvivi a écrit : Jusqu'ici Acer et Toshiba sont réglos, dommage qu'ils ne fassent pas de carte-mère . Il peut etre en version Linux ton Toshiba ? |
il y a windowsXP dessus d'origine, et j'ai installé un dualboot linux. Il fonctionne pas trop mal, excepté une prise micro que je n'arrive plus à avoir. Une régression dans le pilote alsa je suppose.
Marsh Posté le 23-04-2009 à 00:44:51
M300A a écrit : Un lien extremement interressant je trouve: |
Si je devais parier, je miserais sur une implémentation bâclée et liée du speedstep et du C1E. Speedstep joue sur la fréquence, C1E régule le vcore en fonction de la fréquence.
Quand tu o/c, jouer avec le vcore devient plus complexe et plutôt que de gérer ça ou de désactiver juste la partie C1E, Asus a préféré désactiver tout le bloc speedstep.
En clair, c'est un bricolage quick and dirty pour palier à une mauvaise implémentation mais c'est pas lié à l'OS. Je ne serai pas étonné qu'une version plus ancienne du bios n'ait pas ce "correctif".
Marsh Posté le 23-04-2009 à 08:30:34
deK a écrit : |
En fait ça, y'a deux variables réservées utilisée, ça peut se fixer en deux secondes. Quant aux warnings sur le mute, j'ai lu de la doc la dessus et c'est pas vraiment corrigeable. Si c'est bien compris la valeur hexa c'est le temps du timeout et le problème c'est que quoi qu'il arrive à la fin de ce timeout on fait toujours la même chose. C'est pas choquant en fait.
Marsh Posté le 23-04-2009 à 16:10:50
Je viens de tester avec mon dell dimension 9200 (desktop avec 4Gio de Ram fournie avec Vista 32 normalement )
Intel ACPI Component Architecture |
Cela ne m'a pas l'air horrible. Le seul truc que je regrette sur ce BIOS c'est qu'il se reserve certaines plages memoires entre 3.7 et 4Gio, je n'ai acces qu'a 3.75Gio :-( Et pas de nouvelle maj du bios.
Le speedstep marche bien chez moi.
Marsh Posté le 20-04-2009 à 21:05:12
Bonjour à tous !
Ceci est mon coup de gueule de l'année et accessoirement ma révolte du mois. Vous avez des valeurs de température aberrantes ? Vous n'arrivez pas à contrôler vos ventilateurs, vous avez des freezes, un support incomplet voir catastrophique de la gestion de l'énergie et vous êtes vous Linux ? Ce post est fait pour vous.
L'ACPI, vous connaissez ? Simplement, l'Advanced Configuration and Power Interface permet le contrôle de la gestion d'énergie par le système d'exploitation. Le standard industriel précédent, Advanced Power Management (APM), est contrôlé au niveau du BIOS et le système d'exploitation n'a pas connaissance du moment où l'ordinateur change ou va changer d'état (mise en veille ou non, charge batterie critique, vitesse des ventilateurs, veille prolongée etc).
L'ACPI est généralement configuré à partir du système d'exploitation. Celà est possible à l'aide de la table de description différenciée du système (DSDT). La DSDT fournit beaucoup d'informations au système d'exploitation comme le nombre de processeurs et leurs paramètres, certains IRQ, les paramètres de contrôle des
ventilateurs, les senseurs de températures, j'en passe et des meilleurs.
Petit préalable pour les profanes: L'IRQ (Interrupt Request ou demande d'interruption) permet de contrôler et séquencer le traitement des données de votre ordinateur. Imaginez que vous jouiez à Quake en local, et votre carte Ethernet reçoit un paquet, par exemple contenant le message MSN du boulet de votre liste de contact (on en a tous un...), hop, une demande d'interruption est générée qui va dire au CPU "Hého j'ai un paquet qui vient d'arriver, il faut que tu le traites fissa". Le CPU traite le paquet Ethernet, envoie le joli son MSN dans vos hauts parleurs entre 2 tirs de machinegun et reprend son activité histoire que vous fassiez quelques frags. Un autre exemple d'interruption de la vie courante: Vous écrivez un article sur ce beau forum et vous avez soif: vous arrêtez votre activité, vous allez boire et vous reprenez la rédaction, c'est le principe de l'interruption.
L'APIC comprend 2 composants: l'IO-APIC et le Local APIC ( http://en.wikipedia.org/wiki/Intel_APIC_Architecture ). L'IO-APIC est une table de redirection des IRQ des périphériques (gère les interruptions entre les périphériques, comme le système DMA qui permet de transférer des données entre disques durs/lecteur CD sans passer par le CPU). le Local APIC (LAPIC), lui gère les interruptions du CPU par rapport aux autres périphériques (le boulet sur MSN).
Comme vous pouvez l'imaginer, si la DSDT n'est pas correcte, celà compromet le bon fonctionnement de l'APIC les symptômes suivants peuvent apparaitres:
Personnellement, j'ai déjà rencontré sur 2 serveurs comportant des cartes mères Asus P5B-VM (avec BIOS à jour, Debian Etch, kernel 2.6.18) des freezes inexpliqués, une gestion de l'alimentation minimale (il gérait juste les événements tels que l'appui sur le bouton d'alimentation). J'ai essayé de désactiver la gestion de l'ACPI mais ce n'était pas suffisant. En jouant avec les paramètres du BIOS, la seule manière d'avoir un système stable était d'utiliser les paramètres "acpi=off nolapic" et en désactivant l'APIC dans le BIOS. Un seul changement de ces paramètres me donne des blocages au niveau des I/O ou alors des freeze aléatoires. Sur un ordinateur portable Packard Bell de 2007, gestion de l'énergie incomplète et problème lors de la sortie de la mise en veille.
Pourquoi ce comportement irrationnel ? Visiblement, le BIOS et ses composants (ACPI, APIC) étaient en cause. J'ai décompilé et recompilé la DSDT et j'ai eu les erreurs que vous pourrez trouver à la fin de ce post.
Pourquoi tant d'erreurs ? J'ai appris qu'il y avait, sur le "marché" du BIOS, 2 compilateurs permettant de compiler le code DSDT source en code assembleur ( http://www.acpi.info/ ), l'un provenant d'Intel, l'autre de Microsoft. Le compilateur d'Intel est réputé plus strict et respecte les spécifications de l'ACPI. De plus, le code source du kernel Linux utilise le code Intel afin de gérer la DSDT. Celui de Microsoft peut poser problème et générer des tables non conformes, d'où les erreurs et warnings en fin de post qui provoquent des instabilités systèmes sous Linux.
Autre chose: Une rapide lecture de la DSDT peut nous amener à ces lignes là:
Comme nous pouvons le constater, la DSDT fournie au système d'exploitation n'est pas la même suivant le système d'exploitation détecté. Pourquoi celà ? Mettons nous à la place d'un constructeur de carte-mère qui respecte l'ensemble des spécifications. Malheureusement, cette carte-mère fonctionne mal à cause de certains bugs présents dans Windows au niveau de la gestion de la DSDT. Il faut absolument corriger ce problème car Windows représente plus de 90% de la part de marché. Il nous reste comme seule levier d'action le BIOS, c'est ainsi que l'on demandera à nos développeurs d'inclure des DSDT différentes selon le système d'exploitation afin de corriger ces bugs pour que tout fonctionne bien sous Windows.
Malheureusement, ces corrections de bugs sont dangereuses car les systèmes Windows accepte les modifications de DSDT de toutes les versions de Windows (voir les boucles if précédentes) selon Windows Hardware Developer Central:http://www.microsoft.com/whdc/archive/_OSI-method.mspx. Linux, pour des questions de compatibilités, accepte également les modifications de DSDT de tous les Windows (et pas celle de Linux depuis la 2.6.23, paradoxalement (ftp://ftp.suse.com/pub/people/tre [...] endors.pdf), en effet ce serait bête qu'un périphérique ACPI comme un ventilateur soit détecté sous Windows et pas sous Linux). Ces "corrections de bugs" au niveau du BIOS au profit du système d'exploitation de Microsoft peuvent mener à des emplacements mémoires qui se superposent ou encore des aberrations au niveau des IRQ ("salade IRQ" ).
Détail de la compilation d'une table DSDT par le compilateur Intel compilé à l'aide de celui Microsoft:
Afin d'avoir une vision plus globale du problème (et de mesurer l'étendue des dégâts), je vous propose la manipulation suivante afin de déterminer si votre table DSDT fournie par le constructeur de votre carte-mère est conforme et trouver l'origine de vos éventuels problèmes :
iasl est l'Intel ACPI Source Language compiler/decompiler
Voilà, j'en ai fini. Si vous avez des erreurs, warnings lors de cette manip n'hésitez pas à indiquer le modèle/constructeur de votre carte-mère en cause. Eventuellement il est possible de débugger une DSDT en chargeant une version DSDT débuggée par vos soins dans l'initramfs, donc si vous en sentez le besoin postez l'output de iasl -tc DSDT.dsl
Message édité par redvivi le 22-04-2009 à 15:54:49