Désactiver l'ACPI sans réinstallation [Windows 2000/Xp] - Hardware
Marsh Posté le 08-05-2002 à 11:58:45
ça manque de smilie mais pour le travail
pour bjone
Marsh Posté le 08-05-2002 à 12:55:00
seb31 a écrit a écrit : ça manque de smilie mais pour le travail pour bjone http://membres.lycos.fr/elorac73/i [...] /rig31.gif http://membres.lycos.fr/elorac73/i [...] /rig31.gif http://membres.lycos.fr/elorac73/i [...] /rig31.gif http://membres.lycos.fr/elorac73/i [...] /rig31.gif http://membres.lycos.fr/elorac73/i [...] /rig31.gif |
ha tu l'aimes bien celui-là
Marsh Posté le 08-05-2002 à 13:11:23
bjone a écrit a écrit : ha tu l'aimes bien celui-là |
vi y a des smilies sympas
Marsh Posté le 11-05-2002 à 19:11:58
Bjone
Jai fait se que tu dit pour désactiver lacpi.
Mes sa na rien faite, aucune redétection rien.
De plus je voit encore des affaires ACPI dans le gestionnaire de péri. .
........
Marsh Posté le 13-05-2002 à 23:20:08
soyer franc avec lui dit lui quand vous avez rien compris a ce qu'il as dit
Marsh Posté le 08-05-2002 à 00:21:39
Voilà j'ai trouvé une technique pour désactiver l'acpi de Windows 2000/Xp, sans avoir à le désactiver dans le bios et avoir ensuite à réinstaller Windows 2k/Xp.
Le contexte: (Ok c'est un roman)
Sur ma KG7 qui ne possède pas d'I/O APIC (l'implémentation du pont nord AMD et du pont sud VIA, ont l'I/O APIC d'implémenté, mais sont incompatibles), je possédais une SoundBlaster Live!.
Hors mon Xp était installé en ACPI, mais par le plus grand des hasard, j'avais une bonne isolation des IRQs, j'avais notemment la Geforce3, la SB, la 3Com et le contrôleur USB d'isolés (kewwl le coup de moule), tout ça SANS désactiver l'ACPI dans le bios (avec par exemple un bios comme celui de gentilment tweaké par grosquick en ce qui concerne la KG7).
Le seul reproche que j'avais alors à la SBLive, était un mauvais buffering PCI ou autre problème d'implémentation, qui faisait que Winamp se tapait des délires si le CPU était trop chargé (ou qu'une application prenait trop de temps CPU sans laisser aller la queue des messages).
Aussi, dans certains jeux DirectSound 3D, je lui reproche de donner des grésillements si le jeu n'a pas une conne constance en fps (au du moins rafraichissement des paramètres DS3D).
Par exemple IL2 Sturmovik avait tendance à faire des chtis grésillements lorsque les sources DS3D évoluaient (moteurs d'avions), car me semblerait-il dans certains cas la Live avait du mal à faire évoluer la source.
Opération Flashpoint dans mes souvenirs grésillaient énormément dans certains cas.
Hier j'ai testé l'Audigy d'un pote, et le truc qui m'a tout de suite plut: plus aucuns problèmes de tamponnage PCI
Dans les mêmes contextes que la Live, l'Audigy se comportait tranquillement (donc un bon point pour créative qui a revu l'implémentation PCI+driver pour améliorer les flux dma nécessaire au dsp). De plus le firewire c'est toujours utile.
Donc le lendemain, je m'en vais n'acheter une zolie Audigy oem.
Et le problème qui ne m'avais pas frappé jusqu'alors, à savoir des conflits de drivers qui se pêtent la gueule, car ils sont sur le même IRQ.
En effet, l'Audigy ayant un contrôleur firewire ohci, ce contrôlleur est géré nativement non pas par un driver creative mais par un driver microsoft. Hors semblerait-il, le core audio de l'Audigy et le contrôleur 1394 étant sur la même carte (périph PCI), l'ACPI refusa de ne pas partager les IRQs comme il le faisait avec la Live. Du coup j'avais tout mes périphs PCI et la gf3 sur l'irq 3 (puisque le COM2 est désactivé, l'irq 3 était le premier libre).
(Ce n'est pas la faute de l'Audigy, c'est la faute du partage forcé de l'ACPI).
Moralité: L'Audigy marche du tonnerre, mais le driver de la Geforce 3 se mis à se pêter la gueule furieusement...
Hors je ne voulais pas surtout réinstaller mon système en désactivant l'ACPI dans le bios, j'ai autre chose que 3DMark et Quake3 d'installé, croyez-moi (mon program files fait 5.35Go, y'a aucun jeux/mp3/etc.., que des outils)
J'ai passé tout l'après midi à étriper la base de registre pour empêcher le service ACPI de m'aligner tout sur le même irq, le tout en essayant de deviner ce que les valeurs de la base pouvaient avoir comme influance sur la stratégie d'allocation des IRQs, tout en jonglant de slot PCI pour voir si la stratégie évoluait en fonction des INT A/B/C/D matériels partagés au niveau des slots. Et bin que de chi. L'ACPI refusait catégoriquement d'isoler un minimum d'IRQs, alors qu'avec la Live dans le même slot que l'Audigy j'avais une super-bonne indépendance.
J'étais rentré vers chez moi pour faire mumuse avec l'Audigy vers 5-6h de l'aprem... il était 10 heures j'en avais plein le cul. J'ai donc abandonné la voie base de registre/bios/slot.
J'ai donc fini par rechercher chez microsoft une doc permettant de bricoler violemment Windows 2000/Xp pour faire gicler l'ACPI sans rien planter. (et si ça plante temps pis, j'aurais essayé pas mal de trucs)
Et comme ont dit: RTFM (Read The Fucking Manual)
Forcément j'ai trouvé une doc interressante:
http://support.microsoft.com/defau [...] us;Q237556
Bin voilà pour désativer l'ACPI d'un Windows 2000/Xp sans avoir à le réinstaller, il suffit de prendre le CD de Windows 2K/Xp,
extraire tous les HAL*.DLL du driver.cab du répertoire i386, avec l'expand.exe (ça fait une commande du style "D:\I386> EXPAND DRIVER.CAB -F:HAL*.DLL C:\fichiers_hals).
Et sous dos, ou via la console de récupération vous remplacez le fichier HAL.DLL du répertoire SYSTEM32 de Windows, par exemple le HAL.DLL extrait, qui est un HAL standard sans gestion de l'ACPI.
Au reboot Windows vous redétectera tout le matériel (finalement c'est assez rapide).
Parmi les fichiers extraits, y'a donc d'interressant:
HAL.DLL: Hal sans ACPI, Hal standard.
HALACPI.DLL: Hal avec ACPI (celui qui généralement installé par Windows si le BIOS est ACPI)
HALAPIC.DLL: Hal avec gestion d'I/O APIC pour système mono-processeur.
Voilà, notez que la manip est pas garantie, mais chez moi ça a marché.
Si votre mobo supporte un I/O APIC, ne chercher surtout pas à faire sauter l'ACPI, un couple ACPI+I/O APIC est clairement supérieur aux autres solutions. (l'ACPI est une bonne chose, mais le partage de tous les périphériques sur le même IRQs est mauvaises, les ISRs pouvant alors se planter les uns les autres)
Notez aussi que du coup, le core audio de l'Audigy n'est pas sur le même irq que le contrôlleur firewire. L'Audigy est en 12, la gf3 est en 10, la 3Com est en 11, seul le contrôleur USB et le contrôleur 1394 sont sur l'irq 5 (ce qui est largement tolérable).
Par contre forcément j'ai perdu la gestion des événements ACPI et de la gestion d'energie (dont surtout la gestion du bouton d'extinction, maintenant ça coupe NET)..
Donc voilà, j'espère que ça pourra être utile à certains...